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: Thu, 30 Oct 2008 18:50:56 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1Kvcbg-0006AQ-VC@farnsworth.w3.org>


C. M. Sperberg-McQueen <cmsmcq@w3.org> changed:

           What    |Removed                     |Added
           Keywords|needsAgreement              |needsDrafting

--- Comment #4 from C. M. Sperberg-McQueen <cmsmcq@w3.org>  2008-10-30 18:50:56 ---
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

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 Thursday, 30 October 2008 18:51:10 UTC

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