W3C

W3C XML Schema Definition Language (XSDL) 1.1 Part 1: Structures

W3C Working Draft 30 August 2007

This version:
http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/
Latest version:
http://www.w3.org/TR/xmlschema11-1/
Previous versions:
http://www.w3.org/TR/2006/WD-xmlschema11-1-20060831/ http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/ http://www.w3.org/TR/2005/WD-xmlschema11-1-20050224/ http://www.w3.org/TR/2004/WD-xmlschema11-1-20040716/
Editors:
Version 1.1:
Shudi (Sandy) Gao 高殊镝, IBM <sandygao@ca.ibm.com>
C. M. Sperberg-McQueen, World Wide Web Consortium <cmsmcq@w3.org>
Henry S. Thompson, University of Edinburgh <ht@inf.ed.ac.uk>
Version 1.0:
Henry S. Thompson, University of Edinburgh <ht@inf.ed.ac.uk>
Noah Mendelsohn, IBM <noah_mendelsohn@us.ibm.com>
David Beech, Oracle Corporation (retired) <davidbeech@earthlink.net>
Murray Maloney, Muzmo Communications <murray@muzmo.com>

This document is also available in these non-normative formats: XML, XHTML with changes since version 1.0 marked, XHTML with changes since previous Working Draft marked, Independent copy of the schema for schema documents, Independent copy of the DTD for schema documents, Independent tabulation of components and microcomponents, and List of translations.


Abstract

This document specifies the XML Schema Definition Language, which offers facilities for describing the structure and constraining the contents of XML documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in an XML vocabulary and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML document type definitions (DTDs). This specification depends on XML Schema Definition Language 1.1 Part 2: Datatypes.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a Last Call Public Working Draft of W3C XML Schema Definition Language (XSDL) 1.1. It is here made available for review by W3C members and the public. XSDL 1.1 retains all the essential features of XSDL 1.0, but adds several new features to support functionality requested by users, fixes some errors in XSDL 1.0, and clarifies some wording.

This draft was published on 30 August 2007. The major revisions since the previous draft include:

For those primarily interested in the changes since version 1.0, the appendix Changes since version 1.0 (§G) is the recommended starting point. It summarizes both changes made since XSDL 1.0 and some changes which were expected (and predicted in earlier drafts of this specification) but have not been made after all. Accompanying versions of this document display in color all changes to normative text since version 1.0 and since the previous Working Draft.

The Last Call review period for this document extends until 8 November 2007. Comments on this document should be made in W3C's public installation of Bugzilla, specifying "XML Schema" as the product. Instructions can be found at http://www.w3.org/XML/2006/01/public-bugzilla. If access to Bugzilla is not feasible, please send your comments to the W3C XML Schema comments mailing list, www-xml-schema-comments@w3.org (archive) Each Bugzilla entry and email message should contain only one comment.

Although feedback based on any aspect of this specification is welcome, there are certain aspects of the design presented herein for which the Working Group is particularly interested in feedback. These are designated "priority feedback" aspects of the design, and identified as such in editorial notes at appropriate points in this draft. Any feature mentioned in a priority feedback note should be considered a "feature at risk": the feature may be retained as is, modified, or dropped, depending on the feedback received from readers, schema authors, schema users, and implementors.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document has been produced by the W3C XML Schema Working Group as part of the W3C XML Activity. The goals of XSDL 1.1 are discussed in the document Requirements for XML Schema 1.1. The authors of this document are the members of the XML Schema Working Group. Different parts of this specification have different editors.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

The English version of this specification is the only normative version. Information about translations of this document is available at http://www.w3.org/2003/03/Translations/byTechnology?technology=xmlschema.

Table of Contents

1 Introduction
    1.1 Introduction to Version 1.1
    1.2 Purpose
    1.3 Namespaces and Language Identifiers
    1.4 Dependencies on Other Specifications
    1.5 Documentation Conventions and Terminology
2 Conceptual Framework
    2.1 Overview of XSDL
    2.2 XSDL Abstract Data Model
    2.3 Constraints and Validation Rules
    2.4 Conformance
    2.5 Names and Symbol Spaces
    2.6 Schema-Related Markup in Documents Being Validated
    2.7 Representation of Schemas on the World Wide Web
3 Schema Component Details
    3.1 Introduction
    3.2 Attribute Declarations
    3.3 Element Declarations
    3.4 Complex Type Definitions
    3.5 Attribute Uses
    3.6 Attribute Group Definitions
    3.7 Model Group Definitions
    3.8 Model Groups
    3.9 Particles
    3.10 Wildcards
    3.11 Identity-constraint Definitions
    3.12 Type Alternatives
    3.13 Assertions
    3.14 Notation Declarations
    3.15 Annotations
    3.16 Simple Type Definitions
    3.17 Schemas as a Whole
4 Schemas and Namespaces: Access and Composition
    4.1 Layer 1: Summary of the Schema-validity Assessment Core
    4.2 Layer 2: Schema Documents, Namespaces and Composition
    4.3 Layer 3: Schema Document Access and Web-interoperability
5 Schemas and Schema-validity Assessment
    5.1 Errors in Schema Construction and Structure
    5.2 Assessing Schema-Validity
    5.3 Missing Sub-components
    5.4 Responsibilities of Schema-aware Processors

Appendices

A Schema for Schema Documents (Structures) (normative)
B References (normative)
C Outcome Tabulations (normative)
    C.1 Validation Rules
    C.2 Contributions to the post-schema-validation infoset
    C.3 Schema Representation Constraints
    C.4 Schema Component Constraints
D Terminology for implementation-defined features
    D.1 Subset of the Post-schema-validation Infoset
    D.2 Terminology of schema construction
E Required Information Set Items and Properties (normative)
F Checklists of implementation-defined and implementation-dependent features
    F.1 Checklist of implementation-defined features
    F.2 Checklist of implementation-dependent features
G Changes since version 1.0
    G.1 Changes made since version 1.0
    G.2 Issues not resolved
H Checking content-type restriction
I Schema Components Diagram (non-normative)
J Glossary (non-normative)
K DTD for Schemas (non-normative)
L Analysis of the Unique Particle Attribution Constraint (non-normative)
M References (non-normative)
N XSDL Language Identifiers (non-normative)
O Acknowledgements (non-normative)

1 Introduction

This document sets out the structural part of the XML Schema Definition Language.

Chapter 2 presents a Conceptual Framework (§2) for XSDL, including an introduction to the nature of XSDL schemas and an introduction to the XSDL 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 an XSDL schema for an XSDL 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 Schema Documents (Structures) (normative) (§A) for the XML representation of schemas and References (normative) (§B).

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

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.

next sub-section1.1 Introduction to Version 1.1

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

  • Significant improvements in simplicity of design and clarity of exposition without loss of backward or forward compatibility;
  • Provision of support for versioning of XML languages defined using this specification, including the XML transfer syntax for schemas itself.
  • Provision of support for co-occurrence constraints, that is constraints which make the presence of an attribute or element, or the values allowable for it, depend on the value or presence of other attributes or elements.

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

  1. Support for versioning (acknowledging that this may be slightly disruptive to the XML transfer syntax at the margins)
  2. Support for co-occurrence constraints (which will certainly involve additions to the XML transfer syntax, which will not be understood by 1.0 processors)
  3. Bug fixes (unless in specific cases we decide that the fix is too disruptive for a point release)
  4. Editorial changes
  5. Design cleanup will possibly change behavior in edge cases
  6. Non-disruptive changes to type hierarchy (to better support current and forthcoming international standards and W3C recommendations)
  7. Design cleanup will possibly change component structure (changes to functionality restricted to edge cases)
  8. No significant changes in existing functionality
  9. No changes to XML transfer syntax except those required by version control hooks, co-occurrence constraints and bug fixes

The aim with regard to compatibility is that

  • All schema documents conformant to version 1.0 of this specification should also conform to version 1.1, and should have the same validation behavior across 1.0 and 1.1 implementations (except possibly in edge cases and in the details of the resulting PSVI);
  • The vast majority of schema documents conformant to version 1.1 of this specification should also conform to version 1.0, leaving aside any incompatibilities arising from support for versioning or co-occurrence constraints, and when they are conformant to version 1.0 (or are made conformant by the removal of versioning information), should have the same validation behavior across 1.0 and 1.1 implementations (again except possibly in edge cases and in the details of the resulting PSVI);

previous sub-section next sub-section1.2 Purpose

The purpose of XML Schema Definition Language: Structures is to define the nature of !! and their component parts, provide an inventory of XML markup constructs with which to represent schemas, and define the application of schemas to XML documents.

The purpose of an XSDL schema is to define and describe a class of XML documents by using schema components to constrain and document the meaning, usage and relationships of their constituent parts: datatypes, elements and their content and attributes and their values. Schemas can also provide for the specification of additional document information, such as normalization and defaulting of attribute and element values. Schemas have facilities for self-documentation. Thus, XML Schema Definition Language: Structures can be used to define, describe and catalogue XML vocabularies for classes of XML documents.

Any application that consumes well-formed XML can use the formalism defined here to express syntactic, structural and value constraints applicable to its document instances. The XSDL formalism allows a useful level of constraint checking to be described and implemented for a wide spectrum of XML applications. However, the language defined by this specification does not attempt to provide all the facilities that might be needed by applications. Some applications will require constraint capabilities not expressible in this language, and so will need to perform their own additional validations.

previous sub-section next sub-section1.3 Namespaces and Language Identifiers

        1.3.1 XSDL Namespaces
        1.3.2 Conventional Namespace Bindings
        1.3.3 Schema Language Identifiers

1.3.1 XSDL Namespaces

1.3.1.1 The Schema Namespace (xs)

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: or the prefix xsd: to stand for this namespace; in practice, any prefix can be used.

Note:  The namespace for schema documents is unchanged from version 1.0 of this specification, because any schema document valid under the rules of version 1.0 has essentially the same validation semantics under this specification as it did under version 1.0 (Second Edition). There are a few exceptions to this rule, involving errors in version 1.0 of this specification which were not reparable by errata and which have therefore been fixed only in this version of this specification, not in version 1.0.
Note:  The data model used by [XPath 2.0] and other specifications, namely [XDM], makes use of type labels in the XSDL namespace (untyped, untypedAtomic) which are not defined in this specification; see the [XDM] specification for details of those types.

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

1.3.1.2 The Schema Instance Namespace (xsi)

This specification defines several attributes for direct use in any XML documents, as described in Schema-Related Markup in Documents Being Validated (§2.6). These attributes are in the namespacewhose name is http://www.w3.org/2001/XMLSchema-instance. For brevity, the text and examples in this specification use the prefix xsi: to stand for this namespace; in practice, any prefix can be used.

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

1.3.1.3 The Schema Versioning Namespace (vc)

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

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

1.3.2 Conventional Namespace Bindings

Several namespace prefixes are conventionally used in this document for notational convenience. The following bindings are assumed.
  • fn bound to http://www.w3.org/2005/xpath-functions (defined in [Functions and Operators]
  • html bound to http://www.w3.org/1999/xhtml
  • my (in examples) bound to the target namespace of the example schema document
  • rddl bound to http://www.rddl.org/
  • vc bound to http://www.w3.org/2007/XMLSchema-versioning (defined in this and related specifications)
  • xhtml bound to http://www.w3.org/1999/xhtml
  • xlink bound to http://www.w3.org/1999/xlink
  • xml bound to http://www.w3.org/XML/1998/namespace (defined in [XML 1.1] and [XML-Namespaces 1.1])
  • xmlns bound to http://www.w3.org/2000/xmlns/ (defined in [XML-Namespaces 1.1])
  • xs bound to http://www.w3.org/2001/XMLSchema (defined in this and related specifications)
  • xsd bound to http://www.w3.org/2001/XMLSchema (defined in this and related specifications)

    Editorial Note: In its current state, the status quo uses both the prefix xs and the prefix xsd for the XSDL namespace. Once the Working Group reaches a decision on the name of the language, the editors expect to bring forward a proposal to unify all uses on a single prefix; which prefix to use will depend on the Working Group's decision.

  • xsi bound to http://www.w3.org/2001/XMLSchema-instance (defined in this and related specifications)
  • xsl bound to http://www.w3.org/1999/XSL/Transform

In practice, any prefix bound to the appropriate namespace name may be used (unless otherwise specified by the definition of the namespace in question, as for xml and xmlns).

Editorial Note: Loose ends to be tied up: (1) the example with a reference to xsl:quantity lacks any binding for the prefix xsl (and does XSL define a name quantity); (2) We need references (informative?) to the RDDL and XLink specs.

1.3.3 Schema Language Identifiers

Sometimes other specifications or Application Programming Interfaces (APIs) need to refer to the XML Schema Definition Language in general, sometimes they need to refer to a specific version of the language. To make such references easy and enable consistent identifiers to be used, we provide the following URIs to identify these concepts.

http://www.w3.org/XML/XMLSchema
Identifies the XML Schema Definition Language in general, without referring to a specific version of it.
http://www.w3.org/XML/XMLSchema/vX.Y
Identifies the language described in version X.Y of the XSDL specification. URIs of this form refer to a numbered version of the language in general. They do not distinguish among different working drafts or editions of that version. For example, http://www.w3.org/XML/XMLSchema/v1.0 identifies XSDL version 1.0 and http://www.w3.org/XML/XMLSchema/v1.1 identifies XSDL version 1.1.
http://www.w3.org/XML/XMLSchema/vX.Y/ Ne
Identifies the language described in the N-th edition of version X.Y of the XSDL specification. For example, http://www.w3.org/XML/XMLSchema/v1.0/2e identifies the second edition of XSDL version 1.0.
http://www.w3.org/XML/XMLSchema/vX.Y/ Ne/yyyymmdd
Identifies the language described in the N-th edition of version X.Y of the XSDL specification published on the particular date yyyy-mm-dd. For example, http://www.w3.org/XML/XMLSchema/v1.0/1e/20001024 identifies the language defined in the XSDL version 1.0 Candidate Recommendation (CR) published on 24 October 2000, and http://www.w3.org/XML/XMLSchema/v1.0/2e/20040318 identifies the language defined in the XSDL version 1.0 Second Edition Proposed Edited Recommendation (PER) published on 18 March 2004.

Please see XSDL Language Identifiers (non-normative) (§N) for a complete list of XML Schema Definition Language identifiers which exist to date.

previous sub-section next sub-section1.4 Dependencies on Other Specifications

The definition of XML Schema Definition Language: Structures depends on the following specifications: [XML-Infoset], [XML-Namespaces 1.1], [XPath 2.0], and [XML Schema: Datatypes].

See Required Information Set Items and Properties (normative) (§E) for a tabulation of the information items and properties specified in [XML-Infoset] which this specification requires as a precondition to schema-aware processing.

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

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

Note:  Implementations may provide the heuristic of using the 1.1 datatypes if the input is labeled as XML 1.1, and the 1.0 datatypes if the input is labeled 1.0. It should be noted however that the XML version number is not required to be present in the input to an assessment episode, and in any case the heuristic should be subject to override by users, to support cases where users wish to accept XML 1.1 input but validate it using the 1.0 datatypes, or accept XML 1.0 input and validate it using the 1.1 datatypes.
Note:  Some users will perhaps wish to accept only XML 1.1 input, or only XML 1.0 input. Conforming implementations of this specification which accept XML input may accept XML 1.0, XML 1.1, or both and may provide user control over which versions of XML to accept.

previous sub-section 1.5 Documentation Conventions and Terminology

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:

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

Schema Component: Example
{example property}
A Component component. Required.

An example property

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 determines which of several different components corresponds to the source declaration, several tabulations, one per context, are given. The property correspondences are normative, as are the illustrations of the XML representation element information items.

In the XML representation, bold-face attribute names (e.g. count below) indicate a required attribute information item, and the rest are optional. Where an attribute information item has an enumerated type definition, the values are shown separated by vertical bars, as for size below; if there is a default value, it is shown following a colon. Where an attribute information item has a built-in simple type definition defined in [XML Schema: 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.

Note: The illustrations are derived automatically from the Schema for Schema Documents (Structures) (normative) (§A). In the case of apparent conflict, the Schema for Schema Documents (Structures) (normative) (§A) takes precedence, as it, together with the ·Schema Representation Constraints·, provide the normative statement of the form of XML representations.
XML Representation Summary: example Element Information Item

<example
  count = integer
  size = (large | medium | small) : medium>
  Content: (all | any*)
</example>

Example Schema Component
Property
Representation
 
Description of what the property corresponds to, e.g. the value of the size [attribute]
 

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:

PSVI Contributions for example information items
[new property]
The value the property gets.

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.

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

may
Conforming documents and XSDL-aware processors are permitted to but need not behave as described.
should
It is recommended that conforming documents and XSDL-aware processors behave as described, but there can be valid reasons for them not to; it is important that the full implications be understood and carefully weighed before adopting behavior at variance with the recommendation.
must
Conforming documents and XSDL-aware processors are required to behave as described; otherwise they are in error.
must not
Conforming documents and XSDL-aware processors are forbidden to behave as described; if they do they are in error.

These definitions describe in terms specific to this document the meanings assigned to these terms by [IETF RFC 2119]. The specific wording follows that of [XML 1.1].

This specification provides a definition of error and of conformant processors' responsibilities with respect to errors in Schemas and Schema-validity Assessment (§5).

2 Conceptual Framework

This chapter gives an overview of XML Schema Definition Language: 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 will find it most useful first to read [XML Schema: Primer] for a tutorial introduction, and only then to consult the sub-sections of Schema Component Details (§3) named XML Representation of ... for the details.

next sub-section2.1 Overview of XSDL

An XSDL schema is a set of components such as type definitions and element declarations. These can be used to assess the validity of well-formed element and attribute information items (as defined in [XML-Infoset]), and furthermore may specify augmentations to those items and their descendants. This augmentation makes explicit information implicit in the original document, such as normalized and/or default values for attributes and elements and the types of element and attribute information items. The input information set can also be augmented with information about the validity of the item, or about other properties described in this specification. [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. Conforming processors may provide access to some or all of the PSVI, as described in Subset of the Post-schema-validation Infoset (§D.1). The mechanisms by which processors provide such access to the PSVI are neither defined nor constrained by this specification.

Schema-validity assessment has two aspects:
1 Determining local schema-validity, that is whether an element or attribute information item satisfies the constraints embodied in the relevant components of an XSDL schema;
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.

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

previous sub-section next sub-section2.2 XSDL Abstract Data Model

        2.2.1 Type Definition Components
        2.2.2 Declaration Components
        2.2.3 Model Group Components
        2.2.4 Constraint Components
        2.2.5 Group Definition Components
        2.2.6 Annotation Components

This specification builds on [XML 1.1] and [XML-Namespaces 1.1]. 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.1]) and namespace conformance (as defined in [XML-Namespaces 1.1]) for all candidates for ·assessment· and for all ·schema documents·.

Just as [XML 1.1] and [XML-Namespaces 1.1] can be described in terms of information items, XSDL schemas can be described in terms of an abstract data model. In defining schemas in terms of an abstract data model, this specification rigorously specifies the information which must be available to a conforming XSDL processor. The abstract model for schemas is conceptual only, and does not mandate any particular implementation or representation of this information. To facilitate interoperation and sharing of schema information, a normative XML interchange format for schemas is provided.

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

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

The secondary components, are as follows:

  • Attribute group definitions
  • Identity-constraint definitions
  • Type alternatives
  • Assertions
  • 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

The name [Definition:]  Component covers all the different kinds of component defined in this specification.

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 and in some cases must have and be identified by names, which are NCNames as defined by [XML-Namespaces 1.1].

[Definition:]  Several kinds of component have a target namespace, which is either ·absent· or a namespace name, also as defined by [XML-Namespaces 1.1]. The ·target namespace· serves to identify the namespace within which the association between the component and its name exists. In the case of declarations, this in turn determines the namespace name of, for example, the element information items it will ·validate·.

Note: At the abstract level, there is no requirement that the components of a schema share a ·target namespace·. Any schema for use in ·assessment· of documents containing names from more than one namespace will of necessity include components with different ·target namespaces·. 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 is ·validated· with respect to an attribute declaration, a list of element information items with respect to a content model, and so on. The following sections briefly introduce the kinds of components in the schema abstract data model, other major features of the abstract model, and how they contribute to ·validation·.

2.2.1 Type Definition Components

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.

2.2.1.1 Type Definition Hierarchy

[Definition:]  Except for ·xs:anyType·, 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:]  The type definition used as the basis for an ·extension· or ·restriction· is known as the base type definition of that definition.

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

[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 special complex type definition, (referred to in earlier versions of this specification as 'the ur-type definition') whose name is anyType in the XSDL namespace, is present in each ·XSDL schema·. The definition of anyType serves as default type definition for element declarations whose XML representation does not specify one.

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

For brevity, the text and examples in this specification often use the qualified names xsd:anyType and xsd:error for these type definitions. (In practice, any appropriately declared prefix can be used, as described in Schema-Related Markup in Documents Being Validated (§2.6).)

2.2.1.2 Simple Type 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 Schema: Datatypes]) or user-defined, is a ·restriction· of its ·base type definition·. [Definition:]  The simple ur-type definition, a special ·restriction· of ·xs:anyType·, whose name is anySimpleType in the XML Schema namespace is the root of the ·Type Definition Hierarchy· for the simple type definitions. 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 built-in list datatypes all have the ·simple ur-type definition· as their ·base type definition·.

[Definition:]  There is a further special datatype called anyAtomicType, a ·restriction· of the ·simple ur-type definition·, which is the ·base type definition· of all the primitive built-in datatypes. It too is considered to have an unconstrained lexical space. Its value space consists of the union 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· or ·anyAtomicType·. Accordingly this specification does not constrain processors' behavior in areas where this mapping is implicated, for example checking such items against enumerations, constructing default attributes or elements whose declared type definition is 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.

[XML Schema: Datatypes] provides mechanisms for defining new simple type definitions by ·restricting· one of the built-in primitive or ordinary datatypes. It also provides mechanisms for constructing new simple type definitions whose members are lists of items themselves constrained by some other simple type definition, or whose membership is the union of the memberships of some other simple type definitions. Such list and union simple type definitions are also ·restrictions· of the ·simple ur-type definition·.

For detailed information on simple type definitions, see Simple Type Definitions (§3.16) and [XML Schema: Datatypes]. The latter also defines an extensive inventory of pre-defined simple types.

2.2.1.3 Complex Type Definition

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

Each complex type definition other than ·xs:anyType· is either or
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: For the most part, this specification allows only appending, and not other kinds of extensions. This decision simplifies application processing required to cast instances from derived to base type. A special case allows the extension of all-groups in ways that do not guarantee that the new material occurs only at the end of the content. 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).

2.2.2 Declaration Components

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.

2.2.2.1 Element Declaration

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

2.2.2.2 Element Substitution Group

In XML, 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, XSDL 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)).

2.2.2.3 Attribute Declaration

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

2.2.2.4 Notation Declaration

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

For detailed information on notation declarations, see Notation Declarations (§3.14).

2.2.3 Model Group Components

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

2.2.3.1 Model Group

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

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

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

2.2.3.2 Particle

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

The name [Definition:]  Term is used to refer to any of the three kinds of components which can appear in particles. All ·Terms· are themselves ·Annotated Components·. [Definition:]  A basic term is an Element Declaration or a Wildcard. [Definition:]  A basic particle is a Particle whose {term} is a ·basic term·.

[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.
Note: XSDL ·content models· are similar to but more expressive than [XML 1.1] content models; unlike [XML 1.1], XSDL does not restrict the form of ·content models· describing mixed content.

Each content model, indeed each particle, denotes a set of sequences of element information items. Regarding that set of sequences as a language, the set of sequences recognized by a particle P may be written L(P). [Definition:]  A particle P is said to accept or recognize the members of L(P).

Note: The language accepted by a content model plays a role in determining whether an element information item is locally valid or not: if the appropriate content model does not accept the sequence of elements among its children, then the element information item is not locally valid. (Some additional constraints must also be met: not every sequence in L(P) is locally valid against P. See Principles of Validation against Groups (§3.8.4.2).)No assumption is made, in the definition above, that the items in the sequence are themselves valid; only the expanded names of the items in the sequence are relevant in determining whether the sequence is accepted by a particle. Their validity does affect whether their parent is (recursively) valid as well as locally valid.

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

Note: This ·path· has nothing to do with XPath expressions. When there may otherwise be danger of confusion, the ·path· described here may be referred to as the ·match path· of S in P.

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

2.2.3.3 Attribute Use

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.

2.2.3.4 Wildcard

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

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

2.2.4 Constraint Components

2.2.4.1 Identity-constraint Definition

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 2.0] 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).

Note:  In version 1.0 of this specification, identity constraints used [XPath 1.0] They now use [XPath 2.0].
2.2.4.2 Type Alternative

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

Note: The provisions for conditional type assignment are inspired by, but not identical to, those of [SchemaPath].

For detailed information on Type Alternatives, see Type Alternatives (§3.12).

2.2.4.3 Assertion

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

For detailed information on Assertions, see Assertions (§3.13).

Editorial Note: Priority Feedback Request

Assertions are currently only allowed to be specified in complex types. It may be deemed useful also to include assertions in named model group definitions and/or attribute groups, or even simple types. The XML Schema Working Group solicits input from implementors and users of this specification on this question.

2.2.5 Group Definition Components

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.

2.2.5.1 Model Group Definition

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

2.2.5.2 Attribute Group Definition

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

2.2.6 Annotation Components

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

previous sub-section next sub-section2.3 Constraints and Validation Rules

