Re: Generating high-level formatting output

[Norman Gray <norman@xxxxxxxxxxxxxxx>]

Greetings,

On Thu, 17 Jun 1999, Sebastian Rahtz wrote:

> Adam Di Carlo writes:
>  > AFAIK, XSLT (the most mature and implemented part of XSL right now) is
>  > for DTD-to-DTD conversions, so wouldn't buy us much in XML -> TeX
>  > production
> no, its a delusion that you cannot write XML to TeX in XSL. You can do 
> it two ways
>  <xsl:text>\documentclass{foo}</xsl:text>
> or
>  <documentclass name="foo"/>

I don't think this gains you anything, unless you know that all you're
ever going to be interested in is conversion from XML to LaTeX2e;
TeXML doesn't appear to do anything beyond making that particular
conversion easier.

I've recently spent some time on a DTD-to-LaTeX transformation, and
I'm keenly aware that this is partly wasted effort, because there's logic
in that transformation -- more-or-less elaborate queries of the source
document -- which would have to be duplicated in a LaTeX3 (sometime) or
LaTeX-for-screen-PDF version of the output.  That logic is best expressed
in a DTD-to-DTD transformation, with, say, XML output ready to be turned
into LaTeX or whatever by a simple stylesheet such as Sebastian describes.

When I, at least, talk about high-level formatting output, I mean
output conforming to some presentation-based DTD (HTML may not be too
far from this! (ooooh, bleachhhh, forget I said that -- can of worms)).

It's that potentially hard/interesting transformation -- rather than
the rather easy issue of how you spit out LaTeX -- which needs a
powerful language, which to me looks like a better case for DSSSL than XSLT.

> If you want the FO approach, stick with DSSSL. If you want translation to 
> a high-level language like LaTeX, and delay the formatting to LaTeX
> style sheets, then XSL-which-is-the-child-of-DSSSL (ie its nothing to
> be ashamed of) seems a fair way to proceed. Mind you, Jade is probably
> _faster_ today than XSL implementations.

The weaknesses of XSLT (gained from a half-hour acquaintance with the
spec this morning, so apologies if I've missed some fundamentals), seem to be:

 - I wasn't able to find any obvious way of creating external
   entities: all the hits for the word `external' seemed to be specific
   to reading rather than writing them.  If you're going to use external
   tools (such as BibTeX or graphics conversion tools) as part of your
   processing system, or if you want to create a result document plus
   an abstract simultaneously, then you need this, I think.  I realise
   that there may not be an obvious home for such a thing in a model
   which transforms a source tree to a result tree, but since (a) this
   is something one really does want to do, and (b) this desire appears
   to me to be legitimate in SGML terms, the omission seems unattractive.

 - It doesn't seem particularly extensible.  It does have the
   get-out-of-jail-free card of external functions and system functions,
   but resort to that sort of mechanism in a language is only for the
   desparate[1].  Say XSLT didn't have a sort function: It's not obvious to
   me how I would supply that from within the XSLT, though implementing,
   say, quicksort in DSSSL would be merely an afternoon's work.  XSLT
   does have a sort function, of course, but the principle remains.

 - XSLT just doesn't look very nice.  Even the short fragments
   displayed in the spec are difficult to parse (for me -- machines
   are supposed to be good at that stuff).  Something like
     <xsl:if test="function-available('jjc:currentDate')">
       <xsl:value-of select="jjc:currentDate()"/>
     </xsl:if>
   takes some work to see as a test.  This is important: if it's
   unpleasant to read, then it's difficult to understand, and murder
   to maintain.  Certainly DSSSL's brackets take a little getting used
   to, but you _can_ get used to them; the visual clutter of XSLT code
   wouldn't go away.

 - XSLT doesn't grok SGML.  For me this is a killer because I want
   subdocs and minimisation, but it clearly isn't a problem in other
   applications.  However, there will remain SGML applications (!), so
   `use XSL(T) for high-level output' isn't a general answer to the
   problem.

XSL(T) seems fine at putting an XML document on paper, or turning it
into a web page.  But straightforward rendering is not the only thing
you do with *ML, as folk will not need reminding.

Recently, Sebastian said something to the effect that if you don't use
the FO strengths of DSSSL, and merely use it as a transformation language,
then the language simply becomes another competitor in a cluttered field.
I can't see this.  DSSSL is a standard, is well integrated with the grove,
and isn't Perl: all these are advantages (I'm only a Perl enthusiast on
even days of the week).  Failing to use a specific one of the advantages
(the FO approach) doesn't make these remaining advantages suddenly
evaporate.

Ohh dear, I'm blathering again.  But if you've got down here then at
least I'm being provocative.

All the best,

Norman


[1] I realise that it's through precisely this sort of extension that
Jade's implementation of the style language can generate SGML, but
in that case you have a well-designed (and pseudo-standard, now)
extension bringing in a whole class of possibilities, rather than
inviting stylesheet authors to use the facility routinely.

---------------------------------------------------------------------------
Norman Gray                        http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK     norman@xxxxxxxxxxxxxxx



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