I've been writing a conference paper about XSD 1.1, and specifically about assertions, and I hit a rather embarrassing usability problem. Sorry for raising it at this stage of the game, but it's exactly at this stage that usability problems tend to be discovered.

I was trying to show how useful assertions are in customizing a schema for local use. For example, suppose there is a standard IPO schema for internal purchase orders, and you want to customize it so that money amounts are always in dollars. So one should be able to say:

<xs:element name="our-IPO">
  <xs:complexType name="our-IPO-type">
    <xs:complexContent>
      <xs:restriction base="IPO-type">
        <xs:assert test="every $c in .//@currency satisfies $c='USD'"/>
      </xs:restriction>
    </xs:complexContent>
  <xs:complexType>
</xs:element>

Simple, isn't it? But wrong. Applying xs:restriction to a complex type inherits the attribute uses of the base type, but not the particle or the attribute wildcard. If you want your restricted type to have the same content model as the base type, you have to copy it across, in all its gory detail. And of course every time it changes, your new type has to change too.

I've got a few ideas on how to fix this. I'll start with the one that I think is best but most radical, which I'll call the Grand Plan.

The Grand Plan is to remove the assymmetry in complex type restriction as to which parts of the base type definition are inherited and which are explicitly redefined. (This is all at the XML representation level, the component level is unaffected.)

To xs:restriction (for complex types) we add an attribute @inherit, whose value is a list of tokens from the set (content, attributes, anyAttribute) or the value #all to indicate all of the above. The default value, for compatibility reasons, is "attributes". The @inherit attribute indicates which aspects of the base type definition are inherited. If attributes are inherited, we allow attributes to be redefined in the restricted type as at present, but if content or anyAttribute is inherited, we require the restricted type to specify no content or no attribute wildcard respectively.

Add the XML representation rule that if xs:restriction/@inherit includes content, then the xs:restriction element must not have a sequence, choice, all or group child; and if it includes anyAttribute, then it must not have an anyAttribute child.

The mapping rule for attribute uses (3.4.2.4) is changed as follows: in 3.2, change "If T is a complex type definition and {derivation method} = restriction" to add " and the [inherit] attribute of the <restriction> element includes 'attributes'"

The mapping rule for atribute wildcards (3.4.2.5) is changed as follows: rule 2.1, currently "If  {derivation method} = restriction  , then the ·complete wildcard·;" becomes: 2.1 If {derivation method} = restriction, then the relevant case among the following: 2.1.1 if the [inherit] attribute of the <restriction> element includes 'anyAttribute' then the base wildCard 2.1.2 otherwise, the ·complete wildcard·. And promote the definition of "base WildCard" from 2.2.1.

The mapping rule for complex content {content type} (3.4.2.3.3) is changed as follows: in 4.1 ("4.1 If  {derivation method} = restriction") add the rule "If the inherit attribute of the <restriction> element includes "content", then {base type definition}.{content type}

That's the Grand Plan. If it's too much to stomach, can we get away with less?

Plan B: We could cut it down so the only new option is inherit="content".

Plan C: We could cut it down further so there is no new syntax, but inherit="content" is implicit in the case of an xs:restriction that has an xs:assert child but no xs:sequence|xs:choice|xs:all|xs:group child. Yuk.

Plan G: A different approach. We could introduce "manual inheritance" for complex types by syntax such as:

<xs:element name="our-IPO">
  <xs:complexType name="our-IPO-type">
    <xs:complexContent>
      <xs:restriction base="IPO-type">
        <xs:group/>
        <xs:assert test="every $c in .//@currency satisfies $c='USD'"/>
      </xs:restriction>
    </xs:complexContent>
  <xs:complexType>
</xs:element>

where the absence of a "ref" attribute on xs:group means "an anonymous model group corresponding to the content model of the base type". This is perhaps the least disruptive proposal.

Plan H: Introduce special syntax for the case where a complex type is restricted only by addition of assertions:

<xs:element name="our-IPO">
  <xs:complexType name="our-IPO-type">
     <xs:restriction base="IPO-type">
        <xs:assert test="every $c in .//@currency satisfies $c='USD'"/>
     </xs:restriction>
  <xs:complexType>
</xs:element>