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 placement of co-constraints (aka type alternatives) in the element declaration components instead if within type definitions seems to be an ineffective end run around the derivation constraints of the type hierarchy. "Ineffective" because elements declarations are also subject to derivation constraints via substitution groups. See bug 5079. Assume derivation constraints must be dealt with, why not put the co-constraints in the type? Then they could be more readily shared by different elements. How to put co-constraints into type definitions? The mechanism could be switching from the current type alternatives to content model alternatives. Or there could be a new content type for constrained types. For instance, <xs:complexType name="message" base="messageTypeAny"> <xs:alternativeContent> <xs:alternative test="@kind='string' type="messageTypeString"/> <xs:alternative test="@kind='base64' type="messageTypeBase64"/> <xs:alternative test="@kind='binary' type="messageTypeBase64"/> <xs:alternative test="@kind='xml' type="messageTypeXML"/> <xs:alternative test="@kind='XML' type="messageTypeXML"/> </xs:alternativeContent> </xs:complexType> How about those derivation constraints? Now they can't be avoided. It's impractical, if not impossible, to determine if one general XPath test subsumes another, but very constrained derivations could be allowed. For instance, each content alternative type must be a restriction of the base type and if the base type has alternatives, then each derived alternative must be a restriction of its *corresponding* base alternative. Alternatives *correspond* if the base test is "A" and the derived test is "A" or "A and B". If a derived test doesn't match a base test in that way, then it *corresponds* to the default alternative in the base.
This is an interesting idea, but it makes me very nervous. It seems to invite the construction of logical circularities we can't promise to detect or require implementations to detect, and we have advice from computer scientists who have looked at it whose comments can be summarized roughly as "Do not go here; there are dragons." The existing design is not in fact an end run around restriction constraints; there is a (rather elaborate) set of rules to ensure that the type selected for any element E in the context of a complex type B and the type selected for E in a type R which restricts T are in a suitable restriction relation. So my recommendation is that the Working Group close this regretefuly as INVALID.
The WG considered this item and has decided to mark it as INVALID. Note that we had previously (during original discussions) considered the possibility this issue represents. Thanks very much for the input, however. Boilerplate follows... Please let us know if you agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.
This comment is dependent on bug 5079, which was resolved as WORKSFORME. In that context I accept the resolution.