[Bug 12185] Conditional Type Assignment and substitutability

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

--- Comment #7 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> 2011-04-22 01:41:09 UTC ---
A fourth comment, intended solely to offer an example illustrating
the class of schemas and instances affected by the proposed change.

The details will be tedious for some; sorry.  If the example proves
anything it is only that there ARE some schemas and instances which
will be affected by the change.  It also suggests but does not prove
that the class of affected schemas is not a large one: it consists
of schema with two complex types B and R, each defining a local
element E, in such a way that the declared type of B/E is
substitutable for R/E as a restriction, with both local elements E
using conditional type assignment but doing so in different ways 
which don't guarantee substitutability of the selected types.

To create an example in which the Conditional Type Substitutable
rule will object to a type definition, we must postulate two element
declarations with the same name and different type tables.  For
example (to avoid confusion, I'll use the name 'zap' and assume the
existence of the various ___WithTypeAttribute types shown in the
description):

 <xs:complexType name="B">
    <xs:sequence maxOccurs="unbounded" minOccurs="0">
      <xs:element name="zap">
        <xs:alternative test="@type='date'" 
          type="dateWithTypeAttribute"/>
        <xs:alternative test="@type='dateTime'"
          type="dateTimeStampWithTypeAttribute"/>
      </xs:element>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="R">
    <xs:complexContent>
      <xs:restriction base="B">
        <xs:sequence maxOccurs="1991" minOccurs="991">
          <xs:element name="zap">
            <xs:alternative test="@type='date'" 
              type="dateWithTypeAttribute"/>
            <xs:alternative test="@type='dateTime'"
              type="dateTimeWithTypeAttribute"/>
          </xs:element>
        </xs:sequence>        
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

The Conditional Type Substitutable (CTS) rule will fail to be
satisfied for any 'zap' child of an element with type tns:R, if (and
only if) the element has type='dateTime'.  Applying the CTS rule to
such an element information item, we have

  E = <tns:zap type='dateTime'>...</tns:zap>
  T = tns:R  // enclosing type

  B = tns:B // base of T
  T_T = sequence of:
           /type::tns:R/schemaElement::tns:zap/alternative::*[1]
           /type::tns:R/schemaElement::tns:zap/alternative::*[2]
        // i.e. the type table used for zap in an instance of tns:R
  T_B = sequence of:
           /type::tns:B/schemaElement::tns:zap/alternative::*[1]
           /type::tns:B/schemaElement::tns:zap/alternative::*[2]
        // i.e. the type table used for zap in an instance of tns:B
  S_T = tns:dateTimeWithTypeAttribute
  S_B = tns:dateTimeStampWithTypeAttribute

Clause 1 is not satisified, so clause 2 must be true.

Clause 2.2 is not satisfied, so 2.1 must be true.

Clause 2.1 requires:

  - T.{derivation method} = restrction (ok)
  - S_T is validly substitutable for S_B (see below)
  - E and B together satisfy CTS (ok)

S_T (i.e. tns:dateTimeWithTypeAttribute) is not validly
substitutable as a restriction for S_B
(tns:dateTimeStampWithTypeAttribute), though.

In consequence, under the status quo the parent element of the zap
elements will be invalid, because the parent has been too permissive
with the children and has allowed them to do things its base type
would not have allowed.  (O tempora! O mores!)

If we eliminate CTS, the zap elements in question will no longer
cause their parent to be invalid.  The only relevant question will
be: does the content type of R restrict the content type of B
according to Schema component constraint: Content type restricts
(Complex Content) (CTRCC)?

The requirements of CTRCC are two:

  1 Every sequence of element information items which is ·locally
    valid· with respect to R is also ·locally valid· with respect to
    B.

True.  R accepts anywhere between 991 and 1992 zap elements; B
accepts zero or more.

  2 For all sequences of element information items ES which are
    ·locally valid· with respect to R, for all elements E in ES, B's
    ·default binding· for E ·subsumes· that defined by R.

Also true.  The default binding of any zap element in R is the local
element declaration /type::tns:R /schemaElement::tns:zap, and in B
it's /type::tns:B /schemaElement::tns:zap.  Since both are element
declarations, they must satisfy clause 4 of the definition of
subsumption:

  4.1 Either G.{nillable} = true or S.{nillable} = false.

True by first disjunct.

  4.2 Either G has no {value constraint}, or it is not fixed, or S
      has a fixed {value constraint} with an equal or identical
      value.

True by first disjunct.

  4.3 S.{identity-constraint definitions} is a superset of
      G.{identity-constraint definitions}.

True (vacuously).

  4.4 S disallows a superset of the substitutions that G does.

True (vacuously).

  4.5 S's declared {type definition} is ·validly substitutable as a
      restriction· for G's declared {type definition}.

True: xsd:anyType is validly substitutable as a restriction for
xsd:anyType.

Having examined the example, I do not find myself unhappy with the
proposed change; I hope others agree.

-- 
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:41:11 UTC