- From: <bugzilla@wiggum.w3.org>
- Date: Sat, 01 Nov 2008 05:09:11 +0000
- To: www-xml-schema-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5940 --- 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