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 discussing subtype judgements, we say in rule 17 of 2.5.6.2 that Ai is a subtype of Bi if: Bi is schema-element(Bn), the expanded QName of An equals the expanded QName of Bn, Ai is schema-element(An), and either the expanded QName of An equals the expanded QName of Bn, or the element declaration named An is in the substitution group of the element declaration named Bn. In other words we are saying that if E is in the substitution group of B and B is in the substititution group of A, then E is in the substitition group of A. I don't think this is necessarily true. For example if A and B have the same type, and if the type of E is derived by extension from this type, and if A blocks extension but B does not, then B is in the substitution group of A, E is in the substititution group of B, but E is not in the substitution group of A.
My preferred solution would be to change the rule from: <old>[Ai is a subtype of Bi if: ] Bi is schema-element(Bn), the expanded QName of An equals the expanded QName of Bn, Ai is schema-element(An), and either the expanded QName of An equals the expanded QName of Bn, or the element declaration named An is in the substitution group of the element declaration named Bn.</old> (in which, incidentally, the first occurrence of <quote>the expanded QName of An equals the expanded QName of Bn</quote> appears to be a copy/paste typo) to <new>[Ai is a subtype of Bi if: ] Bi is schema-element(Bn), Ai is schema-element(An), and every element declaration that is an actual member of the substitution group of An is also an actual member of the substitution group of Bn</new> with a note: <note>Note that the fact that P is a member of the substitution group of Q does not mean that every element declaration in the substitution group of P is also in the substitution group of Q. For example, Q might block substitution of elements whose type is derived by extension, while P does not.</note>
To determine statically whether schema-element(X) is a subtype of schema-element(Y) requires all schemas to be known statically at query compile time. Is this a reasonable assumption? It makes it rather difficult to compile modules in isolation.
Saxon requires the membership of a substitution group to be known when a module containing a reference to the head of the SG is compiled (i.e. it prevents anyone adding to the substitution group from that point on). Other implementations might allow more dynamic flexibility, but then they cannot make assumptions based on the SG membership being statically known. The spec leaves implementations to decide how flexible to be. I don't think that this is really any different from being able to decide whether or not an element E may or may not be passed to a function expecting schema-element(H). If you freeze the SG membership at compile time, you can type-check this statically; if you don't, then you can't. The spec allows both options.
(In reply to comment #3) > I don't think that this is really any different from being able to decide > whether or not an element E may or may not be passed to a function expecting > schema-element(H). If you freeze the SG membership at compile time, you can > type-check this statically; if you don't, then you can't. The spec allows > both options. Using the MS .NET XmlSchema classes, it is relatively easy to determine the membership of an element at runtime (even in the face of post-compilation changes to the schema). Determining whether scheme-element(X) is a subtype of scheme-element(Y) is somewhat more difficult.
The Working Group adopted the resolution in comment #1.