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 an element declaration <element name="e"> <complexType> <sequence> <element name="id1" type="ID"/> <element name="id2" type="ID"/> </sequence> </complexType> </element> And the instance <e><id1>abc</id1><id2>abc</id2></e> Many people would think the above is invalid, because there are duplicate ID values. But a careful reading of the "ID/IDREF Table" PSVI property suggests that the above is valid. There will only be one entry in the [binding], the element "e". Is this intended? Is this how most schema processors implemented ID/IDREF? Either way, some clarification will be helpful.
No harm, no foul. The guarantee ID provides is that no ID is attached to two distinct items. In SGML and XML, there was also a declaration constraint which prevented items from having two IDs, but we explicitly did _not_ reconstruct this constraint except for attributes, although both parts 1 and 2 both suggest not using ID for the type of elements. The example schema given makes it possible for an element to have multiple IDs, but then the instance doesn't exploit this. In my view the resulting ID/IDREF table is correct -- one entry, with one binding, i.e. 'abc' bound to the doc. element. And I think the spec. correctly specifies that in case of an instance such as <e><id1>abc</id1><id2>xyz</id2></e> there will be _two_ entries in the ID/IDREF table, one binding 'abc' to the doc. elt and one binding 'xyz' to it. Your gun, your foot, your bullet. In other words, no bug, no change required.
Created attachment 446 [details] Test case: schema
Created attachment 447 [details] Test case: instance
Created attachment 448 [details] Test case 2: schema
Created attachment 449 [details] Test case 2: instance
Created attachment 453 [details] Test case 3: schema document One ID attribute, two ID (sub-)elements.
Created attachment 454 [details] Test case 3: XML instance Three dependents of type ID with different values, all on the same element. Several people have said all processors will behave the same on this, but some thing that all processors will accept it, others that all will reject it. The spec is I think clear that the schema is OK and the instance is valid against the schema.
Created attachment 458 [details] Test case 4: schema document When an element's simple content is of type ID and one of its attributes also has type ID, test whether the 2 IDs can have the same value.
Created attachment 459 [details] Test case 4: XML instance When an element's simple content is of type ID and one of its attributes also has type ID, test whether the 2 IDs can have the same value.
The working group discussed this issue at the 2007-03 F2F meeting. It was observed that - Users and some specifications, as with schema itself, view elements with IDs as identifying their parents - Users may want to use different ways (sub-elements/attributes) to identify the same element, but using the same ID value. Based on these, the WG decided not to change the behavior in the current schema spec.