W3C

XML SchemaW3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures Second Edition

W3C Recommendation 5 April 2012

This version:
http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/
http://www.w3.org/TR/xmlschema-1/
http://www.w3.org/TR/xmlschema-1/
http://www.w3.org/TR/xmlschema11-1/
http://www.w3.org/TR/xmlschema11-1/
Previous versions:
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ http://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/
Editors:
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 (retired) <nrm@arcanedomain.com>
David Beech, Oracle Corporation (retired) <davidbeech@earthlink.net>
Murray Maloney, Muzmo Communications <murray@muzmo.com>

Please refer to the errata for this document, which may include some normative corrections.

See also translations.

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


Abstract

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

Status of this Document

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

This W3C Recommendation specifies the XML SchemaW3C XML Schema Definition Language (XSD) 1.1. It is here made available for use by W3C members and the public. XSDL 1.1 retains all the essential features of XSDL 1.0 but adds several new features to support functionality requested by users, fixes many errors in XSDL 1.0, and clarifies wording.

This draft was published on 5 April 2012. 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) (§H) is the recommended starting point. It summarizes both changes made since XSDL 1.0 and some changes which were expected (and predicted in earlier drafts of this specification) but have not been made after all. Accompanying versions of this document display in color all changes to normative text since version 1.0 and since the previous Working Draft.

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) and note explicitly that you have not made a Bugzilla entry for the comment. Each Bugzilla entry and email message should contain only one comment.

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

An implementation report for XSD 1.1 was prepared and used in the Director's decision to publish the previous version of this specification as a Proposed Recommendation. The Director's decision to publish this document as a W3C Recommendation is based on consideration of reviews of the Proposed Recommendation by the public and by the members of the W3C Advisory committee.

The W3C XML Schema Working Group intends to process comments made about this recommendation, with any approved changes being handled as errata to be published separately.

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

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

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

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


Table of Contents

1 Introduction
    1.1 Introduction to Version 1.1
    1.2 Purpose
    1.3 Namespaces and Language Identifiers
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 XML SchemaXSD
    2.2 XML SchemaXSD Abstract Data Model
Type Definition Components · Declaration Components · Model Group Components · Identity-constraint DefinitionConstraint 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 SchemasSchema Documents (Structures) (normative)
B References (normative)
C Outcome Tabulations (normative)
    C.1 Validation Rules
    C.2 Contributions to the post-schema-validation infoset
    C.3 Schema Representation Constraints
    C.4 Schema Component Constraints
D Terminology for implementation-defined features (normative)
    D.1 Subset of the Post-schema-validation Infoset
    D.2 Terminology of schema construction
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
    D.3 Other Implementation-defined Features
E Required Information Set Items and Properties (normative)
F Checklists of implementation-defined and implementation-dependent features (normative)
    F.1 Checklist of implementation-defined features
    F.2 Checklist of implementation-dependent features
G Stylesheets for Composing Schema Documents (Normative)
    G.1 Transformation for Chameleon Inclusion
    G.2 Transformation for xs:override
H Changes since version 1.0 (non-normative)
    H.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 · The post-schema-validation infoset · Conformance · Schema composition · Other substantive changes · Clarifications and editorial changes
    H.2 Issues not resolved
I Schema Components Diagram (non-normative)
J Glossary (non-normative)
K DTD for Schemas (non-normative)
L Analysis of the Unique Particle Attribution Constraint (non-normative)
M References (non-normative)
N XSD Language Identifiers (non-normative)
O References
    O.1 Normative
    O.2 Non-normative
P Acknowledgements (non-normative)

1 Introduction

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

Chapter 2 presents a Conceptual Framework (§2) for XML SchemasXSD, including an introduction to the nature of XML SchemasXSD schemas and an introduction to the XML SchemaXSD abstract data model, along with other terminology used throughout this document.

Chapter 3, Schema Component Details (§3), specifies the precise semantics of each component of the abstract model, the representation of each component in XML, with reference to a DTD and an XML SchemaXSD schema for an XML SchemaXSD document type, along with a detailed mapping between the elements and attribute vocabulary of this representation and the components and properties of the abstract model.

Chapter 4 presents Schemas and Namespaces: Access and Composition (§4), including the connection between documents and schemas, the import, inclusion and redefinition of declarations and definitions and the foundations of schema-validity assessment.

Chapter 5 discusses Schemas and Schema-validity Assessment (§5), including the overall approach to schema-validity assessment of documents, and responsibilities of schema-aware processors.

The normative appendices include a Schema for SchemasSchema Documents (Structures) (normative) (§A) for the XML representation of schemas and Normative (§O.1).

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

This document is primarily intended as a language definition reference. As such, although it contains a few examples, it is not primarily designed to serve as a motivating introduction to the design and its features, or as a tutorial for new users. Rather it presents a careful and fully explicit definition of that design, suitable for guiding implementations. For those in search of a step-by-step introduction to the design, the non-normative [XML Schema: Primer] is a much better starting point than this document.

next sub-section1.1 Introduction to Version 1.1

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

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

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

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

The aim with regard to compatibility is that

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

previous sub-section next sub-section1.2 Purpose

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

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

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

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

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

1.3.1 XSD Namespaces

1.3.1.1 The Schema Namespace (xs)

The XML representation of schema components uses a vocabulary identified by the namespace name http://www.w3.org/2001/XMLSchema. For brevity, the text and examples in this specification use the prefix xs: to stand for this namespace; in practice, any prefix can be used.

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

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

1.3.1.2 The Schema Instance Namespace (xsi)

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

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

1.3.1.3 The Schema Versioning Namespace (vc)

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

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

1.3.2 Namespaces with Special Status

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

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

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

1.3.3 Conventional Namespace Bindings

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

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

1.3.4 Schema Language Identifiers

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

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

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

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

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

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

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

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

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

previous sub-section 1.5 Documentation Conventions and Terminology

The section introduces the highlighting and typography as used in this document to present technical material.

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

Special terms are defined at their point of introduction in the text. For example [Definition:]  a term is something used with a special meaning. The definition is labeled as such and the term it defines is displayed in boldface. The end of the definition is not specially marked in the displayed or printed text. Uses of defined terms are links to their definitions, set off with middle dots, for instance ·term·.

Non-normative examples are set off in boxes and accompanied by a brief explanation:

Example
<schema targetNamespace="http://www.example.com/XMLSchema/1.0/mySchema">
And an explanation of the example.

The definition of each kind of schema component consists of a list of its properties and their contents, followed by descriptions of the semantics of the properties:

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

An example property

References to properties of schema components are links to the relevant definition as exemplified above, set off with curly braces, for instance {example property}.

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

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

The correspondence between an element information item which is part of the XML representation of a schema and one or more schema components is presented in a tableau which illustrates the element information item(s) involved. This is followed by a tabulation of the correspondence between properties of the component and properties of the information item. Where context may determinedetermines which of several different components may arisecorresponds to the source declaration, several tabulations, one per context, are given. The property correspondences are normative, as are the illustrations of the XML representation element information items.

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

The allowed content of the information item is shown as a grammar fragment, using the Kleene operators ?, * and +. Each element name therein is a hyperlink to its own illustration.

Note: The illustrations are derived automatically from the Schema for SchemasSchema Documents (Structures) (normative) (§A). In the case of apparent conflict, the Schema for SchemasSchema Documents (Structures) (normative) (§A) takes precedence, as it, together with the ·Schema Representation Constraints·, provide the normative statement of the form of XML representations.
XML Representation Summary: example Element Information Item
<example
  count = integer
  size = (large | medium | small) : medium>
  Content: (all | any*)
</example>
Example Schema Component
Property
Representation
 
Description of what the property corresponds to, e.g. the value of the size [attribute]
 

References to elements in the text are links to the relevant illustration as exemplified above, set off with angle brackets, for instance <example>.

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

References to properties of information items as defined in [XML Infoset] are notated as links to the relevant section thereof, set off with square brackets, for example [children].

Properties which this specification defines for information items are introduced as follows:

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

References to properties of information items defined in this specification are notated as links to their introduction as exemplified above, set off with square brackets, for example [new property].

The "dot operator" described above for components and their properties is also used for information items and their properties. For a given information item I, an expression of the form "I . [new property]" denotes the (value of the) property [new property] for item I.

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

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

Note: General comments directed to all readers.

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

may
Conforming documents and XML Schema-aware processorsSchemas, schema documents, and processors are permitted to but need not behave as described.
should
It is recommended that schemas, schema documents, and processors behave as described, but there can be valid reasons for them not to; it is important that the full implications be understood and carefully weighed before adopting behavior at variance with the recommendation.
must
Conforming documents and XML Schema-aware processors are required to behave as described; otherwise they are in error.
(Of schemas and schema documents:) Schemas and documents are required to behave as described; otherwise they are in ·error·.
(Of processors:) Processors are required to behave as described.
must not
Schemas, schema documents, and processors are forbidden to behave as described; schemas and documents which nevertheless do so are in ·error·.
error
A failure of a schema or schema document to conform to the rules of this specification.
Except as otherwise specified, processors must distinguish error-free (conforming) schemas and schema documents used in ·assessment· from those with errors; if a schema used in ·assessment· or a schema document used in constructing a schema is in error, processors must report the fact; if more than one is in error, it is ·implementation-dependent· whether more than one is reported as being in error. If one or more of the constraint codes given in Outcome Tabulations (normative) (§C) is applicable, it is ·implementation-dependent· how many of them, and which, are reported.
Note: Failure of an XML document to be valid against a particular schema is not (except for the special case of a schema document consulted in the course of building a schema) in itself a failure to conform to this specification and thus, for purposes of this specification, not an error.
Note: Notwithstanding the fact that (as just noted) failure to be schema-valid is not a violation of this specification and thus not strictly speaking an error as defined here, the names of the PSVI properties [schema error code] (for attributes) and [schema error code] (for elements) are retained for compatibility with other versions of this specification, and because in many applications of XSD, non-conforming documents are "in error" for purposes of those applications.
deprecated
A feature or construct defined in this specification described as deprecated is retained in this specification for compatibility with previous versions of the specification, and but its use is not advisable and schema authors should avoid its use if possible.
Deprecation has no effect on the conformance of schemas or schema documents which use deprecated features. Since deprecated features are part of the specification, processors must support them, although some processors may choose to issue warning messages when deprecated features are encountered.
Features deprecated in this version of this specification may be removed entirely in future versions, if any.
[Definition:]  user option
A choice left under the control of the user of a processor, rather than being fixed for all users or uses of the processor.
Statements in this specification that "Processors may at user option" behave in a certain way mean that processors may provide mechanisms to allow users (i.e. invokers of the processor) to enable or disable the behavior indicated. Processors which do not provide such user-operable controls must not behave in the way indicated. Processors which do provide such user-operable controls must make it possible for the user to disable the optional behavior.
Note: The normal expectation is that the default setting for such options will be to disable the optional behavior in question, enabling it only when the user explicitly requests it. This is not, however, a requirement of conformance: if the processor's documentation makes clear that the user can disable the optional behavior, then invoking the processor without requesting that it be disabled can be taken as equivalent to a request that it be enabled. It is required, however, that it in fact be possible for the user to disable the optional behavior.
Note: Nothing in this specification constrains the manner in which processors allow users to control user options. Command-line options, menu choices in a graphical user interface, environment variables, alternative call patterns in an application programming interface, and other mechanisms may all be taken as providing user options.

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

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

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

2 Conceptual Framework

This chapter gives an overview of XML Schema Definition Language: Structures at the level of its abstract data model. Schema Component Details (§3) provides details on this model, including a normative representation in XML for the components of the model. Readers interested primarily in learning to write schema documents may wish to firstwill find it most useful first to read [XML Schema: Primer] for a tutorial introduction, and only then to consult the sub-sections of Schema Component Details (§3) named XML Representation of ... for the details.

next sub-section2.1 Overview of XML SchemaXSD

An XML SchemaXSD schema consistsis a set of components such as type definitions and element declarations. These can be used to assess the validity of well-formed element and attribute information items (as defined in [XML Infoset]), and furthermore mayto specify augmentations toadditional information about those items and their descendants. This augmentation makesThese augmentations to the information set make explicit information which may have been that was implicitly present in the original document (or in the original document and the governing schema, taken together), such as normalized and/or default values for attributes and elements and the types of element and attribute information items. The input information set is also augmented with information about the validity of the item, or about other properties described in this specification. [Definition:]  We refer to the augmented infoset which results from conformant processing as defined in this specification as the post-schema-validation infoset, or PSVI. Conforming processors may provide access to some or all of the PSVI, as described in Subset of the Post-schema-validation Infoset (§D.1). The mechanisms by which processors provide such access to the PSVI are neither defined nor constrained by this specification.

[Definition:]  As it is used in this specification, the term schema-validity assessment has twothree aspects:
1 Determining local schema-validity, that is whether an element or attribute information item satisfies the constraints embodied in the relevant components of an XML SchemaXSD schema (specifically the ·governing· element or attribute declaration and/or ·governing· type definition);
2
Synthesizing an overall validation outcome for the item, combining local schema-validity with the results of schema-validity assessments of its descendants, if any, and adding appropriate augmentations to the infoset to record this outcome.
Determining an overall validation outcome for the item by combining local schema-validity with the results of schema-validity assessments of its descendants, if any; and
3
Determining the appropriate augmentations to the infoset (and, if desired, exposing them to downstream applications in some way, to record this outcome).

Throughout this specification, [Definition:]  the word valid and its derivatives are used to refer to clause 1 above, the determination of local schema-validity.

Throughout this specification, [Definition:]   the word assessment is used to refer to the overall process of local validation, schema-validity assessmentrecursive determination of validation outcome, and infoset augmentation, i.e. as a short form for "·schema-validity assessment·".

[Definition:]   Validation is the process of determining whether an XML document, an element information item, or an attribute information item obeys the constraints expressed in a schema; in the context of XSD, this amounts to calculating the value of the appropriate item's [validity] property.
Note: As just defined, validation produces not a binary result, but a ternary one: if the information item is ·strictly assessed·, it will be either valid or invalid, but if no applicable declaration is found, its validity will be unknown (and its [validity] property will have the value notKnown). Whether in a particular application notKnown should be treated in the same way as invalid or differently is outside the scope of this specification; sometimes one choice is appropriate, sometimes the other.
Note: In phrases such as "·validly substitutable·" and "length valid restriction", the word valid is used in its ordinary English sense of "conforming to some set of rules", not necessarily limited to rules expressed in an XSD schema.

In general, a valid document is a document whose contents obey the constraints expressed in a particular schema. Since a document may be validated against many different schemas, it is often clearer to speak of a document being valid against a particular schema. When this specification is used, document validity can be defined operationally in terms of the ·post-schema-validation infoset· properties on the nodes of the document (in particular [validity]). Several similar but distinct kinds of validity are usefully distinguished, for which terms are defined below in Schema-validity and documents (§2.5).

Because the [validity] property is part of the ·post-schema-validation infoset·, it should be evident that any full ·assessment· of an item by definition entails the ·validation· of that item. Conversely, since the [validity] property is recursive and depends upon many other pieces of information which are part of the ·post-schema-validation infoset·, ·validation· also typically entails at least partial ·assessment·. The processes denoted by the two terms thus overlap and are not always distinguishable; often the same process can be referred to by either term. In this specification, the term "·assessment·" is used when it is desired to stress the calculation of the complete ·post-schema-validation infoset·, including properties whose values have no effect on validity. The term "·validation·", in contrast, is used when it is desired to focus primarily on the ·validity· of the item, treating the other information generated in the process as merely incidental.
Note: When there is no particular emphasis one way or the other, the choice of terms is necessarily arbitrary, or grounded in the history of this and related specifications. Historical reasons, rather than connotation, determine the use of the term "·validation·" instead of "·assessment·" in terms like "·post-schema-validation infoset·", "·validation root·", and "Validation Rules".
During ·assessment·, some or all of the element and attribute information items in the input document are associated with declarations and/or type definitions; these declarations and type definitions are then used in the ·assessment· of those items, in a recursive process. [Definition:]  The declaration associated with an information item, if any, and with respect to which its validity is ·assessed· in a given assessment episode is said to govern the item, or to be its governing element or attribute declaration. Similarly the type definition with respect to which the type-validity of an item is assessed is its governing type definition.

previous sub-section next sub-section2.2 XML SchemaXSD Abstract Data Model

        2.2.1 Type Definition Components
            2.2.1.1 Type Definition Hierarchy
            2.2.1.2 Simple Type Definition
            2.2.1.3 Complex Type Definition
        2.2.2 Declaration Components
            2.2.2.1 Element Declaration
            2.2.2.2 Element Substitution Group
            2.2.2.3 Attribute Declaration
            2.2.2.4 Notation Declaration
        2.2.3 Model Group Components
            2.2.3.1 Model Group
            2.2.3.2 Particle
            2.2.3.3 Attribute Use
            2.2.3.4 Wildcard
        2.2.4 Identity-constraint DefinitionConstraint Components
            2.2.4.1 Identity-constraint Definition
            2.2.4.2 Type Alternative
            2.2.4.3 Assertion
            2.2.4.4 Overlapping Functionality of Constraint Components
        2.2.5 Group Definition Components
            2.2.5.1 Model Group Definition
            2.2.5.2 Attribute Group Definition
        2.2.6 Annotation Components

This specification builds on [XML 1.0][XML 1.1] and [Namespaces in XML 1.0][XML Namespaces 1.1]. The concepts and definitions used herein regarding XML are framed at the abstract level of information items as defined in [XML Infoset]. By definition, this use of the infoset provides a priori guarantees of well-formedness (as defined in [XML 1.0][XML 1.1]) and namespace conformancenamespace conformance (as defined in [Namespaces in XML 1.0][XML Namespaces 1.1]) for all candidates for ·assessment· and for all ·schema documents·.

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

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

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

The secondary schema components, which must have names, are as follows:

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

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

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

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

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

During ·validation·, [Definition:]  declaration components are associated by (qualified) name to information items being ·validated·.

On the other hand, [Definition:]  definition components define internal schema components that can be used in other schema components.

[Definition:]  Declarations and definitions maymay and in some cases must have and be identified by names, which are NCNames as defined by [Namespaces in XML 1.0][XML Namespaces 1.1].

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

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

Note: At the abstract level, there is no requirement that the components of a schema share a ·target namespace·. Any schema for use in ·assessment· of documents containing names from more than one namespace will of necessity include components with different ·target namespaces·. This contrasts with the situation at the level of the XML representation of components, in which each schema document contributes definitions and declarations to a single target namespace.

·Validation·, defined in detail in Schema Component Details (§3), is a relation between information items and schema components. For example, an attribute information item may ·validate·is ·validated· with respect to an attribute declaration, a list of element information items may ·validate· with respect to a content model, and so on. The following sections briefly introduce the kinds of components in the schema abstract data model, other major features of the abstract model, and how they contribute to ·validation·.

2.2.1 Type Definition Components

The abstract model provides two kinds of type definition component: simple and complex.

[Definition:]  This specification uses the phrase type definition in cases where no distinction need be made between simple and complex types.

Type definitions form a hierarchy with a single root. The subsections below first describe characteristics of that hierarchy, then provide an introduction to simple and complex type definitions themselves.

2.2.1.1 Type Definition Hierarchy

[Definition:]  Except for a distinguished ·ur-type definition·, ·xs:anyType·, every ·type definition· is, by construction, either a ·restriction· or an ·extension· of some other type definition. The exception ·xs:anyType· is a ·restriction· of itself. With the exception of the loop on ·xs:anyType·, the The graph of these relationships forms a tree known as the Type Definition Hierarchy with ·xs:anyType· as its root.

[Definition:]  AThe type definition used as the basis for an ·extension· or ·restriction· is known as the base type definition of that definition. [Definition:]   If a type definition D can reach a type definition B by following its base type definition chain, then D is said to be derived from B. In most cases, a type definition is derived from other type definitions. The only exception is ·xs:anyType·, which is derived from itself.

[Definition:]  A type definition whose declarations or facets are in a one-to-one relation with those of another specified type definition, with each in turn restricting the possibilities of the one it corresponds to,A type defined with the same constraints as its ·base type definition·, or with more, is said to be a restriction. The specific restrictionsadded constraints might include narrowed ranges or reduced alternatives. Members of a type, A, whose definition is a ·restriction· of the definition of another type, B, are always locally valid against type B as well.Given two types A and B, if the definition of A is a ·restriction· of the definition of B, then members of type A are always locally valid against type B as well.

[Definition:]  A complex type definition which allows element or attribute content in addition to that allowed by another specified type definition is said to be an extension.

Note: Conceptually, the definitions of ·restriction· and ·extension· overlap: given a type T, a vacuous ·restriction· of T and a vacuous ·extension· of T will each accept the same inputs as valid. The syntax specified in this version of this specification, however, requires that each type be defined either as a restriction or as an extension, not both. Thus even though the vacuous extension of T accepts the same inputs as the vacuous restriction, it will not be accepted in contexts which require restrictions of T.

[Definition:]  A distinguished complex type definition, the ur-type definition, whose name is anyType in the XML Schema namespace, is present in each ·XML Schema·, serving as the root of the type definition hierarchy for that schema.

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

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

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

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

2.2.1.2 Simple Type Definition

