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

[Bug 2044] R-198: ensure that unions of unions retain union-level facets

From: <bugzilla@wiggum.w3.org>
Date: Thu, 08 Sep 2005 21:55:51 +0000
To: www-xml-schema-comments@w3.org
Cc:
Message-Id: <E1EDUN5-0004Ku-QR@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=2044

           Summary: R-198:  ensure that unions of unions retain union-level
                    facets
           Product: XML Schema
           Version: 1.1
          Platform: PC
               URL: http://www.w3.org/2001/05/xmlschema-rec-
                    comments.html#pfiUnionOfUnion
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSD Part 2: Datatypes
        AssignedTo: cmsmcq@w3.org
        ReportedBy: cmsmcq@w3.org
         QAContact: www-xml-schema-comments@w3.org


[Ed Merks reported the following problem (against XML Schema
1.0) in private email.]

The Union SimpleType Definition Schema Component is defined
with the followg properties:

  {member type definitions}

      The appropriate case among the following:

      1 If the <union> alternative is chosen, then
        [Definition:]define the explicit members as the type
        definitions resolved to by the items in the actual
        value of the memberTypes [attribute], if any,
        followed by the type definitions corresponding to
        the <simpleType>s among the [children] of <union> if
        any. The actual value is then formed by replacing
        any union type definition in the explicit members
        with the members of their {member type definitions},
        in order.

      2 If the <restriction> option is chosen, then the
        {member type definitions} of the {base type
        definition}.

  {facets}

      If the <restriction> alternative is chosen, a set of
      facet components constituting a restriction of the
      {facets} of the {base type definition} with respect to
      a set of facet components corresponding to the
      appropriate element information items among the
      [children] of <restriction> (i.e. those which specify
      facets, if any), as defined in Simple Type Restriction
      (Facets) (3.14.3), otherwise the empty set.

I believe that it implies a loss of facet restrictions which
is highlighted by the following example:

  <xsd:schema 
      targetNamespace="http:///simple/MySchema.xsd"
      xmlns:this="http:///simple/MySchema.xsd" 
      xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  
    <xsd:simpleType name="mySimpleType1">
      <xsd:union 
        memberTypes="xsd:nonNegativeInteger xsd:boolean"/>
    </xsd:simpleType>
  
    <xsd:simpleType name="mySimpleType2">
      <xsd:restriction base="this:mySimpleType1">
        <xsd:enumeration value="true"/>
        <xsd:enumeration value="0"/>
      </xsd:restriction>
    </xsd:simpleType>
  
    <xsd:simpleType name="mySimpleType3">
      <xsd:union 
        memberTypes="xsd:negativeInteger this:mySimpleType2"/>
    </xsd:simpleType>

    <xsd:simpleType name="mySimpleType4">
      <xsd:restriction base="this:mySimpleType3">
        <xsd:enumeration value="-1"/>
        <xsd:enumeration value="0"/>
        <xsd:enumeration value="1"/>
        <xsd:enumeration value="true"/>
        <xsd:enumeration value="false"/>
      </xsd:restriction>
    </xsd:simpleType>

  </xsd:schema>

Since the literal value "1" and the literal value "false"
are not in the value space of mySimpleType2 nor in the value
space of negativeInteger, they would appear to be in
error. But a literal interpretation of the definition would
imply that mySimpleType3 is just a union of negativeInteger,
nonNegativeInteger, and boolean and hence "1" and "false"
are valid literals.
  
Isn't this quiet loss of explicit facet restrictions a
problem?
  
The Working Group discussed this at the telcons of April 10,
2003, and June 12, 2003.

At the latter, the WG classified this as an error to be
fixed in 1.1.  So this Bugzilla record sets 'version' to
1.1.
Received on Thursday, 8 September 2005 21:55:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:13:09 GMT