RE: Application Design

[Sean McGrath <sean.mcgrath@propylon.com>]

>[Don Park]
>I agree with everyone that XSLT is the right tool for manipulating XML

There are many applications for which, XSLT is *not* the right tool
for manipulating XML.

The XSL spec. itself points out that XSLT is not intended to be a
general purpose XML to XML transformation tool:-

"XSLT is not intended as a completely general-purpose XML transformation 
language. Rather
it is designed primarily for the kinds of transformations that are needed 
when XSLT is
used as part of XSL." http://www.w3.org/TR/xslt

James Clark himself has been known to post to this list about the application
areas where XSL is probably not the right way to go:

"XSLT is better at down translations that up translations; if your 
transformation
is going from a less-structured form to a more-structured form, XSLT may not be
a good 
choice"  http://www.biglist.com/lists/xsl-list/archives/199908/msg00210.html

Also
"XSLT is better at transformations on structure than transformations on 
content;
if your transformation is doing complex transformations on the text content of
the document, XSLT may not be a good choice"

Unless the work I do with XML (both internally and consulting with some
thumpingly big international corporations) is very unrepresentative,
the limits of XSLT hit hard and very fast in the development cycle.

Most non-textbook XML transformations I am involved with require
either a) PCDATA based manipulations and b) external
integration e.g. dbms, web services etc. Insofar as they are possible
with XSLT they are complex and read-only at best.  In many cases
they are just not possible at all.

I repeat my assertion made in an earlier post that the irrational
exhuberance about XSLT will be the cause of wholesale server-side
re-writes of XML transformation systems in the medium term.

In the short term, users will try to overcome XSLTs limitations with fancy
debuggers and fancy developers tools. The vendors are already rubbing their
hands with glee at the prospect!

Remember what happened to C++ - it
got so complex that the majority of programmers (on Windows anyway)
ended up with visual tools. These tools in no way allowed you to
visualize what C++ was. They purely acted as buffer zones between
the programmer and the complexity of the language. Over time,
the vendors developed a stranglehold and effectively forced
organizations using C++ to purchase visual tools and then
specifically to look for visual programmers.

The underlying C++ may have been standardized
but the surrounding tools were proprietary and involved $$$.
To the detriment of the idea that C++ was an open "standard".

XSLT is heading in the same direction it seems to me.
To the detriment of the idea that XSL is an open "standard".

Summary:

XSLT has its uses but it is surprisingly useless in some
common server-side scenarios.

XSLT gets complicated quickly. The side-effect free nature
of its processing model causes much pain for developers.
The theoretical reason for this - parallelization of execution
of the stylesheet - seems to me to be unjustified. It puts too
much complexity on the programmers plate for what is after
all an optimisation feature.

Arguments against the "just use XSLT" mantra, including this
one, will be pooh poohed by vendors who know full
well what the limitations are but see lots of $$$ in
debuggers, visual tools, consulting etc. etc.


regards,
Sean