This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Appendix M states: Two non-group particles overlap if ... They are both wildcards, and the {variety} of the wildcard intersection of their {namespace constraint}s as defined in Attribute Wildcard Intersection (§3.10.6.4) is not any and the {namespaces} of such intersection is not the empty set. This implies that the two particles <xs:any namespace="##any"/> <xs:any namespace="##any"/> do not overlap. Can't be right! I think it should say <quote> or * They are both wildcards, and the {variety} of the wildcard intersection of their {namespace constraint}s as defined in Attribute Wildcard Intersection (§3.10.6.4) is *any* or *not*. or * They are both wildcards, and the {variety} of the wildcard intersection of their {namespace constraint}s as defined in Attribute Wildcard Intersection (§3.10.6.4) is *enumeration* and the {namespaces} of such intersection is not the empty set. </quote> (This is assuming we continue to rely on wildcard intersection, which is problematic, as I'm not sure it's defined on element wildcards. An alternative would be to say simply <quote>They are both wildcards, and there is at least one URI that matches both wildcards as defined in Wildcard allows Namespace Name (§3.10.4.3)</quote>)
We discussed this issue at the ftf this morning. After some confusion and delay, we concluded that the analysis here is essentially correct. In the context of this appendix, however, we believed the intensional wording offered in the final paragraph of the description is not the right thing, and we converged on a variant of the first wording offered, namely: They are both wildcards, and one of the following is true of the wildcard intersection of their {namespace constraint}s as defined in Attribute Wildcard Intersection (§3.10.6.4): - it has {variety} = ANY - it has {variety} = NOT - it has {variety} = ENUMERATION {namespaces} != the empty set. There was some sentiment for reducing confusion by eliminating the word 'Attribute' from the name of the constraint being referred to. We also attempted to understand how the original error came about, but the only theory we arrived at was rather strained and involved (a) omission of an 'or', (b) bad formatting, and (c) substitution of an 'and' for an 'or'.
The change agreed upon during the face to face is included in the status-quo document of 31 October; accordingly I'm marking this RESOLVED. Michael, if you would indicate your concurrence with or dissent from the WG's disposition of the comment by closing or reopening the issue, we'll be grateful. If we don't hear from you in the next two weeks, we'll assume that silence implies consent.