This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider the following as a complete XML document <X>abcd</X> where X is declared to have type xs:ID. This arises in test case NISTSchema-SV-IV-atomic-ID-maxLength-1. According to Part 1, section 3.17.5.2, I believe the ID/IDREF table will contain an ID/IDREF binding whose [id] is the string "abcd" and whose [binding] is the empty set. According to Part 1 section 3.3.4.5, this makes the X element invalid. The rationale stated in a Note is "The first clause above applies when there is a reference to an undefined ID." This rationale appears to be incorrect if the situation can also arise for an ID-valued element that has no parent. There are various possible resolutions. The choice of resolution may depend on how we want to handle the document <X IDREF="abcd">abcd</X> - is this valid because the IDREF value exists in the document as an ID, or is it invalid because there is no element whose ID is abcd?
On the telcon of 2010-06-18, the WG decided both these examples should be invalid, as the spec currently says, and the non-normative note in 3.3.4.5 should be reworded to explain why.
I'm changing the keyword to needsDrafting, since I think the WG should have a chance to look at the text before it goes into the status-quo document. (Also, changing this keyword makes it possible for the newly regenerated status-quo document to claim that it incorporates all decisions by the WG made to date. If that means downgrading this from a decision to a directive, well, that's the price we'll have to pay.)
Consider a schema: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="X"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:id"> <xs:attribute name="id" type="xs:id" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:schema> And 2 instances: I1: <X>abcd</X> I2: <X id="abcd">abcd</X> It seems that I1 is invalid (an ID/IDREF binding without a [binding]) but I2 is valid (because of the "id" attribute). Does anyone find this counter-intuitive? I would think either "top-level ID element is bad", then both I1 and I2 are invalid, or "top-level ID element is ignored", then both are valid.
We discussed this 29 October 2010. There seem to be three possible resolutions: 1) top-level ID element is bad and is forbidden explicitly, so T1 and T2 are both invalid. 2) top-level ID as element content is ignored, so T1 and T2 are both valid. 3) the ID table can take references to the document node, so a top-level ID is an ID for the document node (as distinct from an ID for the root element). Then T1 is valid and T2 is invalid, because the ID 'abcd' now has two entries in the ID table. T2 is then parallel to T3 <e><X id="abcd">abcd</X></e> which is invalid now, because 'abcd' cannot be the ID both of e and of X.
In Lyon: The WG discussed this item and suggested that we move this bug back to "needsDrafting" with the instruction to make the change described in comment 1. The WG furter believes that we should abandon work by SG in comment 3. The WG agrees that the example is counter intuitive, but that it is admittedly a corner-case, and changes to the rules will undoubtedly have other counter-intuitive consequences.
I will concur with the WG's decision, but ... 1. Do we believe that a significant number of existing schema 1.0 processors actually forbids I1 and allows I2 in comment #3? It's likely that a conforming 1.1 processor will behave differently from 1.0 anyway. 2. If we adopt option 1 in comment #4, I "doubt" it will have "other counter-intuitive consequences". 3. The "needsDrafting" instruction is to explain why I1 is invalid. Do we believe we can do that without - Saying something inaccurate - Saying something unclear - Drawing people's attention to the counter-intuitive cases? For example, we may need to say "The first clause above applies when there is a reference to an undefined ID, <add>or when the validation root element has an ID value (pending the work to make it easy to say "has an ID value") and there is no other occurrence of the same ID value elsewhere in the document.</add>" Not sure we can say less than that, and this will likely confuse the reader more and eventually lead them to the discovery of the counter-intuitive case. I agree this is indeed a corner case. Maybe we should just leave things alone?
A wording proposal intended to resolve this issue is on the server at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b9922.html (W3C-member-only link) Essentially it consists of a note describing three examples similar to the ones described in the discussion and recommending caution in interpreting ID/IDREF validation results when the validation root has type ID.
Telcon 2011-02-04: 1 Delete "Caution is therefore ... from it." 2 Replace "When ... counter-intuitive" with "Since an element of type xs:ID provides a unique identifier for the element's parent, it is not useful to have an element of type xs:ID when the element has no parent or the parent is not in scope for the validation." Adopted as ammended.
The change mentioned in comment 7 has been integrated (with the amendments mentioned in comment 8) into the WG's status-quo version of the spec at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.html#sec-cvc-id (member-only link) So I'm marking this issue as resolved. Michael, if as the raiser of the issue you would check the resolution and close or reopen the issue as needed, it would be helpful.