[
Lists Home |
Date Index |
Thread Index
]
At 2002-01-16 10:37 -0500, Tom Moertel wrote:
>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,
Since XSLT 1.0 excels at structure manipulation, producing a result
structure from a number of source structures, I agree with the others who
said you've used the wrong tool to produce LaTeX. XSLT processors are not
even required to produce anything other than XML.
>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.
I agree.
>However, the
>points I made hold just as strongly for XML-to-XML and XML-to-HTML
>transformations.
They do not for node tree manipulation ... taking your text in one
structure and building a new structure from the existing text.
>This limitation wouldn't be so bad if it weren't so difficult to write
>nuts-and-bolts code in XSLT.
Here I'm concerned with your use of the word "code".
>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.
But not out of reach given the *need* (I perceive) for the use of XML
syntax for the stylesheet itself.
>Did people think that DSSSL required too much programming?)
When I taught DSSSL, programmers "got it" and web page designers didn't.
>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 --
<quote>
The designers of XSLT made a single decision that accounts for much of the
language's strengths and weaknesses. They decided that XSLT transformations
(i.e., "programs" in the XSLT language) should themselves be well-formed
XML documents.
From this decision the language gains the ability to play alongside other
XML documents, to be manipulated with common XML tools, and to benefit from
advances in related XML standards. In short, it easily integrates into the
XML-programmer's world and gains all benefits thereof.
However, this integration comes at a cost: Verbosity. Terrible verbosity.
The signal-to-noise ratio of XSLT transformations is shameful, easily among
the worst of all computer languages in widespread use. Non-trivial XSLT
transformations almost appear obfuscated.
</quote>
It is unfortunate that you continue to regard (and proclaim) XSLT as a
"programming" language. This misleading characterization is prevalent and,
I feel, is the source of much of the confusion in the community over the
technology. I teach that XSLT is a "templating" language, and that has
helped many many students get over their initial reaction to the necessity
of using XML syntax and what you term "terrible verbosity".
Don't regard writing a stylesheet as writing a program, regard it as
supplying to the processor a collection of templates, or "examples of the
result tree", that the processor is going to use to build the result of the
transformation.
Yes, it happens to be Turing Complete, so if you need to do programming
things along the way (which, I claim, is *not* the norm in XSLT
stylesheets), they are available to be used at the cost of shoehorning the
activity into markup constructs. I agree it isn't a pretty programming
language ... because it's primary purpose *isn't* programming, so that's okay!
But, given the vast majority of XSLT stylesheets need only supply "examples
of the result tree" to the transformation engine, and the result tree is
(by definition) a hierarchical tree of nodes, what better way to represent
a tree of things than using XML syntax?
Why would we invent some new representation of a tree of nodes of the
result tree? Using XML is a perfectly acceptable way to represent the node
structure we want out of the node structure of a source tree we have, given
our task of supplying examples of node structures to the processor to work
with.
This templating perspective on the language has been well received by my
students and readers, converting programmers who attend into, effectively,
"templaters" who have a few tricks up their sleeves when necessary due to
their programming background.
Look at the name ... "Extensible Stylesheet Language Transformations" ... I
don't read that as trying to bill itself as a programming language, but an
expression of the result of transforming XML.
If people continue to bill it or use it as a general purpose programming
language, then they are making it something it is not before deriding it
for doing a bad job of what it isn't ... all to the detriment of the
community who blindly trusts these specious arguments.
>Thanks for your time and any wisdom you may share.
I hope you find this helpful.
........................ Ken
--
Training Blitz: 3-days XSLT/XPath, 2-days XSLFO - Feb 18-22, 2002
- (Early-bird date for discounts is this Friday!)
G. Ken Holman mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (Fax:-0995)
ISBN 0-13-065196-6 Definitive XSLT & XPath
ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath
ISBN 1-894049-07-1 Practical Formatting Using XSLFO
XSL/XML/DSSSL/SGML/OmniMark services, books(electronic, printed),
articles, training(instructor-live,Internet-live,web/CD,licensed)
Next public training: 2002-01-18,02-11,12,13,15,18,21,
- 03-11,14,15,18,19,04-08,09,10,12,06-04,07
|
