↓XML Schema 1.1↓↑W3C XML Schema Definition Language (XSD) 1.1↑ Part 1: Structures

2.2.1 Type Definition Components

The abstract model provides two kinds of type definition component: simple and complex.

[Definition:]  This specification uses the phrase type definition in cases where no distinction need be made between simple and complex types.

Type definitions form a hierarchy with a single root. The subsections below first describe characteristics of that hierarchy, then provide an introduction to simple and complex type definitions themselves.

2.2.2 Declaration Components

There are three kinds of declaration component: element, attribute, and notation. Each is described in a section below. Also included is a discussion of element substitution groups, which is a feature provided in conjunction with element declarations.

<!ELEMENT A . . .>
<!ATTLIST A . . .>

2.2.3 Model Group Components

The model group, particle, and wildcard components contribute to the portion of a complex type definition that controls an element information item's content.

2.2.4 ↓Identity-constraint Definition↓↑Constraint↑ Components

2.2.5 Group Definition Components

There are two kinds of convenience definitions provided to enable the re-use of pieces of complex type definitions: model group definitions and attribute group definitions.

2.2.6 Annotation Components

An annotation is information for human and/or mechanical consumers. The interpretation of such information is not defined in this specification.

For detailed information on annotations, see Annotations (§3.15).

2.6.1 xsi:type

The Simple Type Definition (§2.2.1.2) or Complex Type Definition (§2.2.1.3) used in ·validation· of an element is usually determined by reference to the appropriate schema components. An element information item in an instance may, however, explicitly assert its type using the attribute xsi:type. The value of this attribute is a ·QName·; see ↓QName Interpretation (§3.17.3.2)↓ ↑QName resolution (Instance) (§3.17.6.3)↑ for the means by which the ·QName· is associated with a type definition.

2.6.2 xsi:nil

XML Schema↑ Definition Language↑: Structures introduces a mechanism for signaling that an element ↓should↓↑must↑ be accepted as ·valid· when it has no content despite a content type which does not require or even necessarily allow empty content. An element ↓may be↓↑can be↑ ·valid· without content if it has the attribute xsi:nil with the value true. An element so labeled must be empty, but can carry attributes if permitted by the corresponding complex type.

2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation

The xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes can be used in a document to provide hints as to the physical location of schema documents which ↓may↓↑can↑ be used for ·assessment·. See How schema definitions are located on the Web (§4.3.2) for details on the use of these attributes.

3.1.1 Components and Properties

Components are defined in terms of their properties, and each property in turn is defined by giving its range, that is the values it ↓may↓↑may↑ have. This can be understood as defining a schema as a labeled directed graph, where the root is a schema, every other vertex is a schema component or a literal (string, boolean, ↓number↓↑decimal↑) and every labeled edge is a property. The graph is not acyclic: multiple copies of components with the same name in the same ·symbol space· ↓may not↓↑must not↑ exist, so in some cases re-entrant chains of properties ↓must↓↑will↑ exist. Equality of components for the purposes of this specification is always defined as equality of names (including target namespaces) within symbol spaces.

[Definition:]  Throughout this specification, the term absent is used as a distinguished property value denoting absence.↑ Again this should not be interpreting as constraining implementations, as for instance between using a null value for such properties or not representing them at all.↑ ↑[Definition:]   A property value which is not ·absent· is present.↑

Any property ↓not identified as optional is required to be present↓↑not defined as optional is always present↑; optional properties which are not present are taken to have ·absent· as their value. Any property identified as a having a set, subset or list value ↓may↓↑might↑ have an empty value unless this is explicitly ruled out: this is not the same as ·absent·. Any property value identified as a superset or subset of some set ↓may↓↑might↑ be equal to that set, unless a proper superset or subset is explicitly called for. By 'string' in Part 1 of this specification is meant a sequence of ISO 10646 characters identified as legal XML characters in [XML 1.1].

3.1.2 XML Representations of Components

