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

[Bug 5940] Element Declarations Consistent

From: <bugzilla@wiggum.w3.org>
Date: Sat, 01 Nov 2008 05:09:11 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1Kw8jX-0002Zn-Pq@farnsworth.w3.org>


--- Comment #6 from C. M. Sperberg-McQueen <cmsmcq@w3.org>  2008-11-01 05:09:11 ---
Re:  "Logically, I think they *should* be the same" ...

I think some (at least) in the WG agree with you that in principle
an element declaration without a type table and one with a type table
providing only a single alternative ought to be treated the same way.
Speaking for myself and not for the WG as a whole, I justify the current
design in the following way:  other things being equal, the stricter rule
applied to type tables ought also to be applied to declared types.  But
owing to a bug in XSD 1.0, that stricter rule was not applied by 1.0;
applying it now would at least potentially invalidate existing schemas.
Some in the WG might be willing to do that, since the 1.0 rule is clearly
broken, but the WG as a whole was not willing to make such a change.
The result is that for element declarations without a type table, XSD 1.1 is
bug-compatible with 1.0 here.  

Since type tables don't appear in 1.0, there is no bug-compatibility argument
for not defining the rule properly for them, and so their treatment was
defined using the stricter rule.

Re: dynamic EDC

The term 'dynamic EDC', used sometimes in WG discussions, though probably not
in any public documents, denotes the process of checking that siblings with
the same name have either the same type, or types substitutable for the
locally declared type.  In principle, this is checkable statically, on the
basis of the schema in isolation, but for the reasons outlined above XSD 1.1
does not prescribe a static check.  Instead, the schema fragment given in
comment 0 is allowed as a schema, but any instance in which a tns:X 
element instance matches the wildcard (and would thus be governed by the
global element declaration and by type xsd:date) violates the Element
Locally Valid (Complex Type) constraint and is invalid.  The work of 
dynamic consistency checking of type assignments with the types which 
would be assigned to potential siblings is done in clause 5 of the 
validation rule Element Locally Valid (Complex Type).

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Saturday, 1 November 2008 05:09:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:12 UTC