This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2044 - R-198: ensure that unions of unions retain union-level facets
Summary: R-198: ensure that unions of unions retain union-level facets
Status: CLOSED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Datatypes: XSD Part 2 (show other bugs)
Version: 1.1 only
Hardware: PC Linux
: P2 critical
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL: http://www.w3.org/2001/05/xmlschema-r...
Whiteboard:
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2005-09-08 21:55 UTC by C. M. Sperberg-McQueen
Modified: 2008-03-08 14:49 UTC (History)
0 users

See Also:


Attachments

Description C. M. Sperberg-McQueen 2005-09-08 21:55:51 UTC
[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.
Comment 1 C. M. Sperberg-McQueen 2005-09-08 22:01:45 UTC
The Working Group discussed this issue at our face to face 
meeting in May 2005, and agreed that the correct thing to do 
was to change the structure of unions:  instead of the members 
of a union being only atomic and list types, unions should be 
allowed to be members of unions.  The 1.0 spec describes a
'flattening process' by which unions declared as having other 
unions as members actually got the members of those unions 
as members.  That flattening should be eliminated.

The Datatypes editors were instructed to prepare phase-2
wording to resolve this issue.

In the belief that this is to be treated as a requirement, not
a desideratum, I've given this report a Severity of 'critical'.
Comment 2 C. M. Sperberg-McQueen 2005-10-08 14:05:11 UTC
The related work required in Structures is to be tracked using
Bug 2333.
Comment 3 C. M. Sperberg-McQueen 2006-01-28 18:18:22 UTC
On 27 January 2006, the Working Group considered and adopted a 
proposal to resolve this issue by allowing union datatypes
to be members of union datatypes, thus eliminating the 
flattening of unions required in 1.0.  The WG instructed the
editors to add editorial notes requesting priority feedback from
implementors and users; the changes were incorporated into
the status quo documents, with a draft version of the feedback 
requests, on 27 January 2006. 
Comment 4 C. M. Sperberg-McQueen 2008-03-08 14:49:52 UTC
In the course of routine housekeeping and cleanup, I've come across this
item.  It's not clear from the record here, nor from the one in the old
'Recommendation Comments' issue list, what member of the Working Group 
received the private communication from Ed Merks which gave rise to this
issue.  So it appears unlikely that we are able to communicate with him 
directly to ask that he review the resolution of the issue and indicate his
satisfaction or dissatisfaction with the outcome.

Since however the changes adopted to Structures and Datatypes for this 
issue do resolve the problem he identified, I'm going to mark this bug as
closed, on his behalf.  (If any reader of these words actually has the 
ability to get in touch with Ed Merks, I hope that they will call his 
attention to this bug record in Bugzilla and ask that he review the 
changes to the specs.  But in the meantime, we'll hope for the best.)