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

Unless otherwise noted, the entire text of this specification is normative. Exceptions include:

notes

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 .

For a given component C, an expression of the form C. denotes the (value of the) property for component C. The leading C. (or more) is sometimes omitted, if the identity of the component and any other omitted properties is understood from the context. This dot operator is left-associative, so C.. means the same as (C.) . and denotes the value of property within the component or which itself is the value of C's property. White space on either side of the dot operator has no significance and is used (rarely) solely for legibility.

For components C₁ and C₂, an expression of the form C₁ .  = C₂ .  means that C₁ and C₂ have the same value for the property (or properties) in question. Similarly, C₁ = C₂ means that C₁ and C₂ are identical, and C₁. = C₂ that C₂ is the value of C₁..

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 .

Unless otherwise specified, references to attribute values are references to the actual value of the attribute information item in question, not to its normalized value or to other forms or varieties of value associated with it. For a given element information item E, expressions of the form E has att1 = V are short-hand for there is an attribute information item named att1 among the attributes of E and its actual value is V. If the identity of E is clear from context, expressions of the form att1 = V are sometimes used. The form att1 ≠ V is also used to specify that the actual value of att1 is not V.

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 dot operator described above for components and their properties is also used for information items and their properties. For a given information item I, an expression of the form I .  denotes the (value of the) property for item I.

Lists of normative constraints are typically introduced with phrase like all of the following are true (or ... apply), one of the following is true, at least one of the following is true, one or more of the following is true, the appropriate case among the following is true, etc. The phrase one of the following is true is used in cases where the authors believe the items listed to be mutually exclusive (so that the distinction between exactly one and one or more does not arise). If the items in such a list are not in fact mutually exclusive, the phrase one of the following should be interpreted as meaning one or more of the following. The phrase the appropriate case among the following is used only when the cases are thought by the authors to be mutually exclusive; if the cases in such a list are not in fact mutually exclusive, the first applicable case should be taken. Once a case has been encountered with a true condition, subsequent cases must not be tested.

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 .

Where these terms appear without special highlighting, they are used in their ordinary senses and do not express conformance requirements. Where these terms appear highlighted within non-normative material (e.g. notes), they are recapitulating rules normatively stated elsewhere.

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