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 .

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.

The following terms are used in building definitions and describing the actions of &XSP1; processors:

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

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:

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 defines a set of schema-valid XML documents. At a minimum, it consists of type definitions and element declarations. It identifies a set 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 is a member of the set defined by 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.

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

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

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

Attribute declarations and locally scoped element declarations are special with regard to symbol spaces. Every complex type definition defines its own attribute declaration symbol space and local element declaration symbol space, where these symbol spaces are distinct from each other and from any of the other symbol spaces. So, for example, several complex type definitions having the same target namespace can contain an 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 .

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 qualified attribute name is one that appears with a namespace prefix which is itself declared with a value other than the empty string. A non-null value of the property provides for validation of such attributes qualified with an identical namespace URI. Null values of provide for validation of local (unprefixed) attributes. Each complex type definition provides its own symbol space for the names of its associated local attribute declarations. (E.g. an attribute named title within one type definition need not have the same simple type definition as one declared within another complex type; neither of these need agree with the declaration for a similarly named qualified attribute.)

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

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 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 elements being validated.

A of global declares elements available for use in content models throughout the schema. Locally scoped elements are available for use only within the complex type identified by the property. For globally scoped element declarations, a non-null value of the property provides for validation of namespace qualified elements. Null values of validate unqualified elements, including locally scoped elements. This property is also null 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.

An element is schema-valid if it obeys the schema validity constraints of the . For such an element, 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 the element is also schema valid if it has no text or element content, and carries the namespace qualified attribute with local name null from namespace &XMLSchemaInstanceNS; (see ). 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; an element declaration is implicitly a member of any class of which its is a member.

An empty creates an equivalence class admitting other element declarations having the same or types derived therefrom. The explicit values of exclude from the equivalence class elements having types which are extensions, lists, restrictions or reproductions respectively of . If all values are specified, then no equivalence class is possible based on this element 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, list, restriction and/or reproduction of the type of the declared element, and/or (b) from validating elements which are in the same equivalence class (equivClass) 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 are identified by their and . Except for anonymous complex types (those with no ), complex type definitions must be uniquely identified within an XML Schema. 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 any of extension, restriction or reproduction; the explicit values extension, restriction and reproduction prevent further derivations by extension, restriction and reproduction 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. Attribute group definitions are provided primarily for reference from the (see and ). Thus, attribute group definitions provide a replacement for some uses of XML's parameter entities.

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 ;

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 *, then there is no upper bound on the number of such children.

, and , if specified, merge with the corresponding properties of the supplied element declaration.

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

A wildcard provides for validation of 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;

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.

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.

Provision for multi-field keys etc. goes beyond what is supported by xsl:key.

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:

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 ), simple type definitions must be uniquely identified within an XML Schema. 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.

A simple type definition for which is true must not appear as the of an , must not be used as the of an enumeration simple type, must not used as the of a list simple type, and must not be referenced from an attribute in an instance document.

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

A simple type with an empty specification for can be used as a for other types derived by restriction; and/or as the of an enumeration simple type, and/or as the of a list simple type. The explicit values restriction, enumeration and list prevent any or all of those uses respectively.

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 (or identical to) 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 {, }.

Enumeration simple types are restrictions of the specified ; enumeration types validate only content that matches one of the specified .

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 the schema for datatypes 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 .

There is no single schema component corresponding to a element information item, and so no local correspondence of attributes to properties is specified above. The blockDefault, finalDefault and targetNamespace attributes illustrated above 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 be derived from a (text) document at all: it could be built 'by hand' via e.g. a DOM-conformant API.

Aside from , which is not named and corresponds to a helper schema component, and 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 primary or secondary schema component, and in all cases these 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 explicit 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.

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 therefor the correspondence in the abstract, can always be constructed therefrom.

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 specified 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 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 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 the complete component set.

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 fundamental schema-valid predicate applies to an element information item (EII) and a complex type definition against the background of a schema.

The obligation of a schema-aware processor as far as the schema-validation core is concerned is to implement the definition of schema-valid. The choice of EII, as well as the determination of the complex type definition and schema is not specified at layer 1.

The schema-valid predicate is defined recursively, and e.g. streaming processors may implement it in a way that augments the schema during processing in response to encountering new namespaces. The implication of the invariants expressed above is that schema-valid must be implemented so that the same validation outcome is given in such cases as would be given if the initial invocation of schema-valid was re-performed with the final schema replacing the one initially employed.

This is described in , which defines an XML representation for type definitions and element declarations and so on, specifying their target namespace and collecting them into schema documents.

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.