Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ below:

XML Schema Part 1: Structures Second Edition

This document sets out the structural part (XML Schema: Structures) of the XML Schema definition language.

Chapter 2 presents a Conceptual Framework (§2) for XML Schemas, including an introduction to the nature of XML Schemas and an introduction to the XML Schema abstract data model, along with other terminology used throughout this document.

Chapter 3, Schema Component Details (§3), specifies the precise semantics of each component of the abstract model, the representation of each component in XML, with reference to a DTD and XML Schema for an XML Schema document type, along with a detailed mapping between the elements and attribute vocabulary of this representation and the components and properties of the abstract model.

Chapter 4 presents Schemas and Namespaces: Access and Composition (§4), including the connection between documents and schemas, the import, inclusion and redefinition of declarations and definitions and the foundations of schema-validity assessment.

Chapter 5 discusses Schemas and Schema-validity Assessment (§5), including the overall approach to schema-validity assessment of documents, and responsibilities of schema-aware processors.

The normative appendices include a Schema for Schemas (normative) (§A) for the XML representation of schemas and References (normative) (§B).

The non-normative appendices include the DTD for Schemas (non-normative) (§G) and a Glossary (non-normative) (§F).

This document is primarily intended as a language definition reference. As such, although it contains a few examples, it is not primarily designed to serve as a motivating introduction to the design and its features, or as a tutorial for new users. Rather it presents a careful and fully explicit definition of that design, suitable for guiding implementations. For those in search of a step-by-step introduction to the design, the non-normative [XML Schema: Primer] is a much better starting point than this document.

The purpose of XML Schema: Structures 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 XML Schema: Structures 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, XML Schema: 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 XML Schema: Structures formalism to express syntactic, structural and value constraints applicable to its document instances. The XML Schema: Structures 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 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 [Definition:]  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:

<schema targetNamespace="http://www.example.com/XMLSchema/1.0/mySchema">

And an explanation of the example.

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 {example property}.

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 may determine which of several different components may arise, 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 [XML Schemas: Datatypes], 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 <example>.

References to properties of information items as defined in [XML-Infoset] 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 [new property].

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

Note: General comments directed to all readers.

Following [XML 1.0 (Second Edition)], within normative prose in this specification, the words may and must are defined as follows:

may

Conforming documents and XML Schema-aware processors are permitted to but need not behave as described.

must

Conforming documents and XML Schema-aware processors are required to behave as described; otherwise they are in error.

Note however that this specification provides a definition of error and of conformant processors' responsibilities with respect to errors (see Schemas and Schema-validity Assessment (§5)) which is considerably more complex than that of [XML 1.0 (Second Edition)].

This chapter gives an overview of XML Schema: Structures at the level of its abstract data model. Schema Component Details (§3) provides details on this model, including a normative representation in XML for the components of the model. Readers interested primarily in learning to write schema documents may wish to first read [XML Schema: Primer] for a tutorial introduction, and only then consult the sub-sections of Schema Component Details (§3) named XML Representation of ... for the details.

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 and attribute information items (as defined in [XML-Infoset]), 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. [Definition:]  We refer to the augmented infoset which results from conformant processing as defined in this specification as the post-schema-validation infoset, or PSVI.

Schema-validity assessment has two aspects:

1

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;

2 Synthesizing an overall validation outcome for the item, combining local schema-validity with the results of schema-validity assessments of its descendants, if any, and adding appropriate augmentations to the infoset to record this outcome.

Throughout this specification, [Definition:]  the word valid and its derivatives are used to refer to clause 1 above, the determination of local schema-validity.

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

This specification builds on [XML 1.0 (Second Edition)] and [XML-Namespaces]. The concepts and definitions used herein regarding XML are framed at the abstract level of information items as defined in [XML-Infoset]. By definition, this use of the infoset provides a priori guarantees of well-formedness (as defined in [XML 1.0 (Second Edition)]) and namespace conformance (as defined in [XML-Namespaces]) for all candidates for ·assessment· and for all ·schema documents·.

Just as [XML 1.0 (Second Edition)] and [XML-Namespaces] 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 XML interchange format for schemas is provided.

[Definition:]   Schema component is the generic term for the building blocks that comprise the abstract data model of the schema. [Definition:]   An XML Schema is a set of ·schema components·. There are 13 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:

• Simple type definitions
• Complex type definitions
• Attribute declarations
• Element declarations

The secondary components, which must have names, are as follows:

• Attribute group definitions
• Identity-constraint definitions
• Model group definitions
• Notation declarations

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

• Annotations
• Model groups
• Particles
• Wildcards
• Attribute Uses

During ·validation·, [Definition:]  declaration components are associated by (qualified) name to information items being ·validated·.

On the other hand, [Definition:]  definition components define internal schema components that can be used in other schema components.

[Definition:]  Declarations and definitions may have and be identified by names, which are NCNames as defined by [XML-Namespaces].

[Definition:]  Several kinds of component have a target namespace, which is either ·absent· or a namespace name, also as defined by [XML-Namespaces]. 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 may ·validate·.

At the abstract level, there is no requirement that the components of a schema share a

. Any schema for use in

of documents containing names from more than one namespace will of necessity include components with different

. This contrasts with the situation at the level of the XML representation of components, in which each schema document contributes definitions and declarations to a single target namespace.

·Validation·, defined in detail in Schema Component Details (§3), is a relation between information items and schema components. For example, an attribute information item may ·validate· with 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 abstract model provides two kinds of type definition component: simple and complex.

[Definition:]  This specification uses the phrase type definition in cases where no distinction need be made between simple and complex types.

Type definitions form a hierarchy with a single root. The subsections below first describe characteristics of that hierarchy, then provide an introduction to simple and complex type definitions themselves.

[Definition:]  Except for a distinguished ·ur-type definition·, every ·type definition· is, by construction, either a ·restriction· or an ·extension· of some other type definition. The graph of these relationships forms a tree known as the Type Definition Hierarchy.

[Definition:]  A type definition whose declarations or facets are in a one-to-one relation with those of another specified type definition, with each in turn restricting the possibilities of the one it corresponds to, is said to be a restriction. The specific restrictions might include narrowed ranges or reduced alternatives. Members of a type, A, whose definition is a ·restriction· of the definition of another type, B, are always members of type B as well.

[Definition:]  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.

[Definition:]  A distinguished complex type definition, the ur-type definition, whose name is anyType in the XML Schema namespace, is present in each ·XML Schema·, serving as the root of the type definition hierarchy for that schema.

[Definition:]  A type definition used as the basis for an ·extension· or ·restriction· is known as the base type definition of that definition.

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 [XML Schemas: Datatypes]) or user-defined, is a ·restriction· of some particular simple ·base type definition·. For the built-in primitive type definitions, this is [Definition:]  the simple ur-type definition, a special restriction of the ·ur-type definition·, whose name is anySimpleType in the XML Schema namespace. The ·simple ur-type definition· 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 mapping from lexical space to value space is unspecified for items whose type definition is the ·simple ur-type definition·. Accordingly this specification does not constrain processors' behaviour in areas where this mapping is implicated, for example checking such items against enumerations, constructing default attributes or elements whose declared type definition is the ·simple ur-type definition·, checking identity constraints involving such items.

Note: The Working Group expects to return to this area in a future version of this specification.

Simple types may also be defined 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 the ·simple ur-type definition·.

For detailed information on simple type definitions, see Simple Type Definitions (§3.14) and [XML Schemas: Datatypes]. 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), 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 the ·ur-type definition· is either

• a restriction of a complex ·base type definition·

or

• an ·extension· of a simple or 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.

Note: This specification allows only appending, and not other kinds of extensions. This decision simplifies application processing required to cast instances from derived to base type. Future versions may allow more kinds of extension, requiring more complex transformations to effect casting.

For detailed information on complex type definitions, see Complex Type Definitions (§3.4).

There are three kinds of declaration component: element, attribute, and notation. Each is described in a section below. Also included is a discussion of element substitution groups, which is a feature provided in conjunction with element declarations.

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 A . . .>
<!ATTLIST A . . .>

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 Element Declarations (§3.3).

In XML 1.0, the name and content of an element must correspond exactly to the element type referenced in the corresponding content model.

[Definition:]  Through the new mechanism of element substitution groups, XML Schemas provides a more powerful model supporting substitution of one named element for another. Any top-level element declaration can serve as the defining member, or head, for an element substitution group. Other top-level element declarations, regardless of target namespace, can be designated as members of the substitution group 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 substitution group as well.

All such members must have type definitions which are either the same as the head's type definition or restrictions or extensions of it. Therefore, although the names of elements can vary widely as new namespaces and members of the substitution group are defined, the content of member elements is strictly limited according to the type definition of the substitution group head.

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

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 Attribute Declarations (§3.2).

A notation declaration is an association between a name and an identifier for a notation. For an attribute 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 Notation Declarations (§3.12).

The model group, particle, and wildcard components contribute to the portion of a complex type definition that controls an element information item's content.

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:

• Sequence (the element information items match the particles in sequential order);
• Conjunction (the element information items match the particles, in any order);
• Disjunction (the element information items match one of the particles).

For detailed information on model groups, see Model Groups (§3.8).

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.

[Definition:]  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.

For detailed information on particles, see Particles (§3.9).

An attribute use plays a role similar to that of a particle, but for attribute declarations: an attribute declaration within 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 name, independently of their local names.

For detailed information on wildcards, see Wildcards (§3.10).

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 [XPath] 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 Identity-constraint Definitions (§3.11).

There are two kinds of convenience definitions provided to enable the re-use of pieces of complex type definitions: model group definitions and attribute group definitions.

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 Model Group Definitions (§3.7).

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 Attribute Group Definitions (§3.6).

An annotation is information for human and/or mechanical consumers. The interpretation of such information is not defined in this specification.

For detailed information on annotations, see Annotations (§3.13).

The [XML 1.0 (Second Edition)] 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 focused 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:

Schema Component Constraint

[Definition:]  Constraints on the schema components themselves, i.e. conditions components must satisfy to be components at all. Located in the sixth sub-section of the per-component sections of Schema Component Details (§3) and tabulated in Schema Component Constraints (§C.4).

Schema Representation Constraint

[Definition:]  Constraints on the representation of schema components in XML beyond those which are expressed in Schema for Schemas (normative) (§A). Located in the third sub-section of the per-component sections of Schema Component Details (§3) and tabulated in Schema Representation Constraints (§C.3).

Validation Rules

[Definition:]  Contributions to ·validation· associated with schema components. Located in the fourth sub-section of the per-component sections of Schema Component Details (§3) and tabulated in Validation Rules (§C.1).

Schema Information Set Contribution

[Definition:]  Augmentations to ·post-schema-validation infoset·s expressed by schema components, which follow as a consequence of ·validation· and/or ·assessment·. Located in the fifth sub-section of the per-component sections of Schema Component Details (§3) and tabulated in Contributions to the post-schema-validation infoset (§C.2).

The last of these, schema information set contributions, are not as new as they might at first seem. 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.

[Definition:]  Minimally conforming processors must completely and correctly implement the ·Schema Component Constraints·, ·Validation Rules·, and ·Schema Information Set Contributions· contained in this specification.

[Definition:]  ·Minimally conforming· processors which accept schemas represented in the form of XML documents as described in Layer 2: Schema Documents, Namespaces and Composition (§4.2) 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 Schema Component Details (§3) for mapping the contents of such documents to ·schema components· for use in ·validation· and ·assessment·.

By separating the conformance requirements relating to the concrete syntax of XML schema documents, this specification admits processors which use schemas stored in optimized binary representations, dynamically created schemas represented as programming language data structures, or implementations in which particular schemas are compiled into executable code such as C or Java. Such processors can be said to be

but not necessarily in

.

[Definition:]   Fully conforming processors are network-enabled processors which are not only both ·minimally conforming· and ·in conformance to the XML Representation of Schemas·, but which additionally must be capable of accessing schema documents from the World Wide Web according to Representation of Schemas on the World Wide Web (§2.7) and How schema definitions are located on the Web (§4.3.2). .

Note: Although this specification provides just these three standard levels of conformance, it is anticipated that other conventions can be established in the future. For example, the World Wide Web Consortium is considering conventions for packaging on the Web a variety of resources relating to individual documents and namespaces. Should such developments lead to new conventions for representing schemas, or for accessing them on the Web, new levels of conformance can be established and named at that time. There is no need to modify or republish this specification to define such additional levels of conformance.

See Schemas and Namespaces: Access and Composition (§4) for a more detailed explanation of the mechanisms supporting these levels of conformance.

As discussed in XML Schema Abstract Data Model (§2.2), 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·.

Therefore [Definition:]  this specification 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 [XML-Namespaces]. There is a single distinct symbol space within a given ·target namespace· for each kind of definition and declaration component identified in XML Schema Abstract Data Model (§2.2), 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 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.

XML Schema: Structures also defines several attributes for direct use in any XML documents. These attributes are in a different namespace, which has the namespace name http://www.w3.org/2001/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. All schema processors have appropriate attribute declarations for these attributes built in, see Attribute Declaration for the 'type' attribute (§3.2.7), Attribute Declaration for the 'nil' attribute (§3.2.7), Attribute Declaration for the 'schemaLocation' attribute (§3.2.7) and Attribute Declaration for the 'noNamespaceSchemaLocation' attribute (§3.2.7).

XML Schema: Structures introduces a mechanism for signaling that an element should be accepted as ·valid· when it has no content despite a content type which does not require or even necessarily allow empty content. An element may be ·valid· without content if it has the attribute xsi:nil with the value true. An element so labeled must be empty, but can carry attributes if permitted by the corresponding complex type.

The xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes can be used in a document to provide hints as to the physical location of schema documents which may be used for ·assessment·. See How schema definitions are located on the Web (§4.3.2) for details on the use of these attributes.

The following sections provide full details on the composition of all schema components, together with their XML representations and their contributions to ·assessment·. Each section is devoted to a single component, with separate subsections for

1. properties: their values and significance
2. XML representation and the mapping to properties
3. constraints on representation
4. validation rules
5. ·post-schema-validation infoset· contributions
6. constraints on the components themselves

The sub-sections immediately below introduce conventions and terminology used throughout the component sections.

Components are defined in terms of their properties, and each property in turn is defined by giving its range, that is the values it may have. This can be understood as defining a schema as a labeled directed graph, where the root is a schema, every other vertex is a schema component or a literal (string, boolean, number) and every labeled edge is a property. The graph is not acyclic: multiple copies of components with the same name in the same ·symbol space· may not exist, so in some cases re-entrant chains of properties must exist. Equality of components for the purposes of this specification is always defined as equality of names (including target namespaces) within symbol spaces.

Note: A schema and its components as defined in this chapter are an idealization of the information a schema-aware processor requires: implementations are not constrained in how they provide it. In particular, no implications about literal embedding versus indirection follow from the use below of language such as "properties . . . having . . . components as values".

[Definition:]  Throughout this specification, the term absent is used as a distinguished property value denoting absence.

Any property not identified as optional is required to be present; optional properties which are not present are taken to have ·absent· as their value. Any property identified as a having a set, subset or list value may have an empty value unless this is explicitly ruled out: this is not the same as ·absent·. Any property value identified as a superset or subset of some set may be equal to that set, unless a proper superset or subset is explicitly called for. By 'string' in Part 1 of this specification is meant a sequence of ISO 10646 characters identified as legal XML characters in [XML 1.0 (Second Edition)].