The [XML 1.1] 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 Schema Documents (Structures) (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 validation augments the XML 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 leaves implicit.

previous sub-section next sub-section2.4 Conformance

Note: The Working Group expects to revise this discussion of conformance in future. A sketch of relevant work can be found in Checklist of implementation-defined features (§F.1) and Terminology for implementation-defined features (§D).

Within the context of this specification, conformance can be claimed for schema documents and for XSDL-aware processors.

A ·schema document· conforms to this specification if and only if all of the following are true:
1 It is valid with respect to the schema specified in Schema for Schema Documents (Structures) (normative) (§A). (That is, in its ·post-schema-validation infoset·, the <schema> element has a [validation attempted] property with value full or partial and a [validity] property with value valid.
2 No element in the schema document violates any of the Schema Representation Constraints set out in Schema Representation Constraints (§C.3).
Note: While conformance of schema documents is a precondition for the mapping from schema documents to schema components described in this specification, conformance of the schema documents does not guarantee that the result of that mapping will be a schema that conforms to this specification. Some constraints (e.g. the rule that there must be at most one top-level element declaration with a particular expanded name) can only be checked in the context of the schema as a whole.
Note:  Some Schema Representation Constraints cannot, in their current formulation, be checked against the schema document in isolation, but only in the context of the schema as a whole. It is a consequence that in some cases, the conformance of a schema document cannot be determined in isolation.

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 be schema-document aware. Such processors must, when processing schema documents, completely and correctly implement (or enforce) 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·.

Note: The ·Schema Representation Constraints· are to be enforced after, not before, the conditional-inclusion pre-processing described in Conditional inclusion (§4.2.1).

[Definition:]  A ·minimally conforming· processor which is not ·schema-document aware· is said to be a non-schema-document-aware processor.

Note: By separating the conformance requirements relating to the concrete syntax of ·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 ·minimally conforming· but not necessarily ·schema-document aware·.

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

Note: In version 1.0 of this specification the class of ·schema-document aware· processors was termed "conformant to the XML Representation of Schemas". Similarly, the class of ·Web-aware· processors was called "fully conforming".
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.

previous sub-section next sub-section2.5 Names and Symbol Spaces

As discussed in XSDL 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. There is a single distinct symbol space within a given ·target namespace· for each kind of definition and declaration component identified in XSDL 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.

previous sub-section next sub-section2.6 Schema-Related Markup in Documents Being Validated

        2.6.1 xsi:type
        2.6.2 xsi:nil
        2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation

XML Schema Definition Language: Structures defines several attributes for direct use in any XML documents. These attributes are in the schema instance namespace (http://www.w3.org/2001/XMLSchema-instance) described in The Schema Instance Namespace (xsi) (§1.3.1.2) above. 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).

2.6.1 xsi:type

The Simple Type Definition (§2.2.1.2) or Complex Type Definition (§2.2.1.3) used in ·validation· of an element is usually determined by reference to the appropriate schema components. An element information item in an instance may, however, explicitly assert its type using the attribute xsi:type. The value of this attribute is a ·QName·; see QName Interpretation (§3.17.3) for the means by which the ·QName· is associated with a type definition.

2.6.2 xsi:nil

XML Schema Definition Language: Structures introduces a mechanism for signaling that an element must 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 can 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.

2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation

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 can be used for ·assessment·. See How schema definitions are located on the Web (§4.3.2) for details on the use of these attributes.

previous sub-section 2.7 Representation of Schemas on the World Wide Web

On the World Wide Web, schemas are conventionally represented as XML documents (preferably of MIME type application/xml or text/xml, but see clause 1.1 of Inclusion Constraints and Semantics (§4.2.2)), conforming to the specifications in Layer 2: Schema Documents, Namespaces and Composition (§4.2). For more information on the representation and use of schema documents on the World Wide Web see Standards for representation of schemas and retrieval of schema documents on the Web (§4.3.1) and How schema definitions are located on the Web (§4.3.2).

3 Schema Component Details

next sub-section3.1 Introduction

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.

3.1.1 Components and Properties

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, decimal) 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· must not exist, so in some cases re-entrant chains of properties will 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".

Component properties are simply named values. Most properties have either other components or literals (that is, strings or booleans or enumerated keywords) for values, but in a few cases, where more complex values are involved, [Definition:]  a property value may itself be a collection of named values, which we call a property record.

[Definition:]  Throughout this specification, the term absent is used as a distinguished property value denoting absence. Again this should not be interpreting as constraining implementations, as for instance between using a null value for such properties or not representing them at all.

Any property not defined as optional is always 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.1].

Note: It is ·implementation-defined· whether a schema processor uses the definition of legal character from [XML 1.1] or [XML 1.0].

3.1.2 XML Representations of Components

The principal purpose of XML Schema Definition Language: 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 Schema Documents (Structures) (normative) (§A) and DTD for Schemas (non-normative) (§K)) and schema components. The key element information items in the XML representation of a schema are in the XSDL namespace, that is their [namespace name] is 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 XSDL 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.

The descriptions of the XML representation of components, and the ·Schema Representation Constraints·, apply to schema documents after, not before, the conditional-inclusion pre-processing described in Conditional inclusion (§4.2.1).

3.1.3 The Mapping between XML Representations and Components

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 Schema Documents (Structures) (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 Schema Documents (Structures) (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 can 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 will in some cases 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·, it is possible that an appropriately-named component will have become available to discharge the reference: see Schemas and Namespaces: Access and Composition (§4) for details.

3.1.4 White Space Normalization during Validation

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·, then the ·normalized value· must be determined as in the preserve case above.

There are three alternative validation rules which help 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 1.2).

These three levels of normalization correspond to the processing mandated in XML for element content, CDATA attribute content and tokenized attributed content, respectively. See Attribute Value Normalization in [XML 1.1] 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.

Note: Even when DTD-based information has been appealed to, and Attribute Value Normalization has taken place, it is possible that further normalization will take place, as for instance when character entity references in attribute values result in white space characters other than spaces in their ·initial value·s.
Note: The values replace and collapse may appear to provide a convenient way to "unwrap" text (i.e. undo the effects of pretty-printing and word-wrapping). In some cases, especially highly constrained data consisting of lists of artificial tokens such as part numbers or other identifiers, this appearance is correct. For natural-language data, however, the whitespace processing prescribed for these values is not only unreliable but will systematically remove the information needed to perform unwrapping correctly. For Asian scripts, for example, a correct unwrapping process will replace line boundaries not with blanks but with zero-width separators or nothing. In consequence, it is normally unwise to use these values for natural-language data, or for any data other than lists of highly constrained tokens.

previous sub-section next sub-section3.2 Attribute Declarations

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.
Example
<xs:attribute name="age" type="xs:positiveInteger" use="required"/>
The XML representation of an attribute declaration.

3.2.1 The Attribute Declaration Schema Component

The attribute declaration schema component has the following properties:

Schema Component: , a kind of Annotated Component
{annotations}
A sequence of Annotation components.
{name}
An xs:NCName value. Required.
{target namespace}
An xs:anyURI value. Optional.
{type definition}
A Simple Type Definition component. Required.
{scope}
A Scope property record. Required.
{value constraint}
A Value Constraint property record. Optional.
Property Record: Scope
{variety}
One of {global, local}. Required.
{parent}
Either a Complex Type Definition or a Attribute Group Definition. Required if {variety} is local, otherwise must be ·absent·
Property Record: Value Constraint
{variety}
One of {default, fixed}. Required.
{value}
An ·actual value·. Required.
{lexical form}
A character string. Required.

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} with {variety} 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 or Attribute Group Definition identified by the {scope}'s {parent} property.

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

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

Note: A more complete and formal presentation of the semantics of {name}, {target namespace} and {value constraint} is provided in conjunction with other aspects of complex type ·validation· (see Element Locally Valid (Complex Type) (§3.4.4).)

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

3.2.2 XML Representation of Attribute Declaration Schema Components

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:

XML Representation Summary: attribute Element Information Item

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

Editorial Note: Priority Feedback Request

Earlier versions of this specification did not allow a targetNamespace attribute on attribute declarations; it has been added in this version to make restriction of complex types easier. The XML Schema Working Group has designated the targetNamespace attribute a ‘feature at risk’: it may be dropped from future drafts of this specification if implementation or usage experience shows that its costs outweigh its benefits. The XML Schema Working Group solicits input from implementors and users of this specification as to whether the addition of this attribute is desirable and acceptable.

If the <attribute> element information item has <schema> as its parent, the corresponding schema component is as follows:
Attribute Declaration Schema Component
Property
Representation
 
 
The ·actual value· of the targetNamespace [attribute] of the parent <schema> element information item, or ·absent· if there is none.
 
The simple type definition corresponding to the <simpleType> element information item in the [children], if present, otherwise the simple type definition ·resolved· to by the ·actual value· of the type [attribute], if present, otherwise the ·simple ur-type definition·.
 
A Scope as follows:
Property
Value
global
 
If there is a default or a fixed [attribute], then a Value Constraint as follows, otherwise ·absent·.
Property
Value
either default or fixed, as appropriate
the ·actual value· (with respect to the {type definition}) of the [attribute]
 
otherwise if the <attribute> element information item has <complexType> or <attributeGroup> as an ancestor and the ref [attribute] is absent, it corresponds to an attribute use with properties as follows (unless use='prohibited', in which case the item corresponds to nothing at all):
Attribute Use Schema Component
Property
Representation
 
true if the use [attribute] is present with ·actual value· required, otherwise false.
 
See the Attribute Declaration mapping immediately below.
 
If there is a default or a fixed [attribute], then a Value Constraint as follows, otherwise ·absent·.
Property
Value
either default or fixed, as appropriate
 
The same annotations as the {annotations} of the Attribute Declaration. See below.
Attribute Declaration Schema Component
Property
Representation
 
 
The appropriate case among the following:
1 If targetNamespace is present , then its ·actual value·.
2 If targetNamespace is not present and one of the following is true
2.1 form is present and its ·actual value· is qualified
2.2 form is absent and the ·actual value· of attributeFormDefault on the <schema> ancestor is qualified
, then the ·actual value· of the targetNamespace [attribute] of the ancestor <schema> element information item, or ·absent· if there is none.
3 otherwise ·absent·.
 
The simple type definition corresponding to the <simpleType> element information item in the [children], if present, otherwise the simple type definition ·resolved· to by the ·actual value· of the type [attribute], if present, otherwise the ·simple ur-type definition·.
 
A Scope as follows:
Property
Value
local
If the <attribute> element information item has <complexType> as an ancestor, the Complex Type Definition corresponding to that item, otherwise (the <attribute> element information item is within an <attributeGroup> element information item), the Attribute Group Definition corresponding to that item.
 
 
otherwise (the <attribute> element information item has <complexType> or <attributeGroup> as an ancestor and the ref [attribute] is present), it corresponds to an attribute use with properties as follows (unless use='prohibited', in which case the item corresponds to nothing at all):
Attribute Use Schema Component
Property
Representation
 
true if the use [attribute] is present with ·actual value· required, otherwise false.
 
The (top-level) attribute declaration ·resolved· to by the ·actual value· of the ref [attribute]
 
If there is a default or a fixed [attribute], then a Value Constraint as follows, otherwise ·absent·.
Property
Value
either default or fixed, as appropriate
 

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 the {target namespace} 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.

3.2.3 Constraints on XML Representations of Attribute Declarations

Schema Representation Constraint: Attribute Declaration Representation OK
In addition to the conditions imposed on <attribute> element information items by the schema for schema documents, all of the following also apply:
1 default and fixed must not both be present.
2 If default and use are both present, use must have the ·actual value· optional.
3 If the item's parent is not <schema>, then all of the following must be true:
3.1 One of ref or name is present, but not both.
3.2 If ref is present, then all of <simpleType>, form and type are absent.
4 type and <simpleType> must not both be present.
5 If fixed and use are both present, use must not have the ·actual value· prohibited.
6 If targetNamespace is present then all of the following must be true:
6.1 name is present.
6.2 form is not present.
6.3 If the ancestor <schema> does not have a targetNamespace [attribute] or its ·actual value· is different from the ·actual value· of targetNamespace of <attribute>, then all of the following are true:
6.3.1 <attribute> has <complexType> as an ancestor
6.3.2 Let B be the {base type definition} of the Complex Type Definition corresponding to <complexType>. B's {attribute uses} contains an Attribute Use whose {attribute declaration} has the same {name} and {target namespace} as those of the Attribute Declaration corresponding to this <attribute>.
7 The corresponding attribute declaration must satisfy the conditions set out in Constraints on Attribute Declaration Schema Components (§3.2.6).

3.2.4 Attribute Declaration Validation Rules

Validation Rule: Attribute Locally Valid
For an attribute information item to be locally ·valid· with respect to an attribute declaration all of the following must be true:
1 The declaration is not ·absent· (see Missing Sub-components (§5.3) for how this can fail to be the case).
2 Its {type definition} is not absent.
3 The item's ·normalized value· is locally ·valid· with respect to that {type definition} as per String Valid (§3.16.4).
4 The item's ·actual value· matches the {value} of the {value constraint}, if it is present and its {variety} is fixed.
5 If the declaration is the built-in declaration for xsi:type (Attribute Declaration for the 'type' attribute (§3.2.7)), then the item's ·actual value· ·resolves· to a type definition.
[Definition:]   In a given schema-validity ·assessment· episode, the ·governing· declaration of an attribute (its governing attribute declaration) is the first of the following which applies:
1 A declaration which was stipulated by the processor (see Assessing Schema-Validity (§5.2)).
3 A declaration ·resolved· to by its [local name] and [namespace name], provided the attribute is not ·attributed· to a skip ·wildcard particle· and the processor has not stipulated a type definition at the start of ·assessment·.
If the attribute is ·attributed· to a skip ·wildcard particle· or if the processor has stipulated a type definition, then it has no ·governing· declaration.

[Definition:]   The governing type definition of an attribute, in a given schema-validity ·assessment· episode, is the {type definition} of the ·governing attribute declaration·, unless the processor has stipulated another type definition at the start of ·assessment· (see Assessing Schema-Validity (§5.2)), in which case it is the stipulated type definition.

Validation Rule: Schema-Validity Assessment (Attribute)
The schema-validity assessment of an attribute information item depends on its ·validation· alone.For an attribute information item's schema-validity to have been assessed all of the following must be true:
1 A ·non-absent· attribute declaration is known for it, namely its ·governing· declaration.
2 Its ·validity· with respect to that declaration has been evaluated as per Attribute Locally Valid (§3.2.4).
3 Both clause 1 and clause 2 of Attribute Locally Valid (§3.2.4) are satisfied.
[Definition:]  For attributes, there is no difference between assessment and strict assessment, so the attribute information item has been strictly assessed if and only if its schema-validity has been assessed.

3.2.5 Attribute Declaration Information Set Contributions

Schema Information Set Contribution: Assessment Outcome (Attribute)
If the schema-validity of an attribute information item has been assessed as per Schema-Validity Assessment (Attribute) (§3.2.4), then in the ·post-schema-validation infoset· it has properties as follows:
PSVI Contributions for attribute information items
[validation context]
The nearest ancestor element information item with a [schema information] property.
[validity]
The appropriate case among the following:
1 If it was ·strictly assessed·, then the appropriate case among the following:
1.1 If it was ·valid· as defined by Attribute Locally Valid (§3.2.4), then valid;
1.2 otherwise invalid.
2 otherwise notKnown.
[validation attempted]
The appropriate case among the following:
1 If it was ·strictly assessed·, then full;
2 otherwise none.
[schema specified]
infoset. See Attribute Default Value (§3.4.5) for the other possible value.
Schema Information Set Contribution: Validation Failure (Attribute)
If and only if the local ·validity·, as defined by Attribute Locally Valid (§3.2.4) above, of an attribute information item has been assessed, then in the ·post-schema-validation infoset· the item has a property:
PSVI Contributions for attribute information items
[schema error code]
The appropriate case among the following:
1 If the item is ·invalid·, then a list. Applications wishing to provide information as to the reason(s) for the ·validation· failure are encouraged to record one or more error codes (see Outcome Tabulations (normative) (§C)) herein.
2 otherwise ·absent·.
Schema Information Set Contribution: Attribute Declaration
If and only if a ·governing· declaration is known for an attribute information item then in the ·post-schema-validation infoset· the attribute information item has a property:
PSVI Contributions for attribute information items
[attribute declaration]
An ·item isomorphic· to the ·governing· declaration component itself.
[schema default]
If the attribute information item is ·attributed· to an Attribute Use then the {lexical form} of the ·effective value constraint·, otherwise the {lexical form} of the declaration's {value constraint}.
Schema Information Set Contribution: Attribute Validated by Type
If and only if a ·governing type definition· is known for an attribute information item, then in the ·post-schema-validation infoset· the attribute information item has the properties:
PSVI Contributions for attribute information items
[schema normalized value]
If the attribute's ·normalized value· is ·valid· with respect to the ·governing type definition·, then the ·normalized value· as ·validated·, otherwise ·absent·.
[schema actual value]
If the [schema normalized value] is not ·absent·, then the corresponding ·actual value·; otherwise ·absent·.
[type definition]
An ·item isomorphic· to the ·governing type definition· component.
[type definition type]
simple.
[type definition namespace]
The {target namespace} of the ·type definition·.
[type definition anonymous]
true if the {name} of the ·type definition· is ·absent·, otherwise false.
[type definition name]
The {name} of the ·type definition·, if the {name} is not ·absent·. If the ·type definition·'s {name} property is ·absent·, then schema processors may, but need not, provide a value which uniquely identifies this type definition among those with the same target namespace. It is ·implementation-defined· whether a processor provides a name for such a type definition. If a processor does provide a value in this situation, the choice of what value to use is ·implementation-dependent·.
Note: The [type definition type], [type definition namespace], [type definition name], and [type definition anonymous] properties are redundant with the [type definition] property; they are defined for the convenience of implementations which wish to expose those specific properties but not the entire type definition.
If the attribute's ·normalized value· is ·valid· with respect to the ·governing type definition· as defined by String Valid (§3.16.4) and the ·governing type definition· has {variety} union, then calling [Definition:]   that basic member of its transitive membership which actually ·validated· the attribute item's ·normalized value· the actual member type definition, there are four additional properties:
PSVI Contributions for attribute information items
[member type definition]
an ·item isomorphic· to the ·actual member type definition·.
[member type definition namespace]
The {target namespace} of the ·actual member type definition·.
[member type definition anonymous]
true if the {name} of the ·actual member type definition· is ·absent·, otherwise false.
[member type definition name]
The {name} of the ·actual member type definition·, if it is not ·absent·. If it is ·absent·, schema processors may, but need not, provide a value unique to the definition. It is ·implementation-defined· whether a processor provides a name for such a type definition. If a processor does provide a value in this situation, the choice of what value to use is ·implementation-dependent·.
The first (·item isomorphic·) alternative above is provided for applications such as query processors which need access to the full range of details about an item's ·assessment·, 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.If all of the following are true:
1 the attribute's ·normalized value· is ·valid· with respect to the ·governing type definition·;
2 One of the following is true:
3 the {item type definition} of the list type (from the previous clause) has {variety} union;
then there is an additional property:
PSVI Contributions for attribute information items
[member type definitions]
a sequence of Simple Type Definition components, with the same length as the [schema actual value], each one an ·item isomorphic· to the basic member which actually ·validated· the corresponding space-delimited substring in the [schema normalized value].

See also Attribute Default Value (§3.4.5), Match Information (§3.4.5) and Schema Information (§3.17.5), which describe other information set contributions related to attribute information items.

3.2.6 Constraints on Attribute Declaration Schema Components

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

Schema Component Constraint: Attribute Declaration Properties Correct
All of the following must be true:
1 The values of the properties of an attribute declaration are as described in the property tableau in The Attribute Declaration Schema Component (§3.2.1), modulo the impact of Missing Sub-components (§5.3).
2 if there is a {value constraint}, then it is a valid default with respect to the {type definition} as defined in Simple Default Valid (§3.2.6).
Note: The use of ID and related types together with value constraints goes beyond what is possible with XML DTDs, and should be avoided if compatibility with DTDs is desired.
Schema Component Constraint: Simple Default Valid
For a Value Constraint to be a valid default with respect to a Simple Type Definition all of the following are true:
1 the Value Constraint's {lexical form} is ·valid· with respect to that Simple Type Definition as defined by Datatype Valid in [XML Schema: Datatypes].
2 the Value Constraint's {lexical form} maps to its {value} in that Simple Type Definition's value space.
Schema Component Constraint: xmlns Not Allowed
The {name} of an attribute declaration must not match xmlns.
Note: The {name} of an attribute is an ·NCName·, which implicitly prohibits attribute declarations of the form xmlns:*.
Schema Component Constraint: xsi: Not Allowed
The {target namespace} of an attribute declaration, whether local or top-level, must not match http://www.w3.org/2001/XMLSchema-instance (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.
Note: It is not illegal for Attribute Uses that refer to xsi: attributes to specify default or fixed value constraints (e.g. in a component corresponding to a schema document construct of the form <xsd:attribute ref="xsi:type" default="xsd:integer"/>), but the practice is not recommended; including such attribute uses will tend to mislead readers of the schema document, because the attribute uses would have no effect; see Element Locally Valid (Complex Type) (§3.4.4) and Attribute Default Value (§3.4.5) for details.

3.2.7 Built-in Attribute Declarations

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

Property
Value
type
http://www.w3.org/2001/XMLSchema-instance
The built-in QName simple type definition
A Scope as follows:
Property
Value
global
Property
Value
nil
http://www.w3.org/2001/XMLSchema-instance
The built-in boolean simple type definition
A Scope as follows:
Property
Value
global
Property
Value
schemaLocation
http://www.w3.org/2001/XMLSchema-instance
An anonymous simple type definition, as follows:
Property
Value
http://www.w3.org/2001/XMLSchema-instance
list
The built-in anyURI simple type definition
A Scope as follows:
Property
Value
global
Property
Value
noNamespaceSchemaLocation
http://www.w3.org/2001/XMLSchema-instance
The built-in anyURI simple type definition
A Scope as follows:
Property
Value
global

previous sub-section next sub-section3.3 Element Declarations

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

3.3.1 The Element Declaration Schema Component

The element declaration schema component has the following properties:

Schema Component: Element Declaration, a kind of Term
{annotations}
A sequence of Annotation components.
{name}
An xs:NCName value. Required.
{target namespace}
An xs:anyURI value. Optional.
{type definition}
A Type Definition component. Required.
{type table}
A Type Table property record. Optional.
{scope}
A Scope property record. Required.
{value constraint}
A Value Constraint property record. Optional.
{nillable}
An xs:boolean value. Required.
{identity-constraint definitions}
A set of Identity-Constraint Definition components.
{substitution group affiliations}
A set of Element Declaration components.
{substitution group exclusions}
A subset of {extension, restriction}.
{disallowed substitutions}

A subset of {substitution, extension, restriction}.

{abstract}
An xs:boolean value. Required.
Property Record: Type Table
{alternatives}
A sequence of Type Alternative components.
{default type definition}
A Type Alternative component. Required.
Property Record: Scope
{variety}
One of {global, local}. Required.
{parent}
Either a Complex Type Definition or a Model Group Definition. Required if {variety} is local, otherwise must be ·absent·
Property Record: Value Constraint
{variety}
One of {default, fixed}. Required.
{value}
An ·actual value·. Required.
{lexical form}
A character string. Required.

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

A {scope} with {variety} 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 Definition or Model Group Definition identified by the {scope}'s {parent} property.

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 normally required to satisfy 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·. The type definition against which an element information item is validated (its ·governing type definition·) can be different from the declared {type definition}. The {type table} property of an Element Declaration, which governs conditional type assignment, and the xsi:type attribute of an element information item (see xsi:type (§2.6.1)) can cause the ·governing type definition· and the declared {type definition} to be different.

If {nillable} is true, then an element can 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 a {value constraint} with a {variety} of default is present, and if the element being ·validated· is empty, then the element is treated as if the {value constraint}'s {lexical form} was used as the content of the element. If fixed is specified, then the element's content must either be empty, in which case fixed behaves as default, or its value must be identical to the {value constraint}'s {value}.

Note: The provision of defaults for elements goes beyond what is possible in XML DTDs, and does not exactly correspond to defaults for attributes. In particular, an element with a non-empty {value constraint} whose simple type definition includes the empty string in its lexical space will nonetheless never receive that value, because the {value constraint} 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 groups·, if any, identified by {substitution group affiliations}. Potential membership is transitive but not symmetric; an element declaration is a potential member of any group of which any entry in its {substitution group affiliations} 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 named in the {substitution group affiliations} of other element declarations having the same declared {type definition} or some type derived therefrom. The explicit values of {substitution group exclusions} rule out element declarations having types which are extensions or restrictions respectively of {type definition}.

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 must not themselves ever be used to ·validate· element content.

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

3.3.2 XML Representation of Element Declaration Schema Components

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:

XML Representation Summary: element Element Information Item

<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 = List of QName
  targetNamespace = anyURI
  type = QName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, ((simpleType | complexType)?, alternative*, (unique | key | keyref)*))
</element>

Editorial Note: Priority Feedback Request

Earlier versions of this specification did not allow a targetNamespace attribute on element declarations; it has been added in this version to make restriction of complex types easier. The XML Schema Working Group has designated the targetNamespace attribute a ‘feature at risk’: it may be dropped from future drafts of this specification if implementation or usage experience shows that its costs outweigh its benefits. The XML Schema Working Group solicits input from implementors and users of this specification as to whether the addition of this attribute is desirable and acceptable.

If the <element> element information item has <schema> as its parent, the corresponding schema component is as follows:
Element Declaration Schema Component
Property
Representation
 
The ·actual value· of the name [attribute].
 
The ·actual value· of the targetNamespace [attribute] of the parent <schema> element information item, or ·absent· if there is none.
 
A Scope as follows
Property
Value
global
 
The first of the following that applies:
1 The type definition corresponding to the <simpleType> or <complexType> element information item in the [children], if either is present.
2 The type definition ·resolved· to by the ·actual value· of the type [attribute], if it is present.
3 The declared {type definition} of the Element Declaration ·resolved· to by the first QName in the ·actual value· of the substitutionGroup [attribute], if present.
 
A Type Table corresponding to the <alternative> element information items among the [children], if any, as follows, otherwise ·absent·.
Property
Value
A sequence of Type Alternatives, each corresponding, in order, to one of the <alternative> elements which have a test [attribute].
Depends upon the final <alternative> element among the [children]; the appropriate case among the following:
1 If the <alternative> has no test [attribute], then a Type Alternative corresponding to the <alternative>.
2 otherwise (the <alternative> has a test) a Type Alternative with the following properties:
Property
Value
the empty sequence.
 
The ·actual value· of the nillable [attribute], if present, otherwise false.
 
If there is a default or a fixed [attribute], then a Value Constraint as follows, otherwise ·absent·. [Definition:]  Use the name effective simple type definition for the declared {type definition}, if it is a simple type definition, or, if the declared {type definition}'s {content type} has {variety} simple, that {content type}'s {simple type definition}, or else the built-in string simple type definition).
Property
Value
either default or fixed, as appropriate
 
A set consisting of the identity-constraint-definitions corresponding to all the <key>, <unique> and <keyref> element information items in the [children], if any, otherwise the empty set.
 
A set of the element declarations ·resolved· to by the items in the ·actual value· of the substitutionGroup [attribute], if present, otherwise the empty set.
 
A set depending on the ·actual value· of the block [attribute], if present, otherwise on the ·actual value· of the blockDefault [attribute] of the ancestor <schema> element information item, if present, otherwise on the empty string. Call this the EBV (for effective block value). Then the value of this property is the appropriate case among the following:
1 If the EBV is the empty string, then the empty set;
2 If the EBV is #all, then {extension, restriction, substitution};
3 otherwise a set with members drawn from the set above, each being present or absent depending on whether the ·actual value· (which is a list) contains an equivalently named item.
Note: Although the blockDefault [attribute] of <schema> may include values other than extension, restriction or substitution, those values are ignored in the determination of {disallowed substitutions} for element declarations (they are used elsewhere).
 
As for {disallowed substitutions} above, but using the final and finalDefault [attributes] in place of the block and blockDefault [attributes] and with the relevant set being {extension, restriction}.
 
The ·actual value· of the abstract [attribute], if present, otherwise false.
 
otherwise if the <element> element information item has <complexType> or <group> as an ancestor and the ref [attribute] is absent, the corresponding schema components are as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all):
Particle Schema Component
Property
Representation
 
The ·actual value· of the minOccurs [attribute], if present, otherwise 1.
 
unbounded, if the maxOccurs [attribute] equals unbounded, otherwise the ·actual value· of the maxOccurs [attribute], if present, otherwise 1.
 
A (local) element declaration as given below.
 
The same annotations as the {annotations} of the Element Declaration. See below.
An element declaration as in the first case above, with the exception of its {target namespace} and {scope} properties, which are as below:
Element Declaration Schema Component
Property
Representation
 
The appropriate case among the following:
1 If targetNamespace is present , then its ·actual value·.
2 If targetNamespace is not present and one of the following is true
2.1 form is present and its ·actual value· is qualified
2.2 form is absent and the ·actual value· of elementFormDefault on the <schema> ancestor is qualified
, then the ·actual value· of the targetNamespace [attribute] of the ancestor <schema> element information item, or ·absent· if there is none.
3 otherwise ·absent·.
 
A Scope as follows:
Property
Value
local
If the <element> element information item has <complexType> as an ancestor, the Complex Type Definition corresponding to that item, otherwise (the <element> element information item is within a named <group> element information item), the Model Group Definition corresponding to that item.
otherwise (the <element> element information item has <complexType> or <group> as an ancestor and the ref [attribute] is present), the corresponding schema component is as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all):
Particle Schema Component
Property
Representation
 
The ·actual value· of the minOccurs [attribute], if present, otherwise 1.
 
unbounded, if the maxOccurs [attribute] equals unbounded, otherwise the ·actual value· of the maxOccurs [attribute], if present, otherwise 1.
 
