7913 2009-10-13 21:16:32 +0000 Strange result from definition of governing element declaration 2009-11-03 19:06:00 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.1 only PC Windows XP CLOSED FIXED resolved P2 normal --- 1 kbraun David_E3 cmsmcq www-xml-schema-comments oldest_to_newest 28321 0 kbraun 2009-10-13 21:16:32 +0000 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. 28358 1 cmsmcq 2009-10-14 20:43:28 +0000 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. 28403 2 David_E3 2009-10-16 16:22:26 +0000 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. 29205 3 cmsmcq 2009-10-29 21:39:31 +0000 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. 29235 4 cmsmcq 2009-10-30 21:06:07 +0000 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.) 29267 5 kbraun 2009-11-03 19:06:00 +0000 Sounds good.