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: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
Date: Fri, 2 Oct 2009 20:27:21 -0600
Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, Kevin Braun <kbraun@obj-sys.com>
Message-Id: <9D3EAE28-558A-4C47-ABA8-25AB50D83740@blackmesatech.com>
To: www-xml-schema-comments@w3.org
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 ( 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 (as implied), but is handled by  
> step 5 of
> 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 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, but it was introduced not as part of the shift to
dynamic EDC but as part of the introduction of conditional type

> Element Locally Valid (Complex Type) is mentioned in the  
> "changes
> since" appendix when discussing validation rules for conditional  
> types, while
> Element Declarations Consistent isn't mentioned.  Isn't that  
> somewhat
> backwards? seems to be specifically targeted to conditional  
> types,
> while 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 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

* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
Received on Saturday, 3 October 2009 02:27:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:10 UTC