In this article I have tried to give the reader the flavour of DSSSL without getting into too much detail. There are several areas in which I feel the only (currently) generally available DSSSL style engine, Jade, needs to be improved before it can be applied for most commercial publishing applications.
Jade implements a superset of a subset of the full DSSSL standard know as the DSSSSL Online subset. While this subset can be used for some simple publishing applications it is inadequate for the requirements of many commercial ones. I feel that the following parts of the DSSSL standard need to be implemented:
· the full page flow object class in order to allow such common typesetting devices as dictionary running heads and bottom of the page footnotes to be specified,
· the machinery for specifying transformation of SDATA entities,
· the expression language functions for string and character comparison.
ISOGEN has funded the development of a MIF (FrameMaker Interchange Format) backend for Jade and has said that it will soon make it generally available.
Additional backends are needed for common output formats, such as, Quark, Interleaf, Folio, DL Composer. It would seem that the companies that make these products would have a vested interest in seeing that backends are developed for them.
While Scheme may have been a desirable choice as the basis for the expression language by many measures, user acceptance may require that a more familiar language be selected. The current XSL (XML Style Language) submission uses a combination of XML (eXtensible Markup Language) instance syntax and ECMAscript for its specifications. I don't know if DSSSL will be revised to use some other syntax but whatever syntax is used I believe that the underlying concepts in the DSSSL standard will remain useful.
Contact Robin Cover with corrections and updates, or to submit contributions to the ISUG online document database.
