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 normalization and defaulting of attribute and element values. 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 implemented 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 . Before this specification is finally completed, we will need to account for any changes 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. See for the details of the uriReference type and all uses of URI references in this specification.

See for a tabulation of the information items and properties specified in which this specification requires as a precondition to schema-aware processing.

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 context, 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, as are the illustrations of the XML representation element information items.

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 normalized and/or default values for attributes and elements and the types of element and attribute information items.

Schema-validity assessment has two aspects:

determining local schema-validity, that is whether an element or attribute information item satisfies the constraints embodied in the relevant components of an XML Schema;

Throughout this specification, the word valid and its derivatives are used to refer to item 1 above, the determination of local schema-validity.

Throughout this specification, the work assessment is used to refer to the whole rich process of local validation, schema-validity assessment and infoset augmentation.

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

Validation, defined in detail in , is a relation between information items and schema components. For example, an attribute information item may validate respect to an attribute declaration, a list of element information items may validate 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 validation.

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 validation, 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 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 normalization or access. (As an example of the latter case, consider the effect of NMTOKENS on attribute white space, 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 Rules, 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 and assessment.

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 http://www.w3.org/2000/10/XMLSchema. For brevity, the text and examples in this specification use the prefix xs: to stand for this namespace; in practice, any prefix can be used.

&XSP1; also defines several attributes for direct use in any XML documents. These attributes are in a different namespace, which has the namespace URI http://www.w3.org/2000/10/XMLSchema-instance. 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 global identifies attribute declarations available for use in complex type definitions throughout the schema. Locally scoped declarations are available for use only within the complex type definition identified by the property. This property is absent in the case of declarations within attribute group definitions: their scope will be determined when they are used in the construction of complex type definitions.

A non-absent value of the property provides for validation of namespace-qualified attribute information items (which must be explicitly prefixed in the character-level form of XML documents). Absent values of validate unqualified (unprefixed) items.

The value of the attribute must conform to the supplied .

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

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 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 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 null from namespace http://www.w3.org/2000/10/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 supplied constraint string becomes the schema normalized value of the validated element in the &PSVI;. If fixed is specified, then the element's content must either be empty, in which case fixed behaves as default, or 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 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 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 ). 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 attribute use pairs: each is a pair of a boolean and an individual to be used for validation of the &i-attributes; of element information items, where the boolean determines whether the attribute is required or not. 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 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 entity facility. 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 use pairs, that is, a set of pairs of a boolean and an attribute declaration specifically identified as members of the attribute group, where the boolean determines whether the corresponding attribute is required or not.

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 entity facility.

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

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

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 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 assessment of the information items allowed by wildcards, as follows: strict

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

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 expression(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. 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 validation as such. They are referenced in the course of validating strings as members of the NOTATION simple type, in which case the following constraint applies.

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

Annotations do not participate in validation as such. Provided an annotation itself satisfies all relevant Constraints on Schemas it cannot affect the validation 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, 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. the content 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.

Simple type definitions for all the built-in primitive datatypes, namely string, boolean, float, double, decimal, timeInstant, timeDuration, recurringInstant, binary, uriReference (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 URI http://www.w3.org/2000/10/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 .

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.

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

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.

A QName is a name with an optional namespace qualification, as defined in . When used in connection with the XML representation of schema components in this specification, this refers to the simple type QName as defined in .

An NCName is a name with no colon, as defined in . When used in connection with the XML representation of schema components in this specification, this refers to the simple type NCName as defined in .

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.

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.

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 assessment core is to define assessment 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.

assessment 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 assessment. This is not a circular definition, but rather a post facto observation: no element information item can be fully assessed unless all the components required by any aspect of its (potentially recursive) assessment 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 optimize or pre-compile) the entire schema prior to the start of an assessment 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 assessment core is concerned is to implement one or more of the options for assessment given below in . Neither the choice of element information item for that assessment, nor which of the means of initiating assessment are used, is within the scope of this specification.

Although assessment 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 an assessment outcome that is the same as would be given if assessment was undertaken again 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 assessment 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 assessment 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 assessment can be attempted, a schema is required. Special-purpose applications are free to determine a schema for use in assessment by whatever means are appropriate, but general purpose processors should implement the strategy set out in , starting with the namespaces declared in the document whose assessment is being undertaken, and the &i-value;s of the xsi:schemaLocation and xsi:noNamespaceSchemaLocation &i-attributes; thereof, if any, along with an other information about schema identity or schema document location provided by users in application-specific ways, 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 would not be fully valid with respect to a schema corresponding to the , that is, following schema-validation with such a schema, the element information items would have a validation attempted property with value full or partial and a validity property with value valid.

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 assessment with respect to schema-like entities which do not satisfy all the above conditions is incoherent. Accordingly, conformant processors must not attempt to undertake assessment 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 appeals to (clause 1.1.2);

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.

Note that every element and attribute information item participating in the assessment will also have a validation context property which refers back to the element information item at which assessment began.

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 assessment, an element or attribute information item is being validated with respect to a component of any kind any of whose properties has or contains such an absent value, the validation is modified, as following:

In the case of attribute information items, the effect is as if clause 1.1 of had failed;

Because of the value specification for validation attempted in , if this situation ever arises, the document as a whole cannot show a validation attempted of full.

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.