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 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 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, 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 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 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 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 &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;

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.

The value of the attribute must conform to the supplied .

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.

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.

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 the role of the property.

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

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:

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

As described in , each complex type is derived from a which is itself either a or a . specifies the means of derivation as either extension or restriction (see ).

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

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

are a set of attribute uses. See and for details of attribute validation.

s provide a more flexible specification for validation of attributes not explicitly included in . Informally, the specific values of are interpreted as follows:

any: &i-attributes; can include attributes with any qualified or unqualified name.

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.

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

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

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

The attribute use schema component has the following properties:

determines whether this use of an attribute declaration requires an appropriate attribute information item to be present, or merely allows it.

provides the attribute declaration itself, which will in turn determine the simple type definition used.

allows for local specification of a default or fixed value. This must be consistent with that of the , in that if the specifies a fixed value, the only allowed is the same fixed value.

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:

Attribute groups are identified by their and ; attribute group identities must be unique within an XML Schema. See for the use of component identifiers when importing one schema into another.

is a set attribute uses, allowing for local specification of occurrence and default or fixed values.

provides for an attribute wildcard to be included in an attribute group. See above under for the interpretation of attribute wildcards during validation.

See for information on the role of the property.

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:

Model group definitions are identified by their and ; model group identities must be unique within an XML Schema. See for the use of component identifiers when importing one schema into another.

Model group definitions per se do not participate in validation, but the of a particle may correspond in whole or in part to a model group from a model group definition.

is the for which the model group definition provides a name.

See for information on the role of the property.

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 should 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:

specifies a sequential (sequence), disjunctive (choice) or conjunctive (all) interpretation of the . This in turn determines whether the element information item &i-children; validated by the model group must:

(sequence) correspond, in order, to the specified ;

When two or more particles contained directly or indirectly in the of a model group have identically named element declarations as their , the type definitions of those declarations must be the same. By 'indirectly' is meant particles within the of a group which is itself the of a directly contained particle, and so on recursively.

See for information on the role of the property.

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:

In general, multiple element information item &i-children;, possibly with intervening character &i-children; if the content type is mixed, can be validated with respect to a single particle. When the is an element declaration or wildcard, determines the minimum number of such element &i-children; that can occur. The number of such children must be greater than or equal to . If is 0, then occurrence of such children is optional.

Again, when the is an element declaration or wildcard, the number of such element &i-children; must be less than or equal to any numeric specification of ; if is unbounded, then there is no upper bound on the number of such children.

When the is a model group, the permitted occurrence range is determined by a combination of and and the occurrence ranges of the 's .

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:

provides for validation of attribute and element items that:

(any) have any namespace or are not namespace qualified;

controls the impact on assessment of the information items allowed by wildcards, as follows: strict

There must be a top-level declaration for the item available, or the item must have an xsi:type, and the item must be valid as appropriate.

See for information on the role of the property.

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:

&Constraint; definitions are identified by their and ; &Constraint; definition identities must be unique within an XML Schema. See for the use of component identifiers when importing one schema into another.

Informally, identifies the &Constraint; definition as playing one of three roles:

(unique) the &Constraint; definition asserts uniqueness, with respect to the content identified by , of the tuples resulting from evaluation of the XPath expression(s).

These constraints are specified along side the specification of types for the attributes and elements involved, i.e. something declared as of type integer may also serve as a key. Each constraint declaration has a name, which exists in a single symbol space for constraints. The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. Values of differing type can only be equal if one type is derived from the other, and the value is in the value space of both.

Overall the augmentations to XML's ID/IDREF mechanism are:

specifies a restricted XPath () expression relative to instances of the element being declared. This must identify a node set of subordinate elements (i.e. contained within the declared element) to which the constraint applies.

specifies XPath expressions relative to each element selected by a . This must identify a single node (element or attribute) whose content or value, which must be of a simple type, is used in the constraint. It is possible to specify an ordered list of s, to cater to multi-field keys, keyrefs, and uniqueness constraints.

In order to reduce the burden on implementers, in particular implementers of streaming processors, only restricted subsets of XPath expressions are allowed in and . The details are given in .

See for information on the role of the property.

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:

Notation declarations do not participate in validation as such. They are referenced in the course of validating strings as members of the NOTATION simple type.

See for information on the role of the property.

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:

is intended for human consumption, for automatic processing. In both cases, provision is made for an optional URI reference to supplement the local information, as the value of the source attribute of the respective element information items. Validation does not involve dereferencing these URIs, when present. In the case of , indication should be given as to the identity of the (human) language used in the contents, using the xml:lang attribute.

ensures that when schema authors take advantage of the provision for adding attributes from namespaces other than the XML Schema namespace to schema documents, they are available within the components corresponding to the element items where such attributes appear.

Annotations do not participate in validation as such. Provided an annotation itself satisfies all relevant Schema Component Constraints it cannot affect the validation of element information items.

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:

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

A simple type definition with an empty specification for can be used as the for other types derived by either of extension or restriction, or as the in the definition of a list, or in the of a union; the explicit values extension, restriction, list and union prevent further derivations by extension (to yield a complex type) and restriction (to yield a simple type) and use in constructing lists and unions respectively.

determines whether the simple type corresponds to an atomic, list or union type as defined by &XSP2;.

As described in , every simple type definition is a restriction of some other simple type (the ), which is the simple ur-type definition if and only if the type definition in question is one of the built-in primitive datatypes, or a list or union type definition. Each atomic type is ultimately a restriction of exactly one such built-in simple .

