Re: [xslt] XSLT 2.0

[Tony Graham <Tony Graham MenteithConsulting com>]

On Sat, Jun 21 2008 01:50:48 +0100, Steve Ball explain com au wrote:
...
> 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.

I think you are making a rod for your own back if you want to maintain a
codebase that is full of '#ifdef XSLT2' or similar.  Didn't you earlier
bring up the idea of a branch?

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

So how do you get users to show any interest in it?  How do you attract
new developers if there doesn't seem to be anything going on?  How do
you keep developers if the whole open source ego-stroking meritocracy
thing isn't happening because the wider world can't see the merit being
created?

The FOP XSL formatter project went through a redesign phase between
0.2.x and 0.9.x where it didn't make a new release for years, and I'm
sure that it lost users and developers during that time because it
wasn't seen to be making progress.  It certainly seems to me that there
were fewer voices on the fop-dev mailing list, and not so many old
hands, by the end of the process.

The big-bang approach may work if, as you posit below, there's one or
more programmers working on it full-time, but if there aren't the
resources, I doubt that it's the right approach.

If the work, once started, is going to take more than "a few months",
then I'm inclined to think that the project should make interim
releases, that people can try at their own risk, so people can see the
direction of the project and the project can get feedback about what
it's doing.

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

Certainly the pre-work should demonstrate that the design has good
bones, but I don't know that the spec should flesh out the whole task.
For example, a likely scenario is that a few of the standard functions
would be developed and, once shown the expression parsing worked, the
rest (or their stubs) would be churned out with reference to the spec.

Compliance would be checked against the XSLT 2.0 test suite: over 16 MB
of tests and data, though it doesn't seem to be publicly available.  I
would suggest that getting the test suite runnable would be one of the
first tasks of the project.

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

As this would be built on libxslt, are you considering that the libxslt
code would first be extended to parse XSLT 2.0 stylesheets or, rather
like how C++ first got off the ground, the XSLT 2.0 stylesheet would be
preprocessed into a XSLT 1.0 stylesheet with extension functions and
special attributes, with the goal of reducing and then removing the
preprocessing stage as the project progresses?

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

He also built on the experience of Saxon 0.x through to Saxon 6.x.

The long development of XSLT 2.0 and the fact that it's literally last
year's standard means that this project isn't going to benefit from much
hype effect.  It does also mean that those people who do work on it are
less likely to be distracted by the Next Big Thing.

Regards,


Tony Graham                         Tony Graham MenteithConsulting com
Director                                  W3C XSL FO SG Invited Expert
Menteith Consulting Ltd
XML, XSL and XSLT consulting, programming and training
Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
Registered in Ireland - No. 428599   http://www.menteithconsulting.com
  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
xmlroff XSL Formatter                               http://xmlroff.org
xslide Emacs mode                  http://www.menteith.com/wiki/xslide
Unicode: A Primer                               urn:isbn:0-7645-4625-2