This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 3.10.4.2 starts: Validation Rule: Wildcard allows Expanded Name For an expanded name E, i.e. a (namespace name, local name) pair, to be ·valid· with respect to a namespace constraint C which appears as the value of a {namespace constraint} belonging to a wildcard W, all of the following must be true: It would be reasonable for a reader to therefore assume that this rule is defining a boolean function whose inputs are a wildcard W and an expanded name E. But more careful reading shows that this is not the case. Rule 4.3 introduces: "The item having E as its name is an element information item (call it I) " This means that the question of whether a wildcard allows an expanded name also depends on what item you happen to be validating at the time. The rule as written is therefore very misleading.
WG agrees that we should make a best effort to resolve this editorial issue if possible.
I took an action to propose wording for this. After struggling for a bit, I think the effect can be achieved by moving the relevant rule from 3.10.4.2 to 3.10.4.1. 1. In 3.10.4.2 "Wildcard allows expanded Name", delete rule 4. This means that the condition depends only on the wildcard and the name, and not on any context. 2. In 3.10.4.1, "Item valid (wildcard)", change the rules to: For an element or attribute information item I to be locally ·valid· with respect to a Wildcard W all the following conditions must be true: (1) The expanded name of I must be ·valid· with respect to W.{namespace constraint}, as defined in Wildcard allows Expanded Name (§3.10.4.2). (2) If all of the following are true: 4.1 W.{namespace constraint}.{disallowed names} contains the keyword sibling; 4.2 W is an element wildcard 4.3 I is an element information item 4.4 I has a [parent] P that is also an element information item 4.5 I and P have the same [validation context] 4.6 P has a ·governing type definition· T (which is always a complex type and contains W in its ·content model·) then E does not ·match· any element declaration ·contained· in the content model of T, whether ·directly·, ·indirectly·, or ·implicitly·. 3. The effect of the above changes is to move the effect of "sibling" from "Wildcard allows expanded name" (WAEN) to "Item valid (Wildcard)" (IVW). So we need to look at places where WAEN is invoked other than via IVW. There are two such places. - Wildcard subset. I believe here the change proposed above is beneficial. Wildcard subset needs to look at two wildcards in a context-independent way. There is no "item having E as its name" in this situation. - Attribute wildcard union. The same is true, but it doesn't matter anyway, since we are only concerned here with attribute wildcards. Michael Kay
A proposal intended to resolve this issue is at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6159.html (member-only link)
6159: Wildcard allows element name Summary: recast rules for wildcards to make them fit their names better, and be clearer. SG has found some places that would be affected by the changes we were considering. We discussed a proposal in the call of 10 April but did not reach consensus. MSM's recommendation: approve as shipped. (Cautiously in favor.) Adopt, with option to reopen next week.
During its 2009-04-17 telecon, the schema WG adopted the proposal in comment #3 to address this issue. With these changes, the WG believes that the issue raised in this bug report is addressed. I'm marking this RESOLVED accordingly. 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.