Joachim Schrod <[log in to unmask]> writes:
>>>>>> "WH" == William F Hammond <William> writes:
> WH> Joachim Schrod <[log in to unmask]> writes:
>>> But not necessarily the most interesting. There is also the
>>> possibility of experimenting with new innovative approaches to style
>>> sheets, given by modular XML processors like PXP and modular
>>> typesetting engines like ant.
> WH> James Clark once wrote somewhere that style sheet processing is a
> WH> limited form of sgml processing, and I've never had reason to doubt it
> WH> for author-side processing. Don't underestimate the power of less
> WH> restrained frameworks like David Megginson's perl module SGMLS.pm (and
> WH> its friendly interface sgmlspl.pl) for formatting XML to LaTeX.
> As much as I respect James, I can only agree with him here on a very
> very abstract level. With "style sheets" above I didn't mean
> transforming XML to other markup languages, I meant *directly*
> typesetting XML documents, with a *very* high quality, and including
> all necessary intermediate steps (insertions -- figures, tables,
> footnotes, endnotes, marginal note; table of contents/figures/etc.,
> cross references, complex counting schemes, bibliography, index
> processing, etc: just look at all LaTeX packages or Context modules).
> We don't have this today.
But for most of these tasks there are already fairly good
specialised programs. You only have to bring them together. None
of them is really excellent though: BibTeX needs a replacement that
uses XML at least for the .bib files and the output. Several
projects are working on it. I'm still not sure about xindy, however
it seems to be one of the stronger chain links.
Surprisingly enough, TeX is the most serious limitation at the
moment (of course also because it's so vital). It's still the best
back-end for typesetting something, however its treatment of
so-called special characters, lack of true unicode support, and the
distinction text/math mode is really unfortunate.
> FOP, the XML style sheet communities answer to the task, is not up to
> that demand; its capabilities are not enough.
Absolutely true. However, the biggest part of the problem is the
absence of free good complete FO processors.
> [...] XSLT is a write-only language when it comes to implementing
> the "intermediate steps" above, that's no improvement to TeX macro
> programming. It has poor semantics (like TeX, it's even missing
> elementary boolean clauses),
XPath has boolean expressions, and XSLT knows "choose" and "if".
> and its syntax is horrible to read and thus maintenance is
Well, it's a matter of getting used to. But you're right, finding
fellow developers is very difficult.
> Hopefully, development on the style sheet front has not stopped
> here and will continue after the XML hype is gone.
XSLT 2.0 has many improvements, e.g. real user-defined functions
that can return a value and that can be used in XPath expressions.
But there are other new things, too, that would have made my own
XSLT efforts much simpler. I still consider this template matching
a wonderful thing. So I agree that much has to be done, but I hope
current XSLT will be the starting point.
Torsten Bronger, aquisgrana, europa vetus