W3C

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

Editor's Draft 28 October 2009

This version:
../structures/
Latest version:
http://www.w3.org/TR/xmlschema11-1/
Previous version:
http://www.w3.org/TR/2009/CR-xmlschema11-1-20090430/
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.


...

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 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 28 October 2009. It reflects (unless otherwise noted elsewhere) all decisions on this document made by the Working Group through 23 October 2009. 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:
  • A wording proposal to resolve issue 7813 defaultOpenContent should not prevent inheriting openContent when using extension by preferring the open content wildcard of the base type to the wildcard of the schema-document default open content.
    There are 2 proposals. They only differ for the case of extension, where version 1 uses the open content specified on the derived type, and version 2 unions the specified open content and the base open content.
This draft was published on 28 October 2009. 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 Candidate Recommendation review period for this document extends until 3 August 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 RecommendationEditors' 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 (possibly with editorial changes, and possibly removing features identified as being at risk) as soon after 3 August 2009 as the following conditions are met. At the time this Candidate Recommendation 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-b7813.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 Names and Symbol Spaces
    2.6 Schema-Related Markup in Documents Being Validated
xsi:type · xsi:nil · xsi:schemaLocation, xsi:noNamespaceSchemaLocation
    2.7 Representation of Schemas on the World Wide Web
3 Schema Component Details
    3.1 Introduction
    3.2 Attribute Declarations
    3.3 Element Declarations
    3.4 Complex Type Definitions
    3.5 Attribute Uses
    3.6 Attribute Group Definitions
    3.7 Model Group Definitions
    3.8 Model Groups
    3.9 Particles
    3.10 Wildcards
    3.11 Identity-constraint Definitions
    3.12 Type Alternatives
    3.13 Assertions
    3.14 Notation Declarations
    3.15 Annotations
    3.16 Simple Type Definitions
    3.17 Schemas as a Whole
4 Schemas and Namespaces: Access and Composition
    4.1 Layer 1: Summary of the Schema-validity Assessment Core
    4.2 Layer 2: Schema Documents, Namespaces and Composition
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.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.

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.
Note: Aside from the simple coherence requirements outlined below, the requirement that type definitions identified as restrictions actually be restrictions — that is, the requirement that they accept as valid only a subset of the items which are accepted as valid by their base type definition — is enforced in Constraints on Complex Type Definition Schema Components (§3.4.6).
The following sections describe different sets of mapping rules for complex types; some are common to all or many source declarations, others only in specific circumstances.

Where convenient, the mapping rules are described exclusively in terms of the schema document's information set. The mappings, however, depend not only upon the source declaration but also upon the schema context. Some mappings, that is, depend on the properties of other components in the schema. In particular, several of the mapping rules given in the following sections depend upon the {base type definition} having been identified before they apply.

3.4.2.1 Common Mapping Rules for Complex Type Definitions

Whichever alternative for the content of <complexType> is chosen, the following property mappings apply. Except where otherwise specified, attributes and child elements are to be sought among the [attributes] and [children] of the <complexType> element.

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

When the <complexType> source declaration has a <simpleContent> child, the following elements are relevant (as are <attribute>, <attributeGroup>, and <anyAttribute>), and the property mappings are as below, supplemented by the mappings in Common Mapping Rules for Complex Type Definitions (§3.4.2.1), Mapping Rule for Attribute Uses Property (§3.4.2.4), and Mapping Rule for Attribute Wildcard Property (§3.4.2.5). Note that either <restriction> or <extension> must appear in the content of <simpleContent>.

XML Representation Summary: simpleContent Element Information Item et al.

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

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

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

When the <complexType> element has a <simpleContent> child, then the <complexType> element maps to a complex type with simple content, as follows.

XML Mapping Summary for Complex Type Definition with simple content Schema Component
Property
Representation
 
The type definition ·resolved· to by the ·actual value· of the base [attribute] on the <restriction> or <extension> element appearing as a child of <simpleContent>
 
