The purpose of &XSP1; is to define the nature of XML schemas and their component parts, provide an inventory of XML markup constructs with which to represent schemas, and define the application of schemas to XML documents.

The purpose of an &XSP1; schema is to define and describe a class of XML documents by using schema components to constrain and document the meaning, usage and relationships of their constituent parts: datatypes, elements and their content and attributes and their values. Schemas may also provide for the specification of additional document information, such as default values for attributes and elements. Schemas have facilities for self-documentation. Thus, &XSP1; can be used to define, describe and catalogue XML vocabularies for classes of XML documents.

Any application that consumes well-formed XML can use the &XSP1; formalism to express syntactic, structural and value constraints applicable to its document instances. The &XSP1; formalism allows a useful level of constraint checking to be described and validated for a wide spectrum of XML applications. However, the language defined by this specification does not attempt to provide all the facilities that might be needed by any application. Some applications may require constraint capabilities not expressible in this language, and so may need to perform their own additional validations.

The definition of &XSP1; depends on the following specifications: , , , , and . If the XML Base proposal is adopted before we go to REC, we will need to account for any changes it makes to the Infoset in the areas of QName interpretation and value space and the interpretation of all aspects of schemas involving values identified as being of type uriReference, including in particular xsi:schemaLocation, xsi:noNamespaceSchemaLocation and targetNamespace.

The following highlighting and typography is used to present technical material in this document:

Special terms are defined at their point of introduction in the text; hyperlinks connect other uses of the term to the definition. For example, a definition of term might read: A term is something we use a lot. The definition is labeled as such and the term is highlighted typographically. The end of the definition is not specially marked in the displayed or printed text.

Non-normative examples are set off typographically and accompanied by a brief explanation:

References to properties of information items as defined in are notated as links to the relevant section thereof, set off with square brackets, for example &i-children;.

The definition of each kind of schema component consists of a list of its properties and their contents, followed by descriptions of the semantics of the properties:

References to properties of schema components are notated as links to the relevant definition as exemplified above, set off with curly braces, for instance .

The correspondence between an element information item which is part of the XML representation of a schema and one or more schema components is presented in a tableau which illustrates the element information item(s) involved, followed by a tabulation of the correspondence between properties of the component and properties of the information item. Where context may determine which of several different components may arise, several tabulations, one per component, are given. In the XML representation, bold-face attribute names (e.g. count below) indicate a required attribute information item, and the rest are optional. Where an attribute information item has an enumerated type definition, the values are shown separated by vertical bars, as for size below; if there is a default value, it is shown following a colon. The allowed content of the information item is shown as a grammar fragment, using the Kleene operators ?, * and +. The property correspondences are normative, but the illustration of the XML representation element information items is not.

The following highlighting is used for non-normative commentary in this document:

An XML Schema consists of components such as type definitions and element declarations. These can be used to assess the validity of well-formed element information items (as defined in ), and furthermore may specify augmentations to those items and their descendants. This augmentation makes explicit information which may have been implicit in the original document, such as default values for attributes and elements and the types of element and attribute information items.

The process of schema validation consists of determining whether an element information item satisfies the constraints embodied in the components of an XML Schema, and if so of adding any appropriate augmentations.

This specification builds on and . The concepts and definitions used herein regarding XML are framed at the abstract level of information items as defined in . By definition, this use of the infoset provides a priori guarantees of well-formedness (as defined in ) and namespace conformance (as defined in ) for all candidates for schema-validity and for all schema documents.

Just as and can be described in terms of information items, XML Schemas can be described in terms of an abstract data model. In defining XML Schemas in terms of an abstract data model, this specification rigorously specifies the information which must be available to a conforming XML Schema processor. The abstract model for schemas is conceptual only, and does not mandate any particular implementation or representation of this information. To facilitate interoperation and sharing of schema information, a normative interchange format for schemas is described in

Schema component is the generic term for the building blocks that comprise the abstract data model of the schema. An XML Schema is a set of schema components. There are 12 kinds of component in all, falling into three groups. The primary components are as follows. They may have names, and (except for some element declarations) may be independently accessed:

The secondary components are as follows. Like the primary components, they may have names and be independently accessed:

