The comment for the fix is misleading, it should've stated that XTDE0865 is to be used here, which is correct in the test, but not in the modify-comment.

However, there seems to be a slight ambiguity between erratum E6 [1] and XSLT 3.0. In E6, only XTDE0865 is mentioned (for xsl:element), nothing about XTDE0835 (for xsl:attribute). Strictly speaking, the xmlns error for xsl:attribute is not defined for XSLT20, but is defined for XSLT30 [2].

But, considering that everywhere else in the text of XSLT20 using the xmlns namespace is forbidden and results in the same errors as for when the datatype is not xs:anyUri, I propose to ignore this fact and accept the current version of the test as correct and update the modify-text to reflect this.

Summary:
- XTDE0865 is not updated in E6
- hence test should be XSLT30+
- but this doesn't make sense, XTDE0865/35 are both available in XSLT20 and should be treated semantically equal
- solution: leave as is, update modify-comment.


[1] http://www.w3.org/XML/2007/qt-errata/xslt-errata.html#E6
[2] http://www.w3.org/TR/xslt-30/#err-XTDE0865

Apologies, I wrote 

"In E6, only XTDE0865 is mentioned (for xsl:element), nothing about XTDE0835 (for xsl:attribute)."

this should've been the reverse error numbers:

" In E6, only XTDE0835 is mentioned (for xsl:element), nothing about XTDE0865 (for xsl:attribute)."

rest of the text uses the correct error numbers.

Although the error code XTDE0865 is not mentioned in the Erratum, it is included in the XSLT 2.0 PER at http://www.w3.org/TR/2007/REC-xslt20-20070123/ which I think we can treat as superseding the Erratum. The use of XTDE0865 was explicitly proposed in the bugzilla entry https://www.w3.org/Bugs/Public/show_bug.cgi?id=4464 which led to the drafting of erratum E6.

So I think the no change is needed to the test or the specs, except for correction of the "modified" metadata in the test.

Apologies for being unclear, but it is not that the error is not there, it is that the XTDE0865 and XTDE0835 cover different situations, and it is that different situation (the xmlns namespace) that is covered by this test.

Error XTDE0835 (in REC):
It is a non-recoverable dynamic error if the effective value of the namespace attribute [of the xsl:element instruction] is not in the lexical space of the xs:anyURI data type.

Error XTDE0865 (in REC):
It is a non-recoverable dynamic error if the effective value of the namespace attribute [of the xsl:attribute instruction] is not in the lexical space of the xs:anyURI data type.

Error XTDE0835 (in Erratum):
It is a non-recoverable dynamic error if the string value of the new namespace node is not valid in the lexical space of the data type xs:anyURI, or if it is the string http://www.w3.org/2000/xmlns/.

It is the additional "or if it is the string http://www.w3.org/2000/xmlns/" that causes the ambiguity, as that part is not included for XTDE0865. Note also the difference in wording, the Erratum talks of "namespace node" for XTDE0835, but the REC talks about "namespace attribute". Not a big difference though. In XSLT 3, both errors use the wording "namespace attribute".

Looking further, this same ambiguity applies to error XTDE0905 (creating namespace nodes): XSLT 2.0, nor erratum, mentions the exception for the xmlns namespace, while XSLT 3.0 does mention it. There's currently no test that creates the xmlns namespace with the xsl:namespace instruction.

Thanks.  Marking as RESOLVED INVALID.

Tim, maybe my understanding of "invalid" is incorrect, but considering my last comment, I don't think this bug is ready to be resolved or closed at all. Can you comment on it? If you agree it's resolved in error, I think it's better to reopen the bug and leave it open until all issues are resolved.

Sorry, but I thought I'd said

"This test expects XTDE0865, but should expect XTDE0835"

and the response was

"No, it should expect XTDE0865"

Therefore my bug report was invalid.  Am I mistaken?

No, you are not mistaken. I think we went on hijacking the bug-report, as your report revealed something else: an ambiguity in the spec. XTDE0865, which is what the test is about, is NOT specified in XSLT 2.0 as the error for wrongly using the xmlns namespace with xsl:attribute. So the existence of the test itself should be questioned.

However, in the Erratum, XTDE0835 was updated (for xsl:element), but XTDE0865 was not. Hence it seems an error in the erratum and hence possibly an error in the test. Later I found out that XTDE0905 had the same issues.

I'm yet unsure what the best cause of action is: assume the Erratum for XTDE0835 silently applies to XTDE0865 and XTDE0905 as well, or accept the difference and remove the test for 2.0, but leave it for 3.0. I'm in favor of the first solution and possibly updating the erratum at some point in time.

> However, in the Erratum, XTDE0835 was updated (for xsl:element), but XTDE0865 
> was not. Hence it seems an error in the erratum and hence possibly an error in 
> the test. Later I found out that XTDE0905 had the same issues.

Let's wrap this up. Even if the text of the error in the 2.0 REC or erratum is not 100% correct, the XMLNS namespace is forbidden and I think we can assume that these are the errors to be used for XSLT 2.0 and 3.0.

There are three tests expecting XTDE0865 (xsl:attribute):

* error-865a, XSLT20+, uses malformed xsAnyUri, correct
* si-attribute-065, XSLT30+, uses xmlns namespace, correct
* namespace-2623, XSLT20+, uses xmlns namespace, I added/fixed comment in test

There are four tests expecting XTDE0835 (xsl:element), all correct.

There is one test for XTDE0905 (xsl:namespace), which is correct.


-------
I will close this bug as resolved. A comment has been added to the namespace-2623 test.

Was resolved > 30 days ago, closing.