If the <restriction> alternative is chosen, then restriction, otherwise (the <extension> alternative is chosen) extension.
 
A Content Type as follows:
Property
Value
simple
the appropriate case among the following:
1 If the {base type definition} is a complex type definition whose own {content type} has {variety} simple and the <restriction> alternative is chosen, then starting from either
1.1 the simple type definition corresponding to the <simpleType> among the [children] of <restriction> if there is one;
1.2 otherwise (<restriction> has no <simpleType> among its [children]), the simple type definition which is the {simple type definition} of the {content type} of the {base type definition}
a simple type definition which restricts the simple type definition identified in clause 1.1 or clause 1.2 with a set of facet components corresponding to the appropriate element information items among the <restriction>'s [children] (i.e. those which specify facets, if any), as defined in Simple Type Restriction (Facets) (§3.16.6.4);
2 If the {base type definition} is a complex type definition whose own {content type} has {variety} mixed and {particle} a Particle which is ·emptiable·, as defined in Particle Emptiable (§3.9.6.3) and the <restriction> alternative is chosen, then (let SB be the simple type definition corresponding to the <simpleType> among the [children] of <restriction> if any, otherwise ·xs:anySimpleType·) a simple type definition which restricts SB with a set of facet components corresponding to the appropriate element information items among the <restriction>'s [children] (i.e. those which specify facets, if any), as defined in Simple Type Restriction (Facets) (§3.16.6.4);
Note: If there is no <simpleType> among the [children] of <restriction> (and if therefore SB is ·xs:anySimpleType·), the result will be a simple type definition component which fails to obey the constraints on simple type definitions, including for example clause 1.1 of Derivation Valid (Restriction, Simple) (§3.16.6.2).
3 If the {base type definition} is a complex type definition whose own {content type} has {variety} simple and the <extension> alternative is chosen, then the {simple type definition} of the {content type} of that complex type definition;
4 If the {base type definition} is a simple type definition and the <extension> alternative is chosen, then that simple type definition;
3.4.2.3 Mapping Rules for Complex Types with Complex Content

When the <complexType> element does not have a <simpleContent> child element, then it maps to a complex type with complex content. The following elements are relevant (as are the <attribute>, <attributeGroup>, and <anyAttribute> elements, not repeated here), and the additional property mappings are as below, supplemented by the mappings in Common Mapping Rules for Complex Type Definitions (§3.4.2.1), Mapping Rule for Attribute Uses Property (§3.4.2.4), and Mapping Rule for Attribute Wildcard Property (§3.4.2.5). Note that either <restriction> or <extension> must appear in the content of <complexContent>, but their content models are different in this case from the case above when they occur as children of <simpleContent>.

XML Representation Summary: complexContent Element Information Item et al.

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

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

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

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

Complex types with complex content can be the image of two different forms of <complexType> element: one with a <complexContent> child (discussed in Mapping Rules for Complex Types with Explicit Complex Content (§3.4.2.3.1)), and one with neither <simpleContent> nor <complexContent> as a child (discussed in Mapping Rules for Complex Types with Implicit Complex Content (§3.4.2.3.2)). The mapping of the {content type} is the same in both cases; it is described in Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3).

3.4.2.3.1 Mapping Rules for Complex Types with Explicit Complex Content

When the <complexType> source declaration has a <complexContent> child, the following mappings apply, supplemented by those specified in Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3), Common Mapping Rules for Complex Type Definitions (§3.4.2.1), Mapping Rule for Attribute Uses Property (§3.4.2.4), and Mapping Rule for Attribute Wildcard Property (§3.4.2.5).

XML Mapping Summary for Complex Type Definition with complex content Schema Component
Property
Representation
 
The type definition ·resolved· to by the ·actual value· of the base [attribute]
 
If the <restriction> alternative is chosen, then restriction, otherwise (the <extension> alternative is chosen) extension.
3.4.2.3.2 Mapping Rules for Complex Types with Implicit Complex Content

