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

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 1 March 2011. It reflects (unless otherwise noted elsewhere) all decisions on this document made by the Working Group through 4 February 2011. The document thus incorporates all decisions made by the Working Group to date. ↑

↑

It also includes the following proposal(s) for changes to the wording of the spec:

In the sections on the XML representation of components, reminders have been added that the constraints and mapping rules defined in those sections apply after, not before, pre-processing. This resolves issue 11179 minor editorial improvement : parent schema components of a named model group

↑

This draft was published on 1 March 2011. The major revisions since the previous public working draft include the following:

Enumerations, value constraints, and identity constraints now accept either equal or identical values as the same. This change resolves issue 9196 Enumeration and NaN
Changes have been made in section Constraints on XML Representations of Simple Type Definitions (§3.16.3) and section Constraints on XML Representations of Complex Type Definitions (§3.4.3) to make explicit that XML representations of extension facets (facets in namespaces other than the Schema namespace) are allowed to appear more than once in restrictions of simple types. This resolves issue 11222 src-simple-type.1 should allow duplicate elements from "##other" namespaces.
The text concerning xsi:type attributes and their effect has been clarified in Element Locally Valid (Element) (§3.3.4.3). In particular, the revisions attempt to make clearer just what happens in cases where the xsi:type attribute in the document instance cannot be used (because the type named is unknown, or otherwise not usable). This resolves issue 11219 Editorial revision of Element Locally Valid (Element).
Some errors in the XSLT stylesheet of appendix Transformation for Chameleon Inclusion (§F.1) have been corrected (resolving issues 8573 F.1 Stylesheet for chameleons invalid and 8574 F.1 Stylesheet for chameleons incomplete).
In the DTD for schema documents (DTD for Schemas (non-normative) (§J)), an error has been corrected in the declaration of the inheritable attribute of the xs:attribute element (resolving issue 11070 DTD for schema documents: inheritable declared as %URIref).
In the schema for schema documents, an error in the declaration of xs:group within the named model group xs:allModel has been corrected to make the type of xs:all a legal restriction of its base type and make the schema for schema documents conformant to this specification. This resolves issue 11092 Error in S4SD: complexType name="all" is not a valid restriction.
The XPath subset for selectors and fields in section Selector Value OK (§3.11.6.2) and Fields Value OK (§3.11.6.3) has been revised to align its tokenization rules better with [XPath 2.0]; this resolves issue 8454 Tokens in XPath subset for selectors/fields.
Some passages have been recast for clarity.
Several minor errors, typographic and otherwise, have been corrected.

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.

A test suite is available which tests each required and optional feature of XSD 1.1.
Each feature of the specification has been implemented successfully by at least two independent implementations.
The Working Group has responded formally to all issues raised against this document during the Candidate Recommendation period.

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-b11179.xml. Three kinds of changes are highlighted: ↑new, added text↑, ↑changed text↓, and ↓deleted text↓.

...

2 Conceptual Framework

... ... ...

2.4 Conformance

Note:

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

A ·schema document· conforms to this specification if and only if all of the following are true: ...

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. Because component correctness depends in part upon the other components present, the XML mapping rules defined in this specification do not always map conforming schema documents into components that satisfy all constraints. In some cases, the mapping will produce components which violate constraints imposed at the component level; in others, no component at all will be produced.

Note: In this version of this specification, Schema Representation Constraints concern only properties of the schema document which can be checked in isolation. In version 1.0 of this specification, some Schema Representation Constraints could not be checked against the schema document in isolation, and so it was not always possible to say, for a given schema document, whether it satisfied the constraints or not.

A schema conforms to this specification if and only if it consists of components which individually and collectively satisfy all the relevant constraints specified in this document, including but not limited to all the ·Schema Component Constraints·.

Note: This specification defines no API or other interface for interacting with schemas, so a conformance claim for a schema is not normally testable in any standardized way. However, if an interface is provided which enables a user to interrogate various properties of the schema and check their values, conformance can usefully be claimed for the schema.

