[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Andrew,
At 04:54 AM 4/23/2008, you wrote:
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. :-)
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.
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 :-).
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 |
Andrew,
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 :-).
Cheers, Wendell
====================================================================== 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 ======================================================================
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSL-T should naturally lo, Colin Adams | Thread | [xsl] named template with parameter, Ilya Lifshits |
[xsl] xslt function for generating , David J Birnbaum | Date | [xsl] Rotating Graphics, Horace Burke |
Month |