Finally, the helper components provide small parts of other components; they are not independent of their context and cannot be independently accessed:

During validation, declaration components are associated by (qualified) name to information items being validated.

On the other hand, definition components define internal schema components that can be used in other schema components.

Declarations and definitions may have and be identified by names, which are NCNames as defined by .

Several kinds of component have a target namespace, which is either absent or a namespace URI, also as defined by . The target namespace serves to identify the namespace within which the association between the component and its name exists. In the case of declarations, this in turn determines the namespace URI of, for example, the element information items it may validate.

Schema-validity, defined in detail in , is a relation between information items and schema components. For example, an attribute information item may be schema-valid with respect to an attribute declaration, a list of element information items may be schema-valid with respect to a content model, and so on. The following sections briefly introduce the kinds of components in the schema abstract data model, other major features of the abstract model, and how they contribute to the overall definition of schema-validity.

The specification describes two kinds of constraints on XML documents: well-formedness and validity constraints. Informally, the well-formedness constraints are those imposed by the definition of XML itself (such as the rules for the use of the < and > characters and the rules for proper nesting of elements), while validity constraints are the further constraints on document structure provided by a particular DTD.

The preceding section focussed on schema-validity, that is the constraints on information items which schema components supply. In fact however this specification provides four different kinds of normative statements about schema components, their representations in XML and their contribution to the schema-validation of information items:

The definition of the above constraints sometimes involves many clauses, some as alternatives, some as joint requirements. The presentations below number all clauses: clauses at the same level are either clearly identified as alternatives with words such as either and or, or should be understood as joint.

Schema information set contributions are not new. XML 1.0 validation augments the XML 1.0 information set in similar ways, for example by providing values for attributes not present in instances, and by implicitly exploiting type information for normalisation or access. (As an example of the latter case, consider the effect of NMTOKENS on attribute whitespace, and the semantics of ID and IDREF.) By including schema information set contributions, this specification makes explicit some features that XML 1.0 left implicit.

This specification describes three levels of conformance for schema aware processors. The first is required of all processors. Support for the other two will depend on the application environments for which the processor is intended.

Minimally conforming processors must completely and correctly implement the Constraints on Schemas, Validity Contributions, and Schema Information Set Contributions contained in this specification.

Processors which accept schemas in the form of XML documents as described in are additionally said to provide conformance to the XML Representation of Schemas. Such processors must, when processing schema documents, completely and correctly implement all Schema Representation Constraints in this specification, and must adhere exactly to the specifications in for mapping the contents of such documents to schema components for use in validation.

Fully conforming processors are network-enabled processors which support both levels of conformance described above, and which must additionally be capable of accessing schema documents from the World Wide Web according to and . .

See for a more detailed explanation of the mechanisms supporting these levels of conformance.

As discussed in , most schema components (may) have names. If all such names were assigned from the same pool, then it would be impossible to have, for example, a simple type definition and an element declaration both with the name title in a given target namespace.

This specification therefore introduces the term symbol space to denote a collection of names, each of which is unique with respect to the others. A symbol space is similar to the non-normative concept of namespace partition introduced in . There is a single distinct symbol space within a given target namespace for each kind of definition and declaration component identified in , except that within a target namespace, simple type definitions and complex type definitions share a symbol space. Within a given symbol space, names are unique, but the same name may appear in more than one symbol space without conflict. For example, the same name can appear in both a type definition and an element declaration, without conflict or necessary relation between the two.

Locally scoped attribute and element declarations are special with regard to symbol spaces. Every complex type definition defines its own local attribute and element declaration symbol spaces, where these symbol spaces are distinct from each other and from any of the other symbol spaces. So, for example, two complex type definitions having the same target namespace can contain a local attribute declaration for the unqualified name priority, or contain a local element declaration for the name address, without conflict or necessary relation between the two.

The XML representation of schema components uses a vocabulary identified by the namespace URI &XMLSchemaNS;. &XSP1; also defines several attributes for direct use in XML documents. These attributes are in a different namespace, which has the namespace URI &XMLSchemaInstanceNS;. For brevity, the text and examples in this specification use the prefix xsi: to stand for this latter namespace; in practice, any prefix can be used.

