OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] XSLT and nuts-and-bolts (follow-up)

[ 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





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS