RE: Future of DSSSL: What about PDF?

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