Re: Scheme for DSSSL Back Ends?

Subject: Re: Scheme for DSSSL Back Ends?
From: Alex Milowski <lex@xxxxxxxxxxxxxx>
Date: Tue Apr 1 18:27:09 1997 EST
> Most DSSSL implementations that are intended to produce textual output
> (RTF, TeX, Mif, etc.) will have a concept of a "back end": an API that
> maps make-expressions to constructs in the target language. Every full
> DSSSL implementation will also have an implementation of the Expression
> Language, which is basically Scheme.
> It seems to me that we could define (informally) a common set of
> functions for creating new back-ends in Scheme. Those back-ends would be
> faster to write for non-C++ or non-Java programmers, and portable
> between DSSSL implementations. These back-ends would not replace the
> current ones (they might be much slower), but would augment them to make
> the set of DSSSL targets as large (and as portable) as possible. Many
> back-ends could be prototyped in Scheme, but "mere mortals" and then
> recoded in Java or C++ after they have proven themselves.
> What do implementors think?

Well, to some extent, this is what I have been trying to do with our
dsssl.grove and dsssl.flowobject packages for DSSSL in Java.  These packages
allow loading of custom flowobjects and loading of "exteriors" or "interiors"
for specifying the semantics for the "back-ends" of the DSSSL engine.

Unlike Jade backends, the flowobject tree is not specified in an event
stream.  A logical flowobject tree is built for the document as the
result of applying a compiled stylesheet and the flowobject tree is then
handed to the exterior/interior semantic--which could be a dynamically
loaded Java class.

Thus, application of style is separated from interpretation of the
semantics of the flowobjects.

I am working on a white paper that describes how all this works.

For now, there is some information at:

R. Alexander Milowski   alex@xxxxxxxxxx
Copernican Solutions Incorporated                  (612) 379 - 3608

Current Thread