March 08, 2005

To XSLT 2.0 or To Not XSLT 2.0

An interesting thread has formed on XSL-List based on a post from Daniel O'Donnell in which he poses the following question:

... is there a reason for not using xslt 2.0 for most processing tasks?

The question is expanded and is then answered by several notable experts including Dr. Michael Kay, Elliotte Rusty Harold, and David Carlisle... The thread, thus far, is as follows:

Daniel O'Donnell to XSL-List on March 9th, 2005:

Hi,
I have a question that calls for informed opinion: is there a reason
for not using xslt 2.0 for most processing tasks? I'm thinking
especially privatish, and pre-processed things rather than on-the-fly
commercial applications.
The standard is now pretty stable, correct? and the processors seems to
be working well. Saxon 8b-3 is very good, and since Saxon 6.5.3 has a
bug that seems to stop it writing properly in Service pack two XP
machines, it may be a good time to switch anyway.
No doubt a trivial question, but I'd be interested in hearing what
people think. I'm engaged in a couple of new project involving xslt
where the question of 1.0 or 2.0 is real.
-dan
--
Daniel Paul O'Donnell, PhD
Associate Professor of English
University of Lethbridge

---

Jay Bryant
---
I've been using XSLT 2.0 and the various versions of Saxon 8 since July of
2004. I've had very little trouble with either. Dr. Kay fixed the one bug
I found in Saxon 8 within a day (and I had already thought of a
work-around).

I can see two issues. First, you'll tie yourself to a single vendor.
That's not much of an issue, since you would probably pick a single vendor
anyway and since Saxonica is a fine vendor. Second, the 2.0 specification
may change before it is finalized. However, that risk seems to be low, as
the working group is winding down (so I gather anyway).

I have been solving problems for my clients without undue difficulty (and
often much more easily than I could with XSLT 1) for 8 months now. Based
on my experience, I recommend that you go with Saxon 8 and XSLT 2.0.

Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)

---

Elliotte Rusty Harold
---

JBryant@s-s-t.com wrote:

> I can see two issues. First, you'll tie yourself to a single vendor.
> That's not much of an issue, since you would probably pick a single vendor
> anyway and since Saxonica is a fine vendor. Second, the 2.0 specification
> may change before it is finalized. However, that risk seems to be low, as
> the working group is winding down (so I gather anyway).

I certainly wouldn't count on that. It is far from unheard of for a
working group to think it's winding down when someone comes out of left
field and identifies an unrecognized problem that causes a major rethink
and redesign. It doesn't happen to every or even most specs, but it does
happen often enough to be a problem. So far I've seen this happen to
XPointer, XInclude, SOAP, and xml:id. (There might be others I'm just
not thinking of right now.)

There are numerous other specs where this should have happened but
nobody noticed the problems until after final publication. XSLT 2 isn't
done until the final spec is released, and maybe not then.

---

Dr.Michael Kay
---

This is essentially a risk assessment question: it depends on whether the
value you gain from using 2.0 is greater than the sum of the risks, where
risk is measured by the probability of failure multiplied by the cost of
failure.

You've had several responses with different views on the probability of
failure, but to make a decision you need to assess the other two variables,
and it's unlikely that anyone but you can do that.

I think we're starting to see one risk disappear, namely the risk of being
locked into a single supplier. There are now three XSLT 2.0 processors
released, and I'm sure we'll see others in the next few months. (I have no
idea, of course, what quality they will be.)

I think the risk of seriously disruptive changes to the spec is now
reasonably low. There will be minor changes, but I'm pretty confident they
will be easy enough to absorb for a typical project. The working groups are
now spending nearly all of their time discussing edge cases - examples from
the last meeting include how to handle leap seconds, whether or not it's
legal to write "10 div 3" without the first space, whether or not the
numeric literal 1.0e10000 is an error, whether tokenize() applied to an
empty string returns an empty string or an empty sequence, whether
resolve-uri() should reference RFC 2396 or RFC 3896, how lax validation
handles an xsi:type attribute, whether (1 div 0) is a static error or a
dynamic error. Frankly, none of these are things that will affect the
outcome of more than 1% of stylesheets. But of course, committees are not
always predictable: there can be a tendency for new people at a higher level
of management to get involved at the last minute and this can sometimes rock
the boat.

There is of course a contingency plan for a project if the spec does change:
you can carry on using the software that exists today.

I'm personally seeing a lot of projects where the gain from using XSLT 2.0
far exceeds the potential pain. But I wouldn't advise every project to use
it: on a billion-dollar project, it's always worth erring on the side of
caution.

Michael Kay
http://www.saxonica.com/

---

David Carlisle
---

> The standard is now pretty stable, correct?

That can't be guaranteed, XSLT 1.1 was just abandoned for example.
I imagine that after this length of time the WG aren't keen to do any
major redesign, but to assume stability at this stage is to assume that
the public common process won't be taken seriously.

That said, I'm using xslt2 more and more, but I'd written quite a lot of
XSLT1 before that was finalised as well.

David

---

M. David Peterson
---

> (There might be others I'm just
not thinking of right now.)

In fact one of the primary reasons Microsoft has held back from
providing direct support for the XSLT 2.0 spec is based on the last
second 'split' of the 1.0 spec into the XSL (FO) and XSLT
specifications causing an incompatible processor to be propogated and
a support nightmare to be invoked. I would tend to think that the W3C
has made the necessary changes to ensure that this kind of thing
doesn't take place again but I would also consider the fact that, as
Mr. Harold recognizes, last second changes happen often enough that
the possibility must be considered when making any long term plans for
a technology.

With that said, it seems the latest release of the XPath 2.0, XSLT
2.0, and XQuery drafts have gone a long way into fixing a lot of the
areas that may have been considered questionable or potential problem
areas but caution still must be employed none-the-less.

Best regards,

]]>

David Carlisle
---

> In fact one of the primary reasons Microsoft has held back from
> providing direct support for the XSLT 2.0 spec is based on the last
> second 'split' of the 1.0 spec into the XSL (FO) and XSLT
> specifications causing an incompatible processor to be propagated and
> a support nightmare to be invoked.

I think that's a very skewed view of history:-)

The split between FO and XSLT into two specs wasn't that late in the
process : including the REC there were 7 drafts of XSL(T) only the first
two of which were combined with FO.

and was essentially irrelevant to the microsoft implementation
as it never implemented the FO part of the draft even when they were
combined, splitting it just made it easier for the transformation-only
implementations to claim conformance to a named spec rather than just to
chapter 2 of a combined spec.

msxml2 implemented a language that had a passing resemblance to the
transformation language in the XSL draft of December '98. Even if it had
been a faithful implementation of that draft, releasing an implementation
of a draft spec in a full non-beta release of a piece of software
distributed to 90% of the world's desktops was a mistake, although at
the time I think many of us thought it was probably a good thing,
spreading the word... It's easier to take a different view with hindsight.

> I would tend to think that the W3C has made the necessary changes to
> ensure that this kind of thing doesn't take place again

I don't think the W3C process can have any effect on such
things. Companies (or people) will take commercial decisions on whether
to release (or use) software based on a draft spec. If they do release
such software again they will take commercial decisions about whether
to change the software as later drafts come out.

David

---

M. David Peterson
---

Thanks for this added info... Of course its easy to develop an opinion
in one direction or another based on the information you are aware of
so it certainly helps to understand things further from someone who
has watched this process from the beginning.

Cheers :)
]]>
---

If you have any additional comments or questions please, if you do not belong already, join XSL-List, and then add your comments or questions to the thread entitled

[xsl] Is there a reason for not using XSLT 2.0 as a default