This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Test case 1901 effectively does: <xsl:namespace-alias stylesheet-prefix="#default" result-prefix="xsl"/> <xsl:template match="/"> <stylesheet version="1.0"/> </xsl:template> and expects the output <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"/> which seems reasonable enough. But it is hard to find reasoning in the spec that supports this. We've just done a fresh implementation that generates <xsl:stylesheet xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"/> so I've been studying the spec to see which is correct. Firstly, §11.1.2 says: "The new attribute node will have the same expanded QName (that is, the same namespace URI, local name, and namespace prefix) as the attribute in the stylesheet tree" but I think we can take it that the rules on namespace aliasing are intended to define an exception to the general rule in §11.1.2. §11.1.4 on namespace aliasing says: The default namespace (as declared by xmlns) may be specified by using #default instead of a prefix. If no default namespace is in force, specifying #default denotes the null namespace URI. This allows elements that are in no namespace in the stylesheet to acquire a namespace in the result document, or vice versa. So the interpretation of this is that in this example, the "literal namespace URI" is the "null namespace", and the target namespace is the XSLT namespace. The question then becomes, how does this affect attribute nodes? The rules in §11.1.4 make no distinction between elements and attributes. To quote: The effect is that when names in the namespace identified by the literal namespace URI are copied to the result tree, the namespace URI in the result tree will be the target namespace URI, instead of the literal namespace URI. This applies to: * the namespace URI in the expanded QName of a literal result element in the stylesheet * the namespace URI in the expanded QName of an attribute specified on a literal result element in the stylesheet Clearly these rules aren't sufficiently explicit about the "null namespace" case. According to the data model, in both the element node and attribute node in this fragment, the name of the node is a QName in which the namespace URI is "absent". Although the language isn't very precise, the examples and notes make it clear at least for elements that namespace-alias will change a no-nsamespace name into a target-namespace name in this situation. Is there any justification for not doing the same thing for attribute nodes? I think that to find such a justification, we have to fall back on philosophical principles, in particular the philosophy that the default namespace does not apply to attributes. Note that XSLT 1.0 did not say what should happen when #default is used and there is no default namespace. XSLT 2.0 introduced the rule that it then remaps the "null namespace" - with no distinction made between elements and attributes.
I have drafted erratum E48 to say that (a) in the case where stylesheet-prefix="#default" and there is no default namespace in force, no-namespace attributes remain in no namespace (b) in the case where result-prefix="#default" and there is no default namespace in force, attributes in the "literal" namespace are renamed to be in no namespace. This is consistent with existing expected test results.
> I think that to find such a justification, we have to fall back on > philosophical principles, in particular the philosophy that the default > namespace does not apply to attributes. I think this is fair, and if users want an attribute in a specific namespace, they can do so by other means. I'd find it rather surprising if the reverse is true. In reply to comment#1, I agree to that draft. For reference, here's the HTML preview: https://htmlpreview.github.io/?https://github.com/w3c/qtspecs/blob/master/errata/xslt-30/html/xslt-30-errata.html#E48