When the <complexType> source declaration has neither <simpleContent> nor <complexContent> as a child, it is taken as shorthand for complex content restricting ·xs:anyType·. The mapping rules specific to this situation are as follows; the mapping rules for properties not described here are as given in Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3), Common Mapping Rules for Complex Type Definitions (§3.4.2.1), Mapping Rule for Attribute Uses Property (§3.4.2.4), and Mapping Rule for Attribute Wildcard Property (§3.4.2.5).

XML Mapping Summary for Complex Type Definition with complex content Schema Component
Property
Representation
 
 
restriction
3.4.2.3.3 Mapping Rules for Content Type Property of Complex Content

For complex types with complex content, the {content type} property is calculated as follows. (For the {content type} on complex types with simple content, see Mapping Rules for Complex Types with Simple Content (§3.4.2.2).)

Note: The mapping rule below refers here and there to elements not necessarily present within a <complexType> source declaration. For purposes of evaluating tests like "If the abc attribute is present on the xyz element", if no xyz element information item is present, then no abc attribute is present on the (non-existent) xyz element.
When the mapping rule below refers to "the [children]", then for a <complexType> source declaration with a <complexContent> child, then the [children] of <extension> or <restriction> (whichever appears as a child of <complexContent>) are meant. If no <complexContent> is present, then the [children] of the <complexType> source declaration itself are meant.
The mapping rule also refers to the value of the {derivation method} property, whose value is determined as specified in the preceding sections.
XML Mapping Summary for Complex Type Definition with complex content Schema Component
Property
Representation
 
