RE: [xsl] versioning

Subject: RE: [xsl] versioning
From: David Tolpin <dvd@xxxxxxxxxxxxxx>
Date: Tue, 17 Feb 2004 19:38:16 +0400 (AMT)
> 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.

Understood. Still the idea that the same stylesheet executed with XSLT 1.0
and XSLT 2.0 would give different results concerns me.

Does XSLT 2.0 supercedes XSLT 1.0, or does it specify a different language?
That is, after deployment of XSLT 2.0, would XSLT 1.0 compliant 
implementations be deprecated? As with SAX 1.0? Or is it a different 
language, such as C and C++?

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

It should somehow be stated very clearly and in very bold font that an 
XSLT stylesheet accepted by XSLT 2.0 processor and having version="1.0"
on its document element is not necessarily a valid XSLT 1.0 stylesheet.
And even if it is, it can produce different results when run by XSLT 1.0

I would prefer a variant of 'import' instruction with
imported-stylesheet-version="1.0" as an attribute,  so that I can
explicitely say that I know that what I am importing is an XSLT 1.0 
stylesheet which I am going to use within the framework of XSLT 2.0
data model.

I would prefer version="1.0" to mean what it does, that is, that it is
a program in XSLT 1.0. 

I am not sure whether my notes are relevant or I am missing a point

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


please view my comments as friendly ones, not as rant or troll.

I see the quote above as a flaw in XSLT 2.0; XSLT transformations
have been used to convert XML and XSL data conforming to different
drafts of XSL (FO); there are stylesheets to convert RELAX to Relax NG
(which are different languages), there are stylesheets to convert
between XML and compact syntaxes of Relax NG.

XSLT 1.0 has been powerful enough to perform tricky transformations
for the tasks listed above; XSLT 2.0 has string-oriented constructs
as well (although not structured -- what I mean is that operators
in regular expressions are not a part of the language, but are 
inside literals, I still think it is a wrong approach) and should 
cover things which were difficult in XSLT 1.0. Yet it turns out that
XSLT 2.0 is not upto the task of converting from XSLT 1.0 to XSLT 2.0.

David Tolpin

 XSL-List info and archive:

Current Thread