This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 30397 - [xslt30] Effect of xsl:namespace-alias on attributes in no namespace
Summary: [xslt30] Effect of xsl:namespace-alias on attributes in no namespace
Status: NEW
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-24 10:21 UTC by Michael Kay
Modified: 2019-02-19 19:36 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2019-01-24 10:21:14 UTC
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.
Comment 1 Michael Kay 2019-02-13 12:59:40 UTC
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.
Comment 2 Abel Braaksma 2019-02-19 19:36:04 UTC
> 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