RE: (dsssl) Re: The Future of DSSSL

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

Hi Sebastian,

Sebastian said:
but its not fine for XML applications. As we move to namespaces
and schemas, SP is dead in the water.

arguments for the future of DSSSL are good and fine, but if they don't
encompass XML, they are evanescent vapours, IMHO.

Didier Replies:
I agree. I still remember some arguments I had with Matthias about this
topic. My opinion was and is still today the same. One solution is to
separate the groove engine from the DSSSL engine. By having a clear API and
packaging of modules as, for instance, XPCOM modules, we could have modules
implemented in different languages to communicate together. The decoupling
could be performed as follow:

parser <---> Groove <----> DSSSL

This implies that the groove engine has an API to allow adding, removing,
moving nodes. So that a parser can add new nodes. The parser could be either
an SGML, XML or tutty quanti engine. The goal is that perform a
transformation for a format (i.e. text) to a structure (i.e. Groove). We can
easily imagine as Peter Newcomb and the guys at Isogen are doing every day
to have an engine to perform a transformation from word into Groove or from
a relational data base to a groove. Basically, at this level we have to
perform a translation from something into a hierarchical structure. DSSSL
needs a special property set. This means that the structure has to be
conformant to a particular set or hierarchy of node, each node being of a
particular type (i.e. having a specified number and type of properties).

On top of the Groove engine, any consumer can be envisioned. A DSSSL engine,
an XSLT engine, etc.

So the trick is to at least separate the OpenJade system into 3 major
components

a) Groove builder (i.e. parsers, structure translators, adaptors, etc.)
b) Groove engine
c) Interpreters or Groove consumers (i.e. XSLT, DSSSL, Basic, Perl, etc...)

We are not limited to imagine a Groove structure to be limited to DSSSL. For
instance, a mapper could as well map a groove structure to Java objects and
allows to access a particular node as a class member. Other access mechanism
can also be envisioned.

An other interesting architectural remake would be to separate the FO
modules as well.The main problem with OpenJade today is that everything has
to be implemented in C++ and that everything has to be recompiled. These are
main problem caused by object systems based on inheritance or white box
systems. Other systems like CORBA, DCOM, XPCOM do not have the same
limitation. By having the elements decoupled you even can access one of them
over the net as a web service (but this is a different story).


Cheers
Didier PH Martin


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