This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(1) The Note: Note: If a wildcard union is inexpressible, any rule requiring that one Namespace Constraint be that union cannot be satisfied. is unnecessary, because there is no such rule. (2) The final paragraph is unnecessary, because there is nowhere in the spec that takes a wildcard union with more than two Namespace Constraints as operands. (Wildcard union is used only when one type T is derived by extension from another type B, and this involves only two wildcards.) (3) Rule 4 in the final list is structurally misplaced. Given that the definition has adopted the style "O is the union of O1 and O2 if and only if...", the notion that the union of O1 and O2 might not exist cannot logically be part of this definition. I would move it right up to the front, and then qualify the rest by "If the union of O1 and O2 is expressible, then O is the union of O1 and O2 if and only if..." (4) Finally, and more substantively, I'm having trouble seeing why the wildcard union should be inexpressible in the circumstances stated, or indeed in any circumstances. The union, surely, should match everything that is matched either by one wildcard or by the other or by both. The union could be defined either extensionally (treating "defined" as simply a synonym for the list of names of global attribute declarations present in the schema), or intensionally (if one wildcard excludes "defined" attributes and the other does not, then the union does not exclude "defined" attributes).
Further to (4): the only place that relies on forming a wildcard union is in derivation by extension, and this states that when T is derived by extension from B, and the union of their wildcards is inexpressible, then the derived type uses the wildcard as defined on T. So, in the circumstances where the union of B|T is currently inexpressible, the union is effectively taken as T. Now that's not a very nice rule; one would like union to be commutative. It seems to me that it would be much nicer and simpler to drop rule 4, so that the union is always expressible and always commutative.
More thoughts on (4). I see now why (for example) the union of <xs:anyAttribute notQName="##defined" id="P"/> and <xs:anyAttribute namespace="##local" id="Q"/> is inexpressible: there is no way to express a wildcard that allows all attributes in the *absent* namespace plus all attributes other than globally declared attributes in other namespaces. But consider the consequences. Wildcard union is used in only one place: where types are derived by extension. In this situation, if the base type is defined with wildcard P, and the extension type is defined with wildcard Q, then the actual complex type component will have wildcard Q. This hardly reflects the intent of type extension, whereby the extended type should allow everything the base type allows and more. From this perspective it would be better to combine the wildcards as: <xs:anyAttribute/> That is, the result of the union should be the "smallest expressible wildcard that has the true union as a subset", which can be constructed simply by dropping the notQName="##defined" constraint unless it is present on both wildcards. Note that there is no compatibility issue with 1.0 in making this change. Although 1.0 had the same rule about how inexpressible wildcards were handled during type extension, all unions of 1.0 wildcards are expressible in 1.1; the only inexpressible wildcards in 1.1 arise when ##defined is used (which is a symptom of the lack of orthogonality in the design of this feature, but let that pass).
The WG discussed this issue in today's ftf. We adopted a wording proposal which addresses most though not all of the concerns expressed: (1) the Note is deleted. (2) the reference to multiple wildcards is retained (on the view that it does not harm) (3) rule 4 is gone. (4) the proposal to make the union rule calculate a small expressible superset is adopted. We note in passing that we have not actually proven that this is the smallest expressible subset, but it is easy to calculate and understand, and it's not obviously larger than the smallest expressible superset. Fuller details of the proposal adopted will be posted either to the IG list or to this bug report when doing so is more convenient than it is at the moment. Accordingly, I'm marking this as decided; we'll close it when the change has been integrated into the status-quo document.
A further observation (which doesn't directly affect the resolution in comment #3). In comment #2 I observed that when type E extends type B, and the wildcard union is inexpressible, then under 3.4.2.5 rule 2.2.2.4, the {attribute wildcard} of the extended type is that defined in the xs:extension. However, this will almost certainly mean that the resulting type does not meet Derivation Valid: Extension, under 3.4.6.2 rule 1.3. So although the rules apparently recover from an inexpressible union wildcard, it seems that the attempt to recover will generally fail. Under the proposal of comment #3, the union will not only be expressible, but will also satisfy rule 1.3 which requires that the wildcard of the base type is a wildcard subset of the union.
The resolution of this issue has been incorporated into the status-quo document generated during the face to face meeting in Redmond. So I'm marking this issue RESOLVED. Michael, as the originator, would you please indicate by closing or reopening the issue whether you are satisfied with the disposition of the comment? If we don't hear from you in the next two weeks, we'll assume you're happy.
The resolution is fine in principle, but there's some copy-editing needed on the text. In 3.10.6.3: When one of the wildcard has defined in {disallowed names} and the other does not, then defined is not included in the union. This may allow QNames that was not allowed by either wiledcar. This is to ensure that all unions are expressible. If defined is intended to be included, then it is necessary to have it in both wildcards. should read (see asterisked words) When one of the *wildcards* has defined in {disallowed names} and the other does not, then defined is not included in the union. This may allow QNames that *are* not allowed by either *wildcard*. This is to ensure that all unions are expressible. If defined is intended to be included, then it is necessary to have it in both wildcards.