A simple type definition is a set of constraints on strings and information about the values they encode, applicable to the ·normalized value· of an attribute information item or of an element information item with no element children. Informally, it applies to the values of attributes and the text-only content of elements.

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

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

[Definition:]   Datatypes can be constructed from other datatypes by restricting the value space or lexical space of a {base type definition} using zero or more Constraining Facets, by specifying the new datatype as a list of items of some {item type definition}, or by defining it as a union of some specified sequence of {member type definitions}.

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

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

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

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

2.2.1.3 Complex Type Definition

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

Each complex type definition other than the ·ur-type definition··xs:anyType· is either or
A complex type which extends another does so by having additional content model particles at the end of the other definition's content model, or by having additional attribute declarations, or both.
Note: ThisFor the most part, this specification allows only appending, and not other kinds of extensions. This decision simplifies application processing required to cast instances from derived to the derived type to the base type. One special case allows the extension of all-groups in ways that do not guarantee that the new material occurs only at the end of the content. Another special case is extension via Open Contents in interleave mode. Future versions may allow more kinds of extension, requiring more complex transformations to effect casting.

For detailed information on complex type definitions, see Complex Type Definitions (§3.4).

2.2.2 Declaration Components

There are three kinds of declaration component: element, attribute, and notation. Each is described in a section below. Also included is a discussion of element substitution groups, which is a feature provided in conjunction with element declarations.

2.2.2.1 Element Declaration

An element declaration is an association of a name with a type definition, either simple or complex, an (optional) default value and a (possibly empty) set of identity-constraint definitions. The association is either global or scoped to a containing complex type definition. A top-level element declaration with name 'A' is broadly comparable to a pair of DTD declarations as follows, where the associated type definition fills in the ellipses:

<!ELEMENT A . . .>
<!ATTLIST A . . .>

Element declarations contribute to ·validation· as part of model group ·validation·, when their defaults and type components are checked against an element information item with a matching name and namespace, and by triggering identity-constraint definition ·validation·.

For detailed information on element declarations, see Element Declarations (§3.3). For an overview of identity constraints, see Identity-constraint Definition (§2.2.4.1).

2.2.2.2 Element Substitution Group

In XML 1.0, the name and content of an element must correspond exactly to the element type referenced in the corresponding content model.

When XML vocabularies are defined using the DTD syntax defined by [XML 1.1], a reference in a content model to a particular name is satisfied only by an element in the XML document whose name and content correspond exactly to those given in the corresponding element type declaration.
Note: The "element type declaration" of [XML 1.1] is not quite the same as the ·governing type definition· as defined in this specification: [XML 1.1] does not distinguish between element declarations and type definitions as distinct kinds of object in the way that this specification does. The "element type declaration" of [XML 1.1] specifies both the kinds of properties associated in this specification with element declarations and the kinds of properties associated here with (complex) type definitions.

[Definition:]  Through the new mechanism of element substitution groups, XML SchemasXSD provides a more powerful model than DTDs do supporting substitution of one named element for another. Any top-level element declaration can serve as the defining member, or head, for an element substitution group·substitution group·. Other top-level element declarations, regardless of target namespace, can be designated as members of the substitution group·substitution group· headed by this element. In a suitably enabled content model, a reference to the head ·validates· not just the head itself, but elements corresponding to any other member of the substitution group·substitution group· as well.

All such members must have type definitions which are either the same as the head's type definition or restrictions or extensions ofderived from it. Therefore, although the names of elements can vary widely as new namespaces and members of the substitution group·substitution group· are defined, the content of member elements is strictly limited according toconstrained by the type definition of the substitution group·substitution group· head.

Note that element substitution groups are not represented as separate components. They are specified in the property values for element declarations (see Element Declarations (§3.3)).

2.2.2.3 Attribute Declaration

An attribute declaration is an association between a name and a simple type definition, together with occurrence information and (optionally) a default value. The association is either global, or local to its containing complex type definition. Attribute declarations contribute to ·validation· as part of complex type definition ·validation·, when their occurrence, defaults and type components are checked against an attribute information item with a matching name and namespace.

For detailed information on attribute declarations, see Attribute Declarations (§3.2).

2.2.2.4 Notation Declaration

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

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

2.2.3 Model Group Components

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

2.2.3.1 Model Group

A model group is a constraint in the form of a grammar fragment that applies to lists of element information items. It consists of a list of particles, i.e. element declarations, wildcards and model groups. There are three varieties of model group:

  • Sequence (the element information items match the particles in sequential order);
  • Conjunction (the element information items match the particles, in any order);
  • Disjunction (the element information items match one or more of the particles).

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

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

2.2.3.2 Particle

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

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

[Definition:]  A particle can be used in a complex type definition to constrain the ·validation· of the [children] of an element information item; such a particle is called a content model.
Note: XML Schema: StructuresXSD ·content models· are similar to but more expressive than [XML 1.0][XML 1.1] content models; unlike [XML 1.0][XML 1.1], XML Schema: StructuresXSD applies ·content models· to the ·validation· of both mixed and element-only contentdoes not restrict the form of ·content models· describing mixed content.

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

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

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

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

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

2.2.3.3 Attribute Use

An attribute use plays a role similar to that of a particle, but for attribute declarations: an attribute declaration within used by a complex type definition is embedded within an attribute use, which specifies whether the declaration requires or merely allows its attribute, and whether it has a default or fixed value.

2.2.3.4 Wildcard

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

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

2.2.4 Identity-constraint DefinitionConstraint Components

This section describes constructs which use [XPath 2.0] expressions to constrain the input document; using them, certain rules can be expressed conveniently which would be inconvenient or impossible to express otherwise. Identity-constraint definitions are associated with element declarations; assertions are associated with type definitions; conditional type assignment using type alternatives allows the type of an element instance to be chosen based on properties of the element instance (in particular, based on the values of its attributes).

2.2.4.1 Identity-constraint Definition

An identity-constraint definition is an association between a name and one of several varieties of identity-constraint related to uniqueness and reference. All the varieties use [XPath][XPath 2.0] expressions to pick out sets of information items relative to particular target element information items which are unique, or a key, or a ·valid· reference, within a specified scope. An element information item is only ·valid· with respect to an element declaration with identity-constraint definitions if those definitions are all satisfied for all the descendants of that element information item which they pick out.

For detailed information on identity-constraint definitions, see Identity-constraint Definitions (§3.11).

Note: In version 1.0 of this specification [XSD 1.0 2E], identity constraints used [XPath 1.0]; they now use [XPath 2.0].
2.2.4.2 Type Alternative

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

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

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

2.2.4.3 Assertion

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

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

2.2.4.4 Overlapping Functionality of Constraint Components

Many rules that can be enforced by identity constraints and conditional type assignment can also be formulated in terms of assertions. That is, the various constructs have overlapping functionality. The three forms of constraint differ from each other in various ways which may affect the schema author's choice of formulation.

Most obviously, the ·post-schema-validation infoset· will differ somewhat, depending on which form of constraint is chosen.

Less obviously, identity constraints are associated with element declarations, while assertions are associated with type definitions. If it is desired to enforce a particular property of uniqueness or referential integrity associated with a particular element declaration E, of type T, the schema author may often choose either an identity constraint associated with E, or an assertion associated with T. One obvious difference is that elements substitutable for E are required to have types derived from T, but are not required to enforce the identity constraints (or the nillability) of E. If the constraint applicable to E should be enforced by elements substitutable for E, it is often most convenient to formulate the constraint as an assertion on T; conversely, if only some elements of type T are intended to be subject to the constraint, or if elements substitutable for E need not enforce the constraint, then it will be more convenient to formulate the rule as an identity constraint on E.

Similar considerations sometimes apply to the choice between assertions and conditional type assignment.

Because identity constraints and conditional type assignment are simpler and less variable than assertions, it may be easier for software to exploit or optimize them. Assertions have greater expressive power, which means they are often convenient. The "rule of least power" applies here; it is often preferable to use a less expressive notation in preference to a more expressive one, when either will suffice. See [Rule of Least Power].

2.2.5 Group Definition Components

There are two kinds of convenience definitions provided to enable the re-use of pieces of complex type definitions: model group definitions and attribute group definitions.

2.2.5.1 Model Group Definition

A model group definition is an association between a name and a model group, enabling re-use of the same model group in several complex type definitions.

For detailed information on model group definitions, see Model Group Definitions (§3.7).

2.2.5.2 Attribute Group Definition

An attribute group definition is an association between a name and a set of attribute declarations, enabling re-use of the same set in several complex type definitions.

For detailed information on attribute group definitions, see Attribute Group Definitions (§3.6).

2.2.6 Annotation Components

An annotation is information for human and/or mechanical consumers. The interpretation of such information is not defined in this specification.

For detailed information on annotations, see Annotations (§3.15).

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

The [XML 1.0][XML 1.1] specification describes two kinds of constraints on XML documents: well-formedness and validity constraints. Informally, the well-formedness constraints are those imposed by the definition of XML itself (such as the rules for the use of the < and > characters and the rules for proper nesting of elements), while validity constraints are the further constraints on document structure provided by a particular DTD.

The preceding section focused on ·validation·, that is the constraints on information items which schema components supply. In fact however this specification provides four different kinds of normative statements about schema components, their representations in XML and their contribution to the ·validation· of information items:

Schema Component Constraint
[Definition:]  Constraints on the schema components themselves, i.e. conditions components must satisfy to be components at all. They are located Located in the sixth sub-section of the per-component sections of Schema Component Details (§3) and tabulated in Schema Component Constraints (§C.4).
Schema Representation Constraint
[Definition:]  Constraints on the representation of schema components in XML beyond those which are expressed in Schema for SchemasSchema Documents (Structures) (normative) (§A). They are located Located in the third sub-section of the per-component sections of Schema Component Details (§3) and tabulated in Schema Representation Constraints (§C.3).
Validation Rules
[Definition:]  Contributions to ·validation· associated with schema components. They are located Located in the fourth sub-section of the per-component sections of Schema Component Details (§3) and tabulated in Validation Rules (§C.1).
Schema Information Set Contribution
[Definition:]  Augmentations to ·post-schema-validation infoset·s expressed by schema components, which follow as a consequence of ·validation· and/or ·assessment·. They are located Located in the fifth sub-section of the per-component sections of Schema Component Details (§3) and tabulated in Contributions to the post-schema-validation infoset (§C.2).

The last of these, schema information set contributions, are not as new as they might at first seem. XML 1.0 validation augments the XML 1.0 information set in similar ways, for example by providing values for attributes not present in instances, and by implicitly exploiting type information for normalization or access. (As an example of the latter case, consider the effect of NMTOKENS on attribute white space, and the semantics of ID and IDREF.) By including schema information set contributions, this specification makes explicit some features that XML 1.0 leftleaves implicit.

previous sub-section next sub-section2.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:
1 It is valid with respect to the top-level element declaration for <schema> in the schema specified in Schema for SchemasSchema Documents (Structures) (normative) (§A). That is, when ·assessed· using ·element-driven validation· and stipulating the declaration for <schema>, then in its ·post-schema-validation infoset·, the <schema> element has a [validation attempted] property with value full or partial and a [validity] property with value valid.
2 No element in the schema document violates any of the Schema Representation Constraints set out in Schema Representation Constraints (§C.3), unless that element has an <annotation> element as an ancestor.
Note: Because elements within <annotation> do not map to components, they are not required to obey the Schema Representation Constraints.

If the schema document is invalid only in consequence of invalid descendants of <annotation> elements, processors may treat the schema document as valid. It is ·implementation-defined· what effect, if any, invalid <annotation> elements have on the construction of schema components.

Note: While conformance of schema documents is (with the exception just noted) 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 describes three levels of conformance for schema aware processors. The first is required of all processors. Support for the other two will depend on the application environments for which the processor is intended.

[Definition:]  Minimally conforming processors must completely and correctly implement the ·Schema Component Constraints·, ·Validation Rules·, and ·Schema Information Set Contributions· contained in this specification.

[Definition:]  ·Minimally conforming· processors which accept schemas represented in the form of XML documents as described in Layer 2: Schema Documents, Namespaces and Composition (§4.2) are additionally said to provide conformance to the XML Representation of Schemas. Such processors must, when processing schema documents, completely and correctly implement all ·Schema Representation Constraints· in this specification, and must adhere exactly to the specifications in Schema Component Details (§3) for mapping the contents of such documents to ·schema components· for use in ·validation· and ·assessment·.

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 described in Conditional inclusion (§4.2.2).

[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 XML Schema documents·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:]  Fully conformingWeb-aware processors are network-enabled processors which are not only both ·minimally conforming· and ·in conformance to the XML Representation of Schemas·,·general-purpose· but which additionally must be capable of accessing schema documents from the World Wide Web according toas 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".

Several important classes of processor can be defined in terms of the concepts just given:

general-purpose validators
·Validators· which accept arbitrary schemas expressed in the form of sets of schema documents (i.e., are ·general-purpose·); some general-purpose validators may additionally be ·Web-aware·.
general-purpose schema-validity assessors
·Assessors· which accept arbitrary schemas expressed in the form of sets of schema documents (i.e., are ·general-purpose·); some general-purpose assessors may additionally be ·Web-aware·.
special-purpose validators
·Validators· which do not accept arbitrary schemas expressed in the form of sets of schema documents
Note: Typically a special-purpose validator will either have a built-in (hard-coded) schema, or else will accept arbitrary schemas in some form other than schema documents.
other special-purpose tools
Processors (other than those otherwise defined) which perform some task, service, or activity which depends at least in part on the contents of some schema, and which do so in ways which are consistent with the provisions of this specification.
Note: The class of ·other special-purpose tools· is not, as defined here, a particularly informative description of a piece of software. It is expected that other specifications may wish to define processes depending in part upon schemas, and to require that implementations of those processes conform to this specification; this conformance class provides a reference point for such requirements, and for such claims of conformance.

A claim that a processor conforms to this specification must specify to which processor classes defined here the processor belongs.

Note: Although this specification provides just these three standard levels of conformance, it is anticipated that other conventions can be established in the future. For example, the World Wide Web Consortium is considering conventions for packaging on the Web a variety of resources relating to individual documents and namespaces. Should such developments lead to new conventions for representing schemas, or for accessing them on the Web, new levels of conformance can be established and named at that time. There is no need to modify or republish this specification to define such additional levels of conformance.

See Schemas and Namespaces: Access and Composition (§4) for a more detailed explanation of the mechanisms supporting these levels of conformance.

See Checklist of implementation-defined features (§F.1) and Terminology for implementation-defined features (normative) (§D) for terminology and concepts which may be helpful in defining the behavior of conforming processors and/or claiming conformance to this specification.

previous sub-section next sub-section2.5 Schema-validity and documents

As noted above, in general a document is valid against a particular schema if it obeys the constraints imposed by that schema. Depending on the nature of the application and on the specific invariants to be enforced, different forms of validity may be appropriately required by an application, a specification, or other users of XSD. This section defines terminology for use in describing the requirements of applications or other technologies which use XSD schema to describe constraints on XML documents.

Note: Conformance to this specification cannot be claimed for XML documents other than schema documents; this specification imposes no requirements on documents, validity-related or otherwise, and the terms defined in this section play no role in conformance to this specification. They are defined here for the convenience of users of this specification who do wish to impose specific requirements on documents.
The terms defined capture some commonly used requirements, but the specification of which documents should be regarded as acceptable for a specific application, or as conforming to a given specification, is out of scope for this specification. Applications and specifications which use XSD are free to specify whatever constraints they see fit on documents; the provision of terms for the concepts identified here should not be taken to imply that other rules for document acceptability are discouraged or inappropriate.

All the terms defined below require that the document's root element be ·assessed· using either ·element-driven validation· (when the intended root element of the schema is clearly specified ) or else ·strict wildcard validation· (if several different root elements are acceptable).

root-valid document
A document is root-valid against a given XSD schema if and only if after ·assessment· the document's root element has [validity] = valid and [validation attempted] = full or partial.
deep-valid document
A document is deep-valid against a given XSD schema if and only if after ·assessment· all of the following are true:
1 The document's root element has [validity] = valid.
2 The document's root element has [validation attempted] = full or partial.
3 No element in the document has [validity] = invalid.
4 No attribute in the document has [validity] = invalid.
Note: The second and third clauses are necessary to ensure that invalid descendants of laxly validated elements are caught; they do not cause their laxly validated ancestor to have [validity] = invalid.
uniformly valid document
A document is uniformly valid against a given XSD schema if and only if after ·assessment· all of the following are true:
1 The document's root element has [validity] = valid.
2 The document's root element has [validation attempted] = full.
Note: See Assessment Outcome (Element) (§3.3.5.1) for the definition of the [validation attempted] property.)
It follows from the first and second clauses that every element and attribute in the document has been ·validated· and each of them is valid. (This distinguishes uniform validity from deep validity; a deep-valid document may include elements and attributes whose validity is notKnown, perhaps because they are laxly ·assessed· and no declarations were found for them, or because they were ·skipped·.)
Note: The absence of error codes does not suffice to make a document valid according to any of the definitions just given; the [schema error code] property will be empty (or ·absent·) for any root element with [validity] = notKnown. Validators which expose only the [schema error code] property and fail to distinguish in their behavior between [validity] = notKnown and [validity] = valid can thus easily mislead unwary users. A frequent cause of [validity] = notKnown is the failure of the element information item to ·match· any declaration in the schema.

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

As discussed in XML SchemaXSD Abstract Data Model (§2.2), most schema components (maymay) have ·names·. If all such names were assigned from the same "pool", then it would be impossible to have, for example, a simple type definition and an element declaration both with the name "title" in a given ·target namespace·.

Therefore [Definition:]  this specification introduces the term symbol space to denote a collection of names, each of which is unique with respect to the others. A symbol space is similar to the non-normative concept of namespace partition introduced in [Namespaces in XML 1.0]. There is a single distinct symbol space within a given ·target namespace· for each kind of definition and declaration component identified in XML SchemaXSD Abstract Data Model (§2.2), except that within a target namespace, simple type definitions and complex type definitions share a symbol space. Within a given symbol space, names are unique, but the same name may appear in more than one symbol space without conflict. For example, the same name can appear in both a type definition and an element declaration, without conflict or necessary relation between the two. Within a given schema there are distinct symbol spaces for each kind of named definition and declaration component identified in XML SchemaXSD Abstract Data Model (§2.2), except that simple type definitions and complex type definitions share a symbol space. Within a given symbol space, names must be unique; as a consequence, each expanded name within a given symbol space uniquely identifies a single component. The same expanded name may however appear in more than one symbol space without conflict. For example, assuming that the namespace prefix my is bound to some particular namespace, both a simple type definition and a top-level element declaration can bear the name my:abc without conflict or necessary relation between the two. But it is not possible for both a simple type definition and a complex type definition, or two distinct top-level element declarations, to share the name my:abc.

Locally scoped attribute and element declarations are special with regard to symbol spaces. Every complex type definition defines its own local attribute and element declaration symbol spaces, where these symbol spaces are distinct from each other and from any of the other symbol spaces.Their names are not included in the global symbol spaces for attribute and element names; each complex type definition defines its own attribute symbol space, and elements local to a complex type definition are constrained by Element Declarations Consistent (§3.8.6.3), but not by means of symbol spaces. Their names are not regarded as being in any particular symbol space. So, for example, two complex type definitions having the same target namespace can contain a local attribute declaration for the unqualified name "priority", or contain a local element declaration for the name "address", without conflict or necessary relation between the two.

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

        2.7.1 xsi:type
        2.7.2 xsi:nil
        2.7.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation

The XML representation of schema components uses a vocabulary identified by the namespace name http://www.w3.org/2001/XMLSchema. For brevity, the text and examples in this specification use the prefix xs: to stand for this namespace; in practice, any prefix can be used.

XML Schema Definition Language: Structures also defines several attributes for direct use in any XML documents. These attributes are in a different namespace, which has the namespace name http://www.w3.org/2001/XMLSchema-instance. For brevity, the text and examples in this specification use the prefix xsi: to stand for this latter namespace; in practice, any prefix can be used.These attributes are in the schema instance namespace (http://www.w3.org/2001/XMLSchema-instance) described in The Schema Instance Namespace (xsi) (§1.3.1.2) above. All schema processors must have appropriate attribute declarations for these attributes built in, see Attribute Declaration for the 'type' attribute (§3.2.7.1), Attribute Declaration for the 'nil' attribute (§3.2.7.2), Attribute Declaration for the 'schemaLocation' attribute (§3.2.7.3) and Attribute Declaration for the 'noNamespaceSchemaLocation' attribute (§3.2.7.4).

Note: As described above (Conventional Namespace Bindings (§1.3.3)), the attributes described in this section are referred to in this specification as "xsi:type", "xsi:nil", etc. This is shorthand for "an attribute information item whose [namespace name] is http://www.w3.org/2001/XMLSchema-instance and whose [local name] is type" (or nil, etc.).

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

2.7.1 xsi:type

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

2.7.2 xsi:nil

XML Schema Definition Language: Structures introduces a mechanism for signaling that an element shouldmust be accepted as ·valid· when it has no content despite a content type which does not require or even necessarily allow empty content. An element may becan be ·valid· without content if it has the attribute xsi:nil with the value true. An element so labeled must be empty, but can carry attributes if permitted by the corresponding complex type.

