W3C home > Mailing lists > Public > xsl-editors@w3.org > July to September 1999

XSLT Section 2.5: Forwards-compatible processing

From: David Megginson <david@megginson.com>
Date: Wed, 25 Aug 1999 17:18:58 -0400 (EDT)
To: xsl-editors@w3.org
Message-ID: <14276.23595.574596.383955@localhost.localdomain>
I'd like to comment on the following language in Section 2.5 of the
1999-08-03 XSLT working draft:

  If the namespace URI of the expanded name of an element or attribute
  starts with http://www.w3.org/XSL/Transform/ but is not equal to the
  XSLT 1.0 namespace URI (http://www.w3.org/XSL/Transform/1.0), then
  an XSLT processor must treat the element or attribute the same as if
  its namespace URI was the XSLT 1.0 namespace URI, except that it
  must recover from errors as follows:

I believe that this is a very awkward way to manage
forward-compatibility, since it relies on looking inside Namespace
URIs (which are best left opaque) and it assumes that the XSLT
Namespace URI will change with each version (which is awkward).

Here's what I think will be a better solution:

1. Declare a single, persistent XSLT Namespace URI, such as
   "http://www.w3.org/XSL/Transform/", and plan not to change it.

2. Create an attribute {http://www.w3.org/XSL/Transform/}version, that 
   can appear anywhere within an XSLT document; when it appears, it
   provides a version number for interpreting all XSLT element and
   attribute names within the subtree where it appears, unless
   overridden further down.  Unless specified, the version will be
   assumed to be 1.0.

I think that this kind of approach deals much more elegantly with the
Namespace versioning problem without a proliferation of Namespace

All the best,


David Megginson                 david@megginson.com
Received on Wednesday, 25 August 1999 17:20:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:17 UTC