Re: [xslt] XSLT 2.0

[Mark Howe <mark cyberporte com>]

xslt-request gnome org a écrit :
> OK. So we've established that noone has enough time to do this, but  
> we'd like it done anyway.
On my reading of the discussion, there's a big question as to what the 
'this' in the sentence refers to.

Why do people use LibXSLT rather than one of n other XSLT parsers and 
more than one XSLT 2.0 parser? When we were looking for an XSLT engine 
for our project, the main factors that took us towards LibXSLT were

* Fast

* Highly compliant with a recognised standard

* Written in a way that facilitates tweaking the internal behaviour as 
necessary (in our case extension functions and assorted cacheing)

At the time, we wondered about XSLT 2.0, and, believe me, I wonder about 
it again every time I get an 'invalid type' error or have to throw 
another exsl:node-set into my code. But the considerations above 
outweighed the elegance of XSLT 2.0, and I think that, for our 
application, that's still the case.

So how does the "eating an elephant one mouthful at a time" approach 
affect the above considerations?

Well, I'd expect the stuff that gets done first to be fast, because the 
easy stuff to add is usually easy because it doesn't mean major internal 
changes. But this will not be true - almost axiomatically - of the 
harder stuff, and, indeed, implementing the easy stuff the easiest way 
may just mean more code to rewrite later on.

Tweakability is probably safe.

The big problem as I see it is compliance. XSLT 1.0 only does 1.0 plus 
some EXSL, but because everyone knows what it does and doesn't do it's 
possible to work around the limitations. XSLT 1.0_plus_some_extras is 
going to need extremely good documentation if using it is not to be a 
huge learning experience for each and every user. Documenting the 
functionality that has been explicitly added is probably easy enough. 
The fun starts with how adding such functionality affects the parsing of 
existing XSLT 1.0 stylesheets that are compliant but quirky. Adding 
extra semantics to XPath may well change the behaviour of existing 1.0 
XPaths, but predicting where and how the changes work is going to be 
very hard indeed, especially if the added functionality keeps moving.

Our project is largely about building libraries in XSLT for third 
parties to use. That would be sweeter in 2.0 than in 1.0, and a 
nightmare in something arbitrarily between 1.0 and 2.0. We'd end up 
having to tell people that stylesheet X works with 1.0, and with 1.2, 
but not with 1.4, but probably eventually with 2.0. For an embedded 
parser that is using whichever installed version of LibXSLT it finds on 
the end user's system, that's really Room 101 for technical support.

Obviously open source is all about freedom to do whatever you want with 
the code, so I'm not saying you are wrong, and, if what you are 
suggesting works for you and others, that's great. Really. I'm just 
pointing out that what you are suggesting may not work for everyone who 
would like a finished LibXSLT 2.0. For applications where compliance is 
a major consideration, spec'ing the whole task first would probably be a 
better approach.

Several people have said that getting to 2.0 is 'a lot of work'. Can 
anyone put a ballpark figure on how much work? I know we're guessing in 
the absence of a spec, but I'd find it useful to know if we're talking 
programmer-weeks or programmer-years, and the answer has potential 
implications for funding options too.