2.7.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation

The xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes can be used in a document to provide hints as to the physical location of schema documents which maycan be used for ·assessment·. See How schema definitions are located on the Web (§4.3.2) for details on the use of these attributes.

Note: The xsi:schemaLocation attribute typically appears in XML document instances being ·validated·; it is distinct from the schemaLocation attribute defined for some elements in schema documents (which is not always a hint but sometimes a firm directive).

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

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

3 Schema Component Details

next sub-section3.1 Introduction

The following sections provide full details on the composition of all schema components, together with their XML representations and their contributions to ·assessment·. Each section is devoted to a single component, with separate subsections for
  1. properties: their values and significance
  2. XML representation and the mapping to properties
  3. constraints on representation
  4. validation rules
  5. constraints on the components themselves
The sub-sections immediately below introduce conventions and terminology used throughout the component sections.

3.1.1 Components and Properties

Components are defined in terms of their properties, and each property in turn is defined by giving its range, that is the values it maymay have. This can be understood as defining a schema as a labeled directed graph, where the root is a schema, every other vertex is a schema component or a literal (string, boolean, numberdecimal) and every labeled edge is a property. The graph is not acyclic: multiple copies of components with the same name in the same ·symbol space· may notmust not exist, so in some cases re-entrant chains of properties mustwill exist. Equality of components for the purposes of this specification is always defined as equality of names (including target namespaces) within symbol spaces.

Note: A schema and its components as defined in this chapter are an idealization of the information a schema-aware processor requires: implementations are not constrained in how they provide it. In particular, no implications about literal embedding versus indirection follow from the use below of language such as "properties . . . having . . . components as values".

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

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

Any property not identified as optional is required to be presentnot defined as optional is always present; optional properties which are not present are taken to have ·absent· as their value. Any property identified as a having a set, subset or list value maymight have an empty value unless this is explicitly ruled out: this is not the same as ·absent·. Any property value identified as a superset or subset of some set maymight be equal to that set, unless a proper superset or subset is explicitly called for. By 'string' in Part 1 of this specification is meant a sequence of ISO 10646 characters identified as legal XML characters in [XML 1.0][XML 1.1].

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

3.1.2 XML Representations of Components

The principal purpose of XML Schema Definition Language: Structures is to define a set of schema components that constrain the contents of instances and augment the information sets thereof. Although no external representation of schemas is required for this purpose, such representations will obviously be widely used. To provide for this in an appropriate and interoperable way, this specification provides a normative XML representation for schemas which makes provision for every kind of schema component. [Definition:]  A document in this form (i.e. a <schema> element information item) is a schema document. For the schema document as a whole, and its constituents, the sections below define correspondences between element information items (with declarations in Schema for SchemasSchema Documents (Structures) (normative) (§A) and DTD for Schemas (non-normative) (§K)) and schema components. All theThe key element information items in the XML representation of a schema must beare in the XML SchemaXSD namespace, that is their [namespace name] must beis http://www.w3.org/2001/XMLSchema. Although a common way of creating the XML Infosets which are or contain ·schema documents· will be using an XML parser, this is not required: any mechanism which constructs conformant infosets as defined in [XML Infoset] is a possible starting point.

Two aspects of the XML representations of components presented in the following sections are constant across them all:
  1. All of them allow attributes qualified with namespace names other than the XML SchemaXSD namespace itself: these appear as annotations in the corresponding schema component;
  2. All of them allow an <annotation> as their first child, for human-readable documentation and/or machine-targeted information.

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 described in Conditional inclusion (§4.2.2).

3.1.3 The Mapping between XML Representations and Components

For each kind of schema component there is a corresponding normative XML representation. The sections below describe the correspondences between the properties of each kind of schema component on the one hand and the properties of information items in that XML representation on the other, together with constraints on that representation above and beyond those implicitexpressed in the Schema for SchemasSchema Documents (Structures) (normative) (§A). Neither the correspondences described nor the XML Representation Constraints apply to elements in the Schema namespace which occur as descendants of <appinfo> or <documentation>.

The language used is as if the correspondences were mappings from XML representation to schema component, but the mapping in the other direction, and therefore the correspondence in the abstract, can always be constructed therefrom.

In discussing the mapping from XML representations to schema components below, the value of a component property is often determined by the value of an attribute information item, one of the [attributes] of an element information item. Since schema documents are constrained by the Schema for SchemasSchema Documents (Structures) (normative) (§A), there is always a simple type definition associated with any such attribute information item. [Definition:]   The phrase actual value is used to refer to the member of the value space of the simple type definition associated with an attribute information item which corresponds to its ·normalized value·With reference to any string, interpreted as denoting an instance of a given datatype, the term actual value denotes the value to which the lexical mapping of that datatype maps the string. .In the case of attributes in schema documents, the string used as the lexical representation is normally the ·normalized value· of the attribute. The associated datatype is, unless otherwise specified, the one identified in the declaration of the attribute, in the schema for schema documents; in some cases (e.g. the enumeration facet, or fixed and default values for elements and attributes) the associated datatype will be a more specific one, as specified in the appropriate XML mapping rules. The ·actual value· This will often be a string, but maycan also be an integer, a boolean, a URI reference, etc. This term is also occasionally used with respect to element or attribute information items in a document being ·validatedassessed·.

Many properties are identified below as having other schema components or sets of components as values. For the purposes of exposition, the definitions in this section assume that (unless the property is explicitly identified as optional) all such values are in fact present. When schema components are constructed from XML representations involving reference by name to other components, this assumption maywill in some cases be violated if one or more references cannot be resolved·resolved·. This specification addresses the matter of missing components in a uniform manner, described in Missing Sub-components (§5.3): no mention of handling missing components will be found in the individual component descriptions below.

Forward reference to named definitions and declarations is allowed, both within and between ·schema documents·. By the time the component corresponding to an XML representation which contains a forward reference is actually needed for ·validation·, it is possible that an appropriately-named component maywill have become available to discharge the reference: see Schemas and Namespaces: Access and Composition (§4) for details.

3.1.4 White Space Normalization during Validation

Throughout this specification, [Definition:]  the initial value of some attribute information item is the value of the [normalized value] property of that item. Similarly, the initial value of an element information item is the string composed of, in order, the [character code] of each character information item in the [children] of that element information item.

The above definition means that comments and processing instructions, even in the midst of text, are ignored for allmost ·validation· purposes. For the exception to this rule, see the discussion of comments and processing instructions in Assertion Satisfied (§3.13.4.1).

[Definition:]  The normalized value of an element or attribute information item is an ·initial value· whose white space, if any,which has been normalized according to the value of the whiteSpace facet of, and the values of any other pre-lexical facets, associated with the simple type definition used in its ·validation·:. The keywords for whitespace normalization have the following meanings:
preserve
No normalization is done, the whitespace-normalized value is the ·normalized value··initial value·
replace
All occurrences of #x9 (tab), #xA (line feed) and #xD (carriage return) are replaced with #x20 (space).
collapse
Subsequent to the replacements specified above under replace, contiguous sequences of #x20s are collapsed to a single #x20, and initial and/or final #x20s are deleted.
Similarly, the normalized value of any string with respect to a given simple type definition is the string resulting from normalization using the whiteSpace facet and any other pre-lexical facets, associated with that simple type definition.

When more than one pre-lexical facet applies, the whiteSpace facet is applied first; the order in which ·implementation-defined· facets are applied is ·implementation-defined·.

If the simple type definition used in an item's ·validation· is the ·simple ur-type definition··xs:anySimpleType·, then the ·normalized value· must be determined as in the preserve case above.

There are three alternative validation rules which mayhelp supply the necessary background for the above: Attribute Locally Valid (§3.2.4.1) (clause 3), Element Locally Valid (Type) (§3.3.4.5) (clause 3.1.3) or Element Locally Valid (Complex Type) (§3.4.4.2) (clause 2.2).

These three levels of normalization correspond to the processing mandated in XML 1.0 for element content, CDATA attribute content and tokenized attributed content, respectively. See Attribute Value Normalization in [XML 1.0][XML 1.1] for the precedent for replace and collapse for attributes. Extending this processing to element content is necessary to ensure a consistent ·validation· semantics for simple types, regardless of whether they are applied to attributes or elements. Performing it twice in the case of attributes whose [normalized value] has already been subject to replacement or collapse on the basis of information in a DTD is necessary to ensure consistent treatment of attributes regardless of the extent to which DTD-based information has been made use of during infoset construction.

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

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

        3.2.1 The Attribute Declaration Schema Component
        3.2.2 XML Representation of Attribute Declaration Schema Components
            3.2.2.1 Mapping Rules for Global Attribute Declarations
            3.2.2.2 Mapping Rules for Local Attribute Declarations
            3.2.2.3 Mapping Rules for References to Top-level Attribute Declarations
        3.2.3 Constraints on XML Representations of Attribute Declarations
        3.2.4 Attribute Declaration Validation Rules
            3.2.4.1 Attribute Locally Valid
            3.2.4.2 Governing Attribute Declaration and Governing Type Definition
            3.2.4.3 Schema-Validity Assessment (Attribute)
        3.2.5 Attribute Declaration Information Set Contributions
            3.2.5.1 Assessment Outcome (Attribute)
            3.2.5.2 Validation Failure (Attribute)
            3.2.5.3 Attribute Declaration
            3.2.5.4 Attribute Validated by Type
        3.2.6 Constraints on Attribute Declaration Schema Components
            3.2.6.1 Attribute Declaration Properties Correct
            3.2.6.2 Simple Default Valid
            3.2.6.3 xmlns Not Allowed
            3.2.6.4 xsi: Not Allowed
        3.2.7 Built-in Attribute Declarations
            3.2.7.1 xsi:type
            3.2.7.2 xsi:nil
            3.2.7.3 xsi:schemaLocation
            3.2.7.4 xsi:noNamespaceSchemaLocation

Attribute declarations provide for:

  • Local ·validation· of attribute information item values using a simple type definition;
  • Specifying default or fixed values for attribute information items.
Example
<xs:attribute name="age" type="xs:positiveInteger" use="required"/>
The XML representation of an attribute declaration.

3.2.1 The Attribute Declaration Schema Component

The attribute declaration schema component has the following properties:

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

Either global or a complex type definition.

{scope}
A Scope property record. Required.
{value constraint }
Optional.

A pair consisting of a value and one of default, fixed.

{value constraint}
A Value Constraint property record. Optional.
{inheritable}
An xs:boolean value. Required.
Property Record: Scope
{variety}
One of {global, local}. Required.
{parent }
A Complex Type Definition component. Required if {variety} is local, otherwise must be ·absent·
{parent}
Either a Complex Type Definition or a Attribute Group Definition. Required if {variety} is local, otherwise must be ·absent·
Property Record: Value Constraint
{variety}
One of {default, fixed}. Required.
{value}
An ·actual value·. Required.
{lexical form}
A character string. Required.

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

The value of the each attribute validated must conform to the supplied {type definition}.

A non-·absent··non-absent· value of the {target namespace} property provides for ·validation· of namespace-qualified attribute information items (which must be explicitly prefixed in the character-level form of XML documents). ·Absent· values of {target namespace} ·validate· unqualified (unprefixed) items.

A {scope} of global identifies attribute declarations available for use in complex type definitions throughout the schema. Locally scoped declarations are available for use only within the complex type definition identified by the {scope} property. This property is ·absent· in the case of declarations within attribute group definitions: their scope will be determined when they are used in the construction of complex type definitions.

For an attribute declaration A, if A.{scope}.{variety} = global, then A is available for use throughout the schema. If A.{scope}.{variety} = local, then A is available for use only within (the Complex Type Definition or Attribute Group Definition) A.{scope}.{parent}.

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

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

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

[XML Infoset] distinguishes attributes with names such as xmlns or xmlns:xsl from ordinary attributes, identifying them as [namespace attributes]. Accordingly, it is unnecessary and in fact not possible for schemas to contain attribute declarations corresponding to such namespace declarations, see xmlns Not Allowed (§3.2.6.3). No means is provided in this specification to supply a default value for a namespace declaration.

3.2.2 XML Representation of Attribute Declaration Schema Components

The XML representation for an attribute declaration schema component is an <attribute> element information item. It specifies a simple type definition for an attribute either by reference or explicitly, and maymay provide default information. The correspondences between the properties of the information item and properties of the component are as follows: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.

The default when no simple type definition is referenced or provided is the ·simple ur-type definition·, which imposes no constraints at all.

XML Representation Summary: attribute Element Information Item
<attribute
  default = string
  fixed = string
  form = (qualified | unqualified)
  id = ID
  name = NCName
  ref = QName

  targetNamespace = anyURI

  type = QName
  use = (optional | prohibited | required) : optional

  inheritable = boolean

  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, simpleType?)
</attribute>

An <attribute> element maps to an attribute declaration, and allows the type definition of that declaration to be specified either by reference or by explicit inclusion.

