Re: [xslt] XSLT 2.0

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]