The principal purpose of XML Schema↑ Definition Language↑: Structures is to define a set of schema components that constrain the contents of instances and augment the information sets thereof. Although no external representation of schemas is required for this purpose, such representations will obviously be widely used. To provide for this in an appropriate and interoperable way, this specification provides a normative XML representation for schemas which makes provision for every kind of schema component. [Definition:]  A document in this form (i.e. a <schema> element information item) is a schema document. For the schema document as a whole, and its constituents, the sections below define correspondences between element information items (with declarations in Schema for ↓Schemas↓↑Schema Documents (Structures)↑ (normative) (§A) and DTD for Schemas (non-normative) (§L)) and schema components. ↓All the↓↑The key↑ element information items in the XML representation of a schema ↓must be↓↑are↑ in the ↓XML Schema↓↑XSD↑ namespace, that is their [namespace name] ↓must be↓↑is↑ http://www.w3.org/2001/XMLSchema. Although a common way of creating the XML Infosets which are or contain ·schema documents· will be using an XML parser, this is not required: any mechanism which constructs conformant infosets as defined in [XML-Infoset] is a possible starting point.

3.1.3 The Mapping between XML Representations and Components

For each kind of schema component there is a corresponding normative XML representation. The sections below describe the correspondences between the properties of each kind of schema component on the one hand and the properties of information items in that XML representation on the other, together with constraints on that representation above and beyond those ↓implicit↓↑expressed↑ in the Schema for ↓Schemas↓↑Schema Documents (Structures)↑ (normative) (§A).

The language used is as if the correspondences were mappings from XML representation to schema component, but the mapping in the other direction, and therefore the correspondence in the abstract, can always be constructed therefrom.

In discussing the mapping from XML representations to schema components below, the value of a component property is often determined by the value of an attribute information item, one of the [attributes] of an element information item. Since schema documents are constrained by the Schema for ↓Schemas↓↑Schema Documents (Structures)↑ (normative) (§A), there is always a simple type definition associated with any such attribute information item. [Definition:]  ↓ The phrase actual value is used to refer to the member of the value space of the simple type definition associated with an attribute information item which corresponds to its ·normalized value·↓↑With reference to any string, interpreted as denoting an instance of a given datatype, the term actual value denotes the value to which the lexical mapping of that datatype maps the string. ↑ ↓.↓↑In the case of attributes in schema documents, the string used as the lexical representation is normally the ·normalized value· of the attribute. The associated datatype is, unless otherwise specified, the one identified in the declaration of the attribute, in the schema for schema documents; in some cases (e.g. the enumeration facet, or fixed and default values for elements and attributes) the associated datatype will be a more specific one, as specified in the appropriate XML mapping rules. The ·actual value·↑ ↓This↓ will often be a string, but ↓may↓↑can↑ also be an integer, a boolean, a URI reference, etc. This term is also occasionally used with respect to element or attribute information items in a document being ·validated·.

Many properties are identified below as having other schema components or sets of components as values. For the purposes of exposition, the definitions in this section assume that (unless the property is explicitly identified as optional) all such values are in fact present. When schema components are constructed from XML representations involving reference by name to other components, this assumption ↓may↓↑will in some cases↑ be violated if one or more references cannot be ↓resolved↓↑·resolved·↑. This specification addresses the matter of missing components in a uniform manner, described in Missing Sub-components (§5.3): no mention of handling missing components will be found in the individual component descriptions below.

Forward reference to named definitions and declarations is allowed, both within and between ·schema documents·. By the time the component corresponding to an XML representation which contains a forward reference is actually needed for ·validation·↑, it is possible that↑ an appropriately-named component ↓may↓↑will↑ have become available to discharge the reference: see Schemas and Namespaces: Access and Composition (§4) for details.

3.1.4 White Space Normalization during Validation

Throughout this specification, [Definition:]  the initial value of some attribute information item is the value of the [normalized value] property of that item. Similarly, the initial value of an element information item is the string composed of, in order, the [character code] of each character information item in the [children] of that element information item.

The above definition means that comments and processing instructions, even in the midst of text, are ignored for all ·validation· purposes.

If the simple type definition used in an item's ·validation· is ↓the ·simple ur-type definition·↓↑·xs:anySimpleType·↑, ↑then ↑the ·normalized value· must be determined as in the preserve case above.

There are three alternative validation rules which ↓may↓↑help↑ supply the necessary background for the above: Attribute Locally Valid (§3.2.4.1) (clause 3), Element Locally Valid (Type) (§3.3.4.4) (clause 3.1.3) or Element Locally Valid (Complex Type) (§3.4.4.2) (clause 2.2).

These three levels of normalization correspond to the processing mandated in XML↓ 1.0↓ for element content, CDATA attribute content and tokenized attributed content, respectively. See Attribute Value Normalization in [XML 1.1] for the precedent for replace and collapse for attributes. Extending this processing to element content is necessary to ensure ↓a↓ consistent ·validation· semantics for simple types, regardless of whether they are applied to attributes or elements. Performing it twice in the case of attributes whose [normalized value] has already been subject to replacement or collapse on the basis of information in a DTD is necessary to ensure consistent treatment of attributes regardless of the extent to which DTD-based information has been made use of during infoset construction.