Top-level <attribute> elements (i.e. those which appear within the schema document as children of <schema> elements) produce global attribute declarations; <attribute>s within <attributeGroup> or <complexType> produce either attribute uses which contain global attribute declarations (if there's a ref attribute) or local declarations (otherwise). For complete declarations, top-level or local, the type attribute is used when the declaration can use a built-in or user-defined global type definition. Otherwise an anonymous <simpleType> is provided inline.

Attribute information items ·validated· by a top-level declaration must be qualified with the {target namespace} of that declaration (if this is ·absent·, the item must be unqualified).. If the {target namespace} is ·absent·, the item must be unqualified. Control over whether attribute information items ·validated· by a local declaration must be similarly qualified or not is provided by the form [attribute], whose default is provided by the attributeFormDefault [attribute] on the enclosing <schema>, via its determination of {target namespace}.

The names for top-level attribute declarations are in their own ·symbol space·. The names of locally-scoped attribute declarations reside in symbol spaces local to the type definition which contains them.

The following sections specify several sets of XML mapping rules which apply in different circumstances.
3.2.2.1 Mapping Rules for Global Attribute Declarations

If the <attribute> element information item has <schema> as its parent, the corresponding schema component is as follows:

XML Mapping Summary for Attribute Declaration Schema Component
Property
Representation
 
 
The ·actual value· of the targetNamespace [attribute] of the parent <schema> element information item, or ·absent· if there is none.
 
The simple type definition corresponding to the <simpleType> element information item in the [children], if present, otherwise the simple type definition ·resolved· to by the ·actual value· of the type [attribute], if present, otherwise the ·simple ur-type definition··xs:anySimpleType·.
 
A Scope as follows:
Property
Value
global
 
If there is a default or a fixed [attribute], then a pair consisting ofa Value Constraint as follows, otherwise ·absent·.
Property
Value
either default or fixed, as appropriate
the ·actual value· (with respect to the {type definition}) of thatthe [attribute]
 
The ·actual value· of the inheritable [attribute], if present, otherwise false.
 
The annotation corresponding to the <annotation> element information item in the [children], if present, otherwise ·absent·. The ·annotation mapping· of the <attribute> element, as defined in XML Representation of Annotation Schema Components (§3.15.2).
3.2.2.2 Mapping Rules for Local Attribute Declarations

otherwise ifIf the <attribute> element information item has <complexType> or <attributeGroup> as an ancestor and the ref [attribute] is absent, it correspondsmaps both to an attribute declaration (see below) and to an attribute use with properties as follows (unless use='prohibited', in which case the item corresponds to nothing at all):

XML Mapping Summary for Attribute Use Schema Component
Property
Representation
 
true if the use [attribute] is present with ·actual value· requiredthe <attribute> element has use = required, otherwise false.
 
See the Attribute Declaration mapping immediately below.
 
If there is a default or a fixed [attribute], then a pair consisting of Value Constraint as follows, otherwise ·absent·.
Property
Value
either default or fixed, as appropriate
the ·actual value· (with respect to the {type definition} of the {attribute declaration}) of thatthe [attribute] (with respect to {attribute declaration}.{type definition})
 
The ·actual value· of the inheritable [attribute], if present, otherwise false.
 
The same annotations as the {annotations} of the Attribute Declaration. See below.

The <attribute> element also maps to the {attribute declaration} of the attribute use, as follows:

XML Mapping Summary for Attribute Declaration Schema Component
Property
Representation
 
 
If form is present and its ·actual value· is qualified, or if form is absent and the ·actual value· of attributeFormDefault on the <schema> ancestor is qualified, then the ·actual value· of the targetNamespace [attribute] of the parent <schema> element information item, or ·absent· if there is none, otherwise ·absent·.
 
The appropriate case among the following:
1 If targetNamespace is present , then its ·actual value·.
2 If targetNamespace is not present and one of the following is true
2.1 form = qualified
2.2 form is absent and the <schema> ancestor has attributeFormDefault = qualified
then the ·actual value· of the targetNamespace [attribute] of the ancestor <schema> element information item, or ·absent· if there is none.
3 otherwise ·absent·.
 
The simple type definition corresponding to the <simpleType> element information item in the [children], if present, otherwise the simple type definition ·resolved· to by the ·actual value· of the type [attribute], if present, otherwise the ·simple ur-type definition··xs:anySimpleType·.
 
A Scope as follows:
Property
Value
If the <attribute> element information item has <complexType> as an ancestor, the Complex Type Definition corresponding to that item, otherwise (the <attribute> element information item is within an <attributeGroup> definitionelement information item), ·absent·the Attribute Group Definition corresponding to that item.
 
 
The ·actual value· of the inheritable [attribute], if present, otherwise false.
 
The annotation corresponding to the <annotation> element information item in the [children], if present, otherwise ·absent·. The ·annotation mapping· of the <attribute> element, as defined in XML Representation of Annotation Schema Components (§3.15.2).
3.2.2.3 Mapping Rules for References to Top-level Attribute Declarations

otherwise (If the <attribute> element information item has <complexType> or <attributeGroup> as an ancestor and the ref [attribute] is present), it correspondsmaps to an attribute use with properties as follows (unless use='prohibited', in which case the item corresponds to nothing at all):

XML Mapping Summary for Attribute Use Schema Component
Property
Representation
 
true if the use [attribute] is present with ·actual value· requireduse = required, otherwise false.
 
The (top-level) attribute declaration ·resolved· to by the ·actual value· of the ref [attribute]
 
If there is a default or a fixed [attribute], then a pair consisting of Value Constraint as follows, otherwise ·absent·.
Property
Value
either default or fixed, as appropriate
the ·actual value· (with respect to the {type definition} of the {attribute declaration}) of thatthe [attribute] (with respect to {attribute declaration}.{type definition})
 
The ·actual value· of the inheritable [attribute], if present, otherwise {attribute declaration}.{inheritable}.

3.2.3 Constraints on XML Representations of Attribute Declarations

Schema Representation Constraint: Attribute Declaration Representation OK
In addition to the conditions imposed on <attribute> element information items by the schema for schemas documents, all of the following must be truealso apply :
1 default and fixed must not both be present.
2 If default and use are both present, use must have the ·actual value· optional.
3 If the item's parent is not <schema>, then all of the following mustmust be true:
3.1 One of ref or name must beis present, but not both.
3.2 If ref is present, then all of <simpleType>, form and type must beare absent.
4 The type attribute and a <simpleType> child element must not both be present.
5
If fixed and use are both present, use must not have the ·actual value· prohibited.
6
If the targetNamespace attribute is present then all of the following mustmust be true:
6.1 The name attribute is present.
6.2 The form attribute is absent.
6.3 If the ancestor <schema> does not have a targetNamespace [attribute] or its ·actual value· is different from the ·actual value· of targetNamespace of <attribute>, then all of the following are true:
6.3.1 <attribute> has <complexType> as an ancestor
6.3.2 There is a <restriction> ancestor between the <attribute> and the nearest <complexType> ancestor, and the ·actual value· of the base [attribute] of <restriction> does not ·match· the name of ·xs:anyType·.
7
The corresponding attribute declaration must satisfy the conditions set out in Constraints on Attribute Declaration Schema Components (§3.2.6).

3.2.4 Attribute Declaration Validation Rules

3.2.4.1 Attribute Locally Valid

Informally, an attribute in an XML instance is locally ·valid· against an attribute declaration if and only if (a) the name of the attribute matches the name of the declaration, (b) after whitespace normalization its ·normalized value· is locally valid against the type declared for the attribute, and (c) the attribute obeys any relevant value constraint. Additionally, for xsi:type, it is required that the type named by the attribute be present in the schema. A logical prerequisite for checking the local validity of an attribute against an attribute declaration is that the attribute declaration itself and the type definition it identifies both be present in the schema.

Local validity of attributes is tested as part of schema-validity ·assessment· of attributes (and of the elements on which they occur), and the result of the test is exposed in the [validity] property of the ·post-schema-validation infoset·.

A more formal statement is given in the following constraint.

Validation Rule: Attribute Locally Valid
For an attribute information item A to be locally ·valid· with respect to an attribute declaration D all of the following mustmust be true:
1 The declarationD must not beis not ·absent· (see Missing Sub-components (§5.3) for how this can fail to be the case) and D and A have the same expanded name.
2 Its {type definition}D.{type definition} must not beis not absent·absent·.
3 The itemA's ·normalized value··initial value· must beis locally ·valid· with respect to that D.{type definition} as per String Valid (§3.16.4).
4 The item's ·actual value· must match the value of the {value constraint}, ifIf itD.{value constraint} is present and fixed D.{value constraint}.{variety} = fixed, then A's ·actual value· is equal or identical to D.{value constraint}.{value}.
5
If D is the built-in declaration for xsi:type (Attribute Declaration for the 'type' attribute (§3.2.7.1)), then A's ·actual value· ·resolves· to a type definition.
3.2.4.2 Governing Attribute Declaration and Governing Type Definition
[Definition:]   In a given schema-validity ·assessment· episode, the ·governing· declaration of an attribute (its governing attribute declaration) is the first of the following which applies:
1 A declaration which was stipulated by the processor (see Assessing Schema-Validity (§5.2)).
3 A declaration ·resolved· to by its [local name] and [namespace name], provided the attribute is not ·skipped· and the processor has not stipulated a type definition at the start of ·assessment·.
If none of these applies, the attribute has no ·governing attribute declaration· (or, in equivalent words, the ·governing attribute declaration· is ·absent·).
Note: As a consequence, unless ·skipped· or stipulated otherwise, attributes named xsi:type, xsi:nil, xsi:schemaLocation, or xsi:noNamespaceSchemaLocation are always governed by their corresponding built-in declarations (see Built-in Attribute Declarations (§3.2.7)).
[Definition:]   The governing type definition of an attribute, in a given schema-validity ·assessment· episode, is the first of the following which applies:
1 A type definition stipulated by the processor (see Assessing Schema-Validity (§5.2)).
If neither of these applies, there is no ·governing type definition· (or, in equivalent words, it is ·absent·).
3.2.4.3 Schema-Validity Assessment (Attribute)

Schema-validity assessment of an attribute information item involves identifying its ·governing attribute declaration· and checking its local validity against the declaration. If the ·governing type definition· is not present in the schema, then assessment is necessarily incomplete.

Validation Rule: Schema-Validity Assessment (Attribute)
The schema-validity assessment of an attribute information item depends on its local ·validation· alone.
[Definition:]  During ·validation·, associations between element and attribute information items among the [children] and [attributes] on the one hand, and element and attribute declarations on the other, are established as a side-effect. Such declarations are called the context-determined declarations. See clause 3.1 (in Element Locally Valid (Complex Type) (§3.4.4.2)) for attribute declarations, clause 2 (in Element Sequence Locally Valid (Particle) (§3.9.4.2)) for element declarations.
For an attribute information item's schema-validity to have been assessed all of the following mustmust be true:
1 A non-·absent··non-absent· attribute declaration must beis known for it, namely its ·governing· declaration.
one of the following:
1.1 A declaration which has been established as its ·context-determined declaration·;
1.2 A declaration resolved to by its [local name] and [namespace name] as defined by QName resolution (Instance) (§3.17.6.3), provided its ·context-determined declaration· is not skip.
2 Its local ·validity· with respect to that declaration must havehas been evaluated as per Attribute Locally Valid (§3.2.4.1).
3 Both clause 1 and clause 2 of Attribute Locally Valid (§3.2.4.1) must beare satisfied.

[Definition:]  For attribute information items, there is no difference between assessment and strict assessment, so if the above holds, the attribute information item has been strictly assessed if and only if its schema-validity has been assessed.

3.2.5 Attribute Declaration Information Set Contributions

3.2.5.1 Assessment Outcome (Attribute)
Schema Information Set Contribution: Assessment Outcome (Attribute)
If the schema-validity of an attribute information item has been assessed as per Schema-Validity Assessment (Attribute) (§3.2.4.3), then in the ·post-schema-validation infoset· it has properties as follows:
PSVI Contributions for attribute information items
[validation context]
The nearest ancestor element information item with a [schema information] property.
[validity]
The appropriate case among the following:
1 If it was ·strictly assessed·, then the appropriate case among the following:
1.1 If it was locally ·valid· as defined by Attribute Locally Valid (§3.2.4.1), then valid;
1.2 otherwise invalid.
2 otherwise notKnown.
[validation attempted]
The appropriate case among the following:
1 If it was ·strictly assessed·, then full;
2 otherwise none.
[schema specified]
infoset. See Attribute Default Value (§3.4.5.1) for the other possible value.
3.2.5.2 Validation Failure (Attribute)
Schema Information Set Contribution: Validation Failure (Attribute)
If and only if the local ·validity·, as defined by Attribute Locally Valid (§3.2.4.1) above, of an attribute information item has been assessed, then in the ·post-schema-validation infoset· the item has a property:
PSVI Contributions for attribute information items
[schema error code]
The appropriate case among the following:
1 If the item is not ·valid··invalid·, then a list. Applications wishing to provide information as to the reason(s) for the ·validation· failure are encouraged to record one or more error codes (see Outcome Tabulations (normative) (§C)) herein.
2 otherwise ·absent·.
3.2.5.3 Attribute Declaration
Schema Information Set Contribution: Attribute Declaration
If and only if a ·governing· declaration is known for an attribute information item is ·valid· with respect to an attribute declaration as per Attribute Locally Valid (§3.2.4.1) then in the ·post-schema-validation infoset· the attribute information item may, at processor option, havehas a property:
PSVI Contributions for attribute information items
[attribute declaration]
An ·item isomorphic· to the ·governing· declaration component itself.
[schema default]
If the attribute information item is ·attributed· to an Attribute Use then the {lexical form} of the ·effective value constraint·, otherwise the {lexical form} of the declaration's {value constraint}.
3.2.5.4 Attribute Validated by Type
Schema Information Set Contribution: Attribute Validated by Type
If clause 3 of Attribute Locally Valid (§3.2.4.1) applies with respect toand only if a ·governing type definition· is known for an attribute information item, then in the ·post-schema-validation infoset· the attribute information item has a propertythe properties:
PSVI Contributions for attribute information items
[schema normalized value]
The If the attribute's ·normalized value· is ·valid· with respect to the ·governing type definition·, then the ·normalized value· of the item as ·validated·, otherwise ·absent·.
[schema actual value]
If the [schema normalized value] is not ·absent·, then the corresponding ·actual value·; otherwise ·absent·.
[type definition anonymous]
true if the {name} of the ·type definition· is ·absent·, otherwise false.
[type definition name]
The {name} of the ·type definition·, if the {name} is not ·absent·. If the ·type definition·'s {name} property is ·absent·, then schema processors may, but need not, provide a value which uniquely identifies this type definition among those with the same target namespace. It is ·implementation-defined· whether a processor provides a name for such a type definition. If a processor does provide a value in this situation, the choice of what value to use is ·implementation-dependent·.
Furthermore, the item has one of the following alternative sets of properties:
Either
PSVI Contributions for attribute information items
[type definition]
An ·item isomorphic· to the relevant attribute declaration's {type definition} component.
[member type definition]
If and only if that type definition has {variety} union, then an ·item isomorphic· to that member of its {member type definitions} which actually ·validated· the attribute item's [normalized value].
or
PSVI Contributions for attribute information items
[type definition type]
simple.
[type definition namespace]
The {target namespace} of the ·type definition·.
[type definition anonymous]
true if the {name} of the ·type definition· is ·absent·, otherwise false.
[type definition name]
The {name} of the ·type definition·, if it is not ·absent·. If it is ·absent·, schema processors may, but need not, provide a value unique to the definition.
Note: The [type definition type], [type definition namespace], [type definition name], and [type definition anonymous] properties are redundant with the [type definition] property; they are defined for the convenience of implementations which wish to expose those specific properties but not the entire type definition.
If the attribute's ·initial value· is ·valid· with respect to the ·governing type definition· as defined by String Valid (§3.16.4) and the ·type definition··governing type definition· has {variety} union, then calling [Definition:]   that member of the {member type definitions} which actually ·validated· the attribute item's ·normalized value· the actual member type definition, there are threefour additional properties:
PSVI Contributions for attribute information items
[member type definition namespace]
The {target namespace} of the ·actual member type definition··validating type·.
[member type definition anonymous]
true if the {name} of the ·actual member type definition··validating type· is ·absent·, otherwise false.
[member type definition name]
The {name} of the ·actual member type definition··validating type·, if it is not ·absent·. If it is ·absent·, schema processors may, but need not, provide a value unique to the definition. It is ·implementation-defined· whether a processor provides a name for such a type definition. If a processor does provide a value in this situation, the choice of what value to use is ·implementation-dependent·.
The first (·item isomorphic·) alternative above is provided for applications such as query processors which need access to the full range of details about an item's ·assessment·, for example the type hierarchy; the second, for lighter-weight processors for whom representing the significant parts of the type hierarchy as information items might be a significant burden.
If all of the following are true:
1 the attribute's ·normalized value· is ·valid· with respect to the ·governing type definition·;
2 One of the following is true:
3 the {item type definition} of the list type (from the previous clause) has {variety} = union;
then there is an additional property:
PSVI Contributions for attribute information items
[member type definitions]
a sequence of Simple Type Definition components, with the same length as the [schema actual value], each one an ·item isomorphic· to the ·validating type· of the corresponding item in the [schema actual value].
Also, if the declaration has a {value constraint}, the item has a property:
PSVI Contributions for attribute information items
If the attribute information item was not ·strictly assessed·, then instead of the values specified above,
1 The item's [schema normalized value] property has the ·initial value· of the item as its value;
2 The [type definition] and [member type definition] properties, or their alternatives, are based on the ·simple ur-type definition·.

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

3.2.6 Constraints on Attribute Declaration Schema Components

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

3.2.6.1 Attribute Declaration Properties Correct
Schema Component Constraint: Attribute Declaration Properties Correct
All of the following mustmust be true:
1 The values of the properties of an attribute declaration must beare as described in the property tableau in The Attribute Declaration Schema Component (§3.2.1), modulo the impact of Missing Sub-components (§5.3).
2 if there is a {value constraint}, then the canonical lexical representation of its value must be ·valid· with respect to the {type definition} as defined in String Valid (§3.16.4)it is a valid default with respect to the {type definition} as defined in Simple Default Valid (§3.2.6.2).
3
If the {type definition} is or is derived from ID then there must not be a {value constraint}.
Note: The use of ID and related types together with value constraints goes beyond what is possible with XML DTDs, and should be avoided if compatibility with DTDs is desired.
3.2.6.2 Simple Default Valid
Schema Component Constraint: Simple Default Valid
For a Value Constraint V to be a valid default with respect to a Simple Type Definition T all of the following must be true:
1 V.{lexical form} is ·valid· with respect to T as defined by Datatype Valid in [XML Schema: Datatypes].
2 V.{lexical form} maps to V.{value} in the value space of T.
3.2.6.3 xmlns Not Allowed
Schema Component Constraint: xmlns Not Allowed
The {name} of an attribute declaration must not match xmlns.
Note: The {name} of an attribute is an ·NCName·, which implicitly prohibits attribute declarations of the form xmlns:*.
3.2.6.4 xsi: Not Allowed
Schema Component Constraint: xsi: Not Allowed
The {target namespace} of an attribute declaration, whether local or top-level, must not match http://www.w3.org/2001/XMLSchema-instance (unless it is one of the four built-in declarations given in the next section).
Note: This reinforces the special status of these attributes, so that they not only need not be declared to be allowed in instances, but in consequence of the rule just given must notmust not be declared. It also removes any temptation to experiment with supplying global or fixed values for e.g. xsi:type or xsi:nil, which would be seriously misleading, as they would have no effect.
Note: It is legal for Attribute Uses that refer to xsi: attributes to specify default or fixed value constraints (e.g. in a component corresponding to a schema document construct of the form <xs:attribute ref="xsi:type" default="xs:integer"/>), but the practice is not recommended; including such attribute uses will tend to mislead readers of the schema document, because the attribute uses would have no effect; see Element Locally Valid (Complex Type) (§3.4.4.2) and Attribute Default Value (§3.4.5.1) for details.

3.2.7 Built-in Attribute Declarations

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

3.2.7.1 xsi:type

The xsi:type attribute is used to signal use of a type other than the declared type of an element. See xsi:type (§2.7.1).

3.2.7.2 xsi:nil

The xsi:nil attribute is used to signal that an element's content is "nil" (or "null"). See xsi:nil (§2.7.2).

3.2.7.3 xsi:schemaLocation

The xsi:schemaLocation attribute is used to signal possible locations of relevant schema documents. See xsi:schemaLocation, xsi:noNamespaceSchemaLocation (§2.7.3).

3.2.7.4 xsi:noNamespaceSchemaLocation

The xsi:noNamespaceSchemaLocation attribute is used to signal possible locations of relevant schema documents. See xsi:schemaLocation, xsi:noNamespaceSchemaLocation (§2.7.3).

previous sub-section next sub-section3.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 Conditional Type Substitutable in Restriction
            3.3.4.5 Element Locally Valid (Type)
            3.3.4.6 Validation Root Valid (ID/IDREF)
            3.3.4.7 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 [Optional XPath subset for CTA]
            3.3.6.3 Cartesian Product of Conditional Type Assignments
            3.3.6.4 Element Default Valid (Immediate)
            3.3.6.5 Substitution Group OK (Transitive)
            3.3.6.6 Substitution Group

Element declarations provide for:

  • Local ·validation· of element information item values using a type definition;
  • Specifying default or fixed values for an element information items;
  • Establishing uniquenesses and reference constraint relationships among the values of related elements and attributes;
  • Controlling the substitutability of elements through the mechanism of ·element substitution groups·.
Example
<xs:element name="PurchaseOrder" type="PurchaseOrderType"/>

<xs:element name="gift">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="birthday" type="xs:date"/>
   <xs:element ref="PurchaseOrder"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>
XML representations of several different types of element declaration

3.3.1 The Element Declaration Schema Component

The element declaration schema component has the following properties:

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

A subset of {substitution, extension, restriction}.

{abstract}
An xs:boolean value. Required.
Schema Component: , a kind of Term
{annotations}
A sequence of Annotation components.
{name}

An NCName as defined by [Namespaces in XML 1.0].

{target namespace}

Either ·absent· or a namespace name, as defined in [Namespaces in XML 1.0].

{type definition}

Either a simple type definition or a complex type definition.

{scope}
Optional.

Either global or a complex type definition.

{value constraint}
Optional.

A pair consisting of a value and one of default, fixed.

{nillable}

A boolean.

{identity-constraint definitions}

A set of constraint definitions.

{substitution group affiliation}
Optional.

A top-level element definition.

{substitution group exclusions}

A subset of {extension, restriction}.

{disallowed substitutions}

A subset of {substitution, extension, restriction}.

{abstract}

A boolean.

{annotation}
Optional.

An annotation.

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

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

A {scope} of global identifies element declarations available for use in content models throughout the schema. Locally scoped declarations are available for use only within the complex type identified by the {scope} property. This property is ·absent· in the case of declarations within named model groups: their scope is determined when they are used in the construction of complex type definitions.

For an element declaration E, if E.{scope}.{variety} = global, then E is available for use throughout the schema. If E.{scope}.{variety} = local, then E is available for use only within (the Complex Type Definition or Model Group Definition) E.{scope}.{parent}.

A non-·absent··non-absent· value of the {target namespace} property provides for ·validation· of namespace-qualified element information items. ·Absent· values of {target namespace} ·validate· unqualified items.

An element information item is ·valid· if it satisfiesnormally required to satisfy the {type definition}. For such an item, schema information set contributions appropriate to the {type definition} are added to the corresponding element information item in the ·post-schema-validation infoset·. The type definition against which an element information item is validated (its ·governing type definition·) can be different from the declared {type definition}. The {type table} property of an Element Declaration, which governs conditional type assignment, and the xsi:type attribute of an element information item (see xsi:type (§2.7.1)) can cause the ·governing type definition· and the declared {type definition} to be different.

If {nillable} is true, then an element with no text or element content maycan also be ·valid· if it carries the namespace qualified attribute with [local name] nil from namespace http://www.w3.org/2001/XMLSchema-instance and value true (see xsi:nil (§2.7.2)) even if it has no text or element content despite a {content type} {type definition} which would otherwise require content, if it carries the attribute xsi:nil with the value true (see xsi:nil (§2.7.2)). Formal details of element ·validation· are described in Element Locally Valid (Element) (§3.3.4.3).

[Definition:]  An element information item E is nilled with respect to some element declaration D if and only if all of the following are true:
1 E has xsi:nil = true.
2 D.{nillable} = true.
If E is said to be ·nilled· without the identity of D being clear from the context, then D is assumed to be E's ·governing element declaration·.

{value constraint} establishes a default or fixed value for an element. If a {value constraint} with {variety} = default is specifiedpresent, and if the element being ·validated· is empty, then the canonical form of the supplied constraint value becomes the [schema normalized value] of the ·validated· element in the ·post-schema-validation infoset·. for purposes of calculating the [schema normalized value] and other contributions to the ·post-schema-validation infoset· the element is treated as if {value constraint}.{lexical form} was used as the content of the element. If fixed is specified, then the element's content must either be empty, in which case fixed behaves as default, or its value must matchbe equal or identical to the supplied constraint value{value constraint}.{value}.

Note: When a default value is supplied and used, as described in the second sentence of the preceding paragraph, the default value is used to calculate the [schema normalized value], etc., but the actual content of the element is not changed: the element contained no character information items in the input information set, and it contains none in the PSVI.
Note: The provision of defaults for elements goes beyond what is possible in XML 1.0 DTDs, and does not exactly correspond to defaults for attributes. In particular, an element with a non-empty {value constraint} whose simple type definition includes the empty string in its lexical space will nonetheless never receive that value, because the {value constraint} will override it.

{identity-constraint definitions} express constraints establishing uniquenesses and reference relationships among the values of related elements and attributes. See Identity-constraint Definitions (§3.11).

Element declarations are potential members of the substitution group, if any, identified by {substitution group affiliation}.The {substitution group affiliations} property of an element declaration indicates which ·substitution groups·, if any, it can potentially be a member of. Potential membership is transitive but not symmetric; an element declaration is a potential member of any group named in its {substitution group affiliations}, and also of any group of which any entry in its {substitution group affiliation}{substitution group affiliations} is a potential member. Actual membership maymay be blocked by the effects of {substitution group exclusions} or {disallowed substitutions}, see below.

An empty {substitution group exclusions} allows a declaration to be nominated asnamed in the {substitution group affiliation}{substitution group affiliations} of other element declarations having the same declared {type definition} or typessome type derived·derived· therefrom. The explicit values of {substitution group exclusions}, extension or restriction, rule out element declarations having types which are extensions or restrictions respectively of {type definition}whose derivation from {type definition} involves any extension steps, or restriction steps, respectively. If both values are specified, then the declaration may not be nominated as the {substitution group affiliation} of any other declaration.

The supplied values for {disallowed substitutions} determine whether an element declaration appearing in a ·content model· will be prevented from additionally ·validating· elements (a) with an xsi:type (§2.7.1) that identifies an extension or restriction of the type of the declared element, and/or (b) from ·validating· elements which are in the substitution group·substitution group· headed by the declared element. If {disallowed substitutions} is empty, then all derived·derived· types and substitution group·substitution group· members are allowed.

Element declarations for which {abstract} is true can appear in content models only when substitution is allowed; such declarations may notmust not themselves ever be used to ·validate· element content.

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

3.3.2 XML Representation of Element Declaration Schema Components

The XML representation for an element declaration schema component is an <element> element information item. It specifies a type definition for an element either by reference or explicitly, and maymay provide occurrence and default information. The correspondences between the properties of the information item and properties of the component(s) it corresponds to are as follows: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 = QName

  substitutionGroup = List of QName

  targetNamespace = anyURI

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

An <element> element information item in a schema document corresponds tomaps to an element declaration, and allows the type definition of that declaration to be specified either by reference or by explicit inclusion.

Top-level <element> elements within (i.e. those which appear within the schema document as children of <schema> elements) produce global element declarations; <element>s within <group> or <complexType> produce either particles which contain global element declarations (if there's a ref attribute) or local declarations (otherwise). For complete declarations, top-level or local, the type attribute is used when the declaration can use a built-in or pre-declared user-defined global type definition. Otherwise an anonymous <simpleType> or <complexType> is provided inline.

Element information items ·validated· by a top-level declaration must be qualified with the {target namespace} of that declaration (if this is ·absent·, the item must be unqualified).. If the {target namespace} is ·absent·, the item must be unqualified. Control over whether element information items ·validated· by a local declaration must be similarly qualified or not is provided by the form [attribute], whose default is provided by the elementFormDefault [attribute] on the enclosing <schema>, via its determination of {target namespace}.

As noted above the The names for top-level element declarations are in a separate ·symbol space· from the symbol spaces for the names of type definitions, so there can (but need not be) a simple or complex type definition with the same name as a top-level element. As with attribute names, the names of locally-scoped element declarations with no {target namespace} reside in symbol spaces local to the type definition which contains them.The names of locally-scoped element declarations need not be unique and thus reside in no symbol space at all (but the element declarations are constrained by Element Declarations Consistent (§3.8.6.3)).

Note that the above allows for two levels of defaulting for unspecified type definitions. An <element> with no referenced or included type definition will correspond to an element declaration which has the same type definition as the head of its substitution group if it identifies one, the same type definition as the first substitution-group head named in the substitutionGroup [attribute], if present, otherwise the ·ur-type definition··xs:anyType·. This has the important consequence that the minimum valid element declaration, that is, one with only a name attribute and no contents, is also (nearly) the most general, validating any combination of text and element content and allowing any attributes, and providing for recursive validation where possible.

See below at XML Representation of Identity-constraint Definition Schema Components (§3.11.2) for <key>, <unique> and <keyref>.

The following sections specify several sets of XML mapping rules which apply in different circumstances.
3.3.2.1 Common Mapping Rules for Element Declarations

The following mapping rules apply in all cases where an <element> element maps to an Element Declaration component.

XML Mapping Summary for Element Declaration Schema Component
Property
Representation
 
The ·actual value· of the name [attribute].
 
The type definition corresponding to the <simpleType> or <complexType> element information item in the [children], if either is present, otherwise the type definition ·resolved· to by the ·actual value· of the type [attribute], otherwise the {type definition} of the element declaration ·resolved· to by the ·actual value· of the substitutionGroup [attribute], if present, otherwise the ·ur-type definition·. The first of the following that applies:
1 The type definition corresponding to the <simpleType> or <complexType> element information item in the [children], if either is present.
2 The type definition ·resolved· to by the ·actual value· of the type [attribute], if it is present.
3 The declared {type definition} of the Element Declaration ·resolved· to by the first QName in the ·actual value· of the substitutionGroup [attribute], if present.
 
A Type Table corresponding to the <alternative> element information items among the [children], if any, as follows, otherwise ·absent·.
Property
Value
A sequence of Type Alternatives, each corresponding, in order, to one of the <alternative> elements which have a test [attribute].
Depends upon the final <alternative> element among the [children]. If it has no test [attribute], the final <alternative> maps to the {default type definition}; if it does have a test attribute, it is covered by the rule for {alternatives} and the {default type definition} is taken from the declared type of the Element Declaration. So the value of the {default type definition} is given by the appropriate case among the following:
1 If the <alternative> has no test [attribute], then a Type Alternative corresponding to the <alternative>.
2 otherwise (the <alternative> has a test) a Type Alternative with the following properties:
Property
Value
the empty sequence.
 
The ·actual value· of the nillable [attribute], if present, otherwise false.
 
If there is a default or a fixed [attribute], then a pair consisting of the ·actual value· (with respect to the {type definition}, if it is a simple type definition, or the {type definition}'s {content type}, if that is a simple type definition, or else with respect to the built-in string simple type definition) of that [attribute] and either default or fixed, as appropriatea Value Constraint as follows, otherwise ·absent·.
[Definition:]  Use the name effective simple type definition for the declared {type definition}, if it is a simple type definition, or, if {type definition}.{content type}.{variety} = simple, for {type definition}.{content type}.{simple type definition}, or else for the built-in string simple type definition).
Property
Value
either default or fixed, as appropriate
 
A set consisting of the identity-constraint-definitions corresponding to all the <key>, <unique> and <keyref> element information items in the [children], if any, otherwise the empty set.
 
The element declaration ·resolved· to by the ·actual value· of the substitutionGroup [attribute], if present, otherwise ·absent·.
 
A set of the element declarations ·resolved· to by the items in the ·actual value· of the substitutionGroup [attribute], if present, otherwise the empty set.
 
A set depending on the ·actual value· of the block [attribute], if present, otherwise on the ·actual value· of the blockDefault [attribute] of the ancestor <schema> element information item, if present, otherwise on the empty string. Call this the EBV (for effective block value). Then the value of this property is the appropriate case among the following:
1 If the EBV is the empty string, then the empty set;
2 If the EBV is #all, then {extension, restriction, substitution};
3 otherwise a set with members drawn from the set above, each being present or absent depending on whether the ·actual value· (which is a list) contains an equivalently named item.
Note: Although the blockDefault [attribute] of <schema> maymay include values other than extension, restriction or substitution, those values are ignored in the determination of {disallowed substitutions} for element declarations (they are used elsewhere).
 
As for {disallowed substitutions} above, but using the final and finalDefault [attributes] in place of the block and blockDefault [attributes] and with the relevant set being {extension, restriction}.
 
The ·actual value· of the abstract [attribute], if present, otherwise false.
 
The annotation corresponding to the <annotation> element information item in the [children], if present, otherwise ·absent·.
3.3.2.2 Mapping Rules for Top-Level Element Declarations

If the <element> element information item has <schema> as its parent, the corresponding schema component is as follows:it maps to a global Element Declaration, using the mapping given in Common Mapping Rules for Element Declarations (§3.3.2.1), supplemented by the following.

XML Mapping Summary for Element Declaration Schema Component
Property
Representation
 
The ·actual value· of the targetNamespace [attribute] of the parent <schema> element information item, or ·absent· if there is none.
 
global.A Scope as follows
Property
Value
global
3.3.2.3 Mapping Rules for Local Element Declarations

otherwise ifIf the <element> element information item has <complexType> or <group> as an ancestor, and the ref [attribute] is absent, and it does not have minOccurs=maxOccurs=0, the corresponding schema components are as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all): then it maps both to a Particle and to a local Element Declaration which is the {term} of that Particle. The Particle is as follows:

XML Mapping Summary for Particle Schema Component
Property
Representation
 
The ·actual value· of the minOccurs [attribute], if present, otherwise 1.
 
unbounded, if the maxOccurs [attribute] equals unbounded, otherwise the ·actual value· of the maxOccurs [attribute], if present, otherwise 1.
 
A (local) element declaration as given below.
 
The same annotations as the {annotations} of the {term}.

AnThe <element> element also maps to an element declaration as in the first case above, with the exception of its {target namespace} and {scope} properties, which are as below: using the mapping rules given in Common Mapping Rules for Element Declarations (§3.3.2.1), supplemented by those below:

XML Mapping Summary for Element Declaration Schema Component
Property
Representation
 
If form is present and its ·actual value· is qualified, or if form is absent and the ·actual value· of elementFormDefault on the <schema> ancestor is qualified, then the ·actual value· of the targetNamespace [attribute] of the parent <schema> element information item, or ·absent· if there is none, otherwise ·absent·.
 
The appropriate case among the following:
1 If targetNamespace is present , then its ·actual value·.
2 If targetNamespace is not present and one of the following is true
2.1 form = qualified
2.2 form is absent and the <schema> ancestor has elementFormDefault = qualified
then the ·actual value· of the targetNamespace [attribute] of the ancestor <schema> element information item, or ·absent· if there is none.
3 otherwise ·absent·.
 
If the <element> element information item has <complexType> as an ancestor, the complex definition corresponding to that item, otherwise (the <element> element information item is within a named <group> definition), ·absent·. A Scope as follows:
Property
Value
If the <element> element information item has <complexType> as an ancestor, the Complex Type Definition corresponding to that item, otherwise (the <element> element information item is within a named <group> element information item), the Model Group Definition corresponding to that item.
3.3.2.4 References to Top-Level Element Declarations

otherwise (theIf the <element> element information item has <complexType> or <group> as an ancestor, and the ref [attribute] is present), and it does not have minOccurs=maxOccurs=0, the corresponding schema component is as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all): then it maps to a Particle as follows.

