W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2005

[Bug 2180] R-186: Constraints for min/maxIn/Exclusive facets

From: <bugzilla@wiggum.w3.org>
Date: Wed, 14 Sep 2005 18:43:54 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1EFcEc-0008R3-4U@wiggum.w3.org>


           Summary: R-186: Constraints for min/maxIn/Exclusive facets
           Product: XML Schema
           Version: 1.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSD Part 2: Datatypes
        AssignedTo: cmsmcq@w3.org
        ReportedBy: sandygao@ca.ibm.com
         QAContact: www-xml-schema-comments@w3.org

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"/>

<simpleType name="derived">
  <restriction base="my:base">
    <minInclusive value="6"/>

"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 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
Received on Wednesday, 14 September 2005 18:44:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:04 UTC