Table of contents

Appendices

3.4 Complex Type Definitions

Complex Type Definitions provide for:

• Constraining element information items by providing [Attribute Declaration]s governing the appearance and content of [attributes]

• Constraining element information item [children] to be empty, or to conform to a specified element-only or mixed content model, or else constraining the character information item [children] to conform to a specified simple type definition.

• Using the mechanisms of [Type Definition Hierarchy] to derive a complex type from another simple or complex type.

• Specifying Schema Information Set Contribution for elements.

• Limiting the ability to derive additional types from a given complex type.

• Controlling the permission to substitute, in an instance, elements of a derived type for elements declared in a content model to be of a given complex type.

NOTE: 

<xs:complexType name="PurchaseOrderType">
  <xs:sequence>
   <xs:element name="shipTo" type="USAddress"/>
   <xs:element name="billTo" type="USAddress"/>
   <xs:element ref="comment" minOccurs="0"/>
   <xs:element name="items"  type="Items"/>
  </xs:sequence>
  <xs:attribute name="orderDate" type="xs:date"/>
 </xs:complexType>

The XML representation of a complex type definition.

The Complex Type Definition Schema Component[top]

A complex type definition schema component has the following properties:

Complex types definitions are identified by their [ct-name] and [ct-target_namespace]. Except for anonymous complex type definitions (those with no [ct-name]), since type definitions (i.e. both simple and complex type definitions taken together) must be uniquely identified within an XML Schema, no complex type definition can have the same name as another simple or complex type definition. Complex type [ct-name]s and [ct-target_namespace]s are provided for reference from instances (see [xsi:type]), and for use in the XML representation of schema components (specifically in [element]). See [References to schema components across namespaces] for the use of component identifiers when importing one schema into another.

NOTE: 

The [ct-name] of a complex type is not ipso facto the [(local) name] of the element information items valid by that definition. The connection between a name and a type definition is described in [Element Declarations].

As described in [Type Definition Hierarchy], each complex type is derived from a [ct-base_type_definition] which is itself either a [Simple Type Definition] or a [Complex Type Definition]. [derivation_method] specifies the means of derivation as either extension or restriction (see [Type Definition Hierarchy]).

A complex type with an empty specification for [ct-final] can be used as a [ct-base_type_definition] for other types derived by either of extension or restriction; the explicit values extension, and restriction prevent further derivations by extension and restriction respectively. If all values are specified, then the complex type is said to be final, because no further derivations are possible. Finality is not inherited, that is, a type definition derived by restriction from a type definition which is final for extension is not itself, in the absence of any explicit final attribute of its own, final for anything.

Complex types for which [ct-abstract] is true must not be used as the [type_definition] for the valid of element information items. It follows that they must not be referenced from an [xsi:type] attribute in an instance document. Abstract complex types can be used as [ct-base_type_definition]s, or even as the [type_definition]s of element declarations, provided in every case a concrete derived type definition is used for valid, either via [xsi:type] or the operation of a substitution group.

[ct-attribute_declarations] are a set of attribute uses. See [Element Locally Valid (Complex Type)] and [Attribute Locally Valid] for details of attribute valid.

[ct-attribute_wildcard]s provide a more flexible specification for valid of attributes not explicitly included in [ct-attribute_declarations]. Informally, the specific values of [ct-attribute_wildcard] are interpreted as follows:

• any: [attributes] can include attributes with any qualified or unqualified name.

• a set whose members are either namespace names or absent: [attributes] can include any attribute(s) from the specified namespace(s). If absent is included in the set, then any unqualified attributes are (also) allowed.

• 'not' and a namespace name: [attributes] cannot include attributes from the specified namespace.

• 'not' and absent: [attributes] cannot include unqualified attributes.

[content_type] determines the valid of [children] of element information items. Informally:

• A [content_type] with the distinguished value empty valid elements with no character or element information item [children].

• A [content_type] which is a [Simple Type Definition] valid elements with character-only [children].

• An element-only [content_type] valid elements with [children] that conform to the supplied content model.

• A mixed [content_type] valid elements whose element [children] (i.e. specifically ignoring other [children] such as character information items) conform to the supplied content model.

[ct-exact] determine whether an element declaration appearing in a content model is prevented from additionally valid element items with an [xsi:type] attribute that identifies a complex type definition derived by extension or restriction from this definition, or element items in a substitution group whose type definition is similarly derived: If [ct-exact] is empty, then all such substitutions are allowed, otherwise, the derivation method(s) it names are disallowed.

