Re: Generating high-level formatting output

[Norman Walsh <ndw@xxxxxxxxxx>]

/ Norman Gray <norman@xxxxxxxxxxxxxxx> was heard to say:
| 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)).

XSL formatting objects, perhaps? ;-)

| 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.

I'm coming around to the position that transformations are much easier
in XSLT than in DSSSL. There are some things that are much harder, but
having a path language that let's you query more-or-less arbitrarily
through the document is really, really handy.

|    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.

At first, I thought so too. But now I'm not so sure. The DSSSL
stylesheets for DocBook do the chunking internally. This means
for every cross reference I do this complex calculation to
figure out what chunk the target will be in so I can generate the
right href.

For the XSL stylesheets, I wrote a separate tool to do the
chunking.  This simplified the stylesheets and really gives me a
lot more flexibility in the chunking. Right now that app is in
Perl, but when I'm done prototyping, I'll code it up in Java,
let it call the XSL processor, and to the end user it will seem
like one seamless operation.

The result of an XSLT transformation doesn't have to be the
final result, it just has to be the right semantic model.

|    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.

I agree. The world won't accept Scheme though. Marketing
non-starter.

|  - 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.

Why does this keep coming up? XSLT is a tree to tree
transformation language.  Stick an SGML parser in front of it
and it'll do SGML just fine.

| 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,

Jade doesn't do the transformation part of DSSSL and the
transformation capability in Jade (using the -t sgml backend,
for example) is non-standard extension by James.

                                        Cheers,
                                          norm

-- 
Norman Walsh <ndw@xxxxxxxxxx>      | Give a man a fish and you feed him
http://nwalsh.com/                 | for a day; teach him to use the
                                   | Net and he won't bother you for
                                   | weeks.


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