W3C

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

W3C Working Draft 20 June 2008

This version:
http://www.w3.org/TR/2008/WD-xmlschema11-1-20080620/
Latest version:
http://www.w3.org/TR/xmlschema11-1/
Previous versions:
http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/ 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

XML Schema: StructuresThis document specifies the XML Schema definition languageXML Schema Definition Language, which offers facilities for describing the structure and constraining the contents of XML 1.0 documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in an XML 1.0 vocabulary and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML 1.0 document type definitions (DTDs). This specification depends on XML SchemaXML 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 XML Schema 1.1W3C XML Schema Definition Language (XSD) 1.1. It is here made available for review by W3C members and the public. It is intended to give an indication of the W3C XML Schema Working Group's intentions for this new version of the XML Schema language and our progress in achieving them. It attempts to be complete in indicating what will change from version 1.0, but does not specify in all cases how things will change.XSD 1.1 retains all the essential features of XSD 1.0, but adds several new features to support functionality requested by users, fixes many errors in XSD 1.0, and clarifies wording.

This draft was published on 20 June 2008. The previous working draft of 30 August 2007 was a Last-Call Working Draft which elicited numerous comments and suggestions for improvements. All substantive issues have now been resolved, although some editorial issues remain open. The major revisions since the previous draft include the following:
  • The minimal subset of XPath which processors were required to support for assertions has been eliminated; processors must support all of XPath.
  • A new wildcard keyword ##definedSibling has been added to allow a wildcard to match any element except one mentioned explicitly elsewhere in the current content model.
  • The definitions of must and ·error· have been revised to require that processors detect and report errors (although the quality and level of detail of the error messages are not constrained).
  • An <override> element has been defined to allow the declarations or definitions of specified components in other schema documents to be overridden.
  • The <redefine> element has been ·deprecated·.
  • XML Representation Constraints no longer refer to the component level; they can now be checked for schema documents in isolation.
  • Numerous editorial changes and clarifications have been made and numerous small errors corrected.

For those primarily interested in the changes since version 1.0, the appendix Changes since version 1.0 (non-normative) (§H) appendix, which summarizes both changes already made and also those in prospect, with links to the relevant sections of this draft, is the recommended starting point. It summarizes both changes made since XSD 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.

Please send comments on this Working Draft to www-xml-schema-comments@w3.org (archive).

The Last Call review period for this document extends until 12 September 2008. 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 the XML Schema language versionXSD 1.1 are discussed in the document Requirements for XML Schema 1.1 document. 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.

The presentation of this document has been augmented to identify changes from a previous version, controlled by dg-statusquo-color-1.0.xml. Three kinds of changes are highlighted: new, added text, changed text, and deleted text.


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 XML SchemaXSD
    2.2 XML SchemaXSD 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
    3.18 Auxiliary Components
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 SchemasSchema 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 (normative)
    D.1 Subset of the Post-schema-validation Infoset
    D.2 Terminology of schema construction
    D.3 Other Implementation-defined Features
E Required Information Set Items and Properties (normative)
F Checklists of implementation-defined and implementation-dependent features (normative)
    F.1 Checklist of implementation-defined features
    F.2 Checklist of implementation-dependent features
G Stylesheets for Composing Schema Documents (Normative)
    G.1 Stylesheet for xs:override
H Changes since version 1.0 (non-normative)
    H.1 Changes already made since version 1.0
    H.2 Outstanding issuesIssues not resolved
I Checking content-type restriction (non-normative)
J Schema Components Diagram (non-normative)
K Glossary (non-normative)
L DTD for Schemas (non-normative)
M Analysis of the Unique Particle Attribution Constraint (non-normative)
N References (non-normative)
O XSD Language Identifiers (non-normative)
P Acknowledgements (non-normative)

1 Introduction

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

Chapter 2 presents a Conceptual Framework (§2) for XML SchemasXSD, including an introduction to the nature of XML SchemasXSD schemas and an introduction to the XML SchemaXSD 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 XML SchemaXSD schema for an XML SchemaXSD 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 SchemasSchema 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) (§L) and a Glossary (non-normative) (§K).

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 vocabulary specified here for use in schema documents.
  • 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 XML schemasXSD schemas and their component parts, provide an inventory of XML markup constructs with which to represent schemas, and define the application of schemas to XML documents.