See [Annotations] for information on the role of the [ct-annotations] property.

XML Representation of Complex Type Definitions[top]

The XML representation for a complex type definition schema component is a [complexType] element information item.

The XML representation for complex type definitions with a simple type definition [content_type] is significantly different from that of those with other [content_type]s, and this is reflected in the presentation below, which displays first the elements involved in the first case, then those for the second. The property mapping is shown once for each case.

Whichever alternative for the content of [complexType] is chosen, the following property mappings apply:

When the [simpleContent] alternative is chosen, the following elements are relevant, and the remaining property mappings are as below. Note that either [restriction] or [extension] must be chosen as the content of [simpleContent].

When the [complexContent] alternative is chosen, the following elements are relevant (as are the [attributeGroup] and [anyAttribute] elements, not repeated here), and the additional property mappings are as below. Note that either [restriction] or [extension] must be chosen as the content of [complexContent], but their content models are different in this case from the case above when they occur as children of [simpleContent].

The property mappings below are also used in the case where the third alternative (neither [simpleContent] nor [complexContent]) is chosen. This case is understood as shorthand for complex content restricting the ur-type definition, and the details of the mappings should be modified as necessary.

NOTE: 

Aside from the simple coherence requirements enforced above, constraining type definitions identified as restrictions to actually be restrictions, that is, to valid a subset of the items which are valid by their base type definition, is enforced in [Constraints on Complex Type Definition Schema Components].

NOTE: 

The only substantive function of the value prohibited for the use attribute of an [attribute] is in establishing the correspondence between a complex type defined by restriction and its XML representation. It serves to prevent inheritance of an identically named attribute use from the [ct-base_type_definition]. Such an [attribute] does not correspond to any component, and hence there is no interaction with either explicit or inherited wildcards in the operation of [Complex Type Definition Validation Rules] or [Constraints on Complex Type Definition Schema Components].

Careful consideration of the above concrete syntax reveals that a type definition need consist of no more than a name, i.e. that <complexType name="anyThing"/> is allowed.

NOTE: 

<xs:complexType name="length1">
 <xs:simpleContent>
  <xs:extension base="xs:nonNegativeInteger">
   <xs:attribute name="unit" type="xs:NMTOKEN"/>
  </xs:extension>
 </xs:simpleContent>
</xs:complexType>

<xs:element name="width" type="length1"/>

  <width unit="cm">25</width>

<xs:complexType name="length2">
 <xs:complexContent>
  <xs:restriction base="xs:anyType">
   <xs:sequence>
    <xs:element name="size" type="xs:nonPositiveInteger"/>
    <xs:element name="unit" type="xs:NMTOKEN"/>
   </xs:sequence>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>

<xs:element name="depth" type="length2"/>

  <depth>
   <size>25</size><unit>cm</unit>
  </depth>

<xs:complexType name="length3">
 <xs:sequence>
  <xs:element name="size" type="xs:non-positive-integer"/>
  <xs:element name="unit" type="xs:NMTOKEN"/>
 </xs:sequence>
</xs:complexType>

Three approaches to defining a type for length: one with character data content constrained by reference to a built-in datatype, and one attribute, the other two using two elements. length3 is the abbreviated alternative to length2: they correspond to identical type definition components.

NOTE: 

<xs:complexType name="personName">
 <xs:sequence>
  <xs:element name="title" minOccurs="0"/>
  <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>
  <xs:element name="surname"/>
 </xs:sequence>
</xs:complexType>

<xs:complexType name="extendedName">
 <xs:complexContent>
  <xs:extension base="personName">
   <xs:sequence>
    <xs:element name="generation" minOccurs="0"/>
   </xs:sequence>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

<xs:element name="addressee" type="extendedName"/>

  <addressee>
   <forename>Albert</forename>
   <forename>Arnold</forename>
   <surname>Gore</surname>
   <generation>Jr</generation>
  </addressee>

A type definition for personal names, and a definition derived by extension which adds a single element; an element declaration referencing the derived definition, and a valid instance thereof.

NOTE: 

<xs:complexType name="simpleName">
 <xs:complexContent>
  <xs:restriction base="personName">
   <xs:sequence>
    <xs:element name="forename" minOccurs="1" maxOccurs="1"/>
    <xs:element name="surname"/>
   </xs:sequence>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>

<xs:element name="who" type="simpleName"/>

   <who>
    <forename>Bill</forename>
    <surname>Clinton</surname>
   </who>

