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

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.

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.

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

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.

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 .

The or 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 for the means by which the QName is associated with a type definition.

XML Schema: Structures introduces a mechanism for signaling that an element 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 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.

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 be used for assessment. See for details on the use of these attributes.

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 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, 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 must not exist, so in some cases re-entrant chains of properties will exist. Equality of components for the purposes of this specification is always defined as equality of names (including target namespaces) within symbol spaces.

Component properties are simply named values. Most properties have either other components or literals (that is, strings or booleans or enumerated keywords) for values, but in a few cases, where more complex values are involved, a property value may itself be a collection of named values, which we call a property record.

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.

Any property 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 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 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 .

The principal purpose of XML Schema: 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. A document in this form (i.e. a 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 and ) and schema components. All the element information items in the XML representation of a schema must be in the XML Schema namespace, that is their namespace name must be 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 is a possible starting point.

Two aspects of the XML representations of components presented in the following sections are constant across them all:

All of them allow attributes qualified with namespace names other than the XML Schema namespace itself: these appear as annotations in the corresponding schema component;

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 in the .

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 , there is always a simple type definition associated with any such attribute information item. 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. This will often be a string, but may 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 be violated if one or more references cannot be resolved. This specification addresses the matter of missing components in a uniform manner, described in : 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 an appropriately-named component may have become available to discharge the reference: see for details.

Throughout this specification, 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.

The normalized value of an element or attribute information item is an initial value whose white space, if any, has been normalized according to the value of the whiteSpace facet of the simple type definition used in its validation: preserve

No normalization is done, the value is the normalized value

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

There are three alternative validation rules which may supply the necessary background for the above: (), () or ().

These three levels of normalization correspond to the processing mandated in XML for element content, CDATA attribute content and tokenized attributed content, respectively. See Attribute Value Normalization in 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.

The attribute declaration schema component has the following properties:

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

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 is provided inline.

The default when no simple type definition is referenced or provided is the simple ur-type definition, which imposes no constraints at all.

Attribute information items validated by a top-level declaration must be qualified with the of that declaration. If the 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 , via its determination of .

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.

All attribute declarations (see ) must satisfy the following constraints.

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

The element declaration schema component has the following properties:

The XML representation for an element declaration schema component is an element information item. It specifies a type definition for an element either by reference or explicitly, and 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:

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

s within produce global element declarations; s within or 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 or is provided inline.

Element information items validated by a top-level declaration must be qualified with the of that declaration. If the 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 , via its determination of .

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 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 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, otherwise the ur-type definitiondefinition of 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 for , and .

All element declarations (see ) must satisfy the following constraint.

The following constraints define relations appealed to elsewhere in this specification.

One element declaration is validly substitutable for another if together they satisfy constraint .

A complex type definition schema component has the following properties:

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

The XML representation for complex type definitions with a with simple is significantly different from that of those with other 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.

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.

All complex type definitions (see ) must satisfy the following constraints.

A complex type T is a valid extension of its if and only if T has a of extension and satisfies the constraint .

A type definition R is a valid restriction of another type definition B if and only if:

All element information items which are abstractly valid against R are abstractly valid against B.

An attribute or element information item I is abstractly valid with respect to a simple or complex type definition D if and only if schema-validity assessment of I with respect to D (as defined by or ) either results in a validity property of valid, or would result in validity of valid if constraints on the abstractness of type definitions and element declarations were ignored.

In practice, it is difficult to enforce the definition above directly as a Constraint on Components, owing to a number of corner cases which are difficult to detect or describe concisely. The following constraint is the operationally normative statement.

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

There is a corresponding to the root of the type hierarchy present in every schema by definition:

The outer particle of rootType contains a simple sequence:

The inner particle of rootType contains a skip wildcard:

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

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

The outer particle of anyType contains a sequence with a single term:

The inner particle of anyType contains a wildcard which matches any element:

The attribute use schema component has the following properties:

Attribute uses correspond to all uses of which allow a use attribute. These in turn correspond to two components in each case, an attribute use and its (although note the latter is not new when the attribute use is a reference to a top-level attribute declaration). The appropriate mapping is described in .

None as such.

None as such.

All attribute uses (see ) must satisfy the following constraints.

The attribute group definition schema component has the following properties:

The XML representation for an attribute group definition schema component is an element information item. It provides for naming a group of attribute declarations and an attribute wildcard for use by reference in the XML representation of complex type definitions and other attribute group definitions. The correspondences between the properties of the information item and properties of the component it corresponds to are as follows:

The example above illustrates a pattern which recurs in the XML representation of schemas: The same element, in this case attributeGroup, serves both to define and to incorporate by reference. In the first case the name attribute is required, in the second the ref attribute is required, and the element must be empty. These two are mutually exclusive, and also conditioned by context: the defining form, with a name, must occur at the top level of a schema, whereas the referring form, with a ref, must occur within a complex type definition or an attribute group definition.

None as such.

None as such.

All attribute group definitions (see ) must satisfy the following constraint.

The model group definition schema component has the following properties:

The XML representation for a model group definition schema component is a element information item. It provides for naming a model group for use by reference in the XML representation of complex type definitions and model groups. The correspondences between the properties of the information item and properties of the component it corresponds to are as follows:

The name of this section is slightly misleading, in that the second, un-named, case above (with a ref and no name) is not really a named model group at all, but a reference to one. Also note that in the first (named) case above no reference is made to minOccurs or maxOccurs: this is because the schema for schemas does not allow them on the child of when it is named. This in turn is because the and of the particles which refer to the definition are what count.

Given the constraints on its appearance in content models, an must only occur as the only item in the children of a named model group definition or a content model: see .

None as such.

None as such.

All model group definitions (see ) must satisfy the following constraint.

The model group schema component has the following properties:

The XML representation for a model group schema component is either an , a or a element information item. The correspondences between the properties of those information items and properties of the component they correspond to are as follows:

In order to define the validation rules for model groups clearly, it will be useful to define some basic terminology; this is done in the next two sections, before the validation rules themselves are formulated.

None as such.

All model groups (see ) must satisfy the following constraints.

The attributions of a sequence S of element information items, when S is checked against a particle P, are the element or wildcard particles in P with which the items in S are matched. It is the sequence of these which forms the of S in P. When is non-deterministic, then each element information item in S is attributed to to the it matches up with in the unique , not to any other . Element information items are attributed to element particles only when the element's expanded name matches the of the , and to wildcard particles only then the element's namespace matches the . In addition, the attribution of element information items to must respect the structure (sequence, choice, and , etc.) of the and of nested within its . The rules are given in more detail in and , and in Validation Rule .

An element particle is a whose is an . A wildcard particle is a whose is a .

The following constraints define relations appealed to elsewhere in this specification.

The particle schema component has the following properties:

Particles correspond to all three elements ( not immediately within , not immediately within and ) which allow minOccurs and maxOccurs attributes. These in turn correspond to two components in each case, a particle and its . The appropriate mapping is described in , and respectively.

None as such.

None as such.

All particles (see ) must satisfy the following constraints.

The following constraints define relations appealed to elsewhere in this specification.

The wildcard schema component has the following properties: