Clause 1.2 in 3.4.4.1 may apply for xs:anyType (remember that anyType has a lax wildcard), in which case clause 3 doesn't apply, and E could have a context-determined typed table within anyType.

But clause 1.2 seems to have the unfortunate issue that it applies even for skip wildcards, which may not be intentional.

The WG discussed, and agrees that Sandy's analysis in commnt 1 is correct.
The WG could not agree on whether to change clause 1.2 by excluding skip wildcards, however.
The WG decided to close this bug as LATER, based on Sandy's analysis, and internal lack of consensus on how to do better.

Some new information to consider.

In section 3.4.4.1 where "context-determined type table" is defined, we have the following note:

"Note: The constraint Element Declarations Consistent (§3.8.6.3)  ensures that even if E ·matches· more than one such declaration D, there will be just one ·context-determined type table·."

If we jump to EDC in 3.8.6.3, you can see that bullet 2.1 only considers strict and lax wildcards.

So now we have a contradiction: EDC doesn't guarantee consistency for type tables when skip wildcards are involved, but CDTT definition depends on that.

Somewhat repeating what was said earlier: the whole 1.0 spec and the rest of 1.1 spec were written with the view that if an element/attribute information itme matches a "skip" wildcard, then no additional constraints are imposed on top of "well-formed XML". Why should CDTT be treated differently?

Whether we make this "skip" change or not, consider:

<schema ...>
  <element name="table" type="htmlTable">
    <alternative .../>
    <alternative .../>
  </element>

  <complexType ...>
    <sequence>
      <element name="table" type="furnitureTable"/>

It's almost guaranteed that the complex type would not have a valid instance, because we will apply the type table from the global element declaration to instances of the local one.

This seems to limit the usefulness of type alternatives.

Note that in complex type restriction, we made derivation from xs:anyType magical (clause 2.1 in "Derivation Valid (Restriction, Complex)"). To be consistent with that, maybe anyType really shouldn't provide any CDTT as suggested by the original bug report? (CDTT is only used in complex type restriction.)

In comment #3, Sandy Gao writes:

    So now we have a contradiction

Can you expound the contradiction a bit further?  I am not seeing
a clear contradiction here.

I think you are saying that we can construct a schema in which a
given element instance has more than one context-determined type
table.  If this is true, I think we do have a problem.  Is there
an example schema that illustrates the problem?  It's not clear
to me that such a schema can be constructed.

Created attachment 636 [details]
Alloy model of contextual determination of type table

A further note here on the quest for an example in which there is
a type which for which the mapping from QNames (or element
instances) to context-determined type tables is not a function.
I continue unable to construct such an example.

I attach an Alloy model of this part of the spec.  I have used
this model to try to findt a schema in which there is some
complex type which does not uniquely determine a
context-determined type table for each possible QName.  The Alloy
Analyzer has searched all models with seven or fewer complex
types and seven or fewer element declarations, without finding a
case of a context-determined type table which is not uniquely
determined.

While it is suggestive, Alloy's failure to find a counter-example
is not, of course, conclusive.  There may be counter-examples in
larger schemas.  Or the Alloy model could be faulty in its
description of XSD's rules.  Corrections and examples of
problematic schemas welcome.

My experiments with this model have led me to believe it might be
more nearly correct to rephrase the note which currently reads

    Note: The constraint Element Declarations Consistent
    (§3.8.6.3) ensures that even if E matches more than one such
    declaration D, there will be just one context-determined type
    table.

to make it read

    Note: The definition just given, together with the constraint
    Element Declarations Consistent (§3.8.6.3) and the rule
    ensuring that no two top-level element declarations have the
    same name, ensures that even if E matches more than one such
    declaration D, there will be just one context-determined type
    table.

I doubt, however, that the increased correctness is worth making
the note wordier and harder to follow.

Intuitively, I share Sandy Gao's unease concerning the situation that a) a skip wildcard may play a role in determining the context-determined type table; b) xs:anyType is a possible source of a context-determined type table.

The stated contradiction, however -

"EDC doesn't guarantee consistency for type tables when skip wildcards are involved, but CDTT definition depends on that."

does not exist in my opinion, because the CDTT definition does not at all depend on EDC's second part, the part dealing with wildcards. This follows from CDTT's wording of clause 1:

"Let D be an Element Declaration matched by E, given by the first case among the following which applies."