The (top-level) element declaration ·resolved· to by the ·actual value· of the ref [attribute].
 

<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 the {target namespace} 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 first substitution-group head named in the substitutionGroup [attribute], if present, otherwise ·xs:anyType·. 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>.

Example
<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 ·xs:anyType· The second uses an embedded anonymous complex type definition.
The last two examples illustrate the use of local element declarations. Instances of myLocalElement within contextOne will be constrained by myFirstType, while those within contextTwo will be constrained by mySecondType.
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.
Example
 <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).
Example
The following example illustrates conditional type assignment to an element, based on the value of one of the element's attributes. Each instance of the message element will be assigned either to type messageType or to a more specific type derived from it.
The type messageType accepts any well-formed XML or character sequence as content, and carries a kind attribute which can be used to describe the kind or format of the message. The value of kind is either one of a few well known keywords or, failing that, any string.
<xs:complexType name="messageType" mixed="true">
 <xs:sequence>
  <xs:any processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
 </xs:sequence>
 <xs:attribute name="kind">
  <xs:simpleType>
   <xs:union>
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="string"/>
      <xs:enumeration value="base64"/>
      <xs:enumeration value="binary"/>
      <xs:enumeration value="xml"/>
      <xs:enumeration value="XML"/>
     </xs:restriction>
    </xs:simpleType>
    <xs:simpleType>
     <xs:restriction base="xs:string"/>
    </xs:simpleType>
   </xs:union>
  </xs:simpleType>
 </xs:attribute>
 <xs:anyAttribute processContents="skip"/>
</xs:complexType>
Three restrictions of messageType are defined, each corresponding to one of the three well-known formats: messageTypeString for kind="string", messageTypeBase64 for kind="base64" and kind="binary", and messageTypeXML for kind="xml" or kind="XML".
<xs:complexType name="messageTypeString">
 <xs:simpleContent>
  <xs:restriction base="messageType">
   <xs:simpleType>
    <xs:restriction base="xs:string"/>
   </xs:simpleType>
  </xs:restriction>
 </xs:simpleContent>
</xs:complexType>

<xs:complexType name="messageTypeBase64">
 <xs:simpleContent>
  <xs:restriction base="messageType">
   <xs:simpleType>
    <xs:restriction base="xs:base64Binary"/>
   </xs:simpleType>
  </xs:restriction>
 </xs:simpleContent>
</xs:complexType>

<xs:complexType name="messageTypeXML">
 <xs:complexContent>
  <xs:restriction base="messageType">
   <xs:sequence>
    <xs:any processContents="strict"/>
   </xs:sequence>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>
The message element itself uses messageType both as its declared type and as its default type, and uses test attributes on its <alternative> [children] to assign the appropriate specialized message type to messages with the well known values for the kind attribute:
<xs:element name="message" type="messageType">
  <xs:alternative test="@kind='string'" type="messageTypeString"/>
  <xs:alternative test="@kind='base64'" type="messageTypeBase64"/>
  <xs:alternative test="@kind='binary'" type="messageTypeBase64"/>
  <xs:alternative test="@kind='xml'"    type="messageTypeXML"/>
  <xs:alternative test="@kind='XML'"    type="messageTypeXML"/>
</xs:element>

3.3.3 Constraints on XML Representations of Element Declarations

Schema Representation Constraint: Element Declaration Representation OK
In addition to the conditions imposed on <element> element information items by the schema for schema documents: all of the following must be true:
1 default and fixed are not both present.
2 If the item's parent is not <schema>, then all of the following are true:
2.1 One of ref or name is present, but not both.
2.2 If ref is present, then all of <complexType>, <simpleType>, <key>, <keyref>, <unique>, nillable, default, fixed, form, block and type are absent, i.e. only minOccurs, maxOccurs, id and <annotation> are allowed to appear together with ref.
3 The <element> element does not have both a <simpleType> or <complexType> child and a type attribute.
4 If targetNamespace is present then all of the following are true:
4.1 name is present.
4.2 form is not present.
4.3 If the ancestor <schema> does not have a targetNamespace [attribute] or its ·actual value· is different from the ·actual value· of targetNamespace of <element>, then all of the following are true:
4.3.1 <element> has <complexType> as an ancestor
4.3.2 Let B be the {base type definition} of the Complex Type Definition corresponding to <complexType>. B's ·content model· contains, either directly, indirectly (that is, within the {particles} of a contained model group, recursively) or ·implicitly contains· an Element Declaration whose {name} and {target namespace} are the same as those of the Element Declaration corresponding to this <element>.
5 The corresponding particle and/or element declarations satisfy the conditions set out in Constraints on Element Declaration Schema Components (§3.3.6) and Constraints on Particle Schema Components (§3.9.6).
6 Every <alternative> element but the last has a test [attribute]; the last <alternative> element may have such an [attribute].

3.3.4 Element Declaration Validation Rules

When an element is ·assessed·, it is first checked against its ·governing element declaration·, if any; this in turn entails checking it against its ·governing type definition·. The second step is recursive: the element's [attributes] and [children] are ·assessed· in turn with respect to the declarations assigned to them by their parent's ·governing type definition·.

The ·governing type definition· of an element is normally the declared {type definition} associated with the ·governing element declaration·, but this may be ·overridden· using conditional type assignment in the Element Declaration or using an ·instance-specified type definition·, or both. When the element is declared with conditional type assignment, the ·selected type definition· is used as the ·governing type definition· unless ·overridden· by an ·instance-specified type definition·.

[Definition:]  The selected type definition S of an element information item E is a type definition associated with E in the following way. Let D be the ·governing element declaration· of E. Then:
1 If D has a {type table}, then S is the type ·conditionally selected· for E by the {type table} of D.
2 If D has no {type table}, then S is the declared {type definition} of D.
If E has no ·governing element declaration·, then E has no selected type definition.
Note: It is a consequence of Element Declaration Properties Correct (§3.3.6) that if D is valid, then S will be ·validly substitutable· for D's declared {type definition}, or else that S will be ·xsd:error·.
[Definition:]   Given a Type Table T and an element information item E, T conditionally selects a type S for E in the following way. The {test} expressions in T's {alternatives} are evaluated, in order, until one of the Type Alternatives ·successfully selects· a type definition for E, or until all have been tried without success. If any Type Alternative ·successfully selects· a type definition, none of the following Type Alternatives are tried. Then the type S conditionally selected for E by T is as described in the appropriate case among the following:
1 If at least one Type Alternative in T's {alternatives} ·successfully selects· a type definition for E, then S is the type definition selected by the first such Type Alternative.
2 If no Type Alternative in T's {alternatives} ·successfully selects· a type definition, then S is the {type definition} of the {default type definition} of T.
[Definition:]  An instance-specified type definition is a type definition associated with an element information item in the following way:
1 Among the element's attribute information items is one named xsi:type, that is an [attribute] whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is type.
2 The ·normalized value· of that attribute information item is a qualified name ·valid· with respect to the built-in QName simple type, as defined by String Valid (§3.16.4). (Note: it follows then that the attribute's ·actual value· can be interpreted as denoting a ·local name· and a ·namespace name·, as described in QName Interpretation (§3.17.3).)
3 The ·local name· and a ·namespace name· ·resolve· to a type definition. It is this type definition which is the instance-specified type definition.
[Definition:]  An ·instance-specified type definition· S is said to override another type definition T if and only if all of the following are true:
  1. S is the ·instance-specified type definition· on some element information item E. A ·governing element declaration· may or may not be known for E.
  2. S is ·validly substitutable· for T, subject to the blocking keywords of the {disallowed substitutions} of E's ·governing element declaration·, if any, or ·validly substitutable without limitation· for T (if no ·governing element declaration· is known).
Note:  Typically, T would be the ·governing type definition· for E if it were not overridden. (This will be the case if T was stipulated by the processor, as described in Assessing Schema-Validity (§5.2), or E has a ·governing element declaration· and T is its declared type, or T is the ·context-determined type· of E.)
[Definition:]  A type definition S is validly substitutable for another type T, subject to a set of blocking keywords K (typically drawn from the set {substitution, extension, restriction, list, union} used in the {disallowed substitutions} and {prohibited substitutions} of element declarations and type definitions), if and only if either or or

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

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

Validation Rule: Element Locally Valid (Element)
For an element information item E to be locally ·valid· with respect to an element declaration D all of the following must be true:
1 The declaration D is not ·absent·.
2 Its {abstract} is false.
3 One of the following is true:
3.1 {nillable} is false, and there is no attribute information item among the element information item's [attributes] whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is nil.
3.2 {nillable} is true and one of the following is true
3.2.1 There is no such attribute information item.
3.2.2 There is such an attribute information item, and its ·actual value· is false.
3.2.3 There is such an attribute information item, and its ·actual value· is true, and all of the following are true:
3.2.3.1 The element information item has no character or element information item [children].
3.2.3.2 There is no {value constraint} with {variety} fixed.
4 If there is an attribute information item named xsi:type among the [attributes] of E (i.e. one whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is type), then all of the following are true:
4.1 E has an ·instance-specified type definition· which is not absent.
That is, the ·instance-specified type definition· ·overrides· the ·selected type definition·.If an ·instance-specified type definition· exists and ·overrides· the ·selected type definition·, then the ·governing type definition· of E is the ·instance-specified type definition·, otherwise it is the ·selected type definition·.
5 The appropriate case among the following is true:
5.1 If the declaration D has a {value constraint}, and the item E has neither element nor character [children], and clause 3.2 has not applied, then all of the following are true:
5.1.2 The element information item with the {lexical form} of the declaration's {value constraint} used as its ·normalized value· is ·valid· with respect to the ·governing type definition· as defined by Element Locally Valid (Type) (§3.3.4).
5.2 If the declaration has no {value constraint}, or the item has either element or character [children], or clause 3.2 has applied, then all of the following are true:
5.2.1 The element information item is ·valid· with respect to the ·governing type definition· as defined by Element Locally Valid (Type) (§3.3.4).
5.2.2 If there is a {value constraint} with {variety} fixed and clause 3.2 has not applied, then all of the following are true:
5.2.2.1 The element information item has no element information item [children].
5.2.2.2 The appropriate case among the following is true:
5.2.2.2.1 If the ·governing type definition· is a Complex Type Definition whose {content type}has {variety} mixed, then the ·initial value· of the item matches the {lexical form} of the declaration's {value constraint}.
5.2.2.2.2 If the ·governing type definition· is a Simple Type Definition or a Complex Type Definition whose {content type} has {variety} simple, then the ·actual value· of the item is identical to the {value constraint}'s {value}.
6 The element information item is ·valid· with respect to each of the {identity-constraint definitions} as per Identity-constraint Satisfied (§3.11.4).
7 If the element information item is the ·validation root·, then it is ·valid· per Validation Root Valid (ID/IDREF) (§3.3.4).
Note:  The {name} and {target namespace} properties are not mentioned above because they are checked during particle ·validation·, as per Element Sequence Locally Valid (Particle) (§3.9.4.2).
Note: If an element has an xsi:type attribute whose value does not ·resolve· to a type definition, or if the type definition fails to ·override· the ·selected type definition·, then the ·selected type definition· of its ·governing element declaration· becomes the ·governing type definition·. The local validity of the element with respect to the ·governing type definition· is recorded in the [local type validity] property.
Validation Rule: Element Locally Valid (Type)
For an element information item to be locally ·valid· with respect to a type definition all of the following must be true:
1 The type definition is not ·absent·;
2 It does not have {abstract} with value true.
3 The appropriate case among the following is true:
3.1 If the type definition is a simple type definition, then all of the following are true:
3.1.1 The element information item's [attributes] are empty, excepting those whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is one of type, nil, schemaLocation or noNamespaceSchemaLocation.
3.1.2 The element information item has no element information item [children].
3.1.3 If clause 3.2 of Element Locally Valid (Element) (§3.3.4) did not apply, then the ·normalized value· is ·valid· with respect to the type definition as defined by String Valid (§3.16.4).
3.2 If the type definition is a complex type definition, then the element information item is ·valid· with respect to the type definition as per Element Locally Valid (Complex Type) (§3.4.4);
4 If the element information item has an xsi:type [attribute] (one whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is type) and does not have a ·governing element declaration·, then the ·actual value· of xsi:type ·resolves· to the type definition.
Note: Informally, this rule means that an element with an xsi:type attribute cannot be locally valid with respect to any type other than that named in the attribute.
Note:  This rule only covers the case when a ·governing element declaration· is not available. When a ·governing element declaration· is present, the same rule is checked in clause 4 of Element Locally Valid (Element) (§3.3.4).
Validation Rule: Validation Root Valid (ID/IDREF)
For an element information item which is the ·validation root· to be ·valid· all of the following must be true:
1 There is no ID/IDREF binding in the item's [ID/IDREF table] whose [binding] is the empty set.
2 There is no ID/IDREF binding in the item's [ID/IDREF table] whose [binding] has more than one member.
See ID/IDREF Table (§3.17.5) for the definition of ID/IDREF binding.
Note: 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 Outcome Tabulations (normative) (§C)) are associated with these two cases.
Note: Although this rule applies at the ·validation root·, in practice processors, particularly streaming processors, will perhaps wish to detect and signal the clause 2 case as it arises.
Note: This reconstruction of [XML 1.1]'s ID/IDREF functionality is imperfect in that if the ·validation root· 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.
[Definition:]   The governing element declaration of an element information item, in a given schema-validity ·assessment· episode, is the first of the following which applies:
1 A declaration stipulated by the processor (see Assessing Schema-Validity (§5.2)).
3 A declaration ·resolved· to by its [local name] and [namespace name], provided that none of the following is true:
  1. it is ·attributed· to a skip ·wildcard particle·
  2. the processor has stipulated a type definition for it
  3. a ·non-absent· ·context-determined type· exists for it
If none of these apply, there is no ·governing element declaration· (or, in equivalent words, it is ·absent·).
[Definition:]   The governing type definition of an element information item, in a given schema-validity ·assessment· episode, is the first of the following which applies:
1 An ·instance-specified type definition· which ·overrides· a type definition stipulated by the processor (see Assessing Schema-Validity (§5.2)).
2 A type definition stipulated by the processor (see Assessing Schema-Validity (§5.2)).
4 The ·selected type definition· of the element information item.
5 The value ·absent· if the element information item is ·skipped·.
If none of these apply, there is no ·governing type definition· (or, in equivalent words, it is ·absent·).
Validation Rule: Schema-Validity Assessment (Element)
The schema-validity assessment of an element information item depends on its ·validation· and the ·assessment· of its element information item children and associated attribute information items, if any.[Definition:]   For an element information item's schema-validity to be strictly assessed all of the following must be true:
1 One of the following is true:
1.1 All of the following are true:
1.1.1 A ·non-absent· element declaration is known for it, namely its ·governing· declaration.
1.1.2 Its ·validity· with respect to that declaration has been evaluated as per Element Locally Valid (Element) (§3.3.4).
1.1.3 If that evaluation involved the evaluation of Element Locally Valid (Type) (§3.3.4), clause 1 thereof is satisfied.
1.2 All of the following are true:
1.2.1 It does not have a ·governing element declaration·.
1.2.2 A ·non-absent· type definition is known for it, namely its ·governing type definition·
1.2.3 The element information item's ·validity· with respect to its ·governing type definition· has been evaluated as per Element Locally Valid (Type) (§3.3.4).
2 For each of the attribute information items among its [attributes], the appropriate case among the following is true:
2.1 If the attribute has a ·governing attribute declaration· , then its schema-validity is assessed with respect to that declaration, as defined in Schema-Validity Assessment (Attribute) (§3.2.4).
2.2 otherwise its schema-validity is not assessed.
3 For each of the element information items among its [children], the appropriate case among the following is true:
3.1 If the child has a ·governing element declaration· or a ·governing type definition· , then its schema-validity is assessed with respect to that declaration or type definition, as defined in Schema-Validity Assessment (Element) (§3.3.4).
3.2 If the child is ·attributed to· a skip Wildcard , then its schema-validity is not assessed.
3.3 otherwise its schema-validity is ·laxly assessed· with respect to ·xs:anyType·.
[Definition:]   If the item cannot be ·strictly assessed·, because neither clause 1.1 nor clause 1.2 above is satisfied, and the item is not ·skipped·, the element information item's schema validity must be laxly assessed by ·validating· with respect to ·xs:anyType· as per Element Locally Valid (Type) (§3.3.4) and assessing schema-validity of its [attributes] and [children] as per clause 2 and clause 3 above. If the element information item is ·skipped·, it must not be laxly assessed.

Editorial Note: Priority Feedback Request

In version 1.0 of this specification, the fallback to lax validation described in the preceding paragraph was optional, not required. The XML Schema Working Group solicits input from implementors and users of this specification as to whether this change is desirable and acceptable.

Note:  When an element information item is ·strictly assessed· or ·laxly assessed·, clause 2 above requires that all xsi: [attributes] be assessed with respect to the corresponding attribute declarations from Built-in Attribute Declarations (§3.2.7). The result of such assessment is present in the ·post-schema-validation infoset·, as defined in Attribute Declaration Information Set Contributions (§3.2.5).

3.3.5 Element Declaration Information Set Contributions

Schema Information Set Contribution: Assessment Outcome (Element)
If and only if the schema-validity of an element information item has been assessed as per Schema-Validity Assessment (Element) (§3.3.4), then in the ·post-schema-validation infoset· it has properties as follows:
PSVI Contributions for element information items
[validation context]
The nearest ancestor element information item with a [schema information] property (or this element item itself if it has such a property).
[validity]
The appropriate case among the following:
1 If it was ·strictly assessed·, then the appropriate case among the following:
1.1 If all of the following are true:
1.1.1 One of the following is true:
1.1.2 Neither its [children] nor its [attributes] contains an information item (element or attribute respectively) whose [validity] is invalid.
1.1.3 Neither its [children] nor its [attributes] contains an information item (element or attribute respectively) which is ·attributed· to a strict ·wildcard particle· and whose [validity] is notKnown.
, then valid;
1.2 otherwise invalid..
2 otherwise notKnown.
[validation attempted]
The appropriate case among the following:
1 If it was ·strictly assessed· and neither its [children] nor its [attributes] contains an information item (element or attribute respectively) whose [validation attempted] is not full, then full;
2 If it was not ·strictly assessed· and neither its [children] nor its [attributes] contains an information item (element or attribute respectively) whose [validation attempted] is not none, then none;
3 otherwise partial.
Schema Information Set Contribution: Validation Failure (Element)
If and only if the local ·validity·, as defined by Element Locally Valid (Element) (§3.3.4) above and/or Element Locally Valid (Type) (§3.3.4) below, of an element information item has been assessed, then in the ·post-schema-validation infoset· the item has a property:
PSVI Contributions for element information items
[schema error code]
The appropriate case among the following:
1 If the item is ·invalid·, then a list. Applications wishing to provide information as to the reason(s) for the ·validation· failure are encouraged to record one or more error codes (see Outcome Tabulations (normative) (§C)) herein.
2 otherwise ·absent·.
[subsequence-valid]
The appropriate case among the following:
1 If the element information item is locally ·invalid·, because unexpected attributes or elements were found among its [attributes] and [children] and clause 1 of Element Locally Valid (Complex Type) (§3.4.4) would be satisfied, if those unexpected attributes and children (those with [match information] = none) were removed, then true
2 otherwise false
[failed identity constraints]
A list of Identity-Constraint Definitions that have been checked and failed on the element information item, as defined by Identity-constraint Satisfied (§3.11.4).
Note:  If more than one identity constraint fails to be satisfied, it is ·implementation-dependent· which of the failed identity constraints are included here. As a result, processors may produce different values for this property.
[failed assertions]
A list of Assertions that have been checked and failed on the element information item, as defined by Assertion Satisfied (§3.13.4).
Note:  If more than one assertion fails to be satisfied, it is ·implementation-dependent· which of the failed assertions are included here. As a result, processors may produce different values for this property.
Schema Information Set Contribution: Element Declaration
If and only if a ·governing element declaration· is known for an element information item, then in the ·post-schema-validation infoset· the element information item has the properties:
PSVI Contributions for element information items
[element declaration]
an ·item isomorphic· to the ·governing· declaration component itself
[nil]
true if clause 3.2 of Element Locally Valid (Element) (§3.3.4) above is satisfied, otherwise false
[expected element declaration]
if the element information item is ·attributed· to an ·element particle·, then the {term} of that Particle, otherwise ·absent·
Note:  The [element declaration] either is the same as or is in the ·substitution group· of the [expected element declaration].
[declared type]
an ·item isomorphic· to the declared {type definition} of the ·governing element declaration·
[local element validity]
The appropriate case among the following:
1 If the item was ·valid· as defined by Element Locally Valid (Element) (§3.3.4), then valid
2 otherwise (the item was ·invalid· as defined by Element Locally Valid (Element) (§3.3.4)) invalid.
Schema Information Set Contribution: Element Validated by Type
If and only if and only if a ·governing type definition· is known for an element information item, then in the ·post-schema-validation infoset· the item has the properties:
PSVI Contributions for element information items
[schema normalized value]
The appropriate case among the following:
1 If clause 3.2 of Element Locally Valid (Element) (§3.3.4) above has not applied and either the ·governing type definition· is a simple type definition or its {content type} has {variety} simple, then the appropriate case among the following:
1.1 If clause 5.1 of Element Locally Valid (Element) (§3.3.4) above has applied, then the {lexical form} of the {value constraint}
1.2 If clause 5.1 of Element Locally Valid (Element) (§3.3.4) above has not applied and the the element's ·normalized value· is ·valid· with respect to the simple type definition as defined by String Valid (§3.16.4), then the ·normalized value· of the item as ·validated·
1.3 otherwise ·absent·.
2 otherwise ·absent·.
[schema actual value]
If the [schema normalized value] is not ·absent·, then the corresponding ·actual value· ; otherwise ·absent·.
[type definition]
An ·item isomorphic· to the ·governing type definition· component itself.
[type definition type]
simple or complex, depending on the ·type definition·.
[type definition namespace]
The {target namespace} of the ·type definition·.
[type definition anonymous]
true if the {name} of the ·type definition· is ·absent·, otherwise false.
[type definition name]
The {name} of the ·type definition·, if the {name} is not ·absent·. If the ·type definition·'s {name} property is ·absent·, schema processors may, but need not, provide a value unique to the definition. It is ·implementation-defined· whether a processor provides a name for such a type definition. If a processor does provide a value in this situation, the choice of what value to use is ·implementation-dependent·.
[type fallback]
A keyword indicating whether the expected type definition was unavailable and the element had a fallback type as its ·governing type definition·
[type alternative]
If the element's ·governing element declaration· does not have a {type table}, then ·absent·; otherwise the first Type Alternative that ·successfully selected· the element's ·selected type definition·, if any; otherwise the {default type definition}.
[local type validity]
The appropriate case among the following:
1 If the element information item was ·valid· as defined by Element Locally Valid (Type) (§3.3.4), then valid
2 otherwise (the item was ·invalid· as defined by Element Locally Valid (Type) (§3.3.4)) invalid.
[descendent validity]
The appropriate case among the following:
1 If neither its [children] nor its [attributes] contains an information item I (element or attribute respectively) where either I's [validity] is invalid or I is ·attributed· to a strict ·wildcard particle· and I's [validity] is notKnown , then valid;
2 otherwise invalid.
Note: The [type definition type], [type definition namespace], [type definition name], and [type definition anonymous] properties are redundant with the [type definition] property; they are defined for the convenience of implementations which wish to expose those specific properties but not the entire type definition.
Note:  When clause 5.1 of Element Locally Valid (Element) (§3.3.4) above applies and the default or fixed value constraint {value} is of type QName or NOTATION, it is ·implementation-dependent· whether ·namespace fixup· occurs; if it does not, the prefix used in the lexical representation (in [schema normalized value]) will not necessarily map to the namespace name of the value (in [schema actual value]). To reduce problems and confusion, users may prefer to ensure that the required namespace information item is present in the input infoset.
If the [schema normalized value] is not ·absent· and the ·governing type definition· is a simple type definition with {variety} union, or its {content type} has {variety} simple and {simple type definition} a simple type definition with {variety} union, then calling [Definition:]   that basic member of its transitive membership which actually ·validated· the [schema normalized value] the actual member type definition, there are four additional properties:
PSVI Contributions for element information items
[member type definition]
An ·item isomorphic· to the ·actual member type definition·
[member type definition namespace]
The {target namespace} of the ·actual member type definition·.
[member type definition anonymous]
true if the {name} of the ·actual member type definition· is ·absent·, otherwise false.
[member type definition name]
The {name} of the ·actual member type definition·, if it is not ·absent·. If it is ·absent·, schema processors may, but need not, provide a value unique to the definition. It is ·implementation-defined· whether a processor provides a name for such a type definition. If a processor does provide a value in this situation, the choice of what value to use is ·implementation-dependent·.
The first (·item isomorphic·) alternative above is provided for applications such as query processors which need access to the full range of details about an item's ·assessment·, 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.If all of the following are true:
2 One of the following is true:
2.1 the simple type definition used to validate the ·normalized value· (either the ·governing type definition· or its {simple type definition}) has {variety} list;
2.2 the simple type definition has {variety} union and the ·actual member type definition· has {variety} list;
3 the {item type definition} of the list type (from the previous clause) has {variety} union;
then there is an additional property:
PSVI Contributions for element information items
[member type definitions]
a sequence of Simple Type Definition components, with the same length as the [schema actual value], each one an ·item isomorphic· to the basic member which actually ·validated· the corresponding space-delimited substring in the [schema normalized value].
Also, if the declaration has a {value constraint}, the item has a property:
PSVI Contributions for element information items
Note that if an element is ·laxly assessed·, then the [type definition] and [member type definition] properties, or their alternatives, are based on ·xs:anyType·.
Schema Information Set Contribution: Element Default Value
If and only if the local ·validity·, as defined by Element Locally Valid (Element) (§3.3.4) above, of an element information item has been assessed, in the ·post-schema-validation infoset· the item has a property:
PSVI Contributions for element information items
[schema specified]
The appropriate case among the following:
1 If clause 5.1 of Element Locally Valid (Element) (§3.3.4) above applies, then schema.
2 otherwise infoset.

See also Match Information (§3.4.5), Identity-constraint Table (§3.11.5), Validated with Notation (§3.14.5), and Schema Information (§3.17.5), which describe other information set contributions related to element information items.

3.3.6 Constraints on Element Declaration Schema Components

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

Schema Component Constraint: Element Declaration Properties Correct
All of the following must be true:
1 The values of the properties of an element declaration are as described in the property tableau in The Element Declaration Schema Component (§3.3.1), modulo the impact of Missing Sub-components (§5.3).
2 If there is a {value constraint}, it is a valid default with respect to the declared {type definition} as defined in Element Default Valid (Immediate) (§3.3.6).
3 If there is a non-empty {substitution group affiliations} property, then {scope}'s {variety} is global.
4 If there is a non-empty {substitution group affiliations} property, the declared {type definition} of the element declaration is ·validly substitutable· for the declared {type definition} of each member of the {substitution group affiliations}, subject to the blocking keywords in the value of the {substitution group exclusions} of that member.
5 There are no circular substitution groups. That is, it is not possible to return to an element declaration by repeatedly following any member of the {substitution group affiliations} property.
6 If there is a ·non-absent· {type table}, then for each Type Alternative in the {alternatives}, the {test} property is not ·absent·.
7 If there is a ·non-absent· {type table}, then for each {type definition} T in the {alternatives}, and also for the {type definition} of the {default type definition}, one of the following is true
7.1 T is ·validly substitutable· for the declared {type definition}, subject to the blocking keywords of the element declaration's {disallowed substitutions} property.
7.2 T is the type ·xsd:error·.

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