A simplified type definition derived from the base type from the previous example by restriction, eliminating one optional daughter and fixing another to occur exactly once; an element declared by reference to it, and a valid instance thereof.

NOTE: 

<xs:complexType name="paraType" mixed="true">
 <xs:choice minOccurs="0" maxOccurs="unbounded">
  <xs:element ref="emph"/>
  <xs:element ref="strong"/>
 </xs:choice>
 <xs:attribute name="version" type="xs:number"/>
</xs:complexType>

A further illustration of the abbreviated form, with the mixed attribute appearing on complexType itself.

Constraints on XML Representations of Complex Type Definitions[top]

In addition to the conditions imposed on [complexType] element information items by the schema for schemas,

1. If the [complexContent] alternative is chosen, the type definition QName resolution (Schema Document) to by the actual value of the base [attribute] must be a complex type definition;

2. If the [simpleContent] alternative is chosen, the type definition QName resolution (Schema Document) to by the actual value of the base [attribute] must be either a complex type definition whose [content_type] is a simple type definition or, only if the [extension] alternative is also chosen, a simple type definition;

3. The corresponding complex type definition component must satisfy the conditions set out in [Constraints on Complex Type Definition Schema Components];

4. If [c-awi1] or [c-awi2] in the correspondence specification above for [ct-attribute_wildcard] is satisfied, the intensional intersection must be expressible, as defined in [Attribute Wildcard Intersection].

Complex Type Definition Validation Rules[top]

For an element information item to be locally valid with respect to a complex type definition

1. [ct-abstract] is false.

2. If [c-nl] of [Element Locally Valid (Element)] did not apply, then

   1. ifthe [content_type] is empty

      thenthe element information item has no character or element information item [children].

   2. ifthe [content_type] is a simple type definition

      thenthe element information item has no element information item [children], and the normalized value of the element information item is valid with respect to that simple type definition as defined by [String Valid].

   3. ifthe [content_type] is element-only

      thenthe element information item has no character information item [children] other than those whose [character code] is defined as a white space in [ref-xml].

   4. ifthe [content_type] is element-only or mixed

      thenthe sequence of the element information item's element information item [children], if any, taken in order, is valid with respect to the [content_type]'s particle, as defined in [Element Sequence Locally Valid (Particle)].

3. For each attribute information item in the element information item's [attributes] excepting those whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is one of type, nil, schemaLocation or noNamespaceSchemaLocation,

   1. ifthere is among the [ct-attribute_declarations] an attribute use with an [attribute] whose [a-name] matches the attribute information item's [local name] and whose [a-target_namespace] is identical to the attribute information item's [namespace name] (where an absent [a-target_namespace] is taken to be identical to a [namespace name] with no value)

      thenthe attribute information must be valid with respect to that attribute use as per [Attribute Locally Valid (Use)]. In this case the [attribute] of that attribute use is the context-determined declaration for the attribute information item with respect to [Schema-Validity Assessment (Attribute)] and [Assessment Outcome (Attribute)].

   2. otherwise

      1. There must be an [ct-attribute_wildcard].

      2. The attribute information item must be valid with respect to it as defined in [Item Valid (Wildcard)].

4. The [attribute] of each attribute use in the [ct-attribute_declarations] whose [required] is true matches one of the attribute information items in the element information item's [attributes] as per [c-ctma] above.

5. Let the wild IDs be the set of all attribute information item to which [c-avaw] applied and whose valid resulted in a context-determined declaration of mustFind or no context-determined declaration at all, and whose [local name] and [namespace name] resolve (as defined by [QName resolution (Instance)]) to an attribute declaration whose [a-simple_type_definition] is or is derived from ID. Then

   1. There must be no more than one item in wild IDs.

   2. If wild IDs is non-empty, there must not be any attribute uses among the [ct-attribute_declarations] whose [attribute]'s [a-simple_type_definition] is or is derived from ID.

   NOTE: 

   This clause serves to ensure that even via attribute wildcards no element has more than one attribute of type ID, and that even when an element legitimately lacks a declared attribute of type ID, a wildcard-validated attribute must not supply it. That is, if an element has a type whose attribute declarations include one of type ID, it either has that attribute or no attribute of type ID.

NOTE: 

When an [ct-attribute_wildcard] is present, this does not introduce any ambiguity with respect to how attribute information items for which an attribute use is present amongst the [ct-attribute_declarations] whose name and target namespace match are assessment. In such cases the attribute use always takes precedence, and the assessment of such items stands or falls entirely on the basis of the attribute use and its [attribute]. This follows from the details of [c-aam].

