This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6167 - Attribute Wildcard Intersection
Summary: Attribute Wildcard Intersection
Status: RESOLVED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: 1.1 only
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2008-10-16 11:11 UTC by Michael Kay
Modified: 2008-10-24 17:24 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2008-10-16 11:11:29 UTC
In 3.10.6.4 Attribute Wildcard Intersection, the rules start:

The {variety} and {namespaces} of O are consistent with O being the wildcard intersection of O1 and O2 if and only if
1 O, O1, and O2 have the same {variety} and {namespaces}.
2 Either O1 or O2 has {variety} ...

It doesn't say whether "or" or "and" applies.

I think it should start:

The {variety} and {namespaces} of O are consistent with O being the wildcard intersection of O1 and O2 if and only if at least one of the following is true:
Comment 1 Michael Kay 2008-10-20 16:38:56 UTC
Another issue in this same area (which I hope I can also class as editorial, but please check it carefully).

Under Attribute Wildcard Intersection, second set of rules, rule 3,

3 The intersection of O1.{disallowed names} and O2.{disallowed names}.

I think "intersection" should be "union".

For if wildcard V allows all names in namespace N except A and B, while wildcard W allows all names in N except B and C, then the set of names allowed by both V and W is all names in N except A, B, and C.
Comment 2 Michael Kay 2008-10-20 17:02:59 UTC
Further to comment #1. I'm not sure I got that right. Rules 1 and 2 already give you {A, C} in my example. they don't give you B, because B is not allowed by either wildcard. So rules 1, 2, 3 between them are more-or-less constructing the union, which is the effect I wanted. Moreover rule 3 isn't confined to QName members of {disallowedNames} - it brings in "defined" and "definedSibling" where appropriate. Though that fits oddly with rule 4.

I can't really see why the whole set of 4 rules can't be replaced by "the union of O1.{disallowedName} and O2.{disallowedNames} retaining only those QNames whose URI is allowed by both O1 and O2 as defined in Wildcard allows Namespace Name (§3.10.4.3)" - which seems to me a lot clearer.

And frankly, I don't see the need for the "The {disallowed names} property of O is consistent with O being the wildcard intersection of O1 and O2" style either - it just seems a longwinded way of saying "O.{disallowedQNames} is the union of O1.{disallowedName} and O2.{disallowedNames}, retaining only those QNames whose URI is allowed by both O1 and O2 as defined in Wildcard allows Namespace Name (§3.10.4.3)"
Comment 3 Sandy Gao 2008-10-24 17:24:36 UTC
On 2008-10-24, the working group adopted a proposal to address this issue by
- Adding "one or more of the following is true" after "if and only if"
- Simplifyings rules around intersecting {disallowed names}:

1 QName members of O1.{disallowed names} whose namespace names are allowed by O2, as defined in Wildcard allows Namespace Name (§3.10.4.3).
2 QName members of O2.{disallowed names} whose namespace names are allowed by O1.
3 The keyword defined if it is a member of either {disallowed names}.


The proposal (along with changes for other bugs) can be found at (member-only):
http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni0810.html