xsl-list
[Top] [All Lists]

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

2005-03-08 14:00:07
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/



-----Original Message-----
From: Daniel O'Donnell [mailto:daniel(_dot_)odonnell(_at_)uleth(_dot_)ca] 
Sent: 08 March 2005 18:26
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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(_dot_)odonnell(_at_)uleth(_dot_)ca>
Home Page <http://people.uleth.ca/~daniel.odonnell/>
The Digital Medievalist Project: <http://www.digitalmedievalist.org/>


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--





--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--