Re: [xslt] XSLT 2.0

[Steve Ball <Steve Ball explain com au>]

Mark Howe wrote:
[snip]
> 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.

That's possibly true, but depends on how the changes are designed.

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

From this point-of-view I'd prefer the "big bang" approach. The  
production version of libxslt should remain a XSLT 1.0 compliant  
processor until such time as the new work is complete, at which time  
it suddenly becomes a fully XSLT 2.0 compliant processor.

However, getting to that point may take some time. In the interim, I  
would envisage the new features being enabled only by the  
"version='2.0'" attribute being present in the stylesheet and/or the  
2.0 features being compiled in to the processor with a compile-time  
switch. Hence the default behaviour would be unchanged.

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

There will not be a 1.2, 1.4, etc. There is 1.0 now and 2.0 in the  
future. See above.

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

Again, see above. If I were you, I'd stick with 1.0 until such time as  
the 2.0 libxslt was available as a fully compliant implementation.

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

There is already a spec - the W3C Recommendation. What we don't have  
at the moment is a design.

Off-the-top-of-my-head, my guestimate is that this would take a full- 
time programmer a few months. Working on it myself in my spare time  
will probably take about two years. The purpose of the messages I've  
been sending out over the last couple of weeks is to allow the work to  
be split-up and undertaken by two or more people, so that it may be  
completed in something like one year.

Note that my schedule for the development would be quite different if  
working on it full-time vs part-time. If this was a full-time job then  
I'd tackle the hard, pervasive changes first - XPath syntax, data type  
support, etc - and then do the new elements and functions later in the  
piece. However, since I'm facing a part-time, multi-person approach  
then doing the easy tasks first gets some quick runs on the board,  
thus helping to boost morale and get useful functionality out-the-door.

Someone pointed out a while ago that Mike Kay wrote the XSLT 2.0  
support for Saxon. Unless he has hundreds of minions hidden away in a  
basement somewhere, then that was a one person effort. His advantage  
is that he wrote the code in parallel with working on the development  
of the spec itself. We have a cold start here - the spec is already  
done (and has been out now for a year).

Cheers,
Steve Ball