Please hold fire on making changes here: I think the problem needs discussion.

At first glance, it seems XSLT 1.0 implied that namespace aliases applied to the URIs in namespace nodes, as well as the namespaces in the names of elements and attributes:

<xslt-1.0>
A namespace URI in the stylesheet tree that is being used to specify a namespace URI in the result tree is called a literal namespace URI. This applies to:

the namespace URI in the expanded-name of a literal result element in the stylesheet

the namespace URI in the expanded-name of an attribute specified on a literal result element in the stylesheet

the string-value of a namespace node on a literal result element in the stylesheet
</xslt-1.0>

In the 2.0 spec, the third item in the list has disappeared:

<xslt-2.0>
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
</xslt-2.0>

and 3.0 retains the 2.0 wording.

Was this change deliberate, and is it viable? Saxon appears to implement the 1.0 rule. The literal result element <out> has two in-scope namespaces, xsl and f, and it is applying aliasing to these namespaces as well as to the element and attribute names.

I would like to study this further before agreeing that the test case is wrong.

I think the test results are correct. The logic is as follows:

The <out> element has two namespace nodes: xsl=http://www.w3.org/2009/XSL/Transform, and f=http://impincl32/ns.

The xsl:namespace-alias creates a mapping from the literal namespace URI http://impincl32/ns to the target namespace URI http://www.w3.org/2009/XSL/Transform.

The spec states:

<quote>
When a literal result element is processed, its namespace nodes are handled as follows:

* A namespace node whose string value is a literal namespace URI is not copied to the result tree.
* A namespace node whose string value is a target namespace URI is copied to the result tree, whether or not the URI identifies an excluded namespace.
</quote>

So the namespace node f=http://impincl32/ns is not copied to the result tree (under the first rule), but the namespace node xsl=http://www.w3.org/2009/XSL/Transform is copied (under the second rule).

> I would like to study this further before agreeing that the test case is wrong.

Ok, thanks for holding it off, I will wait with submitting proposed changes (or, alternatively, both outcomes can be accepted).

So it boils down to:

<xsl:template match="/">
   <a>
      <ns:b xmlns:ns="urn:other" />
   </a>
</xsl:template>

whether this can be serialized after ns fixup to:

<a xmlns:ns="urn:other">
    <ns:b />
</a>

or that it must keep the namespace node "connected" to the <b> element. I think that:

1) if the namespace is declared before a certain LRE, it effectively becomes a namespace node on all descending elements (barring namespace redeclarations).

2) if the namespace node is declared only on the element itself, the namespace node springs into existence there and should not appear on ancestors as well.

3) if the namespace is an alias, the rules should apply (should apply?) to the alias, and be changed in-situ with the other namespace it is aliasing. That is to say, the namespace being aliased (here the XSL namespace) is *not* automatically in scope on the ancestors.

4) possibly, namespace fixup may bring the declaration closer to its use, if that doesn't invalidate required earlier namespace nodes.


------
Back to this case: On reconsideration, I think both outcomes are possible, because the f-namespace is declared as an ancestor of the LRE root, yet is only used in one place (but I have to admit I have always found the namespace fixup process rather fuzzy).

>  but the namespace node xsl=http://www.w3.org/2009/XSL/Transform is copied 
> (under the second rule).

I didn't mean to say it is not being copied at all, it is just that I think it should be copied on the "xsl:transform" element, not necessarily on (all) its ancestors. But see my comment (it crossed yours), I think that both are possible. Am I wrong?

Under the section of 5.7.3 Namespace Fixup I found the following line:

<quote>
XSLT 3.0 supports the creation of result trees that do not satisfy this constraint: the namespace fixup process does not add a namespace node to an element merely because its parent node in the result tree has such a namespace node.
</quote>

This suggests that all the ancestors (may/must?) have this namespace node removed because it is not in use, and only when it is required to resolve the QName of the LRE element, it comes into play. I'm quite at a loss to whether this is required or implementation-defined, or even allowed behavior, though it seems reasonable to bring namespace declarations closer to their use.

I don't think namespace fixup plays any part in this. Namespace fixup is relevant only when an element or attribute has a name in a particular namespace but has no namespace node providing a binding for that namespace. Since <out> is in no namespace and has no attributes, there is no need for namespace fixup to do anything. In this case the namespace node is generated not because of the namespace fixup rules, but because of the namespace aliasing rules.

In the absence of the namespace alias: the <out> element would have two in-scope namespaces "xsl" and "f" (plus the trivial "xml" binding, of course). No namespace nodes (other than "xml") would be generated because the xsl namespace is implicitly an excluded namespace, while the f namespace is explicitly excluded. 

But the rules for namespace aliasing kick in before the rules for namespace exclusion, and the effect of these rules is unambiguously that the new <out> element has a namespace node for the xsl namespace.

Regarding comment #4, we only need to consider whether the xsl namespace node should be present on the <out> element. That's the key difference between the results expected by the test and the result you want. If we consider the LRE rules as applied to the <out> LRE, they tell us that the corresponding element in the result tree gets a namespace node for the xsl namespace, and nothing else is going to remove this.

Regarding comment #5, the note you cite says that the fact that a namespace node X=Y is present on a parent element does not necessarily mean that a namespace node for X will also be present on its children. That rule might (sometimes) mean that a namespace that's present on <out> isn't present on the children of <out>, but it can't cause any namespace nodes to be removed from the outermost element <out>.

There is no rule that namespace nodes can be removed from an element because they are not in use. Namespace fixup never removes namespace nodes, it only adds them.

Serialization eliminates redundant namespaces, but it will never eliminate a namespace from the outermost element because a namespace node on the outermost element can never be considered redundant. (A namespace is not redundant because it is unused, it can only be redundant because the same namespace appears on an ancestor element.)

Thanks for your extensive answers. I see now where I went wrong in my assessment. To prevent that I (or someone else) raises this again, I will update the test with a comment and point to this bug report. The test can stay as is (and I have to fix a bug in my implementation ;).

As discussed at F2F 2016 Prague there's was nothing else to be done here. Closed as WORKSFORME.