Re: Jade/DSSSL future

[Brandon Ibach <bibach@xxxxxxxxxxxxxx>]

Quoting James Clark <jjc@xxxxxxxxxx>:
> >   * the proper DSSSL transformation language is missing (I'm not sure
> >     if this is worth implementing -- it would seem that DTD-to-DTD
> >     transformations are possibly better handled with XSLT, although
> >     for SGML users it would need to be accompanied by some SGML->XML
> >     conversions as well)
> 
> I think this would be almost completely useless.  The jade -t sgml
> approach is better, and XSLT is better yet.
>  
   Well, I can't really say anything much about XSLT, as I haven't
been following it lately, but I do have some thoughts regarding (to
coin an acronym) DSSSLT and Jade's SGML backend.  The SGML backend is
much easier to use and provides a much more straightforward model for
doing SGML->SGML transformations (or any combinations of XML/SGML).
However, I think that DSSSLT has a much broader scope than this, and
deserves some attention for that reason.
   The reason I've longed to see an implementation of DSSSLT is that I
believe it has great potential for uses far beyond the fairly basic
SGML->SGML transformations that dominate the current DSSSL and XSL
landscape.  For instance, Eliot Kimber has an excellent excerpt called
"Property Sets and Groves" from his forthcoming "Practical Hypermedia:
An Introduction to Hytime".  It is available at:
	http://www.oasis-open.org/cover/kimberPropGrov.html
In it, he outlines a really slick scenario in which a grove is built
from an SGML document (as Jade does).  Other groves are then created
based on this initial grove using transformation processes based on
architectural forms.  These derived groves are linked to the original,
allowing for some incredibly powerful processing possibilities.  This
type of derivation of groves with links back to the source is not
possible in the SGML backend.  Nor, I suspect, does XSLT have this
kind of facility.
   I may be wrong about this next point, but as I read the DSSSL spec,
there is nothing SGML-specific about the transformation language,
meaning that groves generated from other sources, using non-SGML
property sets (from Word documents, spreadsheets, databases... you
name it!) could be manipulated using the transformation language as
well, opening DSSSL up to be a real unifying force in document and
information management.
   Replace DSSSLT with something else if there's something better, but
just promise me that whatever it is will have *all* of DSSSLT's
capabilities.

> >   * jade is slow (is this even fixable?)
> 
> SGML also brings a lot of overhead to Jade.   A DSSSL stylesheet has to
> be parsed as SGML, the DTD has to be parsed, all the content checking
> has to be done, then the meta-DTD also has to be read and that has to be
> parsed, and the architectural document has to be created; only then does
> the real DSSSL parsing start.  A version of Jade that used an XML parser
> rather than SP and in which DSSSL files didn't have an SGML
> architectural wrapper would be a lot faster.
> 
Quoting Sebastian Rahtz <sebastian.rahtz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>:
> now you're talking... but presumably one of the main groups of people
> who want Jade/DSSSL is the subset of current SGML users who really
> want to stay with full SGML? so one would not want to actually kill
> off their route
> 
   What about caching pre-parsed documents (particularly style-sheets,
but also the possibility of documents that don't change too often)?
Could Jade be modified to allow for serializing a grove to disk, then
reading that back in the next time a document is requested?

> - Making the backends useable independently of the rest of Jade.  Create
> a small program (using an XML parser like expat rather than SP) that
> reads the FOT file and calls an FOT backend.  This would require some
> tweaks to the FOT format and to the FOT interface.  The point of this is
> that it would then be possible to use XSLT with DSSSL flow objects.
> 
   This kind of comes back to the idea I've had for some time to
"componentize" Jade.  Note that I do not necessarily mean that COM,
CORBA, etc would have to be involved, but rather that the individual
components (grove construction, DSSSL engine, backends, etc) would be
well separated with very defined interfaces such that they could be
wired together in different ways.  For instance, there would be the
traditional Jade application that puts them all together just as they
are now, standalone backends that would employ a parser to read in an
FOT and pass it to a backend for translation into a formatted
document, as well as the possibility of writing COM, CORBA, etc
wrappers for individual components or sets of components.
   On a related note, what does everyone think of the idea of a
standardized interface, a la the DOM, to the more general grove
concept used in DSSSL.  Could DOM level 2 (or 3, or whatever) work for
this?

-Brandon :)


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