The principal purpose of XML Schema: Structures is to define a set of schema components that constrain the contents of instances and augment the information sets thereof. Although no external representation of schemas is required for this purpose, such representations will obviously be widely used. To provide for this in an appropriate and interoperable way, this specification provides a normative XML representation for schemas which makes provision for every kind of schema component. [Definition:]  A document in this form (i.e. a <schema> element information item) is a schema document. For the schema document as a whole, and its constituents, the sections below define correspondences between element information items (with declarations in Schema for Schemas (normative) (§A) and DTD for Schemas (non-normative) (§G)) and schema components. All the element information items in the XML representation of a schema must be in the XML Schema namespace, that is their [namespace name] must be http://www.w3.org/2001/XMLSchema. Although a common way of creating the XML Infosets which are or contain ·schema documents· will be using an XML parser, this is not required: any mechanism which constructs conformant infosets as defined in [XML-Infoset] is a possible starting point.

Two aspects of the XML representations of components presented in the following sections are constant across them all:

1. All of them allow attributes qualified with namespace names other than the XML Schema namespace itself: these appear as annotations in the corresponding schema component;
2. All of them allow an <annotation> as their first child, for human-readable documentation and/or machine-targeted information.

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 Schema for Schemas (normative) (§A).

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.

In discussing the mapping from XML representations to schema components below, the value of a component property is often determined by the value of an attribute information item, one of the [attributes] of an element information item. Since schema documents are constrained by the Schema for Schemas (normative) (§A), there is always a simple type definition associated with any such attribute information item. [Definition:]  The phrase actual value is used to refer to the member of the value space of the simple type definition associated with an attribute information item which corresponds to its ·normalized value·. This will often be a string, but may also be an integer, a boolean, a URI reference, etc. This term is also occasionally used with respect to element or attribute information items in a document being ·validated·.

Many properties are identified below as having other schema components or sets of components as values. For the purposes of exposition, the definitions in this section assume that (unless the property is explicitly identified as optional) all such values are in fact present. When schema components are constructed from XML representations involving reference by name to other components, this assumption may be violated if one or more references cannot be resolved. This specification addresses the matter of missing components in a uniform manner, described in Missing Sub-components (§5.3): no mention of handling missing components will be found in the individual component descriptions below.

Forward reference to named definitions and declarations is allowed, both within and between ·schema documents·. By the time the component corresponding to an XML representation which contains a forward reference is actually needed for ·validation· an appropriately-named component may have become available to discharge the reference: see Schemas and Namespaces: Access and Composition (§4) for details.

Throughout this specification, [Definition:]  the initial value of some attribute information item is the value of the [normalized value] property of that item. Similarly, the initial value of an element information item is the string composed of, in order, the [character code] of each character information item in the [children] of that element information item.

The above definition means that comments and processing instructions, even in the midst of text, are ignored for all ·validation· purposes.

[Definition:]  The normalized value of an element or attribute information item is an ·initial value· whose white space, if any, has been normalized according to the value of the whiteSpace facet of the simple type definition used in its ·validation·:

preserve

No normalization is done, the value is the ·normalized value·

replace

All occurrences of #x9 (tab), #xA (line feed) and #xD (carriage return) are replaced with #x20 (space).

collapse

Subsequent to the replacements specified above under replace, contiguous sequences of #x20s are collapsed to a single #x20, and initial and/or final #x20s are deleted.

If the simple type definition used in an item's ·validation· is the ·simple ur-type definition·, the ·normalized value· must be determined as in the preserve case above.

There are three alternative validation rules which may supply the necessary background for the above: Attribute Locally Valid (§3.2.4) (clause 3), Element Locally Valid (Type) (§3.3.4) (clause 3.1.3) or Element Locally Valid (Complex Type) (§3.4.4) (clause 2.2).

These three levels of normalization correspond to the processing mandated in XML 1.0 for element content, CDATA attribute content and tokenized attributed content, respectively. See Attribute Value Normalization in [XML 1.0 (Second Edition)] for the precedent for replace and collapse for attributes. Extending this processing to element content is necessary to ensure a consistent ·validation· semantics for simple types, regardless of whether they are applied to attributes or elements. Performing it twice in the case of attributes whose [normalized value] has already been subject to replacement or collapse on the basis of information in a DTD is necessary to ensure consistent treatment of attributes regardless of the extent to which DTD-based information has been made use of during infoset construction.

Even when DTD-based information

been appealed to, and

has taken place, the above definition of

may mean

normalization takes place, as for instance when character entity references in attribute values result in white space characters other than spaces in their

s.

Attribute declarations provide for:

• Local ·validation· of attribute information item values using a simple type definition;
• Specifying default or fixed values for attribute information items.

<xs:attribute name="age" type="xs:positiveInteger" use="required"/>

The XML representation of an attribute declaration.

The attribute declaration schema component has the following properties:

The {name} property must match the local part of the names of attributes being ·validated·.

The value of the attribute must conform to the supplied {type definition}.

A non-·absent· value of the {target namespace} 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 {target namespace} ·validate· unqualified (unprefixed) items.

A {scope} 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 {scope} 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.

{value constraint} reproduces the functions of XML 1.0 default and #FIXED attribute values. default specifies that the attribute is to appear unconditionally in the ·post-schema-validation infoset·, with the supplied value used whenever the attribute is not actually present; fixed indicates that the attribute value if present must equal the supplied constraint value, and if absent receives the supplied value as for default. Note that it is values that are supplied and/or checked, not strings.

See Annotations (§3.13) for information on the role of the {annotation} property.

[XML-Infoset] distinguishes attributes with names such as xmlns or xmlns:xsl from ordinary attributes, identifying them as [namespace attributes]. Accordingly, it is unnecessary and in fact not possible for schemas to contain attribute declarations corresponding to such namespace declarations, see xmlns Not Allowed (§3.2.6). No means is provided in this specification to supply a default value for a namespace declaration.

The XML representation for an attribute declaration schema component is an <attribute> element information item. It specifies a simple type definition for an attribute either by reference or explicitly, and may provide default information. The correspondences between the properties of the information item and properties of the component are as follows:

<attribute
  default = string
  fixed = string
  form = (qualified | unqualified)
  id = ID
  name = NCName
  ref = QName
  type = QName
  use = (optional | prohibited | required) : optional
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, simpleType?)
</attribute>

If the

element information item has

as its parent, the corresponding schema component is as follows:

otherwise if the

element information item has

or

as an ancestor and the

is absent, it corresponds to an attribute use with properties as follows (unless

, in which case the item corresponds to nothing at all):

otherwise (the

element information item has

or

as an ancestor and the

is present), it corresponds to an attribute use with properties as follows (unless

, in which case the item corresponds to nothing at all):

Attribute declarations can appear at the top level of a schema document, or within complex type definitions, either as complete (local) declarations, or by reference to top-level declarations, or within attribute group definitions. For complete declarations, top-level or local, the type attribute is used when the declaration can use a built-in or pre-declared simple type definition. Otherwise an anonymous <simpleType> is provided inline.

The default when no simple type definition is referenced or provided is the ·simple ur-type definition·, which imposes no constraints at all.

Attribute information items ·validated· by a top-level declaration must be qualified with the {target namespace} of that declaration (if this is ·absent·, the item must be unqualified). Control over whether attribute information items ·validated· by a local declaration must be similarly qualified or not is provided by the form [attribute], whose default is provided by the attributeFormDefault [attribute] on the enclosing <schema>, via its determination of {target namespace}.

The names for top-level attribute declarations are in their own ·symbol space·. The names of locally-scoped attribute declarations reside in symbol spaces local to the type definition which contains them.

In addition to the conditions imposed on

element information items by the schema for schemas,

of the following must be true:

1 default and fixed must not both be present.

2 If

and

are both present,

must have the

.

3 If the item's parent is not

, then

of the following must be true:

3.1 One of ref or name must be present, but not both.

3.2 If

is present, then all of

,

and

must be absent.

For an attribute information item to be locally

with respect to an attribute declaration

of the following must be true:

The schema-validity assessment of an attribute information item depends on its

alone.

. See clause

(in

) for attribute declarations, clause

(in

) for element declarations.

For an attribute information item's schema-validity to have been assessed

of the following must be true:

1 A non-

attribute declaration must be known for it, namely

of the following:

.

If clause

of

applies with respect to an attribute information item, in the

the attribute information item has a property:

Furthermore, the item has one of the following alternative sets of properties:

Either

or

If the

has

, then calling

, there are three additional properties:

The first (

) alternative above is provided for applications such as query processors which need access to the full range of details about an item's

, for example the type hierarchy; the second, for lighter-weight processors for whom representing the significant parts of the type hierarchy as information items might be a significant burden.

Also, if the declaration has a

, the item has a property:

If the attribute information item was not

, then instead of the values specified above,

All attribute declarations (see Attribute Declarations (§3.2)) must satisfy the following constraints.

of the following must be true:

The

of an attribute declaration must not match

.

The

of an attribute is an

, which implicitly prohibits attribute declarations of the form

.

The

of an attribute declaration, whether local or top-level, must not match

(unless it is one of the four built-in declarations given in the next section).

Note: This reinforces the special status of these attributes, so that they not only need not be declared to be allowed in instances, but must not be declared. It also removes any temptation to experiment with supplying global or fixed values for e.g. xsi:type or xsi:nil, which would be seriously misleading, as they would have no effect.

There are four attribute declarations present in every schema by definition:

Element declarations provide for:

• Local ·validation· of element information item values using a type definition;
• Specifying default or fixed values for an element information items;
• Establishing uniquenesses and reference constraint relationships among the values of related elements and attributes;
• Controlling the substitutability of elements through the mechanism of ·element substitution groups·.

<xs:element name="PurchaseOrder" type="PurchaseOrderType"/>

<xs:element name="gift">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="birthday" type="xs:date"/>
   <xs:element ref="PurchaseOrder"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>

XML representations of several different types of element declaration

The element declaration schema component has the following properties:

The {name} property must match the local part of the names of element information items being ·validated·.

A {scope} 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 {scope} property. This property is ·absent· in the case of declarations within named model groups: their scope is determined when they are used in the construction of complex type definitions.

A non-·absent· value of the {target namespace} property provides for ·validation· of namespace-qualified element information items. ·Absent· values of {target namespace} ·validate· unqualified items.

An element information item is ·valid· if it satisfies the {type definition}. For such an item, schema information set contributions appropriate to the {type definition} are added to the corresponding element information item in the ·post-schema-validation infoset·.

If {nillable} is true, then an element may also be ·valid· if it carries the namespace qualified attribute with [local name] nil from namespace http://www.w3.org/2001/XMLSchema-instance and value true (see xsi:nil (§2.6.2)) even if it has no text or element content despite a {content type} which would otherwise require content. Formal details of element ·validation· are described in Element Locally Valid (Element) (§3.3.4).

{value constraint} establishes a default or fixed value for an element. If default is specified, and if the element being ·validated· is empty, then the canonical form of the supplied constraint value becomes the [schema normalized value] 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 its value must match the supplied constraint value.

The provision of defaults for elements goes beyond what is possible in XML 1.0 DTDs, and does not exactly correspond to defaults for attributes. In particular, an element with a non-empty

whose simple type definition includes the empty string in its lexical space will nonetheless never receive that value, because the

will override it.

{identity-constraint definitions} express constraints establishing uniquenesses and reference relationships among the values of related elements and attributes. See Identity-constraint Definitions (§3.11).

Element declarations are potential members of the substitution group, if any, identified by {substitution group affiliation}. Potential membership is transitive but not symmetric; an element declaration is a potential member of any group of which its {substitution group affiliation} is a potential member. Actual membership may be blocked by the effects of {substitution group exclusions} or {disallowed substitutions}, see below.

An empty {substitution group exclusions} allows a declaration to be nominated as the {substitution group affiliation} of other element declarations having the same {type definition} or types derived therefrom. The explicit values of {substitution group exclusions} rule out element declarations having types which are extensions or restrictions respectively of {type definition}. If both values are specified, then the declaration may not be nominated as the {substitution group affiliation} of any other declaration.

The supplied values for {disallowed substitutions} determine whether an element declaration appearing in a ·content model· will be prevented from additionally ·validating· elements (a) with an xsi:type (§2.6.1) 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 {disallowed substitutions} is empty, then all derived types and substitution group members are allowed.

Element declarations for which {abstract} 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 Annotations (§3.13) for information on the role of the {annotation} property.

The XML representation for an element declaration schema component is an <element> element information item. It specifies a type definition for an element either by reference or explicitly, and may provide occurrence and default information. The correspondences between the properties of the information item and properties of the component(s) it corresponds to are as follows:

<element
  abstract = boolean : false
  block = (#all | List of (extension | restriction | substitution))
  default = string
  final = (#all | List of (extension | restriction))
  fixed = string
  form = (qualified | unqualified)
  id = ID
  maxOccurs = (nonNegativeInteger | unbounded)  : 1
  minOccurs = nonNegativeInteger : 1
  name = NCName
  nillable = boolean : false
  ref = QName
  substitutionGroup = QName
  type = QName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, ((simpleType | complexType)?, (unique | key | keyref)*))
</element>

If the

element information item has

as its parent, the corresponding schema component is as follows:

1 If the EBV is the empty string, then the empty set;

2 If the EBV is #all, then {extension, restriction, substitution};

3

a set with members drawn from the set above, each being present or absent depending on whether the

(which is a list) contains an equivalently named item.

Although the

of

may include values other than

,

or

, those values are ignored in the determination of

for element declarations (they

used elsewhere).

otherwise if the

element information item has

or

as an ancestor and the

is absent, the corresponding schema components are as follows (unless

, in which case the item corresponds to no component at all):

An element declaration as in the first case above, with the exception of its

and

properties, which are as below:

otherwise (the

element information item has

or

as an ancestor and the

is present), the corresponding schema component is as follows (unless

, in which case the item corresponds to no component at all):

<element> corresponds to an element declaration, and allows the type definition of that declaration to be specified either by reference or by explicit inclusion.

<element>s within <schema> produce global element declarations; <element>s within <group> or <complexType> produce either particles which contain global element declarations (if there's a ref attribute) or local declarations (otherwise). For complete declarations, top-level or local, the type attribute is used when the declaration can use a built-in or pre-declared type definition. Otherwise an anonymous <simpleType> or <complexType> is provided inline.

Element information items ·validated· by a top-level declaration must be qualified with the {target namespace} of that declaration (if this is ·absent·, the item must be unqualified). Control over whether element information items ·validated· by a local declaration must be similarly qualified or not is provided by the form [attribute], whose default is provided by the elementFormDefault [attribute] on the enclosing <schema>, via its determination of {target namespace}.

As noted above the names for top-level element declarations are in a separate ·symbol space· from the symbol spaces for the names of type definitions, so there can (but need not be) a simple or complex type definition with the same name as a top-level element. As with attribute names, the names of locally-scoped element declarations with no {target namespace} reside in symbol spaces local to the type definition which contains them.

Note that the above allows for two levels of defaulting for unspecified type definitions. An <element> with no referenced or included type definition will correspond to an element declaration which has the same type definition as the head of its substitution group if it identifies one, otherwise the ·ur-type definition·. This has the important consequence that the minimum valid element declaration, that is, one with only a name attribute and no contents, is also (nearly) the most general, validating any combination of text and element content and allowing any attributes, and providing for recursive validation where possible.

See below at XML Representation of Identity-constraint Definition Schema Components (§3.11.2) for <key>, <unique> and <keyref>.

<xs:element name="unconstrained"/>

<xs:element name="emptyElt">
 <xs:complexType>
  <xs:attribute ...>. . .</xs:attribute>
 </xs:complexType>
</xs:element>

<xs:element name="contextOne">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="myLocalElement" type="myFirstType"/>
   <xs:element ref="globalElement"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>

<xs:element name="contextTwo">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="myLocalElement" type="mySecondType"/>
   <xs:element ref="globalElement"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>

The first example above declares an element whose type, by default, is the

. The second uses an embedded anonymous complex type definition.

The last two examples illustrate the use of local element declarations. Instances of

within

will be constrained by

, while those within

will be constrained by

.

Note: The possibility that differing attribute declarations and/or content models would apply to elements with the same name in different contexts is an extension beyond the expressive power of a DTD in XML 1.0.

 <xs:complexType name="facet">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:attribute name="value" use="required"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>

 <xs:element name="facet" type="xs:facet" abstract="true"/>

 <xs:element name="encoding" substitutionGroup="xs:facet">
  <xs:complexType>
   <xs:complexContent>
    <xs:restriction base="xs:facet">
     <xs:sequence>
      <xs:element ref="annotation" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="value" type="xs:encodings"/>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:element name="period" substitutionGroup="xs:facet">
  <xs:complexType>
   <xs:complexContent>
    <xs:restriction base="xs:facet">
     <xs:sequence>
      <xs:element ref="annotation" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="value" type="xs:duration"/>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:complexType name="datatype">
  <xs:sequence>
   <xs:element ref="facet" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="name" type="xs:NCName" use="optional"/>
  . . .
 </xs:complexType>

An example from a previous version of the schema for datatypes. The facet type is defined and the facet element is declared to use it. The facet element is abstract -- it's only defined to stand as the head for a substitution group. Two further elements are declared, each a member of the facet substitution group. Finally a type is defined which refers to facet, thereby allowing either period or encoding (or any other member of the group).

In addition to the conditions imposed on

element information items by the schema for schemas:

of the following must be true:

1 default and fixed must not both be present.

2 If the item's parent is not

, then

of the following must be true:

2.1 One of ref or name must be present, but not both.

2.2 If

is present, then all of

,

,

,

,

,

,

,

,

,

and

must be absent, i.e. only

,

,

are allowed in addition to

, along with

.

For an element information item to be locally

with respect to an element declaration

of the following must be true:

1

The declaration must not be

.

3 The appropriate

among the following must be true:

3.2

is

and there is such an attribute information item and its

is

,

of the following must be true:

3.2.1 The element information item must have no character or element information item

.

5 The appropriate

among the following must be true:

5.1

the declaration has a

, the item has neither element nor character

and clause

has not applied,

of the following must be true:

5.2

the declaration has no

or the item has either element or character

or clause

has applied,

of the following must be true:

5.2.2 If there is a

and clause

has not applied,

of the following must be true:

5.2.2.1 The element information item must have no element information item

.

5.2.2.2 The appropriate

among the following must be true:

For an element information item to be locally

with respect to a type definition

of the following must be true:

1

The type definition must not be

;

3 The appropriate

among the following must be true:

3.1

the type definition is a simple type definition,

of the following must be true:

3.1.1 The element information item's

must be empty, excepting those whose

is identical to

and whose

is one of

,

,

or

.

3.1.2 The element information item must have no element information item

.

For an element information item which is the

to be

of the following must be true:

See

for the definition of

.

The first clause above applies when there is a reference to an undefined ID. The second applies when there is a multiply-defined ID. They are separated out to ensure that distinct error codes (see

) are associated with these two cases.

Although this rule applies at the

, in practice processors, particularly streaming processors, may wish to detect and signal the clause

case as it arises.

This reconstruction of

's

functionality is imperfect in that if the

is not the document element of an XML document, the results will not necessarily be the same as those a validating parser would give were the document to have a DTD with equivalent declarations.

The schema-validity assessment of an element information item depends on its

and the

of its element information item children and associated attribute information items, if any.

So for an element information item's schema-validity to be assessed

of the following must be true:

1

of the following must be true:

1.1

of the following must be true:

1.1.1 A non-

element declaration must be known for it, because

of the following is true

1.1.1.3

of the following must be true:

1.2

of the following must be true:

1.2.1 A non-

type definition is known for it because

of the following is true

1.2.1.2

of the following must be true:

1.2.1.2.1 There is an attribute information item among the element information item's

whose

is identical to

and whose

is

.

.

If the item cannot be

, because neither clause

nor clause

above are satisfied,

.

If an element information item is

with respect to a

as per

, in the

the item has a property:

Furthermore, the item has one of the following alternative sets of properties:

Either

or

If the

is a simple type definition or its

is a simple type definition, and that type definition has

, then calling

, there are three additional properties:

The first (

) alternative above is provided for applications such as query processors which need access to the full range of details about an item's

, for example the type hierarchy; the second, for lighter-weight processors for whom representing the significant parts of the type hierarchy as information items might be a significant burden.

Also, if the declaration has a

, the item has a property:

Note that if an element is

, then the

and

properties, or their alternatives, are based on the

.

All element declarations (see Element Declarations (§3.3)) must satisfy the following constraint.

of the following must be true:

6 Circular substitution groups are disallowed. That is, it must not be possible to return to an element declaration by repeatedly following the

property.

The following constraints define relations appealed to elsewhere in this specification.

For a string to be a valid default with respect to a type definition the appropriate

among the following must be true:

1

the type definition is a simple type definition,

the string must be

with respect to that definition as defined by

.

2

the type definition is a complex type definition,

of the following must be true:

2.2 The appropriate

among the following must be true:

For an element declaration (call it

) to be validly substitutable for another element declaration (call it

) subject to a blocking constraint (a subset of {

,

,

}, the value of a

)

of the following must be true:

1 D and C are the same element declaration.

2

of the following must be true:

2.1 The blocking constraint does not contain substitution.

Define

, the potential substitution group for

, as follows:

1 The element declaration itself is in P;

's actual

is then the set consisting of each member of

such that

of the following must be true:

Complex Type Definitions provide for:

• Constraining element information items by providing Attribute Declaration (§2.2.2.3)s governing the appearance and content of [attributes]
• Constraining element information item [children] to be empty, or to conform to a specified element-only or mixed content model, or else constraining the character information item [children] to conform to a specified simple type definition.
• Using the mechanisms of Type Definition Hierarchy (§2.2.1.1) to derive a complex type from another simple or complex type.
• Specifying ·post-schema-validation infoset contributions· for elements.
• Limiting the ability to derive additional types from a given complex type.
• Controlling the permission to substitute, in an instance, elements of a derived type for elements declared in a content model to be of a given complex type.

<xs:complexType name="PurchaseOrderType">
  <xs:sequence>
   <xs:element name="shipTo" type="USAddress"/>
   <xs:element name="billTo" type="USAddress"/>
   <xs:element ref="comment" minOccurs="0"/>
   <xs:element name="items"  type="Items"/>
  </xs:sequence>
  <xs:attribute name="orderDate" type="xs:date"/>
 </xs:complexType>

The XML representation of a complex type definition.

A complex type definition schema component has the following properties:

Complex types definitions are identified by their {name} and {target namespace}. Except for anonymous complex type definitions (those with no {name}), 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 {name}s and {target namespace}s are provided for reference from instances (see xsi:type (§2.6.1)), and for use in the XML representation of schema components (specifically in <element>). See References to schema components across namespaces (§4.2.3) for the use of component identifiers when importing one schema into another.

As described in Type Definition Hierarchy (§2.2.1.1), each complex type is derived from a {base type definition} which is itself either a Simple Type Definition (§2.2.1.2) or a Complex Type Definition (§2.2.1.3). {derivation method} specifies the means of derivation as either extension or restriction (see Type Definition Hierarchy (§2.2.1.1)).

A complex type with an empty specification for {final} can be used as a {base type definition} 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 [Definition:]  the complex type is said to be final, because no further derivations are possible. Finality is not inherited, that is, a type definition derived by restriction from a type definition which is final for extension is not itself, in the absence of any explicit final attribute of its own, final for anything.

Complex types for which {abstract} is true must not be used as the {type definition} for the ·validation· of element information items. It follows that they must not be referenced from an xsi:type (§2.6.1) attribute in an instance document. Abstract complex types can be used as {base type definition}s, or even as the {type definition}s of element declarations, provided in every case a concrete derived type definition is used for ·validation·, either via xsi:type (§2.6.1) or the operation of a substitution group.

{attribute uses} are a set of attribute uses. See Element Locally Valid (Complex Type) (§3.4.4) and Attribute Locally Valid (§3.2.4) for details of attribute ·validation·.

{attribute wildcard}s provide a more flexible specification for ·validation· of attributes not explicitly included in {attribute uses}. Informally, the specific values of {attribute wildcard} are interpreted as follows:

• any: [attributes] can include attributes with any qualified or unqualified name.
• a set whose members are either namespace names or ·absent·: [attributes] can include any attribute(s) from the specified namespace(s). If ·absent· is included in the set, then any unqualified attributes are (also) allowed.
• 'not' and a namespace name: [attributes] cannot include attributes from the specified namespace.
• 'not' and ·absent·: [attributes] cannot include unqualified attributes.

See Element Locally Valid (Complex Type) (§3.4.4) and Wildcard allows Namespace Name (§3.10.4) for formal details of attribute wildcard ·validation·.

{content type} determines the ·validation· of [children] of element information items. Informally:

• A {content type} with the distinguished value empty ·validates· elements with no character or element information item [children].
• A {content type} which is a Simple Type Definition (§2.2.1.2) ·validates· elements with character-only [children].
• An element-only {content type} ·validates· elements with [children] that conform to the supplied ·content model·.
• A mixed {content type} ·validates· elements whose element [children] (i.e. specifically ignoring other [children] such as character information items) conform to the supplied ·content model·.

{prohibited substitutions} determine whether an element declaration appearing in a · content model· is prevented from additionally ·validating· element items with an xsi:type (§2.6.1) attribute that identifies a complex type definition derived by extension or restriction from this definition, or element items in a substitution group whose type definition is similarly derived: If {prohibited substitutions} is empty, then all such substitutions are allowed, otherwise, the derivation method(s) it names are disallowed.

See Annotations (§3.13) for information on the role of the {annotations} property.

The XML representation for a complex type definition schema component is a <complexType> element information item.

The XML representation for complex type definitions with a simple type definition {content type} is significantly different from that of those with other {content type}s, and this is reflected in the presentation below, which displays first the elements involved in the first case, then those for the second. The property mapping is shown once for each case.

<complexType
  abstract = boolean : false
  block = (#all | List of (extension | restriction))
  final = (#all | List of (extension | restriction))
  id = ID
  mixed = boolean : false
  name = NCName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (simpleContent | complexContent | ((group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?))))
</complexType>

Whichever alternative for the content of

is chosen, the following property mappings apply:

1 If the EBV is the empty string, then the empty set;

2 If the EBV is #all, then {extension, restriction};

3

a set with members drawn from the set above, each being present or absent depending on whether the

(which is a list) contains an equivalently named item.

Although the

of

may include values other than

or

, those values are ignored in the determination of

for complex type definitions (they

used elsewhere).

<simpleContent
  id = ID
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (restriction | extension))
</simpleContent>

<restriction
  base = QName
  id = ID
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (simpleType?, (minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | length | minLength | maxLength | enumeration | whiteSpace | pattern)*)?, ((attribute | attributeGroup)*, anyAttribute?))
</restriction>

<extension
  base = QName
  id = ID
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, ((attribute | attributeGroup)*, anyAttribute?))
</extension>

<attributeGroup
  id = ID
  ref = QName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</attributeGroup>

<anyAttribute
  id = ID
  namespace = ((##any | ##other) | List of (anyURI | (##targetNamespace | ##local)) )  : ##any
  processContents = (lax | skip | strict) : strict
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</anyAttribute>

1

The set of attribute uses corresponding to the

, if any.

2

The

of the attribute groups

to by the

s of the

of the

, if any.

3 if the type definition

to by the

of the

is a complex type definition, the

of that type definition, unless the

alternative is chosen, in which case some members of that type definition's

may not be included, namely those whose

's

and

are the same as

of the following:

3.1 the

and

of the

of an attribute use in the set per clause

or clause

above;

3.2 what would have been the

and

of the

of an attribute use in the set per clause

above but for the

of the

of the relevant

among the

of

being

.

1

the appropriate

among the following:

1.1

there is an

present,

a wildcard based on the

s of the

and

and the

, exactly as for the wildcard corresponding to an

element as set out in

;

1.2

.

2

the appropriate

among the following:

2.1

there are no

corresponding to attribute groups with non-

s,

the

.

2.2

there are one or more

corresponding to attribute groups with non-

s,

the appropriate

among the following:

2.2.1

there is an

present,

a wildcard whose

and

are those of the

, and whose

is the intensional intersection of the

of the

and of the

s of all the non-

s of the attribute groups corresponding to the

, as defined in

.

2.2.2

there is no

present,

a wildcard whose properties are as follows:

{process contents}

The {process contents} of the first non-·absent· {attribute wildcard} of an attribute group among the attribute groups corresponding to the <attributeGroup> [children].

{namespace constraint}

The intensional intersection of the {namespace constraint}s of all the non-·absent· {attribute wildcard}s of the attribute groups corresponding to the <attributeGroup> [children], as defined in Attribute Wildcard Intersection (§3.10.6).

{annotation}

·absent·.

3 The value is then determined by the appropriate

among the following:

3.1

the

alternative is chosen,

the

;

3.2

the

alternative is chosen,

3.2.1

the appropriate

among the following:

3.2.1.1

the type definition

to by the

of the

is a complex type definition with an

,

that

.

3.2.1.2

.

3.2.2 The value is then determined by the appropriate

among the following:

3.2.2.1

the

is non-

,

the appropriate

among the following:

3.2.2.1.1

the

is

,

the

.

3.2.2.1.2

a wildcard whose

and

are those of the

, and whose

is the intensional union of the

of the

and of the

, as defined in

.

3.2.2.2

(the

is

) the

1

the type definition

to by the

of the

is a complex type definition whose own

is a simple type definition and the

alternative is chosen,

starting from either

1.1

the simple type definition corresponding to the

among the

of

if there is one;

1.2

otherwise (

has no

among its

), the simple type definition which is the

of the type definition

to by the

of the

a simple type definition which restricts the simple type definition identified in clause

or clause

with a set of facet components corresponding to the appropriate element information items among the

's

(i.e. those which specify facets, if any), as defined in

;

2

the type definition

to by the

of the

is a complex type definition whose own

is

and a particle which is

, as defined in

and the

alternative is chosen,

starting from the simple type definition corresponding to the

among the

of

(which must be present) a simple type definition which restricts that simple type definition with a set of facet components corresponding to the appropriate element information items among the

's

(i.e. those which specify facets, if any), as defined in

;

3

the type definition

to by the

of the

is a complex type definition (whose own

must be a simple type definition, see below) and the

alternative is chosen,

the

of that complex type definition;

4

(the type definition

to by the

of the

is a simple type definition and the

alternative is chosen), then that simple type definition.

The property mappings below are

used in the case where the third alternative (neither

nor

) is chosen. This case is understood as shorthand for complex content restricting the

, and the details of the mappings should be modified as necessary.

<complexContent
  id = ID
  mixed = boolean
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (restriction | extension))
</complexContent>

<restriction
  base = QName
  id = ID
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?))
</restriction>

<extension
  base = QName
  id = ID
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, ((group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?)))
</extension>