On the World Wide Web, schemas are conventionally represented as documents of MIME type "text/xml", conforming to the specifications in . For more information on the representation and use of schema documents on the World Wide Web see and .

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

See for the XML representation of schemas and for constraints on schemas as such.

Attribute declarations provide for:

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 1 specifies that the corresponding attribute must be present; a value of 0 allows for optional attributes. Similarly, a of 0 indicates an attribute that must not be present; a value of 1 (the normal case) allows the attribute to occur explicitly. The XML representation does not require two attributes to specify these properties, but rather uses a single use &i-attribute; with values such as optional and required: see for details.

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 also absent in the case of non-global 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. fixed indicates that the attribute value must match the supplied constraint string; default specifies that the attribute is to appear unconditionally in the post-schema-validation information set, with the supplied value used whenever the attribute is not actually present. As for and the XML representation reflects this information indirectly: see .

See for the significance 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.

See for the XML representation of attribute declarations and for constraints on attribute declaration components as such.

Element declarations provide for:

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 non-global declarations within named model groups: 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 element information items. absent values of validate unqualified items.

An element information item is schema-valid if it obeys the schema validity constraints of the . For such an item, the schema information set contributions from the are applied to the corresponding element information item in the post-schema-validation information set. must not be an abstract type definition.

If is true, then an element is also schema-valid if it carries the namespace qualified attribute with local name null from namespace &XMLSchemaInstanceNS; 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 supplied constraint string becomes character &i-children; of the validated element in the post-schema-validation infoset. If fixed is specified, then the element's content must either be empty, in which case fixed behaves as default, or it must match the supplied constraint string.

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

Element declarations are members of the equivalence class, if any, identified by . Membership is transitive but not symmetric; an element declaration is implicitly a member of any class 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 same equivalence class as the declared element. If is empty, then all derived types and equivalence class members are valid.

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

See for the XML representation of element declarations and for constraints on element declaration components as such.

Complex Type Definitions provide for:

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 (specifically in and ). 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: no further derivations are possible.

A complex type for which is true must not appear as the of an , and must not be referenced from an attribute in an instance document; such abstract complex types can be used as s, but they are never used directly to validate element content.

are a set of individual s to be used for schema-validating the &i-attributes; of element information items. 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.

A schema can name a group of attribute declarations so that they may be incorporated as a group into complex type definitions.

Attribute group definitions do not participate in schema-validation as such, but the and of one or more complex type definitions may be constructed in whole or part by reference to an attribute group. Thus, attribute group definitions provide a replacement for some uses of XML's parameter entities. Attribute group definitions are provided primarily for reference from the (see and ).

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 of attribute declarations specifically identified as members of the attribute group.

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

See and for formal details of attribute wildcard validation. See for the XML representation of attribute group definitions, and for constraints on attribute group definition components as such.

A model group definition associates a name and optional annotations with a . By reference to the name, the entire model group can be incorporated by reference into a .

Model group definitions are provided primarily for reference from the (see and ). Thus, model group definitions provide a replacement for some uses of XML's parameter entities.

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 schema-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 the XML representation of model group definitions and for constraints on model group definition components as such.

When the &i-children; of element information items are not constrained to be empty or by reference to a simple type definition (), the sequence of element information item &i-children; content may be specified in more detail with a model group. Because the property of a particle can be a model group, and model groups contain particles, model groups can indirectly contain other model groups; the grammar for content models is therefore recursive.

The model group schema component has the following properties:

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 element declarations with the same identity occur at any level within a model group, their type definitions must be the same.

Description to be supplied in a future draft.

See for the XML representation of model groups and for constraints on model group components as such.

As described in , particles contribute to the definition of content models. The particle schema component has the following properties:

The following is an informal overview of the properties of a particle. Formal interpretation of these properties is found in .

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. determines the minimum number of such element &i-children; that can validly occur. The number of such children must be greater than or equal to . If is 0, then occurrence of such children is optional.

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.

See for the XML representation of particles and for constraints on particle components as such.

