(dsssl) The Future of DSSSL

[Brandon Ibach <bibach@xxxxxxxxxxxxxx>]

[Note: This was originally posted on Dec 20th, but due to
       an addressing issue, didn't make it onto the DSSSList.]

   First, let me apologize.  I stirred things up a bit a while back by
suggesting a real-time discussion of future directions for DSSSL
implementations, but never got the discussion set up.  In part, this
was due to the holidays and other diversions, and in part because I
couldn't decide when the best time would be to have this discussion
and include as many people as possible, especially since DSSSL users
are spread all over the globe.
   So, I'm going to fall back to discussing these topics on the
DSSSList.  I'm also addressing this message to the OpenJade
Development list, just in case there are people there, not on the
DSSSList, who are interested, but I suggest we keep the discussion on
the DSSSList and maintain the subject line, in case there are those
who wish to bypass this discussion.

   Let me start by stating my bias, which is that I'm an information
processing geek, so I tend to shy away from the formatting side of
things.  So, forgive me if I don't put as much attention towards those
issues, and I hope that those more involved in that side of things
will prop up that part of the discussion.
   I'll start with generalities and work towards specifics.  While I
acknowledge that there are other DSSSL implementations out there, such
as those offered by NextSolution, by and large these days, DSSSL means
Jade or OpenJade.  Neither of these packages are being actively
developed right now, and it is my opinion that this is unlikely to
change anytime soon.

   Jade has been, and continues to be, a wonderful tool for many
applications.  It deserves recognition as the reference implementation
of DSSSL, developed by James Clark right alongside the DSSSL
specification itself.  However, it has a rather monolithic, fairly
proprietary and somewhat closed design.
   The SP parser, upon which Jade is based, is fairly "heavy", being
built on top of a non-standard library of code which provides a great
deal of the low-level functionality such as string and message
handling.  Jade's DSSSL engine is built on top of SP, and can not
feasibly be separated from it.  Nor can Jade easily be put atop an
alternative grove implementation, such as one built with a
lighter-weight XML-only parser or one built atop a database.
   The Scheme implementation at the heart of Jade's DSSSL engine is
also custom-made.  While there is no real inherent problem with this,
it does preclude the ability to take advantage of improvements that
might become available if Jade were instead built upon an independent
Scheme implementation, such as optimization improvements,
pre-compilation and even ports to new platforms.
   Lastly, I have long felt that DSSSL's Style Language would be best
implemented as a layer atop the Transformation Language.  I think many
would concur that this approach has been validated by a similar design
in XSL, where the XSLT language serves as a generic transformation
tool, with the XSLFO grammar being one possible target.  Very few are
even familiar with the DSSSL TL, largely due to a lack of
implementation of it.

   Now, having royally trashed our favorite DSSSL tool, on to my
point.  I believe the best way to reinvigorate DSSSL implementation is
to "start fresh" with a new implementation.  However, I think it would
be a mistake to throw out everything that's been done, so I want to
make sure that everything worth keeping from existing implementations
is reused.  But first, the overall design.
   There are, as I see it, five main components to a complete DSSSL
implementation: the expression language (Scheme), the grove
implementation, the transformation language, the style language and
the interface to formatters (backends).  As I stated above, I think
the best way to go for a Scheme implementation is to use an
independent implementation that can offer features such as good
optimization and pre-compilation.  Just to stress that last point, how
much faster do you think your Docbook formatting would go if the
Modular Stylesheets were pre-compiled?  Further, if done right, I see
no reason why the system could not be ported to other Scheme
implementations with minimal effort, opening up new platforms and
applications that are not feasible today.
   For the grove implementation, the logical start would be to use
Jade's existing SP-based grove, but integrate it through a generic
interface, such that any number of other implementations could be
created later on.  Ideas that come to mind are lightweight XML-only
groves, an adaptor to allow use of existing information stores with
DOM-based interfaces, interfaces to non-SGML sources, such as
databases, other file formats (DSSSL-based access to MS Office
documents, anyone?) and even real-time data acquisition.  For those
familiar with COM (or other component technologies), how about a
grove-based interface to objects?  Closer to current usage, an
alternative SGML grove implementation could make use of a cache of
pre-parsed documents that could be loaded quickly into memory, or even
cached in memory, for high-throughput production systems, such as a
DSSSL plugin to a web server.  The possibilities are endless.
   The DSSSL Transformation Language is actually fairly simple, so it
shouldn't take too much to implement.  Henry Thompson's DSC
implemented it, and could serve as an example of how to approach it.
As well, there is a wealth of code in Jade that could provide, if
nothing else, models for how to implement certain constructs which are
present in both the Style and Transformation Languages.  Implementing
the Style Language on top of this should then be fairly
straightforward, again utilizing existing code from Jade as a model
for certain aspects.  For what it's worth, I could easily see
implementing XSLT on top of the DSSSL TL, as well, allowing an
alternate "grammar" for transformations on top of this powerful
architecture.
   For the final piece, the formatting backends, I see no reason why
the existing Jade backends could not be used mostly as they are, but,
as with the grove, through a well-defined interface.  This already
exists within Jade, though I would like to see it extended to allow
for, among other things, two-way communication between the backend and
the DSSSL engine, which is needed for certain more advanced features
of the Style Language.

   Now, the final topic, and, as I acknowledged above, the one about
which I have the least to say (think goodness, eh?  you all still with
me this far down?), is that of more complete formatting support,
primarily the page-sequence and column-set-sequence features of the
DSSSL Style Language.
   This is probably the most requested feature for Jade.  While I
doubt most projects require every feature of the page-sequence and
related objects, there is certainly a very real need for more complex
layout than is possible in the current backends.
   Two opportunities have recently arisen.  Takashige Noguchi, of
NextSolution, has expressed a willingness to help improve the
formatting capabilities of Jade.  Given the advanced capabilities in
NextSolution's products, this could be an excellent opportunity.
Also, Javier Farreres has indicated that he has at least one student
interested in doing work on the page-sequence features of DSSSL.
   Javier, how would you like to see a project to develop a backend
(or enhance an existing backend) for Jade with at least partial
page-sequence support?  Would it make sense for your student to "lead"
the project, perhaps setup via SourceForge, to allow others to
contribute?  Takashige (pardon me if that's not the appropriate way to
address you, informally), would you (and possibly others with
knowledge of high-end layout techniques) be willing to serve as a
"technical advisor", as well as whatever other efforts you might wish
to contribute?
   Ideally, the needs of this group would help drive the design of the
new, more powerful interface between the DSSSL engine and the
formatting backends.  Depending on the timing of various efforts, it
my be possible to fit this new (or enhanced) backend on to the
existing Jade implementations, minus some of the features which rely
upon services not offered by Jade (such as two-way communication
between the DSSSL engine and the backend).

   Well, I'm sure I could go on some more, but this email is already
too long, methinks, and if I don't stop now, it may never go out.  So,
I hope this sparks some excitement and discussion out there, and I
hope this will help find others who have a passion for the future of
DSSSL.  On a personal note, I expect to be starting a new job soon,
which will have me working in this area pretty much full time, and if
all goes well, my work there and work on projects such as these could
lead to some mutual benefit.
   Best wishes to you all, and happy holidays (whatever holidays those
may be)! :)

-Brandon :)

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