1

The set of attribute uses corresponding to the

, if any.

2

The

of the attribute groups

to by the

s of the

of the

, if any.

3 The

of the type definition

to by the

of the

, unless the

alternative is chosen, in which case some members of that type definition's

may not be included, namely those whose

's

and

are the same as

of the following:

3.1 The

and

of the

of an attribute use in the set per clause

or clause

above;

3.2 what would have been the

and

of the

of an attribute use in the set per clause

above but for the

of the

of the relevant

among the

of

being

.

1

the appropriate

among the following:

1.1

the

is present on

,

its

;

1.2

the

is present on

,

its

;

1.3 otherwise false.

2

the appropriate

among the following:

2.1

of the following is true

2.1.1 There is no

,

,

or

among the

;

2.1.2 There is an

or

among the

with no

of its own excluding

;

2.1.3 There is a

among the

with no

of its own excluding

whose

has the

;

,

the appropriate

among the following:

2.1.4

the

is

,

A particle whose properties are as follows:

{min occurs}

1

{max occurs}

1

{term}

A model group whose {compositor} is sequence and whose {particles} is empty.

.

2.1.5 otherwise empty

2.2

the particle corresponding to the

,

,

or

among the

.

3 Then the value of the property is the appropriate

among the following:

3.1

the

alternative is chosen,

the appropriate

among the following:

3.1.1

the

is

,

;

3.1.2

a pair consisting of

3.1.2.1

if the

is

, otherwise

3.1.2.2 The

.

3.2

the

alternative is chosen,

the appropriate

among the following:

3.2.1

the

is

,

the

of the type definition

to by the

of the

3.2.2

the type definition

to by the

of the

has a

of

,

a pair as per clause

above;

3.2.3

a pair of

or

(determined as per clause

above) and a particle whose properties are as follows:

{min occurs}

1

{max occurs}

1

{term}

A model group whose {compositor} is sequence and whose {particles} are the particle of the {content type} of the type definition ·resolved· to by the ·actual value· of the base [attribute] followed by the ·effective content·.

Careful consideration of the above concrete syntax reveals that a type definition need consist of no more than a name, i.e. that <complexType name="anyThing"/> is allowed.

<xs:complexType name="length1">
 <xs:simpleContent>
  <xs:extension base="xs:nonNegativeInteger">
   <xs:attribute name="unit" type="xs:NMTOKEN"/>
  </xs:extension>
 </xs:simpleContent>
</xs:complexType>

<xs:element name="width" type="length1"/>

  <width unit="cm">25</width>

<xs:complexType name="length2">
 <xs:complexContent>
  <xs:restriction base="xs:anyType">
   <xs:sequence>
    <xs:element name="size" type="xs:nonNegativeInteger"/>
    <xs:element name="unit" type="xs:NMTOKEN"/>
   </xs:sequence>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>

<xs:element name="depth" type="length2"/>

  <depth>
   <size>25</size><unit>cm</unit>
  </depth>

<xs:complexType name="length3">
 <xs:sequence>
  <xs:element name="size" type="xs:nonNegativeInteger"/>
  <xs:element name="unit" type="xs:NMTOKEN"/>
 </xs:sequence>
</xs:complexType>

Three approaches to defining a type for length: one with character data content constrained by reference to a built-in datatype, and one attribute, the other two using two elements. length3 is the abbreviated alternative to length2: they correspond to identical type definition components.

<xs:complexType name="personName">
 <xs:sequence>
  <xs:element name="title" minOccurs="0"/>
  <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>
  <xs:element name="surname"/>
 </xs:sequence>
</xs:complexType>

<xs:complexType name="extendedName">
 <xs:complexContent>
  <xs:extension base="personName">
   <xs:sequence>
    <xs:element name="generation" minOccurs="0"/>
   </xs:sequence>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

<xs:element name="addressee" type="extendedName"/>

  <addressee>
   <forename>Albert</forename>
   <forename>Arnold</forename>
   <surname>Gore</surname>
   <generation>Jr</generation>
  </addressee>

A type definition for personal names, and a definition derived by extension which adds a single element; an element declaration referencing the derived definition, and a

instance thereof.

<xs:complexType name="simpleName">
 <xs:complexContent>
  <xs:restriction base="personName">
   <xs:sequence>
    <xs:element name="forename" minOccurs="1" maxOccurs="1"/>
    <xs:element name="surname"/>
   </xs:sequence>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>

<xs:element name="who" type="simpleName"/>

   <who>
    <forename>Bill</forename>
    <surname>Clinton</surname>
   </who>

A simplified type definition derived from the base type from the previous example by restriction, eliminating one optional daughter and fixing another to occur exactly once; an element declared by reference to it, and a

instance thereof.

<xs:complexType name="paraType" mixed="true">
 <xs:choice minOccurs="0" maxOccurs="unbounded">
  <xs:element ref="emph"/>
  <xs:element ref="strong"/>
 </xs:choice>
 <xs:attribute name="version" type="xs:number"/>
</xs:complexType>

A further illustration of the abbreviated form, with the mixed attribute appearing on complexType itself.

In addition to the conditions imposed on

element information items by the schema for schemas,

of the following must be true:

2 If the

alternative is chosen,

of the following must be true:

Although not explicitly ruled out either here or in

, specifying

when the

alternative is chosen has no effect on the corresponding component, and should be avoided. This may be ruled out in a subsequent version of this specification.

For an element information item to be locally

with respect to a complex type definition

of the following must be true:

3

For each attribute information item in the element information item's

excepting those whose

is identical to

and whose

is one of

,

,

or

, the appropriate

among the following must be true:

3.2

of the following must be true:

When an

is present, this does

introduce any ambiguity with respect to how attribute information items for which an attribute use is present amongst the

whose name and target namespace match are

. In such cases the attribute use

takes precedence, and the

of such items stands or falls entirely on the basis of the attribute use and its

. This follows from the details of clause

.

All complex type definitions (see Complex Type Definitions (§3.4)) must satisfy the following constraints.

of the following must be true:

If the

is

, the appropriate

among the following must be true:

1

the

is a complex type definition,

of the following must be true:

1.4

of the following must be true:

1.4.3

of the following must be true:

1.4.3.1 The

of the complex type definition itself must specify a particle.

1.4.3.2

of the following must be true:

1.4.3.2.2

of the following must be true:

1.4.3.2.2.1 Both

s must be

or both must be

.

1.5 It must in principle be possible to derive the complex type definition in two steps, the first an extension and the second a restriction (possibly vacuous), from that type definition among its ancestors whose

is the

.

This requirement ensures that nothing removed by a restriction is subsequently added back by an extension. It is trivial to check if the extension in question is the only extension in its derivation, or if there are no restrictions bar the first from the

.

Constructing the intermediate type definition to check this constraint is straightforward: simply re-order the derivation to put all the extension steps first, then collapse them into a single extension. If the resulting definition can be the basis for a valid restriction to the desired definition, the constraint is satisfied.

.

If the

is

of the following must be true:

2

For each attribute use (call this

) in the

the appropriate

among the following must be true:

5

of the following must be true:

5.2

of the following must be true:

5.2.1 The

of the complex type definition must be a simple type definition

5.2.2

of the following must be true:

5.3

of the following must be true:

5.3.2

of the following must be true:

5.4

of the following must be true:

5.4.1

of the following must be true:

5.4.1.1 The

of the complex type definition itself must be

.

Note: To restrict a complex type definition with a simple base type definition to empty, use a simple type definition with a fixed value of the empty string: this preserves the type information.

The following constraint defines a relation appealed to elsewhere in this specification.

For a complex type definition (call it

, for derived) to be validly derived from a type definition (call this

, for base) given a subset of {

,

}

of the following must be true:

1 If

and

are not the same type definition, then the

of

must not be in the subset.

2

of the following must be true:

2.1

and

must be the same type definition.

2.3

of the following must be true:

2.3.2 The appropriate

among the following must be true:

2.3.2.1

's

is complex,

it must be validly derived from

given the subset as defined by this constraint.

Note: This constraint is used to check that when someone uses a type in a context where another type was expected (either via xsi:type or substitution groups), that the type used is actually derived from the expected type, and that that derivation does not involve a form of derivation which was ruled out by the expected type.

Note:

The wording of clause

above appeals to a notion of component identity which is only incompletely defined by this version of this specification. In some cases, the wording of this specification does make clear the rules for component identity. These cases include:

• When they are both top-level components with the same component type, namespace name, and local name;
• When they are necessarily the same type definition (for example, when the two types definitions in question are the type definitions associated with two attribute or element declarations, which are discovered to be the same declaration);
• When they are the same by construction (for example, when an element's type definition defaults to being the same type definition as that of its substitution-group head or when a complex type definition inherits an attribute declaration from its base type definition).

In other cases two conforming implementations may disagree as to whether components are identical.

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

The mixed content specification together with the lax wildcard and attribute specification produce the defining property for the ·ur-type definition·, namely that every type definition is (eventually) a restriction of the ·ur-type definition·: its permissions and requirements are (nearly) the least restrictive possible.

This specification does not provide an inventory of built-in complex type definitions for use in user schemas. A preliminary library of complex type definitions is available which includes both mathematical (e.g.

) and utility (e.g.

) type definitions. In particular, there is a

type definition which is recommended for use as the type definition in element declarations intended for general text content, as it makes sensible provision for various aspects of internationalization. For more details, see the schema document for the type library at its namespace name:

.

An attribute use is a utility component which controls the occurrence and defaulting behavior of attribute declarations. It plays the same role for attribute declarations in complex types that particles play for element declarations.

<xs:complexType>
 . . .
 <xs:attribute ref="xml:lang" use="required"/>
 <xs:attribute ref="xml:space" default="preserve"/>
 <xs:attribute name="version" type="xs:number" fixed="1.0"/>
</xs:complexType>
     

XML representations which all involve attribute uses, illustrating some of the possibilities for controlling occurrence.

The attribute use schema component has the following properties:

{required} determines whether this use of an attribute declaration requires an appropriate attribute information item to be present, or merely allows it.

{attribute declaration} provides the attribute declaration itself, which will in turn determine the simple type definition used.

{value constraint} allows for local specification of a default or fixed value. This must be consistent with that of the {attribute declaration}, in that if the {attribute declaration} specifies a fixed value, the only allowed {value constraint} is the same fixed value.

None as such.

None as such.

All attribute uses (see AttributeUses (§3.5)) must satisfy the following constraints.

of the following must be true:

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 {attribute uses} and {attribute wildcard} 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 XML representation of schema components (see <complexType> and <attributeGroup>).

<xs:attributeGroup name="myAttrGroup">
    <xs:attribute . . ./>
    . . .
</xs:attributeGroup>

<xs:complexType name="myelement">
    . . .
    <xs:attributeGroup ref="myAttrGroup"/>
</xs:complexType>

XML representations for attribute group definitions. The effect is as if the attribute declarations in the group were present in the type definition.

The XML representation for an attribute group definition schema component is an <attributeGroup> element information item. It provides for naming a group of attribute declarations and an attribute wildcard for use by reference in the XML representation of complex type definitions and other attribute group definitions. The correspondences between the properties of the information item and properties of the component it corresponds to are as follows:

The example above illustrates a pattern which recurs in the XML representation of schemas: The same element, in this case attributeGroup, serves both to define and to incorporate by reference. In the first case the name attribute is required, in the second the ref attribute is required, and the element must be empty. These two are mutually exclusive, and also conditioned by context: the defining form, with a name, must occur at the top level of a schema, whereas the referring form, with a ref, must occur within a complex type definition or an attribute group definition.

In addition to the conditions imposed on

element information items by the schema for schemas,

of the following must be true:

None as such.

None as such.

All attribute group definitions (see Attribute Group Definitions (§3.6)) must satisfy the following constraint.

of the following must be true:

A model group definition associates a name and optional annotations with a Model Group (§2.2.3.1). By reference to the name, the entire model group can be incorporated by reference into a {term}.

Model group definitions are provided primarily for reference from the XML Representation of Complex Type Definitions (§3.4.2) (see <complexType> and <group>). Thus, model group definitions provide a replacement for some uses of XML's parameter entity facility.

<xs:group name="myModelGroup">
 <xs:sequence>
  <xs:element ref="someThing"/>
  . . .
 </xs:sequence>
</xs:group>

<xs:complexType name="trivial">
 <xs:group ref="myModelGroup"/>
 <xs:attribute .../>
</xs:complexType>

<xs:complexType name="moreSo">
 <xs:choice>
  <xs:element ref="anotherThing"/>
  <xs:group ref="myModelGroup"/>
 </xs:choice>
 <xs:attribute .../>
</xs:complexType>

A minimal model group is defined and used by reference, first as the whole content model, then as one alternative in a choice.

The XML representation for a model group definition schema component is a <group> element information item. It provides for naming a model group for use by reference in the XML representation of complex type definitions and model groups. The correspondences between the properties of the information item and properties of the component it corresponds to are as follows:

<group
  id = ID
  maxOccurs = (nonNegativeInteger | unbounded)  : 1
  minOccurs = nonNegativeInteger : 1
  name = NCName
  ref = QName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (all | choice | sequence)?)
</group>

If there is a

(in which case the item will have

or

as parent), then the item corresponds to a model group definition component with properties as follows:

Otherwise, the item will have a

, in which case it corresponds to a particle component with properties as follows (unless

, in which case the item corresponds to no component at all):

The name of this section is slightly misleading, in that the second, un-named, case above (with a ref and no name) is not really a named model group at all, but a reference to one. Also note that in the first (named) case above no reference is made to minOccurs or maxOccurs: this is because the schema for schemas does not allow them on the child of <group> when it is named. This in turn is because the {min occurs} and {max occurs} of the particles which refer to the definition are what count.

Given the constraints on its appearance in content models, an <all> should only occur as the only item in the [children] of a named model group definition or a content model: see Constraints on Model Group Schema Components (§3.8.6).

None as such.

None as such.

All model group definitions (see Model Group Definitions (§3.7)) must satisfy the following constraint.

When the [children] of element information items are not constrained to be empty or by reference to a simple type definition (Simple Type Definitions (§3.14)), the sequence of element information item [children] content may be specified in more detail with a model group. Because the {term} 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.

<xs:all>
 <xs:element ref="cats"/>
 <xs:element ref="dogs"/>
</xs:all>

<xs:sequence>
 <xs:choice>
  <xs:element ref="left"/>
  <xs:element ref="right"/>
 </xs:choice>
 <xs:element ref="landmark"/>
</xs:sequence>

XML representations for the three kinds of model group, the third nested inside the second.

The model group schema component has the following properties:

specifies a sequential (sequence), disjunctive (choice) or conjunctive (all) interpretation of the {particles}. This in turn determines whether the element information item [children] ·validated· by the model group must:

• (sequence) correspond, in order, to the specified {particles};
• (choice) corresponded to exactly one of the specified {particles};
• (all) contain all and only exactly zero or one of each element specified in {particles}. The elements can occur in any order. In this case, to reduce implementation complexity, {particles} is restricted to contain local and top-level element declarations only, with {min occurs}=0 or 1, {max occurs}=1.

When two or more particles contained directly or indirectly in the {particles} of a model group have identically named element declarations as their {term}, the type definitions of those declarations must be the same. By 'indirectly' is meant particles within the {particles} of a group which is itself the {term} of a directly contained particle, and so on recursively.

See Annotations (§3.13) for information on the role of the {annotation} property.

