Re: XSLT 2.0 Namespace

Hi Dare,

> My question is exactly how one is supposed to differentiate between
> the W3C XML Schema for XSLT 1.0 and XSLT 2.0 if they use the same
> namespace and W3C XML Schema doesn't provide a way to specify
> alternative content models based on an attribute's value?
 
As you've probably read, XSLT 2.0 has some pretty complex rules
governing forwards [1] and backwards [2] compatibility. (XSLT 1.0 only
needed to worry about forwards compatibility since there was nothing
to be backwards compatible with.[3])

XML Schema will have a hard time articulating these rules, it's true.
But then, XML Schema simply doesn't deal well with the kind of markup
language that XSLT is -- one in which elements from different
namespaces mix semi-freely, many of the attributes contain values that
are impossible to validate using regular expressions, and in which the
presence of an attribute can change the legal content of an element.

So, frankly, I doubt that an XML Schema for XSLT would serve much
purpose given XSLTs design in areas quite aside from version control,
and I think that redesigning XSLT in such a way that XML Schema is a
useful schema language for it is doomed to failure. I don't think that
you'll win the argument about using namespaces to indicate versions
using the fact that XML Schema finds it easier to represent these
kinds of languages.

Instead, let's consider what's important for versioning in XSLT. XSLT
is a language that is likely to exist in several versions at once,
firstly because it has a wide user base which won't "upgrade" all at
once (or at all in some cases), and secondly because it's a language
that's used in distributed applications -- you might write a
stylesheet there that I run here, on my particular setup with my
particular processor; I don't have control over what version you use
and you don't have control over what version my processor supports. So
we're going to get:

  - both version 1.0 and version 2.0 stylesheets floating around
  - processors that support both 1.0 and 2.0 at the same time
  - stylesheets that intermix 1.0 and 2.0 constructs (particularly to
    gain backwards compatibility so that they can be used with older
    processors/browsers)

Now consider the implementers who have to add on XSLT 2.0 support to
their XSLT 1.0 processors. The vast majority of the instructions in
XSLT 2.0 are exactly the same as they were in XSLT 1.0. Under your
proposal, they would be regarded as completely different elements
(XSLT processors are *very* namespace aware -- they have to be) so
implementers would have to copy the code for dealing with the XSLT 1.0
version for the XSLT 2.0 version.

Also consider people who write stylesheets that interpret XSLT --
something that happens fairly frequently. If I wanted to list all the
names of the global parameters used in a stylesheet, I'd have to use:

  /*/(xsl1:param | xsl2:param)/@name

and I'd have to expand this XPath even further if the namespace
changed again for XSLT 3.0. These kinds of paths are often used by
people manipulating the DOM of the stylesheet prior to transformation
in client-side scripts using MSXML; for example to change the way in
which something is sorted, you might have to use an XPath expression
like:

  /*/(xsl1:template | xsl2:template)[@name = 'doSort']
    /(xsl1:for-each | xsl2:for-each)
    /(xsl1:sort | xsl2:sort)/@select

And then consider people who are writing stylesheets that mix XSLT 1.0
and XSLT 2.0. They would have to declare both namespaces, of course,
and then have to choose whether to use the XSLT 1.0 or XSLT 2.0
construct at each point. For example, when defining a template,
presumably I should use the XSLT 1.0 namespace because I need XSLT 1.0
processors to be able to understand it, but what if I want to use the
XSLT 2.0 feature of specifying the types of the parameters? xsl2:param
elements won't be recognised as parameter definitions by an XSLT 1.0
processor, but a type attribute on a xsl1:param element wouldn't be
used by an XSLT 2.0 processor. I'd be in an impossible situation.

I think that the key thing here is that there are going to be multiple
versions of XSLT around, including multiple versions used within the
same stylesheet. While versioning-by-namespace might be a reasonable
course for markup languages where that isn't the case, I think that
it makes versioning-by-namespace untenable for XSLT.
    
Cheers,

Jeni

[1] http://www.w3.org/TR/2002/WD-xslt20-20020430/#forwards
[2] http://www.w3.org/TR/2002/WD-xslt20-20020430/#backwards
[3] http://www.w3.org/TR/xslt#forwards

---
Jeni Tennison
http://www.jenitennison.com/

Received on Saturday, 20 July 2002 10:23:59 UTC