1 [Definition:]  Let the effective mixed be the appropriate case among the following:
1.1 If the mixed [attribute] is present on <complexContent>, then its ·actual value·;
1.2 If the mixed [attribute] is present on <complexType>, then its ·actual value·;
1.3 otherwise false.
Note: It is a consequence of clause 4 of Complex Type Definition Representation OK (§3.4.3) that clause 1.1 and clause 1.2 above will never contradict each other in a conforming schema document.
2 [Definition:]  Let the explicit content be the appropriate case among the following:
2.1 If at least one of the following is true
2.1.1 There is no <group>, <all>, <choice> or <sequence> among the [children];
2.1.2 There is an <all> or <sequence> among the [children] with no [children] of its own excluding <annotation>;
2.1.3 There is a <choice> among the [children] whose minOccurs [attribute] has the ·actual value· 0 and which has no [children] of its own except for <annotation>;
2.1.4 The <group>, <all>, <choice> or <sequence> element among the [children] has a maxOccurs [attribute] with an ·actual value· of 0;
then empty
2.2 otherwise the particle corresponding to the <all>, <choice>, <group> or <sequence> among the [children].
3 [Definition:]  Let the effective content be the appropriate case among the following:
3.1 If the ·explicit content· is empty , then the appropriate case among the following:
3.1.1 If the ·effective mixed· is true, then A particle whose properties are as follows:
Property
Value
a model group whose {compositor} is sequence and whose {particles} is empty.
3.1.2 otherwise empty
3.2 otherwise the ·explicit content·.
4 [Definition:]   Let the explicit content type be the appropriate case among the following:
4.1 If {derivation method} = restriction, then the appropriate case among the following:
4.2 If {derivation method} = extension, then the appropriate case among the following:
4.2.1 If the {base type definition} is a simple type definition or is a complex type definition whose {content type}.{variety} = empty or simple, then a Content Type as per clause 4.1.1 and clause 4.1.2 above;
4.2.2 If the {base type definition} is a complex type definition whose {content type}.{variety} = element-only or mixed and the ·effective content· is empty, then {base type definition}.{content type};
4.2.3 otherwise a Content Type as follows:
Property
Value
mixed if the ·effective mixed· is true, otherwise element-only
[Definition:]  Let the base particle be the particle of the {content type} of the {base type definition}. Then the appropriate case among the following:
4.2.3.1 If the {term} of the ·base particle· has {compositor} all and the ·explicit content· is empty, then the ·base particle·.
4.2.3.2 If the {term} of the ·base particle· has {compositor} all and the {term} of the ·effective content· also has {compositor} all, then a Particle whose properties are as follows:
a model group whose {compositor} is all and whose {particles} are the {particles} of the {term} of the ·base particle· followed by the {particles} of the {term} of the ·effective content·.
4.2.3.3 otherwise
a model group whose {compositor} is sequence and whose {particles} are the ·base particle· followed by the ·effective content·.
5 [Definition:]   Let the wildcard element be the appropriate case among the following:
5.1 If the <openContent> [child] is present , then the <openContent> [child].
5.2 If the <openContent> [child] is not present, the <schema> ancestor has a <defaultOpenContent> [child], and one of the following is true
5.2.1 the ·explicit content type· has {variety}empty
5.2.2 the ·explicit content type· has {variety} = empty and the <defaultOpenContent> element has appliesToEmpty = true
then the <defaultOpenContent> [child] of the <schema>.
5.3 otherwise ·absent·.
6 Then the value of the property is the appropriate case among the following:
6.1 If the ·wildcard element· is ·absent· or is present and has mode = 'none' , then the ·explicit content type·.
6.3 otherwise
Property
Value
The {variety} of the ·explicit content type· if it's not empty; otherwise element-only.
The {particle} of the ·explicit content type· if the {variety} of the ·explicit content type· is not empty; otherwise a Particle as follows:
Property
Value
a model group whose {compositor} is sequence and whose {particles} is empty.
An Open Content as follows:
Property
Value
The ·actual value· of the mode [attribute] of the ·wildcard element·, if present, otherwise interleave.
A Let W be the wildcard corresponding to the <any> [child] of the ·wildcard element·. If the {open content} of the ·explicit content type· is ·absent·, then W; otherwise a wildcard whose {process contents} and {annotations} are those of W, and whose {namespace constraint} is the wildcard union of the {namespace constraint} of W and of {open content}.{wildcard} of the ·explicit content type·, as defined in Attribute Wildcard Union (§3.10.6.3).
Note: It is a consequence of clause 4.2 above that when a type definition is extended, the same particles appear in both the base type definition and the extension; the particles are reused without being copied.
3.4.2.4 Mapping Rule for Attribute Uses Property

Any <complexType> source declaration can have <attribute> and <attributeGroup> elements as children, or descendants. The <attribute> element is described in XML Representation of Attribute Declaration Schema Components (§3.2.2) and will not be repeated here.

XML Representation Summary: attributeGroup Element Information Item

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

The <attribute> and <attributeGroup> elements map to the {attribute uses} property of the Complex Type Definition component as described below. This mapping rule is the same for all complex type definitions.

Note: In the following rule, references to "the [children]" refer to the [children] of the <extension> or <restriction> element (whichever appears as a child of <simpleContent> or <complexContent> in the <complexType> source declaration), if present, otherwise to the [children] of the <complexType> source declaration itself.
The rule also refers to the value of the {derivation method} property, which is described elsewhere.
XML Mapping Summary for Complex Type Definition (Attribute Uses) Schema Component
Property
Representation
 

If the <schema> ancestor has a defaultAttributes attribute, and the <complexType> element does not have defaultAttributesApply = false, then the {attribute uses} property is computed as if there were an <attributeGroup> [child] with empty content and a ref [attribute] whose ·actual value· is the same as that of the defaultAttributes [attribute] appearing after any other <attributeGroup> [children]. Otherwise proceed as if there were no such <attributeGroup> [child].