Schema Component Constraint: Element Default Valid (Immediate)
For a Value Constraint to be a valid default with respect to a type definition the appropriate case among the following must be true:
1 If the type definition is a simple type definition or a complex type definition whose {content type} has {variety} simple type definition, then the Value Constraint is a valid default with respect to the {content type}'s {simple type definition} as defined by Simple Default Valid (§3.2.6).
2 If the type definition is a complex type definition whose {content type}'s {variety} is not simple type definition, then all of the following are true:
Schema Component Constraint: Substitution Group OK (Transitive)
For an element declaration (call it D) to be substitutable for another element declaration (call it C) subject to a blocking constraint (a subset of {substitution, extension, restriction}, the value of a {disallowed substitutions}) one of the following must be true:
1 D and C are the same element declaration.
2 All of the following are true:
2.1 The blocking constraint does not contain substitution.
2.2 There is a chain of {substitution group affiliations}s from D to C, that is, either D's {substitution group affiliations} contains C, or D's {substitution group affiliations} contains a declaration whose {substitution group affiliations} contains C, or . . .
2.3 The set of all {derivation method}s involved in the derivation of D's declared {type definition} from C's declared {type definition} does not intersect with the union of the blocking constraint, C's declared {type definition}'s {prohibited substitutions} (if C's declared {type definition} is complex, otherwise the empty set) and the {prohibited substitutions} (respectively the empty set) of any intermediate declared {type definition}s in the derivation of D's declared {type definition} from C's declared {type definition}.

[Definition:]  One element declaration is substitutable for another if together they satisfy constraint Substitution Group OK (Transitive) (§3.3.6).

[Definition:]   Every element declaration (call this HEAD) in the {element declarations} of a schema defines a substitution group, a subset of those {element declarations}. An element declaration is in the substitution group of HEAD if and only if it is ·substitutable· for HEAD.

previous sub-section next sub-section3.4 Complex Type Definitions

Complex Type Definitions provide for:

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

3.4.1 The Complex Type Definition Schema Component

A complex type definition schema component has the following properties:

Schema Component: Complex Type Definition, a kind of Type Definition
{annotations}
A sequence of Annotation components.
{name}
An xs:NCName value. Optional.
{target namespace}
An xs:anyURI value. Optional.
{base type definition}
A type definition component. Required.
{final}

A subset of {extension, restriction}.

{context}
Required if {name} is ·absent·, otherwise must be ·absent·.
{derivation method}
One of {extension, restriction}. Required.
{abstract}
An xs:boolean value. Required.
{attribute uses}
A set of Attribute Use components.
{attribute wildcard}
A Wildcard component. Optional.
{content type}
A Content Type property record. Required.
{prohibited substitutions}
A subset of {extension, restriction}.
{assertions}
A sequence of Assertion components.
Property Record: Content Type
{variety}
One of {empty, simple, element-only, mixed}. Required.
{particle}
A Particle component. Required if {variety} is element-only or mixed, otherwise must be ·absent·.
{open content}
An Open Content property record. Optional if {variety} is element-only or mixed, otherwise must be ·absent·.
{simple type definition}
A Simple Type Definition component. Required if {variety} is simple, otherwise must be ·absent·.
Property Record: Open Content
{mode}
One of {interleave, suffix}. Required.
{wildcard}
A Wildcard component. Required.

Complex type 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 ·XSDL 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 (<import>) (§4.2.4) for the use of component identifiers when importing one schema into another.

Note: The {name} of a complex type is not ipso facto the [(local) name] of the element information items ·validated· by that definition. The connection between a name and a type definition is described in Element Declarations (§3.3).

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.

The {context} property is only relevant for anonymous type definitions, for which its value is the component in which this type definition appears as the value of a property, e.g. {type definition}.

Complex types for which {abstract} is true have no valid instances and thus cannot be used in the normal way as the {type definition} for the ·validation· of element information items (if for some reason an abstract type is identified as the ·governing type definition· of an element information item, the item will invariably be invalid). It follows that such abstract types 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 declared {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}. See Element Locally Valid (Complex Type) (§3.4.4), The Wildcard Schema Component (§3.10.1) and Wildcard allows Expanded Name (§3.10.4) for formal details of attribute wildcard ·validation·.

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

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

{assertions} constrain elements and attributes to exist, not to exist, or to have specified values. Though specified as a sequence, the order among the assertions is not significant during assessment. See Assertions (§3.13).

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

3.4.2 XML Representation of Complex Type Definitions

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 {content type}with {variety} simple 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.

XML Representation Summary: complexType Element Information Item

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

Whichever alternative for the content of <complexType> is chosen, the following property mappings apply:
Complex Type Definition Schema Component
Property
Representation
 
The ·actual value· of the name [attribute] if present, otherwise ·absent·.
 
The ·actual value· of the targetNamespace [attribute] of the <schema> ancestor element information item if present, otherwise ·absent·.
 
The ·actual value· of the abstract [attribute], if present, otherwise false.
 
A set corresponding to the ·actual value· of the block [attribute], if present, otherwise on the ·actual value· of the blockDefault [attribute] of the ancestor <schema> element information item, if present, otherwise on the empty string. Call this the EBV (for effective block value). Then the value of this property is the appropriate case among the following:
1 If the EBV is the empty string, then the empty set;
2 If the EBV is #all, then {extension, restriction};
3 otherwise a set with members drawn from the set above, each being present or absent depending on whether the ·actual value· (which is a list) contains an equivalently named item.
Note: Although the blockDefault [attribute] of <schema> may include values other than restriction orextension, those values are ignored in the determination of {prohibited substitutions} for complex type definitions (they are used elsewhere).
 
As for {prohibited substitutions} above, but using the final and finalDefault [attributes] in place of the block and blockDefault [attributes].
 
If the name [attribute] is present, then ·absent·, otherwise (the parent element information item will be <element>), the Element Declaration corresponding to that parent information item.
 
A sequence whose members are Assertions drawn from the following sources, in order:
2 Assertions corresponding to all the <assert> element information items among the [children] of <complexType>, <restriction> and <extension>, if any, in order.
 
The ·annotation mapping· of the set of elements containing the <complexType>, the <openContent> [child], if present, the <attributeGroup> [children], if present, the <simpleContent> and <complexContent> [children], if present, and their <restriction> and <extension> [children], if present, and their <openContent> and <attributeGroup> [children], if present, as defined in XML Representation of Annotation Schema Components (§3.15.2).
When the <simpleContent> alternative is chosen, the following elements are relevant, and the remaining property mappings are as below. Note that either <restriction> or <extension> must be chosen as the content of <simpleContent>.

<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 | maxScale | minScale | length | minLength | maxLength | enumeration | whiteSpace | pattern)*)?, ((attribute | attributeGroup)*, anyAttribute?), assert*)
</restriction>

<extension
  base = QName
  id = ID
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, ((attribute | attributeGroup)*, anyAttribute?), assert*)
</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)) )
  notNamespace = List of (anyURI | (##targetNamespace | ##local))
  notQName = List of (QName | ##defined)
  processContents = (lax | skip | strict) : strict
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</anyAttribute>

Property
Representation
 
The type definition ·resolved· to by the ·actual value· of the base [attribute]
 
If the <restriction> alternative is chosen, then restriction, otherwise (the <extension> alternative is chosen) extension.
 

If the defaultAttributesApply [attribute] of the <complexType> element is not present or has ·actual value· true, and the <schema> ancestor has an defaultAttributes attribute, then properties {attribute uses} and {attribute wildcard} are computed as if there were an <attributeGroup> [child] with empty content and a ref [attribute] whose ·actual value· is the same as that of the defaultAttributes [attribute]. Otherwise proceed as if there were no such <attributeGroup> [child].

Then the value is a union of sets of attribute uses as follows
1 The set of attribute uses corresponding to the <attribute> [children], if any.
2 The {attribute uses} of the attribute groups ·resolved· to by the ·actual value·s of the ref [attribute] of the <attributeGroup> [children], if any.
3 If the type definition ·resolved· to by the ·actual value· of the base [attribute] is a complex type definition, the {attribute uses} of that type definition, unless the <restriction> alternative is chosen, in which case some members of that type definition's {attribute uses} must not be included, namely those whose {attribute declaration}'s {name} and {target namespace} are the same as one of the following:
3.1 the {name} and {target namespace} of the {attribute declaration} of an attribute use in the set per clause 1 or clause 2 above;
3.2 what would have been the {name} and {target namespace} of the {attribute declaration} of an attribute use in the set per clause 1 above but for the ·actual value· of the use [attribute] of the relevant <attribute> among the [children] of <restriction> being prohibited.
 
1 [Definition:]  Let the local wildcard be defined as the appropriate case among the following:
1.1 If there is an <anyAttribute> present, then a wildcard based on the ·actual value·s of its [attributes] and the <annotation> [children], exactly as for the wildcard corresponding to an <any> element as set out in XML Representation of Wildcard Schema Components (§3.10.2);
1.2 otherwise ·absent·.
2 [Definition:]  Let the complete wildcard be defined as the appropriate case among the following:
2.1 If there are no <attributeGroup> [children] corresponding to attribute groups with ·non-absent· {attribute wildcard}s, then the ·local wildcard·.
2.2 If there are one or more <attributeGroup> [children] corresponding to attribute groups with ·non-absent· {attribute wildcard}s, then the appropriate case among the following:
2.2.1 If there is an <anyAttribute> present, then a wildcard whose {process contents} and {annotations} are those of the ·local wildcard·, and whose {namespace constraint} is the wildcard intersection of the {namespace constraint} of the ·local wildcard· and 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).
2.2.2 If there is no <anyAttribute> present, then a wildcard whose properties are as follows:
The {process contents} of the first ·non-absent· {attribute wildcard} of an attribute group among the attribute groups corresponding to the <attributeGroup> [children].
The wildcard 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).
3 The value is then determined by the appropriate case among the following:
3.1 If the <restriction> alternative is chosen, then the ·complete wildcard·;
3.2 If the <extension> alternative is chosen, then
3.2.1 [Definition:]  let the base wildcard be defined as the appropriate case among the following:
3.2.1.1 If the type definition ·resolved· to by the ·actual value· of the base [attribute] is a complex type definition with an {attribute wildcard}, then that {attribute wildcard}.
3.2.1.2 otherwise ·absent·.
3.2.2 The value is then determined by the appropriate case among the following:
3.2.2.1 If the ·base wildcard· is ·non-absent· , then the appropriate case among the following:
3.2.2.1.1 If the ·complete wildcard· is ·absent·, then the ·base wildcard·.
3.2.2.1.2 otherwise a wildcard whose {process contents} and {annotations} are those of the ·complete wildcard·, and whose {namespace constraint} is the wildcard union of the {namespace constraint} of the ·complete wildcard· and of the ·base wildcard·, as defined in Attribute Wildcard Union (§3.10.6).
3.2.2.2 otherwise (the ·base wildcard· is ·absent·) the ·complete wildcard·
 
A Content Type as follows:
Property
Value
simple
the appropriate case among the following:
1 If the type definition ·resolved· to by the ·actual value· of the base [attribute] is a complex type definition whose own {content type} has {variety} simple and the <restriction> alternative is chosen, then starting from either
1.1 the simple type definition corresponding to the <simpleType> among the [children] of <restriction> if there is one;
1.2 otherwise (<restriction> has no <simpleType> among its [children]), the simple type definition which is the {simple type definition} of the {content type} of the type definition ·resolved· to by the ·actual value· of the base [attribute]
a simple type definition which restricts the simple type definition identified in clause 1.1 or clause 1.2 with a set of facet components corresponding to the appropriate element information items among the <restriction>'s [children] (i.e. those which specify facets, if any), as defined in Simple Type Restriction (Facets) (§3.16.6);
2 If the type definition ·resolved· to by the ·actual value· of the base [attribute] is a complex type definition whose own {content type} has {variety} mixed and {particle} a Particle which is ·emptiable·, as defined in Particle Emptiable (§3.9.6) and the <restriction> alternative is chosen, then starting from the simple type definition corresponding to the <simpleType> among the [children] of <restriction> (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 <restriction>'s [children] (i.e. those which specify facets, if any), as defined in Simple Type Restriction (Facets) (§3.16.6);
3 If the type definition ·resolved· to by the ·actual value· of the base [attribute] is a complex type definition (whose own {content type} must have {variety} simple, see below) and the <extension> alternative is chosen, then the {simple type definition} of the {content type} of that complex type definition;
4 otherwise (the type definition ·resolved· to by the ·actual value· of the base [attribute] is a simple type definition and the <extension> alternative is chosen), then that simple type definition.
When the <complexContent> alternative is chosen, the following elements are relevant (as are the <attributeGroup> and <anyAttribute> elements, not repeated here), and the additional property mappings are as below. Note that either <restriction> or <extension> must be chosen as the content of <complexContent>, but their content models are different in this case from the case above when they occur as children of <simpleContent>.
The property mappings below are also used in the case where the third alternative (neither <simpleContent> nor <complexContent>) is chosen. This case is understood as shorthand for complex content restricting ·xs:anyType·, and the details of the mappings must 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?, openContent?, (group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?), assert*)
</restriction>

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

<openContent
  id = ID
  mode = (none | interleave | suffix) : interleave
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, any?)
</openContent>

Property
Representation
 
The type definition ·resolved· to by the ·actual value· of the base [attribute]
 
If the <restriction> alternative is chosen, then restriction, otherwise (the <extension> alternative is chosen) extension.
 
As above for the <simpleContent> alternative.
 
As above for the <simpleContent> alternative.
 
1 [Definition:]  Let the effective mixed be the appropriate case among the following:
1.1 If the mixed [attribute] is present on <complexContent>, then its ·actual value·;
1.2 If the mixed [attribute] is present on <complexType>, then its ·actual value·;
1.3 otherwise false.
2 [Definition:]  Let the explicit content be the appropriate case among the following:
2.1 If one of the following is true
2.1.1 There is no <group>, <all>, <choice> or <sequence> among the [children];
2.1.2 There is an <all> or <sequence> among the [children] with no [children] of its own excluding <annotation>;
2.1.3 There is a <choice> among the [children] with no [children] of its own excluding <annotation> whose minOccurs [attribute] has the ·actual value· 0;
2.1.4 <group>, <all>, <choice> or <sequence> among the [children] has a maxOccurs [attribute] with an ·actual value· of 0;
, then empty
2.2 otherwise the particle corresponding to the <all>, <choice>, <group> or <sequence> among the [children].
3 [Definition:]  Let the effective content be the appropriate case among the following:
3.1 If the ·explicit content· is empty , then the appropriate case among the following:
3.1.1 If the ·effective mixed· is true, then A particle whose properties are as follows:
A model group whose {compositor} is sequence and whose {particles} is empty.
.
3.1.2 otherwise empty
3.2 otherwise the ·explicit content·.
4 [Definition:]   Let the explicit content type be the appropriate case among the following:
4.1 If the <restriction> alternative is chosen, then the appropriate case among the following:
4.1.2 otherwise a Content Type as follows:
4.2 If the <extension> alternative is chosen, then the appropriate case among the following:
4.2.1 If the ·effective content· is empty, then the {content type} of the type definition ·resolved· to by the ·actual value· of the base [attribute]
4.2.2 If the type definition ·resolved· to by the ·actual value· of the base [attribute] has a {content type} with {variety} empty or simple, then a Content Type as per clause 4.1.2 above;
4.2.3 otherwise a Content Type as follows:
Property
Value
mixed if the ·effective mixed· is true, otherwise element-only
[Definition:]  Let the base particle be the particle of the {content type} of the type definition ·resolved· to by the ·actual value· of the base [attribute]. Then the appropriate case among the following:
4.2.3.1 If the {term} of the ·base particle· has {compositor} all and the ·explicit content· is empty, then the ·base particle·.
4.2.3.2 If the {term} of the ·base particle· has {compositor} all and the {term} of the ·effective content· also has {compositor} all, then a Particle whose properties are as follows:
a model group whose {compositor} is all and whose {particles} are the {particles} of the {term} of the ·base particle· followed by the {particles} of the {term} of the ·effective content·.
4.2.3.3 otherwise
a model group whose {compositor} is sequence and whose {particles} are the ·base particle· followed by the ·effective content·.
5 [Definition:]   Let the wildcard element be the appropriate case among the following:
5.1 If the <openContent> [child] is present , then the <openContent> [child].
5.2 If the <openContent> [child] is not present, the <schema> ancestor has an <defaultOpenContent> [child], and one of the following is true
5.2.1 the {variety} of the ·explicit content type· is not empty
5.2.2 the {variety} of the ·explicit content type· is empty and the ·actual value· of the appliesToEmpty [attribute] is true
, then the <defaultOpenContent> [child] of the <schema>.
5.3 otherwise ·absent·.
6 Then the value of the property is the appropriate case among the following:
6.3 otherwise
Property
Value
The {variety} of the ·explicit content type· if it's not empty; otherwise element-only.
The {particle} of the ·explicit content type· if the {variety} of the ·explicit content type· is not empty; otherwise a Particle as follows:
Property
Value
a model group whose {compositor} is sequence and whose {particles} is empty.
An Open Content as follows:
Property
Value
The ·actual value· of the mode [attribute] of the ·wildcard element·, if present, otherwise interleave.
A wildcard corresponding to the <any> [child] of the ·wildcard element·.
Note: If the {base type definition} is a complex type definition, then the {assertions} always contain members of the {assertions} of the {base type definition}, no matter which alternatives are chosen in the XML representation, <simpleContent> or <complexContent>, <restriction> or <extension>.
Note: Aside from the simple coherence requirements enforced above, constraining type definitions identified as restrictions to actually be restrictions, that is, to ·validate· a subset of the items which are ·validated· by their base type definition, is enforced in Constraints on Complex Type Definition Schema Components (§3.4.6).
Note: The only substantive function of the value prohibited for the use attribute of an <attribute> is in establishing the correspondence between a complex type defined by restriction and its XML representation. It serves to prevent inheritance of an identically named attribute use from the {base type definition}. Such an <attribute> does not correspond to any component, and hence there is no interaction with either explicit or inherited wildcards in the operation of Complex Type Definition Validation Rules (§3.4.4) or Constraints on Complex Type Definition Schema Components (§3.4.6).

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.

Example
<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.
Example
<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 ·valid· instance thereof.
Example
<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 ·valid· instance thereof.
Example
<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:decimal"/>
</xs:complexType>
A further illustration of the abbreviated form, with the mixed attribute appearing on complexType itself.
Example
<xs:complexType name="name">
  <xs:openContent>
    <xs:any namespace="##other" processContents="skip"/>
  </xs:openContent>
  <xs:sequence>
    <xs:element name="given" type="xs:string"/>
    <xs:element name="middle" type="xs:string" minOccurs="0"/>
    <xs:element name="family" type="xs:string"/>
  </xs:sequence>
</xs:complexType>
A complex type definition that allows three explicitly declared child elements, in the specified order (but not necessarily adjacent), and furthermore allows additional elements of any name from any namespace other than the target namespace to appear anywhere in the children.
Example
To restrict away a local element declaration that ·competes· with a wildcard, use a wildcard in the derived type that explicitly disallows the element's expanded name. For example:
<xs:complexType name="computer">
 <xs:all>
  <xs:element name="CPU"/>
  <xs:element name="memory"/>
  <xs:element name="monitor"/>
  <xs:element name="speaker" minOccurs="0"/>
  <!-- Any additional information about the computer -->
  <xs:any processContents="lax"/>
 </xs:all>
</xs:complexType>

<xs:complexType name="quietComputer">
 <xs:complexContent>
  <xs:restriction base="computer">
   <xs:all>
    <xs:element name="CPU"/>
    <xs:element name="memory"/>
    <xs:element name="monitor"/>
    <!-- Any additional information about the computer -->
    <xs:any processContents="lax" notQName="speaker"/>
   </xs:all>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>
Without the specification of the notQName attribute, the restriction might or might not be valid, depending on whether the schema has a top-level declaration for speaker.
If the schema does have a top-level declaration, then the restriction is valid.
If there is no such top-level declaration, the restriction is not valid, because the base type computer maps speaker elements in the input to a ·default binding· consisting of the element declaration for speaker, while the restricted type quietComputer would map them to a ·default binding· consisting of ·xs:anyType·. The base type's ·default binding· does not subsume the restriction's ·default binding·, so the restriction fails to satisfy clause 2.2 of constraint Content type restricts (§3.4.6).

3.4.3 Constraints on XML Representations of Complex Type Definitions

Schema Representation Constraint: Complex Type Definition Representation OK
In addition to the conditions imposed on <complexType> element information items by the schema for schema documents, all of the following also apply:
1 If the <complexContent> alternative is chosen, the type definition ·resolved· to by the ·actual value· of the base [attribute] must be a complex type definition whose {content type} does not have {variety} simple;
2 If the <simpleContent> alternative is chosen, all of the following must be true:
2.1 The type definition ·resolved· to by the ·actual value· of the base [attribute] is one of the following:
2.1.1 a complex type definition whose {content type} has {variety} simple;
2.1.2 only if the <restriction> alternative is also chosen, a complex type definition whose {content type} has {variety} mixed and {particle} a Particle which is ·emptiable·, as defined in Particle Emptiable (§3.9.6);
2.1.3 only if the <extension> alternative is also chosen, a simple type definition.
2.2 If clause 2.1.2 above is satisfied, then there is a <simpleType> among the [children] of <restriction>.
2.3 The ·actual value· of the mixed [attribute] is false.
3 The corresponding complex type definition component must satisfy the conditions set out in Constraints on Complex Type Definition Schema Components (§3.4.6).
4 If clause 3.2.2.1.2 in the correspondence specification above for {attribute wildcard} is satisfied, the wildcard union must be expressible, as defined in Attribute Wildcard Union (§3.10.6).
5 If <openContent> is present and the ·actual value· of its mode [attribute] is not 'none', then there must be an <any> among the [children] of <openContent>.
6 If the <complexContent> alternative is chosen and the mixed [attribute] is present on both <complexType> and <complexContent>, then ·actual values· of those [attributes] must be the same.

3.4.4 Complex Type Definition Validation Rules

[Definition:]   Every Complex Type Definition determines a partial functional mapping from element or attribute information items (and their expanded names) to type definitions. This mapping serves as a context-determined type for elements and attributes which are allowed by the Complex Type Definition. For a given Complex Type Definition CTD and a given element information item E, the ·context-determined type· of E within CTD is the appropriate case among the following:
1 If CTD is ·xs:anyType· , then ·absent·.
2 If E's expanded name ·matches· the {name} and {target namespace} of some element declaration D which is ·contained· by CTD's content model, whether ·directly·, ·indirectly·, or ·implicitly· , then the declared {type definition} of D.
3 otherwise the ·context-determined type· of E within CTD's {base type definition}.
Note: The constraint Element Declarations Consistent (§3.8.6) ensures that even if there is more than one such declaration D, there will be just one type definition.
Note: The reference to ·implicit· containment ensures that if E has a ·governing element declaration· ·substitutable· for a declaration ·contained· by CTD's content model, a ·context-determined type· is defined for E.
Similarly: [Definition:]  Every Complex Type Definition determines a partial functional mapping from element information items (and their expanded names) to Type Tables. The Type Table identified by this mapping is the context-determined type table for elements which match a Particle contained by the content model of the Complex Type Definition. For a given Complex Type Definition T and a given element information item E, the ·context-determined type table· of E in T is as follows:
1 Let D be an Element Declaration matched by E, given by the first case among the following which applies:
1.1 If E's expanded name ·matches· some element declaration(s) ·contained· by T's content model, whether ·directly·, ·indirectly·, or ·implicitly·, then let D be any one of those Element Declarations.
1.2 If E ·matches· some wildcard particle ·contained· by T's content model, whether ·directly· or ·indirectly·, and E ·matches· some top-level Element Declaration, then let D be that top-level Element Declaration.
2 If E matches some Element Declaration as described above in clause 1, then the ·context-determined type table· of E in T is given by the appropriate case among the following:
2.1 If D has a Type Table, then the ·context-determined type table· of E in T is the Type Table of D.
2.2 If D has no Type Table, then the ·context-determined type table· of E in T is the Type Table whose {alternatives} is the empty sequence and whose {default type definition} is a Type Alternative whose {test} is ·absent· and whose {type definition} is the declared {type definition} of D.
3 If E matches no Element Declaration as described above in clause 1, then:
Note: The constraint Element Declarations Consistent (§3.8.6) ensures that even if E ·matches· more than one such declaration D, there will be just one ·context-determined type table·.
Note: It is a consequence of the definition of ·context-determined type table· that if any element E has a ·context-determined type table· in any complex type T, then E has a ·context-determined type table· in any complex type derived from T.
For a given Complex Type Definition CTD and a given attribute information item A, the ·context-determined type· of A within CTD is the appropriate case among the following:
1 If CTD is ·xs:anyType· , then ·absent·.
2 If A's expanded name matches the {name} and {target namespace} of some attribute declaration D which is the {attribute declaration} of some Attribute Use contained by CTD's {attribute uses} , then the {type definition} of D.
3 otherwise the ·context-determined type· of A within CTD's {base type definition}.
Validation Rule: Element Locally Valid (Complex Type)
For an element information item E to be locally ·valid· with respect to a complex type definition T all of the following must be true:
1 If clause 3.2 of Element Locally Valid (Element) (§3.3.4) did not apply, then the appropriate case among the following is true:
1.1 If the {content type} of T has {variety} empty, then E has no character or element information item [children].
1.2 If the {content type} of T has {variety} simple, then E has no element information item [children], and the ·normalized value· of E is ·valid· with respect to the {content type}'s {simple type definition} as defined by String Valid (§3.16.4).
1.3 If the {content type} of T has {variety} element-only, then E has no character information item [children] other than those whose [character code] is defined as a white space in [XML 1.1].
Note: It is ·implementation-defined· whether a schema processor supports the definition of white space from [XML 1.1], or that from [XML 1.0], or both.
1.4 If the {content type} of T has {variety} element-only or mixed, then the sequence of E's element information item [children], if any, taken in order, is ·valid· with respect to the {content type}, as defined in Element Sequence Locally Valid (Complex Content) (§3.4.4).
2 For each attribute information item in E's [attributes] excepting those named xsi:type, xsi:nil, xsi:schemaLocation, or xsi:noNamespaceSchemaLocation (see Built-in Attribute Declarations (§3.2.7)), the appropriate case among the following is true:
2.1 If there is among the {attribute uses} an attribute use with an {attribute declaration} whose {name} and {target namespace} ·match· the attribute information item's expanded name , then the attribute information is ·valid· with respect to that attribute use as per Attribute Locally Valid (Use) (§3.5.4). In this case the {attribute declaration} of that attribute use is the ·context-determined declaration· for the attribute information item with respect to Schema-Validity Assessment (Attribute) (§3.2.4) and Assessment Outcome (Attribute) (§3.2.5). Also the attribute information item is ·attributed to· the attribute use.
2.2 otherwise all of the following are true:
2.2.1 There is an {attribute wildcard}.
2.2.2 The attribute information item is ·valid· with respect to it as defined in Item Valid (Wildcard) (§3.10.4).
In this case the item is ·attributed to· the {attribute wildcard}.
3 The {attribute declaration} of each attribute use in the {attribute uses} whose {required} is true matches one of the attribute information items in E's [attributes] as per clause 2.1 above.
4
[Definition:]  Let a defaulted attribute be an Attribute Use for which all of the following are true:
4.1 It is a member of the complex type's {attribute uses}.
4.2 Its {required} is false.
4.5 Its {attribute declaration} does not match one of the attribute information items in E's [attributes] as per clause 2.1 above.
Then for each ·defaulted attribute·, the {lexical form} of its ·effective value constraint· is ·valid· with respect to the {type definition} of its {attribute declaration} as defined by String Valid (§3.16.4).
Note: When an {attribute wildcard} is present, this does not introduce any ambiguity with respect to how attribute information items for which an attribute use is present amongst the {attribute uses} whose name and target namespace match are ·assessed·. In such cases the attribute use always takes precedence, and the ·assessment· of such items stands or falls entirely on the basis of the attribute use and its {attribute declaration}. This follows from the details of clause 2.
5 For each element information item in E's [children] and each attribute information item in E's [attributes], if neither the ·governing type definition· nor the ·context-determined type· is ·absent·, then the ·governing type definition· is the same as, or is ·validly substitutable· for, the ·context-determined type·, ·without limitation·.
6 E is ·valid· with respect to each of the {assertions} of T as per Assertion Satisfied (§3.13.4).
7 Each element information item in the [children] of E, together with T, satisfies Conditional Type Substitutable in Restriction (§3.4.4).
Validation Rule: Element Sequence Locally Valid (Complex Content)
For a sequence S (possibly empty) of element information items to be locally ·valid· with respect to a Content Type CT, the appropriate case among the following must be true:
1 If the {open content} of CT is ·absent· , then S is ·valid· with respect to CT's {particle}, as defined in Element Sequence Locally Valid (Particle) (§3.9.4.2).
2 If the {open content} of CT has {mode} suffix , then S can be represented as two subsequences S1 and S2 (either can be empty) such that all of the following are true:
2.1 S = S1 + S2
2.2 S1 is ·valid· with respect to CT's {particle}, as defined in Element Sequence Locally Valid (Particle) (§3.9.4.2).
2.3 If S2 is not empty, let E be the first element in S2, then S1 + E does not have a ·path· in CT's {particle}
2.4 Every element in S2 is ·valid· with respect to the {wildcard} of the {open content}, as defined in Item Valid (Wildcard) (§3.10.4).
3 otherwise (the {open content} of CT has {mode} interleave) S can be represented as two subsequences S1 and S2 (either can be empty) such that all of the following are true:
3.1 S is a member of S1 × S2 (where × is the interleave operator, see All-groups (§3.8.4.1))
3.2 S1 is ·valid· with respect to CT's {particle}, as defined in Element Sequence Locally Valid (Particle) (§3.9.4.2).
3.3 For every element E in S2, let S3 be the longest prefix of S1 where members of S3 are before E in S, then S3 + E does not have a ·path· in CT's {particle}
3.4 Every element in S2 is ·valid· with respect to the {wildcard} of the {open content}, as defined in Item Valid (Wildcard) (§3.10.4).