In order to exploit the full potential for extensibility offered by XML plus namespaces, more provision is needed than DTDs allow for targeted flexibility in content models and attribute declarations. A wildcard provides for validation of attribute and element information items dependent on their namespace URI, but independently of their local name. The wildcard schema component has the following properties:

provides for validation of elements that:

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

controls the impact on schema-validity of the information items allowed by wildcards, as follows: strict

There must be a global declaration for the item available, and it must be schema-valid with respect to that definition.

See for the XML representation of wildcards and for constraints on wildcard components as such.

&Constraint; definition components provide for uniqueness and reference constraints with respect to the contents of multiple elements and attributes. 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(s).

These constraints are specified independently of the types of the attributes and elements involved, i.e. something declared as of type integer may also serve as a key, unlike ID and IDREF. 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 applies to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both decimal, but non-conflicting if they were both strings, or one was a string and one a decimal.

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

specifies an XPath expression relative to instances of the element being declared. This must identify a node set of subelements (i.e. elements 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, not necessarily within the selected element) 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.

A formal description of &Constraint; definition validation is given below in

See for the XML representation of &constraint; definitions and for constraints on &constraint; definition components as such.

The notation declaration schema component has the following properties:

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

See for the XML representation of notation declarations and for constraints on notation declaration components as such.

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. Schema validation does not involve dereferencing these URIs, when present. In the case of , indication may be given as to the identity of the (human) language used in the contents, using the xml:lang attribute.

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

See for the XML representation of annotations and for constraints on annotation components as such.

Simple type definitions provide for constraining character information item &i-children; of element and attribute information items. 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 (specifically in and ). See for the use of component identifiers when importing one schema into another.

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

As described in , every atomic simple type definition is a restriction of some other simple , which is itself either a simple type definition or the ur-type definition. Each atomic type is ultimately a restriction of exactly one built-in simple .

for each atomic simple type definition are selected from those defined in &XSP2; for the corresponding . Therefore, the value space and lexical space (I.e. the content validated by) any atomic simple type is determined by the pair {, }.

As specified in &XSP2;, list simple types validate whitespace separated tokens, each of which conforms to the specified . The base type specified must not itself be a list type, and must be one of the types identified in &XSP2; as a suitable base for a list simple type.

Simple type definitions for all the built-in primitive datatypes, namely string, boolean, float, double, decimal, timeInstant, timeDuration, recurringInstant, binary, uri (see the Primitive Datatypes section of &XSP2;), as well as for the ur-type definition (as previously described), are present by definition in every schema. All are in the XML Schema (namespace URI &XMLSchemaNS;), have an atomic with an empty and the ur-type definition 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 . therein.

There is no separate ur-Type for simple types. As discussed in , the ur-type definition functions as a simple type when used as the base type definition for a simple type.

See for the XML representation of simple type definitions and for constraints on simple type definition components as such.

A schema is represented in XML by one or more schema documents. 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 below, 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 a legal (relative) URI reference, supplying an empty string for targetNamespace 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 schema above 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 sub-sections of present each such item in turn, setting out the components to which it may correspond.

Reference to schema components from a schema document is managed in a uniform way, whether the component corresponds to an element information item from the same schema document or is imported () from an external schema (which may, but need not, correspond to an actual schema document). The form of all such references is a QName. In each of the XML representation expositions in the following sections, an attribute is shown as having type QName if and only if it is interpreted as referencing a schema component.

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

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

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.

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

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

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

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

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

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

All wildcards (see ) must satisfy the following constraint.

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

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

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

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

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

All annotations (see ) must satisfy the following constraint.

All particles (see ) must satisfy the following constraints.

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

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

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

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

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

All schemas (see ) must satisfy the following constraint.

The fundamental purpose of the schema-validation core is to define schema-validatity for a single element information item and its descendants with respect to a complex type definition. All processors are required to implement this core predicate in a manner which conforms exactly to this specification.

Schema-validity is defined with reference to an XML Schema (note not a schema document) which consists of (at a minimum) the set of schema components (definitions and declarations) required for that validation. This is not a circular definition, but rather a post facto observation: no element information item can be fully schema-valid unless all the components required by any aspect of its (potentially recursive) validation are present in the schema.