The XML representation for a model group schema component is either an <all>, a <choice> or a <sequence> element information item. The correspondences between the properties of those information items and properties of the component they correspond to are as follows:

.

For a sequence (possibly empty) of element information items to be locally

with respect to a model group the appropriate

among the following must be true:

Nothing in the above should be understood as ruling out groups whose

is empty: although no sequence can be

with respect to such a group whose

is

, the empty sequence

with respect to empty groups whose

is

or

.

The above definition is implicitly non-deterministic, and should not be taken as a recipé for implementations. Note in particular that when

is

, particles is restricted to a list of local and top-level element declarations (see

). A much simpler implementation is possible than would arise from a literal interpretation of the definition above; informally, the content is

when each declared element occurs exactly once (or at most once, if

is

), and each is

with respect to its corresponding declaration. The elements can occur in arbitrary order.

None as such.

All model groups (see Model Groups (§3.8)) must satisfy the following constraints.

of the following must be true:

2 Circular groups are disallowed. That is, within the

of a group there must not be at any depth a particle whose

is the group itself.

When a model group has

, then

of the following must be true:

1 It appears only as the value of one or both of the following properties:

If the

contains, either directly, indirectly (that is, within the

of a contained model group, recursively) or

two or more element declaration particles with the same

and

, then all their type definitions must be the same top-level definition, that is,

of the following must be true:

.

A content model must be formed such that during

of an element information item sequence, the particle component contained directly, indirectly or

therein with which to attempt to

each item in the sequence in turn can be uniquely determined without examining the content or attributes of that item, and without any information about the items in the remainder of the sequence.

This constraint reconstructs for XML Schema the equivalent constraints of

and SGML. Given the presence of element substitution groups and wildcards, the concise expression of this constraint is difficult, see

for further discussion.

Since this constraint is expressed at the component level, it applies to content models whose origins (e.g. via type derivation and references to named model groups) are no longer evident. So particles at different points in the content model are always distinct from one another, even if they originated from the same named model group.

Because locally-scoped element declarations may or may not have a

, the scope of declarations is

relevant to enforcing either of the two preceding constraints.

The following constraints define relations appealed to elsewhere in this specification.

The effective total range of a particle whose

is a group whose

is

or

is a pair of minimum and maximum, as follows:

minimum

The product of the particle's {min occurs} and the sum of the {min occurs} of every wildcard or element declaration particle in the group's {particles} and the minimum part of the effective total range of each of the group particles in the group's {particles} (or 0 if there are no {particles}).

maximum

unbounded if the {max occurs} of any wildcard or element declaration particle in the group's {particles} or the maximum part of the effective total range of any of the group particles in the group's {particles} is unbounded, or if any of those is non-zero and the {max occurs} of the particle itself is unbounded, otherwise the product of the particle's {max occurs} and the sum of the {max occurs} of every wildcard or element declaration particle in the group's {particles} and the maximum part of the effective total range of each of the group particles in the group's {particles} (or 0 if there are no {particles}).

The effective total range of a particle whose

is a group whose

is

is a pair of minimum and maximum, as follows:

minimum

The product of the particle's {min occurs} and the minimum of the {min occurs} of every wildcard or element declaration particle in the group's {particles} and the minimum part of the effective total range of each of the group particles in the group's {particles} (or 0 if there are no {particles}).

maximum

unbounded if the {max occurs} of any wildcard or element declaration particle in the group's {particles} or the maximum part of the effective total range of any of the group particles in the group's {particles} is unbounded, or if any of those is non-zero and the {max occurs} of the particle itself is unbounded, otherwise the product of the particle's {max occurs} and the maximum of the {max occurs} of every wildcard or element declaration particle in the group's {particles} and the maximum part of the effective total range of each of the group particles in the group's {particles} (or 0 if there are no {particles}).

As described in Model Groups (§3.8), particles contribute to the definition of content models.

<xs:element ref="egg" minOccurs="12" maxOccurs="12"/>

<xs:group ref="omelette" minOccurs="0"/>

<xs:any maxOccurs="unbounded"/>
     

XML representations which all involve particles, illustrating some of the possibilities for controlling occurrence.

The particle schema component has the following properties:

{min occurs}

A non-negative integer.

{max occurs}

Either a non-negative integer or unbounded.

{term}

One of a model group, a wildcard, or an element declaration.

In general, multiple element information item [children], possibly with intervening character [children] if the content type is mixed, can be ·validated· with respect to a single particle. When the {term} is an element declaration or wildcard, {min occurs} determines the minimum number of such element [children] that can occur. The number of such children must be greater than or equal to {min occurs}. If {min occurs} is 0, then occurrence of such children is optional.

Again, when the {term} is an element declaration or wildcard, the number of such element [children] must be less than or equal to any numeric specification of {max occurs}; if {max occurs} is unbounded, then there is no upper bound on the number of such children.

When the {term} is a model group, the permitted occurrence range is determined by a combination of {min occurs} and {max occurs} and the occurrence ranges of the {term}'s {particles}.

None as such.

For a sequence (possibly empty) of element information items to be locally

with respect to a particle the appropriate

among the following must be true:

1

the

is a wildcard,

of the following must be true:

1.1 The length of the sequence must be greater than or equal to the

.

2

the

is an element declaration,

of the following must be true:

2.1 The length of the sequence must be greater than or equal to the

.

2.3 For each element information item in the sequence

of the following must be true:

3

the

is a model group,

of the following must be true:

3.1 There is a

of the sequence into

sub-sequences such that

is greater than or equal to

.

Clauses clause

and clause

do not interact: an element information item validatable by a declaration with a substitution group head in a different namespace is

validatable by a wildcard which accepts the head's namespace but not its own.

None as such.

All particles (see Particles (§3.9)) must satisfy the following constraints.

of the following must be true:

2 If

is not

, that is, it has a numeric value, then

of the following must be true:

The following constraints define relations appealed to elsewhere in this specification.

of the following must be true:

1 They are the same particle.

2

's

=

and its

is a

group whose

' first member is a particle all of whose properties, recursively, are identical to those of

, with the exception of

properties.

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.

Note: The structural correspondence approach to guaranteeing the subset relation set out here is necessarily verbose, but has the advantage of being checkable in a straightforward way. The working group solicits feedback on how difficult this is in practice, and on whether other approaches are found to be viable.

of the following must be true:

1 They are the same particle.

2 depending on the kind of particle, per the table below, with the qualifications that

of the following must be true:

2.2 Any pointless occurrences of

,

or

are ignored, where pointlessness is understood as follows:

<sequence>

One of the following must be true:

2.2.2

All

of the following must be true:

2.2.2.2

One

of the following must be true:

<all>

One of the following must be true:

<choice>

One of the following must be true:

2.2.2

All

of the following must be true:

2.2.2.2

One

of the following must be true:

For a particle's occurrence range to be a valid restriction of another's occurrence range

of the following must be true:

2

of the following must be true:

2.2 Both

are numbers, and the particle's is less than or equal to the other's.

For an element declaration particle to be a

of another element declaration particle

of the following must be true:

3

of the following must be true:

3.1 Both

's declaration's

and

's declaration's

are

.

3.2

of the following must be true:

The above constraint on

means that in deriving a type by restriction, any contained type definitions must themselves be explicitly derived by restriction from the corresponding type definitions in the base definition, or be one of the member types of a corresponding union..

For an element declaration particle to be a

of a wildcard particle

of the following must be true:

For a wildcard particle to be a

of another wildcard particle

of the following must be true:

For a group particle to be a

of a wildcard particle

of the following must be true:

For an

or

group particle to be a

of another group particle with the same

of the following must be true:

Although the

semantics of an

group does not depend on the order of its particles, derived

groups are required to match the order of their base in order to simplify checking that the derivation is OK.

.

For a

group particle to be a

of another

group particle

of the following must be true:

Although the

semantics of a

group does not depend on the order of its particles, derived

groups are required to match the order of their base in order to simplify checking that the derivation is OK.

For a

group particle to be a

of an

group particle

of the following must be true:

2 There is a complete functional mapping from the particles in the

of

to the particles in the

of

such that

of the following must be true:

2.1 No particle in the

of

is mapped to by more than one of the particles in the

of

;

Note: Although this clause allows reordering, because of the limits on the contents of all groups the checking process can still be deterministic.

For a

group particle to be a

of a

group particle

of the following must be true:

2 The pair consisting of the product of the

of

and the length of its

and

if

is

otherwise the product of the

of

and the length of its

is a valid restriction of

's occurrence range as defined by

.

Note: This clause is in principle more restrictive than absolutely necessary, but in practice will cover all the likely cases, and is much easier to specify than the fully general version.

Note: This case allows the "unfolding" of iterated disjunctions into sequences. It may be particularly useful when the disjunction is an implicit one arising from the use of substitution groups.

of the following must be true:

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 name, but independently of their local name.

<xs:any processContents="skip"/>

<xs:any namespace="##other" processContents="lax"/>

<xs:any namespace="http://www.w3.org/1999/XSL/Transform"/>

<xs:any namespace="##targetNamespace"/>

<xs:anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/>

XML representations of the four basic types of wildcard, plus one attribute wildcard.

The wildcard schema component has the following properties:

{namespace constraint} provides for ·validation· of attribute and element items that:

1. (any) have any namespace or are not namespace-qualified;
2. (not and a namespace name) are namespace-qualified with a namespace other than the specified namespace name;
3. (not and ·absent·) are namespace-qualified;
4. (a set whose members are either namespace names or ·absent·) have any of the specified namespaces and/or, if ·absent· is included in the set, are unqualified.

{process contents} controls the impact on ·assessment· of the information items allowed by wildcards, as follows:

strict

There must be a top-level declaration for the item available, or the item must have an xsi:type, and the item must be ·valid· as appropriate.

skip

No constraints at all: the item must simply be well-formed XML.

lax

If the item has a uniquely determined declaration available, it must be ·valid· with respect to that definition, that is, ·validate· if you can, don't worry if you can't.

See Annotations (§3.13) for information on the role of the {annotation} property.

The XML representation for a wildcard schema component is an <any> or <anyAttribute> element information item. The correspondences between the properties of an <any> information item and properties of the components it corresponds to are as follows (see <complexType> and <attributeGroup> for the correspondences for <anyAttribute>):

<any
  id = ID
  maxOccurs = (nonNegativeInteger | unbounded)  : 1
  minOccurs = nonNegativeInteger : 1
  namespace = ((##any | ##other) | List of (anyURI | (##targetNamespace | ##local)) )  : ##any
  processContents = (lax | skip | strict) : strict
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</any>

A particle containing a wildcard, with properties as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all):

##any

any

##other

a pair of not and the ·actual value· of the targetNamespace [attribute] of the <schema> ancestor element information item if present, otherwise ·absent·.

otherwise

a set whose members are namespace names corresponding to the space-delimited substrings of the string, except

1 if one such substring is

##targetNamespace

, the corresponding member is the

·actual value·

of the

targetNamespace [attribute]

of the

<schema>

ancestor element information item if present, otherwise

·absent·

.

2 if one such substring is

##local

, the corresponding member is

·absent·

.

Wildcards are subject to the same ambiguity constraints (Unique Particle Attribution (§3.8.6)) as other content model particles: If an instance element could match either an explicit particle and a wildcard, or one of two wildcards, within the content model of a type, that model is in error.

For a value which is either a namespace name or

to be

with respect to a wildcard constraint (the value of a

)

of the following must be true:

1 The constraint must be any.

2

of the following must be true:

2.1 The constraint is a pair of

and a namespace name or

(

.

3 The constraint is a set, and the value is identical to one of the members of the set.

None as such.

All wildcards (see Wildcards (§3.10)) must satisfy the following constraint.

The following constraints define a relation appealed to elsewhere in this specification.

For a namespace constraint (call it

) to be an intensional subset of another namespace constraint (call it

)

of the following must be true:

1 super must be any.

2

of the following must be true:

2.1

must be a pair of

and a value (a namespace name or

).

2.2 super must be a pair of not and the same value.

3

of the following must be true:

3.1

must be a set whose members are either namespace names or

.

3.2

of the following must be true:

3.2.1 super must be the same set or a superset thereof.

3.2.2

must be a pair of

and a value (a namespace name or

) and neither that value nor

must be in

's set.

For a wildcard's

value to be the intensional union of two other such values (call them

and

): the appropriate

among the following must be true:

1 If O1 and O2 are the same value, then that value must be the value.

2 If either O1 or O2 is any, then any must be the value.

3

both

and

are sets of (namespace names or

),

the union of those sets must be the value.

4

the two are negations of different values (namespace names or

),

a pair of

and

must be the value.

5

either

or

is a pair of

and a namespace name and the other is a set of (namespace names or

) (call this set

),

The appropriate

among the following must be true:

5.1

the set

includes both the negated namespace name and

,

must be the value.

5.2

the set

includes the negated namespace name but not

,

a pair of

and

must be the value.

5.3

the set

includes

but not the negated namespace name,

the union is not expressible.

5.4

the set

does not include either the negated namespace name or

,

whichever of

or

is a pair of

and a namespace name must be the value.

6

either

or

is a pair of

and

and the other is a set of (namespace names or

) (again, call this set

),

The appropriate

among the following must be true:

6.1

the set

includes

,

must be the value.

6.2

the set

does not include

,

a pair of

and

must be the value.

In the case where there are more than two values, the intensional union is determined by identifying the intensional union of two of the values as above, then the intensional union of that value with the third (providing the first union was expressible), and so on as required.

For a wildcard's

value to be the intensional intersection of two other such values (call them

and

): the appropriate

among the following must be true:

1 If O1 and O2 are the same value, then that value must be the value.

2 If either O1 or O2 is any, then the other must be the value.

3

either

or

is a pair of

and a value (a namespace name or

) and the other is a set of (namespace names or

),

that set, minus the negated value if it was in the set, minus

if it was in the set, must be the value.

4

both

and

are sets of (namespace names or

),

the intersection of those sets must be the value.

5 If the two are negations of different namespace names, then the intersection is not expressible.

6

the one is a negation of a namespace name and the other is a negation of

,

the one which is the negation of a namespace name must be the value.

In the case where there are more than two values, the intensional intersection is determined by identifying the intensional intersection of two of the values as above, then the intensional intersection of that value with the third (providing the first intersection was expressible), and so on as required.

Identity-constraint definition components provide for uniqueness and reference constraints with respect to the contents of multiple elements and attributes.

<xs:key name="fullName">
 <xs:selector xpath=".//person"/>
 <xs:field xpath="forename"/>
 <xs:field xpath="surname"/>
</xs:key>

<xs:keyref name="personRef" refer="fullName">
 <xs:selector xpath=".//personPointer"/>
 <xs:field xpath="@first"/>
 <xs:field xpath="@last"/>
</xs:keyref>

<xs:unique name="nearlyID">
 <xs:selector xpath=".//*"/>
 <xs:field xpath="@id"/>
</xs:unique>

XML representations for the three kinds of identity-constraint definitions.

The identity-constraint definition schema component has the following properties:

Identity-constraint definitions are identified by their {name} and {target namespace}; Identity-constraint definition identities must be unique within an ·XML Schema·. See References to schema components across namespaces (§4.2.3) for the use of component identifiers when importing one schema into another.

Informally, {identity-constraint category} identifies the Identity-constraint definition as playing one of three roles:

• (unique) the Identity-constraint definition asserts uniqueness, with respect to the content identified by {selector}, of the tuples resulting from evaluation of the {fields} XPath expression(s).
• (key) the Identity-constraint definition asserts uniqueness as for unique. key further asserts that all selected content actually has such tuples.
• (keyref) the Identity-constraint definition asserts a correspondence, with respect to the content identified by {selector}, of the tuples resulting from evaluation of the {fields} XPath expression(s), with those of the {referenced key}.

These constraints are specified along side the specification of types for 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 apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. Values of differing type can only be equal if one type is derived from the other, and the value is in the value space of both.

Overall the augmentations to XML's ID/IDREF mechanism are:

• Functioning as a part of an identity-constraint is in addition to, not instead of, having a type;
• Not just attribute values, but also element content and combinations of values and content can be declared to be unique;
• Identity-constraints are specified to hold within the scope of particular elements;
• (Combinations of) attribute values and/or element content can be declared to be keys, that is, not only unique, but always present and non-nillable;
• The comparison between keyref {fields} and key or unique {fields} is by value equality, not by string equality.

{selector} specifies a restricted XPath ([XPath]) expression relative to instances of the element being declared. This must identify a node set of subordinate elements (i.e. contained within the declared element) to which the constraint applies.

{fields} specifies XPath expressions relative to each element selected by a {selector}. This must identify a single node (element or attribute) 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 {fields}s, to cater to multi-field keys, keyrefs, and uniqueness constraints.

In order to reduce the burden on implementers, in particular implementers of streaming processors, only restricted subsets of XPath expressions are allowed in {selector} and {fields}. The details are given in Constraints on Identity-constraint Definition Schema Components (§3.11.6).

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

See Annotations (§3.13) for information on the role of the {annotation} property.

The XML representation for an identity-constraint definition schema component is either a <key>, a <keyref> or a <unique> element information item. The correspondences between the properties of those information items and properties of the component they correspond to are as follows:

<unique
  id = ID
  name = NCName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (selector, field+))
</unique>

<key
  id = ID
  name = NCName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (selector, field+))