XML Mapping Summary for Particle Schema Component
Property
Representation
 
The ·actual value· of the minOccurs [attribute], if present, otherwise 1.
 
unbounded, if the maxOccurs [attribute] equals unbounded, otherwise the ·actual value· of the maxOccurs [attribute], if present, otherwise 1.
 
The (top-level) element declaration ·resolved· to by the ·actual value· of the ref [attribute].
3.3.2.5 Examples of Element Declarations
Example
<xs:element name="unconstrained"/>

<xs:element name="emptyElt">
 <xs:complexType>
  <xs:attribute ...>. . .</xs:attribute>
 </xs:complexType>
</xs:element>

<xs:element name="contextOne">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="myLocalElement" type="myFirstType"/>
   <xs:element ref="globalElement"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>

<xs:element name="contextTwo">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="myLocalElement" type="mySecondType"/>
   <xs:element ref="globalElement"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>
The first example above declares an element whose type, by default, is the ·ur-type definition··xs:anyType·. The second uses an embedded anonymous complex type definition.
The last two examples illustrate the use of local element declarations. Instances of myLocalElement within contextOne will be constrained by myFirstType, while those within contextTwo will be constrained by mySecondType.
Note: The possibility that differing attribute declarations and/or content models would apply to elements with the same name in different contexts is an extension beyond the expressive power of a DTD in XML 1.0.
Example
 <xs:complexType name="facet">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:attribute name="value" use="required"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>

 <xs:element name="facet" type="xs:facet" abstract="true"/>

 <xs:element name="encoding" substitutionGroup="xs:facet">
  <xs:complexType>
   <xs:complexContent>
    <xs:restriction base="xs:facet">
     <xs:sequence>
      <xs:element ref="annotation" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="value" type="xs:encodings"/>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:element name="period" substitutionGroup="xs:facet">
  <xs:complexType>
   <xs:complexContent>
    <xs:restriction base="xs:facet">
     <xs:sequence>
      <xs:element ref="annotation" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="value" type="xs:duration"/>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:complexType name="datatype">
  <xs:sequence>
   <xs:element ref="facet" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="name" type="xs:NCName" use="optional"/>
  . . .
 </xs:complexType>
An example from a previous version of the schema for datatypes. The facet type is defined and the facet element is declared to use it. The facet element is abstract -- it's only defined to stand as the head for a substitution group·substitution group·. Two further elements are declared, each a member of the facet substitution group·substitution group·. Finally a type is defined which refers to facet, thereby allowing either period or encoding (or any other member of the group).
Example
The following example illustrates conditional type assignment to an element, based on the value of one of the element's attributes. Each instance of the message element will be assigned either to type messageType or to a more specific type derived from it.
The type messageType accepts any well-formed XML or character sequence as content, and carries a kind attribute which can be used to describe the kind or format of the message. The value of kind is either one of a few well known keywords or, failing that, any string.
<xs:complexType name="messageType" mixed="true">
 <xs:sequence>
  <xs:any processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
 </xs:sequence>
 <xs:attribute name="kind">
  <xs:simpleType>
   <xs:union>
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="string"/>
      <xs:enumeration value="base64"/>
      <xs:enumeration value="binary"/>
      <xs:enumeration value="xml"/>
      <xs:enumeration value="XML"/>
     </xs:restriction>
    </xs:simpleType>
    <xs:simpleType>
     <xs:restriction base="xs:string"/>
    </xs:simpleType>
   </xs:union>
  </xs:simpleType>
 </xs:attribute>
 <xs:anyAttribute processContents="skip"/>
</xs:complexType>
Three restrictions of messageType are defined, each corresponding to one of the three well-known formats: messageTypeString for kind="string", messageTypeBase64 for kind="base64" and kind="binary", and messageTypeXML for kind="xml" or kind="XML".
<xs:complexType name="messageTypeString">
 <xs:simpleContent>
  <xs:restriction base="messageType">
   <xs:simpleType>
    <xs:restriction base="xs:string"/>
   </xs:simpleType>
  </xs:restriction>
 </xs:simpleContent>
</xs:complexType>

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

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

3.3.3 Constraints on XML Representations of Element Declarations

Schema Representation Constraint: Element Declaration Representation OK
In addition to the conditions imposed on <element> element information items by the schema for schemas documents: all of the following mustmust be true:
1 default and fixed must not both beare not both present.
2 If the item's parent is not <schema>, then all of the following must beare true:
2.1 One of ref or name must beis present, but not both.
2.2 If ref is present, then all of <complexType>, <simpleType>, <key>, <keyref>, <unique>, nillable, default, fixed, form, block and type must be absent, i.e. only minOccurs, maxOccurs, id are allowed in addition to ref, along with <annotation>. no unqualified attributes are present other than minOccurs, maxOccurs, and id, and no children in the Schema namespace (xs) other than <annotation>.
3
type and either <simpleType> or <complexType> are mutually exclusive.
The <element> element does not have both a <simpleType> or <complexType> child and a type attribute.
4
If targetNamespace is present then all of the following must beare true:
4.1 name is present.
4.2 form is not present.
4.3 If the ancestor <schema> does not have a targetNamespace [attribute] or its ·actual value· is different from the ·actual value· of targetNamespace of <element>, then all of the following are true:
4.3.1 <element> has <complexType> as an ancestor
4.3.2 There is a <restriction> ancestor between the <element> and the nearest <complexType> ancestor, and the ·actual value· of the base [attribute] of <restriction> does not ·match· the name of ·xs:anyType·.
5
The corresponding particle and/or element declarations must satisfy the conditions set out in Constraints on Element Declaration Schema Components (§3.3.6) and Constraints on Particle Schema Components (§3.9.6).
6 Every <alternative> element but the last has a test [attribute]; the last <alternative> element may have such an [attribute].

3.3.4 Element Declaration Validation Rules

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

3.3.4.1 Selected and Instance-specified Type Definitions

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

[Definition:]  The selected type definition S of an element information item E is a type definition associated with E in the following way. Let D be the ·governing element declaration· of E. Then:
1 If D has a {type table}, then S is the type ·conditionally selected· for E by D.{type table}.
2 If D has no {type table}, then S is D.{type definition}.
If E has no ·governing element declaration·, then E has no selected type definition.
Note: It is a consequence of Element Declaration Properties Correct (§3.3.6.1) that if D is valid, then S will be ·validly substitutable· for D's declared {type definition}, or else that S will be ·xs:error·.
[Definition:]   Given a Type Table T and an element information item E, T conditionally selects a type S for E in the following way. The {test} expressions in T's {alternatives} are evaluated, in order, until one of the Type Alternatives ·successfully selects· a type definition for E, or until all have been tried without success. If any Type Alternative ·successfully selects· a type definition, none of the following Type Alternatives are tried. Then the type S conditionally selected for E by T is as described in the appropriate case among the following:
1 If at least one Type Alternative in T.{alternatives} ·successfully selects· a type definition for E, then S is the type definition selected by the first such Type Alternative.
[Definition:]  An instance-specified type definition is a type definition associated with an element information item in the following way:
1 Among the element's attribute information items is one named xsi:type.
2 The ·normalized value· of that attribute information item is a qualified name ·valid· with respect to the built-in QName simple type, as defined by String Valid (§3.16.4).
3 The ·actual value· (a ·QName·) ·resolves· to a type definition. It is this type definition which is the instance-specified type definition.
3.3.4.2 Type Override and Valid Substitutability
[Definition:]  An ·instance-specified type definition· S is said to override another type definition T if and only if all of the following are true:
1 S is the ·instance-specified type definition· on some element information item E. A ·governing element declaration· may or may not be known for E.
Note: Typically, T would be the ·governing type definition· for E if it were not overridden. (This will be the case if T was stipulated by the processor, as described in Assessing Schema-Validity (§5.2), or E has a ·governing element declaration· and T is its declared type, or T is the ·locally declared type· of E.)
Note: The use of the term "·override·" to denote the relation between an ·instance-specified type definition· S and another type T has nothing to do with the <override> element; the two mechanisms are distinct and unrelated.
[Definition:]  A type definition S is validly substitutable for another type T, subject to a set of blocking keywords K (typically drawn from the set {substitution, extension, restriction, list, union} used in the {disallowed substitutions} and {prohibited substitutions} of element declarations and type definitions), if and only if either or or

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

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

3.3.4.3 Element Locally Valid (Element)

The concept of local validity of an element information item against an element declaration is an important part of the schema-validity ·assessment· of elements. (The other important part is the recursive ·assessment· of attributes and descendant elements.) Local validity partially determines the element information item's [validity] property, and fully determines the [local element validity] property, in the ·post-schema-validation infoset·.

Informally, an element is locally valid against an element declaration when:
  1. The declaration is present in the schema and the name of the element matches the name of the declaration.
  2. The element is declared concrete (i.e. not abstract).
  3. Any xsi:nil attribute on the element obeys the rules. The element is allowed to have an xsi:nil attribute only if the element is declared nillable, and xsi:nil = 'true' is allowed only if the element itself is empty. If the element declaration specifies a fixed value for the element, xsi:nil='true' will make the element invalid.
  4. Any xsi:type attribute present names a type which is ·validly substitutable· for the element's declared {type definition}.
  5. The element's content satisfies the appropriate constraints: If the element is empty and the declaration specifies a default value, the default is checked against the appropriate type definitions. Otherwise, the content of the element is checked against the ·governing type definition·; additionally, if the element declaration specifies a fixed value, the content is checked against that value.
  6. The element satisfies all the identity constraints specified on the element declaration.
  7. Additionally, on the ·validation root·, document-level ID and IDREF constraints are checked.

The following validation rule gives the normative formal definition of local validity of an element against an element declaration.

Validation Rule: Element Locally Valid (Element)
For an element information item E to be locally ·valid· with respect to an element declaration D all of the following mustmust be true:
1 The declaration D must not beis not ·absent· and E and D have the same expanded name.
2 Its D.{abstract} must be= false.
3
The appropriate case among the following must be true:
3.1 If {nillable} is false, then there must be no attribute information item among the element information item's [attributes] whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is nil.
3.2 If {nillable} is true and there is such an attribute information item and its ·actual value· is true , then all of the following must be true:
3.2.1 The element information item must have no character or element information item [children].
3.2.2 There must be no fixed {value constraint}.
One of the following is true:
3.1 D.{nillable} = false, and E has no xsi:nil attribute.
3.2 D.{nillable} = true and one of the following is true
3.2.1 E has no xsi:nil attribute information item.
3.2.2 E has xsi:nil = false.
3.2.3 E has xsi:nil = true (that is, E is ·nilled·), and all of the following are true:
3.2.3.1 E has no character or element information item [children].
3.2.3.2 D has no {value constraint} with {variety} = fixed.
4
If there is an attribute information item among the element information item's [attributes] whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is type, then all of the following must beare true:
4.1 The ·normalized value· of that attribute information item must be ·valid· with respect to the built-in QName simple type, as defined by String Valid (§3.16.4);
4.2 The ·local name· and ·namespace name· (as defined in QName Interpretation (§3.17.3.1)), of the ·actual value· of that attribute information item must resolve to a type definition, as defined in QName resolution (Instance) (§3.17.6.3)[Definition:]  call this type definition the local type definition;
4.3 The ·local type definition· must be validly derived from the {type definition} given the union of the {disallowed substitutions} and the {type definition}'s {prohibited substitutions}, as defined in Type Derivation OK (Complex) (§3.4.6.6) (if it is a complex type definition), or given {disallowed substitutions} as defined in Type Derivation OK (Simple) (§3.16.6.3) (if it is a simple type definition).
[Definition:]  The phrase actual type definition occurs below. If the above three clauses are satisfied, this should be understood as referring to the ·local type definition·, otherwise to the {type definition}.
5 The appropriate case among the following must beis true:
5.1 If the declaration D has a {value constraint}, and the item E has neither element nor character [children], and clause 3.2 has not appliedE is not ·nilled· with respect to D , then all of the following must beare true:
5.1.1 If theE's ·actual type definition··governing type definition· is a ·local type definition·an ·instance-specified type definition·, then the canonical lexical representation of the D.{value constraint} value must beis a valid default for the ·actual type definition··governing type definition· as defined in Element Default Valid (Immediate) (§3.3.6.4).
5.1.2 The element information item with the canonical lexical representation of the {value constraint} value D.{value constraint}.{lexical form} used as its ·normalized value· must beis locally ·valid· with respect to the ·actual type definition··governing type definition· as defined by Element Locally Valid (Type) (§3.3.4.5).
5.2 If the declarationD has no {value constraint}, or the itemE has either element or character [children], or clause 3.2 has appliedE is ·nilled· with respect to D, then all of the following must beare true:
5.2.1 The element information itemE must beis locally ·valid· with respect to the ·actual type definition··governing type definition· as defined by Element Locally Valid (Type) (§3.3.4.5).
5.2.2 If there is a fixed {value constraint}D.{value constraint}.{variety} = fixed and clause 3.2 has not appliedE is not ·nilled· with respect to D, then all of the following must beare true:
5.2.2.1 The element information itemE must havehas no element information item [children].
5.2.2.2 The appropriate case among the following must beis true:
5.2.2.2.1 If the {content type} of the ·actual type definition· is mixedE's ·governing type definition· is a Complex Type Definition with {content type}.{variety} = mixed , then the ·initial value· of the itemE must matchmatches the canonical lexical representation of the {value constraint} valueD.{value constraint}.{lexical form}.
5.2.2.2.2 If the {content type} of the ·actual type definition· is a simple type definitionE's ·governing type definition· is a Simple Type Definition or a Complex Type Definition with {content type}.{variety} = simple, then the ·actual value· of the itemE must matchis equal or identical to the canonical lexical representation of the {value constraint} value D.{value constraint}.{value}.
6 The element information itemE must beis ·valid· with respect to each of the {identity-constraint definitions} as per Identity-constraint Satisfied (§3.11.4).
7 If the element information itemE is the ·validation root·, then it must beis ·valid· per Validation Root Valid (ID/IDREF) (§3.3.4.6).
Note: If an element has an xsi:type attribute, the type definition indicated by that attribute normally takes precedence over the ·selected type definition· which would otherwise govern the element. If an xsi:type attribute is present and ·resolves· to a known type definition, but fails to ·override· the ·selected type definition·, then E is not locally valid against D, since E has failed to satisfy clause 4. In this case (or if xsi:type fails to ·resolve·), the ·governing type definition· of the element is the ·selected type definition· of its ·governing element declaration·, and the element is validated against that type as described in clause 5. The local validity of the element with respect to the ·governing type definition· is recorded in the [local type validity] property. The use of the ·selected type definition· when the ·instance-specified type definition· cannot be used allows useful validation to proceed in some cases (not all) even when the schema is incomplete. It also helps ensure consistent typing for sub-elements with the same name.
3.3.4.4 Conditional Type Substitutable in Restriction
3.3.4.5 Element Locally Valid (Type)

