10662 2010-09-20 15:42:54 +0000 Should IDREFS and ENTITIES be magic types? 2011-03-04 23:51:47 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.1 only PC Windows NT CLOSED FIXED resolved P2 normal --- 1 mike David_E3 cmsmcq sandygao www-xml-schema-comments oldest_to_newest 39117 0 mike 2010-09-20 15:42:54 +0000 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". 39222 1 sandygao 2010-09-23 17:55:55 +0000 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. 44977 2 cmsmcq 2011-02-01 17:48:48 +0000 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. 45181 3 David_E3 2011-02-07 15:38:36 +0000 On the telcon 2011-02-04 Amendment: instruct the editors to make "ENTITY value" (etc.) point to the paragraph defining that class of terms. 46367 4 cmsmcq 2011-03-04 22:43:35 +0000 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?