[
Lists Home |
Date Index |
Thread Index
]
> >I don't know if this will be productive/practical on a
> mailing list but are
> >you able to summarise what your contacts were unable to
> achieve for their
> >customers using XSLT? If XSLT isn't working in the real
> world (or part of it)
> >as you suggest isn't it time to be feeding such real world
> feedback into the XSLT 2.0 process?
I don't think you have to lurk on xsl-list for very long to discover the
things that people have difficulty with in XSLT 1.0. (I've now idea how
representative the people who go to xsl-list for help are, but my experience
doing workshops and tutorials, and answering questions from our customers
and support people, suggests it's a reasonable cross-section). Here's a
quick "top ten":
- grouping and elimination of duplicates
- "programming without variables" - learning how to use recursion
- text manipulation
- handling XML features absent from the data model (entities, CDATA,
DOCTYPE)
- inability to construct XPath expressions dynamically
- interaction between XSLT and Javascript
- namespaces
- character encoding
- whitespace
- understanding context node and context position
Some of these are pure learning issues. Arguably a different language design
could have made these things easier (for example, a different approach to
"context"); but it's too late to fix that now, and it just becomes one of
the things that newcomers to any language have to learn. I think every
language has a few hurdles of this sort.
(One interesting example of a learning hurdle is that many beginners seem to
assume that variables in XPath expressions are macros; I suspect this is
because the "$" sign reminds them of operating system command languages.
Again, I don't think we as language designers can solve that problem now, we
have to rely on the educators.)
Some of the problems are missing features which I think we can fix, and
which I hope that XSLT 2.0 will fix. Grouping is an obvious example; we also
hope to make progress on text manipulation (using regular expressions),
though finding the right design is proving difficult.
Some of them are problems in the wider XML space, e.g. namespaces and
character encoding, and it's hard to see how we can do very much more in
XSLT or XPath to reduce the damage.
I have some personal doubts about whether it was wise to go for a
declarative language rather than a procedural one. As a computer scientist,
I like it, but I don't always find it easy to convince people that the gain
is worth the pain. I think this is probably the biggest reason that some
people find XSLT too difficult, or resort to "language abuse" by means of
Javascript hacks and things like disable-output-escaping.
But overall I'm convinced XSLT is a success. There is a learning curve, and
there are some things that are difficult even for experienced users, but
there's a large body of users who have overcome the difficulties and are
using the language very successfully.
Michael Kay
Software AG
home: Michael.H.Kay@ntlworld.com
work: Michael.Kay@softwareag.com
|