3.2.1 The Attribute Declaration Schema Component

The attribute declaration schema component has the following properties:

The {name} property must match the local part of the names of attributes being ·validated·.

The value of ↓the↓ ↑each↑ attribute ↑validated↑ must conform to the supplied {type definition}.

A ↓non-·absent·↓↑·non-absent·↑ value of the {target namespace} property provides for ·validation· of namespace-qualified attribute information items (which must be explicitly prefixed in the character-level form of XML documents). ·Absent· values of {target namespace} ·validate· unqualified (unprefixed) items.

↑The↑ {value constraint} ↑property↑ reproduces the functions of XML↓ 1.0↓ default and #FIXED attribute values. ↑A {variety} of ↑default specifies that the attribute is to appear unconditionally in the ·post-schema-validation infoset·, with ↓the supplied value↓↑{value} and {lexical form}↑ used whenever the attribute is not actually present; fixed indicates that the attribute value if present must ↓equal the supplied constraint value↓↑be equal to {value}↑, and if absent receives ↓the supplied value↓↑{value} and {lexical form}↑ as for default. Note that it is values that are ↓supplied and/or ↓checked, not strings↑, and that the test is for equality, not identity↑.

See Annotations (§3.15) for information on the role of the {annotations} property.

[XML-Infoset] distinguishes attributes with names such as xmlns or xmlns:xsl from ordinary attributes, identifying them as [namespace attributes]. Accordingly, it is unnecessary and in fact not possible for schemas to contain attribute declarations corresponding to such namespace declarations, see xmlns Not Allowed (§3.2.6.3). No means is provided in this specification to supply a default value for a namespace declaration.

3.2.2 XML Representation of Attribute Declaration Schema Components

The XML representation for an attribute declaration schema component is an <attribute> element information item. It specifies a simple type definition for an attribute either by reference or explicitly, and ↓may↓↑may↑ provide default information. The correspondences between the properties of the information item and properties of the component are ↓as follows:↓↑given in this section.↑

Attribute declarations can appear at the top level of a schema document, or within complex type definitions, either as complete (local) declarations, or by reference to top-level declarations, or within attribute group definitions. For complete declarations, top-level or local, the type attribute is used when the declaration can use a built-in or pre-declared simple type definition. Otherwise an anonymous <simpleType> is provided inline. ↑When no simple type definition is referenced or provided, the default is ·xs:anySimpleType·, which imposes no constraints at all.↑

Attribute information items ·validated· by a top-level declaration must be qualified with the {target namespace} of that declaration↓ (if this is ·absent·, the item must be unqualified).↓↑. If the {target namespace} is ·absent·, the item must be unqualified.↑ Control over whether attribute information items ·validated· by a local declaration must be similarly qualified or not is provided by the form [attribute], whose default is provided by the attributeFormDefault [attribute] on the enclosing <schema>, via its determination of {target namespace}.

The names for top-level attribute declarations are in their own ·symbol space·. The names of locally-scoped attribute declarations reside in symbol spaces local to the type definition which contains them.

3.2.3 Constraints on XML Representations of Attribute Declarations

3.2.4 Attribute Declaration Validation Rules

3.2.5 Attribute Declaration Information Set Contributions

3.2.6 Constraints on Attribute Declaration Schema Components

All attribute declarations (see Attribute Declarations (§3.2)) must satisfy the following constraints.

3.2.7 Built-in Attribute Declarations

There are four attribute declarations present in every schema by definition:

3.3.1 The Element Declaration Schema Component

The element declaration schema component has the following properties:

The {name} property must match the local part of the names of element information items being ·validated·.

A ↓non-·absent·↓↑·non-absent·↑ value of the {target namespace} property provides for ·validation· of namespace-qualified element information items. ·Absent· values of {target namespace} ·validate· unqualified items.

An element information item is ↓·valid· if it satisfies↓↑normally required to satisfy↑ the {type definition}. For such an item, schema information set contributions appropriate to the {type definition} are added to the corresponding element information item in the ·post-schema-validation infoset·. ↑ The type definition against which an element information item is validated (its ·governing type definition·) can be different from the declared {type definition}. The {type table} property of an Element Declaration, which governs conditional type assignment, and the xsi:type attribute of an element information item (see xsi:type (§2.6.1)) can cause the ·governing type definition· and the declared {type definition} to be different. ↑

