W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2009

block attribute and substitution groups

From: Tobias Koenig <tobias.koenig@trolltech.com>
Date: Wed, 7 Jan 2009 12:25:24 +0100
To: xmlschema-dev@w3.org
Message-Id: <200901071225.24426.tobias.koenig@trolltech.com>

Hej,

today I have a question about the block attribute in conjunction with 
substitution groups.

Let's assume the following schema
=========================================
<xsd:schema
  xmlns="ElemDecl/disallowedSubst"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  targetNamespace="ElemDecl/disallowedSubst"
  elementFormDefault="qualified"
  >

  <xsd:element name="root">
      <xsd:complexType>
          <xsd:sequence>
              <xsd:element ref="Head" maxOccurs="unbounded"/>
          </xsd:sequence>
      </xsd:complexType>
  </xsd:element>

  <xsd:element name="Head" type="Type"/>

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

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

  <xsd:element name="Member1" type="derivedFromType" 
substitutionGroup="Head"/>

</xsd:schema>
==========================================
according to the test suite and some schema validators it is correct.

However I stumble about http://www.w3.org/TR/xmlschema11-1/#e-props-correct 4)
that defines
	For each member M of E.{substitution group affiliations}, E.{type definition} 
	is ·validly substitutable· for M.{type definition}, subject to the blocking 
	keywords in M.{substitution group exclusions}.

So when checking element Member1, derivedFromType must be validly 
substitutable for Type, subject to the blocking keywords (empty set in this 
case)

When checking ·validly substitutable·, the first case (both are complex types) 
is used, which means:
	derivedFromType is validly derived from Type subject to the blocking keywords
	in the union of {empty set} and {restriction}, as defined in Type Derivation
	OK (Complex) (§3.4.6.5)

Now when testing Type Derivation Ok (Complex) all rules from 
http://www.w3.org/TR/xmlschema11-1/#cos-ct-derived-ok must be true, however
the first fails, as derivedFromType and Type are not the same type 
but 'restriction' _is_ part of the constraint set.

Where is my error in reasoning? Any help is appreciated.

Ciao,
Tobias
Received on Wednesday, 7 January 2009 11:25:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:50 UTC