This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The definition of governing element declaration seems to produce an odd effect. According to the rules, when there is no processor-stipulated decl, and no context-determined decl, but there is a locally declared type, the governing element declaration is absent. Consider this example: <xs:element name="elem1" type="xs:int" fixed="10"/> <xs:element name="elem2" type="xs:int" fixed="10"/> <xs:element name="root" type="OddBall"/> <xs:complexType name="OddBall"> <xs:sequence> <xs:element name="elem1" type="xs:int"/> <xs:any/> <xs:any/> </xs:sequence> </xs:complexType> And consider this instance: <root> <elem1>5</elem1> <elem1>9</elem1> <elem2>10</elem2> </root> The second elem1 is attributed to a strict wildcard; it does not have a context-determined declaration. It does have a locally declared type, the local elem1 declaration. The result is that elem1 does not have a governing declaration, and it not required to meet the fixed value constraint. However, elem2 is in a fairly parallel situation, but it will have a governing element declaration and elem2's fixed value will apply. Perhaps I have missed something, but this seems quite odd to me. I can't quite make out why 3.3 in the definition of governing element declaration is there. Also, it looks like this is different behavior from XSD 1.0.
Thank you for the comment. At the moment, I too am puzzled by clause 3.3 of the definition of governing element declaration. (I'm also puzzled by 3.2.) The WG will have to examine this carefully before deciding what to do.
On the telcon (see the minutes) MSM: concrete proposal: a) remove clause 3.3 and b) allow editors some time to make sure such change doesn't break something we tried to fix with this clause. and then MSM: Propose to still delete 3.3 and try to find a different to allow falling back to the local type when the content is invalid.
A wording proposal intended to resolve this issue is now on the server at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b7913.html (member-only link) The proposal does two things. First, as requested by the WG it introduces the variable E to provide a name for the element instance whose governing element declaration is being defined, similar in effect to the E used by the definition of governing type definition immediately following. Second, it inserts a new rule three in front of the old one (which now becomes rule 4): 3 A declaration ·resolved· to by E's [local name] and [namespace name], provided that E is ·attributed· either to a strict ·wildcard particle· or to a lax ·wildcard particle·. This has the effect that when an element instance is attributed to a wildcard, it gets the appropriate global element declaration. And the effect originally aimed at by clause 3.3 (now 4.3) is retained: when the element is not attributed to a wildcard at all (because its parent is invalid and we are in a fallback mode, trying to get what information we can out of things), it uses a locally declared type if there is one.
The wording proposal mentioned in comment 3 was approved by the XML Schema working group on its call today and has been integrated into the status-quo documents. Accordingly I'm marking this issue resolved. Kevin Braun, it would be helpful if you, as the originator of the issue report, would indicate by closing the issue that you are satisfied with the WG's consideration and resolution of the issue, or by reopening it indicate that you are dissatisfied (and explain why). If we don't hear from you in the next two weeks on this question, we will assume you are satisfied. (I am assuming that the description of the change given in comment 3 suffices for your review; if you need more detail let me know.)
Sounds good.