The Working Group has three main goals for this version of W3C XML Schema:

These goals are in tension with one another. The Working Group's strategic guidelines for changes between versions 1.0 and 1.1 can be summarized as follows:

The aim with regard to compatibility is that

The purpose of XML Schema Definition Language: Structures is to define the nature of !! 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 XSDL 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 can 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, XML Schema Definition Language: Structures 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 formalism defined here to express syntactic, structural and value constraints applicable to its document instances. The XSDL 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 applications. Some applications will require constraint capabilities not expressible in this language, and so will need to perform their own additional validations.

The definition of XML Schema Definition Language: Structures depends on the following specifications: , , , and .

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

defines some datatypes which depend on definitions in and ; those definitions, and therefore the datatypes based on them, vary between version 1.0 (, ) and version 1.1 (, ) of those specifications. In any given schema-validity-assessment episode, the choice of the 1.0 or the 1.1 definition of those datatypes is implementation-defined.

Conforming implementations of this specification may provide either the 1.1-based datatypes or the 1.0-based datatypes, or both. If both are supported, the choice of which datatypes to use in a particular assessment episode should be under user control.

The section introduces the highlighting and typography as used in this document to present technical material.

Special terms are defined at their point of introduction in the text. For example a term is something used with a special meaning. The definition is labeled as such and the term it defines is displayed in boldface. The end of the definition is not specially marked in the displayed or printed text. Uses of defined terms are links to their definitions, set off with middle dots, for instance term.

Non-normative examples are set off in boxes 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:

References to properties of schema components are 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. This is followed by a tabulation of the correspondence between properties of the component and properties of the information item. Where context determines which of several different components corresponds to the source declaration, several tabulations, one per context, are given. The property correspondences are normative, as are the illustrations of the XML representation element information items.

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. Where an attribute information item has a built-in simple type definition defined in , a hyperlink to its definition therein is given.

The allowed content of the information item is shown as a grammar fragment, using the Kleene operators ?, * and +. Each element name therein is a hyperlink to its own illustration.

References to elements in the text are links to the relevant illustration as exemplified above, set off with angle brackets, for instance .

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

Properties which this specification defines for information items are introduced as follows:

References to properties of information items defined in this specification are notated as links to their introduction as exemplified above, set off with square brackets, for example .

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

Within normative prose in this specification, the words may, should, must and must not are defined as follows:

These definitions describe in terms specific to this document the meanings assigned to these terms by . The specific wording follows that of .

This specification provides a definition of error and of conformant processors' responsibilities with respect to errors in .

An XSDL schema is a set of components such as type definitions and element declarations. These can be used to assess the validity of well-formed element and attribute information items (as defined in ), and furthermore may specify augmentations to those items and their descendants. This augmentation makes explicit information 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. The input information set can also be augmented with information about the validity of the item, or about other properties described in this specification. We refer to the augmented infoset which results from conformant processing as defined in this specification as the post-schema-validation infoset, or PSVI. Conforming processors may provide access to some or all of the PSVI, as described in . The mechanisms by which processors provide such access to the PSVI are neither defined nor constrained by this specification.

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 XSDL schema;

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

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

During , some or all of the element and attribute information items in the input document are associated with declarations and/or type definitions; these declarations and type definitions are then used in the of those items, in a recursive process. The declaration associated with an information item, if any, and with respect to which its validity is assessed in a given assessment episode is said to govern the item, or to be its governing element or attribute declaration. Similarly the type definition with respect to which the type-validity of an item is assessed is its governing type definition.

See also the definitions of and (for elements) and and (for attributes).

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, XSDL schemas can be described in terms of an abstract data model. In defining schemas in terms of an abstract data model, this specification rigorously specifies the information which must be available to a conforming XSDL 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 XML interchange format for schemas is provided.

Schema component is the generic term for the building blocks that make up the abstract data model of the schema. An XSDL schema is a set of schema components. There are 14 kinds of component in all, falling into three groups. The primary components, which may (type definitions) or must (element and attribute declarations) have names, are as follows:

The secondary components, are as follows:

Finally, the helper components provide small parts of other components; they are not independent of their context:

The name covers all the different kinds of component defined in this specification.

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 and in some cases must 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 name, 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 name of, for example, the element information items it will validate.

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