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.

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 signaling that an element &must.x.s; 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 becan 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 &can.xm; 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.xm; 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) 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&mustnot; 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.

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 identified as optional is required to be presentdefined as 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 &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, 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 &i-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 &i-value;. This will often be a string, but &can.xm; 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 maywill in some cases 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, it is possible that an appropriately-named component &will.xm; 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 &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.

The normalized value of an element or attribute information item is 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;

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

There are three alternative validation rules which mayhelp 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 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.xm; 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 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.xm; 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 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.

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 simple type definition 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 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 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 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.x.s; only occur as the only item in the &i-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:

None as such.

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

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 approach to defining a type by restricting another type definition set out here is designed to ensure that types defined in this way are guaranteed to be a subset of the type they restrict. This is accomplished by requiring a clear mapping between the components of the base type definition and the restricting type definition. Permissible mappings are set out below via a set of recursive definitions, bottoming out in the obvious cases, e.g. where an (restricted) element declaration corresponds to another (base) element declaration with the same name and type but the same or wider range of occurrence.

The wildcard schema component has the following properties:

The XML representation for a wildcard schema component is an or element information item. The correspondences between the properties of an information item and properties of the components it corresponds to are as follows (see and for the correspondences for ):

Wildcards are subject to the same ambiguity constraints () as other content model particles: If an instance element could match either an explicit particle and a wildcard, or one of two wildcards, within the content model of a type, that model is in error.

None as such.

All wildcards (see ) &must; satisfy the following constraint.

The following constraints define a relation appealed to elsewhere in this specification.

The &constraint; definition schema component has the following properties:

The XML representation for an &constraint; definition schema component is either a , 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:

All &constraint; definitions (see ) &must; satisfy the following constraint.

The notation declaration schema component has the following properties:

The XML representation for a notation declaration schema component is a element information item. The correspondences between the properties of that information item and properties of the component it corresponds to are as follows:

None as such.

All notation declarations (see ) &must; satisfy the following constraint.

The annotation schema component has the following properties:

Annotation of schemas and schema components, with material for human or computer consumption, is provided for by allowing application information and human information at the beginning of most major schema elements, and anywhere at the top level of schemas. The XML representation for an annotation schema component is an element information item. The correspondences between the properties of that information item and properties of the component it corresponds to are as follows:

The annotation component corresponding to the element in the example above will have one element item in each of its and and one attribute item in its .

None as such.

None as such: the addition of annotations to the &PSVI; is covered by the &PSVI; contributions of the enclosing components.

All annotations (see ) &must; satisfy the following constraint.

The simple type definition schema component has the following properties:

None as such.

All simple type definitions other than the simple ur-type definition and the built-in primitive datatype definitions (see ) &must; satisfy both the following constraints.

The following constraint defines relations appealed to elsewhere in this specification.

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

The simple ur-type definition is the root of the simple type definition hierarchy, and as such mediates between the other simple type definitions, which all eventually trace back to it via their properties, and the ur-type definition, which is its . This is why the simple ur-type definition is exempted from the first clause of , which would otherwise bar it because of its &derivation; from a complex type definition and absence of .

There is a simple type definition named anyAtomicType present in every schema by definition. It has the following properties:

Simple type definitions for all the built-in primitive datatypes, namely string, boolean, float, double, number, dateTime, duration, time, date, gMonth, gMonthDay, gDay, gYear, gYearMonth, hexBinary, base64Binary, anyURI (see the Primitive Datatypes section of &XSP2;) are present by definition in every schema. All are in the XML Schema (namespace name http://www.w3.org/2001/XMLSchema), have an atomic with an empty and the simple ur-type definitionanyAtomicType as their and themselves as .

Similarly, simple type definitions for all the built-in &derived; datatypes (see the &Derived; Datatypes section of &XSP2;) are present by definition in every schema, with properties as specified in &XSP2; and as represented in XML in .

At the abstract level, the schema itself is just a container for its components.

A schema is represented in XML by one or more schema documents, that is, one or more element information items. A schema document contains representations for a collection of schema components, e.g. type definitions and element declarations, which have a common target namespace. A schema document which has one or more element information items corresponds to a schema with components with more than one target namespace, see .

Note that none of the attribute information items displayed above correspond directly to properties of schemas. The blockDefault, finalDefault, attributeFormDefault, elementFormDefaultand targetNamespace attributes are appealed to in the sub-sections above, as they provide global information applicable to many representation/component correspondences. The other attributes (id and version) are for user convenience, and this specification defines no semantics for them.

The definition of the schema abstract data model in makes clear that most components have a target namespace. Most components corresponding to representations within a given element information item will have a target namespace which corresponds to the targetNamespace attribute.

Since the empty string is not a legal namespace name, supplying an empty string for targetNamespace is incoherent, and is not the same as not specifying it at all. The appropriate form of schema document corresponding to a schema whose components have no is one which has no targetNamespace attribute specified at all.

Although the example schema at the beginning of this section might be a complete XML document, need not be the document element, but can appear within other documents. Indeed there is no requirement that a schema correspond to a (text) document at all: it could correspond to an element information item constructed 'by hand', for instance via a DOM-conformant API.

Aside from and , which do not correspond directly to any schema component at all, each of the element information items which &may.xm; appear in the content of corresponds to a schema component, and all except are named. The sections below present each such item in turn, setting out the components to which it &may.xm; correspond.

Whenever the word resolve in any form is used in this chapter in connection with a QName in a schema document, the following definition &must.x.s; be understood:

As the discussion above at makes clear, at the level of schema components and validation, reference to components by name is normally not involved. In a few cases, however, qualified names appearing in information items being validated &must; be resolved to schema components by such lookup. The following constraint is appealed to in these cases.