This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In "3.2.4.2 Governing Attribute Declaration and Governing Type Definition" 1. Clause 3 has "provided the attribute is not ·attributed· to a skip ·wildcard particle·". But attributes don't match particles. Should use the definition of "skipped". 2. At the end of the first definition: "If the attribute is ·attributed· to a skip ·wildcard particle· or if the processor has stipulated a type definition, then it has no ·governing· declaration." To avoid the repetition and to make it consistent with other similar definitions, should probably say "If none of these applies, the attribute has no ·governing attribute declaration· (or, in equivalent words, the ·governing attribute declaration· is ·absent·)." 3. It's not clear what the "governing type definition" should be when there is neither a declaration nor a stipulated type. To follow the similar definition for elements, may want: "the first of the following which applies: 1 A type definition stipulated by the processor (see Assessing Schema-Validity (§5.2)). 2 The {type definition} of the ·governing attribute declaration· If neither of these applies, there is no ·governing type definition· (or, in equivalent words, it is ·absent·). In "3.3.4.6 Schema-Validity Assessment (Element)" 4. For both occurrences, "If none of these apply" should be "If none of these applies". 5. Clause 4.1 reads "4.1 E is ·attributed· to a skip ·wildcard particle·". This does not cover the case where E's parent is skipped. Should say "4.1 E is ·skipped·".
<rant> It seems to me that the clause 3 is clear on the case in question. If there is no governing attribute declaration and no stipulation by the caller, then the there is no {type definition} around, so the attribute can have no governing type definition. The only way I can think of to be uncertain about that is to be afraid to make any inferences on the basis of what the spec says, because one is not certain that the spec is ever willing to accept the implications of its statements. Attempting to state every implication explicitly seems to encourage that fear. ("They must not mean that implication, since they didn't state it explicitly, whereas over there they did ...") Admittedly, the XSD spec has a history of problems with clarity and with being willing to accept the implications of its statements. In the long run, the solution is to make it safer to reason about the spec by cleaning it up, not to encourage the habit of fear. </rant> On the other points, I'm in agreement. And even on clause 3, while I think the change is not necessary I also agree that it does no direct harm, only the indirect harm of encouraging the view that it's the spec's job to state every possible implication of its definitions explicitly.
The WG has not agreed that this is a bug, much less instructed the editors in how to resolve it, but the editors have reached agreement on a wording proposal intended to resolve this issue; it is at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b12259.html I'm marking this issue with both the needsAgreement and needsReview keywords, to indicate both that the WG needs to discuss the issue and that there is a proposal ready for adoption.
RESOLUTION: adopt the proposal in comment #2
Fixed in status quo.