This specification distinguishes several classes of conforming processors, which are defined in terms of the following concepts.

[Definition:] A validator (or instance validator) is a processor which ·validates· an XML instance document against a conforming schema and distinguishes between valid documents and others, for one or more of the definitions of validity (·root-validity·, ·deep validity·, or ·uniform validity·) defined below in section Schema-validity and documents (§2.5). Conforming validators may additionally support other definitions of validity defined in terms of the ·post-schema-validation infoset·.

[Definition:] A schema-validity assessor (or just assessor) is a processor which performs full or partial ·schema-validity assessment· of an XML instance document, element information item, or attribute information item, with reference to a conforming schema, and provides access to the entirety of the resulting ·post-schema-validation infoset·. The means by which an ·assessor· provides access to the ·post-schema-validation infoset· is ·implementation-defined·.

[Definition:] A general-purpose processor is a ·validator· or ·assessor· which accepts schemas represented in the form of XML documents as described in Layer 2: Schema Documents, Namespaces and Composition (§4.2).

Note: The ·Schema Representation Constraints· are to be enforced after, not before, the ↓conditional-inclusion pre-processing↓↑·conditional-inclusion pre-processing·↑ described in Conditional inclusion (§4.2.2)↑, the ·override pre-processing· described in Overriding component definitions (<override>) (§4.2.5), and the ·chameleon pre-processing· described in Assembling a schema for a single target namespace from multiple schema definition documents (<include>) (§4.2.3)↑.

[Definition:] A schema processor which is not a ·general-purpose· processor is a special-purpose 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 conform to this specification as ·special-purpose· but not as ·general-purpose· processors.

[Definition:] Web-aware processors are network-enabled processors which are not only ·general-purpose· 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.8) and How schema definitions are located on the Web (§4.3.2). .

Note: In version 1.0 of this specification the class of ·general-purpose· processors was termed "conformant to the XML Representation of Schemas". Similarly, the class of ·Web-aware· processors was called "fully conforming".

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

3 Schema Component Details

3.1 Introduction

        3.1.1 Components and Properties
        3.1.2 XML Representations of Components
        3.1.3 The Mapping between XML Representations and Components
        3.1.4 White Space Normalization during Validation

...

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) (§J)) and schema components. The key element information items in the XML representation of a schema are in the XSD 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:

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

A recurrent pattern in the XML representation of schemas may also be mentioned here. In many cases, the same element name (e.g. element or attribute or attributeGroup), serves both to define a particular schema component and to incorporate it by reference. In the first case the name attribute is required, in the second the ref attribute is required. These two usages are mutually exclusive, and sometimes also depend on context.

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↓↑·conditional-inclusion pre-processing·↑ described in Conditional inclusion (§4.2.2)↑, the ·override pre-processing· described in Overriding component definitions (<override>) (§4.2.5), and the ·chameleon pre-processing· described in Assembling a schema for a single target namespace from multiple schema definition documents (<include>) (§4.2.3)↑.

... ...

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

... ... ...

...

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 ↑after the appropriate ·pre-processing·↑ and ↑the↑ properties of the component are given in this section.

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. When no simple type definition is referenced or provided, the default is ·xs:anySimpleType·, which imposes no constraints at all.

...

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