The purpose of an XML Schema: StructuresXSD 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 maycan 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 XML Schema: Structures formalism defined here to express syntactic, structural and value constraints applicable to its document instances. The XML Schema: StructuresXSD formalism allows a useful level of constraint checking to be described and implemented for a wide spectrum of XML applications. However, the language defined by this specification does not attempt to provide all the facilities that might be needed by any applicationapplications. Some applications maywill require constraint capabilities not expressible in this language, and so maywill need to perform their own additional validations.

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

        1.3.1 XSD Namespaces
            1.3.1.1 The Schema Namespace (xs)
            1.3.1.2 The Schema Instance Namespace (xsi)
            1.3.1.3 The Schema Versioning Namespace (vc)
        1.3.2 Namespaces with Special Status
        1.3.3 Conventional Namespace Bindings
        1.3.4 Schema Language Identifiers

1.3.1 XSD 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: 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 XSD 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 namespace whose name is http://www.w3.org/2001/XMLSchema-instance. For brevity, the text and examples in this specification use the prefix xsi: to stand for this namespace; in practice, any prefix can be used.

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

1.3.1.3 The Schema Versioning Namespace (vc)

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

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

1.3.2 Namespaces with Special Status

Except as otherwise specified elsewhere in this specification, if components are ·present· in a schema, or source declarations are included in an XSD schema document, for components in any of the following namespaces, then the components, or the declarations, should agree with the descriptions given in the relevant specifications and with the declarations given in any applicable XSD schema documents maintained by the World Wide Web Consortium for these namespaces. If they do not, the effect is ·implementation-dependent· and not defined by this specification.
  • http://www.w3.org/XML/1998/namespace
  • http://www.w3.org/2001/XMLSchema
  • http://www.w3.org/2001/XMLSchema-instance
  • http://www.w3.org/2007/XMLSchema-versioning
Note: Depending on implementation details, some processors may be able to process and use (for example) variant forms of the schema for schema documents devised for specialized purposes; if so, this specification does not forbid the use of such variant components. Other processors, however, may find it impossible to validate and use alternative components for these namespaces; this specification does not require them to do so. Users who have an interest in such specialized processing should be aware of the attending interoperability problems and should exercise caution.
This flexibility does not extend to the components described in this specification or in [XML Schema: Datatypes] as being included in every schema, such as those for the primitive and other built-in datatypes. Since those components are by definition part of evey schema, it is not possible to have different components with the same expanded names present in the schema without violating constraints defined elsewhere against multiple components with the same expanded names.

Components and source declarations must not specify http://www.w3.org/2000/xmlns/ as their target namespace. If they do, then the schema and/or schema document is in ·error·.

Note: Any confusion in the use, structure, or meaning of this namespace would have catastrophic effects on the interpretability of this specification.

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

1.3.4 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 XSD 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 XSD version 1.0 and http://www.w3.org/XML/XMLSchema/v1.1 identifies XSD 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 XSD specification. For example, http://www.w3.org/XML/XMLSchema/v1.0/2e identifies the second edition of XSD 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 XSD 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 XSD 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 XSD version 1.0 Second Edition Proposed Edited Recommendation (PER) published on 18 March 2004.

