[
Lists Home |
Date Index |
Thread Index
]
[My apologies if you are seeing this for the second time. The first
email was apparently lost in transit, and so I am resending it now.]
A short while ago, I wrote a story in a weblog diary that managed to
work its way onto this list. Normally I wouldn't post this kind of
thing here, figuring that this topic has been already discussed to
death, but since the diary draft made it here (and seemed to spark
some, ah, interesting responses), I feel obligated to follow up and
point you to the final version.
For those who didn't read it, in the story I shared a programming
puzzle that I solved a year of so ago when using XSLT to transform XML
documents into LaTeX documents (and also HTML documents, but I didn't
mention this in the diary). I also shared my concerns about XSLT's
lack of support for nuts-and-bolts programming, often required to fill
minor gaps in XSLT's built-in transformation support. To illustrate
my point I used a small example problem, having to do with the
manipulation of the text within the elements of my documents. It's a
problem that, while common in many XML transformation jobs, was
surprisingly awkward to solve within XSLT. Since XSLT's support for
processing the text within elements was limited, it seemed natural
to fill the gaps with a little XSLT programming, which would let me
process the text in passing, in context, and in a highly portable way.
But no elegant solution was to be found.
Some people, having read the diary draft, have dismissed the ideas it
contains because they were explained in the context of an XML-to-LaTeX
transformation problem, certainly not XSLT's forte. However, the
points I made hold just as strongly for XML-to-XML and XML-to-HTML
transformations. In short, I suggest that XSLT provides half of a good
solution. It makes it easy to transform element structures but falls
short on the other half of the job -- transforming the stuff inside
the elements. [1]
This limitation wouldn't be so bad if it weren't so difficult to write
nuts-and-bolts code in XSLT. Again, XSLT seems to provide only half
of a good solution. While it mandates a functional style of
programming, many common functional-programming idioms have no
convenient XSLT representation, and those that do are often grotesque.
(One has only to browse the online repositories of XSLT code to see
what I mean.) This deficiency makes gap-filling measures difficult.
(It is interesting to compare DSSSL to XSLT in this regard. The two
seem like mirrored reflections of each another. Where DSSSL is rich
in nuts-and-bolts programming support, XSLT is weak. Where XSLT
shines with domain-specific convenience, DSSSL is lackluster. I'd be
interested to know how criticisms of DSSSL influenced the design of
XSLT 1.0. Did people think that DSSSL required too much programming?)
After I posted my diary story on kuro5hin.org, a number of regulars on
the site read it and suggested that I give it a good editing pass to
fix obvious deficiencies and then submit it to the general readership
of the site, which I did. You can find the article here, along with
the follow-on discussion:
http://www.kuro5hin.org/story/2002/1/15/1562/95011
While I am open to any comments and criticisms you may have about my
ideas, I would ask that you respond only to what is written in this
message or in the story linked above -- and not to what is written in
the diary entry, which is crude and incomplete.
Thanks for your time and any wisdom you may share.
Cheers,
Tom
[1] There are those who would argue that, if you have the need to
transform the text in your XML documents, the text hasn't been
sufficiently marked up. However, it is often impractical (or
impossible) to dictate that all documents be marked up perfectly.
Sometimes we have little choice but to take what we are given.
|
