RE: Future of DSSSL: What about PDF?

[Avi Kivity <Avi@xxxxxxxxxxxxx>]

On Saturday, March 06, 1999 22:15, Didier PH Martin
[SMTP:martind@xxxxxxxxxxxxx] wrote:
> jade code maintenance and modifications) is that what is missing is
> real
> versatile grove objects.

I understand that Jade does have an abstract (C++) grove interface, and that
someone (on this very mailing list) COMed it some time ago.

> 
> 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).

> 
> 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!

> 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).

>  <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.

---
"The only words which have meaning are the last ones spoken"


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