The following validation rule specifies formally what it means for an element to be locally valid against a type definition. This concept is appealed to in the course of checking an element's local validity against its ·governing type definition·. It is also part of schema-validity ·assessment· of an element when the element is ·laxly assessed·, by checking its local validity against xs:anyType.

Informally, local validity against a type requires first that the type definition be present in the schema and not declared abstract. For a simple type definition, the element must lack attributes (except for namespace declarations and the special attributes in the xsi namespace) and child elements, and must be type-valid against that simple type definition. For a complex type definition, the element must be locally valid against that complex type definition.

Validation Rule: Element Locally Valid (Type)
For an element information item E to be locally ·valid· with respect to a type definition T all of the following mustmust be true:
1 The type definitionT must not beis not ·absent·;
2
It must not have {abstract} with value true.
If T is a complex type definition, then T.{abstract} = false.
3 The appropriate case among the following must beis true:
3.1 If the type definitionT is a simple type definition, then all of the following must beare true:
3.1.1 The element information item's [attributes] must be emptyE.[attributes] is empty, excepting thoseexcept for attributes whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is one of type, nil, schemaLocation or noNamespaceSchemaLocationnamed xsi:type, xsi:nil, xsi:schemaLocation, or xsi:noNamespaceSchemaLocation.
3.1.2 The element information itemE must havehas no element information item [children].
3.1.3 If clause 3.2 of Element Locally Valid (Element) (§3.3.4.3) did not applyE is not ·nilled·, then the ·normalized value··initial value· must beis ·valid· with respect to the type definitionT as defined by String Valid (§3.16.4).
3.2 If the type definitionT is a complex type definition, then the element information itemE must beis locally ·valid· with respect to the type definitionT as per Element Locally Valid (Complex Type) (§3.4.4.2);
4
If the element information item has an xsi:type [attribute] (one whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is type) and does not have a ·governing element declaration·, then the ·actual value· of xsi:type ·resolves· to the type definition.
3.3.4.6 Validation Root Valid (ID/IDREF)

The following validation rule specifies document-level ID/IDREF constraints checked on the ·validation root· if it is an element; this rule is not checked on other elements. Informally, the requirement is that each ID identifies a single element within the ·validation root·, and that each IDREF value matches one ID.

Validation Rule: Validation Root Valid (ID/IDREF)
For an element information item E which is the ·validation root· to be ·valid· all of the following mustmust be true:
1 There must beis no ID/IDREF binding in the item's E.[ID/IDREF table] whose [binding] is the empty set.
2 There must beis no ID/IDREF binding in the item's E.[ID/IDREF table] whose [binding] has more than one member.
See ID/IDREF Table (§3.17.5.2) for the definition of ID/IDREF binding.
Note: The first clause above appliesis violated when there is a reference to an undefined ID. The second appliesis violated when there is a multiply-defined ID. TheyThe cases are separated out to ensure that distinct error codes (see Outcome Tabulations (normative) (§C)) are associated with these two cases.
Note: Since an element governed by type xs:ID provides a unique identifier for the element's parent element, it is not useful to have an element governed by xs:ID when the element has no parent element or when the parent element lies outside the scope of validation.
In the following examples, DOC and Y are governed by type ·xs:anyType·, the element X and the attribute xml:id are governed by xs:ID, and the element Z is governed by a complex type with simple content derived from xs:ID.
  • In the document <DOC><X>abcd</X></DOC>, the ID value 'abcd' will normally be bound to the DOC element. But if the X element is the validation root, then 'abcd' will have no element binding, because DOC is outside the scope of the validation episode. So the first clause is violated and the document is invalid.
  • The superficially similar case <DOC><Y xml:id="abcd"/></DOC> will, in contrast, be valid whether the DOC element or the Y element is the validation root. The ID/IDREF table will have one entry in either case, binding 'abcd' to the Y element.
  • For the document <DOC><Z xml:id="abcd">abcd</Z></DOC>, if Z is the validation root, then the ID/IDREF table for the document will have a single entry for 'abcd' and will be valid. The single binding comes from the xml:id attribute; the content of Z produces no binding, just as the content of X above produces no binding.
    But if DOC is the validation root, then the ID/IDREF table for the document will have two entries for 'abcd' (one, from the xml:id attribute, binding 'abcd' to the Z element, one from the content of Z binding 'abcd' to the DOC element) and will be invalid.
Note: Although this rule applies at the ·validation root·, in practice processors, particularly streaming processors, maywill perhaps wish to detect and signal the clause 2 case as it arises.
Note: This reconstruction of [XML 1.0][XML 1.1]'s ID/IDREF functionality is imperfect in that if the ·validation root· is not the document element of an XML document, the results will not necessarily be the same as those a validating parser would give were the document to have a DTD with equivalent declarations.
3.3.4.7 Schema-Validity Assessment (Element)
This section gives the top-level rule for ·assessment· of an element information item. Informally:
  1. Assessment begins with the identification of a ·governing element declaration· for the element and then checks that the element is locally valid against the declaration; if no ·governing element declaration· is available, a ·governing type definition· can be used instead.
  2. The element's attributes are to be ·assessed· recursively, unless they match a skip wildcard and are thus ·skipped·.
  3. The element's children are to be ·assessed· recursively, unless they match a skip wildcard and are thus ·skipped·. For each child element, the ·governing element declaration· is the one identified in the course of checking the local validity of the parent, unless that declaration is not available. If the ·governing element declaration· is not available, the element may still be ·strictly assessed· if a ·governing type definition· can be identified (e.g. via the xsi:type attribute), otherwise the element will be ·laxly assessed·.