3.3 Element Declarations

        3.3.1 The Element Declaration Schema Component
        3.3.2 XML Representation of Element Declaration Schema Components
            3.3.2.1 Common Mapping Rules for Element Declarations
            3.3.2.2 Mapping Rules for Top-Level Element Declarations
            3.3.2.3 Mapping Rules for Local Element Declarations
            3.3.2.4 References to Top-Level Element Declarations
            3.3.2.5 Examples of Element Declarations
        3.3.3 Constraints on XML Representations of Element Declarations
        3.3.4 Element Declaration Validation Rules
            3.3.4.1 Selected and Instance-specified Type Definitions
            3.3.4.2 Type Override and Valid Substitutability
            3.3.4.3 Element Locally Valid (Element)
            3.3.4.4 Element Locally Valid (Type)
            3.3.4.5 Validation Root Valid (ID/IDREF)
            3.3.4.6 Schema-Validity Assessment (Element)
        3.3.5 Element Declaration Information Set Contributions
            3.3.5.1 Assessment Outcome (Element)
            3.3.5.2 Validation Failure (Element)
            3.3.5.3 Element Declaration
            3.3.5.4 Element Validated by Type
            3.3.5.5 Element Default Value
            3.3.5.6 Inherited Attributes
        3.3.6 Constraints on Element Declaration Schema Components
            3.3.6.1 Element Declaration Properties Correct
            3.3.6.2 Element Default Valid (Immediate)
            3.3.6.3 Substitution Group OK (Transitive)
            3.3.6.4 Substitution Group

...

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 ↑after the appropriate ·pre-processing·↑ and ↑the↑ properties of the component(s) it corresponds to are given in this section.

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>

...

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

3.4 Complex Type Definitions

...

3.4.2 XML Representation of Complex Type Definition Schema Components

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 describes the mappings for the two cases in separate subsections. Common mapping rules are factored out and given in separate sections. ↑As always, the mapping rules given here apply after, not before, the appropriate ·pre-processing·.↑

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

Note: It is a consequence of the concrete syntax given above that a top-level type definition need consist of no more than a name, i.e. that <complexType name="anyThing"/> is allowed.

...

3.6 Attribute Group Definitions

        3.6.1 The Attribute Group Definition Schema Component
        3.6.2 XML Representation of Attribute Group Definition Schema Components
            3.6.2.1 XML Mapping Rule for Named Attribute Groups
            3.6.2.2 Common Rules for Attribute Wildcards
        3.6.3 Constraints on XML Representations of Attribute Group Definitions
        3.6.4 Attribute Group Definition Validation Rules
        3.6.5 Attribute Group Definition Information Set Contributions
        3.6.6 Constraints on Attribute Group Definition Schema Components

...

3.6.2 XML Representation of Attribute Group Definition Schema Components

3.6.2.1 XML Mapping Rule for Named Attribute Groups

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 ↑after the appropriate ·pre-processing·↑ and ↑the↑ properties of the component it corresponds to are given in this section.

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>

...

3.7 Model Group Definitions

        3.7.1 The Model Group Definition Schema Component
        3.7.2 XML Representation of Model Group Definition Schema Components
        3.7.3 Constraints on XML Representations of Model Group Definitions
        3.7.4 Model Group Definition Validation Rules
        3.7.5 Model Group Definition Information Set Contributions
        3.7.6 Constraints on Model Group Definition Schema Components

...

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 ↑after the appropriate ·pre-processing·↑ and ↑the↑ properties of the component it corresponds to are given in this section.

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>

...

3.8 Model Groups

        3.8.1 The Model Group Schema Component
        3.8.2 XML Representation of Model Group Schema Components
        3.8.3 Constraints on XML Representations of Model Groups
        3.8.4 Model Group Validation Rules
            3.8.4.1 Language Recognition by Groups
            3.8.4.2 Principles of Validation against Groups
            3.8.4.3 Element Sequence Valid
        3.8.5 Model Group Information Set Contributions
        3.8.6 Constraints on Model Group Schema Components
            3.8.6.1 Model Group Correct
            3.8.6.2 All Group Limited
            3.8.6.3 Element Declarations Consistent
            3.8.6.4 Unique Particle Attribution
            3.8.6.5 Effective Total Range (all and sequence)
            3.8.6.6 Effective Total Range (choice)

...

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 ↑after the appropriate ·pre-processing·↑ and ↑the↑ properties of the component they correspond to are given in this section.

XML Representation Summary: all Element Information Item et al.

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

...

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

...