"given by the first case" means: 
a) if there is at least one matching element declaration, clause 1.2 becomes irrelevant and wildcard matches are ignored
b) if there are only wildcard matches, there can be only one matching top level element declaration

So the EDC is only relevant if clause 1.1 applies, and it is only used to exclude inconsistencies between matching element declarations.

In conclusion, I suggest a microscopic modification of 3.4.4.1/note#1:

<actual>
Note: The constraint Element Declarations Consistent (§3.8.6.3) ensures that even if E ·matches· more than one such declaration D,
there will be just one ·context-determined type table·.
</actual>

<proposed>
Note: The constraint Element Declarations Consistent (§3.8.6.3) ensures that even if clause 1.1 applies and E ·matches· more than one such declaration D,
there will be just one ·context-determined type table·.
</proposed>

With kind regards -
Hans-Juergen Rennau

I think both of you are correct in that the contradiction doesn't exist. I missed the phrase "the first case" in clause 1 of the CDTT definition.

(Because of EDC, I naively thought it was not necessary to use "the first case", as EDC should/would guarantee that 1.1 and 1.2 will produce the same result.)

So I'm ready to withdraw the first half of my comment #3, given that there is no new information. I'm leaving this bug as "reopened", because I believe the process is that once you submit a comment, you can't just take it back.

Also it's not clear to me whether the WG needs/wants to take an explicit action on the second half of comment #3 (about anyType).

