Subject: RE: Future of DSSSL: What about PDF? From: Avi Kivity <Avi@xxxxxxxxxxxxx> Date: Sun, 7 Mar 1999 22:23:06 +0200 |
On Sunday, March 07, 1999 18:43, Didier PH Martin [SMTP:martind@xxxxxxxxxxxxx] wrote: > HI Avi > > <YourComment> > I understand that Jade does have an abstract (C++) grove interface, > and that > someone (on this very mailing list) COMed it some time ago. > </YourComment> > > <Reply> > You are right, grovea.dll is a COM object. However, it is not > implemented > with the composite pattern and is therefore quite restritive. A > "general > grove" interface could potentialy be more versatile, even be able to > other > hierarchical structures like, for instance, directory services. This > is why > I included the "general grove" interfaces. So that you can see by > yourself > that the interface is more adaptable to different kinds of > hierarchies > inluding document groves. > </Reply> > > <YourComment> > > > > When you look closely to what a dsssl engine is doing: > > > > a) it parse the SGML/XML document and construct a grove > > b) from this grove it (theoretically) construct a new one. This > > latter is a > > FO grove contrary to the former which is a document grove. > > Jade also has an abstract (C++) flow object interface - the Flow > Object Tree > Builder. Nothing prevents you from COMing (or RMIing, or CORBAing) > it as > well. > > I mentioned in an earlier post that I believe that it would be a > mistake to > tie Jade down with an additional interface technology. Right now it > is only > tied to C++, which is widely available, non-proprietary, efficient, > and > easily extendable (albeit not as easy to use as some others). > </YourComment> > > <Reply> > But we can also use the XPCOM mechanism which is portable but is > language > dependent (C++). However, dynamic module invocation is possible with > XPCOM. > A think impossible actually. The style engine and the FO backend are > in the > same module. It can be possible to decouple them and invoke a > particular FO > module dynamically. > </Reply> > > <YourComment> > > > > So, basically we have to deal with groves. Most grove interfaces > > that I saw > > makes this equation "concept object" = "code object" instead on > > creating a > > general mechanism based on good software practice like > > implementing > > a grove > > with the composite pattern (gamma & al.). I'll explain. This > > brings > > us the > > result that we have to multiply entities. > > > > I see nothing to be gained by unifying the interfaces of the source > grove > and target flow object tree. The usages are very different! > </YourComment> > > <Reply> > Its only a choice. A style engine can simple use the document grove > and > create an output stream. Or having a FO grove could help for real > document > transformation. So, in this case you have document grove ---> > document grove > kind of transformation. > </Reply> > > <YourComment> > > If you look at a document's hierarchy or the concept of a grove, > > it > > is > > simply a hierarchy of objects and to each object is associated a > > property > > set. The composite design pattern is simply that all objects > > inherit > > from a > > basic object used to manipulate a collection or implement an > > interface to > > manipulate a collection. Thus, for example, imagine an object > > having > > methods > > to manipulate a collection of objects and therefore you can say > > that > > this > > object is implicitly a collection of objects. Usual collection > > methods could > > be implemented in this object like: > > - add an element (the element is an other object and therefore we > > can create > > a tree) > > - remove an element > > - delete an element > > - update an element > > - find or get an element > > dsssl defines for node-lists only the 'find or get' operations, and > for > result-node-lists and sosofos, 'add'. > > I don't think there's anything you can do with a flow object tree > except > render it. Nothing to do with a result-node-list except using it as > a > node-list for some other operation (possibly outputting and re- > parsing sgml > in the process, but this could and should be avoided). > <YourComment> > > <Reply> > I talked about a grove object interface not about each object class. > A > specific class instance could be created with a grove object. You > can > strongly type the class by validating the property set or simply not > do any > validation. > </Reply> > > > <YourComment> > > <long discussion containing many names of various technologies> > > >From the latest round of talks, I can see that there are too > >concerns > regarding dsssl development > - internal development - movement towards a full conforming > implementation, > including more capable back-ends > - external development - more ways to interface, distributed dsssl- > ing, etc. > > I believe the former is much more important right now. Also having a > full > implementation first would help define the interfaces correctly. > <YourComment> > > <Reply> > Your point is well taken. As soon as have something more stable (the > grove > engine is very stable and tested since one year) but to modify the > dsssl > engine to include it is not as easy :-) > </Reply> > > Regards > Didier PH Martin > mailto:martind@xxxxxxxxxxxxx > http://www.netfolder.com > > > DSSSList info and archive: > http://www.mulberrytech.com/dsssl/dssslist --- "The only words which have meaning are the last ones spoken" DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Future of DSSSL: What about PDF, Didier PH Martin | Thread | RE: Future of DSSSL: What about PDF, Avi Kivity |
Re: DSSSL style sheet for the XML s, Stefan Mintert | Date | RE: DSSSL style sheet for the XML s, Didier PH Martin |
Month |