This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
QT approved comment: In 2.6.1, I don't think it's correct to say that the lexical mapping for a union is the union of the lexical mappings of its member types. Rather, the lexical mappings are combined using an algorithm that treats the member types as ordered so as to disambiguate the mapping.
Thank you for the comment. I believe it's a question of choice. At least, I believe that the desired behaviors can be modeled in at least two ways. One is the way you describe: mappings of union types are created with a sequence of set overlays, xsi:type modifies the mapping, or perhaps specifies a different one entirely, but is restricted to the mapping of one of the member types, and so on with whatever changes that way of describing things would entail. The other is the way we chose (and have endeavored, with imperfect success, to make clearer in the spec): the mapping of a union type is the union of the mappings of the members. When for practical reasons one wants to have a unique value rather than a set of values (as, for example, when validating), one can apply some appropriate set of rules to choose the appropriate value. In the case of schema-validity assessment, the rule is to consult the order of the types in the union, unless xsi:type tells you to choose a different value. In the case of anySimpleType, which is the *unordered* union of all simple types, one may wish to use rules like the type coercion rules of XSLT 2.0 and XQuery. As that last example hints, the XML Schema WG believes that the union-as-union approach gives a better story for explaining why the QT rules for anySimpleType (under the relabeling 'untypedAtomic') are actually OK and not something to object to. All that said, the comment suggests that some, at least, of the exposition could usefully be revised. I'm marking the issue as editorial for that reason.
Bug 3025 subsumes this bug, so I'm closing this one as a duplicate of bug 3025. *** This bug has been marked as a duplicate of bug 3025 ***