Please see XSD Language Identifiers (non-normative) (§O) 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], [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: It is a consequence of the rule just given that 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. The rules just given ensure that 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.

Unless otherwise noted, the entire text of this specification is normative. Exceptions include:
  • notes
  • sections explicitly marked non-normative
  • examples and their commentary
  • informal descriptions of the consequences of rules formally and normatively stated elsewhere (such informal descriptions are typically introduced by phrases like "Informally, ..." or "It is a consequence of ... that ...")
Explicit statements that some material is normative are not to be taken as implying that material not so described is non-normative (other than that mentioned in the list just given).

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

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

For components C1 and C2, an expression of the form "C1 . {example property 1} = C2 . {example property 2}" means that C1 and C2 have the same value for the property (or properties) in question. Similarly, "C1 = C2" means that C1 and C2 are identical, and "C1.{example property} = C2" that C2 is the value of C1.{example property}.

The correspondence between an element information item which is part of the XML representation of a schema and one or more schema components is presented in a tableau which illustrates the element information item(s) involved. This is followed by a tabulation of the correspondence between properties of the component and properties of the information item. Where context may determinedetermines which of several different components may arisecorresponds 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 SchemasSchema Documents (Structures) (normative) (§A). In the case of apparent conflict, the Schema for SchemasSchema 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>.

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

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

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

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

Note: General comments directed to all readers.

Following [XML 1.1], wWithin normative prose in this specification, the words may and, should, must and must not are defined as follows:

may
Conforming documents and XML Schema-aware processorsSchemas, schema documents, and processors are permitted to but need not behave as described.
should
It is recommended that schemas, schema documents, and 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 XML Schema-aware processors are required to behave as described; otherwise they are in error.
(Of schemas and schema documents:) Schemas and documents are required to behave as described; otherwise they are in ·error·.
(Of processors:) Processors are required to behave as described.
must not
Schemas, schema documents, and processors are forbidden to behave as described; schemas and documents which nevertheless do so are in ·error·.
error
A failure of a schema or schema document to conform to the rules of this specification.
Except as otherwise specified, processors must distinguish error-free (conforming) schemas and schema documents used in ·assessment· from those with errors; if a schema used in ·assessment· or a schema document used in constructing a schema is in error, processors must report the fact; if more than one is in error, it is ·implementation-dependent· whether more than one is reported as being in error. If one or more of the constraint codes given in Outcome Tabulations (normative) (§C) is applicable, it is ·implementation-dependent· how many of them, and which, are reported.
Note: Failure of an XML document to be valid against a particular schema is not (except for the special case of a schema document consulted in the course of building a schema) in itself a failure to conform to this specification and thus, for purposes of this specification, not an error.
Note: Notwithstanding the fact that (as just noted) failure to be schema-valid is not a violation of this specification and thus not strictly speaking an error as defined here, the names of the PSVI properties [schema error code] (for attributes) and [schema error code] (for elements) are retained for compatibility with other versions of this specification, and because in many applications of XSD, non-conforming documents are "in error" for purposes of those applications.
deprecated
A feature or construct defined in this specification described as deprecated is retained in this specification for compatibility with previous versions of the specification, and but its use is not advisable and schema authors should avoid its use if possible.
Deprecation has no effect on the conformance of schemas or schema documents which use deprecated features. Since deprecated features are part of the specification, processors must support them, although some processors may choose to issue warning messages when deprecated features are encountered.
Features deprecated in this version of this specification may be removed entirely in future versions, if any.

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

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

Note however that thisThis specification provides a definition further description of error and of conformant processors' responsibilities with respect to errors (seein Schemas and Schema-validity Assessment (§5)) which is considerably more complex than that of [XML 1.1].

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 may wish to firstwill 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 XML SchemaXSD

An XML SchemaXSD schema consistsis 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 maymay specify augmentations to those items and their descendants. This augmentation makes explicit information which may have been implicit in the original document, such as normalized and/or default values for attributes and elements and the types of element and attribute information items. 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.

As it is used in this specification, the term schema-validity assessment has two aspects:
1 Determining local schema-validity, that is whether an element or attribute information item satisfies the constraints embodied in the relevant components of an XML SchemaXSD 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 XML SchemaXSD Abstract Data Model

        2.2.1 Type Definition Components
            2.2.1.1 Type Definition Hierarchy
            2.2.1.2 Simple Type Definition
            2.2.1.3 Complex Type Definition
        2.2.2 Declaration Components
            2.2.2.1 Element Declaration
            2.2.2.2 Element Substitution Group
            2.2.2.3 Attribute Declaration
            2.2.2.4 Notation Declaration
        2.2.3 Model Group Components
            2.2.3.1 Model Group
            2.2.3.2 Particle
            2.2.3.3 Attribute Use
            2.2.3.4 Wildcard
        2.2.4 Identity-constraint DefinitionConstraint Components
            2.2.4.1 Identity-constraint Definition
            2.2.4.2 Type Alternative
            2.2.4.3 Assertion
        2.2.5 Group Definition Components
            2.2.5.1 Model Group Definition
            2.2.5.2 Attribute Group Definition
        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, XML SchemasXSD schemas can be described in terms of an abstract data model. In defining XML Schemasschemas in terms of an abstract data model, this specification rigorously specifies the information which must be available to a conforming XML SchemaXSD 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 comprisemake up the abstract data model of the schema. [Definition:]   An XML Schema is a set of ·schema components·[Definition:]   An XSD schema is a set of ·schema components·. There are 13 kinds of component in allseveral kinds of schema component, falling into three groups. The primary schema 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 schema components, which must have names, are as follows:

  • Attribute group definitions
  • Identity-constraint definitions
  • Type alternatives
  • Assertions
  • Model group definitions
  • Notation declarations

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

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

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

The name [Definition:]  Component covers all the different kinds of schema 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 maymay 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 may ·validate·.

An expanded name, as defined in [XML-Namespaces 1.1], is a pair consisting of a namespace name, which may be ·absent·, and a local name. The expanded name of any component with both a ·target namespace· property and a ·component name· property is the pair consisting of the values of those two properties. The expanded name of a declaration is used to help determine which information items will be ·governed· by the declaration.

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 may ·validate·is ·validated· with respect to an attribute declaration, a list of element information items may ·validate· with respect to a content model, and so on. The following sections briefly introduce the kinds of components in the schema abstract data model, other major features of the abstract model, and how they contribute to ·validation·.

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 a distinguished ·ur-type definition·, ·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:]  AThe type definition used as the basis for an ·extension· or ·restriction· is known as the base type definition of that definition.

