W3C

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

Editor's Draft 11 January 2011

This version:
../structures/
Latest version:
http://www.w3.org/TR/xmlschema11-1/
Previous version:
http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/
Editors (Version 1.1):
Shudi (Sandy) Gao 高殊镝, IBM <sandygao@ca.ibm.com>
C. M. Sperberg-McQueen, Black Mesa Technologies LLC <cmsmcq@blackmesatech.com>
Henry S. Thompson, University of Edinburgh <ht@inf.ed.ac.uk>
Editors (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.

Copyright © 2011 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

...

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 member-only review version which will in due course be published as a↑ W3C Proposed Recommendation ↓specifies↓ ↑specifying↑ the W3C XML Schema Definition Language (XSD) 1.1. It ↑has no formal standing within W3C; it↑ is here made available for review by W3C members↓ and the public↓. 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 created on 11 January 2011. It reflects (unless otherwise noted elsewhere) all decisions on this document made by the Working Group through 4 November 2010 (with the exception of part of the group's decision on bug 11219). The document thus incorporates all decisions made by the Working Group to date, with the exception noted. A proposed wording change for the note following Element Locally Valid (Element) (§3.3.4.3) is shown as 'non-status-quo' text. It has not gone through a full cycle of editorial revisions and is subject to change. ↑

↑
It also includes the following proposal(s) for changes to the wording of the spec:
↑
This draft was published on 11 January 2011. The major revisions since the previous public working draft include the following:

For those primarily interested in the changes since version 1.0, the appendix Changes since version 1.0 (non-normative) (§G) 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.

The Last Call review period for this document extends until 31 December 2009. 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 is a "feature at risk": the feature may be retained as is or dropped, depending on the feedback received from readers, schema authors, schema users, and implementors.

Publication as a ↓Proposed Recommendation↓↑Editors' 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.

The W3C XML Schema Working Group intends to request advancement of this specification and publication as a Proposed Recommendation (bypassing the usual Candidate Recommendation phase) as soon after 31 December 2009 as the following conditions are met. The expected Proposed Recommendaton may include editorial changes and may possibly remove features identified in this draft as being at risk. At the time this Last Call Working Draft was published, no interoperability or implementation report had yet been prepared.

This document has been produced by the W3C XML Schema Working Group as part of the W3C XML Activity. The goals of XSD 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.

The presentation of this document has been augmented to identify changes from a previous version, controlled by dg-b11222.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

XSD Namespaces · Namespaces with Special Status · Conventional Namespace Bindings · Schema Language Identifiers
    1.4 Dependencies on Other Specifications
    1.5 Documentation Conventions and Terminology
2 Conceptual Framework
    2.1 Overview of XSD
    2.2 XSD Abstract Data Model
Type Definition Components · Declaration Components · Model Group Components · Constraint Components · Group Definition Components · Annotation Components
    2.3 Constraints and Validation Rules
    2.4 Conformance
    2.5 Schema-validity and documents
    2.6 Names and Symbol Spaces
    2.7 Schema-Related Markup in Documents Being Validated
xsi:type · xsi:nil · xsi:schemaLocation, xsi:noNamespaceSchemaLocation
    2.8 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
Basic concepts of schema construction and composition · Conditional inclusion · Assembling a schema for a single target namespace from multiple schema definition documents (<include>) · Including modified component definitions (<redefine>) · Overriding component definitions (<override>) · References to schema components across namespaces (<import>)
    4.3 Layer 3: Schema Document Access and Web-interoperability
Standards for representation of schemas and retrieval of schema documents on the Web · How schema definitions are located on the Web
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 Outcome Tabulations (normative)
    B.1 Validation Rules
    B.2 Contributions to the post-schema-validation infoset
    B.3 Schema Representation Constraints
    B.4 Schema Component Constraints
C Terminology for implementation-defined features (normative)
    C.1 Subset of the Post-schema-validation Infoset
    C.2 Terminology of schema construction

Identifying locations where components are sought · Identifying methods of indirection · Identifying the key for use in indirection · Identifying when to stop searching · Identifying how to react to failure
    C.3 Other Implementation-defined Features
D Required Information Set Items and Properties (normative)
E Checklists of implementation-defined and implementation-dependent features (normative)
    E.1 Checklist of implementation-defined features
    E.2 Checklist of implementation-dependent features
F Stylesheets for Composing Schema Documents (Normative)
    F.1 Transformation for Chameleon Inclusion
    F.2 Transformation for xs:override
G Changes since version 1.0 (non-normative)
    G.1 Changes made since version 1.0
Relationship between XSD and other specifications · XSD versions · Changes to content models · Assertions and XPath · Derivation of complex types · Changes to complex type definitions · ID, IDREF, and related types · Simple type definitions · Element declarations · Attribute declarations · Component structure · The process of validation · post-schema-validation infoset · Conformance · Schema composition · Other substantive changes · Clarifications and editorial changes
    G.2 Issues not resolved
H Schema Components Diagram (non-normative)
I Glossary (non-normative)
J DTD for Schemas (non-normative)
K Analysis of the Unique Particle Attribution Constraint (non-normative)
L XSD Language Identifiers (non-normative)
M References
    M.1 Normative
    M.2 Non-normative
N Acknowledgements (non-normative)

... ...

3 Schema Component Details

... ... ...

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

        3.4.1 The Complex Type Definition Schema Component
        3.4.2 XML Representation of Complex Type Definition Schema Components
            3.4.2.1 Common Mapping Rules for Complex Type Definitions
            3.4.2.2 Mapping Rules for Complex Types with Simple Content
            3.4.2.3 Mapping Rules for Complex Types with Complex Content
            3.4.2.4 Mapping Rule for Attribute Uses Property
            3.4.2.5 Mapping Rule for Attribute Wildcard Property
            3.4.2.6 Examples of Complex Type Definitions
        3.4.3 Constraints on XML Representations of Complex Type Definitions
        3.4.4 Complex Type Definition Validation Rules
            3.4.4.1 Locally Declared Type and Context-determined Type Table
            3.4.4.2 Element Locally Valid (Complex Type)
            3.4.4.3 Element Sequence Locally Valid (Complex Content)
            3.4.4.4 Attribution
            3.4.4.5 Conditional Type Substitutable
        3.4.5 Complex Type Definition Information Set Contributions
            3.4.5.1 Attribute Default Value
            3.4.5.2 Match Information
        3.4.6 Constraints on Complex Type Definition Schema Components
            3.4.6.1 Complex Type Definition Properties Correct
            3.4.6.2 Derivation Valid (Extension)
            3.4.6.3 Derivation Valid (Restriction, Complex)
            3.4.6.4 Content Type Restricts (Complex Content)
            3.4.6.5 Type Derivation OK (Complex)
        3.4.7 Built-in Complex Type Definition

Complex Type Definitions provide for:

... ... ...
... ...

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 <simpleContent> alternative is chosen, the <complexType> element must not have mixed = true.
2
↑
If <restriction> is present under <simpleContent>, then the [children] of <restriction> must not include any two elements with the same expanded name in the Schema (xs) namespace, unless that expanded name is one of xs:enumeration, xs:pattern, or xs:assert.
↑
3 If <openContent> is present and has mode ≠ 'none', then there must be an <any> among the [children] of <openContent>.
4 If <openContent> is present and has mode = 'none', then there must not be an <any> among the [children] of <openContent>.
5 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.
... ... ... ...
... ... ... ... ... ... ... ... ... ... ...

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

        3.16.1 The Simple Type Definition Schema Component
        3.16.2 XML Representation of Simple Type Definition Schema Components
            3.16.2.1 Common mapping rules for Simple Type Definitions
            3.16.2.2 Mapping Rules for Atomic Simple Type Definitions
            3.16.2.3 Mapping Rules for Lists
            3.16.2.4 Mapping Rules for Unions
        3.16.3 Constraints on XML Representations of Simple Type Definitions
        3.16.4 Simple Type Definition Validation Rules
        3.16.5 Simple Type Definition Information Set Contributions
        3.16.6 Constraints on Simple Type Definition Schema Components
            3.16.6.1 Simple Type Definition Properties Correct
            3.16.6.2 Derivation Valid (Restriction, Simple)
            3.16.6.3 Type Derivation OK (Simple)
            3.16.6.4 Simple Type Restriction (Facets)
        3.16.7 Built-in Simple Type Definitions
            3.16.7.1 xs:anySimpleType
            3.16.7.2 xs:anyAtomicType
            3.16.7.3 xs:error
            3.16.7.4 Built-in primitive datatypes
            3.16.7.5 Other built-in datatypes
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 provide for constraining character information item [children] of element and attribute information items.

... ... ...
... ...

3.16.3 Constraints on XML Representations of Simple Type Definitions

Schema Representation Constraint: Simple Type Definition Representation OK
In addition to the conditions imposed on <simpleType> element information items by the schema for schema documents, all of the following must be true:
1
↓
With the exception of <enumeration>, <pattern>, and <assert>, the [children] of <restriction> do not contain more than one element information item with the same name.
↓
↑
No two elements among the [children] of <restriction> have the same expanded name in the Schema (xs) namespace, unless that expanded name is one of xs:enumeration, xs:pattern, or xs:assert.
↑
↑
Note: That is, most of the facets for simple types defined by this specification are forbidden to occur more than once. But <enumeration>, <pattern>, and <assert> may occur multiple times, and facets defined in other namespaces and made available as extensions to this specification may occur multiple times.
↑
2 If the <restriction> alternative is chosen, it has either a base [attribute] or a <simpleType> among its [children], but not both.
3 If the <list> alternative is chosen, it has either an itemType [attribute] or a <simpleType> among its [children], but not both.
4 If the <union> alternative is chosen, either it has a non-empty memberTypes [attribute] or it has at least one simpleType [child].
... ... ... ...
...
... ...