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

Subject: RE: [xsl] Is there a reason for not using XSLT 2.0 as a default
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Tue, 8 Mar 2005 21:00:07 -0000
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

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

Michael Kay

> -----Original Message-----
> From: Daniel O'Donnell [mailto:daniel.odonnell@xxxxxxxx] 
> Sent: 08 March 2005 18:26
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: [xsl] Is there a reason for not using XSLT 2.0 as a default
> 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
> Lethbridge AB T1K 3M4
> Tel. (403) 329-2377
> Fax. (403) 382-7191
> E-mail <daniel.odonnell@xxxxxxxx>
> Home Page <>
> The Digital Medievalist Project: <>

Current Thread