W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2009

Re: [Bug 7787] New: Description of change to Element Declarations Consistent is confusing

From: Kevin Braun <kbraun@obj-sys.com>
Date: Mon, 05 Oct 2009 13:28:12 -0400
Message-ID: <4ACA2CAC.3030404@obj-sys.com>
To: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
CC: www-xml-schema-comments@w3.org

Unless I misunderstand it, the change to 3.8.6.3 is entirely about 
conditional type assignment, and not at all about dynamic EDC, while the 
way I read the change list implies that it is entirely about dynamic EDC.

I see I misread the change list on "Validation rules for conditional 
types", so disregard my comment on that.

So then, I would recommend something along the following lines (I may 
not have it quite right, but hopefully it illustrates what I'm getting at).

Replace:
"The constraint Element Declarations Consistent (§3.8.6.3) has been 
revised to
require more consistency in type assignment when elements with the same
expanded name may match both a local element declaration and a wildcard 
in the
same content model. XSD 1.0 allows such content models even if there is a
discrepancy between the type assigned to elements by the local element
declarations and by the top-level element declaration which will govern
elements which match the wildcard. For compatibility reasons, such content
models are still allowed, but any element instance which matches the 
wildcard
is required to have a governing type definition compatible with the type
assigned by the local element declarations matched by the element's 
expanded
name."

with something along the lines of:
"The constraint Locally Valid (Complex Type) (§3.4.4.2) 
<http://www.w3.org/TR/xmlschema11-1/#cvc-complex-type> has been revised 
to require type assignment consistency.
XSD 1.0 allows content models where elements with the same
expanded name may match both a local element declaration and a wildcard 
in the
same content model, even if there is a discrepancy between the type 
assigned to elements by the local element
declarations and by the top-level element declaration which will govern
elements which match the wildcard. For compatibility reasons, such content
models are still allowed.  However, Element Locally Valid (Complex Type) 
(§3.4.4.2) now requires that any element instance which matches the 
wildcard (at validation time)
has a governing type definition compatible with the type
assigned by the local element declarations matched by the element's 
expanded
name.

And then before the following bullet point:
"Validation rules for conditional types: a validation-time check on 
restrictions of complex types ensures that the conditionally assigned 
types of their children are appropriately related to the types assigned 
by their base type; see Element Locally Valid (Complex Type) (§3.4.4.2) 
<http://www.w3.org/TR/xmlschema11-1/#cvc-complex-type> and Conditional 
Type Substitutable (§3.4.4.5) 
<http://www.w3.org/TR/xmlschema11-1/#vr-cta-substitutable>; the 
definition of ·governing type definition· 
<http://www.w3.org/TR/xmlschema11-1/#key-governing-type-elem> is also 
adjusted"

add a bullet point similar to this one:
"The constraint Element Declarations Consistent (§3.8.6.3) 
<http://www.w3.org/TR/xmlschema11-1/#cvc-complex-type> has been modified 
to help ensure type consistency in a model group among the type tables 
of local element declarations and those global element declarations of 
the same expanded name which may be attributed to either wildcards or 
open content in the model group."

HTH,
Kevin

On 10/2/2009 10:27 PM, C. M. Sperberg-McQueen wrote:
> On 1 Oct 2009, at 13:32 , bugzilla@wiggum.w3.org wrote:
>
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7787
>>
>>           Summary: Description of change to Element Declarations 
>> Consistent
>>                    is confusing
>>           Product: XML Schema
>>           Version: 1.1 only
>>          Platform: PC
>>        OS/Version: Windows XP
>>            Status: NEW
>>          Severity: normal
>>          Priority: P2
>>         Component: Structures: XSD Part 1
>>        AssignedTo: David_E3@VERIFONE.com
>>        ReportedBy: kbraun@obj-sys.com
>>         QAContact: www-xml-schema-comments@w3.org
>>                CC: cmsmcq@blackmesatech.com
>>
>>
>> In the "changes since 1.0", we have the following description:
>>
>> "The constraint Element Declarations Consistent (§3.8.6.3) has been 
>> revised to
>> require more consistency in type assignment when elements with the same
>> expanded name may match both a local element declaration and a 
>> wildcard in the
>> same content model. XSD 1.0 allows such content models even if there 
>> is a
>> discrepancy between the type assigned to elements by the local element
>> declarations and by the top-level element declaration which will govern
>> elements which match the wildcard. For compatibility reasons, such 
>> content
>> models are still allowed, but any element instance which matches the 
>> wildcard
>> is required to have a governing type definition compatible with the type
>> assigned by the local element declarations matched by the element's 
>> expanded
>> name."
>>
>> This seems misleading to me.  From what I can tell, the "is required" 
>> of the
>> last sentence is not part of 3.8.6.3 (as implied), but is handled by 
>> step 5 of
>> 3.4.4.2 Element Locally Valid (Complex Type) (which I discovered 
>> thanks to the
>> discussion in bug 5940).
>
> The description attempts to record what seemed to the editor
> who drafted it the salient part of the change and the salient
> motivations for it.  The key concept in the change described
> here is the introduction of what the WG informally called at
> the time "dynamic EDC".  As you observe, the realization of
> dynamic EDC required changes to several other locations which
> define concepts appealed to directly and indirectly from the
> EDC rule.
>
> If you find the characterization misleading or unhelpful, then
> I regret that shortcoming in the description.  But in the final
> analysis, when drafting the description of changes I call 'em
> as I see 'em.
>
>> The change to 3.8.6.3 seems to focus on type consistency when 
>> conditional type
>> assignment is being used, but you'd never get that from the 
>> discussion above.
>
> There is plenty of mechanism related to conditional type assignment
> in 3.8.6.3, but it was introduced not as part of the shift to
> dynamic EDC but as part of the introduction of conditional type
> assignment.
>
>> 3.4.4.2 Element Locally Valid (Complex Type) is mentioned in the 
>> "changes
>> since" appendix when discussing validation rules for conditional 
>> types, while
>> 3.8.6.3 Element Declarations Consistent isn't mentioned.  Isn't that 
>> somewhat
>> backwards?  3.8.6.3 seems to be specifically targeted to conditional 
>> types,
>> while 3.4.4.2 aims for a more general type consistency.
>
> I won't claim to remember the exact thought processes that
> gave rise to the wording now in the document, but since
> 3.8.6.3 contains a static constraint on schemas, not a validation
> rule, I would find it strange if it were mentioned in a
> paragraph about changes to validation rules.  It may well be
> that other observers drafting a list of changes would choose
> to set different accents.  If you want a characterization
> of changes that does not depend on any individual's judgement,
> then you probably want to consult the diffed version with
> changes since 1.0.  It is not devoid of judgement calls, but
> they are less obtrusive.
>
> I hope this helps, but I don't see any obvious way to revise
> any of the text you have commented on here so as to improve
> things.
>
Received on Monday, 5 October 2009 17:30:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:13:17 GMT