Re: [xsl] XSL-T should naturally loop? not grabbing all the children node-sets..
Subject: Re: [xsl] XSL-T should naturally loop? not grabbing all the children node-sets..|
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Wed, 23 Apr 2008 11:57:34 -0400
At 04:54 AM 4/23/2008, you wrote:
On 22/04/2008, Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> wrote:
> XSLT 1.0 is lightweight, fast, widely deployed,
> and covers its application domain very well. In particular, there was
> nothing in the OP's post that suggested he'd get any particular
> 2.0. Is there a reason we should be steering people away from it?
Well the RTF issue is just annoying, and the first item semantics are
a problem... Then there's the "produce output at all costs" mentality
which results in silently incorrect output when you make a mistake
instead of an error message.
Then there's the lack of the XHTML output method - anyone wanting to
avoid minimized elements has to code carefully with XML output method.
Then there's the functions available in 2.0 that make everyday taks
straightforward, which in 1.0 would require some established technique
- the transform and sum problem is the classic. Another is splitting
a string. Another is replacing more that one character at a time.
All basic problems that repeatedly come up but take 10 minutes to
write in 1.0.
These are all good answers, as of course I've run into all of them.
A counter-argument: theseare mainly problems on the edge of what
beginners should be thinking about, even if they have 2.0. (But oops:
that's an argument in favor of using 2.0 not 1.0.)
Another counter-argument: if you're using XSLT 1.0 and you're not
running into any of these things, what's the harm? Should XSL-List
complicate your life for a hypothetical? (Okay, we do that all the time. :-)
If I were to teach 1.0 now, I would find myself saying "but in 2.0 you
can just do this..." all the time...
Yes, that certainly happens. Not that it wasn't worse at one time,
when we'd have to say "use an extension" or "use another tool" or
demonstrate some elaborate and mind-numbing workaround.
On the other hand, 2.0 is just so much more, um, "massive". But on
reflection, I think this is actually more of an issue on the XPath
side than on the XSLT side. Maybe I should be thinking about teaching
XSLT 2.0 with the "XPath 1.0" subset of XPath 2.0.
Another mitigating factor is that so many people have no choice but
to use 1.0 at least for the time being. We can agitate for more
implementations, which will help, but for now it seems this is where we are.
Interestingly, one hole seems to be in the Linux/Unix/MacOS world
where some developers seem to be allergic to Java (for reasons I
understand but don't quite buy) and/or XSD datatypes (a feeling I
have more sympathy for, but hey, the pain wears off). They are very
happy with XSLTProc, which of course is an excellent tool -- but not
ready to move forward, to all appearances.
Then there's the question of support in the browsers.
These days I'm asking up front whether a client or customer can use
2.0, which eases the problem when the answer is yes. But this leaves
open the question of what to pitch in venues that are open to all comers.
I think this problem will be with us for some time yet. And while
you're convincing me that the time may have come to prefer 2.0 for
introductory treatments (all else being equal), I'm skeptical about
telling just any XSLTer that they "should" be using it. There are too
many extraneous factors in play.
1.0 is/was great, but 2.0 is such a massive leap forward which once
you've made that jump, you never really want to go back.
This is undoubtedly true when you have the choice to use XSLT 2.0 for
any and every XSLT application you design. But that isn't the case
for everyone. It's not that we "want to go back", it's that a
significant amount of work still gets done over there.
In my own case (leaving clients aside), I'm probably nearly at 100%
in 2.0 for work in batch mode and at 80% on the server, but I still
have plenty of XML being processed in browsers. (It rocks for
micro-publishing inside organizations.) If I need 2.0 features for
that, I consider preprocessing the data, which isn't ideal but it
works. And this is pretty much what XSLT 1.0 was designed for in any
case (without the expectation that the preprocessor would also be a
flavor of XSLT :-).
Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
Mulberry Technologies: A Consultancy Specializing in SGML and XML