The XML representation of schema components uses a vocabulary identified by the namespace name http://www.w3.org/2001/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.

Users of the namespaces defined here should be aware, as a matter of namespace policy, that more names in this namespace may be given definitions in future versions of this or other specifications.

This specification defines several attributes for direct use in any XML documents, as described in . These attributes are in the namespace whose name is http://www.w3.org/2001/XMLSchema-instance. For brevity, the text and examples in this specification use the prefix xsi: to stand for this namespace; in practice, any prefix can be used.

Users of the namespaces defined here should be aware, as a matter of namespace policy, that more names in this namespace may be given definitions in future versions of this or other specifications.

The pre-processing of schema documents described in uses attributes in the namespace http://www.w3.org/2007/XMLSchema-versioning. For brevity, the text and examples in this specification use the prefix vc: to stand for this namespace; in practice, any prefix can be used.

Users of the namespaces defined here should be aware, as a matter of namespace policy, that more names in this namespace may be given definitions in future versions of this or other specifications.

Except for xs:anyType, every type definition is, by construction, either a restriction or an extension of some other type definition. The exception xs:anyType is a of itself. With the exception of the loop on xs:anyType, the graph of these relationships forms a tree known as the Type Definition Hierarchy with xs:anyType as its root.

The type definition used as the basis for an extension or restriction is known as the base type definition of that definition. If a type definition D can reach a type definition B by following its base type definition chain, then D is said to be derived from B. In most cases, a type definition is derived from other type definitions. The only exception is xs:anyType, which is derived from itself.

A type defined with the same constraints as its , or with more, is said to be a restriction. The added constraints might include narrowed ranges or reduced alternatives. Given two types A and B, if the definition of A is a restriction of the definition of B, then members of type A are always locally valid against type B as well.

A complex type definition which allows element or attribute content in addition to that allowed by another specified type definition is said to be an extension.

A special complex type definition, (referred to in earlier versions of this specification as 'the ur-type definition') whose name is anyType in the XSD namespace, is present in each XSD schema. The definition of anyType serves as default type definition for element declarations whose XML representation does not specify one.

A special simple type definition, whose name is error in the XSD namespace, is also present in each XSD schema. The XSD error type has no valid instances. It can be used in any place where other types are normally used; in particular, it can be used in conditional type assignment to cause elements which satisfy certain conditions to be invalid.

For brevity, the text and examples in this specification often use the qualified names xs:anyType and xs:error for these type definitions. (In practice, any appropriately declared prefix can be used, as described in .)

A simple type definition is a set of constraints on strings and information about the values they encode, applicable to the normalized value of an attribute information item or of an element information item with no element children. Informally, it applies to the values of attributes and the text-only content of elements.

Each simple type definition, whether built-in (that is, defined in ) or user-defined, is a restriction of its base type definition. A special restriction of xs:anyType, whose name is anySimpleType in the XSD namespace, is the root of the for all simple type definitions. xs:anySimpleType has a lexical space containing all sequences of characters in the Universal Character Set (UCS) and a value space containing all atomic values and all finite-length lists of atomic values. As with xs:anyType, this specification sometimes uses the qualified name xs:anySimpleType to designate this type definition. The built-in list datatypes all have xs:anySimpleType as their base type definition.

There is a further special datatype called anyAtomicType, a restriction of xs:anySimpleType, which is the base type definition of all the primitive datatypes. This type definition is often referred to simply as xs:anyAtomicType. It too is considered to have an unconstrained lexical space. Its value space consists of the union of the value spaces of all the primitive datatypes.

Datatypes can be constructed from other datatypes by restricting the value space or lexical space of a using zero or more s, by specifying the new datatype as a list of items of some , or by defining it as a union of some specified sequence of .

The mapping from lexical space to value space is unspecified for items whose type definition is xs:anySimpleType or xs:anyAtomicType. Accordingly this specification does not constrain processors' behavior in areas where this mapping is implicated, for example checking such items against enumerations, constructing default attributes or elements whose declared type definition is xs:anySimpleType or xs:anyAtomicType, checking identity constraints involving such items.

provides mechanisms for defining new simple type definitions by restricting some primitive or ordinary datatype. It also provides mechanisms for constructing new simple type definitions whose members are lists of items themselves constrained by some other simple type definition, or whose membership is the union of the memberships of some other simple type definitions. Such list and union simple type definitions are also restrictions of xs:anySimpleType.

For detailed information on simple type definitions, see and . The latter also defines an extensive inventory of pre-defined simple types.

A complex type definition is a set of attribute declarations and a content type, applicable to the attributes and children of an element information item respectively. The content type may require the children to contain neither element nor character information items (that is, to be empty), or to be a string which belongs to a particular simple type, or to contain a sequence of element information items which conforms to a particular model group, with or without character information items as well.

