Re: Jade/DSSSL future

Subject: Re: Jade/DSSSL future
From: Adam Di Carlo <adam@xxxxxxxxxxx>
Date: 27 May 1999 15:17:46 -0400
I'm glad to see my posting has sparked some serious, constructive

Let me start off by saying that at this point, no one has stepped
forward and offered to maintain jade, so I would guess it's still up
to you at this point AFAICT.  I don't know how many patches you have
in your jade queue -- I've seen a lot of patches floating around, but
actually not much that was really significant in terms of
functionality or increasing the quality/usability of jade.

James Clark <jjc@xxxxxxxxxx> writes:
> My priorities would be a bit different.

Naturally :)

> >   * some misc DSSSL features and operators missing (there was a patch
> >     submitted on this list which looked pretty good to me)
> A lot of these can be trivially implemented with the existing operators,
> and there's little performance benefit in implementing them in C++, in
> fact there may be a loss because of code bloat. A better solution for
> such operators would be an ability to automatically preload a startup
> file with function definitions (you have to be careful to ensure that
> these preloaded definitions work even when other primitives get
> redefined).

Interesting -- shouldn't even been very hard.  I agree with this
assessment.  I guess DSSSL hackers can endeavor to do this already --
we can emulate the preloader using external specification stylesheets.
It even sounds fun to me (I like Scheme much more than C++, wacky me).

> I agree that it would be nice to have the operators that cannot be
> defined in terms of the others, but I don't think this will make a big
> difference to the overall utility of Jade.

Probably not...

> Yes.  It would be better to do more work in the backend and less work in
> macros.
> Apart from the things I've mentioned, my priorities would be:
> - 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 is an excellent idea and very interesting.  In fact, I would
think that if we can pinch off the backends from the core in this way,
it will be (a) easier to add and maintain backends, and (b) the fact
that you could tie in backends with more than just jade would increase
the possible coverage (audience) for the backends.

I need to learn more about FOTs.  Are they similar/the same to FO in
XSL?   Are you saying:

  jade -> <some_file>.fot -> separate backend (i.e., RTF or TeX) processor
                          \-> alternatively, do other stuff with the FOT, 
                              i.e., use XT on it

> - Make it easier to use Jade for XML.  At the moment the fact that the
> DSSSL stylesheet is an SGML document makes it awkward to use Jade with
> XML.  There are several possible solutions here and I'm not sure what
> the best is.

The easiest in my mind would be to make the DSSSL stylesheet into a
XML rather than SGML document.  However, I don't want to close the
door to SGML users -- could we still exploit architectural forms and
all that?

> - Support XSLT in Jade. XSLT has an xsl:functions element that allows
> XSLT stylesheets to include extensions written in arbitrary extension
> languages. With Jade, that extension language would be the DSSSL
> expression/query language.  This is probably too much work.


> My general feeling is that just as the future is XML not SGML, so the
> future is also XSL not DSSSL.  When XSLT and XSL are done, there will (I
> hope) be nothing you can do in DSSSL that you can't do with XSL(T). 
> DSSSL has not achieved widespread acceptance, and of course that's
> disappointing to all of us involved in DSSSL.

I agree with you, and I understand that you are going to put your
attention towards a technology that you feel has a future.  However,
XML or SGML via DSSSL *today* is the only open standard technology
which can produce quality printable output (even with its problems).

>From a cynic's standpoint, XSL-FO is still 2 years off, and definately
there's no guarantee it itself won't hit critical implementation flaws
and problems.  The fact that big corporations are shoveling money into
it helps but doesn't guarantee success.  Anyhow, I'm not trying to
flame XSL (in fact, I think XSLT is excellent) ...

I would hope that possibly we can hit a FOT/FO synthesis point, and be
able to adapt, for instance, Jade backends to either DSSSL or XSL.
You seemed to hint above that this might be possible.

> On the XSL flow objects side, politics and market realities have
> necessitated building DSSSL functionality on top of CSS formatting
> objects/properties rather than starting with the DSSSL flow objects.

Interesting, never heard this stated before.  XSL-FO is still
grove-based, though, isn't it?

> On the XSLT side, as
> we've continued to work on the language we've found many ways to improve
> it, and the language has evolved substantially from DSSSL; however it's
> still very much the same approach to transformation as jade -tsgml. 
> There are big advantages to being in the mainstream, and XSLT looks set
> to become a mainstream technology.

I agree with this assessment.  My assumption is that jade will be in
serious (even if not widespread) use even 5 years from now for the
generate of printable output; whereas XSLT will probably *practically*
obsolete 'jade -tsgml' within 18 months.

> So what does this mean for my involvement in Jade?  I think the reality
> is that although there are improvements that I would dearly like to
> make, it's unlikely, at least in the near future, that they are going to
> get to the top of priority list, and I don't want to stand in the way of
> others who wish to make improvements.
> I do have one request: if you release something independently of me, you
> call it something other than simply Jade, but preferably a name that
> acknowledges Jade; maybe OpenJade or something like that.
> I am also willing to make all my RCS files available, which I would
> suggest be used to start a public CVS repository.

Well, if there are any C++ hackers out there willing to take up jade
maintenance, I might be able to swing publically accessible CVS space
at, and I'd be willing to personally convert the RCS,v
files to a CVS area (it's pretty easy).  Let me know.

> I also have one strong recommendation on how to proceed with Jade
> development.  Before you start hacking the code, create some
> documentation on Jade internals. Jade was not designed for a bazaar
> development model and there is no internals/design documentation.  But

Very sage recommendation. I also think the core/FOT/backend breakup
you suggested is most intriguing, and would help reduce the curve
also.  Wish I was a C++ wizard, I'd be tempted to take up this

.....Adam Di Carlo....adam@xxxxxxxxxxxxxxxx<URL:>

 DSSSList info and archive:

Current Thread