If {nillable} is true, then an element ↑with no text or element content↑ ↓may↓↑can↑ ↓also↓ be ·valid· ↓if it carries the namespace qualified attribute with [local name] nil from namespace http://www.w3.org/2001/XMLSchema-instance and value true (see xsi:nil (§2.6.2)) even if it has no text or element content↓ despite a ↓{content type}↓ ↑{type definition}↑ which would otherwise require content↑, if it carries the attribute xsi:nil with the value true (see xsi:nil (§2.6.2))↑. Formal details of element ·validation· are described in Element Locally Valid (Element) (§3.3.4.3).

{value constraint} establishes a default or fixed value for an element. If ↑a {value constraint} with {variety} = ↑default is ↓specified↓↑present↑, and if the element being ·validated· is empty, then ↓the canonical form of the supplied constraint value becomes the [schema normalized value] of the ·validated· element in the ·post-schema-validation infoset·.↓ ↑the element is treated as if {value constraint}.{lexical form} was used as the content of the element.↑ If fixed is specified, then the element's content must either be empty, in which case fixed behaves as default, or its value must ↓match↓↑be equal to↑ ↓the↓ ↓supplied constraint value↓↑{value constraint}.{value}↑.

{identity-constraint definitions} express constraints establishing uniquenesses and reference relationships among the values of related elements and attributes. See Identity-constraint Definitions (§3.11).

Element declarations are potential members of the ↓substitution group↓↑·substitution groups·↑, if any, identified by ↓{substitution group affiliation}↓↑{substitution group affiliations}↑. Potential membership is transitive but not symmetric; an element declaration is a potential member of any group of which ↑any entry in↑ its ↓{substitution group affiliation}↓↑{substitution group affiliations}↑ is a potential member. Actual membership ↓may↓↑may↑ be blocked by the effects of {substitution group exclusions} or {disallowed substitutions}, see below.

An empty {substitution group exclusions} allows a declaration to be ↓nominated as↓↑named in↑ the ↓{substitution group affiliation}↓↑{substitution group affiliations}↑ of other element declarations having the same ↑declared ↑{type definition} or ↓types↓↑some type↑ derived therefrom. The explicit values of {substitution group exclusions}↑, extension or restriction,↑ rule out element declarations having types ↓which are extensions or restrictions respectively of {type definition}↓↑whose derivation from {type definition} involves any extension steps, or restriction steps, respectively↑ . ↓If both values are specified, then the declaration must not be nominated as the {substitution group affiliation} of any other declaration.↓

The supplied values for {disallowed substitutions} determine whether an element declaration appearing in a ·content model· will be prevented from additionally ·validating· elements (a) with an xsi:type (§2.6.1) that identifies an extension or restriction of the type of the declared element, and/or (b) from ·validating· elements which are in the ↓substitution group↓↑·substitution group·↑ headed by the declared element. If {disallowed substitutions} is empty, then all derived types and ↓substitution group↓↑·substitution group·↑ members are allowed.

Element declarations for which {abstract} is true can appear in content models only when substitution is allowed; such declarations ↓may not↓↑must not↑ themselves ever be used to ·validate· element content.

See Annotations (§3.15) for information on the role of the {annotations} property.

3.3.2 XML Representation of Element Declaration Schema Components

The XML representation for an element declaration schema component is an <element> element information item. It specifies a type definition for an element either by reference or explicitly, and ↓may↓↑may↑ provide occurrence and default information. The correspondences between the properties of the information item and properties of the component(s) it corresponds to are ↓as follows:↓↑given in this section.↑

<element> corresponds to an element declaration, and allows the type definition of that declaration to be specified either by reference or by explicit inclusion.

