RE: Future of DSSSL: What about PDF?

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

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