[Definition:]  A type definition whose declarations or facets are in a one-to-one relation with those of another specified type definition, with each in turn restricting the possibilities of the one it corresponds to,A type defined with the same constraints as its ·base type definition·, or with more, is said to be a restriction. The specific restrictionsadded constraints might include narrowed ranges or reduced alternatives. Members of a type, A, whose definition is a ·restriction· of the definition of another type, B, are always locally valid against type B as well.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 distinguished complex type definition, the ur-type definition, whose name is anyType in the XML Schema namespace, is present in each ·XML Schema·, serving as the root of the type definition hierarchy for that schema.

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

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

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

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

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 some particular simpleits ·base type definition·. For the built-in primitive type definitions, this is [Definition:]  the simple ur-type definition, a special ·restriction· of the ·ur-type definition·, whose name is anySimpleType in the XML Schema namespace. The ·simple ur-type definition· is considered to have an unconstrained lexical space, and a value space consisting of the union of the value spaces of all the built-in primitive datatypes and the set of all lists of all members of the value spaces of all the built-in primitive datatypes. [Definition:]  A special ·restriction· of ·xs:anyType·, whose name is anySimpleType in the XSD namespace, is the root of the ·Type Definition Hierarchy· for all simple type definitions. ·xs:anySimpleType· has a lexical space containing all sequences of characters in the Universal Character Set (UCS) and a value space containing all atomic values and all finite-length lists of atomic values. As with ·xs:anyType·, this specification sometimes uses the qualified name xs:anySimpleType to designate this type definition. The built-in list datatypes all have ·xs:anySimpleType· as their ·base type definition·.

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

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

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

Simple types may also be defined[XML Schema: Datatypes] provides mechanisms for defining new simple type definitions by ·restricting· some primitive or ordinary datatype. It also provides mechanisms for constructing new simple type definitions whose members are lists of items themselves constrained by some other simple type definition, or whose membership is the union of the memberships of some other simple type definitions. Such list and union simple type definitions are also ·restrictions· of the ·simple ur-type definition··xs:anySimpleType·.

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 maymay require the [children] to contain neither element nor character information items (that is, to be empty),