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. First we 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.

An &constraint; definition is an association between a name and one of several varieties of &constraint; related to uniqueness and reference. All the varieties use expressions to pick out sets of information items relative to particular target element information items which are unique, or a key, or a valid reference, within a specified scope. An element information item is only valid with respect to an element declaration with &constraint; definitions if those definitions are all satisfied for all the descendants of that element information item which they pick out.

For detailed information on &constraint; definitions, see .

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.

&XSP1; introduces a mechanism for signalling that an element should 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 labelled 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 labelled directed graph, where the root is a schema, every other vertex is a schema component or a literal (string, boolean, number) and every labelled edge is a property. The graph is not acyclic: multiple copies of components with the same name in the same symbol space may not exist, so in some cases re-entrant chains of properties must exist. Equality of components for the purposes of this specification is always defined as equality of names (including target namespaces) within symbol spaces.

Throughout this specification, the term absent is used as a distinguished property value denoting absence.

Any property not identified as optional is required to be 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 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 &XSP1; 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, we specify 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 are in the XML Schema namespace, that is their namespace name 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 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 &i-attribute;. Since schema documents are constrained by the , there is always a simple type definition associated with any such attribute. We use the phrase actual value to refer to the member of the value space of the simple type definition associated with an &i-attribute; which corresponds to its &i-value;. This will often be a string, but may also be an integer, a boolean, a URI reference, etc. We will also occasionally use this term 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 do discharge the reference: see for details.

Throughout this specification, when we refer to the initial value of some attribute information item, we mean by this the value of the normalized value property of that item. Similarly, when we refer to the initial value of an element information item, we mean the string composed of, in order, the &i-ccode; of each character information item in the &i-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.

When we refer to the normalized value of an element or attribute information item, we mean an &r-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 &i-value;

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 1.0 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 property must match the local part of the names of attributes being validated.

A of global identifies attribute declarations available for use in complex type definitions throughout the schema. Locally scoped declarations are available for use only within the complex type definition identified by the property. This property is absent in the case of declarations within attribute group definitions: their scope will be determined when they are used in the construction of complex type definitions.

A non-absent value of the 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 validate unqualified (unprefixed) items.

The value of the attribute must conform to the supplied .

reproduces the functions of XML 1.0 default and #FIXED attribute values. default specifies that the attribute is to appear unconditionally in the &PSVI;, with the supplied value used whenever the attribute is not actually present; fixed indicates that the attribute value if present must equal the supplied constraint value, and if absent receives the supplied value as for default. Note that it is values that are supplied and/or checked, not strings.

See for information on role of the property.

distinguishes namespace declarations such as xmlns or xmlns:xsl from attributes. Accordingly, it is unnecessary and in fact not possible for schemas to contain attribute declarations corresponding to such namespace declarations, see . No means is provided in this specification to supply a default value for a namespace declaration.

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 this 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 &i-attribute;, whose default is provided by the attributeFormDefault &i-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 with no 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 property must match the local part of the names of element information items being validated.

A of global identifies element declarations available for use in content models throughout the schema. Locally scoped declarations are available for use only within the complex type identified by the property. This property is absent in the case of declarations within named model groups: their scope is determined when they are used in the construction of complex type definitions.

A non-absent value of the property provides for validation of namespace-qualified element information items. Absent values of validate unqualified items.

An element information item is valid if it satisfies the . For such an item, schema information set contributions appropriate to the are added to the corresponding element information item in the &PSVI;.

If is true, then an element may 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 ) even if it has no text or element content despite a which would otherwise require content. Formal details of element validation are described in .

establishes a default or fixed value for an element. If default is specified, 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 &PSVI;. 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 the supplied constraint value.

express constraints establishing uniquenesses and reference relationships among the values of related elements and attributes. See .

Element declarations are members of the substitution group, if any, identified by . Membership is transitive but not symmetric; an element declaration is a member of any group of which its is a member.

An empty allows a declaration to be nominated as the of other element declarations having the same or types derived therefrom. The explicit values of rule out element declarations having types which are extensions or restrictions respectively of . If both values are specified, then the declaration may not be nominated as the of any other declaration.

The supplied values for determine whether an element declaration appearing in a content model will be prevented from additionally validating elements (a) with an 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 headed by the declared element. If is empty, then all derived types and substitution group members are allowed.

Element declarations for which is true can appear in content models only when substitution is allowed; such declarations may not themselves ever be used to validate element content.

See for information on role of the property.

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 this 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 &i-attribute;, whose default is provided by the elementFormDefault &i-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 type 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 definition. This has the important consequence that the minimum valid element declaration, that is, one with only a name attribute and no contents, is also the most general, validating any combination of text and element content and allowing any attributes.

See below at for , and .