[Definition:]   A sequence of element information items is locally valid with respect to a Content Type if and only if it satisfies Element Sequence Locally Valid (Complex Content) (§3.4.4) with respect to that Content Type.

[Definition:]   During ·validation· of an element information item against its (complex) ·governing type definition·, associations between element and attribute information items among the [children] and [attributes] on the one hand, and attribute uses, attribute wildcards, particles and open contents on the other, are established. The element or attribute information item is attributed to the corresponding component.

When the expanded name of an attribute information item ·matches· the {name} and {target namespace} of the {attribute declaration} of an Attribute Use, then the item is attributed to that attribute use. Otherwise, if the item matches an attribute wildcard, as described in Item Valid (Wildcard) (§3.10.4), then the item is attributed to that wildcard. Otherwise the item is not attributed to any component.

When a sequence S of [child] element information items are checked against the ·governing type definition·'s {content type} CT, let S1 and S2 be subsequences of S such that
  1. S is a member of S1 × S2
  2. S1 is a prefix of some element sequence that is ·locally valid· with respect to CT, as defined in Element Sequence Locally Valid (Complex Content) (§3.4.4).
  3. for every element E in S2, let S3 be the longest prefix of S1 where members of S3 are before E in S, then S3 + E is not a prefix of any element sequence that is ·locally valid· with respect to CT.
Then members of S1 that form a ·validation-path· in CT's {particle} (see Element Sequence Locally Valid (Complex Content) (§3.4.4)) are attributed to the particles they match up with in the ·validation-path·. Other members of S1 are attributed to the {open content} of CT. Members of S2 are not attributed to any component.
Note:  The above definition makes sure that ·attribution· happens even when the sequence of element information items is not ·locally valid· with respect to a Content Type. For example, if a complex type definition has the following content model:
   <xsd:sequence>
     <xsd:element name="a"/>
     <xsd:element name="b"/>
     <xsd:element name="c"/>
   </xsd:sequence>
and an input sequence
   <a/><b/><d/>
Then the element <a> is ·attributed· to the particle whose term is the "a" element declaration. Similarly, <b> is ·attributed· to the "b" particle.

[Definition:]   During ·validation·, associations between element and attribute information items among the [children] and [attributes] on the one hand, and element and attribute declarations on the other, are also established. When an item is ·attributed· to an ·element particle·, then it is associated with the declaration which is the {term} of the particle. Similarly, when an attribute information item is ·attributed to· an Attribute Use, then the item is associated with the {attribute declaration} of that Attribute Use. Such declarations are called the context-determined declarations. See clause 2.1 (in Element Locally Valid (Complex Type) (§3.4.4)) for attribute declarations, clause 2 (in Element Sequence Locally Valid (Particle) (§3.9.4.2)) for element declarations.

Validation Rule: Conditional Type Substitutable in Restriction
Given an element information item E and a complex type T, let E and T satisfy this constraint if and only if one of the following is true
1 TB does not exist (i.e. E has no ·context-determined type table· in B).
2 TT and TB both exist and at least one of the following is true
2.2 T has {derivation method} restriction, and ST is ·validly substitutable as a restriction· for SB, and E and B together satisfy this constraint.
2.3 T has {derivation method} extension, and ST is identical to SB, and E and B together satisfy this constraint.
Note: This constraint has (by clause 2.2) the effect of ensuring that if T is a restriction of B, then any type conditionally assigned to E in the context of T is a restriction of the type which would be assigned to E in the context of B.It also ensures (by clause 2.3, together with clause 3.2 of the definition of ·context-determined type table·) that if any element declaration in a complex type T has a {type table}, then the {type table}s used for same-named elements in any types derived from T will be consistent with that used in T.

Editorial Note: Priority Feedback Request

The constraint Conditional Type Substitutable in Restriction (§3.4.4) above is intended to ensure that the use of Type Tables for conditional type assignment does not violate the usual principles of complex type restriction. More specifically, if T is a complex type definition derived from its base type B by restriction, then the rule seeks to ensure that a type definition conditionally assigned by T to some child element is always derived by restriction from that assigned by B to the same child. The current design enforces this using a "run-time" rule: instead of marking T as invalid if it could possibly assign types incompatible with those assigned by B, the run-time rule accepts the schema as valid if the usual constraints on the declared {type definition}s are satisifed, without checking the details of the {type table}s. Element instances are then checked as part of validation, and any instances that would cause T (or any type in T's {base type definition} chain) to assign the incompatible types are made invalid with respect to T. This rule may prove hard to understand or implement. The Working Group is uncertain whether the current design has made the right trade-off and whether we should use a simpler but more restrictive rule. We solicit input from implementors and users of this specification as to whether the current run-time rule should be retained.

3.4.5 Complex Type Definition Information Set Contributions

Schema Information Set Contribution: Attribute Default Value
For each ·defaulted attribute·, the ·post-schema-validation infoset· has an attribute information item whose properties are as below added to the [attributes] of the element information item.In addition, if necessary ·namespace fixup· is performed on the element information item for the {attribute declaration}'s {target namespace}. The added items also have [type definition] (and [member type definition] and [member type definitions] if appropriate) properties, and their lighter-weight alternatives, as specified in Attribute Validated by Type (§3.2.5).
[Definition:]  When default values are supplied for attributes, namespace fixup may be required, to ensure that the ·post-schema-validation infoset· includes the namespace bindings needed and maintains the consistency of the namespace information in the infoset. To perform namespace fixup on an element information item E for a namespace N:
  1. If the [in-scope namespaces] of E contains a binding for N, no namespace fixup is needed; the properties of E are not changed.
  2. Otherwise, first select some prefix P which is not bound by the [in-scope namespaces] of E (the choice of prefix is ·implementation-dependent·).
  3. Add an entry to the [in-scope namespaces] of E binding P to N.
  4. Add a namespace attribute to the [namespace attributes] of E.
  5. Maintain the consistency of the information set by adjusting the namespace bindings on the descendants of E. This may be done in either of two ways:
    • Add the binding of P to N to the [in-scope namespaces] of all descendants of E, except where that binding is overridden by another binding for P.
    • Add to the [namespace attributes] of each child of E a namespace attribute which undeclares the binding for P (i.e. a namespace attribute for prefix P whose ·normalized value· is the empty string), unless that child already has a namespace declaration for prefix P. Note that this approach is possible only if [XML-Namespaces 1.1] is in use, rather than [XML-Namespaces 1.0].
    The choice between the two methods of maintaining consistency in the information set is ·implementation-dependent·.
If the ·namespace fixup· is occasioned by a defaulted attribute with a non-absent target namespace, then (as noted above), the [prefix] of the attribute information item supplied in the ·post-schema-validation infoset· is set to P.
Note:  When a default value of type QName or NOTATION is applied, it is ·implementation-dependent· whether ·namespace fixup· occurs; if it does not, the prefix used in the lexical representation (in [normalized value] or [schema normalized value]) will not necessarily map to the namespace name of the value (in [schema actual value]). To reduce problems and confusion, users may prefer to ensure that the required namespace information item is present in the input infoset.
Schema Information Set Contribution: Match Information
To allow users of the ·post-schema-validation infoset· to distinguish element information items which are ·attributed· to ·element particles· from those ·attributed· to ·wildcard particles·, if and only if the local ·validity· of an element information item has been assessed as defined by Element Locally Valid (Complex Type) (§3.4.4), then each attribute information item in its [attributes] has the following properties in the ·post-schema-validation infoset·:
PSVI Contributions for attribute information items
[attribute attribution]
The appropriate case among the following:
1 If the attribute information item is ·attributed· to an Attribute Use, then an ·item isomorphic· to the Attribute Use.
2 If the attribute information item is ·attributed· to an {attribute wildcard}, then an ·item isomorphic· to the attribute wildcard.
3 otherwise (the item is not ·attributed· to an Attribute Use or an {attribute wildcard}) ·absent·.
[match information]
A keyword indicating what kind of component the attribute information item is ·attributed· to. The appropriate case among the following:
1 If the item is ·attributed· to an Attribute Use, then attribute
2 If the item is ·attributed· to a strict {attribute wildcard}, then strict
3 If the item is ·attributed· to a lax {attribute wildcard}, then lax
4 If the item is ·attributed· to a skip {attribute wildcard}, then skip
5 otherwise (the item is not ·attributed· to an Attribute Use or an {attribute wildcard}) none
And each element information item in its [children] has the following properties in the ·post-schema-validation infoset·:
PSVI Contributions for element information items
[element attribution]
The appropriate case among the following:
1 If the element information item is ·attributed· to an ·element particle· or a ·wildcard particle·, then an ·item isomorphic· to the Particle.
2 If the item is ·attributed· to an Open Content, then an ·item isomorphic· to the Open Content.
3 otherwise (the item is not ·attributed· to a Particle or an Open Content) ·absent·.
[match information]
A keyword indicating what kind of Particle the item is ·attributed· to. The appropriate case among the following:
1 If the item is ·attributed· to an ·element particle·, then element
2 If the item is ·attributed· to a strict ·wildcard particle·, then strict
3 If the item is ·attributed· to a lax ·wildcard particle·, then lax
4 If the item is ·attributed· to a skip ·wildcard particle·, then skip
5 If the item is ·attributed· to an Open Content, then open
6 otherwise (the item is not ·attributed· to a Particle or an Open Content) none

3.4.6 Constraints on Complex Type Definition Schema Components

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

Schema Component Constraint: Complex Type Definition Properties Correct
All of the following must be true:
1 The values of the properties of a complex type definition are as described in the property tableau in The Complex Type Definition Schema Component (§3.4.1), modulo the impact of Missing Sub-components (§5.3).
2 If the {base type definition} is a simple type definition, the {derivation method} is extension.
3 There are no circular definitions, except for that of ·xs:anyType·. That is, it is possible to reach the definition of ·xs:anyType· by repeatedly following the {base type definition}.
4 No two distinct attribute declarations in the {attribute uses} have identical {name}s and {target namespace}s.
5 If the {open content} of the {content type} is not ·absent·, then the {variety} of the {content type} is either element-only or mixed.
Schema Component Constraint: Derivation Valid (Extension)
If the {derivation method} is extension, then the appropriate case among the following must be true:
1 If the {base type definition} is a complex type definition, then all of the following are true:
1.1 The {final} of the {base type definition} does not contain extension.
1.2 Its {attribute uses} is a subset of the {attribute uses} of the complex type definition itself. That is, for every attribute use (call it B) in the {attribute uses} of the {base type definition}, there is an attribute use in the {attribute uses} of the complex type definition itself whose properties, recursively, are identical to those of B, with the exception of {annotation} properties.
1.3 If it has an {attribute wildcard}, then the complex type definition also has one, and the base type definition's {attribute wildcard}'s {namespace constraint} is a subset of the complex type definition's {attribute wildcard}'s {namespace constraint}, as defined by Wildcard Subset (§3.10.6).
1.4 One of the following is true:
1.4.1 The {content type} of the {base type definition} and the {content type} of the complex type definition itself both have {variety} simple and {simple type definition} the same simple type definition.
1.4.2 The {content type} of both the {base type definition} and the complex type definition itself have {variety} empty.
1.4.3 All of the following are true:
1.4.3.1 The {content type} of the complex type definition itself has {variety} element-only or mixed.
1.4.3.2 One of the following is true:
1.4.3.2.1 The {content type} of the {base type definition} has {variety} empty.
1.4.3.2.2 All of the following are true:
1.4.3.2.2.1 Both {content type}s have {variety} mixed or both have {variety} element-only.
1.4.3.2.2.2 The {particle} of the {content type} of the complex type definition is a ·valid extension· of the {base type definition}'s {content type}'s {particle}, as defined in Particle Valid (Extension) (§3.9.6).
1.4.3.2.2.3 One of the following is true:
1.4.3.2.2.3.1 The {open content} of the {content type} of the {base type definition} (call it BOT) is ·absent·.
1.4.3.2.2.3.2 The {open content} of the {content type} of the complex type definition itself (call it EOT) has {mode} interleave.
1.4.3.2.2.3.3 Both BOT and EOT have {mode} suffix.
1.4.3.2.2.4 If neither BOT nor EOT is ·absent·, then the {namespace constraint} of BOT's {wildcard} is a subset of that of EOT's {wildcard}, as defined by Wildcard Subset (§3.10.6).
1.5 It is in principle 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 {base type definition} is ·xs:anyType·.
Note: This requirement ensures that nothing removed by a restriction is subsequently added back by an extension in an incompatible way (for example, with a conflicting type assignment or value constraint).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.
1.6 For any element or attribute information item, its ·context-determined type· within the complex type definition is ·validly substitutable· for the ·context-determined type· within the {base type definition}, ·without limitation·, if neither is ·absent·.
1.7 The {assertions} of the {base type definition} is a prefix of the {assertions} of the complex type definition itself.
2 If the {base type definition} is a simple type definition, then all of the following are true:
2.1 The {content type}'s {variety} is simple and its {simple type definition} is the same simple type definition.
2.2 The {final} of the {base type definition} does not contain extension.
.

[Definition:]   A complex type T is a valid extension of its {base type definition} if and only if T has a {derivation method} of extension and satisfies the constraint Derivation Valid (Extension) (§3.4.6).

Schema Component Constraint: Derivation Valid (Restriction, Complex)
If the {derivation method} of some complex type T is restriction all of the following must be true:
1 The {base type definition} is a complex type definition whose {final} does not contain restriction.
2 One of the following is true:
2.2 All of the following are true:
2.2.1 The {content type} of the complex type definition has {variety} simple
2.2.2 One of the following is true:
2.2.2.1 The {simple type definition} of the {content type} of the {base type definition} is a simple type definition from which the {content type}'s {simple type definition} is validly derived as defined in Type Derivation OK (Simple) (§3.16.6).
2.3 All of the following are true:
2.3.1 The {content type} of the complex type itself has {variety} empty
2.3.2 One of the following is true:
2.3.2.1 The {content type} of the {base type definition} also has {variety} empty.
2.3.2.2 The {content type} of the {base type definition} has {variety} element-only or mixed and {particle} a Particle which is ·emptiable· as defined in Particle Emptiable (§3.9.6).
2.4 All of the following are true:
2.4.1 One of the following is true:
2.4.1.1 The {content type} of the complex type definition itself has {variety} element-only and the {content type} of the {base type definition} has {variety} element-only or mixed.
2.4.1.2 The {content type} of the complex type definition itself and of the {base type definition} have {variety} mixed.
2.4.2 The {content type} of the complex type definition itself ·restricts· the {content type} of the {base type definition} as defined in Content type restricts (§3.4.6).
3 For every element information item E, if the [attributes] of E satisfy clause 2 and clause 3 of Element Locally Valid (Complex Type) (§3.4.4) with respect to T itself, then they also satisfy the same clauses with respect to the {base type definition}, and for every attribute information item A in E's [attributes], the {base type definition}'s ·default binding· for A ·subsumes· that defined by T.
4 For any element or attribute information item, its ·context-determined type· within the complex type definition is ·validly substitutable· for the ·context-determined type· within the {base type definition}, subject to the blocking keywords {extension, list, union}, if neither is ·absent·.
5 The {assertions} of the {base type definition} is a prefix of the {assertions} of the complex type definition itself.
[Definition:]   A complex type definition with {derivation method} restriction is a valid restriction of its {base type definition} if and only if the constraint Derivation Valid (Restriction, Complex) (§3.4.6) is satisfied.
Note:  Valid restriction involves both a subset relation on the set of elements valid against R and those valid against B, and a derivation relation, explicit in the type hierarchy, between the types assigned to attributes and child elements by R and those assigned to the same attributes and children by B.
Schema Component Constraint: Content type restricts
Note: Checking content-type restriction (§H) provides guidance to implementors on how to implement this constraint.
[Definition:]  A Content Type RCT (for "restriction") restricts another Content Type BCT (for "base") if and only if the appropriate case among the following is true:
1 If BCT's {variety} is empty, then RCT's {variety} is empty.
2 otherwise all of the following are true:
2.1 Every sequence of element information items which is ·locally valid· with respect to RCT is also ·locally valid· with respect to BCT.
2.2 For all sequences of element information items ES which are ·locally valid· with respect to RCT, for all elements E in ES, B's ·default binding· for E ·subsumes· that defined by R.
[Definition:]   When a sequence of element information items ES is ·locally valid· with respect to a Content Type CT or when a set of attribute information items AS satisfies clause 2 and clause 3 of Element Locally Valid (Complex Type) (§3.4.4) with respect to a Complex Type Definition, there is a (partial) functional mapping from the element information items E in the sequence ES or the attribute information items in AS to a default binding for the item, where the default binding is an Element Declaration, a pair of an Attribute Declaration and a possibly empty Value Constraint, or one of the keywords strict, lax, or skip, as follows:
1 When the item has a ·governing element declaration·, the default binding is that Element Declaration.
2 When the item has a ·governing attribute declaration· and it is ·attributed· to an Attribute Use, the default binding is the pair of that Attribute Declaration and the Attribute Use's ·effective value constraint·.
3 When the item has a ·governing attribute declaration· and it is ·attributed· to an attribute wildcard, the default binding is the pair of that Attribute Declaration and its {value constraint}.
4 When the item is ·attributed· to a strict ·wildcard particle· or attribute wildcard or an Open Content with a strict Wildcard and it does not have a ·governing element declaration· or a ·governing attribute declaration·, then the default binding is the keyword strict.
5 When the item is ·attributed· to a lax ·wildcard particle· or attribute wildcard or an Open Content with a lax Wildcard and it does not have a ·governing element declaration· or a ·governing attribute declaration·, then the default binding is the keyword lax.
6 When the item is ·attributed· to a skip ·wildcard particle· or attribute wildcard or an Open Content with a skip Wildcard then the default binding is the keyword skip.
[Definition:]  A ·default binding· G (for general) subsumes another ·default binding· S (for specific) if and only if one of the following is true
1 G is skip.
2 G is lax and S is not skip.
3 Both G and S are strict.
4 G and S are both Element Declarations and all of the following are true:
4.1 Either G has {nillable} true or S has {nillable} false.
4.2 Either G has no {value constraint}, or it is not fixed, or S has a fixed {value constraint} with the same value.
4.3 S's {identity-constraint definitions} are a superset of G's.
4.4 S disallows a superset of the substitutions that G does.
5 G and S are both pairs of an Attribute Declaration and a Value Constraint (call them GAD, SAD, GVC, and SVC respectively) and all of the following are true:
5.2 one of the following is true
5.2.1 GVC is ·absent· or has {variety} default.
5.2.2 SVC has {variety} fixed and {value} identical to GVC's.
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.
Note: To restrict away a local element declaration that ·competes· with a wildcard, use a wildcard in the derived type that explicitly disallows the element's expanded name. See the example given in XML Representation of Complex Type Definitions (§3.4.2).

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

Schema Component Constraint: Type Derivation OK (Complex)
For a complex type definition (call it D, for derived) to be validly derived from a type definition (call this B, for base) subject to the blocking keywords in a subset of {extension, restriction} all of the following must be true:
1 If B and D are not the same type definition, then the {derivation method} of D is not in the subset.
2 One of the following is true:
2.1 B and D are the same type definition.
2.3 All of the following are true:
2.3.2 The appropriate case among the following is true:
2.3.2.1 If D's {base type definition} is complex, then it is validly derived from B subject to the subset as defined by this constraint.
2.3.2.2 If D's {base type definition} is simple, then it is validly derived from B subject to the subset as defined in Type Derivation OK (Simple) (§3.16.6).
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 2.1 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 it is possible that conforming implementations will disagree as to whether components are identical.
Note: When a complex type definition S is said to be "validly derived" from a type definition T, without mention of any specific set of blocking keywords, or with the explicit phrase "without limitation", then what is meant is that S is validly derived from T, subject to the empty set of blocking keywords, i.e. without any particular limitations.

3.4.7 Built-in Complex Type Definition

There is a complex type definition for ·xs:anyType· present in every schema by definition. It has the following properties:

Property
Value
anyType
http://www.w3.org/2001/XMLSchema
restriction
The empty set
a wildcard with the following properties::
Property
Value
A Namespace Constraint with the following properties:
Property
Value
any
The empty set
The empty set
The empty set
The empty sequence
false

The outer particle of ·xs:anyType· contains a sequence with a single term:

Property
Value
a model group with the following properties:
Property
Value
sequence
a list containing one particle with the properties shown below in Inner Particle for Content Type of anyType (§3.4.7).

The inner particle of ·xs:anyType· contains a wildcard which matches any element:

Property
Value
unbounded
a wildcard with the following properties:
Property
Value
A Namespace Constraint with the following properties:
Property
Value
any
The empty set
The empty set
Note: 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. rational) and utility (e.g. array) type definitions. In particular, there is a text 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: http://www.w3.org/2001/03/XMLSchema/TypeLibrary.xsd.

previous sub-section next sub-section3.5 Attribute Uses

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.

Example
<xs:complexType>
 . . .
 <xs:attribute ref="xml:lang" use="required"/>
 <xs:attribute ref="xml:space" default="preserve"/>
 <xs:attribute name="version" type="xs:decimal" fixed="1.0"/>
</xs:complexType>
     
XML representations which all involve attribute uses, illustrating some of the possibilities for controlling occurrence.

3.5.1 The Attribute Use Schema Component

The attribute use schema component has the following properties:

Schema Component: Attribute Use, a kind of Annotated Component
{annotations}
A sequence of Annotation components.
{required}
An xs:boolean value. Required.
{attribute declaration}
An Attribute Declaration component. Required.
{value constraint}
A Value Constraint property record. Optional.
Property Record: Value Constraint
{variety}
One of {default, fixed}. Required.
{value}
An ·actual value·. Required.
{lexical form}
A character string. Required.

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

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

3.5.2 XML Representation of Attribute Use Components

Attribute uses correspond to all uses of <attribute> which allow a use attribute. These in turn correspond to two components in each case, an attribute use and its {attribute declaration} (although note the latter is not new when the attribute use is a reference to a top-level attribute declaration). The appropriate mapping is described in XML Representation of Attribute Declaration Schema Components (§3.2.2).

3.5.3 Constraints on XML Representations of Attribute Uses

None as such.

3.5.4 Attribute Use Validation Rules

[Definition:]   The effective value constraint of an attribute use is its {value constraint}, if present, otherwise its {attribute declaration}'s {value constraint}, if present, otherwise the effective value constraint is ·absent·.

Validation Rule: Attribute Locally Valid (Use)
The item's ·actual value· matches the {value} of the {value constraint}, if it is present and its {variety} is fixed.For an attribute information item to be ·valid· with respect to an attribute use its ·actual value· must be identical to the {value} of the attribute use's {value constraint}, if it is present and has {variety} fixed.

3.5.5 Attribute Use Information Set Contributions

None as such.

3.5.6 Constraints on Attribute Use Schema Components

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

Schema Component Constraint: Attribute Use Correct
All of the following must be true:
1 The values of the properties of an attribute use are as described in the property tableau in The Attribute Use Schema Component (§3.5.1), modulo the impact of Missing Sub-components (§5.3).
2 If the {value constraint} is not ·absent·, then it is a valid default with respect to the {attribute declaration}'s {type definition} as defined in Simple Default Valid (§3.2.6).
3 If the {attribute declaration} has a {value constraint} with {variety} fixed and the attribute use itself has a {value constraint}, then the {value constraint} on the attribute use also has {variety} fixed and its {value} is identical to the {value} of the {attribute declaration}'s {value constraint}.

previous sub-section next sub-section3.6 Attribute Group Definitions

A schema can name a group of attribute declarations so that they can 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>).

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

3.6.1 The Attribute Group Definition Schema Component

The attribute group definition schema component has the following properties:

Schema Component: Attribute Group Definition, a kind of Annotated Component
{annotations}
A sequence of Annotation components.
{name}
An xs:NCName value. Required.
{target namespace}
An xs:anyURI value. Optional.
{attribute uses}
A set of Attribute Use components.
{attribute wildcard}
A Wildcard component. Optional.

Attribute groups are identified by their {name} and {target namespace}; attribute group identities must be unique within an ·XSDL schema·. See References to schema components across namespaces (<import>) (§4.2.4) for the use of component identifiers when importing one schema into another.

{attribute uses} is a set attribute uses, allowing for local specification of occurrence and default or fixed values.

{attribute wildcard} provides for an attribute wildcard to be included in an attribute group. See above under Complex Type Definitions (§3.4) for the interpretation of attribute wildcards during ·validation·.

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

3.6.2 XML Representation of Attribute Group Definition Schema Components

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:

XML Representation Summary: attributeGroup Element Information Item

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

When an <attributeGroup> appears as a daughter of <schema> or <redefine>, it corresponds to an attribute group definition as below. When it appears as a daughter of <complexType> or <attributeGroup>, it does not correspond to any component as such.
Attribute Group Definition Schema Component
Property
Representation
 
 
The ·actual value· of the targetNamespace [attribute] of the ancestor schema element information item.
 
The union of the set of attribute uses corresponding to the <attribute> [children], if any, with the {attribute uses} of the attribute groups ·resolved· to by the ·actual value·s of the ref [attribute] of the <attributeGroup> [children], if any.
 
 
Note:  It is a consequence of this rule and the rule in XML Representation of Complex Type Definitions (§3.4.2) that any annotations specified in attribute group references are included in the sequence of Annotations of the enclosing Complex Type Definition or Attribute Group Definition components.

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.

3.6.3 Constraints on XML Representations of Attribute Group Definitions

