This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I believe that the schema substitution.xsd used with QT3 test set prod-SchemaImport is OK in XSD 1.0 but not in XSD 1.1 (But I would appreciate someone else checking my reasoning...) The schema declares a complex type that blocks extension: <xs:complexType name="Ht" block="extension"> and a type that extends it: <xs:complexType name="HtE"> <xs:complexContent> <xs:extension base="s:Ht"> It defines an element declaration: <xs:element name="H" type="s:Ht" nillable="true"/> and a substitution group member: <xs:element name="G" substitutionGroup="s:H" type="s:HtE"/> So in the component model, Ht has {prohibited substitutions} = (extension), and in consequence HtE is not *validly derived* from Ht. Rule 4 of 3.3.6.1 Element Declaration Properties correct requires: For each member M of E.{substitution group affiliations}, E.{type definition} is ·validly substitutable· for M.{type definition}, subject to the blocking keywords in M.{substitution group exclusions}. Because HtE is not validly derived from Ht, the type of G is not validly substitutable for the type of H. But H is a member of G.{substitution group affiliations} ("A set of the element declarations ·resolved· to by the items in the ·actual value· of the substitutionGroup [attribute]"), therefor Element Declaration Properties is not satisfied, and therefore we do not have a valid schema. In XSD 1.0 the situation is subtly different. Rule 4 of Element Declaration Properties Correct now reads: If there is a {substitution group affiliation}, the {type definition} of the element declaration must be validly derived from the {type definition} of the {substitution group affiliation}, given the value of the {substitution group exclusions} of the {substitution group affiliation}, as defined in Type Derivation OK (Complex) (§3.4.6) One change here is that in XSD 1.0 an element can belong to only one substitition group. The other change is the use phrase "validly derived" rather than "validly substitutable". Type D is not validly derived from type B given blocking keywords K if K includes "extension" and B blocks extension. But in the XSD 1.0 formulation, the phrase "validly derived" is not qualified by "given K=(extension)" - K is determined solely by what the substitution group blocks, not by what the type blocks. Essentially, this schema is valid in XSD 1.0 only because of a loophole in the XSD 1.0 specification that was plugged in XSD 1.1.
I should perhaps correct the paragraph above that reads: So in the component model, Ht has {prohibited substitutions} = (extension), and in consequence HtE is not *validly derived* from Ht. to read: So in the component model, Ht has {prohibited substitutions} = (extension), and in consequence HtE is not *validly derived* from Ht *given K=(extension)*. It is however validly derived given K=() (the empty set), and the XSD 1.0 rule (Rule 4 of Element Declaration Properties Correct) in fact invokes it with K=().
So, what should we do about it? That depends a bit on what we think we are trying to test. The comment in the schema reads: <!-- A schema designed to explore corner cases relating to schema-element() and its interaction with substitution groups --> So I think the intent of the test is probably best preserved by keeping the XSD 1.0 test cases "as is", and the question then becomes what to do for XSD 1.1. We already have a similar schema substitution11, and associated tests, that performs a similar function for XSD 1.1. So I propose simply to mark the schema substitution.xsd, and the tests that depend on it, as XSD-1.0-only tests.
ACTION A-664-02: O'Neil to mark the schema substitution.xsd, and the tests that depend on it, as XSD-1.0-only tests
Resolved bug according to comment #2