[Definition:]   The governing element declaration of an element information item E, in a given schema-validity ·assessment· episode, is the first of the following which applies:
1 A declaration stipulated by the processor (see Assessing Schema-Validity (§5.2)).
3 A declaration ·resolved· to by E's [local name] and [namespace name], provided that E is ·attributed· either to a strict ·wildcard particle· or to a lax ·wildcard particle·.
4 A declaration ·resolved· to by E's [local name] and [namespace name], provided that none of the following is true:
4.1 E is ·skipped·
4.2 the processor has stipulated a type definition for E
If none of these applies, E has no ·governing element declaration· (or, in equivalent words, E's ·governing element declaration· is ·absent·).
[Definition:]   The governing type definition of an element information item E, in a given schema-validity ·assessment· episode, is the first of the following which applies: If none of these applies, there is no ·governing type definition· (or, in equivalent words, it is ·absent·).
Validation Rule: Schema-Validity Assessment (Element)
The schema-validity assessment of an element information item depends on its ·validation· and the ·assessment· of its element information item children and associated attribute information items, if any.
So for an element information item's schema-validity to be assessed
[Definition:]   all of the following mustmust be true:
1 One of the following must beis true:
1.1All of the following must beare true:
1.1.1A non-·absent· element declaration must be known for it, because one of the following is true
1.1.1.1 A declaration was stipulated by the processor (see Assessing Schema-Validity (§5.2)).
1.1.1.2 A declaration has been established as its ·context-determined declaration·.
1.1.1.3 All of the following must beare true:
1.1.1.3.1 Its ·context-determined declaration· is not skip.
1.1.1.3.2 Its [local name] and [namespace name] resolve to an element declaration as defined by QName resolution (Instance) (§3.17.6.3).
1.1.2 Its ·validity· with respect to that declaration must have been evaluated as per Element Locally Valid (Element) (§3.3.4.3).
1.1.3 If that evaluation involved the evaluation of Element Locally Valid (Type) (§3.3.4.5), clause 1 thereof must be satisfied.
1.2All of the following must beare true:
1.2.1 A non-·absent· type definition is known for it because one of the following is true
1.2.1.1 A type definition was stipulated by the processor (see Assessing Schema-Validity (§5.2)).
1.2.1.2 All of the following must beare true:
1.2.1.2.1 There is an attribute information item among the element information item's [attributes] whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is type.
1.2.1.2.2 The ·normalized value· of that attribute information item is ·valid· with respect to the built-in QName simple type, as defined by String Valid (§3.16.4).
1.2.1.2.3 The ·local name· and ·namespace name· (as defined in QName Interpretation (§3.17.3.1)), of the ·actual value· of that attribute information item resolve to a type definition, as defined in QName resolution (Instance) (§3.17.6.3)call this type definition the local type definition.
1.2.1.2.4 If there is also a processor-stipulated type definition, the ·local type definition· must be validly derived from that type definition given its {prohibited substitutions}, as defined in Type Derivation OK (Complex) (§3.4.6.6) (if it is a complex type definition), or given the empty set, as defined in Type Derivation OK (Simple) (§3.16.6.3) (if it is a simple type definition).
1.2.2The element information item's ·validity· with respect to the ·local type definition· (if present and validly derived) or the processor-stipulated type definition (if no ·local type definition· is present) has been evaluated as per Element Locally Valid (Type) (§3.3.4.5).
2 The schema-validity of all the element information items among its [children] has been assessed as per Schema-Validity Assessment (Element) (§3.3.4.7), and the schema-validity of all the attribute information items among its [attributes] has been assessed as per Schema-Validity Assessment (Attribute) (§3.2.4.3).
[Definition:]  If either case of clause 1 above holds, the element information item has been strictly assessed.
If the item cannot be ·strictly assessed·, because neither clause 1.1 nor clause 1.2 above are satisfied, an element information item's schema validity may be laxly assessed if its ·context-determined declaration· is not skip by ·validating· with respect to the ·ur-type definition· as per Element Locally Valid (Type) (§3.3.4.5).
Note: In general if clause 1.1 above holds clause 1.2 does not, and vice versa. When an xsi:type [attribute] is involved, however, clause 1.2 takes precedence, as is made clear in Element Locally Valid (Element) (§3.3.4.3).
Validation Rule: Schema-Validity Assessment (Element)
The schema-validity assessment of an element information item E is performed as follows:
2 If E is ·skipped·, then E must not be ·assessed·.
3 Otherwise, E must be ·laxly assessed·.
[Definition:]  An element information item E is said to be strictly assessed if and only if all of the following are true:
1 One of the following must beis true:
1.1All of the following must beare true:
1.1.1A non-·absent··non-absent· element declaration must beis known for itE, namely its ·governing· declaration.because
one of the following is true
1.1.1.1 A declaration was stipulated by the processor (see Assessing Schema-Validity (§5.2)).
1.1.1.2 A declaration has been established as its ·context-determined declaration·.
1.1.1.3 All of the following must beare true:
1.1.1.3.1 Its ·context-determined declaration· is not skip.
1.1.1.3.2 Its [local name] and [namespace name] resolve to an element declaration as defined by QName resolution (Instance) (§3.17.6.3).
1.1.2 ItsE's local ·validity· with respect to that declaration must havehas been evaluated as per Element Locally Valid (Element) (§3.3.4.3).
1.1.3 If that evaluation involved the evaluation of Element Locally Valid (Type) (§3.3.4.5), clause 1 thereof must beis satisfied.
1.2All of the following must beare true:
1.2.2 A non-·absent··non-absent· type definition is known for itE, namely its ·governing type definition· because
one of the following is true
1.2.2.1 A type definition was stipulated by the processor (see Assessing Schema-Validity (§5.2)).
1.2.2.2 All of the following must beare true:
1.2.2.2.1 There is an attribute information item among the element information item's [attributes] whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is type.
1.2.2.2.2 The ·normalized value· of that attribute information item is ·valid· with respect to the built-in QName simple type, as defined by String Valid (§3.16.4).
1.2.2.2.3 The ·local name· and ·namespace name· (as defined in QName Interpretation (§3.17.3.1)), of the ·actual value· of that attribute information item resolve to a type definition, as defined in QName resolution (Instance) (§3.17.6.3)call this type definition the local type definition.
1.2.2.2.4 If there is also a processor-stipulated type definition, the ·local type definition· must be validly derived from that type definition given its {prohibited substitutions}, as defined in Type Derivation OK (Complex) (§3.4.6.6) (if it is a complex type definition), or given the empty set, as defined in Type Derivation OK (Simple) (§3.16.6.3) (if it is a simple type definition).
1.2.3The element information item's local ·validity· of E with respect to the ·local type definition· (if present and validly derived) or the processor-stipulated type definition (if no ·local type definition· is present)its ·governing type definition· has been evaluated as per Element Locally Valid (Type) (§3.3.4.5).
For each of the attribute information items among E.[attributes], the appropriate case among the following is true:
2.1 If the attribute has a ·governing attribute declaration· , then its schema-validity is assessed with respect to that declaration, as defined in Schema-Validity Assessment (Attribute) (§3.2.4.3).
2.2 otherwise its schema-validity is not assessed.
For each of the element information items among its [children], the appropriate case among the following is true:
3.1 If the child has a ·governing element declaration· or a ·governing type definition· , then its schema-validity is assessed with respect to that declaration or type definition, as defined in Schema-Validity Assessment (Element) (§3.3.4.7).
3.2 If the child is ·attributed to· a skip Wildcard , then its schema-validity is not assessed.
3.3 otherwise its schema-validity is ·laxly assessed· with respect to ·xs:anyType·.
[Definition:]  The schema validity of an element information item E is said to be laxly assessed if and only if both of the following are true:
2 E is locally ·validated· with respect to ·xs:anyType· as defined in Element Locally Valid (Type) (§3.3.4.5), and the schema-validity of E's [attributes] and [children] is assessed as described in clause 2 and clause 3 of Schema-Validity Assessment (Element) (§3.3.4.7).
Note: It follows from the definitions given that no element information item can be both ·strictly assessed· and ·laxly assessed· in the same schema-validity ·assessment· episode.
Note: The {name} and {target namespace} properties are not mentioned above because they are checked during particle ·validation·, as per Element Sequence Locally Valid (Particle) (§3.9.4.2).

3.3.5 Element Declaration Information Set Contributions

3.3.5.1 Assessment Outcome (Element)
Schema Information Set Contribution: Assessment Outcome (Element)
If and only if the schema-validity of an element information item has been assessed as per Schema-Validity Assessment (Element) (§3.3.4.7), then in the ·post-schema-validation infoset· it has properties as follows:
PSVI Contributions for element information items
[validation context]
The nearest ancestor element information item with a [schema information] property (or this element item itself if it has such a property).
[validity]
The appropriate case among the following:
1 If it was ·strictly assessed·, then the appropriate case among the following:
1.1 If all of the following are true:
1.1.1 One of the following is true:
1.1.1.1 clause 1.1 of Schema-Validity Assessment (Element) (§3.3.4.7) applied and the item was locally ·valid· as defined by Element Locally Valid (Element) (§3.3.4.3);
1.1.1.2 clause 1.2 of Schema-Validity Assessment (Element) (§3.3.4.7) applied and the item was locally ·valid· as defined by Element Locally Valid (Type) (§3.3.4.5).
1.1.2 Neither its [children] nor its [attributes] contains an information item (element or attribute respectively) whose [validity] is invalid.
1.1.3 Neither its [children] nor its [attributes] contains an information item (element or attribute respectively) with a ·context-determined declaration· of mustFindwhich is ·attributed· to a strict ·wildcard particle· and whose [validity] is notKnown.
then valid;
1.2 otherwise invalid.
2 otherwise notKnown.
[validation attempted]
The appropriate case among the following:
1 If it was ·strictly assessed· and neither its [children] nor its [attributes] contains an information item (element or attribute respectively) whose [validation attempted] is not full, then full;
2 If it was not ·strictly assessed· and neither its [children] nor its [attributes] contains an information item (element or attribute respectively) whose [validation attempted] is not none, then none;
3 otherwise partial.
3.3.5.2 Validation Failure (Element)
Schema Information Set Contribution: Validation Failure (Element)
If and only if the local ·validity·, as defined by Element Locally Valid (Element) (§3.3.4.3) above and/or Element Locally Valid (Type) (§3.3.4.5) below, of an element information item has been assessed, then in the ·post-schema-validation infoset· the item has a property:
PSVI Contributions for element information items
[schema error code]
The appropriate case among the following:
1 If the item is not ·valid··invalid·, then a list. Applications wishing to provide information as to the reason(s) for the ·validation· failure are encouraged to record one or more error codes (see Outcome Tabulations (normative) (§C)) herein.
2 otherwise ·absent·.
[subsequence-valid]
The appropriate case among the following:
1 If the element information item is locally ·invalid·, because unexpected attributes or elements were found among its [attributes] and [children] and clause 2 of Element Locally Valid (Complex Type) (§3.4.4.2) would be satisfied, if those unexpected attributes and children (those with [match information] = none) were removed, then true
2 otherwise false
[failed identity constraints]
A list of Identity-Constraint Definitions that are not satisfied by the element information item, as defined by Identity-constraint Satisfied (§3.11.4).
Note: In principle, the value of this property includes all of the Identity-Constraint Definitions which are not satisfied for this element item; in practice, some processors will expose a subset of the items in this value, rather than the full value. For example, a processor could choose not to check further identity constraints after detecting the first failure.
[failed assertions]
A list of Assertions that are not satisfied by the element information item, as defined by Assertion Satisfied (§3.13.4.1).
Note: In principle, the value of this property includes all of the Assertions which are not satisfied by this element item; in practice, some processors will expose a subset of the items in this value, rather than the full value. For example, a processor could choose not to check further assertions after detecting the first failure.
3.3.5.3 Element Declaration
Schema Information Set Contribution: Element Declaration
If and only if a ·governing element declaration· is known for an element information item is ·valid· with respect to an element declaration as per Element Locally Valid (Element) (§3.3.4.3), then in the ·post-schema-validation infoset· the element information item must, at processor option, have eitherhas the properties:
PSVI Contributions for element information items
[element declaration]
an ·item isomorphic· to the declaration component itself
or
PSVI Contributions for element information items
[nil]
true if clause 3.2 of Element Locally Valid (Element) (§3.3.4.3) above is satisfied, otherwise false
PSVI Contributions for element information items
[element declaration]
an ·item isomorphic· to the ·governing· declaration component itself
[nil]
true if clause 3.2.3 of Element Locally Valid (Element) (§3.3.4.3) above is satisfied, otherwise false
[expected element declaration]
if the element information item is ·attributed· to an ·element particle·, then the {term} of that Particle, otherwise ·absent·
Note: The [element declaration] either is the same as or is in the ·substitution group· of the [expected element declaration].
[declared type]
an ·item isomorphic· to the declared {type definition} of the ·governing element declaration·
[local element validity]
The appropriate case among the following:
1 If the item was locally ·valid· as defined by Element Locally Valid (Element) (§3.3.4.3), then valid
2 otherwise (the item was locally ·invalid· as defined by Element Locally Valid (Element) (§3.3.4.3)) invalid.
3.3.5.4 Element Validated by Type
Schema Information Set Contribution: Element Validated by Type
If and only if a ·governing type definition· is known for an element information item is ·valid· with respect to a ·type definition· as per Element Locally Valid (Type) (§3.3.4.5), then in the ·post-schema-validation infoset· the item has a propertythe properties:
PSVI Contributions for element information items
[schema normalized value]
The appropriate case among the following:
1 If clause 3.2 of Element Locally Valid (Element) (§3.3.4.3) and Element Default Value (§3.3.5.5) above have not applied and either the ·type definition· is a simple type definition or its {content type} is a simple type definition, then the ·normalized value· of the item as ·validated·.
2 otherwise ·absent·.
The appropriate case among the following:
1 If the element information item is not ·nilled· and either the ·governing type definition· is a simple type definition or its {content type} has {variety} simple, then the appropriate case among the following:
1.1 If clause 5.1 of Element Locally Valid (Element) (§3.3.4.3) above has applied, then the {lexical form} of the {value constraint}
1.2 If clause 5.1 of Element Locally Valid (Element) (§3.3.4.3) above has not applied and the element's ·initial value· is ·valid· with respect to the simple type definition as defined by String Valid (§3.16.4), then the ·normalized value· of the item as ·validated·
1.3 otherwise ·absent·.
2 otherwise ·absent·.
[schema actual value]
If the [schema normalized value] is not ·absent·, then the corresponding ·actual value· ; otherwise ·absent·.
[type definition type]
simple or complex, depending on the [type definition].
[type definition anonymous]
true if [type definition].{name} is ·absent·, otherwise false.
[type definition name]
If [type definition].{name} is not ·absent·, then [type definition].{name}, otherwise schema processors may, but need not, provide a value unique to the definition. It is ·implementation-defined· whether a processor provides a name for such a type definition. If a processor does provide a value in this situation, the choice of what value to use is ·implementation-dependent·.
[type fallback]
A keyword indicating whether the expected type definition was unavailable and the element had a fallback type as its ·governing type definition·
[local type validity]
The appropriate case among the following:
1 If the element information item was locally ·valid· as defined by Element Locally Valid (Type) (§3.3.4.5), then valid
2 otherwise (the item was locally ·invalid· as defined by Element Locally Valid (Type) (§3.3.4.5)) invalid.
[descendant validity]
The appropriate case among the following:
1 If neither its [children] nor its [attributes] contains an information item I (element or attribute respectively) where either I's [validity] is invalid or I is ·attributed· to a strict ·wildcard particle· and I's [validity] is notKnown , then valid;
2 otherwise invalid.
Furthermore, the item has one of the following alternative sets of properties:
Either
PSVI Contributions for element information items
[type definition]
An ·item isomorphic· to the ·type definition· component itself.
[member type definition]
If and only if that type definition is a simple type definition with {variety} union, or a complex type definition whose {content type} is a simple type definition with {variety} union, then an ·item isomorphic· to that member of the union's {member type definitions} which actually ·validated· the element item's ·normalized value·.
or
PSVI Contributions for element information items
[type definition type]
simple or complex, depending on the ·type definition·.
[type definition namespace]
The {target namespace} of the ·type definition·.
[type definition anonymous]
true if the {name} of the ·type definition· is ·absent·, otherwise false.
[type definition name]
The {name} of the ·type definition·, if it is not ·absent·. If it is ·absent·, schema processors may, but need not, provide a value unique to the definition.
Note: The [type definition type], [type definition namespace], [type definition name], and [type definition anonymous] properties are redundant with the [type definition] property; they are defined for the convenience of implementations which wish to expose those specific properties but not the entire type definition.
Note: When clause 5.1 of Element Locally Valid (Element) (§3.3.4.3) above applies and the default or fixed value constraint {value} is of type QName or NOTATION, it is ·implementation-dependent· whether ·namespace fixup· occurs; if it does not, the prefix used in the lexical representation (in [schema normalized value]) will not necessarily map to the namespace name of the value (in [schema actual value]). To reduce problems and confusion, users may prefer to ensure that the required namespace information item is present in the input infoset.
If the [schema normalized value] is not ·absent· and the ·type definition· ·governing type definition· is a simple type definition with {variety} union, or its {content type} is a simple type definition, and that type definition hashas {variety} simple and {simple type definition} a simple type definition with {variety} union, then calling [Definition:]   that member of the {member type definitions} which actually ·validated· the element item's ·normalized value· the actual member type definition, there are threefour additional properties:
PSVI Contributions for element information items
[member type definition namespace]
The {target namespace} of the ·actual member type definition··validating type·.
[member type definition anonymous]
true if the {name} of the ·actual member type definition··validating type· is ·absent·, otherwise false.
[member type definition name]
The {name} of the ·actual member type definition··validating type·, if it is not ·absent·. If it is ·absent·, schema processors may, but need not, provide a value unique to the definition. It is ·implementation-defined· whether a processor provides a name for such a type definition. If a processor does provide a value in this situation, the choice of what value to use is ·implementation-dependent·.
The first (·item isomorphic·) alternative above is provided for applications such as query processors which need access to the full range of details about an item's ·assessment·, for example the type hierarchy; the second, for lighter-weight processors for whom representing the significant parts of the type hierarchy as information items might be a significant burden.
The [type definition] property is provided for applications such as query processors which need access to the full range of details about an item's ·assessment·, for example the type hierarchy; the [type definition type], [type definition namespace], [type definition name], and [type definition anonymous] properties are defined for the convenience of those specifying lighter-weight interfaces, in which exposing the entire type hierarchy and full component details might be a significant burden.
If all of the following are true:
2 One of the following is true:
2.1 the simple type definition used to validate the ·normalized value· (either the ·governing type definition· or its {simple type definition}) has {variety} = list;
2.2 the simple type definition has {variety} = union and the ·validating type· of the [schema actual value] has {variety} = list;
3 the {item type definition} of the list type (from the previous clause) has {variety} = union;
then there is an additional property:
PSVI Contributions for element information items
[member type definitions]
a sequence of Simple Type Definition components, with the same length as the [schema actual value], each one an ·item isomorphic· to the ·validating type· of the corresponding item in the [schema actual value].
Also, if the declaration has a {value constraint}, the item has a property:
PSVI Contributions for element information items
[schema default]
The canonical lexical representation{lexical form} of the declaration's {value constraint} value.
Note that if an element is ·laxly assessed·, then the [type definition] and [member type definition] properties, or their alternatives, are based on the ·ur-type definition··xs:anyType·.
3.3.5.5 Element Default Value
Schema Information Set Contribution: Element Default Value
If and only if the local ·validity·, as defined by Element Locally Valid (Element) (§3.3.4.3) above, of an element information item has been assessed, in the ·post-schema-validation infoset· the item has a property:
PSVI Contributions for element information items
[schema specified]
The appropriate case among the following:
1 If the item is ·valid· with respect to an element declaration as per Element Locally Valid (Element) (§3.3.4.3) and the {value constraint} is present, but clause 3.2 of Element Locally Valid (Element) (§3.3.4.3) above is not satisfied and the item has no element or character information item [children] clause 5.1 of Element Locally Valid (Element) (§3.3.4.3) above applies, then schema. Furthermore, the ·post-schema-validation infoset· has the canonical lexical representation of the {value constraint} value as the item's [schema normalized value] property.
2 otherwise infoset.

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

3.3.5.6 Inherited Attributes
Schema Information Set Contribution: Inherited Attributes
[Definition:]  An attribute information item A, whether explicitly specified in the input information set or defaulted as described in Attribute Default Value (§3.4.5.1), is potentially inherited by an element information item E if and only if all of the following are true:
1 A is among the [attributes] of one of E's ancestors.
2 A and E have the same [validation context].
3 One of the following is true:
If and only if an element information item P is not ·skipped· (that is, it is either ·strictly· or ·laxly· assessed), in the ·post-schema-validation infoset· each of P's element information item [children] E which is not ·attributed to· a skip Wildcard, has a property:
PSVI Contributions for element information items
[inherited attributes]
A list of attribute information items. An attribute information item A is included if and only if all of the following are true:
2 Let O be A's [owner element]. A does not have the same expanded name as another attribute which is also ·potentially inherited· by E and whose [owner element] is a descendant of O.

3.3.6 Constraints on Element Declaration Schema Components

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

3.3.6.1 Element Declaration Properties Correct
Schema Component Constraint: Element Declaration Properties Correct
For any element declaration E, all of the following mustmust be true:
1 The values of theE's properties of an element declaration. must beare as described in the property tableau in The Element Declaration Schema Component (§3.3.1), modulo the impact of Missing Sub-components (§5.3).
2 If there is aE has a ·non-absent· {value constraint}, the canonical lexical representation of its value must be ·valid·then E.{value constraint} is a valid default with respect to the {type definition}E.{type definition} as defined in Element Default Valid (Immediate) (§3.3.6.4).
3 If there is a non-·absent· {substitution group affiliation}E.{substitution group affiliations} is non-empty, then {scope} must be global E.{scope}.{variety} = global.
4
If there is a {substitution group affiliation}, the {type definition} of the element declaration must be validly derived from the {type definition} of the {substitution group affiliation}, given the value of the {substitution group exclusions} of the {substitution group affiliation}, as defined in Type Derivation OK (Complex) (§3.4.6.6) (if the {type definition} is complex) or as defined in Type Derivation OK (Simple) (§3.16.6.3) (if the {type definition} is simple).
5
If the {type definition} or {type definition}'s {content type} is or is derived from ID then there must not be a {value constraint}.
Note: The use of ID as a type definition for elements goes beyond XML 1.0, and should be avoided if backwards compatibility is desired.
6 Circular substitution groups are disallowed. There are no circular substitution groups. That is, it must not beis not possible to return to an element declarationE by repeatedly following any member of the {substitution group affiliation}{substitution group affiliations} property.
7
If E.{type table} exists, then for each Type Alternative in E.{type table}.{alternatives}, the {test} property is not ·absent·.
8 If E.{type table} exists, then for each {type definition} T in E.{type table}.{alternatives}, and also for E.{type table}.{default type definition}.{type definition}, one of the following is true
8.1 T is ·validly substitutable· for E.{type definition}, subject to the blocking keywords of E.{disallowed substitutions}.
8.2 T is the type ·xs:error·.
3.3.6.2 [Optional XPath subset for CTA]
3.3.6.3 Cartesian Product of Conditional Type Assignments
3.3.6.4 Element Default Valid (Immediate)

The following constraints This and the following sections define relations appealed to elsewhere in this specification.

Schema Component Constraint: Element Default Valid (Immediate)
For a stringValue Constraint V to be a valid default with respect to a type definition T the appropriate case among the following mustmust be true:
1 If the type definitionT is a simple type definition or a complex type definition with {content type}.{variety} = simple , then the string must be ·valid· with respect to that definition as defined by String Valid (§3.16.4).V is a valid default with respect either to T (if T is simple) or (if T is complex) to T.{content type}.{simple type definition} as defined by Simple Default Valid (§3.2.6.2).
2 If the type definitionT is a complex type definition with {content type}.{variety}simple , then all of the following must beare true:
2.1 its {content type} must be a simple type definition or mixedT.{content type}.{variety} = mixed.
2.2
The appropriate case among the following must beis true:
2.2.1 If the {content type} is a simple type definition, then the string must be ·valid· with respect to that simple type definition as defined by String Valid (§3.16.4).
2.2.2 If the {content type} is mixed, then the {content type}'s particle must be ·emptiable· as defined by Particle Emptiable (§3.9.6.14).
3.3.6.5 Substitution Group OK (Transitive)
Schema Component Constraint: Substitution Group OK (Transitive)
For an element declaration (call it DM, for member) to be validly substitutable for another element declaration (call it CH, for head) subject to a blocking constraint (a subset of {substitution, extension, restriction}, the value of a {disallowed substitutions}) at least one of the following mustmust be true:
1 DM and CH are the same element declaration.
2 All of the following must beare true:
2.1 The blocking constraint H. {disallowed substitutions} does not contain substitution.
2.2 There is a chain of {substitution group affiliation}{substitution group affiliations} properties from DM to CH, that is, either DM's .{substitution group affiliation}{substitution group affiliations} iscontains CH, or DM's .{substitution group affiliation}{substitution group affiliations}'s {substitution group affiliations} is contains a declaration whose {substitution group affiliations} contains CH, or . . .
2.3 The set of all {derivation method}s involved in the derivation·derivation· of D's {type definition} from C's {type definition}M.{type definition} from H.{type definition} does not intersect with the union of (1) the blocking constraint,H.{disallowed substitutions}, (2) C's H.{type definition}.{prohibited substitutions} (if CH.{type definition} is complex, otherwise the empty set), and (3) the {prohibited substitutions} (respectively the empty set) of any intermediate declared {type definition}s in the derivation·derivation· of D's {type definition} from C's {type definition}M.{type definition} from H.{type definition}.
3.3.6.6 Substitution Group

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

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

Schema Component Constraint: Substitution Group
[Definition:]  Every element declaration (call this HEAD) in the {element declarations} of a schema defines a substitution group, a subset of those {element declarations}, as follows:
Define P, the potential substitution group for HEAD, as follows:
1 The element declaration itself is in P;
2 P is closed with respect to {substitution group affiliation}, that is, if any element declaration in the {element declarations} has a {substitution group affiliation} in P, then that element is also in P itself.
HEAD's actual ·substitution group· is then the set consisting of each member of P such that all of the following must beare true:
1 Its {abstract} is false.
2 It is validly substitutable for HEAD subject to HEAD's {disallowed substitutions} as the blocking constraint, as defined in Substitution Group OK (Transitive) (§3.3.6.5).

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
            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
        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 Complex Type Definition Actually Restricts
            3.4.6.5 Content Type Restricts (Complex Content)
            3.4.6.6 Type Derivation OK (Complex)
        3.4.7 Built-in Complex Type Definition

Complex Type Definitions provide for:

Example
<xs:complexType name="PurchaseOrderType">
  <xs:sequence>
   <xs:element name="shipTo" type="USAddress"/>
   <xs:element name="billTo" type="USAddress"/>
   <xs:element ref="comment" minOccurs="0"/>
   <xs:element name="items"  type="Items"/>
  </xs:sequence>
  <xs:attribute name="orderDate" type="xs:date"/>
 </xs:complexType>
The XML representation of a complex type definition.

3.4.1 The Complex Type Definition Schema Component

A complex type definition schema component has the following properties:

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

A subset of {extension, restriction}.

{context}
Required if {name} is ·absent·, otherwise must be ·absent·.
{derivation method}
One of {extension, restriction}. Required.
{abstract}
An xs:boolean value. Required.
{attribute uses}
A set of Attribute Use components.
{attribute wildcard}
A Wildcard component. Optional.
{content type }
Required.

One of empty, a simple type definition or a pair consisting of a ·content model· (I.e. a Particle (§2.2.3.2)) and one of mixed, element-only.

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

Complex type definitions are identified by their {name} and {target namespace}. Except for anonymous complex type definitions (those with no {name}), since type definitions (i.e. both simple and complex type definitions taken together) must be uniquely identified within an ·XML Schema··XSD schema·, no complex type definition can have the same name as another simple or complex type definition. Complex type {name}s and {target namespace}s are provided for reference from instances (see xsi:type (§2.7.1)), and for use in the XML representation of schema components (specifically in <element>). See References to schema components across namespaces (<import>) (§4.2.6) for the use of component identifiers when importing one schema into another.

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

As described in Type Definition Hierarchy (§2.2.1.1), each complex type is derived·derived· from a {base type definition} which is itself either a Simple Type Definition (§2.2.1.2) or a Complex Type Definition (§2.2.1.3). {derivation method} specifies the means of derivation·derivation· as either extension or restriction (see Type Definition Hierarchy (§2.2.1.1)).

A complex type with an empty specification for {final} can be used as a {base type definition} for other types derived·derived· by either of extension or restriction; the explicit values extension, and restriction prevent further derivations·derivations· by extension and restriction respectively. If all values are specified, then [Definition:]  the complex type is said to be final, because no further derivations·derivations· are possible. Finality is not inherited, that is, a type definition derived·derived· by restriction from a type definition which is final for extension is not itself, in the absence of any explicit final attribute of its own, final for anything.

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

Complex types for which {abstract} is true must not be used as the {type definition} for the ·validation· of element information itemshave no valid instances and thus cannot be used in the normal way as the {type definition} for the ·validation· of element information items (if for some reason an abstract type is identified as the ·governing type definition· of an element information item, the item will invariably be invalid). It follows that theysuch abstract types must not be referenced from an xsi:type (§2.7.1) attribute in an instance document. Abstract complex types can be used as {base type definition}s, or even as the declared {type definition}s of element declarations, provided in every case a concrete derived·derived· type definition is used for ·validation·, either via xsi:type (§2.7.1) or the operation of a substitution group·substitution group·.

{attribute uses} are a set of attribute uses. See Element Locally Valid (Complex Type) (§3.4.4.2) and Attribute Locally Valid (§3.2.4.1) for details of attribute ·validation·.

{attribute wildcard}s provide a more flexible specification for ·validation· of attributes not explicitly included in {attribute uses}. Informally, the specific values of {attribute wildcard} are interpreted as follows:
  • any: [attributes] can include attributes with any qualified or unqualified name.
  • a set whose members are either namespace names or ·absent·: [attributes] can include any attribute(s) from the specified namespace(s). If ·absent· is included in the set, then any unqualified attributes are (also) allowed.
  • 'not' and a namespace name: [attributes] cannot include attributes from the specified namespace.
  • 'not' and ·absent·: [attributes] cannot include unqualified attributes.
See Element Locally Valid (Complex Type) (§3.4.4.2), The Wildcard Schema Component (§3.10.1) and Wildcard allows Namespace Name (§3.10.4.3)Wildcard allows Expanded Name (§3.10.4.2) for formal details of attribute wildcard ·validation·.
{content type} determines the ·validation· of [children] of element information items. Informally:
Note: Not all combinations of {derivation method} and {content type} are compatible with all properties of the {base type definition}. For example, it is not allowed to derive a complex type with complex content from a simple type. The XML mapping rules specified in the following section (in particular clause 6 of the rule for the {simple type definition} in the rule for {content type} of complex types with simple content, and clause 4.1 and clause 4.2.3 of the rule for {content type} for complex types with complex content) do not detect such incompatible combinations of properties; in such cases the mapping rules will build a complex type regardless of the fact that the properties specified are incompatible. But the resulting complex type does not satisfy component rules outlined in Derivation Valid (Extension) (§3.4.6.2) or Derivation Valid (Restriction, Complex) (§3.4.6.3).

{prohibited substitutions} determine whether an element declaration appearing in a · content model· is prevented from additionally ·validating· element items with an xsi:type (§2.7.1) attribute that identifies a complex type definition derived by extension or restriction from this definition, or element items in a substitution group whose type definition is similarly derived: If {prohibited substitutions} is empty, then all such substitutions are allowed, otherwise, the derivation method(s) it names are disallowed.

The {prohibited substitutions} property of a complex type definition T determines whether type definitions derived from T are or are not ·validly substitutable· for T. Examples include (but are not limited to) the substitution of another type definition: If {prohibited substitutions} is empty, then all such substitutions are allowed; if it contains the keyword restriction, then no type definition is ·validly substitutable· for T if its derivation from T involves any restriction steps; if {prohibited substitutions} contains the keyword extension, then no type definition is ·validly substitutable· for T if its derivation from T involves any extension steps.

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

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

3.4.2 XML Representation of Complex Type 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 simple type definition {content type} with {variety} simple is significantly different from that of those with other {content type}s, and this is reflected in the presentation below, which displays first the elements involved in the first case, then those for the second. The property mapping is shown once for each casedescribes 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 : false

  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: Careful consideration of the above concrete syntax revealsIt 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 onto 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> maymay 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 (among the ancestor element information items there will be a nearest <element>), the Element Declaration corresponding to the nearest <element> information item among the the ancestor element information items.
 
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 annotations corresponding to the <annotation> element information item in the [children], if present, in the <simpleContent> and <complexContent> [children], if present, and in their <restriction> and <extension> [children], if present, otherwise ·absent·. 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 <simpleContent> alternative is chosen<complexType> source declaration has a <simpleContent> child, the following elements are relevant (as are <attribute>, <attributeGroup>, and <anyAttribute>), and the remaining 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 be chosen asappear 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 | length | minLength | maxLength | enumeration | whiteSpace | pattern | assertion | explicitTimezone | {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 type definition ·resolved· to by the ·actual value· of the base [attribute]{base type definition} is a complex type definition whose own {content type} is a simple type definitionhas {variety} simple and the <restriction> alternative is chosen, then starting from either let B be
1.1 the simple type definition corresponding to the <simpleType> among the [children] of <restriction> if there is one;
1.2 otherwise (<restriction> has no <simpleType> among its [children]), the simple type definition which is the {simple type definition} of the {content type} of the type definition ·resolved· to by the ·actual value· of the base [attribute]{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); as follows:
2 If the type definition ·resolved· to by the ·actual value· of the base [attribute]{base type definition} is a complex type definition whose own {content type} ishas {variety} mixed and a particle{particle} a Particle which is ·emptiable·, as defined in Particle Emptiable (§3.9.6.14) and the <restriction> alternative is chosen, then starting from (let SB be the simple type definition corresponding to the <simpleType> among the [children] of <restriction> (which must be present) if any, otherwise ·xs:anySimpleType·) a simple type definition which restricts that simple type definition 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 type definition ·resolved· to by the ·actual value· of the base [attribute]{base type definition} is a complex type definition (whose own {content type} must be a simple type definition has {variety} simple, see below) and the <extension> alternative is chosen, then the {simple type definition} of the {content type} of that complex type definition;
4 otherwise (the type definition ·resolved· to by the ·actual value· of the base [attribute] is a simple type definition and the <extension> alternative is chosen), then that simple type definition.
5 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 <complexContent> alternative is chosen, 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, which are described more fully in XML Representation of Attribute Declaration Schema Components (§3.2.2), Mapping Rule for Attribute Uses Property (§3.4.2.4), and XML Representation of Wildcard Schema Components (§3.10.2), respectively, and which are 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), Mapping Rule for Attribute Wildcard Property (§3.4.2.5), Mapping Rules for Local Attribute Declarations (§3.2.2.2), and Mapping Rules for References to Top-level Attribute Declarations (§3.2.2.3). Note that either <restriction> or <extension> must be chosen asappear 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>.

The property mappings below are also used in the case where the third alternative (neither <simpleContent> nor <complexContent>) is chosen. This case is understood as shorthand for complex content restricting the ·ur-type definition·, and the details of the mappings should be modified as necessary.

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
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.
 
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} of the type definition ·resolved· to by the ·actual value· of the base [attribute], unless the <restriction> alternative is chosen, in which case some members of that type definition's {attribute uses} may not be included, namely those whose {attribute declaration}'s {name} and {target namespace} are the same as one of the following:
3.1 The {name} and {target namespace} of the {attribute declaration} of an attribute use in the set per clause 1 or clause 2 above;
3.2 what would have been the {name} and {target namespace} of the {attribute declaration} of an attribute use in the set per clause 1 above but for the ·actual value· of the use [attribute] of the relevant <attribute> among the [children] of <restriction> being prohibited.
 
