For the record, here's a dump of the discussion on member bug 937:

Description Tim Mills 2011-05-31 13:46:05 UTC
The expected result for nspc-n138 is

<out xmlns:n="http://ns.test.com">
<n:x>from stylesheet</n:x>
<e xmlns="http://literalURI"
><n:a xmlns="" xmlns:n="http://example.com">content</n:a>
</e>
</out>

but should be

<out xmlns:n="http://ns.test.com">
<n:x>from stylesheet</n:x>
<e xmlns="http://literalURI">
<n:a xmlns:n="http://example.com">content</n:a>
</e>
</out>

The expected result for nspc-n139 is

<out xmlns:n="http://ns.test.com" xmlns:s="http://example.com">
<n:x>from stylesheet</n:x>
<e xmlns="http://literalURI">
<n:a xmlns="" xmlns:n="http://example.com">content</n:a>
</e>
</out>

but should be

out xmlns:n="http://ns.test.com" xmlns:s="http://example.com">
<n:x>from stylesheet</n:x>
<e xmlns="http://literalURI">
<n:a xmlns:n="http://example.com">content</n:a>
</e>
</out>
[reply] [-] Comment 1 Michael Kay 2011-05-31 14:17:51 UTC
Please see bug #931, which explains why the results of these tests were
changed.
[reply] [-] Comment 2 Tim Mills 2011-06-01 13:21:45 UTC
Sorry for the duplication.

However, having attempted to implement the changes for the erratum, I think
some other tests may be affected.  Consider nspc-n120:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0"
    xmlns="http://base.test/">

<xsl:template match = "/">
  <out xmlns:p1="http://xyz/">
    <xsl:element namespace="http://new/" name="p1:foo">
      <yyy/>
    </xsl:element>
  </out>
</xsl:template>

</xsl:stylesheet>

At the point that 'out' is being constructed, reading the new text:

If the newly constructed node (out) is an element node (which it is),

and if namespaces are inherited (which they are),

then each named (that is, non-default) namespace node of the newly
constructed element (namespace node for p1="http://xyz/")

(including any produced as a result of the namespace fixup
process) is copied to each descendant element (p1:foo, y)

of the newly constructed element,

unless that element or an intermediate element already has a namespace node
with the same name (p1:foo already has a namespace node with name p1).

Thus the expected result should be:
<out xmlns="http://base.test/" xmlns:p1="http://xyz/">
<p1:foo xmlns="" xmlns:p1="http://new/">
<yyy xmlns="http://base.test/" xmlns:p1="http://xyz/"></yyy>
</p1:foo>
</out>

because p1:foo does not inherit xmlns="http://base.test/" from "out" according
to these rules.
[reply] [-] Comment 3 Michael Kay 2011-06-02 15:44:10 UTC
I agree with you about nspc-n120 - the erratum changes the result of this test.
I can't say I like it, but I don't see much alternative. Please let me know of
any other tests you think are affected.

I think that in the Saxon implementation of the bug 5857 fix, I only changed
the behaviour of literal result elements, not xsl:element and xsl:copy, which
would account for why some affected tests have gone unnoticed.
[reply] [-] Comment 4 Tim Mills 2011-06-02 15:52:28 UTC
15 tests are affected.

bug19
nspc42
nspc-n120
nspc-n121
nspc-n122
nspc-n123
nspc-n124
nspc-n58
nspc-n59
nspc-n63
nspc-n67
nspc-n69
nspc-n83
nspc-n84
nspc-n87

I see why the change was made, but I'm not sure I like its consequences, nor
the way it makes XQuery and XSLT a little bit different in a quirky way.

Similary arguments to the XSLT example with XML Schemas might be raised with
the XQuery:

<xs:schema xmlns:xs="..." xmlns="urn:not-null">
{
  doc('myschema.xsd')/xs:schema/node()
}
[reply] [-] Comment 5 Michael Kay 2011-06-02 17:01:09 UTC
I've reopened bug 5857 so this can be discussed by the WG. I don't think
there's an easy answer.


On 30/11/2011 14:28, Michael Kay wrote:
On 30/11/2011 13:09, Hans-Juergen Rennau wrote:
Hello,
 
I encounter a problem with managing namespaces in an XSLT 2.0 stylesheet. Perhaps it is a bug, or I misread the spec.
This is a matter that has been taxing the Working Group. See

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5857

The text you are quoting was introduced by erratum XT.E37 (as mentioned in comment 6 of the bugzilla entry). But this was subsequently found to have problems (sadly the discussion moves to the member-only bug entry 937), and in consequence, I reverted the change in Saxon, which now behaves as described in the original 2007 version of the spec.

At the time of writing, the WG doesn't have a solution to this problem that gives satisfactory behaviour in all cases.

Michael Kay
Saxonica