This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the Microsoft SimpleType test set, test group stZ073b, the schema defines a type <xs:simpleType name="st.unionType"> <xs:restriction> <xs:simpleType> <xs:union memberTypes="xs:string xs:integer"/> </xs:simpleType> <xs:enumeration value="a"/> </xs:restriction> </xs:simpleType> Intuitively, the value "11" cannot appear as an instance of this type, and the test is therefore correct to reject it. However, the test actually has <test xsi:type="xs:integer"> 11 </test> Now in Type Derivation OK (Simple), rule 2.2.4 appears to say that xsi:type="xs:integer" is validly derived from st:unionType, because "B's {variety} is union and D is validly derived from a type definition in B's {member type definitions}." If this is the case, then the value 11 is validated against xs:integer and succeeds. This seems to be an error in the specification. Rule 2.2.4 should perhaps say "B's {variety} is union and B's {base type definition} is anySimpleType and D is validly derived from a type definition in B's {member type definitions}."
WG needs to clarify on what the behavior should be here.
Agreed, this is a known bug in the 1.0 spec, and the instance ought to be invalid: the question is whether it is possible to fix it without an excessive amount of disruption. As an alternative to the fix suggested in the bug, one could say that a member of a union is not validly derived from the union if the union has any facets. This is probably equivalent except in the case of a trivial restriction. Leaving this one as open, dependent on bug #5784 which has been raised against the 1.0 spec.
WG decided copy the test stz073B and mark the copy stable and 1.1 only. (Action to HT).
Copied to a 1.1-only stable test stZ073b, marked this as 1.0 only, left instance-test as disputed-spec but schema-test as stable