for each simple type definition are selected from those defined in &XSP2;. For atomic definitions, these are restricted to those appropriate for the corresponding . Therefore, the value space and lexical space (i.e. what is validated by any atomic simple type) is determined by the pair (, ).

As specified in &XSP2;, list simple type definitions validate space separated tokens, each of which conforms to a specified simple type definition, the . The item type specified must not itself be a list type, and must be one of the types identified in &XSP2; as a suitable item type for a list simple type. In this case the apply to the list itself, and are restricted to those appropriate for lists.

A union simple type definition validates strings which satisfy at least one of its . As in the case of list, the apply to the union itself, and are restricted to those appropriate for unions.

As discussed in , the ur-type definition functions as a simple type when used as the base type definition for the built-in primitive datatypes and for list and union type definitions. It is considered to have an unconstrained lexical space, and a value space consisting of the union of the value spaces of all the built-in primitive datatypes and the set of all lists of all members of the value spaces of all the built-in primitive datatypes.

The simple ur-type definition must not be named as the base type definition of any user-defined simple types: as it has no constraining facets, this would be incoherent.

See for information on the role of the property.

None as such.

All simple type definitions (see ) must satisfy 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 version of the ur-type definition 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;), as well as for the simple and complex ur-type definitions (as previously described), 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 definition as their base type definition 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 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 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 should 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.

All schemas (see ) must satisfy the following constraint.

Schema components for a single target namespace can be assembled from several schema documents, that is several element information items:

A information item may contain any number of elements. Their schemaLocation attributes, consisting of a URI reference, identify other schema documents, that is information items.

The XML Schema corresponding to contains not only the components corresponding to its definition and declaration &i-children;, but also all the components of all the XML Schemas corresponding to any d schema documents. Such included schema documents must either (a) have the same targetNamespace as the ing schema document, or (b) no targetNamespace at all, in which case the d schema document is converted to the ing schema document's targetNamespace.

In order to provide some support for evolution and versioning, it is possible to incorporate components corresponding to a schema document with modifications. The modifications have a pervasive impact, that is, only the redefined components are used, even when referenced from other incorporated components, whether redefined themselves or not.

A information item may contain any number of elements. Their schemaLocation attributes, consisting of a URI reference, identify other schema documents, that is information items.

The XML Schema corresponding to contains not only the components corresponding to its definition and declaration &i-children;, but also all the components of all the XML Schemas corresponding to any d schema documents. Such schema documents must either (a) have the same targetNamespace as the ing schema document, or (b) no targetNamespace at all, in which case the d schema document is converted to the ing schema document's targetNamespace.

The definitions within the element itself are restricted to be redefinitions of components from the d schema document, in terms of themselves. That is,

Type definitions must use themselves as their base type definition;

As described in , every top-level schema component is associated with a target namespace (or, explicitly, with none). This section sets out the exact mechanism and syntax in the XML form of schema definition by which a reference to a foreign component is made, that is, a component with a different target namespace from that of the referring component.

Two things are required: not only a means of addressing such foreign components but also a signal to schema-aware processors that a schema document contains such references:

The element information item identifies namespaces used in external references, i.e. those whose QName identifies them as coming from a different namespace (or none) than the enclosing schema document's targetNamespace. The &v-value; of its namespace &i-attribute; indicates that the containing schema document may contain qualified references to schema components in that namespace (via one or more prefixes declared with namespace declarations in the normal way). If that attribute is absent, then the import allows unqualified reference to components with no target namespace. Note that components to be imported need not be in the form of a schema document; the processor is free to access or construct components using means of its own choosing.

The &v-value; of the schemaLocation, if present, gives a hint as to where a serialization of a schema document with declarations and definitions for that namespace (or none) may be found. When no schemaLocation &i-attribute; is present, the schema author is leaving the identification of that schema to the instance, application or user, via the mechanisms described below in . When a schemaLocation is present, it must contain a single URI reference which the schema author warrants will resolve to a serialization of a schema document containing the component(s) in the ed namespace referred to elsewhere in the containing schema document.

For interoperability, serialized schema documents, like all other Web resources, may be identified by URI and retrieved using the standard mechanisms of the Web (e.g. http, https, etc.) Such documents on the Web must be part of XML documents (see ), and are represented in the standard XML schema definition form described by layer 2 (that is as element information items).

As described in , processors are responsible for providing the schema components (definitions and declarations) needed for assessment. This section introduces a set of normative conventions to facilitate interoperability for instance and schema documents retrieved and processed from the Web.

Processors on the Web are free to undertake assessment against arbitrary schemas in any of the ways set out in . However, it is useful to have a common convention for determining the schema to use. Accordingly, general-purpose schema-aware processors (i.e. those not specialized to one or a fixed set of pre-determined schemas) undertaking assessment of a document on the web must behave as follows:

unless directed otherwise by the user, assessment is undertaken on the document element information item of the specified document;

The composition of the complete schema for use in assessment is discussed in above. The means used to locate appropriate schema document(s) are processor and application dependent, subject to the following requirements:

Improved or alternative conventions for Web interoperability can be standardized in the future without reopening this specification. For example, the W3C is currently considering initiatives to standardize the packaging of resources relating to particular documents and/or namespaces: this would be an addition to the mechanisms described here for layer 3. This architecture also facilitates innovation at layer 2: for example, it would be possible in the future to define an additional standard for the representation of schema components which allowed e.g. type definitions to be specified piece by piece, rather than all at once.