RE: [xsl] versioning

Subject: RE: [xsl] versioning
From: "Michael Kay" <mhk@xxxxxxxxx>
Date: Tue, 17 Feb 2004 13:43:44 -0000
As you can imagine, there's been a lot of debate about how to use the
version attribute in the working group, and there's no one solution that
meets all requirements.

One of the aims behind the design that we adopted is that you should be
able to mix 1.0 and 2.0 code. We felt that this was necessary to make
transition as painless as possible. You should be able to include a 1.0
stylesheet module from within a 2.0 module, for example. XSLT 1.0
already allowed parts of the stylesheet to be labeled as "version='2.0'"
so we had to support that. The data models for 1.0 and 2.0 are
different, so an XSLT 1.0 processor won't understand data that's passed
to it by a 2.0 processor, or vice versa. Therefore, a 2.0 processor must
execute 1.0 code according to rules defined in the 2.0 spec, not
according the the 1.0 spec.

So we defined that version='1.0' would invoke processing according to
rules defined in the 2.0 specification, but with backwards compatibility
mode enabled to make the results as consistent as possible with the
results produced by a 1.0 processor, subject to the differences that are
necessary because the data model is different. We also tried to take
into account that the purpose of BCM is to provide a bridge between 1.0
and 2.0, and that both transitions (from 1.0 to 2.0+BCM, and from
2.0+BCM to 2.0) should be as painless as possible.

Some working group members did argue that specifying version="1.0"
should mean that the stylesheet is guaranteed to be processed according
to the XSLT 1.0 specification. This would essentially mean that a 2.0
processor is required either to reject such a stylesheet or to delegate
its processing to a 1.0 processor. This would allow no mixed-mode
working, and it would mean for example that sections of a 1.0 stylesheet
labeled as version='2.0' would be processed according to the 1.0 spec:
that is, they would error if they contained any 2.0 constructs.

My own experience of migrating real stylesheets has been that there have
been very few problems, and that they have generally related to use of
extensions rather than to facilities in the W3C specs. If anyone does
have any negative experiences of migration, I will be very interested to
hear them (ideally, send them direct to the public-qt-comments@xxxxxx

The idea of creating tools to help in the conversion is an interesting
one, but such tools would be quite tricky to write. They couldn't be
written in XSLT, because they would need to do detailed parsing of the
XPath expressions. For example, one would want to take the XPath
expression "X < Y", do type inference on it, and if there is any
possibility that both X and Y are non-numeric, replace it by the
construct "some $x in X, $y in Y satisfies number($x) < number($y)".
Saxon's approach instead is to give you a warning message if it
encounters such a construct, and allow you to make the change by hand.
(As an indication of how rare these situations are, I found I had to
write new tests to invoke these warnings: they weren't coming up from my
existing XSLT 1.0 test suite).

Michael Kay

> -----Original Message-----
> From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx 
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of 
> David Tolpin
> Sent: 17 February 2004 09:23
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: [xsl] Normalize / Simplify HTML-Tables with 
> row-span / col-span
> > An XSLT 2.0 processor is *not* required to detect every time you do 
> > something that wouldn't have been allowed under 1.0 and 
> reject it if 
> > the stylesheet says version="1.0". That would be far too 
> burdensome, 
> > especially for facilities like this one where it would 
> require extra 
> > information to be maintained at run-time.
> On the other hand, the common software practice has been to 
> honour versioning. For example, XML parsers should use 
> different lexical parsers for XML 1.0 and XML 1.0+Namespaces. 
> Regex-based utilities on BSD flavours of Unix allow to choose 
> between basic and extended syntax; and if basic syntax is 
> chosen, any construct from the extended syntax is an error. A 
> C compiler that supports both K&R C (as described in Version 
> 6 Manual) and ANSI/ISO C is expected to report things which 
> are not traditional when invoked in traditional mode.
> Is 'version="1.0"' a documented hack to quickly use XSLT 1.0 
> stylesheets with an XSLT 2.0 processor without warranty? 
> Would not a transformation expressed in XSLT 2.0 that turns 
> XSLT 1.0 into XSLT 2.0, incorporated in or appended to the 
> specification, be more appropriate for this purpose? Ot is it 
> yet another bit I omitted from the draft?
> David Tolpin
>  XSL-List info and archive:

 XSL-List info and archive:

Current Thread