<element>s within <schema> produce global element declarations; <element>s within <group> or <complexType> produce either particles which contain global element declarations (if there's a ref attribute) or local declarations (otherwise). For complete declarations, top-level or local, the type attribute is used when the declaration can use a built-in or pre-declared type definition. Otherwise an anonymous <simpleType> or <complexType> is provided inline.

Element information items ·validated· by a top-level declaration must be qualified with the {target namespace} of that declaration↓ (if this is ·absent·, the item must be unqualified).↓↑. If the {target namespace} is ·absent·, the item must be unqualified.↑ Control over whether element information items ·validated· by a local declaration must be similarly qualified or not is provided by the form [attribute], whose default is provided by the elementFormDefault [attribute] on the enclosing <schema>, via its determination of {target namespace}.

As noted above the names for top-level element declarations are in a separate ·symbol space· from the symbol spaces for the names of type definitions, so there can (but need not be) a simple or complex type definition with the same name as a top-level element. As with attribute names, the names of locally-scoped element declarations with no {target namespace} reside in symbol spaces local to the type definition which contains them.

Note that the above allows for two levels of defaulting for unspecified type definitions. An <element> with no referenced or included type definition will correspond to an element declaration which has ↓the same type definition as the head of its substitution group if it identifies one, ↓ ↑the same type definition as the first substitution-group head named in the substitutionGroup [attribute], if present,↑ otherwise ↓the ·ur-type definition·↓↑·xs:anyType·↑. This has the important consequence that the minimum valid element declaration, that is, one with only a name attribute and no contents, is also (nearly) the most general, validating any combination of text and element content and allowing any attributes, and providing for recursive validation where possible.

See below at XML Representation of Identity-constraint Definition Schema Components (§3.11.2) for <key>, <unique> and <keyref>.

<xs:element name="unconstrained"/>

<xs:element name="emptyElt">
 <xs:complexType>
  <xs:attribute ...>. . .</xs:attribute>
 </xs:complexType>
</xs:element>

<xs:element name="contextOne">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="myLocalElement" type="myFirstType"/>
   <xs:element ref="globalElement"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>

<xs:element name="contextTwo">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="myLocalElement" type="mySecondType"/>
   <xs:element ref="globalElement"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>

 <xs:complexType name="facet">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:attribute name="value" use="required"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>

 <xs:element name="facet" type="xs:facet" abstract="true"/>

 <xs:element name="encoding" substitutionGroup="xs:facet">
  <xs:complexType>
   <xs:complexContent>
    <xs:restriction base="xs:facet">
     <xs:sequence>
      <xs:element ref="annotation" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="value" type="xs:encodings"/>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:element name="period" substitutionGroup="xs:facet">
  <xs:complexType>
   <xs:complexContent>
    <xs:restriction base="xs:facet">
     <xs:sequence>
      <xs:element ref="annotation" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="value" type="xs:duration"/>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:complexType name="datatype">
  <xs:sequence>
   <xs:element ref="facet" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="name" type="xs:NCName" use="optional"/>
  . . .
 </xs:complexType>

<xs:complexType name="messageType" mixed="true">
 <xs:sequence>
  <xs:any processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
 </xs:sequence>
 <xs:attribute name="kind">
  <xs:simpleType>
   <xs:union>
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="string"/>
      <xs:enumeration value="base64"/>
      <xs:enumeration value="binary"/>
      <xs:enumeration value="xml"/>
      <xs:enumeration value="XML"/>
     </xs:restriction>
    </xs:simpleType>
    <xs:simpleType>
     <xs:restriction base="xs:string"/>
    </xs:simpleType>
   </xs:union>
  </xs:simpleType>
 </xs:attribute>
 <xs:anyAttribute processContents="skip"/>
</xs:complexType>

<xs:complexType name="messageTypeString">
 <xs:simpleContent>
  <xs:restriction base="messageType">
   <xs:simpleType>
    <xs:restriction base="xs:string"/>
   </xs:simpleType>
  </xs:restriction>
 </xs:simpleContent>
</xs:complexType>

<xs:complexType name="messageTypeBase64">
 <xs:simpleContent>
  <xs:restriction base="messageType">
   <xs:simpleType>
    <xs:restriction base="xs:base64Binary"/>
   </xs:simpleType>
  </xs:restriction>
 </xs:simpleContent>
</xs:complexType>

<xs:complexType name="messageTypeXML">
 <xs:complexContent>
  <xs:restriction base="messageType">
   <xs:sequence>
    <xs:any processContents="strict"/>
   </xs:sequence>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>

<xs:element name="message" type="messageType">
  <xs:alternative test="@kind='string'" type="messageTypeString"/>
  <xs:alternative test="@kind='base64'" type="messageTypeBase64"/>
  <xs:alternative test="@kind='binary'" type="messageTypeBase64"/>
  <xs:alternative test="@kind='xml'"    type="messageTypeXML"/>
  <xs:alternative test="@kind='XML'"    type="messageTypeXML"/>
</xs:element>

3.3.3 Constraints on XML Representations of Element Declarations