This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In section 3.8.6.3 we read: <quote> If the {particles} property contains, either directly, indirectly (that is, within the {particles} property of a contained model group, recursively), or ·implicitly·, both one or more element declarations with the same expanded name and one or more ·wildcard particles· which ·match· the same expanded name as the element declarations, then the {type table}s of the element declarations and the {type table} of any top-level element declaration with the same expanded name must either all be ·absent· or else all be present and have the same sequence of {alternatives} and the same {default type definition}. </quote> Firstly, this seems to be a new rule added since 1.0, and it appears to introduce a backwards incompatibility. Secondly, it's not clear what it achieves. It means that with a strict wildcard, an element <a> that matches an explicit element particle will always get the same type as an element <a> that matches the wildcard. But the rule also applies to lax and skip wildcards, and they offer no such guarantee. It seems that despite "Element Declarations Consistent", XML Schema 1.0 allowed a content model of the form <xs:element name="X" type="xs:integer"/> <xs:any namespace="##local" processContents="strict"/> with the global element declaration for X having type="xs:date"; and this is now being disallowed.
One other point on this (which is how I arrived here in the first place): it seems pointless to have such a rule that applies to wildcards appearing within the particles if it does not also apply to a wildcard appearing as part of the open content.
Strictly speaking, the WG has not classified this issue; the editors are marking it as needsAgreement because we think doing so will save time later. When the WG deals with this issue, all of the moves legitimate for an unclassified issue are also in order for this issue.
Another observation regarding Element Declarations Consistent. I think one of the objectives of this constraint is to make static type inferencing possible: if you has an element E of type T, and you are looking for a child of E called FOO, then you know what type FOO will be by examination of type T. But there is yet another situation that prevents such an inference: you can have two independent types P and Q that both extend B, and that both introduce new element particles called FOO, but that give FOO different types. So I wonder if the time has come to review whether EDC actually achieves anything useful at all?
The XML Schema WG discussed this issue at some length today during our ftf meeting, with varying results. 1) Yes, the rule cited in the description is new in 1.1. 2) No, it doesn't introduce a compatibility issue (as far as we can see): it constrains type tables, and 1.0 schemas don't have type tables. 3) The schema fragment given in the description is not disallowed by 1.1 (the rule cited only covers element declarations with type tables, not others); if any element named X matches the wildcard in the content model, the parent element won't be locally valid (this is what the WG internally sometimes refers to as the 'dynamic EDC' check). 4) After long discussion and with some misgivings on the part of some, we agreed to exclude 'skip' wildcards from the EDC rule cited. That helps make the case with type tables more closely analogous to the case without type tables: both now require that if siblings in the instance can be bound one to a top-level element declaration and one to a local element declaration, then they have compatible types, and both effectively exclude elements bound to skip wildcards, since those elements will have no governing element declarations. 5) The point in comment 1 is well taken; the EDC rule will be recast to capture wildcards in applicable open content. 6) The first formulation in comment 3 is over-broad: the effect of EDC has only ever been to guarantee that in a particular context, any type governing an element instance will be either the type discoverable by inspection of the schema (as described in the comment) or a type substitutable for it. In the example given, if the common base type B has no FOO elements, then the type assigned to FOO by P and that assigned by Q will both be subsitutable for xsd:anyType. The WG having reached phase-1 agreement on this issue, I'm marking it needsDrafting.
Re: Points (2) and (3) in comment #4 I had missed that an element declaration with no {type table} is treated differently from an element declaration whose {type table} allows only one alternative. My implementation will have to change, it treats both cases the same. Logically, I think they *should* be the same, but so be it... In point (3). "if any element named X matches the wildcard in the content model, the parent element won't be locally valid (this is what the WG internally sometimes refers to as the 'dynamic EDC' check)." - I haven't come across the term "dynamic EDC", can you point me to the actual rule in the spec?
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).
>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). Thanks. I've now sussed out how that works. Mind-blowing, I need a very strong drink to recover. That leaves the question: is there an equivalent rule in XSD 1.0 that would make the content <X>3<X><X>2008-11-01</X> invalid against this content model, or have we introduced an incompatibility? (And the secondary question, if it was allowed in 1.0, and no-one complained, then who benefits from the introduction of this amazingly complex machinery designed to make it invalid in 1.1?)
W.r.t. comment 7, my understanding (without having refreshed my memory by rereading all the relevant parts of the spec or all the relevant issue reports) is that there is no rule that makes the example illegal in 1.0, and that the absence of such a rule causes 1.0 to allow restrictions which accept instances rejected by the base type. The fix is too large a change to introduce in an erratum, so the WG put the fix into 1.1. Some of the earlier discussion may be seen at bug 2544.
The WG decided to accept the proposal at: http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b5940.html ammended as follows -- <MSM> Proposal: For "1 The {particles} property contains (either directly, indirectly, <MSM> or ·implicitly·) one or more element declarations with the same <MSM> expanded name Q." <MSM> read "1 The {particles} property contains (either directly, <MSM> indirectly, or ·implicitly·) one or more element declarations with the <MSM> same expanded name Q; call these element declarations EDs." <MSM> For "contained in the {particles}" read "EDs"