Each complex type definition other than xs:anyType is either

a restriction of a complex base type definition

A complex type which extends another does so by having additional content model particles at the end of the other definition's content model, or by having additional attribute declarations, or both.

For the most part, this specification allows only appending, and not other kinds of extensions. This decision simplifies application processing required to cast instances from the derived type to the base type. One special case allows the extension of all-groups in ways that do not guarantee that the new material occurs only at the end of the content. Another special case is extension via s in interleave mode.

For detailed information on complex type definitions, see .

An element declaration is an association of a name with a type definition, either simple or complex, an (optional) default value and a (possibly empty) set of identity-constraint definitions. The association is either global or scoped to a containing complex type definition. A top-level element declaration with name 'A' is broadly comparable to a pair of DTD declarations as follows, where the associated type definition fills in the ellipses:

Element declarations contribute to validation as part of model group validation, when their defaults and type components are checked against an element information item with a matching name and namespace, and by triggering identity-constraint definition validation.

For detailed information on element declarations, see . For an overview of identity constraints, see .

When XML vocabularies are defined using the document type definition DTD syntax defined by , a reference in a content model to a particular name is satisfied only by an element in the XML document whose name and content correspond exactly to those given in the corresponding element type declaration.

The element type declaration of is not quite the same as the as defined in this specification: does not distinguish between element declarations and type definitions as distinct kinds of object in the way that this specification does. The element type declaration of specifies both the kinds of properties associated in this specification with element declarations and the kinds of properties associated here with (complex) type definitions.

Through the mechanism of element substitution groups, XSD provides a more powerful model than DTDs do supporting substitution of one named element for another. Any top-level element declaration can serve as the defining member, or head, for an element . Other top-level element declarations, regardless of target namespace, can be designated as members of the headed by this element. In a suitably enabled content model, a reference to the head validates not just the head itself, but elements corresponding to any other member of the as well.

All such members must have type definitions which are either the same as the head's type definition or derived from it. Therefore, although the names of elements can vary widely as new namespaces and members of the are defined, the content of member elements is constrained by the type definition of the head.

Note that element substitution groups are not represented as separate components. They are specified in the property values for element declarations (see ).

An attribute declaration is an association between a name and a simple type definition, together with occurrence information and (optionally) a default value. The association is either global, or local to its containing complex type definition. Attribute declarations contribute to validation as part of complex type definition validation, when their occurrence, defaults and type components are checked against an attribute information item with a matching name and namespace.

For detailed information on attribute declarations, see .

A notation declaration is an association between a name and an identifier for a notation. For an attribute or element information item to be valid with respect to a NOTATION simple type definition, its value must have been declared with a notation declaration.

For detailed information on notation declarations, see .

A model group is a constraint in the form of a grammar fragment that applies to lists of element information items. It consists of a list of particles, i.e. element declarations, wildcards and model groups. There are three varieties of model group:

Each model group denotes a set of sequences of element information items. Regarding that set of sequences as a language, the set of sequences recognized by a group G may be written L(G). A model group G is said to accept or recognize the members of L(G).

For detailed information on model groups, see .

A particle is a term in the grammar for element content, consisting of either an element declaration, a wildcard or a model group, together with occurrence constraints. Particles contribute to validation as part of complex type definition validation, when they allow anywhere from zero to many element information items or sequences thereof, depending on their contents and occurrence constraints.

The name is used to refer to any of the three kinds of components which can appear in particles. All Terms are themselves Annotated Components. A basic term is an or a . A basic particle is a whose is a .

A particle can be used in a complex type definition to constrain the validation of the children of an element information item; such a particle is called a content model.

XSD content models are similar to but more expressive than content models; unlike , XSD does not restrict the form of content models describing mixed content.

Each content model, indeed each particle and each term, denotes a set of sequences of element information items. Regarding that set of sequences as a language, the set of sequences recognized by a particle P may be written L(P). A particle P is said to accept or recognize the members of L(P). Similarly, a term T accepts or recognizes the members of L(T).

If a sequence S is a member of L(P), then it is necessarily possible to trace a path through the basic particles within P, with each item within S corresponding to a matching particle within P. The sequence of particles within P corresponding to S is called the of S in P.

For detailed information on particles, see .

An attribute use plays a role similar to that of a particle, but for attribute declarations: an attribute declaration within used by a complex type definition is embedded within an attribute use, which specifies whether the declaration requires or merely allows its attribute, and whether it has a default or fixed value.

A wildcard is a special kind of particle which matches element and attribute information items dependent on their namespace names and optionally on their local names.

For detailed information on wildcards, see .