Complex Type Definition Information Set Contributions[top]

For each attribute use in the [ct-attribute_declarations] whose [required] is false and whose [au-value_constraint] is not absent but whose [attribute] does not match one of the attribute information items in the element information item's [attributes] as per [c-ctma] of [Element Locally Valid (Complex Type)] above, the post-schema-validation infoset has an attribute information item whose properties are as below added to the [attributes] of the element information item.

[local name]

The [attribute]'s [a-name].

[namespace name]

The [attribute]'s [a-target_namespace].

[a-schema_normalized_value]

The canonical lexical representation of the [au-value_constraint] value.

[a-schema_default]

The canonical lexical representation of the [au-value_constraint] value.

[a-validation_context]

The nearest ancestor element information item with a [e-schema_information] property.

[a-validity]

valid.

[a-validation_attempted]

full.

[a-schema_specified]

schema.

The added items should also either have [a-type_definition] (and [a-member_type_definition] if appropriate) properties, or their lighter-weight alternatives, as specified in [Attribute Validated by Type].

Constraints on Complex Type Definition Schema Components[top]

All complex type definitions (see [Complex Type Definitions]) must satisfy the following constraints.

1. The values of the properties of a complex type definition must be as described in the property tableau in [The Complex Type Definition Schema Component], modulo the impact of [Missing Sub-components].

2. If the [ct-base_type_definition] is a simple type definition, the [derivation_method] must be extension.

3. Circular definitions are disallowed, except for the Complex Type Definition of the Ur-Type. That is, it must be possible to reach the Complex Type Definition of the Ur-Type by repeatedly following the [ct-base_type_definition].

4. Two distinct attribute declarations in the [ct-attribute_declarations] must not have identical [a-name]s and [a-target_namespace]s.

5. Two distinct attribute declarations in the [ct-attribute_declarations] must not have [a-simple_type_definition]s which are or are derived from ID.

If the [derivation_method] is extension,

1. ifthe [ct-base_type_definition] is a complex type definition

   then

   1. The [ct-final] of the [ct-base_type_definition] must not contain extension.

   2. Its [ct-attribute_declarations] must be a subset of the [ct-attribute_declarations] of the complex type definition itself, that is, for every attribute use in the [ct-attribute_declarations] of the [ct-base_type_definition], there must be an attribute use in the [ct-attribute_declarations] of the complex type definition itself whose [attribute] has the same [a-name], [a-target_namespace] and [a-simple_type_definition] as its attribute declaration.

   3. If it has an [ct-attribute_wildcard], the complex type definition must also have one, and the base type definition's [ct-attribute_wildcard]'s [namespace_constraint] must be a subset of the complex type definition's [ct-attribute_wildcard]'s [namespace_constraint], as defined by [Wildcard Subset].

   4. 1. The [content_type] of the [ct-base_type_definition] and the [content_type] of the complex type definition itself must be the same simple type definition.

      2. 1. The [content_type] of the complex type definition itself must specify a particle.

         2. 1. The [content_type] of the [ct-base_type_definition] must be empty.

            2. 1. Both [content_type]s must be mixed or both must be element-only.

               2. The particle of the complex type definition must be a valid extension of the [ct-base_type_definition]'s particle, as defined in [Particle Valid (Extension)].

   5. It must in principle be possible to derive the complex type definition in two steps, the first an extension and the second a restriction (possibly vacuous), from that type definition among its ancestors whose [ct-base_type_definition] is the Complex Type Definition of the Ur-Type.

      NOTE: 

      This requirement ensures that nothing removed by a restriction is subsequently added back by an extension. It is trivial to check if the extension in question is the only extension in its derivation, or if there are no restrictions bar the first from the Complex Type Definition of the Ur-Type.

      Constructing the intermediate type definition to check this constraint is straightforward: simply re-order the derivation to put all the extension steps first, then collapse them into a single extension. If the resulting definition can be the basis for a valid restriction to the desired definition, the constraint is satisfied.

2. ifthe [ct-base_type_definition] is a simple type definition

   then

   1. The [content_type] must be the same simple type definition.

   2. The [st-final] of the [ct-base_type_definition] must not contain extension.

If the [derivation_method] is restriction

1. The [ct-base_type_definition] must be a complex type definition whose [ct-final] does not contain restriction.

