Note that the constraint is called "Conditional Type Substitutable in *Restriction*", but your example uses <extension>.

As we have observed in bug 6561, the "skip wildcard bringing in CDTT" aspect may not seem intuitive to some people, but we haven't identified a case where this behavior is "incoherent", instead of just "feels strange".

Closing this bug according to comment #1.

Note that the concerns raised in bug 6561 have been addressed by a proposal recently adopted by the schema WG. See bug 6561 for details.

(In reply to comment #2)
I think 3.4.4.5 "Conditional Type Substitutable in Restriction" deals with extension too, in spite of its title. Therefore the example presented seems to me appropriate.

The resolution of bug #6561 *seems* to fix the problem which the concrete example presented above poses. This is so because a skip wildcard is used. But after replacing it with a lax wildcard, we get these phenomena:

1. the element declaration of e2 is correct according to 3.8.6.3 (because it does not use type tables), but will yield any element instance invalid (because 3.4.4.5 does compare type definitions, in the absence of type tables)

2. if the local element declaration of b (or the global one) included a "redundant type table" stating the type definition as the default and not containing alternatives - then suddenly the element declaration of e2 would be inconsistent according to 3.8.6.3 part 2.

And now with the latest correction - xs:anyType does not create any context-determined type table - we get a further twist:

3. the example as presented above yields element instances invalid; but if we collapse the two steps of derivation into one, getting

  <xs:complexType name="t2">
    <xs:sequence>
      <xs:element name="a" type="xs:string"/>
      <xs:any processContents="lax"/>
      <xs:element name="b" type="xs:date"/>
    </xs:sequence>
  </xs:complexType>

I think the element instances that were found invalid (due to 3.4.4.5 Conditional Type Substitutable in Restriction) are again valid (clause 1: "if TB does not exist => constraint is satisfied"). 

So if *one* of the purposes of 3.4.4.5 was to disallow one element name to be associated with different types within a complex type, this purpose is sometimes met, sometimes not: it depends on how the matches (wildcard and element declaration) are distributed over derivation steps. So I think it is inappropriate to try let 3.4.4.5 do a job *beyond* safeguarding the consistency of proper type tables within derivation chains: better leave a job alone, than do it unreliably, occasionally, undermining the confidence in what is correct and what is not.

I suppose there is a general feeling that the present state of affairs is not quite as clear as one might wish. Perhaps there is just no real improvement in sight, and one should leave things as they are.

So I really do not know if the following proposal would be an improvement - but at any rate you might consider it as an option:

!
Change the definition of context-determined type table in such a way that an element does not have a CDTT unless it does contain a type table (that is, dropping clause 2.2)
!

Advantage: than the rules dedicated to safeguard the consistency of type tables (3.4.4.5 and 3.8.6.3) would be clear and without contradiction. The basic concept of consistent type tables would be: the elements in question must either all have compatible type tables - or all have no type tables.

Disadvantage: 3.4.4.5 would cease to help ensure that one element name cannot be associated with several types (in case concurrent element declaration and wildcard) within a complex type.

But, as I tried to point out, the disadvantage is perhaps an illusionary one, as the safeguarding function of 3.4.4.5 is unreliable. The proposal would reduce 3.4.4.5 to this purpose: safeguard the consistence of type tables within derivation chains.

> you might consider it as an option:
> ... (that is, dropping clause 2.2)

I think clause 2.2 is there to make sure the following works:

  <xs:complexType name="base">
    <xs:sequence>
      <xs:element name="a" type="xs:decimal">
        <xs:alternative test="1" type="xs:integer"/>
      </xs:element>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="restriction">
    <xs:complexContent>
      <xs:restriction base="base">
        <xs:sequence>
          <xs:element name="a" type="xs:int"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

For element "a", base assigns "xs:integer" and and restriction assigns "xs:int", it should be OK.

Without clause 2.2, T_T for "restriction" would be absent, and "Validation Rule: Conditional Type Substitutable in Restriction" would fail.

(In reply to comment #4)

Yes, you are right - therefore dropping clause 2.2 would have to be combined with a modification of 3.4.4.5 Conditional Type Substitutable in Restriction. This modification would distinguish the special case you pointed at - "B has a type table and T has not" - and use in this case instead of ST a T_T constructed "on the fly" from T.{type definition}, just as CDTT presently is always constructed. And in a similar way one would have to handle a second special case: "B has no type table but T has, and derivation mode is extension".

But one can get the same result in a much simpler way: 
a) leave the definition of CDTT as it is
b) add a special clause to 3.4.4.5 which states the constraint to be satisfied if neither B nor T has a type table. 

So please REPLACE THE PROPOSAL made in comment #3 by the following ...

Proposal:
====================================
Change 3.4.4.5 in the following way:
a) 
After "E and T satisfy this constraint if and only if one of the following is true", insert:
1. T.{type table} is absent, and B.{type table} is absent

b) 
Accordingly renumber the presently existing clauses, that is, increment their numbering by 1, to get:
2 Tb does not exist (i.e. E has no context-determined type table in B)
3 TT and TB both exist ...
etc.
====================================

Motivation:
====================================
1. The purpose of 3.4.4.5 - as stated in the Note immediately following it - would still be fully met
2. This side effect would be removed: erratically making instances invalid in cases where no type tables are involved.
====================================

Thank you for your comments and your interest in the XSD 1.1 spec.

The XML Schema WG discussed this issue at its telcon today.  I am sorry
to have to tell you that, while several members of the WG found the
proposal attractive in various ways, there was also some feeling in
the WG that a really full development of the idea would probably 
require more time than the WG has as its disposition (we are late in
delivering XSD 1.1 as a Candidate Recommendation), and runs a
fairly high risk of leading to results which are not compatible
with the fundamentals of the story the WG believes we are telling
about restriction.  I am not sure that the WG had consensus on
the proposition that we should do nothing here, but it was clear
that the WG did not have consensus to hold the progress of the
spec for this issue, and that developing a strong consensus either
way would not happen in the foreseeable future.

Accordingly we are resolving the issue with a disposition of LATER,
which means we recommend consideration of this idea to any
WG responsible for future versions of XSD.

Please let us know if you agree with this resolution of your
issue, by adding a comment to the issue record and changing the
Status of the issue to Closed. Or, if you do not agree with this
resolution, please add a comment explaining why. If you wish to
appeal the WG's decision to the Director, then also change the
Status of the record to Reopened. If you wish to record your
dissent, but do not wish to appeal the decision to the Director,
then change the Status of the record to Closed. If we do not hear
from you in the next ten days or so, we will assume you agree
with the WG decision.

(In reply to comment #6)

Thank you for your detailed explanation of how you came to your decision. From my point of view it is a pity, but I understand your hesitation. What also reconciles me with the outcome is the thought that a future fix is likely to make the language more tolerant, rather than stricter. So postponing the fix will not result in later breaking schemas which are valid now. Accordingly, I close this bug report.