An identity-constraint definition is an association between a name and one of several varieties of identity-constraint related to uniqueness and reference. All the varieties use expressions to pick out sets of information items relative to particular target element information items which are unique, or a key, or a valid reference, within a specified scope. An element information item is only valid with respect to an element declaration with identity-constraint definitions if those definitions are all satisfied for all the descendants of that element information item which they pick out.

For detailed information on identity-constraint definitions, see .

A component (type alternative for short) associates a type definition with a predicate. Type alternatives are used in conditional type assignment, in which the choice of for elements governed by a particular element declaration depends on properties of the document instance. An element declaration may have a which contains a sequence of type alternatives; the predicates on the alternatives are tested, and when a predicate is satisfied, the type definition paired with it is chosen as the element instance's .

For detailed information on Type Alternatives, see .

An assertion is a predicate associated with a type, which is checked for each instance of the type. If an element or attribute information item fails to satisfy an assertion associated with a given type, then that information item is not locally valid with respect to that type.

For detailed information on Assertions, see .

Many rules that can be enforced by identity constraints and conditional type assignment can also be formulated in terms of assertions. That is, the various constructs have overlapping functionality. The three forms of constraint differ from each other in various ways which may affect the schema author's choice of formulation.

Most obviously, the post-schema-validation infoset will differ somewhat, depending on which form of constraint is chosen.

Less obviously, identity constraints are associated with element declarations, while assertions are associated with type definitions. If it is desired to enforce a particular property of uniqueness or referential integrity associated with a particular element declaration E, of type T, the schema author may often choose either an identity constraint associated with E, or an assertion associated with T. One obvious difference is that elements substitutable for E are required to have types derived from T, but are not required to enforce the identity constraints (or the nillability) of E. If the constraint applicable to E should be enforced by elements substitutable for E, it is often most convenient to formulate the constraint as an assertion on T; conversely, if only some elements of type T are intended to be subject to the constraint, or if elements substitutable for E need not enforce the constraint, then it will be more convenient to formulate the rule as an identity constraint on E.

Similar considerations sometimes apply to the choice between assertions and conditional type assignment.

Because identity constraints and conditional type assignment are simpler and less variable than assertions, it may be easier for software to exploit or optimize them. Assertions have greater expressive power, which means they are often convenient. The rule of least power applies here; it is often preferable to use a less expressive notation in preference to a more expressive one, when either will suffice. See .

A model group definition is an association between a name and a model group, enabling re-use of the same model group in several complex type definitions.

For detailed information on model group definitions, see .

An attribute group definition is an association between a name and a set of attribute declarations, enabling re-use of the same set in several complex type definitions.

For detailed information on attribute group definitions, see .

If the element information item has as its parent, the corresponding schema component is as follows:

If the element information item has or as an ancestor and the ref attribute is absent, it maps both to an attribute declaration (see belowbelow) and to an attribute use with properties as follows (unless use='prohibited', in which case the item corresponds to nothing at all):

The element also maps to the of the attribute use just described, as follows:

If the element information item has or as an ancestor and the ref attribute is present, it maps to an attribute use with properties as follows (unless use='prohibited', in which case the item corresponds to nothing at all):

Informally, an attribute in an XML instance is locally valid against an attribute declaration if and only if (a) the name of the attribute matches the name of the declaration, (b) after whitespace normalization its normalized value is locally valid against the type declared for the attribute, and (c) the attribute obeys any relevant value constraint. Additionally, for xsi:type, it is required that the type named by the attribute be present in the schema. A logical prerequisite for checking the local validity of an attribute against an attribute declaration is that the attribute declaration itself and the type definition it identifies both be present in the schema.

Local validity of attributes is tested as part of schema-validity of attributes (and of the elements on which they occur), and the result of the test is exposed in the property of the post-schema-validation infoset.

A more formal statement is given in the following constraint.

In a given schema-validity episode, the declaration of an attribute (its governing attribute declaration) is the first of the following which applies:

A declaration which was stipulated by the processor (see ).

Schema-validity assessment of an attribute information item involves identifying its and checking its local validity against the declaration. If the is not present in the schema, then assessment is necessarily incomplete.

For attribute information items, there is no difference between assessment and strict assessment, so the attribute information item has been strictly assessed if and only if its schema-validity has been assessed.

See also , and , which describe other information set contributions related to attribute information items.

The xsi:type attribute is used to signal use of a type other than the declared type of an element. See .

The xsi:nil attribute is used to signal that an element's content is nil (or null). See .

The xsi:schemaLocation attribute is used to signal possible locations of relevant schema documents. See .

The xsi:noNamespaceSchemaLocation attribute is used to signal possible locations of relevant schema documents. See .

The following mapping rules apply in all cases where an element maps to an component.

