This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The specification currently states that an AtomicOrUnionType must be an atomic or union type in the in-scope schema definitions. If the type is a union type derived by restriction from another union type, then the rules ensure that no instance will ever satisfy this ItemType (because it would require testing the item against the restriction facets). Therefore, it would be better not to allow such union types to appear here. Proposal: we should say that the AtomicOrUnionType must be either an atomic type, or an "unrestricted union type", where an "unrestricted union type" is a type of variety union whose member types are all either atomic types or unrestricted union types.
Note, the proposed rule also disallows unions of list types, which is also a good thing since no XDM instance will ever satisfy such a type.
Looking at this again, bug #12626 reminds me that it may be unwise to use the phrase "whose member types..." without qualification. Also, to align fully with "Schema Component Constraint: Type Derivation OK (Simple)", we should allow unions that are derived from other unions by a trivial restriction (one that involves no constraining facets) - this case isn't very important, but we might as well handle it the same way that XSD 1.1 does. Revised formulation: <quote> the type named by an _AtomicOrUnionType_ must either be an atomic type, or an *unrestricted union type*. An *unrestricted union type* is a type whose {variety} is _union_, whose {facets} property is empty, and whose {member type definitions} consists exclusively of atomic types and *unrestricted union types*. Note: the definition of *unrestricted union type* excludes union types derived by non-trivial restriction from other union types, as well as union types that include list types in their membership. Unrestricted union types have the property that every instance of an atomic type defined as one of the member types of the union is also a valid instance of the union type. </quote>
The Working Group agrees. I will make this change.
(In reply to comment #2) > *unrestricted union type* One of the changes you suggest is to go back to a term that we earlier rejected. An "unrestricted union type" in this definition has restrictions: it excludes union types derived by non-trivial restriction from other union types, as well as union types that include list types in their membership. The current document uses the term "generalized atomic type", because it is more general than atomic types. I suppose "restricted union type" also makes sense. I don't think going back to "unrestricted union type" for a restricted union type is an improvement.
While integrating this, I ran into some other questions. 1. Is there a difference between this set of types: all simple types whose {variety} is union, provided they satisfy all the following conditions: the {facets} property of the union type is empty; and no type in the transitive membership of the union type has {variety} list; and no type in the transitive membership of the union type is a type with {variety} union having a non-empty {facets} property And this set of types? a type whose {variety} is _union_, whose {facets} property is empty, and whose {member type definitions} consists exclusively of atomic types and *restricted union types*. 2. In the current document, we use the term [generalized atomic type] in many places, not just here, and it refers to either an atomic type or a "restricted union type". If there *is* a difference between the sets of types in (1) above, do we really need to have both definitions? And which definition applies in the various places where we currently reference *generalized atomic type*?
We decided that the two definitions are probably equivalent. We also decided "restricted" is ambiguous in this terminology, as is "urestricted" - looking for a better term.