3.10 Wildcards

        3.10.1 The Wildcard Schema Component
        3.10.2 XML Representation of Wildcard Schema Components
            3.10.2.1 Mapping from <any> to a Particle
            3.10.2.2 Mapping from <any> and <anyAttribute> to a Wildcard Component
        3.10.3 Constraints on XML Representations of Wildcards
        3.10.4 Wildcard Validation Rules
            3.10.4.1 Item Valid (Wildcard)
            3.10.4.2 Wildcard allows Expanded Name
            3.10.4.3 Wildcard allows Namespace Name
        3.10.5 Wildcard Information Set Contributions
        3.10.6 Constraints on Wildcard Schema Components
            3.10.6.1 Wildcard Properties Correct
            3.10.6.2 Wildcard Subset
            3.10.6.3 Attribute Wildcard Union
            3.10.6.4 Attribute Wildcard Intersection

...

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.

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 | ##definedSibling))
  processContents = (lax | skip | strict) : strict
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</any>

XML Representation Summary: anyAttribute Element Information Item

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

An <any> information item corresponds both to a wildcard component and to a particle containing that wildcard (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all). The mapping rules are given in the following two subsections. ↑As always, the mapping rules given here apply after, not before, the appropriate ·pre-processing·.↑

...

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

3.11 Identity-constraint Definitions

        3.11.1 The Identity-constraint Definition Schema Component
        3.11.2 XML Representation of Identity-constraint Definition Schema Components
        3.11.3 Constraints on XML Representations of Identity-constraint Definitions
        3.11.4 Identity-constraint Definition Validation Rules
        3.11.5 Identity-constraint Definition Information Set Contributions
        3.11.6 Constraints on Identity-constraint Definition Schema Components
            3.11.6.1 Identity-constraint Definition Properties Correct
            3.11.6.2 Selector Value OK
            3.11.6.3 Fields Value OK

...

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 ↑after the appropriate ·pre-processing·↑ and ↑the↑ properties of the component they correspond to are as follows:

XML Representation Summary: unique Element Information Item et al.

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

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

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

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

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

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

3.12 Type Alternatives

        3.12.1 The Type Alternative Schema Component
        3.12.2 XML Representation of Type Alternative Schema Components
        3.12.3 Constraints on XML Representations of Type Alternatives
        3.12.4 Type Alternative Validation Rules
        3.12.5 Type Alternative Information Set Contributions
        3.12.6 Constraints on Type Alternative Schema Components

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

...

3.12.2 XML Representation of Type Alternative Schema Components

The XML representation for a type alternative schema component is an <alternative> element information item. The correspondences between the properties of that information item ↑after the appropriate ·pre-processing·↑ and ↑the↑ 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>

Each <alternative> element maps to a Type Alternative component as follows.

XML Mapping Summary for Type Alternative Schema Component

Property

Representation

{test}

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

{type definition}

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.

{annotations}

The ·annotation mapping· of the <alternative> element, as defined in XML Representation of Annotation Schema Components (§3.15.2).

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

3.13 Assertions

        3.13.1 The Assertion Schema Component
        3.13.2 XML Representation of Assertion Schema Components
        3.13.3 Constraints on XML Representations of Assertions
        3.13.4 Assertion Validation Rules
            3.13.4.1 Assertion Satisfied
            3.13.4.2 XPath Evaluation
        3.13.5 Assertion Information Set Contributions
        3.13.6 Constraints on Assertion Schema Components
            3.13.6.1 Assertion Properties Correct
            3.13.6.2 XPath Valid

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

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

...

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 ↑after the appropriate ·pre-processing·↑ and ↑the↑ 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>

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

3.14 Notation Declarations

        3.14.1 The Notation Declaration Schema Component
        3.14.2 XML Representation of Notation Declaration Schema Components
        3.14.3 Constraints on XML Representations of Notation Declarations
        3.14.4 Notation Declaration Validation Rules
        3.14.5 Notation Declaration Information Set Contributions
        3.14.6 Constraints on Notation Declaration Schema Components