(In reply to comment #7)
> I think both of you are correct in that the contradiction doesn't exist. I
> missed the phrase "the first case" in clause 1 of the CDTT definition.
> 
> (Because of EDC, I naively thought it was not necessary to use "the first
> case", as EDC should/would guarantee that 1.1 and 1.2 will produce the same
> result.)
> 
> So I'm ready to withdraw the first half of my comment #3, given that there is
> no new information. I'm leaving this bug as "reopened", because I believe the
> process is that once you submit a comment, you can't just take it back.
> 
> Also it's not clear to me whether the WG needs/wants to take an explicit action
> on the second half of comment #3 (about anyType).
> 

By now I am convinced that you are right in your intuition that allowing skip wildcards to determine a CDTT might introduce inconsistency. 

A simple example demonstrates this. Consider this schema:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="e2" type="t2"/>
  <xs:element name="b" type="xs:integer"/>

  <xs:complexType name="t1">
    <xs:sequence>
      <xs:element name="a" type="xs:string"/>
      <xs:any processContents="skip"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="t2">
    <xs:complexContent>
      <xs:extension base="t1">
        <xs:sequence>
          <xs:element name="b" type="xs:date"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

</xs:schema>

Then any element validated against element declaration e2 will be invalid, because applying "Conditional Type Substitutable in Restriction" to child element b (with T=t2, B=t1) yields:
ST = xs:date
SB = xs:integer

that is, ST != SB, a violation of the constraint. If the global and the local element declaration indeed contained type tables (<alternative> children) the problem could be removed by ignoring skip wildcards when determining the CDTT, as you suggested (that is, by modifying clause 1.2 of the CDTT definition).

However, if global and local declaration do not contain type tables - as was the case in the example - the CDTTs are "effective type tables" (constructed from {type definition}), and then the wildcard's {process contents} becomes irrelevant, as "3.8.6.3 Element Declarations Consistent" does not safeguard against differences of {type definition} in the absence of {type table}. To address this issue, I am going to open a separate bug report.

Perhaps I am just too dim to understand it, but I don't see what contradiciton
arises from the example in comment #8.   If someone who has looked into the
example in greater detail can put it in terms of "For this example, rule xyz 
entails that A, and rule vwx entails that not(A)", I'd be grateful.

FYI. It seems that bug 6644 was opened for the example in comment #8.

(In reply to comment #9)
> Perhaps I am just too dim to understand it, but I don't see what contradiciton
> arises from the example in comment #8.   If someone who has looked into the
> example in greater detail can put it in terms of "For this example, rule xyz 
> entails that A, and rule vwx entails that not(A)", I'd be grateful.
> 

Before trying to express the problem in a more general way I want to clarify a point on which we may disagree. The matter *is* important because constraint 3.4.4.5 can destroy the validity of a document which is valid according to the conviction of 9 out of 10 experienced users (if not 999 out of 1000). Imagine a little ten-liner in the depth of a large project, which is called in the course of vital system operations and which - under rare yet conceivable circumstances - produces a null pointer exception. The ten-liner is given in three parts - constraint 3.4.4.5 (Conditional Type Substitutable in Restriction), the definition of CDTT and constraint 3.8.6.3 (Element Declarations Consistent). The null pointer exception consists in rendering a perfectly healthy document invalid. The rare but conceivable conditions are these:

- a complex type T overrides a global Element Declaration by a local one (call its name E)
- T is derived from another type B whose content model does not reference  element E (so T either adds E as part of an extension, or narrows down a wildcard to E as part of a restriction) 
- B's content type contains a wildcard matched by E

This constellation seems to me ordinary. Yet chances are that the validity of any element validated against T will be destroyed if it has a child E! This is because constraint 3.4.4.5 compares the type associated with E (according to the CDTTs) in B on the one hand, and in T on the other hand. If T extends B, these types even have to be equal - which probably will not be the case, as T chose to override the global element declaration.

You asked about the "contradictions". 

Contradiction 1: Constraint 3.8.6.3 (Element Declarations Consistent) explicitly states that strict and lax wildcards restrict the freedom of using a type table in a locally redeclared element; the constraint implies that skip wildcards do not restrict this freedom. But constraint 3.4.4.5 means that skip wildcards do restrict the freedom! The difference is esoteric, but it may decide who will have a conversation with the boss: a strict or lax wildcard causes a schema error detected when processing 3.8.6.3, while a skip wildcard causes an instance document invalidity, detected when processing 3.4.4.5.

Contradiction 2: Constraint 3.4.4.5 is meant (I believe) to ensure that the possibility of redefining type tables within a derivation chain does not compromise the concept of restriction, that is, the principle that any instance valid against the restricted type is valid against the base type. The effect however is introducing invalidity in cases where type tables are not even used and the "restriction principle" is not at all threatened. This is a contradiction to common sense.

By the way: the present state of our ten-liner means that documents valid according to schema 1.0 become invalid according to schema 1.1. You discourage me from giving a further example. But I think I might present *real world examples* where nothing looks eccentric.

During its 2009-04-03 telecon, the schema WG adopted a proposal to address this issue.

The proposal can be found at (member-only):
  http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni.20090313.html#anchor6561

Changes include:
1. Do not consider "skip" wildcards in computing context-determined type tables.
2. xs:anyType does *not* define any context-determined type table.

With these changes, the WG believes that the issue raised in this bug report is fully addressed. I'm marking this RESOLVED accordingly.

Hans-Juergen, as the persons who opened and reopened this issue, if you would indicate your concurrence with or dissent from the WG's disposition of the comment by closing or reopening the issue, we'll be grateful. If we don't hear from you in the next two weeks, we'll assume that silence implies consent.

Thank you for tackling this issue - I am content with the outcome. If I reopen this bug, it is only to draw your attention to a couple of editorial details:

a) In 3.4.4.5 "Conditional Type Substitutable in Restriction", clause 2.1 should be removed (as B cannot any more be xs:anyType)- otherwise, this clause would definitely confuse.
b) Perhaps 3.4.4.5 "Conditional Type Substitutable in Restriction" should be renamed, as it deals with extension too.




(In reply to comment #12)
> During its 2009-04-03 telecon, the schema WG adopted a proposal to address this
> issue.
> 
> The proposal can be found at (member-only):
>  
> http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni.20090313.html#anchor6561
> 
> Changes include:
> 1. Do not consider "skip" wildcards in computing context-determined type
> tables.
> 2. xs:anyType does *not* define any context-determined type table.
> 
> With these changes, the WG believes that the issue raised in this bug report is
> fully addressed. I'm marking this RESOLVED accordingly.
> 
> Hans-Juergen, as the persons who opened and reopened this issue, if you would
> indicate your concurrence with or dissent from the WG's disposition of the
> comment by closing or reopening the issue, we'll be grateful. If we don't hear
> from you in the next two weeks, we'll assume that silence implies consent.
> 

Thank you for pointing out these residual editorial problems.  They have
now been fixed (and a reference to clause 2.1 of Conditional Type
Substitutable from elsewhere has also been suppressed, since the
clause is gone).  

Those with W3C member access can see the change integrated into the
status quo text at 

  http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.html
  (member-only link)

-- or at least, they will when the upload completes.

Accordingly, I'm closing this issue as fixed.  Thank you again for
your interest in the spec and your comments.