[Bug 12185] Conditional Type Assignment and substitutability

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12185

--- Comment #4 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> 2011-04-22 00:10:06 UTC ---
To make my comments a little easier to follow, I'll break them up
into smaller units.  First, on the premise.  The bug description
says

    So, given a complex type definition B that allows <chap> within
    its content, it is perfectly acceptable for an <appendix> to
    appear as a substitute for <chap>.

    However, if I define a complex type R that restricts B, then
    within the content of an element whose declared type is R, it
    seems I can no longer substitute an arbitrary <appendix> for a
    <chap>: I am liable to fall foul of the "Conditional Type
    Substitutable" rules.

I don't think so.  

You don't say so explicitly, but I understand you to be thinking of
a pair of complex types B and R each of which has a content model
including the top-level 'chap'.  But in that case, the Conditional
Type Substitutable rules will have no objection.

[Details, for those who feel obligated to check my work: In type B,
the type table for any element named 'chap' (T_B in the validation
rule) will be the type table specified in the top-level declaration
for 'chap'; in type R, the responsible type table (T_T) will be the
same type table.  Whatever 'chap' element is presented to that type
table will get the same type both in the B context and the R
context, so the S_T and S_R mentioned in the validation rule will be
the same type definition.  Since by hypothesis R is a restriction of
B, clause 2.2 fails on its first condition, so clause 2.1 must be
satisfied; it requires that S_T by validly substitutable as a
restriction for S_B.  After a short trip through the definitions for
"validly substitutable as a restriction" and "validly substitutable"
subject to a set of blocking keywords, we fetch up eventually at
Schema Component Constraint: Type Derivation OK (Complex) in section
3.4.6.5, which tells us (if we are patient and determined) that any
type definition counts as being validly derived from itself.
Popping the stack of questions and definitions, this turns out to
mean that any type is validly substitutable for itself, and in
particular S_T is validly substitutable for S_B, given that they are
the same type.

The same argument applies to any element named 'app':  since B and R
use the same top-level element declaration for 'app', any 'app'
element would be assigned the same governing type definition in R as
in B, and there is no violation of restriction in that.]

This does not address the question of the run-time checking being
hard on performance or of the current rule being overnice, only
the proposition that the spec imposes restrictions on the use of
substitution groups in restrictions that it does not impose on their
use in the base type.

-- 
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 Friday, 22 April 2011 00:10:09 UTC