...

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 ↑after the appropriate ·pre-processing·↑ and ↑the↑ 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>

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

3.15 Annotations

        3.15.1 The Annotation Schema Component
        3.15.2 XML Representation of Annotation Schema Components
        3.15.3 Constraints on XML Representations of Annotations
        3.15.4 Annotation Validation Rules
        3.15.5 Annotation Information Set Contributions
        3.15.6 Constraints on Annotation Schema Components

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

... ... ...

...

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 ↑after the appropriate ·pre-processing·↑ and ↑the↑ properties of the component it corresponds to are as follows:

XML Representation Summary: annotation Element Information Item et al.

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

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

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

...

3.16.2 XML Representation of Simple Type Definition Schema Components

↑

As always, the mapping rules given in this section apply after, not before, the appropriate ·pre-processing·.

↑

Note: This section reproduces a version of material from [XML Schema: Datatypes], for local cross-reference purposes.

XML Representation Summary: simpleType Element Information Item et al.

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

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

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

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

...

3.17 Schemas as a Whole

        3.17.1 The Schema Itself
        3.17.2 XML Representations of Schemas
            3.17.2.1 References to Schema Components
            3.17.2.2 References to Schema Components from Elsewhere
        3.17.3 Constraints on XML Representations of Schemas
        3.17.4 Validation Rules for Schemas as a Whole
        3.17.5 Schema Information Set Contributions
            3.17.5.1 Schema Information
            3.17.5.2 ID/IDREF Table
        3.17.6 Constraints on Schemas as a Whole
            3.17.6.1 Schema Properties Correct
            3.17.6.2 QName resolution (Schema Document)
            3.17.6.3 QName resolution (Instance)

A schema consists of a set of schema components.

...

3.17.2 XML Representations of Schemas

A schema is represented in XML by one or more ·schema documents·, that is, one or more <schema> element information items. A ·schema document· contains representations for a collection of schema components, e.g. type definitions and element declarations, which have a common {target namespace}. A ·schema document· which has one or more <import> element information items corresponds to a schema with components with more than one {target namespace}, see Import Constraints and Semantics (§4.2.6.2).

↑

As always, the mapping rules given in this section apply after, not before, the appropriate ·pre-processing·.

↑

XML Representation Summary: schema Element Information Item et al.

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

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

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

... ...

...

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

Editor's Draft 1 March 2011

Status of this Document

Table of Contents

Appendices

2 Conceptual Framework

2.4 Conformance

3 Schema Component Details

3.1 Introduction

3.1.2 XML Representations of Components

3.2 Attribute Declarations

3.2.2 XML Representation of Attribute Declaration Schema Components

3.3 Element Declarations

3.3.2 XML Representation of Element Declaration Schema Components

3.4 Complex Type Definitions

3.4.2 XML Representation of Complex Type Definition Schema Components

3.6 Attribute Group Definitions

3.6.2 XML Representation of Attribute Group Definition Schema Components

3.6.2.1 XML Mapping Rule for Named Attribute Groups

3.7 Model Group Definitions

3.7.2 XML Representation of Model Group Definition Schema Components

3.8 Model Groups

3.8.2 XML Representation of Model Group Schema Components

3.10 Wildcards

3.10.2 XML Representation of Wildcard Schema Components

3.11 Identity-constraint Definitions

3.11.2 XML Representation of Identity-constraint Definition Schema Components

3.12 Type Alternatives

3.12.2 XML Representation of Type Alternative Schema Components

3.13 Assertions

3.13.2 XML Representation of Assertion Schema Components

3.14 Notation Declarations

3.14.2 XML Representation of Notation Declaration Schema Components

3.15 Annotations

3.15.2 XML Representation of Annotation Schema Components

3.16 Simple Type Definitions

3.16.2 XML Representation of Simple Type Definition Schema Components

3.17 Schemas as a Whole

3.17.2 XML Representations of Schemas