</key>

<keyref
  id = ID
  name = NCName
  refer = QName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (selector, field+))
</keyref>

<selector
  id = ID
  xpath = a subset of XPath expression, see below
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</selector>

<field
  id = ID
  xpath = a subset of XPath expression, see below
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</field>

<xs:element name="vehicle">
 <xs:complexType>
  . . .
  <xs:attribute name="plateNumber" type="xs:integer"/>
  <xs:attribute name="state" type="twoLetterCode"/>
 </xs:complexType>
</xs:element>

<xs:element name="state">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="code" type="twoLetterCode"/>
   <xs:element ref="vehicle" maxOccurs="unbounded"/>
   <xs:element ref="person" maxOccurs="unbounded"/>
  </xs:sequence>
 </xs:complexType>

 <xs:key name="reg"> <!-- vehicles are keyed by their plate within states -->
  <xs:selector xpath=".//vehicle"/>
  <xs:field xpath="@plateNumber"/>
 </xs:key>
</xs:element>

<xs:element name="root">
 <xs:complexType>
  <xs:sequence>
   . . .
   <xs:element ref="state" maxOccurs="unbounded"/>
   . . .
  </xs:sequence>
 </xs:complexType>

 <xs:key name="state"> <!-- states are keyed by their code -->
  <xs:selector xpath=".//state"/>
  <xs:field xpath="code"/>
 </xs:key>

 <xs:keyref name="vehicleState" refer="state">
  <!-- every vehicle refers to its state -->
  <xs:selector xpath=".//vehicle"/>
  <xs:field xpath="@state"/>
 </xs:keyref>

 <xs:key name="regKey"> <!-- vehicles are keyed by a pair of state and plate -->
  <xs:selector xpath=".//vehicle"/>
  <xs:field xpath="@state"/>
  <xs:field xpath="@plateNumber"/>
 </xs:key>

 <xs:keyref name="carRef" refer="regKey"> <!-- people's cars are a reference -->
  <xs:selector xpath=".//car"/>
  <xs:field xpath="@regState"/>
  <xs:field xpath="@regPlate"/>
 </xs:keyref>

</xs:element>

<xs:element name="person">
 <xs:complexType>
  <xs:sequence>
   . . .
   <xs:element name="car">
    <xs:complexType>
     <xs:attribute name="regState" type="twoLetterCode"/>
     <xs:attribute name="regPlate" type="xs:integer"/>
    </xs:complexType>
   </xs:element>
  </xs:sequence>
 </xs:complexType>
</xs:element>

A state element is defined, which contains a code child and some vehicle and person children. A vehicle in turn has a plateNumber attribute, which is an integer, and a state attribute. State's codes are a key for them within the document. Vehicle's plateNumbers are a key for them within states, and state and plateNumber is asserted to be a key for vehicle within the document as a whole. Furthermore, a person element has an empty car child, with regState and regPlate attributes, which are then asserted together to refer to vehicles via the carRef constraint. The requirement that a vehicle's state match its containing state's code is not expressed here.

For an element information item to be locally

with respect to an identity-constraint

of the following must be true:

1 The

, with the element information item as the context node, evaluates to a node-set (as defined in

).

.

2 Each node in the

is either the context node oran element node among its descendants.

3 For each node in the

all of the

, with that node as the context node, evaluate to either an empty node-set or a node-set with exactly one member, which must have a simple type.

.

4

. The appropriate

among the following must be true:

The use of

in the definition of

above means that

or

value constraints may play a part in

s.

Because the validation of

(see clause

) depends on finding appropriate entries in a element information item's

, and

are assembled strictly recursively from the node tables of descendants, only element information items within the sub-tree rooted at the element information item being

can be referenced successfully.

Although this specification defines a

contribution which would enable schema-aware processors to implement clause

above (

), processors are not required to provide it. This clause can be read as if in the absence of this infoset contribution, the value of the relevant

property must be available.

.

.

Whenever an element information item has one or more

, in the

that element information item has a property as follows:

The complexity of the above arises from the fact that

identity-constraints may be defined on domains distinct from the embedded domain of the identity-constraint they reference, or the domains may be the same but self-embedding at some depth. In either case the

for the referenced identity-constraint needs to propagate upwards, with conflict resolution.

The

information item, unlike others in this specification, is essentially an internal bookkeeping mechanism. It is introduced to support the definition of

above. Accordingly, conformant processors may, but are

required to, expose them via

properties in the

. In other words, the above constraints may be read as saying

of identity-constraints proceeds

such infoset items existed.

All identity-constraint definitions (see Identity-constraint Definitions (§3.11)) must satisfy the following constraint.

of the following must be true:

of the following must be true:

2

of the following must be true:

2.1 It must conform to the following extended BNF:

2.2 It must be an XPath expression involving the child axis whose abbreviated form is as given above.

For readability, whitespace may be used in selector XPath expressions even though not explicitly allowed by the grammar:

may be freely added within patterns before or after any

.

When tokenizing, the longest possible token is always returned.

of the following must be true:

1 Each member of the

must be a valid XPath expression, as defined in

.

2

of the following must be true:

2.1 It must conform to the extended BNF given above for

, with the following modification:

This production differs from the one above in allowing the final step to match an attribute node.

2.2 It must be an XPath expression involving the child and/or attribute axes whose abbreviated form is as given above.

For readability, whitespace may be used in field XPath expressions even though not explicitly allowed by the grammar:

may be freely added within patterns before or after any

.

When tokenizing, the longest possible token is always returned.

Notation declarations reconstruct XML 1.0 NOTATION declarations.

<xs:notation name="jpeg" public="image/jpeg" system="viewer.exe">

The XML representation of a notation declaration.

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.

See Annotations (§3.13) for information on the role of the {annotation} property.

The XML representation for a notation declaration schema component is a <notation> element information item. The correspondences between the properties of that information item and properties of the component it corresponds to are as follows:

<xs:notation name="jpeg"
             public="image/jpeg" system="viewer.exe" />

<xs:element name="picture">
 <xs:complexType>
  <xs:simpleContent>
   <xs:extension base="xs:hexBinary">
    <xs:attribute name="pictype">
     <xs:simpleType>
      <xs:restriction base="xs:NOTATION">
       <xs:enumeration value="jpeg"/>
       <xs:enumeration value="png"/>
       . . .
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
   </xs:extension>
  </xs:simpleContent>
 </xs:complexType>
</xs:element>

<picture pictype="jpeg">...</picture>

None as such.

Whenever an attribute information item is

with respect to a

, in the

its parent element information item either has a property as follows:

or has a pair of properties as follows:

Note: For compatibility, only one such attribute should appear on any given element. If more than one such attribute does appear, which one supplies the infoset property or properties above is not defined.

All notation declarations (see Notation Declarations (§3.12)) must satisfy the following constraint.

Annotations provide for human- and machine-targeted annotations of schema components.

<xs:simpleType fn:note="special">
  <xs:annotation>
   <xs:documentation>A type for experts only</xs:documentation>
   <xs:appinfo>
    <fn:specialHandling>checkForPrimes</fn:specialHandling>
   </xs:appinfo>
  </xs:annotation>
     

XML representations of three kinds of annotation.

The annotation schema component has the following properties:

{user information} is intended for human consumption, {application information} 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 {user information}, indication should be given as to the identity of the (human) language used in the contents, using the xml:lang attribute.

{attributes} ensures that when schema authors take advantage of the provision for adding attributes from namespaces other than the XML Schema namespace to schema documents, they are available within the components corresponding to the element items where such attributes appear.

Annotations do not participate in ·validation· as such. Provided an annotation itself satisfies all relevant ·Schema Component Constraints· it cannot affect the ·validation· of element information items.

Annotation of schemas and schema components, with material for human or computer consumption, is provided for by allowing application information and human information at the beginning of most major schema elements, and anywhere at the top level of schemas. The XML representation for an annotation schema component is an <annotation> element information item. The correspondences between the properties of that information item and properties of the component it corresponds to are as follows:

<annotation
  id = ID
  {any attributes with non-schema namespace . . .}>
  Content: (appinfo | documentation)*
</annotation>

<appinfo
  source = anyURI
  {any attributes with non-schema namespace . . .}>
  Content: ({any})*
</appinfo>

<documentation
  source = anyURI
  xml:lang = language
  {any attributes with non-schema namespace . . .}>
  Content: ({any})*
</documentation>

The annotation component corresponding to the <annotation> element in the example above will have one element item in each of its {user information} and {application information} and one attribute item in its {attributes}.

None as such.

All annotations (see Annotations (§3.13)) must satisfy the following constraint.

This section consists of a combination of non-normative versions of normative material from

, for local cross-reference purposes, and normative material relating to the interface between schema components defined in this specification and the simple type definition component.

Simple type definitions provide for constraining character information item [children] of element and attribute information items.

<xs:simpleType name="fahrenheitWaterTemp">
 <xs:restriction base="xs:number">
  <xs:fractionDigits value="2"/>
  <xs:minExclusive value="0.00"/>
  <xs:maxExclusive value="100.00"/>
 </xs:restriction>
</xs:simpleType>

The XML representation of a simple type definition.

The simple type definition schema component has the following properties:

Simple types are identified by their {name} and {target namespace}. Except for anonymous simple types (those with no {name}), 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 {name}s and {target namespace}s are provided for reference from instances (see xsi:type (§2.6.1)), and for use in the XML representation of schema components (specifically in <element> and <attribute>). See References to schema components across namespaces (§4.2.3) for the use of component identifiers when importing one schema into another.

A simple type definition with an empty specification for {final} can be used as the {base type definition} for other types derived by either of extension or restriction, or as the {item type definition} in the definition of a list, or in the {member type definitions} of a union; the explicit values extension, restriction, list and union prevent further derivations by extension (to yield a complex type) and restriction (to yield a simple type) and use in constructing lists and unions respectively.

{variety} determines whether the simple type corresponds to an atomic, list or union type as defined by [XML Schemas: Datatypes].

As described in Type Definition Hierarchy (§2.2.1.1), every simple type definition is a ·restriction· of some other simple type (the {base type definition}), 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 which is not itself derived by restriction from a list or union respectively. Each atomic type is ultimately a restriction of exactly one such built-in primitive datatype, which is its {primitive type definition}.

{facets} for each simple type definition are selected from those defined in [XML Schemas: Datatypes]. For atomic definitions, these are restricted to those appropriate for the corresponding {primitive type definition}. Therefore, the value space and lexical space (i.e. what is ·validated· by any atomic simple type) is determined by the pair ({primitive type definition}, {facets}).

As specified in [XML Schemas: Datatypes], list simple type definitions ·validate· space separated tokens, each of which conforms to a specified simple type definition, the {item type definition}. The item type specified must not itself be a list type, and must be one of the types identified in [XML Schemas: Datatypes] as a suitable item type for a list simple type. In this case the {facets} 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 {member type definitions}. As in the case of list, the {facets} apply to the union itself, and are restricted to those appropriate for unions.

The ·simple ur-type definition· must not be named as the ·base type definition· of any user-defined atomic simple type definitions: as it has no constraining facets, this would be incoherent.

See Annotations (§3.13) for information on the role of the {annotation} property.

<simpleType
  final = (#all | List of (list | union | restriction))
  id = ID
  name = NCName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (restriction | list | union))
</simpleType>

<restriction
  base = QName
  id = ID
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (simpleType?, (minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | length | minLength | maxLength | enumeration | whiteSpace | pattern)*))
</restriction>

<list
  id = ID
  itemType = QName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, simpleType?)
</list>

<union
  id = ID
  memberTypes = List of QName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, simpleType*)
</union>

1

the

alternative is chosen,

the type definition

to by the

of the

of

, if present, otherwise the type definition corresponding to the

among the

of

.

2

the

or

alternative is chosen,

the

.

If the

is

, the following additional property mappings also apply:

If the

is

, the following additional property mappings also apply:

If the

is

, the following additional property mappings also apply:

1

the

alternative is chosen,

the type definitions

to by the items in the

of the

, if any, followed by the type definitions corresponding to the

s among the

of

, if any. The actual value is then formed by replacing any union type definition in the

with the members of their

, in order.

2

the

option is chosen,

the

of the

.

In addition to the conditions imposed on

element information items by the schema for schemas,

of the following must be true:

4 Circular union type definition is disallowed. That is, if the

alternative is chosen, there must not be any entries in the

at any depth which resolve to the component corresponding to the

.

For a string to be locally

with respect to a simple type definition

of the following must be true:

2 The appropriate

among the following must be true:

2.3 otherwise no further condition applies.

None as such.

All simple type definitions other than the ·simple ur-type definition· and the built-in primitive datatype definitions (see Simple Type Definitions (§3.14)) must satisfy both the following constraints.

of the following must be true:

The appropriate

among the following must be true:

1

the

is

,

of the following must be true:

1.3 For each facet in the

(call this

)

of the following must be true:

2

the

is

,

of the following must be true:

2.2

2.3 The appropriate

among the following must be true:

2.3.2

of the following must be true:

2.3.2.4 Only

,

,

,

,

and

facet components are allowed among the

.

The first case above will apply when a list is derived by specifying an item type, the second when derived by restriction from another list.

3

the

is

,

of the following must be true:

3.2

3.3 The appropriate

among the following must be true:

3.3.2

of the following must be true:

3.3.2.4 Only

and

facet components are allowed among the

.

The first case above will apply when a union is derived by specifying one or more member types, the second when derived by restriction from another union.

.

The following constraint defines relations appealed to elsewhere in this specification.

For a simple type definition (call it

, for derived) to be validly derived from a type definition (call this

, for base) given a subset of {

,

,

,

} (of which only

is actually relevant)

of the following must be true:

1

They are the same type definition.

2

of the following must be true:

2.2