2. For each attribute use (call this R) in the [ct-attribute_declarations]

   1. ifthere is an attribute use in the [ct-attribute_declarations] of the [ct-base_type_definition] (call this B) whose [attribute] has the same [a-name] and [a-target_namespace]

      then

      1. 1. B's [required] is false.

         2. R's [required] is true.

      2. R's [attribute]'s [a-simple_type_definition] must be validly derived from B's [a-simple_type_definition] given the empty set as defined in [Type Derivation OK (Simple)].

      3. Let the effective value constraint of an attribute use be its [au-value_constraint], if present, otherwise its [attribute]'s [a-value_constraint] . Then

         1. B's effective base value constraint is absent or default.

         2. R's effective base value constraint is fixed with the same string as B's.

   2. otherwisethe [ct-base_type_definition] must have an [ct-attribute_wildcard] and the [a-target_namespace] of the R's [attribute] must be valid with respect to that wildcard, as defined in [Wildcard allows Namespace Name].

3. For each attribute use in the [ct-attribute_declarations] of the [ct-base_type_definition] whose [required] is true, there must be an attribute use with an [attribute] with the same [a-name] and [a-target_namespace] as its [attribute] in the [ct-attribute_declarations] of the complex type definition itself whose [required] is true.

4. If there is an [ct-attribute_wildcard],

   1. The [ct-base_type_definition] must also have one.

   2. The complex type definition's [ct-attribute_wildcard]'s [namespace_constraint] must be a subset of the [ct-base_type_definition]'s [ct-attribute_wildcard]'s [namespace_constraint], as defined by [Wildcard Subset].

5. 1. ifthe [content_type] of the complex type definition is a simple type definition

      then

      1. The [content_type] of the [ct-base_type_definition] must be a simple type definition of which the [content_type] is a valid restriction as defined in [Derivation Valid (Restriction, Simple)].

      2. The [ct-base_type_definition] must be mixed and have a particle which is emptiable as defined in [Particle Emptiable].

   2. ifthe [content_type] of the complex type itself is empty

      then

      1. The [content_type] of the [ct-base_type_definition] must also be empty.

      2. The [content_type] of the [ct-base_type_definition] must be elementOnly or mixed and have a particle which is emptiable as defined in [Particle Emptiable].

   3. ifthe [content_type] of the [ct-base_type_definition] is mixed or the [content_type] of the complex type definition itself is element-only

      thenthe particle of the complex type definition itself must be a valid restriction of the particle of the [content_type] of the [ct-base_type_definition] as defined in [Particle Valid (Restriction)].

NOTE: 

To restrict a complex type definition with a simple base type definition to empty, use a simple type definition with a fixed value of the empty string: this preserves the type information.

The following constraint defines a relation appealed to elsewhere in this specification.

For a complex type definition (call it D, for derived) to be validly derived from a type definition (call this B, for base) given a subset of {extension, restriction}

1. If B and D are not the same type definition, then the [derivation_method] of D must not be in the subset.

2. 1. B and D must be the same type definition.

   2. B must be D's [ct-base_type_definition].

   3. 1. D's [ct-base_type_definition] must not be the Complex Type Definition of the Ur-Type.

      2. 1. ifD's [ct-base_type_definition] is complex

            thenit must be validly derived from B given the subset as defined by this constraint.

         2. ifD's [ct-base_type_definition] is simple

            thenit must be validly derived from B given the subset as defined in [Type Derivation OK (Simple)].

NOTE: 

This constraint is used to check that when someone uses a type in a context where another type was expected (either via xsi:type or substitution groups), that the type used is actually derived from the expected type, and that that derivation does not involve a form of derivation which was ruled out by the expected type.

Built-in Complex Type Definition[top]

There is a complex type definition nearly equivalent to the ur-type definition present in every schema by definition. It has the following properties:

The mixed content specification together with the unconstrained wildcard content model and attribute specification produce the defining property for the ur-type definition, namely that every complex type definition is (eventually) a restriction of the ur-type definition: its permissions and requirements are the least restrictive possible.

NOTE: 

This specification does not provide an inventory of built-in complex type definitions for use in user schemas. A preliminary library of complex type definitions is available which includes both mathematical (e.g. rational) and utility (e.g. array) type definitions. In particular, there is a text type definition which is recommended for use as the type definition in element declarations intended for general text content, as it makes sensible provision for various aspects of internationalization. For more details, see the schema document for the type library at its namespace name: http://www.w3.org/2001/03/XMLSchema/TypeLibrary.xsd.