Complex type derivations

Just as it is possible for the schema author to derive new simple data types from existing simple types, it is also possible to create new complex types from existing complex types. Again, this can be done either by extending or by restricting the base type, though the precise techniques are necessarily different (there are no list and union constructs, and no facets to consider).

A major apparent difference between deriving complex types and deriving simple types is that there are no complex types built in to the XML Schema standard. The usual reason for creating new simple types is to create types that deal with specific document model requirements, but it seems that the same argument cannot be made for complex types: an original complex type should have already been crafted for the intended purpose. Yet there are some good reasons for the presence of this feature, including the ability to create (and later validate) a hierarchy of increasingly refined data types.

Complex content

The ComplexContent element is used within the ComplexType element to indicate that the content will be a derivation of another complex data type. The Mixed attribute may be used on the ComplexContent element, and overrides any setting for this attribute on the ComplexType element.

<complexType>
  <complexContent mixed="false">
    ...
  </complexContent>
</complexType>

Extensions

As with simple types, an extension of a base type is defined using the Extension element. The new model is created by appending any new definitions, as if the original and new definitions were enclosed in a sequence group:

						<sequence>
						<!-- ORIGINAL DEFINITIONS -->
<!-- NEW DEFINITIONS -->
</sequence>
					

The original definitions are not repeated. For example, consider a base type that defines a book cover page structure:

<complexType name="BookCover">
  <sequence>
    <element ref="DOC:title" />
    <element ref="DOC:publisher" />
    <element ref="DOC:authorName" />
  </sequence>
</complexType>

Then consider an extension that adds a Date element. The comments in the example below enclose the implied content, including the conceptual outer-sequence element:

<complexType name="BookCoverWithDate">
  <!--
						<sequence>
						<sequence>
						<element ref="DOC:title" />
						<element ref="DOC:publisher" />
						<element ref="DOC:authorName" />
						</sequence>
    -->
    <sequence>
      <element ref="DOC:date" />
    </sequence>
  <!--
  </sequence>
  -->
</complexType>

Restrictions

Just as simple types can be restricted, it is also possible for complex types to be restricted. However, there are no facets to be applied in this case. Instead, restrictions are created by reproducing the original complex type definition, but with more limited options. For example, an original occurrence range can be narrowed, in the following case from a minimum of zero participants to a minimum of one participant:

<complexType name="ParticipantsType">
  <element ref="DOC:participant" minOccurs="0"
                                 maxOccurs="100">
</complexType>

<complexType name="AtLeastOneParticipantType">
  <complexContent>
    <restriction base="DOC:ParticipantsType">
      <element ref="DOC:participant" minOccurs="1" />
    </restriction>
  </complexContent>
</complexType>

Other ways of restricting a complex base type include:

• setting a default value for an element or attribute that previously had no default value

• setting a fixed value for an element or attribute that previously had no fixed value

• omitting an element or attribute reference when that item was previously optional (in the case of an element, just making the maximum occurrence zero, and in the case of an attribute, setting the Use attribute value to 'prohibited').

Any instance document structure that conforms to the restricted model should also conform to the original base model. This is why, for example, an element can only be omitted if it was originally optional. A schema-sensitive parser should also find nothing in a restricted model that is new.

It has been argued that the need to reproduce the definition in the derived restricted type makes the whole concept inefficient, and potentially redundant. After all, it would be just as easy to create the new type from scratch, without any reference to the type it is based on, and validation of document instances would not be affected in any way. But this approach would not allow for the feature described next (derivation selection from within instance documents), and would not permit the schema-sensitive parser to detect any changes to the base type that had not been copied into the derived types.