of the following must be true:

With respect to clause

, see the Note on identity at the end of

above.

For a simple type definition (call it

) to restrict another simple type definition (call it

) with a set of facets (call this

)

of the following must be true:

1 The

of

is the same as that of

.

3

The

of

are the union of

and the

of

, eliminating duplicates. To eliminate duplicates, when a facet of the same kind occurs in both

and the

of

, the one in the

of

is not included, with the exception of

and

facets, for which multiple occurrences with distinct values are allowed.

Additional constraint(s) may apply depending on the kind of facet, see the appropriate sub-section of

.

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

The ·simple ur-type definition· is the root of the simple type definition hierarchy, and as such mediates between the other simple type definitions, which all eventually trace back to it via their {base type definition} properties, and the ·ur-type definition·, which is its {base type definition}. This is why the ·simple ur-type definition· is exempted from the first clause of Simple Type Definition Properties Correct (§3.14.6), which would otherwise bar it because of its derivation from a complex type definition and absence of {variety}.

Simple type definitions for all the built-in primitive datatypes, namely string, boolean, float, double, number, dateTime, duration, time, date, gMonth, gMonthDay, gDay, gYear, gYearMonth, hexBinary, base64Binary, anyURI (see the Primitive Datatypes section of [XML Schemas: Datatypes]) are present by definition in every schema. All are in the XML Schema {target namespace} (namespace name http://www.w3.org/2001/XMLSchema), have an atomic {variety} with an empty {facets} and the ·simple ur-type definition· as their ·base type definition· and themselves as {primitive type definition}.

Similarly, simple type definitions for all the built-in derived datatypes (see the Derived Datatypes section of [XML Schemas: Datatypes]) are present by definition in every schema, with properties as specified in [XML Schemas: Datatypes] and as represented in XML in Schema for Schemas (normative) (§A).

A schema consists of a set of schema components.

<xs:schema
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.example.com/example">
  . . .
</xs:schema>

The XML representation of the skeleton of a schema.

At the abstract level, the schema itself is just a container for its components.

A schema is represented in XML by one or more ·schema documents·, that is, one or more <schema> element information items. 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 <import> element information items corresponds to a schema with components with more than one {target namespace}, see Import Constraints and Semantics (§4.2.3).

<schema
  attributeFormDefault = (qualified | unqualified) : unqualified
  blockDefault = (#all | List of (extension | restriction | substitution))  : ''
  elementFormDefault = (qualified | unqualified) : unqualified
  finalDefault = (#all | List of (extension | restriction | list | union))  : ''
  id = ID
  targetNamespace = anyURI
  version = token
  xml:lang = language
  {any attributes with non-schema namespace . . .}>
  Content: ((include | import | redefine | annotation)*, (((simpleType | complexType | group | attributeGroup) | element | attribute | notation), annotation*)*)
</schema>

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 above, 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 XML Schema Abstract Data Model (§2.2) makes clear that most components have a {target namespace}. Most components corresponding to representations within a given <schema> element information item will have a {target namespace} which corresponds to the targetNamespace attribute.

Since the empty string is not a legal namespace name, supplying an empty string for targetNamespace is incoherent, and is not the same as not specifying it at all. The appropriate form of schema document corresponding to a ·schema· whose components have no {target namespace} is one which has no targetNamespace attribute specified at all.

Note: The XML namespaces Recommendation discusses only instance document syntax for elements and attributes; it therefore provides no direct framework for managing the names of type definitions, attribute group definitions, and so on. Nevertheless, the specification applies the target namespace facility uniformly to all schema components, i.e. not only declarations but also definitions have a {target namespace}.

Although the example schema at the beginning of this section might be a complete XML document, <schema> 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 <include> and <import>, which do not correspond directly to any schema component at all, each of the element information items which may appear in the content of <schema> corresponds to a schema component, and all except <annotation> are named. The sections below 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 (References to schema components across namespaces (§4.2.3)) from an external schema (which may, but need not, correspond to an actual schema document). The form of all such references is a ·QName·.

[Definition:]  A QName is a name with an optional namespace qualification, as defined in [XML-Namespaces]. When used in connection with the XML representation of schema components or references to them, this refers to the simple type QName as defined in [XML Schemas: Datatypes].

[Definition:]  An NCName is a name with no colon, as defined in [XML-Namespaces]. When used in connection with the XML representation of schema components in this specification, this refers to the simple type NCName as defined in [XML Schemas: Datatypes].

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.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
            xmlns:xhtml="http://www.w3.org/1999/xhtml"
            xmlns="http://www.example.com"
            targetNamespace="http://www.example.com">
  . . .

  <xs:element name="elem1" type="Address"/>

  <xs:element name="elem2" type="xhtml:blockquote"/>

  <xs:attribute name="attr1"
                type="xsl:quantity"/>
  . . .
</xs:schema>

The first of these is most probably a local reference, i.e. a reference to a type definition corresponding to a

element information item located elsewhere in the schema document, the other two refer to type definitions from schemas for other namespaces and assume that their namespaces have been declared for import. See

for a discussion of importing.

The names of schema components such as type definitions and element declarations are not of type ID: they are not unique within a schema, just within a symbol space. This means that simple fragment identifiers will not always work to reference schema components from outside the context of schema documents.

There is currently no provision in the definition of the interpretation of fragment identifiers for the text/xml MIME type, which is the MIME type for schemas, for referencing schema components as such. However, [XPointer] provides a mechanism which maps well onto the notion of symbol spaces as it is reflected in the XML representation of schema components. A fragment identifier of the form #xpointer(xs:schema/xs:element[@name="person"]) will uniquely identify the representation of a top-level element declaration with name person, and similar fragment identifiers can obviously be constructed for the other global symbol spaces.

Short-form fragment identifiers may also be used in some cases, that is when a DTD or XML Schema is available for the schema in question, and the provision of an id attribute for the representations of all primary and secondary schema components, which is of type ID, has been exploited.

It is a matter for applications to specify whether they interpret document-level references of either of the above varieties as being to the relevant element information item (i.e. without special recognition of the relation of schema documents to schema components) or as being to the corresponding schema component.

[Definition:]  Whenever the word resolve in any form is used in this chapter in connection with a ·QName· in a schema document, the following definition QName resolution (Schema Document) (§3.15.3) should be understood:

For a

to resolve to a schema component of a specified kind

of the following must be true:

1 That component is a member of the value of the appropriate property of the schema which corresponds to the schema document within which the

appears, that is the appropriate

among the following must be true:

1.1

the kind specified is simple or complex type definition,

the property is the

.

4 The appropriate

among the following must be true:

As the discussion above at Schema Component Details (§3) makes clear, at the level of schema components and ·validation·, reference to components by name is normally not involved. In a few cases, however, qualified names appearing in information items being ·validated· must be resolved to schema components by such lookup. The following constraint is appealed to in these cases.

A pair of a local name and a namespace name (or

) resolve to a schema component of a specified kind in the context of

by appeal to the appropriate property of the schema being used for the

. Each such property indexes components by name. The property to use is determined by the kind of component specified, that is, the appropriate

among the following must be true:

1

the kind specified is simple or complex type definition,

the property is the

.

The component resolved to is the entry in the table whose

matches the local name of the pair and whose

is identical to the namespace name of the pair.

Schema components provide a wealth of information about the basis of

, which may well be of relevance to subsequent processing. Reflecting component structure into a form suitable for inclusion in the

is the way this specification provides for making this information available.

Accordingly,

.

Processors must add a property in the

to the element information item at which

began, as follows:

[schema information]

A set of namespace schema information information items, one for each namespace name which appears as the {target namespace} of any schema component in the schema used for that assessment, and one for ·absent· if any schema component in the schema had no {target namespace}. Each namespace schema information information item has the following properties and values:

The

property is provided for processors which wish to provide a single access point to the components of the schema which was used during

. Lightweight processors are free to leave it empty, but if it

provided, it must contain at a minimum all the top-level (i.e. named) components which actually figured in the

, either directly or (because an anonymous component which figured is contained within) indirectly.

In the

a set of

information items is associated with the

element information item:

[ID/IDREF table]

A (possibly empty) set of ID/IDREF binding information items, as specified below.

for which

of the following are true

Then there is one

in the

for every distinct string which is

of the following:

Each

has properties as follows:

[id]

The string identified above.

[binding]

A set consisting of every element information item for which all of the following are true

2 it has an attribute information item in its

[attributes]

or an element information item in its

[children]

which was

·validated·

by the built-in

ID

simple type definition or a type derived from it whose

[schema normalized value]

is the

[id]

of this

ID/IDREF binding

.

The net effect of the above is to have one entry for every string used as an id, whether by declaration or by reference, associated with those elements, if any, which actually purport to have that id. See

above for the validation rule which actually checks for errors here.

The

information item, unlike most other aspects of this specification, is essentially an internal bookkeeping mechanism. It is introduced to support the definition of

above. Accordingly, conformant processors may, but are

required to, expose it in the

. In other words, the above constraint may be read as saying

proceeds

such an infoset item existed.

All schemas (see Schemas as a Whole (§3.15)) must satisfy the following constraint.

of the following must be true:

This chapter defines the mechanisms by which this specification establishes the necessary precondition for ·assessment·, namely access to one or more schemas. This chapter also sets out in detail the relationship between schemas and namespaces, as well as mechanisms for modularization of schemas, including provision for incorporating definitions and declarations from one schema in another, possibly with modifications.

Conformance (§2.4) describes three levels of conformance for schema processors, and Schemas and Schema-validity Assessment (§5) provides a formal definition of ·assessment·. This section sets out in detail the 3-layer architecture implied by the three conformance levels. The layers are:

1. The ·assessment· core, relating schema components and instance information items;
2. Schema representation: the connections between XML representations and schema components, including the relationships between namespaces and schema components;
3. XML Schema web-interoperability guidelines: instance->schema and schema->schema connections for the WWW.

Layer 1 specifies the manner in which a schema composed of schema components can be applied to in the ·assessment· of an instance element information item. Layer 2 specifies the use of <schema> elements in XML documents as the standard XML representation for schema information in a broad range of computer systems and execution environments. To support interoperation over the World Wide Web in particular, layer 3 provides a set of conventions for schema reference on the Web. Additional details on each of the three layers is provided in the sections below.

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 processor succeed in locating the ·schema components· transitively required to complete an ·assessment· (note that components derived from ·schema documents· can be integrated with components obtained through other means);
• no definition or declaration changes once it has been established;
• if the processor chooses to acquire declarations and definitions dynamically, that there be no side effects of such dynamic acquisition that would cause the results of ·assessment· to differ from that which would have been obtained from the same schema components acquired in bulk.

the

core is defined in terms of schema components at the abstract level, and no mention is made of the schema definition syntax (i.e.

). Although many processors will acquire schemas in this format, others may operate on compiled representations, on a programmatic representation as exposed in some programming language, etc.

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 Assessing Schema-Validity (§5.2). 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.

The sub-sections of Schema Component Details (§3) define 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.

The core

architecture requires that a complete schema with all the necessary declarations and definitions be available. This may involve resolving both instance->schema and schema->schema references. As observed earlier in

, the precise mechanisms for resolving such references are expected to evolve over time. In support of such evolution, this specification observes the design principle that references from one schema document to a schema use mechanisms that directly parallel those used to reference a schema from an instance document.

Note: In the sections below, "schemaLocation" really belongs at layer 3. For convenience, it is documented with the layer 2 mechanisms of import and include, with which it is closely associated.

Schema components for a single target namespace can be assembled from several ·schema documents·, that is several <schema> element information items:

A <schema> information item may contain any number of <include> elements. Their schemaLocation attributes, consisting of a URI reference, identify other ·schema documents·, that is <schema> information items.

The ·XML Schema· corresponding to <schema> contains not only the components corresponding to its definition and declaration [children], but also all the components of all the ·XML Schemas· corresponding to any <include>d schema documents. Such included schema documents must either (a) have the same targetNamespace as the <include>ing schema document, or (b) no targetNamespace at all, in which case the <include>d schema document is converted to the <include>ing schema document's targetNamespace.

In addition to the conditions imposed on

element information items by the schema for schemas,

of the following must be true:

1

If the

of the

successfully resolves

of the following must be true:

1.1

It resolves to (a fragment of) a resource which is an XML document (of type

or

with an XML declaration for preference, but this is not required), which in turn corresponds to a

element information item in a well-formed information set, which in turn corresponds to a valid schema.

1.2 It resolves to a

element information item in a well-formed information set, which in turn corresponds to a valid schema.

In either case call the

d

item

, the valid schema

and the

ing item's parent

item

.

2

of the following must be true:

2.2

Neither

nor

have a

.

2.3

has no

(but

does).

3 The appropriate

among the following must be true:

3.1

clause

or clause

above is satisfied,

the schema corresponding to

must include not only definitions or declarations corresponding to the appropriate members of its own

, but also components identical to all the

of

.

3.2

clause

above is satisfied,

the schema corresponding to the

d item's parent

must include not only definitions or declarations corresponding to the appropriate members of its own

, but also components identical to all the

of

, except that anywhere the

target namespace name would have appeared, the

of the

of

is used. In particular, it replaces

in the following places:

3.2.1 The {target namespace} of named schema components, both at the top level and (in the case of nested type definitions and nested attribute and element declarations whose code was qualified) nested within definitions;

It is

an error for the

of the

to fail to resolve it all, in which case no corresponding inclusion is performed. It

an error for it to resolve but the rest of clause 1 above to fail to be satisfied. Failure to resolve may well cause less than complete

outcomes, of course.

As discussed in

,

s in XML representations may fail to

, rendering components incomplete and unusable because of missing subcomponents. During schema construction, implementations must retain

values for such references, in case an appropriately-named component becomes available to discharge the reference by the time it is actually needed.

target

s of such as-yet unresolved reference

s in

d components must also be converted if clause

is satisfied.

The above is carefully worded so that multiple

ing of the same schema document will not constitute a violation of clause

of

, but applications are allowed, indeed encouraged, to avoid

ing the same schema document more than once to forestall the necessity of establishing identity component by component.

In order to provide some support for evolution and versioning, it is possible to incorporate components corresponding to a schema document with modifications. The modifications have a pervasive impact, that is, only the redefined components are used, even when referenced from other incorporated components, whether redefined themselves or not.

A <schema> information item may contain any number of <redefine> elements. Their schemaLocation attributes, consisting of a URI reference, identify other ·schema documents·, that is <schema> information items.

The ·XML Schema· corresponding to <schema> contains not only the components corresponding to its definition and declaration [children], but also all the components of all the ·XML Schemas· corresponding to any <redefine>d schema documents. Such schema documents must either (a) have the same targetNamespace as the <redefine>ing schema document, or (b) no targetNamespace at all, in which case the <redefine>d schema document is converted to the <redefine>ing schema document's targetNamespace.

The definitions within the <redefine> element itself are restricted to be redefinitions of components from the <redefine>d schema document, in terms of themselves. That is,

• Type definitions must use themselves as their base type definition;
• Attribute group definitions and model group definitions must be supersets or subsets of their original definitions, either by including exactly one reference to themselves or by containing only (possibly restricted) components which appear in a corresponding way in their <redefine>d selves.

Not all the components of the <redefine>d schema document need be redefined.

This mechanism is intended to provide a declarative and modular approach to schema modification, with functionality no different except in scope from what would be achieved by wholesale text copying and redefinition by editing. In particular redefining a type is not guaranteed to be side-effect free: it may have unexpected impacts on other type definitions which are based on the redefined one, even to the extent that some such definitions become ill-formed.

Note: The pervasive impact of redefinition reinforces the need for implementations to adopt some form of lazy or 'just-in-time' approach to component construction, which is also called for in order to avoid inappropriate dependencies on the order in which definitions and references appear in (collections of) schema documents.

v1.xsd:
 <xs:complexType name="personName">
  <xs:sequence>
   <xs:element name="title" minOccurs="0"/>
   <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
 </xs:complexType>

 <xs:element name="addressee" type="personName"/>

v2.xsd:
 <xs:redefine schemaLocation="v1.xsd">
  <xs:complexType name="personName">
   <xs:complexContent>
    <xs:extension base="personName">
     <xs:sequence>
      <xs:element name="generation" minOccurs="0"/>
     </xs:sequence>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:redefine>

 <xs:element name="author" type="personName"/>
  

The schema corresponding to v2.xsd has everything specified by v1.xsd, with the personName type redefined, as well as everything it specifies itself. According to this schema, elements constrained by the personName type may end with a generation element. This includes not only the author element, but also the addressee element.

In addition to the conditions imposed on

element information items by the schema for schemas

of the following must be true:

2 If the

of the

successfully resolves

of the following must be true:

2.1 it resolves to (a fragment of) a resource which is an XML document (see clause

), which in turn corresponds to a

element information item in a well-formed information set, which in turn corresponds to a valid schema.

2.2 It resolves to a

element information item in a well-formed information set, which in turn corresponds to a valid schema.

In either case call the

d

item

, the valid schema

and the

ing item's parent

item

.

3

of the following must be true:

3.2

Neither

nor

have a

.

3.3

has no

(but

does).

4 The appropriate

among the following must be true:

6 Within the

, for each

the appropriate

among the following must be true:

6.1

it has a

among its contents at some level the

of whose

is the same as the

of its own

attribute plus target namespace,

of the following must be true:

6.1.1 It must have exactly one such group.

6.2

it has no such self-reference,

of the following must be true:

6.2.1 The

of its own

attribute plus target namespace must successfully

to a model group definition in

.

7 Within the

, for each

the appropriate

among the following must be true:

7.2

it has no such self-reference,

of the following must be true:

7.2.1 The

of its own

attribute plus target namespace must successfully

to an attribute group definition in

.

Corresponding to each non-

member of the

of a

there are one or two schema components in the

ing schema:

1 The

and

information items each correspond to two components:

1.2 One component which corresponds to the information item itself, as defined in

, except that its

is the component defined in 1.1 above.

This pairing ensures the coherence constraints on type definitions are respected, while at the same time achieving the desired effect, namely that references to names of redefined components in both the

ing and

d schema documents resolve to the redefined component as specified in 1.2 above.

In all cases there must be a top-level definition item of the appropriate name and kind in the

d schema document.

The above is carefully worded so that multiple equivalent

ing of the same schema document will not constitute a violation of clause

of

, but applications are allowed, indeed encouraged, to avoid

ing the same schema document in the same way more than once to forestall the necessity of establishing identity component by component (although this will have to be done for the individual redefinitions themselves).

As described in XML Schema Abstract Data Model (§2.2), every top-level schema component is associated with a target namespace (or, explicitly, with none). This section sets out the exact mechanism and syntax in the XML form of schema definition by which a reference to a foreign component is made, that is, a component with a different target namespace from that of the referring component.

Two things are required: not only a means of addressing such foreign components but also a signal to schema-aware processors that a schema document contains such references:

The <import> element information item identifies namespaces used in external references, i.e. those whose ·QName· identifies them as coming from a different namespace (or none) than the enclosing schema document's targetNamespace. The ·actual value· of its namespace [attribute] indicates that the containing schema document may contain qualified references to schema components in that namespace (via one or more prefixes declared with namespace declarations in the normal way). If that attribute is absent, then the import allows unqualified reference to components with no target namespace. Note that components to be imported need not be in the form of a ·schema document·; the processor is free to access or construct components using means of its own choosing.

The ·actual value· of the schemaLocation, if present, gives a hint as to where a serialization of a ·schema document· with declarations and definitions for that namespace (or none) may be found. When no schemaLocation [attribute] is present, the schema author is leaving the identification of that schema to the instance, application or user, via the mechanisms described below in Layer 3: Schema Document Access and Web-interoperability (§4.3). When a schemaLocation is present, it must contain a single URI reference which the schema author warrants will resolve to a serialization of a ·schema document· containing the component(s) in the <import>ed namespace referred to elsewhere in the containing schema document.

Since both the

and

are optional, a bare

information item is allowed. This simply allows unqualified reference to foreign components with no target namespace without giving any hints as to where to find them.

The same namespace may be used both for real work, and in the course of defining schema components in terms of foreign components:

<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:html="http://www.w3.org/1999/xhtml"
        targetNamespace="uri:mywork" xmlns:my="uri:mywork">

 <import namespace="http://www.w3.org/1999/xhtml"/>

 <annotation>
  <documentation>
   <html:p>[Some documentation for my schema]</html:p>
  </documentation>
 </annotation>

 . . .

 <complexType name="myType">
  <sequence>
   <element ref="html:p" minOccurs="0"/>
  </sequence>
  . . .
 </complexType>

 <element name="myElt" type="my:myType"/>
</schema>

The treatment of references as

implies that since (with the exception of the schema for schemas) the target namespace and the XML Schema namespace differ, without massive redeclaration of the default namespace

internal references to the names being defined in a schema document

the schema declaration and definition elements themselves must be explicitly qualified. This example takes the first option -- most other examples in this specification have taken the second.

In addition to the conditions imposed on

element information items by the schema for schemas

of the following must be true:

1 The appropriate

among the following must be true:

2

If the application schema reference strategy using the

s of the

and

, provides a referent, as defined by

,

of the following must be true:

2.1 The referent is (a fragment of) a resource which is an XML document (see clause

), which in turn corresponds to a

element information item in a well-formed information set, which in turn corresponds to a valid schema.

2.2 The referent is a

element information item in a well-formed information set, which in turn corresponds to a valid schema.

In either case call the

item

and the valid schema

.

3 The appropriate

among the following must be true:

It is

an error for the application schema reference strategy to fail. It

an error for it to resolve but the rest of clause

above to fail to be satisfied. Failure to find a referent may well cause less than complete

outcomes, of course.

The

(that is

,

,

,

,

,

) of a schema corresponding to a

element information item with one or more

element information items must include not only definitions or declarations corresponding to the appropriate members of its

, but also, for each of those

element information items for which clause

above is satisfied, a set of

identical to all the

of

.

The above is carefully worded so that multiple

ing of the same schema document will not constitute a violation of clause

of

, but applications are allowed, indeed encouraged, to avoid

ing the same schema document more than once to forestall the necessity of establishing identity component by component. Given that the

is only a hint, it is open to applications to ignore all but the first

for a given namespace, regardless of the

of

, but such a strategy risks missing useful information when new

s are offered.

Layers 1 and 2 provide a framework for ·assessment· and XML definition of schemas in a broad variety of environments. Over time, a range of standards and conventions may well 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.

For interoperability, serialized ·schema documents·, like all other Web resources, may be identified by URI and retrieved using the standard mechanisms of the Web (e.g. http, https, etc.) Such documents on the Web must be part of XML documents (see clause 1.1), and are represented in the standard XML schema definition form described by layer 2 (that is as <schema> element information items).

there will often be times when a schema document will be a complete XML 1.0 document whose document element is

. There will be other occasions in which

items will be contained in other documents, perhaps referenced using fragment and/or XPointer notation.

The variations among server software and web site administration policies make it difficult to recommend any particular approach to retrieval requests intended to retrieve serialized

. An

header of

is perhaps a reasonable starting point.

As described in Layer 1: Summary of the Schema-validity Assessment Core (§4.1), processors are responsible for providing the schema components (definitions and declarations) needed for ·assessment·. This section introduces a set of normative conventions to facilitate interoperability for instance and schema documents retrieved and processed from the Web.

Processors on the Web are free to undertake ·assessment· against arbitrary schemas in any of the ways set out in Assessing Schema-Validity (§5.2). However, it is useful to have a common convention for determining the schema to use. Accordingly, general-purpose schema-aware processors (i.e. those not specialized to one or a fixed set of pre-determined schemas) undertaking ·assessment· of a document on the web must behave as follows:

• unless directed otherwise by the user, ·assessment· is undertaken on the document element information item of the specified document;
• unless directed otherwise by the user, the processor is required to construct a schema corresponding to a schema document whose targetNamespace is identical to the namespace name, if any, of the element information item on which ·assessment· is undertaken.

The composition of the complete schema for use in ·assessment· is discussed in Layer 2: Schema Documents, Namespaces and Composition (§4.2) above. The means used to locate appropriate schema document(s) are processor and application dependent, subject to the following requirements:

1. Schemas are represented on the Web in the form specified above in Standards for representation of schemas and retrieval of schema documents on the Web (§4.3.1);
2. The author of a document uses namespace declarations to indicate the intended interpretation of names appearing therein; there may or may not be a schema retrievable via the namespace name. Accordingly whether a processor's default behavior is or is not to attempt such dereferencing, it must always provide for user-directed overriding of that default.

   Note:  Experience suggests that it is not in all cases safe or desirable from a performance point of view to dereference namespace names as a matter of course. User community and/or consumer/provider agreements may establish circumstances in which such dereference is a sensible default strategy: this specification allows but does not require particular communities to establish and implement such conventions. Users are always free to supply namespace names as schema location information when dereferencing is desired: see below.

3. On the other hand, in case a document author (human or not) created a document with a particular schema in view, and warrants that some or all of the document conforms to that schema, the schemaLocation and noNamespaceSchemaLocation [attributes] (in the XML Schema instance namespace, that is, http://www.w3.org/2001/XMLSchema-instance) (hereafter xsi:schemaLocation and xsi:noNamespaceSchemaLocation) are provided. The first records the author's warrant with pairs of URI references (one for the namespace name, and one for a hint as to the location of a schema document defining names for that namespace name). The second similarly provides a URI reference as a hint as to the location of a schema document with no targetNamespace [attribute].Unless directed otherwise, for example by the invoking application or by command line option, processors should attempt to dereference each schema document location URI in the ·actual value· of such xsi:schemaLocation and xsi:noNamespaceSchemaLocation [attributes], see details below.
4. xsi:schemaLocation and xsi:noNamespaceSchemaLocation [attributes] can occur on any element. However, it is an error if such an attribute occurs after the first appearance of an element or attribute information item within an element information item initially ·validated· whose [namespace name] it addresses. According to the rules of Layer 1: Summary of the Schema-validity Assessment Core (§4.1), the corresponding schema may be lazily assembled, but is otherwise stable throughout ·assessment·. Although schema location attributes can occur on any element, and can be processed incrementally as discovered, their effect is essentially global to the ·assessment·. Definitions and declarations remain in effect beyond the scope of the element on which the binding is declared.

Multiple schema bindings can be declared using a single attribute. For example consider a stylesheet:

 <stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
            xmlns:html="http://www.w3.org/1999/xhtml"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://www.w3.org/1999/XSL/Transform
                                http://www.w3.org/1999/XSL/Transform.xsd
                                http://www.w3.org/1999/xhtml
                                http://www.w3.org/1999/xhtml.xsd">

The namespace names used in schemaLocation can, but need not be identical to those actually qualifying the element within whose start tag it is found or its other attributes. For example, as above, all schema location information can be declared on the document element of a document, if desired, regardless of where the namespaces are actually used.

Given a namespace name (or none) and (optionally) a URI reference from

or

, schema-aware processors may implement any combination of the following strategies, in any order:

1 Do nothing, for instance because a schema containing components for the given namespace name is already known to be available, or because it is known in advance that no efforts to locate schema documents will be successful (for example in embedded systems);

2 Based on the location URI, identify an existing schema document, either as a resource which is an XML document or a

element information item, in some local schema repository;

3 Based on the namespace name, identify an existing schema document, either as a resource which is an XML document or a

element information item, in some local schema repository;

4 Attempt to resolve the location URI, to locate a resource on the web which is or contains or references a

element;

5 Attempt to resolve the namespace name to locate such a resource.

Whenever possible configuration and/or invocation options for selecting and/or ordering the implemented strategies should be provided.

Improved or alternative conventions for Web interoperability can be standardized in the future without reopening this specification. For example, the W3C is currently considering initiatives to standardize the packaging of resources relating to particular documents and/or namespaces: this would be an addition to the mechanisms described here for layer 3. This architecture also facilitates innovation at layer 2: for example, it would be possible in the future to define an additional standard for the representation of schema components which allowed e.g. type definitions to be specified piece by piece, rather than all at once.

The architecture of schema-aware processing allows for a rich characterization of XML documents: schema validity is not a binary predicate.

This specification distinguishes between errors in schema construction and structure, on the one hand, and schema validation outcomes, on the other.

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 Schema Document Location Strategy (§4.3.2), starting with the namespaces declared in the document whose ·assessment· is being undertaken, and the ·actual value·s of the xsi:schemaLocation and xsi:noNamespaceSchemaLocation [attributes] thereof, if any, along with any 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 the last section of each of the subsections of Schema Component Details (§3).

If a schema is derived from one or more schema documents (that is, one or more <schema> element information items) based on the correspondence rules set out in Schema Component Details (§3) and Schemas and Namespaces: Access and Composition (§4), 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 Schema for Schemas (normative) (§A), that is, following schema-validation with such a schema, the <schema> element information items would have a [validation attempted] property with value full or partial and a [validity] property with value valid.
• It is an error if any such schema document is or contains any element information items which violate any of the relevant Schema Representation Constraints set out in Schema Representation Constraints (§C.3).

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 Errors in Schema Construction and Structure (§5.1) above, the schema-validity of an element information item can be assessed. Three primary approaches to this are possible:

3 The processor starts from

with no stipulated declaration or definition, and either

or

assessment ensues, depending on whether or not the element information and the schema determine either an element declaration (by name) or a type definition (via

) or not.

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 [attributes] and [children], recursively, as defined by Assessment Outcome (Element) (§3.3.5) and Assessment Outcome (Attribute) (§3.2.5). 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. [Definition:]  This item, that is the element information item at which ·assessment· began, is called the validation root.

This specification does not reconstruct the XML 1.0 notion of

in either schemas or instances. Equivalent functionality is provided for at

invocation, via clause

above.

This specification has nothing normative to say about multiple

episodes. It should however be clear from the above that if a processor restarts

with respect to a

some

contributions from the previous

may be overwritten. Restarting nonetheless may be useful, particularly at a node whose

property is

, in which case there are three obvious cases in which additional useful information may result:

• ·assessment· was not attempted because of a ·validation· failure, but declarations and/or definitions are available for at least some of the [children] or [attributes];
• ·assessment· was not attempted because a named definition or declaration was missing, but after further effort the processor has retrieved it.
• ·assessment· was not attempted because it was skipped, but the processor has at least some declarations and/or definitions available for at least some of the [children] or [attributes].

At the beginning of Schema Component Details (§3), 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 of Attribute Locally Valid (§3.2.4) had failed;
• In the case of element information items, the effect is as if clause 1 of Element Locally Valid (Element) (§3.3.4) had failed;
• In the case of element information items, processors may choose to continue ·assessment·: see ·lax assessment·.

Because of the value specification for [validation attempted] in Assessment Outcome (Element) (§3.3.5), 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 Conformance (§2.4)) they support, consistently with the conditions set out above.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3