Schema Representation Constraint: Attribute Group Definition Representation OK
In addition to the conditions imposed on <attributeGroup> element information items by the schema for schema documents, all of the following also apply:
1 The corresponding attribute group definition, if any, must satisfy the conditions set out in Constraints on Attribute Group Definition Schema Components (§3.6.6).
2 Circular group reference is disallowed outside <redefine>. That is, unless this element information item's parent is <redefine>, then among the [children], if any, there must not be an <attributeGroup> with ref [attribute] which ·resolves· to the component corresponding to this <attributeGroup>. Indirect circularity is also ruled out. That is, when QName resolution (Schema Document) (§3.17.3) is applied to a ·QName· arising from any <attributeGroup>s with a ref [attribute] among the [children], it must not be the case that a ·QName· is encountered at any depth which ·resolves· to the component corresponding to this <attributeGroup>.

3.6.4 Attribute Group Definition Validation Rules

None as such.

3.6.5 Attribute Group Definition Information Set Contributions

None as such.

3.6.6 Constraints on Attribute Group Definition Schema Components

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

Schema Component Constraint: Attribute Group Definition Properties Correct
All of the following must be true:
1 The values of the properties of an attribute group definition are as described in the property tableau in The Attribute Group Definition Schema Component (§3.6.1), modulo the impact of Missing Sub-components (§5.3);
2 No two distinct members of the {attribute uses} have {attribute declaration}s both of whose {name}s match and whose {target namespace}s are identical.

previous sub-section next sub-section3.7 Model Group Definitions

A model group definition associates a name and optional annotations with a Model Group. 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.

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

3.7.1 The Model Group Definition Schema Component

The model group definition schema component has the following properties:

Schema Component: Model Group Definition, a kind of Annotated Component
{annotations}
A sequence of Annotation components.
{name}
An xs:NCName value. Required.
{target namespace}
An xs:anyURI value. Optional.
{model group}
A Model Group component. Required.

Model group definitions are identified by their {name} and {target namespace}; model group identities must be unique within an ·XSDL schema·. See References to schema components across namespaces (<import>) (§4.2.4) for the use of component identifiers when importing one schema into another.

Model group definitions per se do not participate in ·validation·, but the {term} of a particle may correspond in whole or in part to a model group from a model group definition.

{model group} is the Model Group for which the model group definition provides a name.

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

3.7.2 XML Representation of Model Group Definition Schema Components

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:

XML Representation Summary: group Element Information Item

<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 name [attribute] (in which case the item will have <schema> or <redefine> as parent), then the item corresponds to a model group definition component with properties as follows:
Model Group Definition Schema Component
Property
Representation
 
 
The ·actual value· of the targetNamespace [attribute] of the ancestor schema element information item.
 
A model group which is the {term} of a particle corresponding to the <all>, <choice> or <sequence> among the [children] (there must be one).
 
Otherwise, the item will have a ref [attribute], in which case it corresponds to a particle component with properties as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all):
Particle Schema Component
Property
Representation
 
The ·actual value· of the minOccurs [attribute], if present, otherwise 1.
 
unbounded, if the maxOccurs [attribute] equals unbounded, otherwise the ·actual value· of the maxOccurs [attribute], if present, otherwise 1.
 
The {model group} of the model group definition ·resolved· to by the ·actual value· of the ref [attribute]
 

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 schema documents 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> must 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).

3.7.3 Constraints on XML Representations of Model Group Definitions

Schema Representation Constraint: Model Group Definition Representation OK
In addition to the conditions imposed on <group> element information items by the schema for schema documents, the corresponding model group definition, if any, must satisfy the conditions set out in Constraints on Model Group Schema Components (§3.8.6).

3.7.4 Model Group Definition Validation Rules

None as such.

3.7.5 Model Group Definition Information Set Contributions

None as such.

3.7.6 Constraints on Model Group Definition Schema Components

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

Schema Component Constraint: Model Group Definition Properties Correct
The values of the properties of a model group definition must be as described in the property tableau in The Model Group Definition Schema Component (§3.7.1), modulo the impact of Missing Sub-components (§5.3).

previous sub-section next sub-section3.8 Model Groups

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.16)), 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. [Definition:]  A model group directly contains the particles in the value of its {particles} property. [Definition:]  A model group indirectly contains the particles, groups, wildcards, and element declarations which are ·contained· by the particles it ·directly contains·. [Definition:]  A model group contains the components which it either ·directly contains· or ·indirectly contains·.

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

3.8.1 The Model Group Schema Component

The model group schema component has the following properties:

Schema Component: Model Group, a kind of Term
{annotations}
A sequence of Annotation components.
{compositor}
One of {all, choice, sequence}. Required.
{particles}
A sequence of Particle components.
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.15) for information on the role of the {annotations} property.

3.8.2 XML Representation of Model Group Schema Components

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:

XML Representation Summary: all Element Information Item

<all
  id = ID
  maxOccurs = 1 : 1
  minOccurs = (0 | 1) : 1
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, ( | element | any)*)
</all>

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

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

Each of the above items corresponds to a particle containing a model group, with properties as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all):
Particle Schema Component
Property
Representation
 
The ·actual value· of the minOccurs [attribute], if present, otherwise 1.
 
unbounded, if the maxOccurs [attribute] equals unbounded, otherwise the ·actual value· of the maxOccurs [attribute], if present, otherwise 1.
 
A model group as given below:
 
The same annotations as the {annotations} of the model group. See below.
Model Group Schema Component
Property
Representation
 
One of all, choice, sequence depending on the element information item.
 
A sequence of particles corresponding to all the <all>, <choice>, <sequence>, <any>, <group> or <element> items among the [children], in order.
 

3.8.3 Constraints on XML Representations of Model Groups

Schema Representation Constraint: Model Group Representation OK
In addition to the conditions imposed on <all>, <choice> and <sequence> element information items by the schema for schema documents, the corresponding particle and model group must satisfy the conditions set out in Constraints on Model Group Schema Components (§3.8.6) and Constraints on Particle Schema Components (§3.9.6).

3.8.4 Model Group Validation Rules

In order to define the validation rules for model groups clearly, it will be useful to define some basic terminology; this is done in the next two sections, before the validation rules themselves are formulated.

3.8.4.1 Language Recognition by Groups

Each model group M denotes a language L(M), whose members are the sequences of element information items ·accepted· by M.

Within L(M) a smaller language V(M) can be identified, which is of particular importance for schema-validity assessment. The difference between the two languages is that V(M) enforces some constraints which are ignored in the definition of L(M). Informally L(M) is the set of sequences which are accepted by a model group if no account is taken of the schema component constraint Unique Particle Attribution (§3.8.6) or the related provisions in the validation rules which specify how to choose a unique ·path· in a non-deterministic content model. By contrast, V(M) takes account of those constraints and includes only the sequences which are ·locally valid· against M. For all model groups M, V(M) is a subset of L(M). L(M) and related concepts are described in this section; V(M) is described in the next section, Principles of Validation against Groups (§3.8.4.2).

[Definition:]  When a sequence S of element information items is checked against a model group M, the sequence of ·basic particles· which the items of S match, in order, is a path of S in M. For a given S and P, the path of S in P is not necessarily unique. Detailed rules for the matching, and thus for the construction of paths, are given in Language Recognition by Groups (§3.8.4.1) and Principles of Validation against Particles (§3.9.4.1). Not every sequence has a path in every content model, but every sequence accepted by the content model does have a path. [Definition:]  For a content model M and a sequence S in L(M), the path of S in M is a complete path; prefixes of complete paths which are themselves not complete paths are incomplete paths. For example, in the content model

   <xsd:sequence>
    <xsd:element name="a"/>
    <xsd:element name="b"/>
    <xsd:element name="c"/>
   </xsd:sequence>

the sequences (<a/><b/><c/>) and (<a/><b/>) have ·paths· (the first a ·complete path· and the second an ·incomplete path·), but the sequences (<a/><b/><c/><d/>) and (<a/><x/>) do not have paths.

Note: It is possible, but unusual, for a content model to have some paths which are neither complete paths, nor prefixes of complete paths. For example, the content model
   <xsd:sequence>
    <xsd:element name="a"/>
    <xsd:element name="b"/>
    <xsd:choice/>
   </xsd:sequence>
accepts no sequences because the empty choice recognizes no input sequences. But the sequences (</a>) and (</a><b/>) have paths in the content model.

The definitions of L(M) and ·paths· in M, when M is a ·basic term· or a ·basic particle·, are given in Principles of Validation against Particles (§3.9.4.1). The definitions for groups are given below.

3.8.4.1.1 Sequences

This section defines L(M), the set of ·paths· in M, and V(M), if M is a sequence group.

If M is a Model Group, and the {compositor} of M is sequence, and the {particles} of M is the sequence P1, P2, ..., Pn, then L(M) is the set of sequences S = S1 + S2 + ... + Sn (taking "+" as the concatenation operator), where Si is in L(Pi) for 0 < in. The sequence of sequences S1, S2, ..., Sn is a ·partition· of S. Less formally, when M is a sequence of P1, P2, ... Pn, then L(M) is the set of sequences formed by taking one sequence which is accepted by P1, then one accepted by P2, and so on, up through Pn, and then concatenating them together in order.

[Definition:] A partition of a sequence is a sequence of sub-sequences, some or all of which may be empty, such that concatenating all the sub-sequences yields the original sequence.

When M is a sequence group and S is a sequence of input items, the set of ·paths· of S in M is the set of all paths Q = Q1 + Q2 + ... + Qj, where
  • jn, and
  • S = S1 + S2 + ... + Sj (i.e. S1, S2, ..., Sj is a ·partition· of S), and
  • Si is in L(Pi) for 0 < i < j, and
  • Qi is a ·path· of Si in Pi for 0 < ij.
Example
By this definition, some sequences which do not satisfy the entire content model nevertheless have ·paths· in a content model. For example, given the content model P
   <xsd:sequence>
    <xsd:element name="a"/>
    <xsd:element name="b"/>
    <xsd:element name="c"/>
   </xsd:sequence>
and an input sequence S
<a/><b/>
where n = 3, j = 2, then S1 is (<a/>), S2 is (<b/>), and S has a ·path· in P, even though S is not in L(P). The ·path· has two items, first the Particle for the a element, then the Particle for the b element.

When M is a sequence group, the set V(M) (the set of sequences ·locally valid· against M) is the set of sequences S which are in L(M) and which have a ·validation-path· in M. Informally, V(M) contains those sequences which are accepted by M and for which no element information item is ever ·attributed to· a ·wildcard particle· if it can, in context, instead be ·attributed to· an ·element particle·. There will invariably be a ·partition· of S whose members are ·locally valid· against the sub-sequences of P.

Note: For sequences with more than one ·path· in M, the ·attributions· of the ·validation-path· are used in validation and for determining the contents of the ·post-schema-validation infoset·. For example, if M is
  <xsd:sequence>
   <xsd:any minOccurs="0"/>
   <xsd:element name="a" minOccurs="0"/>
  </xsd:sequence>
then the sequence (<a/>) has two ·paths· in M, one containing just the ·wildcard particle· and the other containing just the ·element particle·. It is the latter which is a ·validation-path· and which determines which Particle the item in the input is ·attributed to·.
Note: There are model groups for which some members of L(M) are not in V(M). For example, if M is
  <xsd:sequence>
   <xsd:any minOccurs="0"/>
   <xsd:element name="a"/>
  </xsd:sequence>
then the sequence (<a/><a/>) is in L(M), but not in V(M), because the validation rules require that the first a be ·attributed to· the ·wildcard particle·. In a ·validation-path· the initial a will invariably be ·attributed to· the ·element particle·, and so no sequence with an initial a can be ·locally valid· against this model group.
3.8.4.1.2 Choices

This section defines L(M), the set of ·paths· in M, and V(M), if M is a choice group.

When the {compositor} of M is choice, and the {particles} of M is the sequence P1, P2, ..., Pn, then L(M) is L(P1) ∪ L(P2) ∪ ... ∪ L(Pn), and the set of ·paths· of S in P is the set Q = Q1Q2 ∪ ... ∪ Qn, where Qi is the set of ·paths· of S in Pi, for 0 < in. Less formally, when M is a choice of P1, P2, ... Pn, then L(M) contains any sequence accepted by any of the particles P1, P2, ... Pn, and any ·path· of S in any of the particles P1, P2, ... Pn is a ·path· of S in P.

The set V(M) (the set of sequences ·locally valid· against M) is the set of sequences S which are in L(M) and which have a ·validation-path· in M. In effect, this means that if one of the choices in M ·attributes· an initial element information item to a ·wildcard particle·, and another ·attributes· the same item to an ·element particle·, then the latter choice is used for validation.

Note: For example, if M is
  <xsd:choice>
   <xsd:any/>
   <xsd:element name="a"/>
  </xsd:choice>
then the ·validation-path· for the sequence (<a/>) contains just the ·element particle· and it is to the ·element particle· that the input element will be ·attributed·; the alternate ·path· containing just the ·wildcard particle· is not relevant for validation as defined in this specification.
3.8.4.1.3 All-groups

This section defines L(M), the set of ·paths· in M, and V(M), if M is an all-group.

When the {compositor} of M is all, and the {particles} of M is the sequence P1, P2, ..., Pn, then L(M) is the set of sequences S = S1 × S2 × ... × Sn (taking "×" as the interleave operator), where for 0 < in, Si is in L(Pi). The set of sequences {S1, S2, ..., Sn} is a ·grouping· of S. The set of ·paths· of S in P is the set of all ·paths· Q = Q1 × Q2 × ... × Qn, where Qi is a ·path· of Si in Pi, for 0 < in.

Less formally, when M is an all-group of P1, P2, ... Pn, then L(M) is the set of sequences formed by taking one sequence which is accepted by P1, then one accepted by P2, and so on, up through Pn, and then interleaving them together. Equivalently, L(M) is the set of sequences S such that the set {S1, S2, ..., Sn} is a ·grouping· of S, and for 0 < in, Si is in L(Pi).

[Definition:] A grouping of a sequence is a set of sub-sequences, some or all of which may be empty, such that each member of the original sequence appears once and only once in one of the sub-sequences and all members of all sub-sequences are in the original sequence.

For example, given the content model P
  <xsd:all>
   <xsd:element name="a" minOccurs="0" maxOccurs="5">
   <xsd:element name="b" minOccurs="1" maxOccurs="1">
   <xsd:element name="c" minOccurs="0" maxOccurs="5">
   </xsd:element>
  </xsd:all>
and an input sequence S
<a/><b/><a/>
where n = 3, then S1 is (<a/><a/>), S2 is (<b/>), and the ·path· of S in P is the sequence containing first the Particle for the a element, then the Particle for the b element, then once more the Particle for the a element.

The set V(M) (the set of sequences ·locally valid· against M) is the set of sequences S which are in L(M) and which have a ·validation-path· in M. In effect, this means that if one of the Particles in M ·attributes· an element information item to a ·wildcard particle·, and a ·competing· Particle ·attributes· the same item to an ·element particle·, then the ·element particle· is used for validation.

Note: For example, if M is
  <xsd:all>
   <xsd:any/>
   <xsd:element name="a"/>
  </xsd:all>
then M accepts sequences of length two, containing one a element and one other element. The other element can be anything at all, including a second a element. After the first a the ·element particle· accepts no more elements and so no longer ·competes· with the ·wildcard particle·. So if the sequence (<a/><a/>) is checked against M, in the ·validation-path· the first a element will be ·attributed to· the ·element particle· and the second to the ·wildcard particle·. If the intention is not to allow the second a, use a wildcard that explicitly disallows it. That is,
  <xsd:all>
   <xsd:any notQName="a"/>
   <xsd:element name="a"/>
  </xsd:all>
Now the sequence (<a/><a/>) is not accepted by the particle.
3.8.4.1.4 Multiple Paths in Groups

It is possible for a given sequence of element information items to have multiple ·paths· in a given model group M; this is the case, for example, when M is ambiguous, as for example

  <xsd:choice>
   <xsd:sequence>
    <xsd:element ref="my:a" maxOccurs="unbounded"/>
    <xsd:element ref="my:b"/>
   </xsd:sequence>
   <xsd:sequence>
    <xsd:element ref="my:a"/>
    <xsd:element ref="my:b" maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:choice>

which can match the sequence (<a/><b/>) in more than one way. It may also be the case with unambiguous model groups, if they do not correspond to a deterministic expression (as it is termed in [XML 1.1]) or a "1-unambiguous" expression, as it is defined by [One-Unambiguous Regular Languages]. For example,

  <xsd:sequence>
   <xsd:element name="a" minOccurs="0"/>
   <xsd:element name="a"/>
  </xsd:sequence>
Note: Because these model groups do not obey the constraint Unique Particle Attribution (§3.8.6), they cannot appear in a valid schema.
3.8.4.2 Principles of Validation against Groups

As noted above, each model group M denotes a language L(M), whose members are sequences of element information items. Each member of L(M) has one or more ·paths· in M, as do other sequences of element information items.

By imposing conditions on ·paths· in a model group M it is possible to identify a set of ·validation-paths· in M, such that if M is a model group which obeys the Unique Particle Attribution (§3.8.6) constraint, then any sequence S has at most one ·validation-path· in M. The language V(M) can then be defined as the set of sequences which have ·validation-paths· in M.

[Definition:]  Two Particles P1 and P2 contained in some Particle P compete with each other if and only if some sequence S of element information items has two ·paths· in P which are identical except that one path has P1 as its last item and the other has P2.

For example, in the content model

  <xsd:sequence>
   <xsd:element name="a"/>
   <xsd:choice>
    <xsd:element name="b"/>
    <xsd:any/>
   </xsd:choice>
  </xsd:sequence>

the sequence (<a/><b/>) has two paths, one (Q1) consisting of the Particle whose {term} is the declaration for a followed by the Particle whose {term} is the declaration for b, and a second (Q2) consisting of the Particle whose {term} is the declaration for a followed by the Particle whose {term} is the wildcard. The sequences Q1 and Q2 are identical except for their last items, and so the two Particles which are the last items of Q1 and Q2 are said to ·compete· with each other.

By contrast, in the content model
  <xsd:choice>
   <xsd:sequence>
    <xsd:element name="a"/>
    <xsd:element name="b"/>
   </xsd:sequence>
   <xsd:sequence>
    <xsd:element name="c"/>
    <xsd:any/>
   </xsd:sequence>
  </xsd:choice>
the Particles for b and the wildcard do not ·compete·, because there is no pair of ·paths· in P which differ only in one having the ·element particle· for b and the other having the ·wildcard particle·.

[Definition:] Two (or more) ·paths· of a sequence S in a Particle P are competing paths if and only if they are identical except for their final items, which differ.

[Definition:] For any sequence S of element information items and any particle P, a ·path· of S in P is a validation-path if and only if for each prefix of the ·path· which ends with a ·wildcard particle·, the corresponding prefix of S has no ·competing path· which ends with an ·element particle·.

Note: It is a consequence of the definition of ·validation-path· that for any content model M which obeys constraint Unique Particle Attribution (§3.8.6) and for any sequence S of element information items, S has at most one ·validation-path· in M.

[Definition:] A sequence S of element information items is locally valid against a particle P if and only if S has a ·validation-path· in P. The set of all such sequences is written V(P).

3.8.4.3 Validation Rules
Validation Rule: Element Sequence Valid
For a sequence S (possibly empty) of element information items to be locally ·valid· with respect to a model group M, S must be in V(M).
Note: It is possible to define groups whose {particles} is empty. When a choice-group M has an empty {particles} property, then L(M) is the empty set. When M is a sequence- or all-group with an empty {particles} property, then L(M) is the set containing the empty (zero-length) sequence.

3.8.5 Model Group Information Set Contributions

None as such.

3.8.6 Constraints on Model Group Schema Components

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

Schema Component Constraint: Model Group Correct
All of the following must be true:
1 The values of the properties of a model group are as described in the property tableau in The Model Group Schema Component (§3.8.1), modulo the impact of Missing Sub-components (§5.3).
2 There are no circular groups. That is, within the {particles} of a group there is no particle at any depth whose {term} is the group itself.
Schema Component Constraint: All Group Limited
When a model group has {compositor} all, then all of the following must be true:
1 It appears only as the value of one or both of the following properties:
1.1 the {model group} property of a model group definition.
1.2 the {term} property of a Particle with {max occurs}=1which is the {particle} of the {content type} of a complex type definition.
Schema Component Constraint: Element Declarations Consistent
If the {particles} contains, either directly, indirectly (that is, within the {particles} of a contained model group, recursively), or ·implicitly·, two or more element declaration particles with the same {name} and {target namespace}, then all their type definitions must be the same top-level definition, that is, all of the following must be true:
1 All their declared {type definition}s have a ·non-absent· {name}.
2 All their declared {type definition}s have the same {name}.
3 All their declared {type definition}s have the same {target namespace}.
4 All their {type table}s are either all ·absent· or else all are present and have the same sequence of {alternatives} and the same {default type definition}.
If the {particles} contains, either directly, indirectly (that is, within the {particles} of a contained model group, recursively), or ·implicitly·, both one or more element declaration particles with the same {name} and {target namespace} and one or more ·wildcard particles· which ·match· the same expanded name as the element declarations, then the {type table}s of the element declarations and the {type table} of any top-level element declaration with the same {name} and {target namespace} must either all be ·absent· or else all be present and have the same sequence of {alternatives} and the same {default type definition}.[Definition:]  A list of particles implicitly contains an element declaration if and only if a member of the list contains that element declaration in its ·substitution group·.

[Definition:]   An element particle is a Particle whose {term} is an Element Declaration. [Definition:]   A wildcard particle is a Particle whose {term} is a Wildcard. Wildcard particles may be referred to as "strict", "lax", or "skip" particles, depending on the {process contents} property of their {term}.

Schema Component Constraint: Unique Particle Attribution
A content model must not contain two ·element particles· which ·compete· with each other, nor two ·wildcard particles· which ·compete· with each other.
Note: Content models in which an ·element particle· and a ·wildcard particle· ·compete· with each other are not prohibited. In such cases, the Element Declaration is chosen; see the definitions of ·attribution· and ·validation-path·.
Note: This constraint reconstructs for XSDL the equivalent constraints of [XML 1.1] and SGML. See Analysis of the Unique Particle Attribution Constraint (non-normative) (§L) 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.
Note: It is a consequence of Unique Particle Attribution (§3.8.6), together with the definition of ·validation-path·, that any sequence S of element information items has at most one ·validation-path· in any particle P. This means in turn that each item in S is attributed to at most one particle in P. No item can match more than one Wildcard or more than one Element Declaration (because no two ·wildcard particles· and no two ·element particles· may ·compete·), and if an item matches both a ·wildcard particle· and an ·element particle·, it is ·attributed· by the rules for ·validation-paths· to the ·element particle·.
Note: Because locally-scoped element declarations sometimes have and sometimes do not have a {target namespace}, the scope of declarations is not relevant to enforcing either the Unique Particle Attribution (§3.8.6) constraint or the Element Declarations Consistent (§3.8.6) constraint.

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

Schema Component Constraint: Effective Total Range (all and sequence)
The effective total range of a particle whose {term} is a group whose {compositor} is all or sequence 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}).
Schema Component Constraint: Effective Total Range (choice)
The effective total range of a particle whose {term} is a group whose {compositor} is choice 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}).

previous sub-section next sub-section3.9 Particles

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

When an element is validated against a complex type, its sequence of child elements is checked against the content model of the complex type and the children are ·attributed to· to Particles of the content model. The attribution of items to Particles determines the calculation of the items' ·context-determined declarations· and thus partially determines the ·governing element declarations· for the children: when an element information item is ·attributed to· an ·element particle·, that Particle's Element Declaration, or an Element Declaration ·substitutable· for it, becomes the item's ·context-determined declaration· and thus normally its ·governing element declaration·; when the item is ·attributed to· a ·wildcard particle·, the ·governing element declaration· depends on the {process contents} property of the wildcard and on QName resolution (Instance) (§3.17.4).

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

3.9.1 The Particle Schema Component

The particle schema component has the following properties:

Schema Component: Particle, a kind of Component
{min occurs}
An xs:nonNegativeInteger value. Required.
{max occurs}
Either a positive integer or unbounded. Required.
{term}
A Term component. Required.
{annotations}
A sequence of Annotation components.

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

[Definition:]  A particle directly contains the component which is the value of its {term} property. [Definition:]  A particle indirectly contains the particles, groups, wildcards, and element declarations which are contained by the value of its {term} property. [Definition:]  A particle contains the components which it either ·directly contains· or ·indirectly contains·.

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

3.9.2 XML Representation of Particle Components

Particles correspond to all three elements (<element> not immediately within <schema>, <group> not immediately within <schema> and <any>) which allow minOccurs and maxOccurs attributes. These in turn correspond to two components in each case, a particle and its {term}. The appropriate mapping is described in XML Representation of Element Declaration Schema Components (§3.3.2), XML Representation of Model Group Schema Components (§3.8.2) and XML Representation of Wildcard Schema Components (§3.10.2) respectively.

3.9.3 Constraints on XML Representations of Particles

None as such.

3.9.4 Particle Validation Rules

3.9.4.1 Principles of Validation against Particles

Every particle P ·recognizes· some language L(P). When {min occurs} and {max occurs} of P are both 1, L(P) is the language of P's {term}. The following section (Language Recognition for Repetitions (§3.9.4.1)) describes how more complicated counts are handled.

3.9.4.1.1 Language Recognition for Repetitions

When {min occurs} of P = {max occurs} of P = n, and T is the {term} of P, then L(P) is the set of sequences S = S1 + S2 + ... + Snsuch that Si is in L(T) for 0 < in. Less formally: L(P) is the set of sequences which have ·partitions· into n sub-sequences for which each of the n subsequences is in the language accepted by the {term} of P.

When {min occurs} = j and {max occurs} = k, and T is the {term} of P, then L(P) is the set of sequences S = S1, + S2 + ... + Sn, i.e. the set of sequences which have ·partitions· into n sub-sequences such that nj and nk (or k is unbounded) and Si is in L(T) for 0 < in.

When {min occurs} = 0, then L(P) also includes the empty sequence.

If (1) Particle P has {min occurs} = j, {max occurs} = k, and {term} = T, and (2) S is a sequence of element information items such that S = S1 + S2 + ... + Sn (i.e. S1, S2, ..., Sn is a ·partition· of S), and (3) nk (or k is unbounded), and (4) Si is in L(T) for 0 < i < n, then:
Note:  Informally: the path of an input sequence S in a particle P may go through the ·basic particles· in P as many times as is allowed by the {max occurs} of P. If the path goes through P more than once, each time before the last one must correspond to a sequence accepted by the {term} of P; because the last iteration in the path may not be complete, it need not be accepted by the {term}.
3.9.4.1.2 Validation of Basic Terms
When the {term} of a Particle P is an Element Declaration D, then L(P) is the set of all sequences of length 1 whose sole member is an element information item which ·matches· D.
[Definition:]  An element information item E matches an Element Declaration D if and only if:
[Definition:]  An expanded name E matches an ·NCName· N and a namespace name NS (or, equivalently, N and NS match E) if and only if all of the following are true:
  • The local name of E is identical to N.
  • Either the namespace name of E is identical to NS, or else E has no namespace name (E is an unqualified name) and NS is ·absent·.
Note: For convenience, expanded names are sometimes spoken of as ·matching· a Type Definition, an Element Declaration, an Attribute Declaration, or other schema component which has both a {name} and a {target namespace} property (or vice versa, the component is spoken of as ·matching· the expanded name), when what is meant is, strictly speaking, that the expanded name ·matches· the {name} and {target namespace} properties of the component.