If the element information item has as its parent, it maps to a global , using the mapping given in , supplemented by the following.

If the element information item has or as an ancestor, and the ref attribute is absent, and it does not have minOccurs=maxOccurs=0, then it maps both to a and to a local which is the of that . The is as follows:

The element also maps to an element declaration using the mapping rules given in , supplemented by those below:

If the element information item has or as an ancestor, and the ref attribute is present, and it does not have minOccurs=maxOccurs=0, then it maps to a as follows.

The of an element is normally the declared associated with the , but this may be overridden using conditional type assignment in the or using an , or both. When the element is declared with conditional type assignment, the is used as the unless overridden by an .

The selected type definition S of an element information item E is a type definition associated with E in the following way. Let D be the of E. Then:

If D has a , then S is the type conditionally selected for E by D..

An S is said to override another type definition T if and only if all of the following are true:

S is the on some element information item E. A may or may not be known for E.

A type definition S is validly substitutable for another type T, subject to a set of blocking keywords K (typically drawn from the set {substitution, extension, restriction, list, union} used in the and of element declarations and type definitions), if and only if either

S and T are both complex type definitions and S is validly derived from T subject to the blocking keywords in the union of K and T. , as defined in

If the set of keywords controlling whether a type S is for another type T is the empty set, then S is said to be validly substitutable for T without limitation or absolutely. The phrase validly substitutable, without mention of any set of blocking keywords, means validly substitutable without limitation.

Sometimes one type S is for another type T only if S is derived from T by a chain of restrictions, or if T is a union type and S a member type of the union. The concept of valid substitutability is appealed to often enough in such contexts that it is convenient to define a term to cover this specific case. A type definition S is validly substitutable as a restriction for another type T if and only if S is for T, subject to the blocking keywords {extension, list, union}.

The concept of local validity of an element information item against an element declaration is an important part of the schema-validity of elements. (The other important part is the recursive of attributes and descendant elements.) Local validity partially determines the element information item's property, and fully determines the property, in the post-schema-validation infoset.

Informally, an element is locally valid against an element declaration when:

The declaration is present in the schema and the name of the element matches the name of the declaration.

The following validation rule gives the normative formal definition of local validity of an element against an element declaration.

The following validation rule specifies formally what it means for an element to be locally valid against a type definition. This concept is appealed to in the course of checking an element's local validity against its . It is also part of schema-validity of an element when the element is laxly assessed, by checking its local validity against xs:anyType.

Informally, local validity against a type requires first that the type definition be present in the schema and not declared abstract. For a simple type definition, the element must lack attributes (except for namespace declarations and the special attributes in the xsi namespace) and child elements, and must be type-valid against that simple type definition. For a complex type definition, the element must be locally valid against that complex type definition. Also, if the element has an xsi:type attribute, then it is not locally valid against any type other than the one named by that attribute.

The following validation rule specifies document-level ID/IDREF constraints checked on the if it is an element; this rule is not checked on other elements. Informally, the requirement is that each ID identifies a single element within the , and that each IDREF value matches one ID.

This section gives the top-level rule for of an element information item. Informally:

Assessment begins with the identification of a for the element and then checks that the element is locally valid against the declaration; if no is available, a can be used instead.

The governing element declaration of an element information item E, in a given schema-validity episode, is the first of the following which applies:

A declaration stipulated by the processor (see ).

The governing type definition of an element information item E, in a given schema-validity episode, is the first of the following which applies:

An which overrides a type definition stipulated by the processor (see ).

See also , , , and , which describe other information set contributions related to element information items.

This and the following sections define relations appealed to elsewhere in this specification.

One element declaration is substitutable for another if together they satisfy constraint .

Every element declaration (call this HEAD) in the of a schema defines a substitution group, a subset of those . An element declaration is in the substitution group of HEAD if and only if it is for HEAD.

Whichever alternative for the content of is chosen, the following property mappings apply. Except where otherwise specified, attributes and child elements are to be sought among the attributes and children of the element.

When the source declaration has a child, the following elements are relevant (as are , , and ), and the property mappings are as below, supplemented by the mappings in , , and . Note that either or must appear in the content of .

When the element has a child, then the element maps to a complex type with simple content, as follows.

When the element does not have a child element, then it maps to a complex type with complex content. The following elements are relevant (as are the , , and elements, which are described more fully in , , and , respectively, and which are not repeated here), and the additional property mappings are as below, supplemented by the mappings in , , and , , and . Note that either or must appear in the content of , but their content models are different in this case from the case above when they occur as children of .

Complex types with complex content can be the image of two different forms of element: one with a child (discussed in ), and one with neither nor as a child (discussed in ). The mapping of the is the same in both cases; it is described in .