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 benefit from
> 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.      
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

Current Thread