Then the value is a union of sets of attribute uses as follows
1 The set of attribute uses corresponding to the <attribute> [children], if any.
2 The {attribute uses} of the attribute groups ·resolved· to by the ·actual value·s of the ref [attribute] of the <attributeGroup> [children], if any.
3 The attribute uses "inherited" from the {base type definition} T, as described by the appropriate case among the following:
3.1 If T is a complex type definition and {derivation method} = extension, then the attribute uses in T.{attribute uses} are inherited.
3.2 If T is a complex type definition and {derivation method} = restriction, then the attribute uses in T.{attribute uses} are inherited, with the exception of those with an {attribute declaration} whose expanded name is one of the following:
3.2.1 the expanded name of the {attribute declaration} of an attribute use which has already been included in the set, following the rules in clause 1 or clause 2 above;
3.2.2 the expanded name of the {attribute declaration} of what would have been an attribute use corresponding to an <attribute> [child], if the <attribute> had not had use = prohibited.
3.3 otherwise no attribute use is inherited.
Note: The only substantive function of the value prohibited for the use attribute of an <attribute> is in establishing the correspondence between a complex type defined by restriction and its XML representation. It serves to prevent inheritance of an identically named attribute use from the {base type definition}. Such an <attribute> does not correspond to any component, and hence there is no interaction with either explicit or inherited wildcards in the operation of Complex Type Definition Validation Rules (§3.4.4) or Constraints on Complex Type Definition Schema Components (§3.4.6). It is pointless, though not an error, for the use attribute to have the value prohibited in other contexts (e.g. in complex type extensions or named model group definitions), in which cases the <attribute> element is simply ignored, provided that it does not violate other constraints in this specification.
3.4.2.5 Mapping Rule for Attribute Wildcard Property

The {attribute wildcard} property of a Complex Type Definition depends on the <anyAttribute> element which may be present within the <complexType> element or within the attribute groups referred to within <complexType>. The <attributeGroup> element is described in the preceding section Mapping Rule for Attribute Uses Property (§3.4.2.4) and will not be repeated here.

Note: The following mapping rule is the same for all complex type definitions.
References to "the [children]" refer to the [children] of the <extension> or <restriction> element (whichever appears as a child of <simpleContent> or <complexContent> in the <complexType> source declaration), if present, otherwise to the [children] of the <complexType> source declaration itself.
The rule also refers to the value of the {derivation method} property, which is described elsewhere.
XML Mapping Summary for Complex Type Definition (Attribute Wildcard) Schema Component
Property
Representation
 

If the <schema> ancestor has a defaultAttributes attribute, and the <complexType> element does not have defaultAttributesApply = false, then the {attribute wildcard} property is computed as if there were an <attributeGroup> [child] with empty content and a ref [attribute] whose ·actual value· is the same as that of the defaultAttributes [attribute] appearing after any other <attributeGroup> [children]. Otherwise proceed as if there were no such <attributeGroup> [child].

1 [Definition:]  Let the complete wildcard be the Wildcard computed as described in Common Rules for Attribute Wildcards (§3.6.2.2).
2 The value is then determined by the appropriate case among the following:
2.1 If {derivation method} = restriction, then the ·complete wildcard·;
2.2 If {derivation method} = extension, then
2.2.1 [Definition:]  let the base wildcard be defined as the appropriate case among the following:
2.2.1.1 If the {base type definition} is a complex type definition with an {attribute wildcard}, then that {attribute wildcard}.
2.2.1.2 otherwise ·absent·.
2.2.2 The value is then determined by the first case among the following which applies:
2.2.2.3 otherwise a wildcard whose {process contents} and {annotations} are those of the ·complete wildcard·, and whose {namespace constraint} is the wildcard union of the {namespace constraint} of the ·complete wildcard· and of the ·base wildcard·, as defined in Attribute Wildcard Union (§3.10.6.3).
3.4.2.6 Examples of Complex Type Definitions
Example: Three ways to define a type for length

The following declaration defines a type for specifications of length by creating a complex type with simple content, with xs:nonNegativeInteger as the type of the content, and a unit attribute to give the unit of measurement.

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

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