As specified above, each schema component is associated directly or indirectly with a target namespace, or explicitly with no namespace. In the case of multi-namespace documents, components for more than one target namespace will co-exist in a schema.

Processors have the option to assemble (and perhaps to optimise or pre-compile) the entire schema prior to the start of a validation episode, or to gather the schema lazily as individual components are required. In all cases it is required that:

The obligation of a schema-aware processor as far as the schema-validation core is concerned is to implement the definitions of schema-valid given below in . Neither the choice of element information item to be schema-validated, nor which of three means of initiating validation are used, is within the scope of this specification.

Although assessing schema-validity is defined recursively, it is also intended to be implementable in streaming processors. Such processors may choose to incrementally assemble the schema during processing in response, for example, to encountering new namespaces. The implication of the invariants expressed above is that such incremental assembly must result in a validation outcome that is the same as would be given if schema-validity was re-assessed with the final, fully assembled schema.

defines an XML representation for type definitions and element declarations and so on, specifying their target namespace and collecting them into schema documents. The two following sections relate to assembling a complete schema for validation from multiple sources. They should not be understood as a form of text substitution, but rather as providing mechanisms for distributed definition of schema components, with appropriate schema-specific semantics.

Layers 1 and 2 provide a framework for validation and XML definition of schemas in a broad variety of environments. Over time, we expect that a range of standards and conventions will evolve to support interoperability of XML Schema implementations on the World Wide Web. Layer 3 defines the minimum level of function required of all conformant processors operating on the Web: it is intended that, over time, future standards (e.g. XML Packages) for interoperability on the Web and in other environments can be introduced without the need to republish this specification.

Before schema validation can be attempted, a schema is required. Special-purpose applications are free to determine a schema for use in validation by whatever means are appropriate, but general purpose processors should implement the strategy set out in , starting with the namespaces declared in the document to be validated, and the &i-value;s of the xsi:schemaLocation and xsi:noNamespaceSchemaLocation &i-attributes; thereof, if any.

It is an error if a schema and all the components which are the value of any of its properties, recursively, fail to satisfy all the relevant Constraints on Schemas set out in .

If a schema is derived from one or more schema documents (that is, one or more element information items) based on the correspondence rules set out in and , two additional conditions hold:

It is an error if any such schema document is not schema-valid with respect to a schema corresponding to the , that is, following schema-validation, the element information items must have a validation attempted property with value full or partial and a validity property with value complete.

The three cases described above are the only types of error which this specification defines. With respect to the processes of the checking of schema structure and the construction of schemas corresponding to schema documents, this specification imposes no restrictions on processors after an error is detected. However schema-validity with respect to schema-like entities which do not satisfy all the above conditions is incoherent. Accordingly, conformant processors must not attempt to schema-validate using such non-schemas.

With a schema which satisfies the conditions expressed in above, the schema-validity of an element information item can be assessed. Three primary approaches to this are possible:

The user or application identifies a complex type definition from among the of the schema, and assesses the schema-validity of the item by appealing to ;

The outcome of this effort, in any case, will be manifest in the validation attempted and validity properties on the element information item and its &i-attributes; and &i-children;, recursively, as defined by , and . It is up to applications to decide what constitutes a successful outcome.

Throughout this document we use the phrase schema-valid loosely to refer to a successful outcome to any of the above-listed assessments of an element information item with respect to a schema.

At the beginning of , attention is drawn to the fact that most kinds of schema components have properties which are described therein as having other components, or sets of other components, as values, but that when components are constructed on the basis of their correspondence with element information items in schema documents, such properties usually correspond to QNames, and the resolution of such QNames may fail, resulting in one or more values of or containing absent where a component is mandated.

If at any time during schema-validation, schema-validity of an information item is being assessed with respect to a component of any kind any of whose properties has or contains such an absent value, the schema-validation effort is modified, as following:

In the post-schema validation infoset, the validation attempted of the item has the value partial;

Because of clause 1.2 of , if this situation ever arises, the document as a whole will not show a validation attempted of full, unless the problem arises within an area of lax validation (see clause 1.2.3 of ).

Schema-aware processors are responsible for processing XML documents, schemas and schema documents, as appropriate given the level of conformance (as defined in ) they support, consistently with the conditions set out above.