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 3527 - Attributes: xml:id processing misleading
Summary: Attributes: xml:id processing misleading
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Data Model 1.0 (show other bugs)
Version: Candidate Recommendation
Hardware: Other Linux
: P2 normal
Target Milestone: ---
Assignee: Don Chamberlin
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2006-07-24 13:54 UTC by Frans Englich
Modified: 2006-09-19 23:06 UTC (History)
0 users

See Also:


Description Frans Englich 2006-07-24 13:54:25 UTC
The fifth step in Attributes reads:

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.
This step accomplishes xml:id processing as defined in [XML ID].

However, section 4 Processing xml:id Attributes in [XML ID] reads(among other things):

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).

This validation-part of xml:id processing is not mentioned in 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."

Comment 1 Frans Englich 2006-09-13 10:58:48 UTC
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:
Comment 2 David Marston 2006-09-14 21:04:35 UTC
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?
Comment 3 Jonathan Robie 2006-09-19 14:20:15 UTC
At the last face-to-face, we decided to close Bug #3527 as follows:

In the XQuery/XPath documents and, 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.
Comment 4 Frans Englich 2006-09-19 23:06:09 UTC
Seems fine. Consistent with the recent xml:space changes.