This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
[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.
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'.
The related work required in Structures is to be tracked using Bug 2333.
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.
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.)