[Bug 12185] Conditional Type Assignment and substitutability

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

--- Comment #6 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> 2011-04-22 01:04:22 UTC ---

A third comment (preparatory to actually drafting the wording
requested by the WG), concerning the relation of the proposed change
to our definition of restriction.

In XSD 1.0 the WG experimented with a set of rules that essentially
supplied an algorithm for checking restriction; in the aftermath we
discovered that the algorithm was flawed in various ways, and we
encountered difficulty understanding the algorithm well enough to
modify it reliably.  In XSD 1.1, the WG replaced the constructive
rules for restriction checking with somewhat higher-level rule which
essentially requires that a restriction:

  (a) count things as locally valid only if they are locally valid
      against the base type, and

  (b) associate types with all attributes and children which are
      subsumed by those associated with those attributes or children
      under the base type.  

      At a first approximation, one can think of 'associating' a
      type with a child element or attribute as assigning the type
      to it, but the story is complicated by (1) skip and lax
      wildcards and (2) the difference between the declared type of
      an item and its governing type: the rules of complex type
      restriction ignore the effect of xsi:type and the effect of
      conditional type assignment.

Rule (a) guarantees that the restriction won't allow sequences of
children or sets of attributes not allowed by the base type; rule
(b) guarantees that the type of a child or attribute won't be
broadened if the enclosing complex type is restricted.

The explicit statement of what guarantees restriction is supposed to
make are given in 3.4.6.4 Content Type Restricts (Complex Content),
which I'll call CTRCC from now on.

I do not believe remember that we explicitly thought about
conditional type assignment when we drafted CTRCC and the rest of
the section containing it. I'm almost certain that we didn't,
because the core of the new rules was drafted in 2005, while
conditional type assignment was not added until 2007.  Similarly, I
do not believe that we explicitly thought about the constraint
Content Type Restricts when we worked on conditional type assignment
and the Conditional Type Substitutable (CTS) rule.  If we had, we
either would have tightened CTRCC to cover selected types, not just
declared types, or else we would have realized that CTS was
unnecessary, because "the usual principles of complex type
restriction" as outlined by CTRCC do not require it.

Essentially, it now appears to me in retrospect that when the WG
first addressed the issue that led to CTS being drafted, the
question was raised in a form that presupposed that the rules in
CTRCC were more stringent than in fact they are, and that we needed
to do something special with condition type assignment, in order to
avoid violating XSD 1.1's new story about restriction.  But that
presupposition was a false one, and it was an error to allow it to
be smuggled into our work and taken as a requirement without
examination or debate.

When this bug was first opened, I was worried about the possibility
that in loosening the rules for conditional type assignment in the
context of complex type restriction of the parent, we might be
blasting a hole in the 1.1 rules governing restriction.  Having
studied CTRCC and the contexts which refer to CTS, I now think that
the change proposed will not break our rules for restriction or
require any change.  

If we make the change, restriction will not guarantee that the
governing type of any item I in a restriction will be identical to
or a restriction of the type I would have in the base type (in the
cases where both the base and the restriction assign a type to I);
that guarantee will be made of the declared type, instead.  That
guarantee has *never* been made for the governing type; it has
*always* been made only for the declared type of I.

-- 
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 01:04:25 UTC