2180 2005-09-14 18:43:54 +0000 R-186: Constraints for min/maxIn/Exclusive facets 2009-04-21 19:21:35 +0000 1 1 1 Unclassified XML Schema Datatypes: XSD Part 2 unspecified All All CLOSED LATER resolved P2 normal --- 1 sandygao cmsmcq www-xml-schema-comments oldest_to_newest 6183 0 sandygao 2005-09-14 18:43:54 +0000 In the definitions of these facets, it says their values *must* be in the value space of the base type. But there is no constraint to enforce this rule. For example, <simpleType name="base"> <restriction base="integer"> <enumeration value="7"/> <enumeration value="8"/> <enumeration value="9"/> <restriction> <simpleType> <simpleType name="derived"> <restriction base="my:base"> <minInclusive value="6"/> <restriction> <simpleType> "6" in the derived type isn't from the value space of the base type, so this should be an invalid derivation, according to the definition of the minInclusive facet. But there is no constraint saying it's invalid. Section 4.3.10.4 only talks about how the minInclusive value compares with the values in the base. IMO, all "XXX valid restriction" constraints in 4.3.7/8/9/10.4 should be replaced by a simple statement saying their values must be from the value space of the base, with the exception of min/maxExclusive, where their values could be the same as the value of the same facet in the base type. See : http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Nov/0233.html 6184 1 sandygao 2005-09-14 18:44:04 +0000 Discussed at the 2003-11-20 telecon. Sandy Gao to study further, to see if there is already a Rec issue that covers this Sandy's research: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Dec/0038.html 11897 2 cmsmcq 2006-09-20 23:05:20 +0000 At the face to face meeting of January 2006 in St. Petersburg, the Working Group discussed this issue. While there was some sentiment for giving it a high priority, in the end the Working Group decided not to take further action on this issue in XML Schema 1.1. The rationale for the Working Group's decision was that while real, the design inconsistency identified in the issue does not actually involve any logical inconsistency, and does not seem to be presenting an acute problem for users. While most members of the Working Group would be glad to see this issue addressed (not all members of the WG -- one dissenter describes this as another instance of paternalism that complicates the spec needlessly), the Working Group did not feel it useful to delay Datatypes 1.1 for such a change. This issue should have been mark as RESOLVED / LATER at that time, but apparently was not. I am marking it that way now, to reduce confusion.