As above for the <simpleContent> alternative.
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 9 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 among the [children] a <choice> element 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
one of the following is true
3.1.1 There is no <group>, <all>, <choice> or <sequence> among the [children];
3.1.2 There is an <all> or <sequence> among the [children] with no [children] of its own excluding <annotation>;
3.1.3 There is a <choice> among the [children] with no [children] of its own excluding <annotation> whose minOccurs [attribute] has the ·actual value· 0;
the ·explicit content· is empty then the appropriate case among the following:
3.1.5 If the ·effective mixed· is true, then A particle whose properties are as follows:
A model group whose {compositor} is sequence and whose {particles} is empty.
.
Property
Value
a model group whose {compositor} is sequence and whose {particles} is empty.
3.1.6 otherwise empty
3.2 otherwise the particle corresponding to the <all>, <choice>, <group> or <sequence> among the [children].the ·explicit content·.
4 Then the value of the property is [Definition:]   Let the explicit content type be the appropriate case among the following:
4.1 If the <restriction> alternative is chosen{derivation method} = restriction, then the appropriate case among the following:
4.1.1 If the ·effective content· is empty , then a Content Type as follows:
4.1.2 otherwise a pair consisting ofa Content Type as follows:
4.1.2.1 mixed if the ·effective mixed· is true, otherwise elementOnly
4.2 If the <extension> alternative is chosen{derivation method} = extension, then the appropriate case among the following:
4.2.1 If the ·effective content· is empty, then the {content type} of the type definition ·resolved· to by the ·actual value· of the base [attribute]
4.2.2 If the type definition ·resolved· to by the ·actual value· of the base [attribute] has a {content type} of empty, then a pair as per clause 4.1.2 above;
4.2.3 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.4 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.5 otherwise a pair ofContent Type as follows:
Property
Value
mixed if the ·effective mixed· is true, otherwise or elementOnlyelement-only (determined as per clause 4.1.2.1 above) and a Particle whose properties are as follows:
A model group whose {compositor} is sequence and whose {particles} are the particle of the {content type} of the type definition ·resolved· to by the ·actual value· of the base [attribute] followed by the ·effective content·.
[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.5.1 If the {term} of the ·base particle· has {compositor} all and the ·explicit content· is empty, then the ·base particle·.
4.2.5.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.5.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.2 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.
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].

A Then the value is a union of sets of attribute uses as follows
1 The set of attribute uses corresponding to the <attribute> [children], if any.
2 The {attribute uses} of the attribute groups ·resolved· to by the ·actual value·s of the ref [attribute] of the <attributeGroup> [children], if any.
3
If the type definition ·resolved· to by the ·actual value· of the base [attribute] is a complex type definition, the {attribute uses} of that type definition, unless the <restriction> alternative is chosen, in which case some members of that type definition's {attribute uses} may not be included, namely those whose {attribute declaration}'s {name} and {target namespace} are the same as one of the following:
3.1 the {name} and {target namespace} of the {attribute declaration} of an attribute use in the set per clause 1 or clause 2 above;
3.2 what would have been the {name} and {target namespace} of the {attribute declaration} of an attribute use in the set per clause 1 above but for the ·actual value· of the use [attribute] of the relevant <attribute> among the [children] of <restriction> being prohibited.
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.
Note: This sub-clause handles the case where the base type definition T allows the attribute in question, but the restriction prohibits it.
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.

XML Representation Summary: anyAttribute Element Information Item
<anyAttribute
  id = ID

  namespace = ((##any | ##other) | List of (anyURI | (##targetNamespace | ##local)) )  : ##any

  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>
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 local wildcard be defined as the appropriate case among the following:
1.1 If there is an <anyAttribute> present, then a wildcard based on the ·actual values· of the namespace and processContents [attributes] and the <annotation> [children], exactly as for the wildcard corresponding to an <any> element as set out in XML Representation of Wildcard Schema Components (§3.10.2);
1.2 otherwise ·absent·.
2
[Definition:]  Let the complete wildcard be defined as the appropriate case among the following:
2.1 If there are no <attributeGroup> [children] corresponding to attribute groups with non-·absent· {attribute wildcard}s, then the ·local wildcard·.
2.2 If there are one or more <attributeGroup> [children] corresponding to attribute groups with non-·absent· {attribute wildcard}s, then the appropriate case among the following:
2.2.1 If there is an <anyAttribute> present, then a wildcard whose {process contents} and {annotation} are those of the ·local wildcard·, and whose {namespace constraint} is the intensional intersection of the {namespace constraint} of the ·local wildcard· and of the {namespace constraint}s of all the non-·absent· {attribute wildcard}s of the attribute groups corresponding to the <attributeGroup> [children], as defined in Attribute Wildcard Intersection (§3.10.6.4).
2.2.2 If there is no <anyAttribute> present, then a wildcard whose properties are as follows:
The {process contents} of the first non-·absent· {attribute wildcard} of an attribute group among the attribute groups corresponding to the <attributeGroup> [children].
The intensional intersection of the {namespace constraint}s of all the non-·absent· {attribute wildcard}s of the attribute groups corresponding to the <attributeGroup> [children], as defined in Attribute Wildcard Intersection (§3.10.6.4).
3
[Definition:]  Let the complete wildcard be the Wildcard computed as described in Common Rules for Attribute Wildcards (§3.6.2.2).
4 The value is then determined by the appropriate case among the following:
4.1 If the <restriction> alternative is chosen{derivation method} = restriction, then the ·complete wildcard·;
4.2 If the <extension> alternative is chosen{derivation method} = extension, then
4.2.1 [Definition:]  let the base wildcard be defined as the appropriate case among the following:
4.2.1.1 If the type definition ·resolved· to by the ·actual value· of the base [attribute]{base type definition} is a complex type definition with an {attribute wildcard}, then that {attribute wildcard}.
4.2.1.2 otherwise ·absent·.
4.2.2 The value is then determined by the appropriatefirstcase among the following which applies:
4.2.2.1 If the ·base wildcard· is non-·absent· , then the appropriate case among the following:
4.2.2.1.1 If the ·complete wildcard· is ·absent·, then the ·base wildcard·.
4.2.2.1.2 otherwise a wildcard whose {process contents} and {annotation} are those of the ·complete wildcard·, and whose {namespace constraint} is the intensional union of the {namespace constraint} of the ·complete wildcard· and of the ·base wildcard·, as defined in Attribute Wildcard Union (§3.10.6.3).
4.2.2.2 otherwise (the ·base wildcard· is ·absent·) the ·complete wildcard·
4.2.2.5
a wildcard whose {process contents} and {annotations} are those of the ·complete wildcard·, and whose {namespace constraint} is the above union;
4.2.2.6 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).
Note: Aside from the simple coherence requirements enforced above, constraining type definitions identified as restrictions to actually be restrictions, that is, to ·validate· a subset of the items which are ·validated· by their base type definition, is enforced in Constraints on Complex Type Definition Schema Components (§3.4.6).
3.4.2.6 Examples of Complex Type Definitions
Example
<xs:complexType name="length1">
 <xs:simpleContent>
  <xs:extension base="xs:nonNegativeInteger">
   <xs:attribute name="unit" type="xs:NMTOKEN"/>
  </xs:extension>
 </xs:simpleContent>
</xs:complexType>

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

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

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

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

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

<xs:complexType name="length3">
 <xs:sequence>
  <xs:element name="size" type="xs:nonNegativeInteger"/>
  <xs:element name="unit" type="xs:NMTOKEN"/>
 </xs:sequence>
</xs:complexType>
    
Three approaches to defining a type for length: one with character data content constrained by reference to a built-in datatype, and one attribute, the other two using two elements. length3 is the abbreviated alternative to length2: they correspond to identical type definition components.
Example: 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="personName">
 <xs:sequence>
  <xs:element name="title" minOccurs="0"/>
  <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>
  <xs:element name="surname"/>
 </xs:sequence>
</xs:complexType>

<xs:complexType name="extendedName">
 <xs:complexContent>
  <xs:extension base="personName">
   <xs:sequence>
    <xs:element name="generation" minOccurs="0"/>
   </xs:sequence>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

<xs:element name="addressee" type="extendedName"/>

  <addressee>
   <forename>Albert</forename>
   <forename>Arnold</forename>
   <surname>Gore</surname>
   <generation>Jr</generation>
  </addressee>
A type definition for personal names, and a definition derived·derived· by extension which adds a single element; an element declaration referencing the derived·derived· definition, and a ·valid· instance thereof.
Example
<xs:complexType name="simpleName">
 <xs:complexContent>
  <xs:restriction base="personName">
   <xs:sequence>
    <xs:element name="forename" minOccurs="1" maxOccurs="1"/>
    <xs:element name="surname"/>
   </xs:sequence>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>

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

   <who>
    <forename>Bill</forename>
    <surname>Clinton</surname>
   </who>
A simplified type definition derived·derived· from the base type from the previous example by restriction, eliminating one optional daughterchild 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:numberdecimal"/>
</xs:complexType>
An further illustration of the abbreviated form, with the mixed attribute appearing on complexType itself.
Example
<xs:complexType name="name">
  <xs:openContent>
    <xs:any namespace="##other" processContents="skip"/>
  </xs:openContent>
  <xs:sequence>
    <xs:element name="given" type="xs:string"/>
    <xs:element name="middle" type="xs:string" minOccurs="0"/>
    <xs:element name="family" type="xs:string"/>
  </xs:sequence>
</xs:complexType>
A complex type definition that allows three explicitly declared child elements, in the specified order (but not necessarily adjacent), and furthermore allows additional elements of any name from any namespace other than the target namespace to appear anywhere in the children.
Example
To restrict away a local element declaration that ·competes· with a wildcard, use a wildcard in the derived type that explicitly disallows the element's expanded name. For example:
<xs:complexType name="computer">
 <xs:all>
  <xs:element name="CPU" 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.5)

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 schemas documents, all of the following must be truealso apply :
1
If the <complexContent> alternative is chosen, the type definition ·resolved· to by the ·actual value· of the base [attribute] must be a complex type definition;
2 If the <simpleContent> alternative is chosen, the <complexType> element must not have mixed = true.
all of the following mustmust be true:
2.1 The type definition ·resolved· to by the ·actual value· of the base [attribute] must be one of the following:
2.1.1 a complex type definition whose {content type} is a simple type definition;
2.1.2 only if the <restriction> alternative is also chosen, a complex type definition whose {content type} is mixed and a particle which is ·emptiable·, as defined in Particle Emptiable (§3.9.6.14);
2.1.3 only if the <extension> alternative is also chosen, a simple type definition.
2.2 If clause 2.1.2 above is satisfied, then there must be a <simpleType> among the [children] of <restriction>.
Note: Although not explicitly ruled out either here or in Schema for SchemasSchema Documents (Structures) (normative) (§A), specifying <xs:complexType . . .mixed='true' when the <simpleContent> alternative is chosen has no effect on the corresponding component, and should be avoided. This may be ruled out in a subsequent version of this specification.
3
If <restriction> is present under <simpleContent>, then no facet-specifying element other than xs:enumeration, xs:pattern, or xs:assertion may appear more than once among the [children] of <restriction>.
4
The corresponding complex type definition component must satisfy the conditions set out in Constraints on Complex Type Definition Schema Components (§3.4.6).
5
If clause 3.2.1 or clause 3.2.2 in the correspondence specification above for {attribute wildcard} is satisfied, the intensional intersection must be expressible, as defined in Attribute Wildcard Intersection (§3.10.6.4).
6
If clause 4.2.2.1.2 in the correspondence specification above for {attribute wildcard} is satisfied, the intensional union must be expressible, as defined in Attribute Wildcard Union (§3.10.6.3).
7
If <openContent> is present and has mode'none', then there must be an <any> among the [children] of <openContent>.
8
If <openContent> is present and has mode = 'none', then there must not be an <any> among the [children] of <openContent>.
9
If the <complexContent> alternative is chosen and the mixed [attribute] is present on both <complexType> and <complexContent>, then ·actual values· of those [attributes] must be the same.

3.4.4 Complex Type Definition Validation Rules

3.4.4.1 Locally Declared Type

This section defines the concept of ·locally declared type·; this concept plays a role in determining whether restrictions and extensions of complex type definitions are legitimate. The ·locally declared type· is also used to help determine the ·governing element declaration· and ·governing type definition· of an element information item.

[Definition:]   Every Complex Type Definition determines a partial functional mapping from element or attribute information items (and their expanded names) to type definitions. This mapping serves as a locally declared type for elements and attributes which are allowed by the Complex Type Definition.

The attribute case is simpler and will be taken first.

[Definition:]   For a given Complex Type Definition CTD and a given attribute information item A, the ·locally declared type· of A within CTD is the appropriate case among the following:
1 If CTD is ·xs:anyType· , then ·absent·.
2 If A has the same expanded name as some attribute declaration D which is the {attribute declaration} of some Attribute Use contained by CTD's {attribute uses} , then the {type definition} of D.
3 otherwise the ·locally declared type· of A within CTD.{base type definition}.

The definition for elements is slightly more complex.

[Definition:]   For a given Complex Type Definition CTD and a given element information item E, the ·locally declared type· of E within CTD is the appropriate case among the following:
1 If CTD is ·xs:anyType· , then ·absent·.
2 If E has the same expanded name as some element declaration D which is ·contained· by CTD's content model, whether ·directly·, ·indirectly·, or ·implicitly· , then the declared {type definition} of D.
3 otherwise the ·locally declared type· of E within CTD.{base type definition}.
Note: The constraint Element Declarations Consistent (§3.8.6.3) ensures that even if there is more than one such declaration D, there will be just one type definition.
Note: The reference to ·implicit· containment ensures that if E has a ·governing element declaration· ·substitutable· for a declaration ·contained· by CTD's content model, a ·locally declared type· is defined for E.
3.4.4.2 Element Locally Valid (Complex Type)
Validation Rule: Element Locally Valid (Complex Type)
For an element information item E to be locally ·valid· with respect to a complex type definition T all of the following mustmust be true:
1
{abstract} is false.
2 If clause 3.2 of Element Locally Valid (Element) (§3.3.4.3) did not applyE is not ·nilled·, then
the appropriate case among the following must beis true:
2.1 If the {content type} is empty, then the element information item has no character or element information item [children].
2.2 If the {content type} is a simple type definition, then the element information item has no element information item [children], and the ·normalized value· of the element information item is ·valid· with respect to that simple type definition as defined by String Valid (§3.16.4).
2.3 If the {content type} is element-only, then the element information item has no character information item [children] other than those whose [character code] is defined as a white space in [XML 1.0].
2.4 If the {content type} is element-only or mixed, then the sequence of the element information item's element information item[children], if any, taken in order, is ·valid· with respect to the {content type}'s , as defined in Element Sequence Locally Valid (Particle) (§3.9.4.2).
all of the following must beare true:
2.1 If T.{content type}.{variety} = empty, then E has no character or element information item [children].
2.2 If T.{content type}.{variety} = simple, then E has no element information item [children], and the ·initial value· of E is ·valid· with respect to T.{content type}.{simple type definition} as defined by String Valid (§3.16.4).
2.3 If T.{content type}.{variety} = element-only, then E has no character information item [children] other than those whose [character code] is defined as a white space in [XML 1.1].
2.4 If T.{content type}.{variety} = element-only or T.{content type}.{variety} = mixed, then the sequence of element information items in E.[children], if any, taken in order, is ·valid· with respect to T.{content type}, as defined in Element Sequence Locally Valid (Complex Content) (§3.4.4.3).
3 For each attribute information item A in the element information itemE's .[attributes] excepting those whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is one of type, nil, schemaLocation or noNamespaceSchemaLocationnamed xsi:type, xsi:nil, xsi:schemaLocation, or xsi:noNamespaceSchemaLocation (see Built-in Attribute Declarations (§3.2.7)), the appropriate case among the following must beis true:
3.1 If there is among the {attribute uses} an attribute use U with an {attribute declaration} whose {name} matches the attribute information item's [local name] and whose {target namespace} is identical to the attribute information item's [namespace name] (where an ·absent· {target namespace} is taken to be identical to a [namespace name] with no value)whose {attribute declaration} has the same expanded name as A , then the attribute information itemA must beis locally ·valid· with respect to that attribute useU as per Attribute Locally Valid (Use) (§3.5.4). In this case the {attribute declaration} of that attribute useU.{attribute declaration} is the ·context-determined declaration· for the attribute information itemA with respect to Schema-Validity Assessment (Attribute) (§3.2.4.3) and Assessment Outcome (Attribute) (§3.2.5.1). Also A is ·attributed to· U.
3.2 otherwise all of the following must beare true:
3.2.1 There must beis an {attribute wildcard}.
3.2.2 The attribute information itemA must beis ·valid· with respect to it as defined in Item Valid (Wildcard) (§3.10.4.1).
In this case A is ·attributed to· the {attribute wildcard}.
4
The {attribute declaration} of each attribute use in the {attribute uses} whose {required} is true matches one of the attribute information items in the element information item's [attributes] as per clause 3.1 above.
For each attribute use U in T.{attribute uses}, if U.{required} = true, then U.{attribute declaration} has the same expanded name as one of the attribute information items in E.[attributes].
Note: It is a consequence that (with few exceptions) each such U will have the matching attribute information item ·attributed to· it by clause 3.1 above. The exceptions are uses of xsi:type and the other attributes named in clause 3.1; no ·attribution· is performed for them.
5
Note: When an {attribute wildcard} is present, this does not introduce any ambiguity with respect to how attribute information items for which an attribute use is present amongst the {attribute uses} whose name and target namespace match are ·assessed·. In such cases the attribute use always takes precedence, and the ·assessment· of such items stands or falls entirely on the basis of the attribute use and its {attribute declaration}. This follows from the details of clause 3.
6
Let [Definition:]  the wild IDs be the set of all attribute information item to which clause 3.2 applied and whose ·validation· resulted in a ·context-determined declaration· of mustFind or no ·context-determined declaration· at all, and whose [local name] and [namespace name] resolve (as defined by QName resolution (Instance) (§3.17.6.3)) to an attribute declaration whose {type definition} is or is derived from ID. Then all of the following must beare true:
6.1 There must be no more than one item in ·wild IDs·.
6.2 If ·wild IDs· is non-empty, there must not be any attribute uses among the {attribute uses} whose {attribute declaration}'s {type definition} is or is derived from ID.
Note: This clause serves to ensure that even via attribute wildcards no element has more than one attribute of type ID, and that even when an element legitimately lacks a declared attribute of type ID, a wildcard-validated attribute must not supply it. That is, if an element has a type whose attribute declarations include one of type ID, it either has that attribute or no attribute of type ID.
7
For each element information item in E.[children] and each attribute information item in E.[attributes], if neither the ·governing type definition· nor the ·locally declared type· is ·absent·, then the ·governing type definition· is the same as, or is ·validly substitutable· for, the ·locally declared type·, ·without limitation·.
8
E is ·valid· with respect to each of the assertions in T.{assertions} as per Assertion Satisfied (§3.13.4.1).
9
Note: When an {attribute wildcard} is present, this does not introduce any ambiguity with respect to how attribute information items for which an attribute use is present amongst the {attribute uses} whose name and target namespace match are ·assessed·. In such cases the attribute use always takes precedence, and the ·assessment· of such items stands or falls entirely on the basis of the attribute use and its {attribute declaration}. This follows from the details of clause 3.
[Definition:]  A defaulted attribute belonging to an element information item E ·governed by· a complex type T is any Attribute Use U for which all of the following are true:
1 U is a member of T.{attribute uses}.
2 U.{required} = false.
5 U.{attribute declaration} does not match any of the attribute information items in E.[attributes] as per clause 3.1 of Element Locally Valid (Complex Type) (§3.4.4.2) above.
3.4.4.3 Element Sequence Locally Valid (Complex Content)
Validation Rule: Element Sequence Locally Valid (Complex Content)
For a sequence S (possibly empty) of element information items to be locally ·valid· with respect to a Content Type CT, the appropriate case among the following mustmust be true:
2 If CT.{open content}.{mode} = suffix , then S can be represented as two subsequences S1 and S2 (either can be empty) such that all of the following are true:
2.1 S = S1 + S2
2.2 S1 is ·valid· with respect to CT.{particle}, as defined in Element Sequence Locally Valid (Particle) (§3.9.4.2).
2.3 If S2 is not empty, let E be the first element in S2, then S1 + E does not have a ·path· in CT.{particle}
2.4 Every element in S2 is ·valid· with respect to the wildcard CT.{open content}.{wildcard}, as defined in Item Valid (Wildcard) (§3.10.4.1).
3 otherwise (CT.{open content}.{mode} = interleave) S can be represented as two subsequences S1 and S2 (either can be empty) such that all of the following are true:
3.1 S is a member of S1 × S2 (where × is the interleave operator, see All-groups (§3.8.4.1.3))
3.2 S1 is ·valid· with respect to CT.{particle}, as defined in Element Sequence Locally Valid (Particle) (§3.9.4.2).
3.3 For every element E in S2, let S3 be the longest prefix of S1 where members of S3 are before E in S, then S3 + E does not have a ·path· in CT.{particle}
3.4 Every element in S2 is ·valid· with respect to the wildcard CT.{open content}.{wildcard}, as defined in Item Valid (Wildcard) (§3.10.4.1).

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

3.4.4.4 Attribution

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

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

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

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

3.4.5 Complex Type Definition Information Set Contributions

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