This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The fifth step in 3.7.1.1 Attributes reads: <quote> If the attribute name is xml:id, the string value and typed value of the attribute are further normalized by discarding any leading and trailing space (#x20) characters, and by replacing sequences of space (#x20) characters by a single space (#x20) character. Note: This step accomplishes xml:id processing as defined in [XML ID]. </quote> However, section 4 Processing xml:id Attributes in [XML ID] reads(among other things): <quote> An xml:id processor must assure that the following constraints hold for all xml:id attributes: The normalized value of the attribute is an NCName according to the Namespaces in XML Recommendation which has the same version as the document in which this attribute occurs (NCName for XML 1.0, or NCName for XML 1.1). </quote> This validation-part of xml:id processing is not mentioned in 3.7.1.1 Attributes. That is, I find it unclear what an implementation is supposed to do on for example <elem xml:id="1.ThisIsNotAnNCName"/> I can imagine several different ways: 1) issue an error; 2) the attribute is ignored as if it wasn't set and/or is-id is not set; 3) set is-id to true and keep the invalid value. Perhaps related: this topic is also touched in F&O. 15.5.2 fn:id and 15.5.3 fn:idref reads: "If any of the tokens is not a lexically valid IDREF (that is, if it is not lexically an xs:NCName), it is ignored." Frans
It looks like xml:space attributes will be validated, and therefore one can think that it is also sensible to validate xml:id(consistency, user expectations). ACTION A-305-10(Jonathan Robie) is assigned to this report. xml:space bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=3636
I believe that XSLT 2.0 has a similar issue. I can construct an element (for the final result tree OR a temporary tree) and give it an attribute named xml:id and parts 11.1.2 and 11.3 of the CR of XSLT 2.0 say that the is-id property would be set true. They do not have an error code for the value of said attribute not meeting the constraints. Can we ensure that the resolution is coordinated between XSLT and XQuery?
At the last face-to-face, we decided to close Bug #3527 as follows: In the XQuery/XPath documents 3.7.1.1 and 3.7.3.2, we will add add "If an error occurs during xml:id processing, an implementation may, but is not required to, raise an error XQVYxxxxxxxx". In the data model, under is-id, when we way "xml:id processing is performed", we will insert the same language as above.
Seems fine. Consistent with the recent xml:space changes.