Subject: RE: (dsssl) Re: The Future of DSSSL From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Wed, 2 Jan 2002 15:12:38 -0500 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: (dsssl) Re: The Future of DSSSL, Sebastian Rahtz | Thread | RE: (dsssl) Re: The Future of DSSSL, Didier PH Martin |
RE: (dsssl) Re: The Future of DSSSL, Didier PH Martin | Date | Re: (dsssl) Re: The Future of DSSSL, M. Wroth |
Month |