This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The namespace Axis is optional in XPath with a comment that if it is not supported then namespace nodes need not be supported at all. In XSLT the option of not supporting namespace nodes is not present (as they may be generated by xsl:namespace) so one may have expected that the namespace axis was required but unfortunately it is only required in the scope of backward compatibility mode. For a real, fairly high profile example (the implementation of schematron) where this is already causing problems in interoperability see http://colina.demon.co.uk/?q=node/8 It's not possible to change this situation via errata, but this is a request for any XSLT 2.x release to address this by (preferably) mandating support for the namespace axis or adding something that allows a stylesheet to test for this, perhaps in conjunction with system-property() (like xsl:supports-backwards-compatibility) David
Personal response: I have some sympathy with both parts of this requirement. It does seem a little odd that XSLT 2.0 simultaneously introduced the ability to create namespace nodes and deprecated the mechanism for retrieving them. And it is indeed unfortunate that we don't provide an interrogative that enables the application to determine whether the axis is supported or not. My feeling is that we could solve the second issue by means of a permissive erratum: "An implementation MAY provide the following system property: xsl:supports-namespace-axis, returns the string "yes" in the case of a processor that supports use of the namespace axis, or "no" otherwise. Note that if this system property is not provided, system-property('xsl:supports-namespace-axis') will return a zero-length-string." This erratum would not affect the conformance of existing implementations, so I think it might be acceptable. On the other hand, it is feature creep.
On 31 May 2007 the WG agreed to make this change by means of an erratum.
After much discussion of adding additional system-property interrogatives the decision was reaching at the XSLT meeting on 10/10/07 provide the namespace interrogative only through the erratum. ALB took the action item to add an enhancement request for additional interrogatives. Note: need erratum number!
thanks David
Process as E14.
Proposed text: in 16.6.5, after the list of required system properties, add: In addition, processors MAY support the following system property in the XSLT Namespace. A processor that does not support this property will return a zero-length string if the property is requested. * xsl:supports-namespace-axis, returns the string <code>"yes"</code> in the case of a processor that offers the XPath namespace axis even when not in backwards compatible mode, or <code>"no"</code> otherwise. Note that a processor that supports backwards compatible mode must support the namespace axis when in that mode, so this property is not relevant to that case.
I would change: "A processor that does not support this property will return a zero-length string if the property is requested." to: "(A processor that does not support this property will return a zero-length string if the property is requested, as a consequence of the rules in section 16.6.5)" Why not mandate the property if the namespace axis IS supported (so that the empty string is reliably equivalent to "no")? I believe that Saxon is the only processor that currently supports it, and since I assume that you (Michael) will be adding this property, as you have proposed it, there doesn't seem to be a problem with this.
Personal response: I'm OK with parenthesizing the sentence as suggested - this would also seem to satisfy Howard who wanted the sentence removed as redundant. As a matter of principle, I don't think we can behave as if it's OK to change the spec if all known implementors get round the table and agree. It's a public spec and the public are entitled to stability. People who implement it aren't required to register their interest with W3C, and in fact it's quite common for implementations of specifications to exist that are not widely known (there have been XSLT 1.0 implementations produced for in-house use within a single company, and there have been implementations that were never marketed outside Japan, for example). Also, closer to home, people who have bought a Saxon license believing that they were buying a conformant product are entitled to continue using it knowing that once conformant, it will remain conformant - much as I would like them to upgrade.