An instance using this type might look like this:

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

A second approach to defining length uses two elements, one for size and one for the unit of measure. The definition of the type and the declaration of the element might look like this:

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

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

An instance using this method might look like this:

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

A third definition of type leaves the base type implicit; at the component level, the following declaration is equivalent to the preceding one.

<xs:complexType name="length3">
 <xs:sequence>
  <xs:element name="size" type="xs:nonNegativeInteger"/>
  <xs:element name="unit" type="xs:NMTOKEN"/>
 </xs:sequence>
</xs:complexType>
Example
<xs:complexType name="simpleName">
 <xs:complexContent>
  <xs:restriction base="personName">
   <xs:sequence>
    <xs:element name="forename" minOccurs="1" maxOccurs="1"/>
    <xs:element name="surname"/>
   </xs:sequence>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>

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

   <who>
    <forename>Bill</forename>
    <surname>Clinton</surname>
   </who>
A simplified type definition ·derived· from the base type from the previous example by restriction, eliminating one optional child and fixing another to occur exactly once; an element declared by reference to it, and a ·valid· instance thereof.
Example
<xs:complexType name="paraType" mixed="true">
 <xs:choice minOccurs="0" maxOccurs="unbounded">
  <xs:element ref="emph"/>
  <xs:element ref="strong"/>
 </xs:choice>
 <xs:attribute name="version" type="xs:decimal"/>
</xs:complexType>
An illustration of the abbreviated form, with the mixed attribute appearing on complexType itself.
Example
<xs:complexType name="name">
  <xs:openContent>
    <xs:any namespace="##other" processContents="skip"/>
  </xs:openContent>
  <xs:sequence>
    <xs:element name="given" type="xs:string"/>
    <xs:element name="middle" type="xs:string" minOccurs="0"/>
    <xs:element name="family" type="xs:string"/>
  </xs:sequence>
</xs:complexType>
A complex type definition that allows three explicitly declared child elements, in the specified order (but not necessarily adjacent), and furthermore allows additional elements of any name from any namespace other than the target namespace to appear anywhere in the children.
Example
To restrict away a local element declaration that ·competes· with a wildcard, use a wildcard in the derived type that explicitly disallows the element's expanded name. For example:
<xs:complexType name="computer">
 <xs:all>
  <xs:element name="CPU" type="CPUType"/>
  <xs:element name="memory" type="memoryType"/>
  <xs:element name="monitor" type="monitorType"/>
  <xs:element name="speaker" type="speakerType"
              minOccurs="0"/>
  <!-- Any additional information about the computer -->
  <xs:any processContents="lax"
          minOccurs="0" maxOccurs="unbounded"/>
 </xs:all>
</xs:complexType>

<xs:complexType name="quietComputer">
 <xs:complexContent>
  <xs:restriction base="computer">
   <xs:all>
    <xs:element name="CPU" type="CPUType"/>
    <xs:element name="memory" type="memoryType"/>
    <xs:element name="monitor" type="monitorType"/>
    <!-- Any additional information about the computer -->
    <xs:any processContents="lax" notQName="speaker"
            minOccurs="0" maxOccurs="unbounded"/>
   </xs:all>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>
The restriction type quietComputer has a lax wildcard, which ·matches· any element but one with the name speaker.
Without the specification of the notQName attribute, the wildcard would ·match· elements named speaker, as well. In that case, the restriction would be valid only if there is a top-level declaration for speaker that also has type speakerType or a type derived from it. Otherwise, there would be instances locally valid against the restriction quietComputer that are not locally valid against the base type computer.
For example, if there is no notQName attribute on the wildcard and no top-level declaration for speaker, then the following is allowed by quietComputer, but not by computer:
   <speaker xsi:type="xs:string"/>
The specific rule violated in this case is clause 2 of constraint Content type restricts (Complex Content) (§3.4.6.4)
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...