This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It seems that in XSD 1.1: * There is no magic associated with the type xs:IDREFS; it behaves exactly the same as any other type defined as a list of IDREF values * But there is magic associated with the type xs:ENTITIES. In a user-defined type declared as a list of ENTITY values, the ENTITY values are not validated against the known set of unparsed entities; but in a value of type ENTITIES, they are. This asymmetry seems wrong. Any type declared as a list of ENTITY should have the semantics currently associated with xs:ENTITIES. This can be achieved by changing validation rule String Valid (3.16.4): delete rule 3.2, and add "or constructed" after "is validly derived".
I agree to the direction suggested in the bug report. We made the changes for ID/IDREF, but obviously missed ENTITY. But the actual change will likely be more complex than suggested. We need to cover cases where the type is a union or a list of union and ENTITY is a member in the union. This is why we had to introduce complex words like those in 3.17.5 for ID/IDREF: ... one of the following: 1 the ·actual value· of a member of the ·eligible item set· whose [type definition] or [member type definition] is or is ·derived· from ID or IDREF; 2 an item in the ·actual value· of a member of the ·eligible item set· whose [type definition] or [member type definition] has {variety} list and either its {item type definition} or the item's corresponding entry in [member type definitions] is or is ·derived· from ID or IDREF.
A wording proposal intended to resolve this issue is now at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b10662.html (W3C member only link) The main innovation is that it defines a class of terms (ENTITY value, ID value, etc.) which can be used to describe the relevant constraints more consistently, more briefly, and the editors hope more clearly.
On the telcon 2011-02-04 Amendment: instruct the editors to make "ENTITY value" (etc.) point to the paragraph defining that class of terms.
The change mentioned in comment 2 has been integrated into the status-quo version of the spec, with the amendment mentioned in comment 3. This issue can accordingly be marked resolved. Michael?