[Bug 6382] Substitution group and "block"

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





--- Comment #1 from Sandy Gao <sandygao@ca.ibm.com>  2009-01-07 19:16:38 ---
Dug a little deeper into this. It seems that we introduced the "validly
substitutable" concept, taking "block" of the base type into account, which is
suitable for certain scenarios. Then we applied it to many other places where
type derivation is checked, without carefully examine whether "block" should be
honored.

In 3.4.1, the description of {prohibited substitution} = block indicates that
it's for 3 purposes:
1. xsi:type
2. substitution group
3. type alternative (new in 1.1, similar to xsi:type)

I searched for "validly substitutable" in the 1.1 draft to see which
occurrences are for one of the above 3. The following look suspicious:

* 3.3.6.1 Element Declaration Properties Correct bullet 4

This is the case mentioned in the bug report.

This does not hurt too much, as no valid instance can substitute "head" with an
element through "member1", because of "block". The only difference is whether
to reject the schema, or reject the instance.

But this is still a behavior change since 1.0.

* 3.4.4.5 Conditional Type Substitutable in Restriction bullet 2.1

This on the surface is related to type alternative, but it actually has more to
do with restriction. We want to make sure that the type assigned by a
restriction type is a restriction of the type assigned by the base type.
Restriction isn't something we intended to govern using "block", so this seems
to be an incorrect reference to "validly substitutable".

* 3.4.6.2 Derivation Valid (Extension) bullet 1.6
* 3.4.6.3 Derivation Valid (Restriction, Complex) bullet 4
* 3.4.6.4 Content Type Restricts (Complex Content) bullet 4.5

Similarly, all these 3 references are about type extension/restriction, and
don't fall into one of the 3 "block" scenarios. The references to "validly
substitutable" (by taking "block" into account) make certain schema valid under
1.0 invalid under 1.1. e.g.

  <xsd:complexType name="Type" block="restriction"/>

  <xsd:complexType name="derivedFromType">
      <xsd:complexContent>
          <xsd:restriction base="Type"/>
      </xsd:complexContent>
  </xsd:complexType>

  <xsd:complexType name="base">
    <xsd:sequence>
      <xsd:element name="e" type="Type"/>
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="restriction">
      <xsd:complexContent>
          <xsd:restriction base="base">
            <xsd:sequence>
              <xsd:element name="e" type="derivedFromType"/>
            </xsd:sequence>
          </xsd:restriction>
      </xsd:complexContent>
  </xsd:complexType>

In 1.0, "restriction" is a valid restriction of "base", but in 1.1, because
"Type" blocks restriction, "e" in "restriction" can't restrict "e" in "base",
and "restriction" becomes invalid.


I think we should update the above 5 links to check type derivation *without*
involving "block" of 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 Wednesday, 7 January 2009 19:16:48 UTC