RE: Unix login name and full name into output?

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

Hi Brandon:

Brandon said:
--------------------------------------------
   In theory (if my understanding of OpenJade's internals is correct),
this should be quite simple.  OpenJade supposedly uses some type of
generic interface to groves.  SPGrove is an in-memory implementation
of this interface based on SP.  Could we not create a new
implementation of this interface which would pull in the appropriate
information when requested via SDQL?  My question would be what
OpenJade's abilities are as far as interfacing to multiple grove
implementations in a single session.  In other words, could the object
returned by (environment-grove-root) (or whatever we call it) somehow
indicate which grove implementation serves that grove?

Didier says:
-------------------------------------------
I Have checked the spgrove package and more particularly the
grovebuilder.cxx file. Yes you are right, this implies that we create a new
node type (ex: environment) having as child the (grove-root) element.
Talking of  grove, we discovered that there is indeed some services
available to update the grove. These services could be useful for the
transformation part or for custom grove plan based on grove plans. This
would require a grove plan interpreter able to dynamically create a grove in
accordance to this grove plan.

Thus, a grove built from a grove plan requires an interpreter able to decode
property sets declarations. Such interpreter need to process SP parser
events and update the grove accordingly. The code used to update the grove
is the chunk series of struct and classes having this inheritance (ref:
groveBuilder.cxx):

Chunk (struct)
  |__ LocChunk (struct)
	   |__ ParentChunk (struct)
		     |__ ElementChunk (class)

So, the class to use is ElementChunk having the following members:
- setNodePtrFirst which is used to set a node' content ( data, element, or
node list)

To add to the collection of existing items a new environmentobject, we need
to create a new grove element (packaged as a class). When the class is
instantiated it pulls the environments variables from the system and keep
that in class's internal variables. Then, when a SQL request is made on the
grove manager for an "environment" node type, the content is accessible.

Matthias, included in the OpenJade to do list support for grove plans, this
implies that the grove engine, could be parameterized with property sets.
This is a very powerful capability because, if the grove engine can be set
to any kind of property set, then we can create new objects and, therefore,
create more significant grove objects. Steve Newcomb reported that groves
have been created for the legal field. This implies that you can query not
only a generic object like a sgml-document node but also a more semantically
significant node object like a legal-document. This latter instance created
from a class which itself inherits from the sgml-document class. This has
major impacts on the query language part of DSSSL. Thus, if we can set grove
plans, we can build the infrastructure for semantically rich query language
based on the domain language instead of the generic static and more general
purpose grove plan.

In the OpenJade team, we are slowly gaining more knowledge about the grove
engine and we are studying how to modify it so that the grove could be
dynamically defined by a grove plan. If we can reach that point, the next
step is to provide an interface to external grove engines based on different
memory schema than the local heap (i.e. relational database, object data
base, directory service, etc...). Imagine for a second, the impacts of such
grove manager. We would be able to query a directory service as you would
query a document, or we would be able to format an invoice or statement
directly form a relational database (this is a major impact for enterprises
having their ERP system already based on relational databases).

We did not set any priority yet, just a to do list. However, we agreed that
our first goal is to fill the missing gaps in the actual core language and
in some backend engines. Matthias is working on the core language and me on
the html backend. Matthias goal is to add support for the corte language
missing constructs. My goal is to have a single script which would use the
same flow objects and format a SGML or XML document into: a) html, b) rtf,
c) pdf, d)MIF and have these documents respectively rendered in: a) a html 4
browser, b) word, c) Adobe pdf viewer, d) framemaker. Having this would mean
that we have reached to a certain point the goal of "write once" "output
everywhere", or at least having progressed toward that goal. To reach that
goal I need to bring the html backend to the level of the other backends and
add support for tables, links (on url instead of idrefs, etc...)

As a parallel activity, we have to slowly build the DSSSL-2 draft (this task
is not an OpenJade task but more an ISO task - but based on this community
experience and wisdom). Like said earlier, we are just probing the needs and
are lurking the good things learned in other languages like for instance
XSL. XSL made a proof of concept for template based processing and the
leverage of their kind of processing which allows transformations or a
descriptive way of programming a style sheet. Ken Holman one day told that
this is a kind of programming by example. This is indeed a powerful
paradigm. We can study carefully is this kind of capability could not be
included in DSSSL. At a certain point, the authors of DSSSL where thinking
seriously to include such feature into DSSSL. We can at least make our
homework and see how we can integrate template based notation in to the
DSSSL framework. Also, James started the work to simplify the query language
(ref: http://www.netfolder.com/OpenJade/dsssl2.htm#ExtendedPatterns ), the
result of this work is now found mostly in XPath. We can see how we can
harmoniously integrate a new kind of query-expression in DSSSL-2. Jeames
made interesting suggestions base on grove navigation (parent, sibling,
child, document, processing-instruction, etc...). The suggested extended
pattern was mostly for element pattern match and not necessarily for
queries. However, this could also be used in the context of queries because
the operators are based on the grove. (NOTE: I hope that this time, people
reading the messages a bit too fast won't make comments about our inability
to discern between the dsssl2 features set of OpenJade and the DSSSL-2 next
generation specifications).

Very recently, James made an announcement for a new XT version. Something in
it grabbed my attention: Support for single/multiple input and
single/multiple output. Said differently, James created an extension
allowing xml document aggregation (multiple input) and the creation of
multiple documents (multiple output). A very recent thread on this list just
showed a need for such feature. I played with XT to see how this behaves and
I could create a batch processing domain language. The good thing is that
this batch processing has the potential to be platform independent and run
as well on Linux as Windows (no platform dependent script to do, instead a
standard based language to express a batch file). This reinforce me to think
that this is a good feature. Now, if this kind of feature is implemented in
OpenJade, we have the advantage of our "write once" "output everywhere".
Thus, SGML/XML documents could be transformed in more than one output
format. I only I got this for the demo next week in Montreal. But now the
goal could be to get this for the demo next year. This feature also depend
on the grove.

So, it seems that the give manage is at the hart of several improvements:
a) grove plans and semantically rich groves and therefore semantically rich
queries. This implies a dynamic grove instead of a static grove. For
example, a grove plan may state that a legal-document class inherit from a
sgml-document class and this would translate into new properties and then,
queries possible on these properties.
b) Grove memory management for multiple input/multiple output. A better
memory management (i.e. garbage collection) of groves is required for this
kind of processing. Up to now, OpenJade is missing document or file level
operators or functions. With this kind of feature, OpenJade would have the
capability to output more than one document in more than one format. This is
not negligible.
c) Template based and pull processing needs also good grove management.
However, if we can add semantically rich groves (created with custom grove
plans) to OpenJade, we also provide a way to create domain dependant
queries. Thus, particular domain languages could share common grove plans
and then query constructs (i.e. particular to declared additional or
complementary properties). This is not even dreamed yet by the XSL world
which depend on DOM and this latter is light years behind the grove concept
as demonstrated by Paul Prescod (ref:
http://www.prescod.net/groves/shorttut/)

CALL FOR HELP: If you have C++ skill, we need help. If some people would
just give a bit of time to help us build the next generation OpenJade, this
would be very appreciated.

regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist