2223 2005-09-14 19:23:46 +0000 R-231: Enumeration restrictions are unclear 2006-12-08 18:03:17 +0000 1 1 1 Unclassified XML Schema Datatypes: XSD Part 2 unspecified All All CLOSED DUPLICATE 2246 editorial P2 normal --- 2454 1 sandygao cmsmcq www-xml-schema-comments oldest_to_newest 6246 0 sandygao 2005-09-14 19:23:46 +0000 The prose in parts 1 and 2 wrt the components which result from a pair of type definitions such as: Example: <xs:simpleType name="A"> <xs:restriction base="xs:token"> <xs:enumeration value="x"/> <xs:enumeration value="y"/> <xs:enumeration value="z"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="B"> <xs:restriction base="A"> <xs:enumeration value="y"/> </xs:restriction> </xs:simpleType> is not clear at all. Does the {facets} property of B contain: 1 - One enumeration component whose {value} is {y}? 2 - One enumeration component whose {value} is {x, y, z}? 3 - Two enumeration components whose {value}s are {y} and {x, y, z}? This need to be cleaned up once and for all. See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JulSep/0060.html 12827 1 davep 2006-11-04 16:17:50 +0000 (In reply to comment #0) > Does the {facets} property of B contain: > > 1 - One enumeration component whose {value} is {y}? > 2 - One enumeration component whose {value} is {x, y, z}? > 3 - Two enumeration components whose {value}s are {y} and {x, y, z}? As best I can tell, it must be either 1 or 3, and is presumably is implementation-dependent which. On the one hand, for evaluation purposes it doesn't matter since evaluating against {x, y, z} is totally redundant when also evaluating against {y}. OTOH, allowing 3 makes it's esxposure implementation dependent if that (those) component(s) is (are) hooked into a PSVI or other application-visible place. (I'm not going to claim expertise in the intricacies of "extreme PSVI" without more searching than I want to do right now.) I thought that the WG had prescribed 1, but I'm not clever enough to read that into the spec as it stands now. 12828 2 davep 2006-11-04 22:19:50 +0000 (In reply to comment #1) > As best I can tell, it must be either 1 or 3, and is presumably is > implementation-dependent which. Further information: In the definition of "constitutes a restriction" (from Part 1, Structures), line two ("2 Every facet in B is in R, unless it is of the same kind as some facet in S."): If you interpret the word "unless" as meaning not only that B need not be in R but must not be in R, then that precludes more than one of any kind of facet in {facets}. I think we might want to reword that definition in Part 1, and also at least put a note in Part 2 explaining the result. In any case, this bug seems to be a duplicate of bug 2246, so I'm closing this one. I'll try to put a more complete explanation of how I got to this conclusion in the comments for that bug. *** This bug has been marked as a duplicate of bug 2246 ***