When the {term} of a Particle P is a Wildcard W, then L(P) is the set of all sequences of length 1 whose sole member is an element information item E which ·matches· W. [Definition:]  An element information item E matches a Wildcard W (or a ·wildcard particle· whose {term} is W) if and only if W allows the [namespace name] of E, as defined in the validation rule Wildcard allows Namespace Name (§3.10.4).

[Definition:]  Two namespace names N1 and N2 are said to match if and only if they are identical or both are ·absent·.

For principles of validation when the {term} is a model group instead of a ·basic particle·, see Language Recognition by Groups (§3.8.4.1) and Principles of Validation against Groups (§3.8.4.2).

3.9.4.2 Validation Rules
Validation Rule: Element Sequence Locally Valid (Particle)
For a sequence (possibly empty) of element information items to be locally ·valid· with respect to a Particle all of the following must be true:
1 The sequence must be accepted by the Particle, as defined in Element Sequence Accepted (Particle) (§3.9.4.2).
Validation Rule: Element Sequence Accepted (Particle)
For a sequence (possibly empty) of element information items to be accepted by a Particle, the appropriate case among the following must be true:
1 If the {term} is a wildcard, then all of the following are true:
1.1 The length of the sequence is greater than or equal to the {min occurs}.
1.2 If {max occurs} is a number, the length of the sequence is less than or equal to the {max occurs}.
1.3 Each element information item in the sequence is ·valid· with respect to the wildcard as defined by Item Valid (Wildcard) (§3.10.4).
In this case, each element information item in the sequence is ·attributed to· the particle and has no ·context-determined declaration·.
2 If the {term} is an element declaration, then all of the following are true:
2.1 The length of the sequence is greater than or equal to the {min occurs}.
2.2 If {max occurs} is a number, the length of the sequence is less than or equal to the {max occurs}.
2.3 For each element information item in the sequence one of the following is true
2.3.1 The element declaration is local (i.e. its {scope}'s {variety} is not global), the element information item's [namespace name] is identical to the element declaration's {target namespace} (where an ·absent· {target namespace} is taken to be identical to a [namespace name] with no value) and the element information item's [local name] matches the element declaration's {name}.In this case the element declaration is the ·context-determined declaration· for the element information item with respect to Schema-Validity Assessment (Element) (§3.3.4) and Assessment Outcome (Element) (§3.3.5).
2.3.2 The element declaration is top-level (i.e. its {scope}'s {variety} is global), the element information item's [namespace name] is identical to the element declaration's {target namespace} (where an ·absent· {target namespace} is taken to be identical to a [namespace name] with no value) and the element information item's [local name] matches the element declaration's {name}.In this case the element declaration is the ·context-determined declaration· for the element information item with respect to Schema-Validity Assessment (Element) (§3.3.4) and Assessment Outcome (Element) (§3.3.5).
2.3.3 The element declaration is top-level (i.e. its {scope}'s {variety} is global), its {disallowed substitutions} does not contain substitution, the [local ] and [namespace name] of the element information item ·resolve· to an element declaration — [Definition:]  call this declaration the substituting declaration and the ·substituting declaration· together with the particle's element declaration's {disallowed substitutions} is ·substitutable· for the particle's element declaration as defined in Substitution Group OK (Transitive) (§3.3.6).In this case the ·substituting declaration· is the ·context-determined declaration· for the element information item with respect to Schema-Validity Assessment (Element) (§3.3.4) and Assessment Outcome (Element) (§3.3.5).
In this case the element information item is ·attributed to· the particle.
3 If the {term} is a model group, then all of the following are true:
3.1 There is a ·partition· of the sequence into n sub-sequences such that n is greater than or equal to {min occurs}.
3.2 If {max occurs} is a number, n is less than or equal to {max occurs}.
3.3 Each sub-sequence in the ·partition· is ·valid· with respect to that model group as defined in Element Sequence Valid (§3.8.4.3).
In this case, the element information items in each sub-sequence are ·attributed to· Particles within the model group which is the {term}, as described in Language Recognition by Groups (§3.8.4.1).
Note: The rule just given does not require that the content model be deterministic. In practice, however, most non-determinism in content models is ruled out by the schema component constraint Unique Particle Attribution (§3.8.6). Non-determinism can occur despite that constraint for several reasons. In some such cases, some particular element information item may be accepted by either a Wildcard or an Element Declaration. In such situations, the validation process defined in this specification matches the element information item against the Element Declaration, both in identifying the Element Declaration as the item's ·context-determined declaration·, and in choosing alternative paths through a content model. Other cases of non-determinism involve nested particles each of which has {max occurs} greater than 1, where the input sequence can be partitioned in multiple ways. In those cases, there is no fixed rule for eliminating the non-determinism.
Note: clause 1 and clause 2.3.3 do not interact: an element information item validatable by a declaration with a substitution group head is not validatable by a wildcard which accepts the head's (namespace, name) pair but not its own.

3.9.5 Particle Information Set Contributions

None as such.

3.9.6 Constraints on Particle Schema Components

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

Schema Component Constraint: Particle Correct
All of the following must be true:
1 The values of the properties of a particle are as described in the property tableau in The Particle Schema Component (§3.9.1), modulo the impact of Missing Sub-components (§5.3).
2 If {max occurs} is not unbounded, that is, it has a numeric value, then all of the following are true:
2.1 {min occurs} is not greater than {max occurs}.

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

Schema Component Constraint: Particle Valid (Extension)
[Definition:]  For a particle (call it E, for extension) to be a valid extension of another particle (call it B, for base) one of the following must be true:
1 They are the same particle.
2 E's {min occurs}={max occurs}=1 and its {term} is a sequence group whose {particles}' first member is a particle all of whose properties, recursively, are identical to those of B, with the exception of {annotation} properties.
3 All of the following are true:
3.1 E's {min occurs} is the same as B's {min occurs}.
3.2 Both E and B have all groups as their {term}s.
3.3 The {particles} of B's all group is a prefix of {particles} of E's all group.
Schema Component Constraint: Particle Emptiable
[Definition:]  For a particle to be emptiable one of the following must be true:
1 Its {min occurs} is 0.
2 Its {term} is a group and the minimum part of the effective total range of that group, as defined by Effective Total Range (all and sequence) (§3.8.6) (if the group is all or sequence) or Effective Total Range (choice) (§3.8.6) (if it is choice), is 0.

previous sub-section next sub-section3.10 Wildcards

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 names and optionally on their local names.

Example
<xs:any processContents="skip"/>

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

<xs:any namespace="http://www.w3.org/1999/XSL/Transform"
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        notQName="xsl:comment xsl:fallback"/>

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

<xs:anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/>
XML representations of the four basic types of wildcard, plus one attribute wildcard.

3.10.1 The Wildcard Schema Component

The wildcard schema component has the following properties:

Schema Component: Wildcard, a kind of Term
{annotations}
A sequence of Annotation components.
{namespace constraint}
A Namespace Constraint property record. Required.
{process contents}
One of {skip, strict, lax}. Required.
Property Record: Namespace Constraint
{variety}
One of {any, enumeration, not}. Required.
{namespaces}

A set each of whose members is either an xs:anyURI value or ·absent·. Required.

{disallowed names}

A set each of whose members is either an xs:QName value or the keyword defined. Required.

{namespace constraint} provides for ·validation· of attribute and element items that:
  1. ({variety} any) have any namespace or are not namespace-qualified;
  2. ({variety} not and {namespaces} a set whose members are either namespace names or ·absent·) have any namespace other than the specified namespaces and/or, if ·absent· is included in the set, are namespace-qualified;
  3. ({variety} enumeration and {namespaces} 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.
  4. ({disallowed names} contains QName members) have any (namespace name, local name) other than the specified names.
  5. ({disallowed names} contains the keyword defined) have any (namespace name, local name) other than those matching the names of global element or attribute declarations.
{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.15) for information on the role of the {annotations} property.

Editorial Note: Priority Feedback Request

The keyword defined allows a kind of wildcard which matches only elements not declared in the current schema. It is new in this version of this specification. The Working Group is uncertain whether its value outweighs its liabilities; we solicit input from implementors and users of this specification as to whether it should be retained or not.

3.10.2 XML Representation of Wildcard Schema Components

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

XML Representation Summary: any Element Information Item

<any
  id = ID
  maxOccurs = (nonNegativeInteger | unbounded)  : 1
  minOccurs = nonNegativeInteger : 1
  namespace = ((##any | ##other) | List of (anyURI | (##targetNamespace | ##local)) )
  notNamespace = List of (anyURI | (##targetNamespace | ##local))
  notQName = List of (QName | ##defined)
  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):
Particle Schema Component
Property
Representation
 
The ·actual value· of the minOccurs [attribute], if present, otherwise 1.
 
unbounded, if the maxOccurs [attribute] equals unbounded, otherwise the ·actual value· of the maxOccurs [attribute], if present, otherwise 1.
 
A wildcard as given below:
 
The same annotations as the {annotations} of the wildcard. See below.
Wildcard Schema Component
Property
Representation
 
A Namespace Constraint with the following properties:
Property
Value
the appropriate case among the following:
1 If the namespace [attribute] is present, then the appropriate case among the following:
1.1 If the ·actual value· of the namespace [attribute] is "##any", then any;
1.2 If the ·actual value· of the namespace [attribute] is "##other", then not;
1.3 otherwise enumeration;
2 If the notNamespace [attribute] is present, then not;
3 otherwise (neither namespace nor notNamespace is present) any.
the appropriate case among the following:
1 If neither namespace nor notNamespace is present, then the empty set;
2 If the namespace [attribute] is present and its ·actual value· is "##any", then the empty set;
3 If the namespace [attribute] is present and its ·actual value· is "##other", then a set consisting ·absent· and, if the targetNamespace [attribute] of the <schema> ancestor element information item is present, its ·actual value·;
4 otherwise a set whose members are namespace names corresponding to the space-delimited substrings of the ·actual value· of the namespace or notNamespace [attribute] (whichever is present), except
4.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·;
4.2 if one such substring is ##local, the corresponding member is ·absent·.
If the notQName [attribute] is present, then a set whose members are QName values corresponding to the space-delimited substrings of the ·actual value· of the notQName [attribute], except if one such substring is ##defined, the corresponding member is the keyword defined, otherwise (the notQName [attribute] is not present) the empty set.
 
The ·actual value· of the processContents [attribute], if present, otherwise strict.
 
The ·annotation mapping· of the <any> element, as defined in XML Representation of Annotation Schema Components (§3.15.2).
Note:  When this rule is used for an attribute wildcard (see XML Representation of Complex Type Definitions (§3.4.2)), the {annotations} is the ·annotation mapping· of the <anyAttribute> element.

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 one of two wildcards, within the content model of a type, that model is in error.

3.10.3 Constraints on XML Representations of Wildcards

Schema Representation Constraint: Wildcard Representation OK
In addition to the conditions imposed on <any> element information items by the schema for schema documents, all of the following must be true:
1 namespace and notNamespace are not both present;
2 The corresponding particle and model group satisfy the conditions set out in Constraints on Model Group Schema Components (§3.8.6) and Constraints on Particle Schema Components (§3.9.6).

3.10.4 Wildcard Validation Rules

Validation Rule: Item Valid (Wildcard)
For an element or attribute information item to be locally ·valid· with respect to a wildcard constraint its ([namespace name], [local name]) pair must be ·valid· with respect to the wildcard constraint, as defined in Wildcard allows Expanded Name (§3.10.4).

When an element or attribute information item is ·attributed· to a wildcard and the preceding constraint (Item Valid (Wildcard) (§3.10.4)) is satisfied, then the item has no ·context-determined declaration·. Its ·governing· declaration, if any, is found by matching its expanded name as described in QName resolution (Instance) (§3.17.4). Note that QName resolution is performed only if the item is ·attributed· to a strict or lax wildcard; if the wildcard has a {process contents} property of skip, then the item has no ·governing· declaration.

[Definition:]   An element or attribute information item is skipped if it is ·attributed· to a skip wildcard or if one of its ancestor elements is.

Validation Rule: Wildcard allows Expanded Name
For a (namespace name, local name) pair to be ·valid· with respect to a wildcard constraint (the value of a {namespace constraint}) all of the following must be true:
1 The namespace name is ·valid· with respect to the wildcard constraint, as defined in Wildcard allows Namespace Name (§3.10.4);
2 The constraint's {disallowed names} does not contain the pair.
3 If the constraint's {disallowed names} contains the keyword defined, then the pair does not ·resolve· to an element or attribute declaration (depending on whether the pair is an element or attribute name).
Validation Rule: Wildcard allows Namespace Name
For a value which is either a namespace name or ·absent· to be ·valid· with respect to a wildcard constraint (the value of a {namespace constraint}) one of the following must be true:
1 The constraint's {variety} is any.
2 The constraint's {variety} is not, and the value is not identical to any of the members of the constraint's {namespaces}.
3 The constraint's {variety} is enumeration, and the value is identical to one of the members of the constraint's {namespaces}.

3.10.5 Wildcard Information Set Contributions

None as such.

3.10.6 Constraints on Wildcard Schema Components

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

Schema Component Constraint: Wildcard Properties Correct
All of the following must be true:
1 The values of the properties of a wildcard are as described in the property tableau in The Wildcard Schema Component (§3.10.1), modulo the impact of Missing Sub-components (§5.3).
2 If {variety} is not, {namespaces} has at least one member.
3 If {variety} is any, {namespaces} is empty.
4 The namespace name of each QName member in {disallowed names} is allowed by the {namespace constraint}, as defined in Wildcard allows Namespace Name (§3.10.4).

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

Schema Component Constraint: Wildcard Subset
[Definition:]   Given two Namespace Constraints sub and super, sub is a wildcard subset of super if and only if one of the following is true
1 super has {variety} = any.
2 Both sub and super have {variety} = enumeration, and super's {namespaces} is a superset of sub's {namespaces}.
3 The {variety} of sub is enumeration, the {variety} of super is not, and the {namespaces} of the two are disjoint.
4 Both sub and super have {variety} = not, and super's {namespaces} is a subset of sub's {namespaces}.
And all of the following must be true:
1 Each QName member of super's {disallowed names} is not allowed by sub, as defined in Wildcard allows Expanded Name (§3.10.4).
2 If super's {disallowed names} contains defined, then sub's {disallowed names} also contains defined.
Schema Component Constraint: Attribute Wildcard Union
[Definition:]   Given three Namespace Constraints O, O1, and O2, O is the wildcard union of O1 and O2 if and only if, first, the {variety} and {namespaces}, and, second, the {disallowed names} of O are consistent with O being the union of O1 and O2, as that is defined below. The {variety} and {namespaces} of O are consistent with O being the wildcard union of O1 and O2 if and only if one of the following is true
1 O, O1, and O2 all have the same {variety} and {namespaces}.
2 Either O1 or O2 has {variety} any, and O has {variety} any.
3 O, O1, and O2 all have {variety} enumeration, and O's {namespaces} is the union of O1's {namespaces} and O2's {namespaces}.
4 O1 and O2 both have {variety} not, and one of the following is true
4.1 The intersection of the {namespaces} of O1 and O2 is the empty set, and O has {variety} = any.
4.2 O also has {variety} not, and the {namespaces} of O is the non-empty intersection of the {namespaces} of O1 and O2.
5 Either O1 or O2 has {variety} not and {namespaces} S1, and the other has {variety} enumeration and {namespaces} S2, and one of the following is true
5.1 The set difference S1 minus S2 is the empty set, and O has {variety} = any.
5.2 O has {variety} = not and the {namespaces} of O is the non-empty set difference S1 minus S2.
The {disallowed names} property of O is consistent with O being the wildcard union of O1 and O2 if and only if O's {disallowed names} includes all and only the following:
1 QName members of O1's {disallowed names} that are not allowed by O2, as defined in Wildcard allows Expanded Name (§3.10.4).
2 QName members of O2's {disallowed names} that are not allowed by O1.
3 The keyword defined if it is contained in both O1's and O2's {disallowed names}.
4 If one {disallowed names} (assume it is from O1 without losing generality) contains defined and the other one (from O2) does not, and there exists a namespace name or ·absent· that is allowed by O1, as defined in Wildcard allows Namespace Name (§3.10.4), but not by O2, then the wildcard union is not expressible.
Note: If a wildcard union is inexpressible, any rule requiring that one Namespace Constraint be that union cannot be satisfied.
In the case where there are more than two Namespace Constraints to be combined, the wildcard union is determined by identifying the wildcard union of two of them as above, then the wildcard union of the result with the third (providing the first union was expressible), and so on as required. If some of the Namespace Constraints contain defined in their {disallowed names}, then the union operation must be applied first to those who do not contain that keyword, to maximize the chance of expressibility.
Schema Component Constraint: Attribute Wildcard Intersection
[Definition:]   Given three Namespace Constraints O, O1, and O2, O is the wildcard intersection of O1 and O2 if and only if both its {variety} and {namespaces} properties, on the one hand, and its {disallowed names} property, on the other, are consistent with O being the intersection of O1 and O2, as that is defined below.The {variety} and {namespaces} of O are consistent with O being the wildcard intersection of O1 and O2 if and only if
1 O, O1, and O2 have the same {variety} and {namespaces}.
2 Either O1 or O2 has {variety} = any and O has {variety} and {namespaces} identical to those of the other.
3 O, O1, and O2 all have {variety} = enumeration, and the {namespaces} of O is the intersection of the {namespaces} of O1 and O2.
4 O, O1, and O2 all have {variety} not, and the {namespaces} of O is the union of the {namespaces} of O1 and O2.
5 Either O1 or O2 has {variety} = not and {namespaces} = S1 and the other has {variety} = enumeration and {namespaces} = S2, and O has {variety} = enumeration and {namespaces} = the set difference S2 minus S1.
The {disallowed names} property of O is consistent with O being the wildcard intersection of O1 and O2 if and only if O's {disallowed names} includes all and only the following:
1 QName members of O1's {disallowed names} that are allowed by O2, as defined in Wildcard allows Expanded Name (§3.10.4).
2 QName members of O2's {disallowed names} that are allowed by O1.
3 The intersection of O1's {disallowed names} and O2's {disallowed names}.
4 The keyword defined if it is a member of either {disallowed names}.
In the case where there are more than two Namespace Constraints to be combined, the wildcard intersection is determined by identifying the wildcard intersection of two of them as above, then the wildcard intersection of the result with the third, and so on as required.

previous sub-section next sub-section3.11 Identity-constraint Definitions

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

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

3.11.1 The Identity-constraint Definition Schema Component

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

{annotations}
A sequence of Annotation components.
{name}
An xs:NCName value. Required.
{target namespace}
An xs:anyURI value. Optional.
{identity-constraint category}
One of {key, keyref, unique}. Required.
{selector}
An XPath Expression property record. Required.
{fields}
A sequence of XPath Expression property records.
{referenced key}
An Identity-Constraint Definition component. Required if {identity-constraint category} is keyref, otherwise ({identity-constraint category} is key or unique) must be ·absent·.

If a value is present, its {identity-constraint category} must be key or unique.

Identity-constraint definitions are identified by their {name} and {target namespace}; Identity-constraint definition identities must be unique within an ·XSDL schema·. See References to schema components across namespaces (<import>) (§4.2.4) 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 can also serve as a key. Each constraint declaration has a name, which exists in a single symbol space for constraints. The identity conditions appealed to in checking these constraints apply to the values of the fields selected, not their lexical representation, so that for example 3.0 and 3 would be conflicting keys if they were both decimal, but non-conflicting if they were both strings, or one was a string and one a decimal.

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 2.0]) expression relative to instances of the element being declared. This must identify a sequence of element nodes that are 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.
Note:  In version 1.0 of this specification, identity constraints used [XPath 1.0]. They now use [XPath 2.0].

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

3.11.2 XML Representation of Identity-constraint Definition Schema Components

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:

XML Representation Summary: unique Element Information Item

<unique
  id = ID
  name = NCName
  ref = QName
  xpathDefaultNamespace = (anyURI | (##defaultNamespace | ##targetNamespace | ##local))
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (selector, field+))
</unique>

<key
  id = ID
  name = NCName
  ref = QName
  xpathDefaultNamespace = (anyURI | (##defaultNamespace | ##targetNamespace | ##local))
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (selector, field+))
</key>

<keyref
  id = ID
  name = NCName
  ref = QName
  refer = QName
  xpathDefaultNamespace = (anyURI | (##defaultNamespace | ##targetNamespace | ##local))
  {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>

If the ref [attribute] is absent, the corresponding schema component is as follows:
Property
Representation
 
 
The ·actual value· of the targetNamespace [attribute] of the ancestor schema element information item.
 
One of key, keyref or unique, depending on the item.
 
An XPath Expression property record, as described in section XML Representation of Assertion Schema Components (§3.13.2), with <selector> as the "host element" and xpath as the designated expression [attribute].
 
A sequence of XPath Expression property records, corresponding to the <field> element information item [children], in order, following the rules given in XML Representation of Assertion Schema Components (§3.13.2), with <field> as the "host element" and xpath as the designated expression [attribute].
 
If the item is a <keyref>, the identity-constraint definition ·resolved· to by the ·actual value· of the refer [attribute], otherwise ·absent·.
 
The ·annotation mapping· of the set of elements containing the <key>, <keyref>, or <unique> element, whichever is present, and the <selector> and <field> [children], if present, as defined in XML Representation of Annotation Schema Components (§3.15.2).
Otherwise (the ref [attribute] is present), the corresponding schema component is the identity-constraint definition ·resolved· to by the ·actual value· of the ref [attribute].
Example
<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.

3.11.3 Constraints on XML Representations of Identity-constraint Definitions

Schema Representation Constraint: Identity-constraint Definition Representation OK
In addition to the conditions imposed on <key>, <keyref> and <unique> element information items by the schema for schema documents, all of the following must be true:
1 One of ref or name is present, but not both.
2 If name is present on <keyref>, then refer is also present.
3 If ref is present, then only id and <annotation> are allowed to appear together with ref.
4 If ref is present, then the {identity-constraint category} of the identity-constraint definition ·resolved· to by the ·actual value· of the ref [attribute] matches the name of the element information item.
5 The corresponding identity-constraint definition must satisfy the conditions set out in Constraints on Identity-constraint Definition Schema Components (§3.11.6).

3.11.4 Identity-constraint Definition Validation Rules

Validation Rule: Identity-constraint Satisfied
For an element information item to be locally ·valid· with respect to an identity-constraint all of the following must be true:
1 A data model instance is constructed from the input information set, as described in [XDM]. The {selector}, with the element node corresponding to the element information item as the context node, evaluates to a sequence of element nodes, as defined in XPath Evaluation (§3.13.4). [Definition:]   The target node set is the set of nodes in that sequence, excluding element nodes corresponding to element information items that are ·skipped·.
2 Each node in the ·target node set· is either the context node or an element node among its descendants.
3 For each node in the ·target node set· all of the {fields}, with that node as the context node, evaluates to a sequence of nodes (as defined in XPath Evaluation (§3.13.4)) that only contains ·skipped· nodes and at most one node whose ·governing· type definition is either a simple type definition or a complex type definition with {variety} simple. [Definition:]  Call the sequence of the [schema actual value]s of the element and/or attribute information items in those node-sets in order the key-sequence of the node.
4 [Definition:]  Call the subset of the ·target node set· for which all the {fields} evaluate to a node-set one of whose members is an element or attribute node with a ·non-absent· [schema actual value] the qualified node set. The appropriate case among the following is true:
4.1 If the {identity-constraint category} is unique, then no two members of the ·qualified node set· have ·key-sequences· whose members are pairwise equal, as defined by Equality in [XML Schema: Datatypes].
4.2 If the {identity-constraint category} is key, then all of the following are true:
4.2.1 The ·target node set· and the ·qualified node set· are equal, that is, every member of the ·target node set· is also a member of the ·qualified node set· and vice versa.
4.2.2 No two members of the ·qualified node set· have ·key-sequences· whose members are pairwise equal, as defined by Equality in [XML Schema: Datatypes].
4.2.3 No element member of the ·key-sequence· of any member of the ·qualified node set· was assessed as ·valid· by reference to an element declaration whose {nillable} is true.
4.3 If the {identity-constraint category} is keyref, then for each member of the ·qualified node set· (call this the keyref member), there is a ·node table· associated with the {referenced key} in the [identity-constraint table] of the element information item (see Identity-constraint Table (§3.11.5), which is understood as logically prior to this clause of this constraint, below) and there is an entry in that table whose ·key-sequence· is equal to the keyref member's ·key-sequence· member for member, as defined by Equality in [XML Schema: Datatypes].
Note: The use of [schema actual value] in the definition of ·key sequence· above means that default or fixed value constraints may play a part in ·key sequence·s.
Note: Because the validation of keyref (see clause 4.3) depends on finding appropriate entries in a element information item's ·node table·, and ·node tables· 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 ·validated· can be referenced successfully.
Note: Although this specification defines a ·post-schema-validation infoset· contribution which would enable schema-aware processors to implement clause 4.2.3 above (Element Declaration (§3.3.5)), 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 {nillable} property must be available.

3.11.5 Identity-constraint Definition Information Set Contributions

Schema Information Set Contribution: Identity-constraint Table
[Definition:]  An eligible identity-constraint of an element information item is one such that clause 4.1 or clause 4.2 of Identity-constraint Satisfied (§3.11.4) is satisfied with respect to that item and that constraint, or such that any of the element information item [children] of that item have an [identity-constraint table] property whose value has an entry for that constraint.[Definition:]  A node table is a set of pairs each consisting of a ·key-sequence· and an element node.Whenever an element information item has one or more ·eligible identity-constraints·, in the ·post-schema-validation infoset· that element information item has a property as follows:
PSVI Contributions for element information items
[identity-constraint table]
one Identity-constraint Binding information item for each ·eligible identity-constraint·, with properties as follows:
PSVI Contributions for Identity-constraint Binding information items
[definition]
The ·eligible identity-constraint·.
[node table]
A ·node table· with one entry for every ·key-sequence· (call it k) and node (call it n) such that one of the following is true
1 There is an entry in one of the ·node tables· associated with the [definition] in an Identity-constraint Binding information item in at least one of the [identity-constraint table]s of the element information item [children] of the element information item whose ·key-sequence· is k and whose node is n;
2 n appears with ·key-sequence· k in the ·qualified node set· for the [definition].
provided no two entries have the same ·key-sequence· but distinct nodes. Potential conflicts are resolved by not including any conflicting entries which would have owed their inclusion to clause 1 above. Note that if all the conflicting entries arose under clause 1 above, this means no entry at all will appear for the offending ·key-sequence·.
Note: The complexity of the above arises from the fact that keyref identity-constraints can be defined on domains distinct from the embedded domain of the identity-constraint they reference, or on domains which are the same but self-embedding at some depth. In either case the ·node table· for the referenced identity-constraint needs to propagate upwards, with conflict resolution.The Identity-constraint Binding information item, unlike others in this specification, is essentially an internal bookkeeping mechanism. It is introduced to support the definition of Identity-constraint Satisfied (§3.11.4) above. Accordingly, conformant processors may, but are not required to, expose them via [identity-constraint table] properties in the ·post-schema-validation infoset·. In other words, the above constraints are to be read as saying ·validation· of identity-constraints proceeds as if such infoset items existed.

3.11.6 Constraints on Identity-constraint Definition Schema Components

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

Schema Component Constraint: Identity-constraint Definition Properties Correct
All of the following must be true:
1 The values of the properties of an identity-constraint definition are as described in the property tableau in The Identity-constraint Definition Schema Component (§3.11.1), modulo the impact of Missing Sub-components (§5.3).
2 If the {identity-constraint category} is keyref, the cardinality of the {fields} is equal to that of the {fields} of the {referenced key}.
Schema Component Constraint: Selector Value OK
All of the following must be true:
1 The {selector} satisfies the constraint XPath Valid (§3.13.6).
2 One of the following is true:
2.1 Its {expression} conforms to the following extended BNF:
Selector XPath expressions
[1]    Selector    ::=    Path ( '|' Path )*
[2]    Path    ::=    ('.//')? Step ( '/' Step )*
[3]    Step    ::=    '.' | NameTest
[4]    NameTest    ::=    QName | '*' | NCName ':' '*'
2.2 Its {expression} is 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: whitespace may be freely added within patterns before or after any token.
Lexical productions
[5]    token    ::=    '.' | '/' | '//' | '|' | '@' | NameTest
[6]    whitespace    ::=    S
When tokenizing, the longest possible token is always returned.
Schema Component Constraint: Fields Value OK
All of the following must be true:
1 Each member of the {fields} satisfies the constraint XPath Valid (§3.13.6).
2 For each member of the {fields} one of the following is true
2.1 Its {expression} conforms to the extended BNF given above for Selector, with the following modification:
Path in Field XPath expressions
[7]    Path    ::=    ('.//')? ( Step '/' )* ( Step | '@' NameTest )
This production differs from the one above in allowing the final step to match an attribute node.
2.2 Its {expression} is 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: whitespace may be freely added within patterns before or after any token. When tokenizing, the longest possible token is always returned.

previous sub-section next sub-section3.12 Type Alternatives

Type Alternative components provide associations between boolean conditions (as XPath expressions) and Type Definitions. They are used in conditional type assignment.

3.12.1 The Type Alternative Schema Component

The type alternative schema component has the following properties:

Schema Component: Type Alternative, a kind of Annotated Component
{annotations}
A sequence of Annotation components.
{test}
An XPath Expression property record. Optional.
{type definition}
A Type Definition component. Required.

Type alternatives can be used by an Element Declaration to specify a condition ({test}) under which a particular type ({type definition}) is used as the ·governing type definition· for element information items governed by that Element Declaration. Each Element Declaration may have multiple Type Alternatives in its {type table}.

3.12.2 XML Representation of Type Alternative Schema Components

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

XML Representation Summary: alternative Element Information Item

<alternative
  id = ID
  test = an XPath expression
  type = QName
  xpathDefaultNamespace = (anyURI | (##defaultNamespace | ##targetNamespace | ##local))
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (simpleType | complexType)?)
</alternative>

Type Alternative Schema Component
Property
Representation
 
If the test [attribute] is not present, then ·absent·; otherwise an XPath Expression property record, as described in section XML Representation of Assertion Schema Components (§3.13.2), with <alternative> as the "host element" and test as the designated expression [attribute].
 
The type definition ·resolved· to by the ·actual value· of the type [attribute], if one is present, otherwise the type definition corresponding to the complexType or simpleType among the [children] of the <alternative> element.
 

3.12.3 Constraints on XML Representations of Type Alternatives

Schema Representation Constraint: Type Alternative Representation OK
In addition to the conditions imposed on <alternative> element information items by the schema for schema documents: all of the following must be true:
1 Every <alternative> element has a type attribute, or a complexType child element, or a simpleType child element. No <alternative> element has more than one of these, and each has at least one of these.
2 The corresponding type alternative satisfies the conditions set out in Constraints on Type Alternative Schema Components (§3.12.6).

3.12.4 Type Alternative Validation Rules

[Definition:]  A Type Alternative A successfully selects a Type Definition T for an element information item E if and only if A's {test} evaluates to true and T is the {type definition} of A. The {test} is evaluated in the following way:
  1. An instance of the [XDM] data model is constructed as follows:
    1. An information set is constructed by copying E and its [attributes], but not its [children]. No validation is performed, and the information set thus constructed is not a ·post-schema-validation infoset·.
    2. An [XDM] data model instance is constructed from that information set, following the rules given in [XDM].
  2. The XPath expression which is the value of the {test}, is evaluated as described in XPath Evaluation (§3.13.4). If a dynamic error or a type error is raised during evaluation, then the {test} is treated as if it had evaluated (without error) to false.
    Note:  Dynamic errors and type errors in the evaluation of {test} expressions cause neither the schema nor the document instance to be invalid. But conforming processors may issue a warning if they occur.
Note:  As a consequence of the rules just given, the root node of the [XDM] instance is necessarily constructed from E; the ancestors, siblings, children, and descendants of E are not represented in the data model instance, and they are thus not accessible to the tests expressed in the {test}s in the {type table}. The element E and its [attributes] will be represented in the data model instance by nodes labeled as untyped. If the {test} expressions being evaluated include comparisons which require type information, then explicit casts will sometimes be necessary.

3.12.5 Type Alternative Information Set Contributions

None.

3.12.6 Constraints on Type Alternative Schema Components

All type alternatives (see Type Alternatives (§3.12)) must satisfy the following constraints.

Schema Component Constraint: Type Alternative Properties Correct
All of the following must be true:
1 The values of the properties of a type alternatives must be as described in the property tableau in The Type Alternative Schema Component (§3.12.1), modulo the impact of Missing Sub-components (§5.3).
2 If the {test} is not ·absent·, then it satisfies the constraint Test Value OK (§3.13.6), with the following modification:
Comparator in Alternative XPath expressions
[8]    Comparator    ::=    '=' | '!=' | '<' | '<=' | '>' | '>='

previous sub-section next sub-section3.13 Assertions

Assertion components constrain the existence and values of related elements and attributes.

Example
<xs:assert test="@min le @max"/>
The XML representations for assertions.
The <assert> element requires that the value of the min attribute be less than or equal to that of the max attribute, and fails if that is not the case.

3.13.1 The Assertion Schema Component

The assertion schema component has the following properties:

Schema Component: Assertion, a kind of Annotated Component
{annotations}
A sequence of Annotation components.
{test}
An XPath Expression property record. Required.
Property Record: XPath Expression
{namespace bindings}
A set of Namespace Binding property records.
{default namespace}
An xs:anyURI value. Optional.
{base URI}
An xs:anyURI value. Optional.
{expression}
An [XPath 2.0] expression. Required.
Property Record: Namespace Binding
{prefix}
An xs:NCName value. Required.
{namespace}
An xs:anyURI value. Required.

The {test} property specifies an XPath ([XPath 2.0]) expression. Conforming processors may implement all of [XPath 2.0] or may restrict themselves to the subset described below. Interoperability among all conforming implementations is best achieved by restricting XPath expressions to the subset. In the minimum subset:

  • Path steps are restricted to only match information items within the element being ·assessed·.
  • XPath predicates are restricted to only match information items within the element on which the predicates are applied.
  • Operations are limited to those defined in this specification. For example, comparison of ·actual values· is supported, while general comparison, addition and multiplication are not.
  • Functions are also limited to those whose semantics is within the scope of this specification..

To check an assertion, an instance of the XPath 2.0 data model ([XDM]) is constructed, in which the element information item being ·assessed· is the root element, and elements and attributes are assigned types and values according to XPath 2.0 data model construction rules, with some exceptions. See Assertion Satisfied (§3.13.4) for details about how the data model is constructed. When evaluated against this data model instance, {test} evaluates to either true or false (if any other value is returned, it's converted to either true or false as if by a call to the XPath fn:boolean function).

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

3.13.2 XML Representation of Assertion Schema Components

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

XML Representation Summary: assert Element Information Item

<assert
  id = ID
  test = an XPath expression
  xpathDefaultNamespace = (anyURI | (##defaultNamespace | ##targetNamespace | ##local))
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</assert>

Assertion Schema Component
Property
Representation
 
An XPath Expression property record, as described below, with <assert> as the "host element" and test as the designated expression [attribute].
 

Assertions, like identity constraints and conditional type assignment, use [XPath 2.0] expressions. The expression itself is recorded, together with relevant parts of the context, in an XPath Expression property record. The mapping is as described below; in each case, the XPath expression itself is given in a designated attribute of the appropriate "host element".

XML Mapping Summary
XPath Expression Property Record
Property
Representation
 
A set of Namespace Binding property records. Each member corresponds to an entry in the [in-scope namespaces] of the host element, with {prefix} being the [prefix] and {namespace} the [namespace name].
 
Let D be the ·actual value· of the xpathDefaultNamespace [attribute], if present on the host element, otherwise that of the defaultXPathDefaultNamespace [attribute] of the <schema> ancestor. Then the value is the appropriate case among the following:
1 If D is ##defaultNamespace, then the appropriate case among the following:
1.1 If there is an entry in the [in-scope namespaces] of the host element whose [prefix] is ·absent·, then the corresponding [namespace name];
1.2 otherwise ·absent·;
2 If D is ##targetNamespace, then the appropriate case among the following:
2.1 If the targetNamespace [attribute] is present on the <schema> ancestor, then its ·actual value·;
2.2 otherwise ·absent·;
3 If D is ##local, then ·absent·;
4 otherwise (D is an xs:anyURI value) D.
 
The [base URI] of the host element.
 
An XPath expression corresponding to the ·actual value· of the designated [attribute] of the host element.
Example
<xs:complexType name="intRange">
 <xs:attribute name="min" type="xs:int"/>
 <xs:attribute name="max" type="xs:int"/>
 <xs:assert test="@min le @max"/>
</xs:complexType>
The value of the min attribute must be less than or equal to that of the max attribute.
Example
<xs:complexType name="arrayType">
 <xs:sequence>
  <xs:element name="entry" minOccurs="0" maxOccurs="unbounded"/>
 </xs:sequence>
 <xs:attribute name="length" type="xs:int"/>
 <xs:assert test="@length eq fn:count(./entry)"/>
</xs:complexType>
The value of the length attribute must be the same as the number of occurrences of entry sub-elements.

3.13.3 Constraints on XML Representations of Assertions

Schema Representation Constraint: Assertion Representation OK
In addition to the conditions imposed on <assert> element information items by the schema for schema documents, the corresponding assertion must satisfy the conditions set out in Constraints on Assertion Schema Components (§3.13.6).

3.13.4 Assertion Validation Rules

Validation Rule: Assertion Satisfied
An element information item E is locally ·valid· with respect to an assertion if and only if the {test} evaluates to true (see below) without raising any dynamic error or type error. Evaluation of {test} is performed as defined in [XPath 2.0], with the following conditions:
1 A data model instance (see [XDM]) is constructed in the following way:
1.1 The element information item E is validated with respect to its ·governing element declaration·, as defined in Element Locally Valid (Element) (§3.3.4), if the ·governing element declaration· exisits, otherwise against its ·governing type definition·, as defined in Element Locally Valid (Complex Type) (§3.4.4), except that for the element information item itself (though not for its element information item descendents), clause 6 of Element Locally Valid (Complex Type) (§3.4.4) is skipped. (Informally, the element is validated normally, except that assertions are not checked.)
Note: It is a consequence of this rule that the [attributes] and [children] of E will be validated in the usual way.
1.2 A "partial" ·post-schema-validation infoset· describing the results of this partial validation of E is constructed. The ·post-schema-validation infoset· properties of E's [children] and [attributes] are defined in the usual way. On the element information item itself, all ·post-schema-validation infoset· properties are supplied as described elsewhere in this specification if their values are known. The element's [validity] property is given the value invalid if and only if the element is known to be invalid; otherwise it is given the value notKnown. The element's [validation attempted] property is given the value partial.
Note: Since the assertions of its ·governing type definition· have not been checked, E has been only partially validated, and can be known to be invalid, but not known to be valid. The values of the [validity] and [validation attempted] properties are set accordingly.
1.3 From the "partial" ·post-schema-validation infoset·, a data model instance is constructed as described in [XDM]. The root node of the [XDM] instance is constructed from E; the data model instance contains only that node and nodes constructed from the [attributes], [children], and descendants of E.
Note: It is a consequence of this construction that attempts to refer, in an assertion, to the siblings or ancestors of E, or to any part of the input document outside of E itself, will be unsuccessful.
1.4 If all of the following are true:
1.4.1 E's [validity] in the "partial" ·post-schema-validation infoset· is not invalid;
1.4.2 E's [nil] in the "partial" ·post-schema-validation infoset· does not exist or has value false;
then the typed-value of the root node is changed to a sequence consisting of E's [schema actual value] (if it is an atomic value) or of the items in E's [schema actual value] (if it is a list value).
Note:  This clause provides type information to simple contents of elements, to make type-aware comparisons and operations possible without explicit casting in the XPath expressions.
2 The XPath expression {test} is evaluated, following the rules given in XPath Evaluation (§3.13.4), with the root node of the [XDM] instance as the context node.
3 The evaluation result is converted to either true or false as if by a call to the XPath fn:boolean function.
Note:  Although the rules just given describe how an ·post-schema-validation infoset· and a [XDM] instance are constructed, processors are not required to construct actual data structures representing them. However, the result of XPath evaluation must be the same as if such ·post-schema-validation infoset· and [XDM] instance data structures were constructed.
Validation Rule: XPath Evaluation
An XPath Expression property record X, with a context node E, is evaluated as defined in [XPath 2.0], with a static context as described in XPath Valid (§3.13.6) and with the following dynamic context:
1 The context item is E.
2 The context position is 1.
3 The context size is 1.
4 The variable values is the empty set.
5 The function implementations include an implementation of every function in the function signatures of the static context. See XPath Valid (§3.13.6).
6 The current dateTime is ·implementation-defined·, but is constant during an ·assessment· episode.
7 The implicit timezone is ·implementation-defined·, but is constant during an ·assessment· episode.
8 The available documents is the empty set.
Note: [XPath 2.0] does not currently require support for the precisionDecimal datatype, but conforming XPath processors are allowed to support additional primitive data types, including precisionDecimal. For interoperability, it is recommended that XPath processors intending to support precisionDecimal as an additional primitive data type follow the recommendations in [bib-chamberlin-2006]. If the XPath processor used to evaluate XPath expressions supports precisionDecimal, then any precisionDecimal values in the ·post-schema-validation infoset· should be labeled as xsd:precisionDecimal in the data model instance and handled accordingly in XPath. If the XPath processor does not support precisionDecimal, then any precisionDecimal values in the ·post-schema-validation infoset· should be mapped into decimal, unless the numericalValue is not a decimal number (for example, it is positiveInfinity, negativeInfinity, or notANumber), in which case they should be mapped to float. Whether this is done by altering the type information in the partial ·post-schema-validation infoset·, or by altering the usual rules for mapping from a ·post-schema-validation infoset· to an [XDM] data model instance, or by treating precisionDecimal as an unknown type which is coerced as appropriate into decimal or float by the XPath processor, is ·implementation-defined· and out of scope for this specification. As a consequence of the above variability, it is possible that XPath expressions that perform various kinds of type introspections will produce different results when different XPath processors are used. If the schema author wishes to ensure interoperable results, such introspections will need to be avoided.

3.13.5 Assertion Information Set Contributions

None as such.

3.13.6 Constraints on Assertion Schema Components

All assertions (see Assertions (§3.13)) must satisfy the following constraints.

Schema Component Constraint: Assertion Properties Correct
The values of the properties of an assertion must be as described in the property tableau in The Assertion Schema Component (§3.13.1), modulo the impact of Missing Sub-components (§5.3).
Schema Component Constraint: Test Value OK
Note: This constraint imposes distinct obligations on conforming schemas and on conforming processors.
An XPath expression in a conforming schema must, if governed by this constraint, satisfy Schema Component Constraint XPath Valid (§3.13.6).
Note: The {test} properties of Assertion and the {test} properties of Type Alternatives are governed by this constraint, as are any other properties whose definitions require that they satisfy this constraint. The XPath expressions used in identity constraints are not governed by this constraint.
A conforming processor must accept and process any XPath expression conforming to the "required subset" of [XPath 2.0] defined by the following grammar.
Note: Any XPath expression valid according to [XPath 2.0] may appear in a conforming schema. Conforming processors may but are not required to support XPath expressions not belonging to the required subset of XPath.
An XPath expression belongs to the required subset of XPath if and only if all of the following are true:
1 The {expression} property of the XPath Expression is a valid XPath expression, as defined in [XPath 2.0].
2 One of the following must be true:
2.1 It conforms to the following extended BNF:
Test XPath expressions
[9]    Test    ::=    ExprSingle
[10]    ExprSingle    ::=    QuantifiedExpr | IfExpr | OrExpr
[11]    QuantifiedExpr    ::=    ("some" | "every") "$" VarName "in" ValueExpr ("," "$" VarName "in" ValueExpr)* "satisfies" ExprSingle
[12]    VarName    ::=    QName
[13]    IfExpr    ::=    "if" "(" ExprSingle ")" "then" ExprSingle "else" ExprSingle
[14]    OrExpr    ::=    AndExpr ( 'or' AndExpr )*
[15]    AndExpr    ::=    BooleanExpr ( 'and' BooleanExpr )*
[16]    BooleanExpr    ::=    '(' ExprSingle ')' |
BooleanFunction |
( ValueFunction | SimpleValue) Comparator ValueExpr |
UnionExpr ( Comparator ValueExpr )?
[17]    BooleanFunction    ::=    QName '(' ( ExprSingle ( ',' ExprSingle )* )? ')'
[18]    Comparator    ::=    '=' | '!=' | '<' | '<=' | '>' | '>='
[19]    ValueExpr    ::=    ValueFunction | SimpleValue | UnionExpr
[20]    ValueFunction    ::=    QName '(' ValueExpr? ')'
[21]    SimpleValue    ::=    ConstructorFunction | StringLiteral | IntegerLiteral
[22]    ConstructorFunction    ::=    QName '(' StringLiteral ')'
[23]    StringLiteral    ::=    ('"' (EscapeQuot | [^"])* '"') | ("'" (EscapeApos | [^'])* "'")
[24]    IntegerLiteral    ::=    [\-+]?[0-9]+
[25]    EscapeQuot    ::=    '""'
[26]    EscapeApos    ::=    "''"
[27]    UnionExpr    ::=    PathExpr ( '|' PathExpr )*
[28]    PathExpr    ::=    ('.//')? ( StepExpr '/' )* ( StepExpr | '@' NameTest)
[29]    StepExpr    ::=    ('.' | NameTest ) ( '[' PredicateExpr ']' )*
[30]    PredicateExpr    ::=    ExprSingle | PositionLiteral
[31]    PositionLiteral    ::=    [0-9]+
2.2 It is an XPath expression involving the child and/or attribute axes whose abbreviated form is as given above.
Note: For readability, [XPath 2.0] allows whitespace to be used between tokens in XPath expressions, even though this is not explicitly shown in the grammar. For details of whitespace handling, consult [XPath 2.0].
3 If part of the restricted XPath matches QName in the BooleanFunction production, then it identifies one of the following functions defined in the [Functions and Operators] specification: fn:true, fn:false and fn:not.
4 If part of the restricted XPath matches QName in the ValueFunction production production, then it identifies one of the following functions defined in the [Functions and Operators] specification: fn:data, fn:local-name, fn:namespace-uri, fn:count, fn:max and fn:min.
5 If part of the restricted XPath matches the ConstructorFunction production, then all of the following are true:
5.1 The piece that matches QName identifies a simple type definition.
5.2 The ·normalized value· of the piece that matches StringLiteral is locally ·valid· with respect to the simple type definition identified in the above step, as per String Valid (§3.16.4).
Note:  Implementations may choose to support a bigger subset of [XPath 2.0].
Note: The definition of PredicateExpr given above may be more general than is desirable.

Editorial Note: Priority Feedback Request

Earlier drafts of this specification defined a more restricted form of the non-terminal PredicateExpr (shown below). The XML Schema Working Group is not certain whether to retain the more comprehensive definition given above in the required minimum subset of XPath which all processors must implement, or to return to the earlier restricted form. The Working Group solicits input from implementors and users on this issue.

Alternate definition of Predicate Expressions
[32]    PredicateExpr    ::=    PredicateOr | PositionLiteral
[33]    PredicateOr    ::=    PredicateAnd ( 'or' PredicateAnd )*
[34]    PredicateAnd    ::=    PredicateBoolean ( 'and' PredicateBoolean )*
[35]    PredicateBoolean    ::=    '(' PredicateOr ')'
| PBooleanFunction
| ( PValueFunction | ConstructorFunction ) Comparator PredicateValue
| '@' NameTest ( Comparator PredicateValue )?
[36]    PBooleanFunction    ::=    QName '(' PredicateOr? ( ',' PredicateOr )* ')'
[37]    PValueFunction    ::=    QName '(' PredicateValue? ')'
[38]    PredicateValue    ::=    ConstructorFunction | '.' | '@' NameTest
Schema Component Constraint: XPath Valid
For an XPath Expression property record to be valid, all of the following must be true:
1 The {expression} of X is a valid XPath expression, as defined in [XPath 2.0].
2 X does not produce any static error, under the following conditions:
2.1 The Static Typing Feature is disabled.
2.2 The static context is given as follows:
2.2.4 The default function namespace is http://www.w3.org/2005/xpath-functions.
2.2.5 The in-scope schema definitions are those components that are present in every schema by definition, as defined in Built-in Attribute Declarations (§3.2.7), Built-in Complex Type Definition (§3.4.7) and Built-in Simple Type Definitions (§3.16.7).
2.2.6 The in-scope variables is the empty set.
2.2.7 The context item static type is not applicable, because the Static Typing Feature is disabled.
2.2.8 The function signatures are ·implementation-defined·. However, if X belongs to a Type Alternative or an Assertion, then the function signatures include functions mentioned in Test Value OK (§3.13.6).
2.2.9 The statically known collations are ·implementation-defined·, but always include the Unicode codepoint collation (http://www.w3.org/2005/xpath-functions/collation/codepoint) defined by [Functions and Operators].
2.2.10 The default collation is the Unicode codepoint collation.
2.2.11 The base URI is the {base URI} of X.
2.2.12 The statically known documents is the empty set.

previous sub-section next sub-section3.14 Notation Declarations

Notation declarations reconstruct XML NOTATION declarations.

Example
<xs:notation name="jpeg" public="image/jpeg" system="viewer.exe">
The XML representation of a notation declaration.

3.14.1 The Notation Declaration Schema Component

The notation declaration schema component has the following properties:

Schema Component: Notation Declaration, a kind of Annotated Component
{annotations}
A sequence of Annotation components.
{name}
An xs:NCName value. Required.
{target namespace}
An xs:anyURI value. Optional.
{system identifier}
An xs:anyURI value. Required if {public identifier} is ·absent·, otherwise ({public identifier} is present) optional.
{public identifier}
A publicID value. Required if {system identifier} is ·absent·, otherwise ({system identifier} is present) optional.

As defined in [XML 1.1].

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. An element or attribute information item with its ·governing· type definition or its ·actual member type definition· derived from the NOTATION simple type is ·valid· only if its value was among the enumerations of such simple type. As a consequence such a value is required to be the {name} of a notation declaration.

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

3.14.2 XML Representation of Notation Declaration Schema Components

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:

XML Representation Summary: notation Element Information Item

<notation
  id = ID
  name = NCName
  public = token
  system = anyURI
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</notation>

Notation Declaration Schema Component
Property
Representation
 
 
The ·actual value· of the targetNamespace [attribute] of the parent schema element information item.
 
The ·actual value· of the system [attribute], if present, otherwise ·absent·.
 
The ·actual value· of the public [attribute], if present, otherwise ·absent·.
 
Example
<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>

3.14.3 Constraints on XML Representations of Notation Declarations

Schema Representation Constraint: Notation Definition Representation OK
In addition to the conditions imposed on <notation> element information items by the schema for schema documents, the corresponding notation definition must satisfy the conditions set out in Constraints on Notation Declaration Schema Components (§3.14.6).

3.14.4 Notation Declaration Validation Rules

None as such.

3.14.5 Notation Declaration Information Set Contributions

Schema Information Set Contribution: Validated with Notation
Whenever an attribute information item is ·valid· with respect to a NOTATION, in the ·post-schema-validation infoset· its parent element information item has the following properties:
PSVI Contributions for element information items
[notation]
An ·item isomorphic· to the notation declaration whose {name} and {target namespace} match the ·local name· and ·namespace name· (as defined in QName Interpretation (§3.17.3)) of the attribute item's ·actual value·
[notation system]
The value of the {system identifier} of that notation declaration.
[notation public]
The value of the {public identifier} of that notation declaration.
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.
Note: Element as well as attribute information items may be ·valid· with respect to a NOTATION, but only attribute information items cause a notation declaration to appear in the ·post-schema-validation infoset· as a property of their parent.

3.14.6 Constraints on Notation Declaration Schema Components

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

Schema Component Constraint: Notation Declaration Correct
The values of the properties of a notation declaration must be as described in the property tableau in The Notation Declaration Schema Component (§3.14.1), modulo the impact of Missing Sub-components (§5.3).

previous sub-section next sub-section3.15 Annotations

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

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

3.15.1 The Annotation Schema Component

The annotation schema component has the following properties:

Schema Component: Annotation, a kind of Component
{application information}
A sequence of Element infoitems.
{user information}
A sequence of Element infoitems.
{attributes}
A set of Attribute infoitems.

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

The name [Definition:]  Annotated Component covers all the different kinds of component which may have annotations.

3.15.2 XML Representation of Annotation Schema Components

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:

XML Representation Summary: annotation Element Information Item

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

Annotation Schema Component
Property
Representation
 
A sequence of the <appinfo> element information items from among the [children], in order, if any, otherwise the empty sequence.
 
A sequence of the <documentation> element information items from among the [children], in order, if any, otherwise the empty sequence.
 
A set of attribute information items, namely those allowed by the attribute wildcard in the type definition for the <annotation> item itself or for the enclosing items which correspond to the component within which the annotation component is located.

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

Virtually every kind of schema component defined in this specification has an {annotations} property. When the component is described in a schema document, the mapping from the XML representation of the component to the Annotation components in the appropriate {annotations} property follows the rules described in the next paragraph.

[Definition:]  The annotation mapping of a set of element information items ES is a sequence of annotations AS, with the following properties:
1 For every <annotation> element information item among the [children] of any element information item in ES, there is a corresponding Annotation component in AS.
Note: As described above (earlier in this section), the {attributes} property of each Annotation component includes any attribute information items on the parent (and possibly ancestors) of the <annotation> element which have a [namespace name] different from the XSDL namespace.
2 If there are any attribute information items among the [attributes] of any element information item E in ES with a [namespace name] different from the XSDL namespace, which are not included in the {attributes} of any Annotation from clause 1, then there is an Annotation component in AS whose {application information} and {user information} are the empty sequence and whose {attributes} contains all and only such attribute information items among E's [attributes].
3 AS contains no other Annotation components.
[Definition:]  The annotation mapping of a single element information item is the ·annotation mapping· of the singleton set containing that element.
Note:  The order of Annotation components within the sequence is ·implementation-dependent·.
Note:  When the input set has more than one member, the Annotation components in the resulting sequence do not record which element in the set they correspond to. The attribute information items in the {attributes} of any Annotation similarly do not indicate which element information item in the schema document was their parent.

3.15.3 Constraints on XML Representations of Annotations

Schema Representation Constraint: Annotation Definition Representation OK
In addition to the conditions imposed on <annotation> element information items by the schema for schema documents, the corresponding annotation must satisfy the conditions set out in Constraints on Annotation Schema Components (§3.15.6).

3.15.4 Annotation Validation Rules

None as such.

3.15.5 Annotation Information Set Contributions

None as such: the addition of annotations to the ·post-schema-validation infoset· is covered by the ·post-schema-validation infoset· contributions of the enclosing components.

3.15.6 Constraints on Annotation Schema Components

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

Schema Component Constraint: Annotation Correct
The values of the properties of an annotation must be as described in the property tableau in The Annotation Schema Component (§3.15.1), modulo the impact of Missing Sub-components (§5.3).

previous sub-section next sub-section3.16 Simple Type Definitions

Note: This section consists of a combination of copies of normative material from [XML Schema: Datatypes], for local cross-reference purposes, and material unique to this specification, relating to the interface between schema components defined in this specification and the simple type definition component.

Simple type definitions prov