W3C

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

W3C Working Draft 30 August 2007

This version:
http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/
Latest version:
http://www.w3.org/TR/xmlschema11-1/
Previous versions:
http://www.w3.org/TR/2006/WD-xmlschema11-1-20060831/ http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/ http://www.w3.org/TR/2005/WD-xmlschema11-1-20050224/ http://www.w3.org/TR/2004/WD-xmlschema11-1-20040716/
Editors:
Version 1.1:
Shudi (Sandy) Gao 高殊镝, IBM <sandygao@ca.ibm.com>
C. M. Sperberg-McQueen, World Wide Web Consortium <cmsmcq@w3.org>
Henry S. Thompson, University of Edinburgh <ht@inf.ed.ac.uk>
Version 1.0:
Henry S. Thompson, University of Edinburgh <ht@inf.ed.ac.uk>
Noah Mendelsohn, IBM <noah_mendelsohn@us.ibm.com>
David Beech, Oracle Corporation (retired) <davidbeech@earthlink.net>
Murray Maloney, Muzmo Communications <murray@muzmo.com>

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


Abstract

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

Status of this Document

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

This is a Last Call Public Working Draft of XML Schema 1.1W3C XML Schema Definition Language (XSDL) 1.1. It is here made available for review by W3C members and the public. It is intended to give an indication of the W3C XML Schema Working Group's intentions for this new version of the XML Schema language and our progress in achieving them. It attempts to be complete in indicating what will change from version 1.0, but does not specify in all cases how things will change.XSDL 1.1 retains all the essential features of XSDL 1.0, but adds several new features to support functionality requested by users, fixes some errors in XSDL 1.0, and clarifies some wording.

This draft was published on 30 August 2007. The major revisions since the previous draft include:
  • A mechanism for conditional type assignment has been defined; this allows the ·governing type definition· to be assigned by evaluating information in the instance document.
  • Element declarations may now specify multiple substitution group heads.
  • A default attribute group may now be specified at the schema-document level; all complex types defined in the schema document will include that attribute group unless they specify otherwise; this makes it easier to specify that particular attributes are to be accepted by every complex type in a schema.
  • Content models may now be defined as "open", which means that elements other than those explicitly named will be accepted during validation. Several styles and degrees of openness are possible; they can be configured at the level of the schema document or of the complex type definition.
  • Wildcards may now be defined which match only elements not declared in the schema (so-called "not-in-schema" wildcards).
  • Complex types whose content models are all-groups may now be extended. (This change is in addition to other changes in all-groups described in Changes since version 1.0 (§G).)
  • The assertions facility defined in the previous working draft has been revised; the report element has been dropped and the rules for evaluation of XPath expressions have been made more explicit. These changes may help minimize confusion between the assertions defined here and the assert and report elements of Schematron, which can still be used in <appinfo> elements, or separately.
  • Elements may now have more than one attribute of type xs:ID.
  • Various enhancements to the definition of the ·post-schema-validation infoset· have been made. These include the definition of some new properties to support new features (e.g. [type alternative] to support conditional type assignment) and new rules for assigning values to existing properties (the [type definition], for example, is now defined whenever the ·governing type definition· is known, instead of being undefined if the element is invalid).
  • Some aspects of the use of xsi:type have been clarified.
  • A conditional-inclusion mechanism has been defined to allow XSDL 1.1 processors to cope more successfully with constructs defined in future versions of this specification, if any. Schema authors can use this mechanism to define alternative constructs depending on the version of the processor, so that the same schema document can be usable with processors supporting different versions of XSDL.
  • Numerous editorial changes and small bug fixes have been made in the interests of clarity and correctness.

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

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

The Last Call review period for this document extends until 8 November 2007. Comments on this document should be made in W3C's public installation of Bugzilla, specifying "XML Schema" as the product. Instructions can be found at http://www.w3.org/XML/2006/01/public-bugzilla. If access to Bugzilla is not feasible, please send your comments to the W3C XML Schema comments mailing list, www-xml-schema-comments@w3.org (archive) Each Bugzilla entry and email message should contain only one comment.

Although feedback based on any aspect of this specification is welcome, there are certain aspects of the design presented herein for which the Working Group is particularly interested in feedback. These are designated "priority feedback" aspects of the design, and identified as such in editorial notes at appropriate points in this draft. Any feature mentioned in a priority feedback note should be considered a "feature at risk": the feature may be retained as is, modified, or dropped, depending on the feedback received from readers, schema authors, schema users, and implementors.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

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

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

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

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


Table of Contents

1 Introduction
    1.1 Introduction to Version 1.1
    1.2 Purpose
    1.3 Namespaces and Language Identifiers
    1.4 Dependencies on Other Specifications
    1.5 Documentation Conventions and Terminology
2 Conceptual Framework
    2.1 Overview of XML SchemaXSDL
    2.2 XML SchemaXSDL Abstract Data Model
    2.3 Constraints and Validation Rules
    2.4 Conformance
    2.5 Names and Symbol Spaces
    2.6 Schema-Related Markup in Documents Being Validated
    2.7 Representation of Schemas on the World Wide Web
3 Schema Component Details
    3.1 Introduction
    3.2 Attribute Declarations
    3.3 Element Declarations
    3.4 Complex Type Definitions
    3.5 Attribute Uses
    3.6 Attribute Group Definitions
    3.7 Model Group Definitions
    3.8 Model Groups
    3.9 Particles
    3.10 Wildcards
    3.11 Identity-constraint Definitions
    3.12 Type Alternatives
    3.13 Assertions
    3.14 Notation Declarations
    3.15 Annotations
    3.16 Simple Type Definitions
    3.17 Schemas as a Whole
    3.18 Auxiliary Components
4 Schemas and Namespaces: Access and Composition
    4.1 Layer 1: Summary of the Schema-validity Assessment Core
    4.2 Layer 2: Schema Documents, Namespaces and Composition
    4.3 Layer 3: Schema Document Access and Web-interoperability
5 Schemas and Schema-validity Assessment
    5.1 Errors in Schema Construction and Structure
    5.2 Assessing Schema-Validity
    5.3 Missing Sub-components
    5.4 Responsibilities of Schema-aware Processors

Appendices

A Schema for SchemasSchema Documents (Structures) (normative)
B References (normative)
C Outcome Tabulations (normative)
    C.1 Validation Rules
    C.2 Contributions to the post-schema-validation infoset
    C.3 Schema Representation Constraints
    C.4 Schema Component Constraints
D Terminology for implementation-defined features
    D.1 Subset of the Post-schema-validation Infoset
    D.2 Terminology of schema construction
E Required Information Set Items and Properties (normative)
F Checklists of implementation-defined and implementation-dependent features
    F.1 Checklist of implementation-defined features
    F.2 Checklist of implementation-dependent features
G Changes since version 1.0
    G.1 Changes already madesince version 1.0
    G.2 Outstanding issuesIssues not resolved
H Checking content-type restriction
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 XSDL Language Identifiers (non-normative)
O 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 SchemasXSDL, including an introduction to the nature of XML SchemasXSDL schemas and an introduction to the XML SchemaXSDL 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 SchemaXSDL schema for an XML SchemaXSDL document type, along with a detailed mapping between the elements and attribute vocabulary of this representation and the components and properties of the abstract model.

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

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

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

The non-normative appendices include the DTD for Schemas (non-normative) (§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 transfer syntax for schemas itself.
  • Provision of support for co-occurrence constraints, that is constraints which make the presence of an attribute or element, or the values allowable for it, depend on the value or presence of other attributes or elements.

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

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

The aim with regard to compatibility is that

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

previous sub-section next sub-section1.2 Purpose

The purpose of XML SchemaDefinition Language: Structures is to define the nature of !! 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: StructuresXSDL 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 SchemaDefinition 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: StructuresXSDL 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 application applications. 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 XSDL Namespaces
        1.3.2 Conventional Namespace Bindings
        1.3.3 Schema Language Identifiers

1.3.1 XSDL 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: or the prefix xsd: to stand for this namespace; in practice, any prefix can be used.

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

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

1.3.1.2 The Schema Instance Namespace (xsi)

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

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

1.3.1.3 The Schema Versioning Namespace (vc)

The pre-processing of schema documents described in Conditional inclusion (§4.2.1) uses two 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 Conventional Namespace Bindings

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

    Editorial Note: In its current state, the status quo uses both the prefix xs and the prefix xsd for the XSDL namespace. Once the Working Group reaches a decision on the name of the language, the editors expect to bring forward a proposal to unify all uses on a single prefix; which prefix to use will depend on the Working Group's decision.

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

Editorial Note: Loose ends to be tied up: (1) the example with a reference to xsl:quantity lacks any binding for the prefix xsl (and does XSL define a name quantity); (2) We need references (informative?) to the RDDL and XLink specs.

1.3.3 Schema Language Identifiers

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

http://www.w3.org/XML/XMLSchema
Identifies the XML Schema Definition Language in general, without referring to a specific version of it.
http://www.w3.org/XML/XMLSchema/vX.Y
Identifies the language described in version X.Y of the XSDL 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 XSDL version 1.0 and http://www.w3.org/XML/XMLSchema/v1.1 identifies XSDL 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 XSDL specification. For example, http://www.w3.org/XML/XMLSchema/v1.0/2e identifies the second edition of XSDL 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 XSDL 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 XSDL 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 XSDL version 1.0 Second Edition Proposed Edited Recommendation (PER) published on 18 March 2004.

Please see XSDL 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 SchemaDefinition Language: Structures depends on the following specifications: [XML-Infoset], [XML-Namespaces 1.1], [XPath], [XPath 2.0],and [XML Schema: Datatypes].

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

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

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

Note:  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. 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.

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

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

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 following highlighting is used for non-normative commentary in this document:

Note: General comments directed to all readers.

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

may
Conforming documents and XML SchemaXSDL-aware processors are permitted to but need not behave as described.
should
It is recommended that conforming documents and XSDL-aware 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 SchemaXSDL-aware processors are required to behave as described; otherwise they are in error.
must not
Conforming documents and XSDL-aware processors are forbidden to behave as described; if they do they are in error.

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

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

2 Conceptual Framework

This chapter gives an overview of XML SchemaDefinition 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 SchemaXSDL

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

Schema-validity assessment has two aspects:
1 Determining local schema-validity, that is whether an element or attribute information item satisfies the constraints embodied in the relevant components of an XML SchemaXSDL schema;
2 Synthesizing an overall validation outcome for the item, combining local schema-validity with the results of schema-validity assessments of its descendants, if any, and adding appropriate augmentations to the infoset to record this outcome.

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

Throughout this specification, [Definition:]   the word assessment is used to refer to the overall process of local validation, schema-validity assessment and infoset augmentation.

During ·assessment·, some or all of the element and attribute information items in the input document are associated with declarations and/or type definitions; these declarations and type definitions are then used in the ·assessment· of those items, in a recursive process. [Definition:]  The declaration associated with an information item, if any, and with respect to which its validity is ·assessed· in a given assessment episode is said to govern the item, or to be its governing element or attribute declaration. Similarly the type definition with respect to which the type-validity of an item is assessed is its governing type definition.

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

        2.2.1 Type Definition Components
        2.2.2 Declaration Components
        2.2.3 Model Group Components
        2.2.4 Identity-constraint DefinitionConstraint Components
        2.2.5 Group Definition Components
        2.2.6 Annotation Components

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

Just as [XML 1.1] and [XML-Namespaces 1.1] can be described in terms of information items, XML SchemasXSDL 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 SchemaXSDL 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 XSDL schema is a set of ·schema components·. There are 1314 kinds of component in all, falling into three groups. The primary 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 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" components provide small parts of other components; they are not independent of their context:

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

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

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

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

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

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

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

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

2.2.1 Type Definition Components

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

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

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

2.2.1.1 Type Definition Hierarchy

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

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

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

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

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

[Definition:]  A special complex type definition, (referred to in earlier versions of this specification as 'the ur-type definition') whose name is anyType in the XSDL namespace, is present in each ·XSDL 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 XSDL namespace, is also present in each ·XSDL schema·. The XSDL 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 xsd:anyType and xsd:error for these type definitions. (In practice, any appropriately declared prefix can be used, as described in Schema-Related Markup in Documents Being Validated (§2.6).)

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

2.2.1.2 Simple Type Definition

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

Each simple type definition, whether built-in (that is, defined in [XML Schema: Datatypes]) or user-defined, is a ·restriction· of some particular simpleits ·base type definition·. For the built-in primitive type definitions, this is[Definition:]  theThe simple ur-type definition, a special ·restriction· of the ·ur-type definition··xs:anyType·, whose name is anySimpleType in the XML Schema namespaceis the root of the ·Type Definition Hierarchy· for the simple type definitions. 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. The built-in list datatypes all have the ·simple ur-type definition· as their ·base type definition·.

[Definition:]  There is a further special datatype called anyAtomicType, a ·restriction· of the ·simple ur-type definition·, which is the ·base type definition· of all the primitive built-in datatypes. It too is considered to have an unconstrained lexical space. Its value space consists of the union of the value spaces of all the built-in primitive datatypes.

The mapping from lexical space to value space is unspecified for items whose type definition is the ·simple ur-type definition· or ·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· , 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· one of the built-in primitive or ordinary datatypes. 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·.

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 base type. A 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. 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).

2.2.2.2 Element Substitution Group

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

[Definition:]  Through the new mechanism of element substitution groups, XML SchemasXSDL provides a more powerful model 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 of 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 to 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 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 Gis 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: StructuresXSDL ·content models· are similar to but more expressive than [XML 1.1] content models; unlike [XML 1.1], XML Schema: StructuresXSDL 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, 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).

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

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: 
Note:  In version 1.0 of this specification, 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).

Editorial Note: Priority Feedback Request

Assertions are currently only allowed to be specified in complex types. It may be deemed useful also to include assertions in named model group definitions and/or attribute groups, or even simple types. The XML Schema Working Group solicits input from implementors and users of this specification on this question.

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.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. 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). 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. 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·. 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. XML1.0 validation augments the XML1.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 XML1.0 leftleaves implicit.

previous sub-section next sub-section2.4 Conformance

Note: The Working Group expects to revise this discussion of conformance in future. A sketch of relevant work can be found in Checklist of implementation-defined features (§F.1) and Terminology for implementation-defined features (§D).

Within the context of this specification, conformance can be claimed for schema documents and for XSDL-aware 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 schema specified in Schema for SchemasSchema Documents (Structures) (normative) (§A). (That is, 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).
Note: While conformance of schema documents is a precondition for the mapping from schema documents to schema components described in this specification, conformance of the schema documents does not guarantee that the result of that mapping will be a schema that conforms to this specification. Some constraints (e.g. the rule that there must be at most one top-level element declaration with a particular expanded name) can only be checked in the context of the schema as a whole.
Note:  Some Schema Representation Constraints cannot, in their current formulation, be checked against the schema document in isolation, but only in the context of the schema as a whole. It is a consequence that in some cases, the conformance of a schema document cannot be determined in isolation.

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 Schemasbe schema-document aware. Such processors must, when processing schema documents, completely and correctly implement (or enforce) 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·.

Note: The ·Schema Representation Constraints· are to be enforced after, not before, the conditional-inclusion pre-processing described in Conditional inclusion (§4.2.1).

[Definition:]  A ·minimally conforming· processor which is not ·schema-document aware· is said to be a non-schema-document-aware 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 be ·minimally conforming· but not necessarily in ·conformance to the XML Representation of Schemas··schema-document aware·.

[Definition:]  Fully conformingWeb-aware processors are network-enabled processors which are not only both ·minimally conforming· and ·in conformance to the XML Representation of Schemasschema-document aware·, 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.7) and How schema definitions are located on the Web (§4.3.2). .

Note: In version 1.0 of this specification the class of ·schema-document aware· processors was termed "conformant to the XML Representation of Schemas". Similarly, the class of ·Web-aware· processors was called "fully conforming".
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.

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

As discussed in XML SchemaXSDL 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 [XML-Namespaces 1.1]. There is a single distinct symbol space within a given ·target namespace· for each kind of definition and declaration component identified in XML SchemaXSDL 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.

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. 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.6 Schema-Related Markup in Documents Being Validated

        2.6.1 xsi:type
        2.6.2 xsi:nil
        2.6.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.

Note: 
Note: 

XML SchemaDefinition 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 have appropriate attribute declarations for these attributes built in, see Attribute Declaration for the 'type' attribute (§3.2.7), Attribute Declaration for the 'nil' attribute (§3.2.7), Attribute Declaration for the 'schemaLocation' attribute (§3.2.7) and Attribute Declaration for the 'noNamespaceSchemaLocation' attribute (§3.2.7).

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.6.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) for the means by which the ·QName· is associated with a type definition.

2.6.2 xsi:nil

XML SchemaDefinition 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.6.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.

previous sub-section 2.7 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.2)), 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. ·post-schema-validation infoset· contributions
  6. 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 interpreting as constraining implementations, as for instance between using a null value for such properties or not representing them at all.

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 may 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 may 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.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 SchemaDefinition 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 SchemaXSDL 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 SchemaXSDL 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.

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.1).

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 implicit in the Schema for SchemasSchema Documents (Structures) (normative) (§A).

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·. 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 ·validated·.

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 all ·validation· purposes.

[Definition:]  The normalized value of an element or attribute information item is an ·initial value· whose white space, if any, has been normalized according to the value of the whiteSpace facet of the simple type definition used in its ·validation·:
preserve
No normalization is done, the value is the ·normalized 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.

If the simple type definition used in an item's ·validation· is the ·simple ur-type definition·, thenthe ·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) (clause 3), Element Locally Valid (Type) (§3.3.4) (clause 3.1.3) or Element Locally Valid (Complex Type) (§3.4.4) (clause 2.2).

These three levels of normalization correspond to the processing mandated in XML1.0 for element content, CDATA attribute content and tokenized attributed content, respectively. See Attribute Value Normalization in [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

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.
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 attribute 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} ofwith {variety} 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 definitionComplex Type Definition or Attribute Group Definition identified by the {scope}'s {parent} 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.

{value constraint} reproduces the functions of XML1.0 default and #FIXED attribute values. A {variety} ofdefault 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 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/orchecked, not strings.

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

[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). 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:

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

Editorial Note: Priority Feedback Request

Earlier versions of this specification did not allow a targetNamespace attribute on attribute declarations; it has been added in this version to make restriction of complex types easier. The XML Schema Working Group has designated the targetNamespace attribute a ‘feature at risk’: it may be dropped from future drafts of this specification if implementation or usage experience shows that its costs outweigh its benefits. The XML Schema Working Group solicits input from implementors and users of this specification as to whether the addition of this attribute is desirable and acceptable.

If the <attribute> element information item has <schema> as its parent, the corresponding schema component is as follows:
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·.
 
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 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).
otherwise if the <attribute> element information item has <complexType> or <attributeGroup> as an ancestor and the ref [attribute] is absent, it corresponds to an attribute use with properties as follows (unless use='prohibited', in which case the item corresponds to nothing at all):
Attribute Use Schema Component
Property
Representation
 
true if the use [attribute] is present with ·actual value· required, otherwise false.
 
See the Attribute Declaration mapping immediately below.
 
If there is a default or a fixed [attribute], then a pair consisting ofValue 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]
 
The same annotations as the {annotations} of the Attribute Declaration. See below.
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 is present and its ·actual value· is qualified
2.2 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 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·.
 
A Scope as follows:
Property
Value
local
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 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).
otherwise (the <attribute> element information item has <complexType> or <attributeGroup> as an ancestor and the ref [attribute] is present), it corresponds to an attribute use with properties as follows (unless use='prohibited', in which case the item corresponds to nothing at all):
Attribute Use Schema Component
Property
Representation
 
true if the use [attribute] is present with ·actual value· 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 ofValue 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]

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.

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

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.

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 schemasdocuments, 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 type and <simpleType> must not both be present.
5
If fixed and use are both present, use must not have the ·actual value· prohibited.
6
If targetNamespace is present then all of the following mustmust be true:
6.1 name is present.
6.2 form is not present.
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 Let B be the {base type definition} of the Complex Type Definition corresponding to <complexType>. B's {attribute uses} contains an Attribute Use whose {attribute declaration} has the same {name} and {target namespace} as those of the Attribute Declaration corresponding to this <attribute>.
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

Validation Rule: Attribute Locally Valid
For an attribute information item to be locally ·valid· with respect to an attribute declaration all of the following mustmust be true:
1 The declaration must not beis not ·absent· (see Missing Sub-components (§5.3) for how this can fail to be the case).
2 Its {type definition} must not beis not absent.
3 The item's ·normalized value· must beis locally ·valid· with respect to that {type definition} as per String Valid (§3.16.4).
4 The item's ·actual value· must matchmatches the value{value} of the {value constraint}, if it is present and its {variety} isfixed.
5
If the declaration is the built-in declaration for xsi:type (Attribute Declaration for the 'type' attribute (§3.2.7)), then the item's ·actual value· ·resolves· to a 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 ·attributed· to a skip ·wildcard particle· and the processor has not stipulated a type definition at the start of ·assessment·.
If the attribute is ·attributed· to a skip ·wildcard particle· or if the processor has stipulated a type definition, then it has no ·governing· declaration.

[Definition:]   The governing type definition of an attribute, in a given schema-validity ·assessment· episode, is the {type definition} of the ·governing attribute declaration·, unless the processor has stipulated another type definition at the start of ·assessment· (see Assessing Schema-Validity (§5.2)), in which case it is the stipulated type definition.

Validation Rule: Schema-Validity Assessment (Attribute)
The schema-validity assessment of an attribute information item depends on its ·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)) 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.4), provided its ·context-determined declaration· is not skip.
2 Its ·validity· with respect to that declaration must havehas been evaluated as per Attribute Locally Valid (§3.2.4).
3 Both clause 1 and clause 2 of Attribute Locally Valid (§3.2.4) must beare satisfied.
[Definition:]  For attributes, there is no difference between assessment and strict assessment, so if the above holds, the attribute information item has been strictly assessedif and only if its schema-validity has been assessed.

3.2.5 Attribute Declaration Information Set Contributions

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), 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 ·valid· as defined by Attribute Locally Valid (§3.2.4), 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) for the other possible value.
Schema Information Set Contribution: Validation Failure (Attribute)
Ifand only if the local ·validity·, as defined by Attribute Locally Valid (§3.2.4) 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·.
Schema Information Set Contribution: Attribute Declaration
If and only if a ·governing· declaration is known for an attribute information itemis ·valid· with respect to an attribute declaration as per Attribute Locally Valid (§3.2.4) 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}.
Schema Information Set Contribution: Attribute Validated by Type
If clause 3 of Attribute Locally Valid (§3.2.4) 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· 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 which uniquely identifies this type definition among those with the same target namespace.
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 ·normalized value· is ·valid· with respect to the ·governing type definition· as defined by String Valid (§3.16.4) and the ·governing type definition· has {variety} union, then calling [Definition:]   that member of the {member type definitions} basic member of its transitive membership 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·.
[member type definition anonymous]
true if the {name} of the ·actual member type definition· is ·absent·, otherwise false.
[member type definition name]
The {name} of the ·actual member type definition·, 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 basic member which actually ·validated· the corresponding space-delimited substring in the [schema normalized 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
3 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), Match Information (§3.4.5) and Schema Information (§3.17.5), 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.

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).
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.
Schema Component Constraint: Simple Default Valid
For a Value Constraint to be a valid default with respect to a Simple Type Definition all of the following must beare true:
1 the Value Constraint's {lexical form} is ·valid· with respect to that Simple Type Definition as defined by Datatype Valid in [XML Schema: Datatypes].
2 the Value Constraint's {lexical form} maps to its {value} in that Simple Type Definition's value space.
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:*.
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 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 not illegal 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 <xsd:attribute ref="xsi:type" default="xsd: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) and Attribute Default Value (§3.4.5) for details.

3.2.7 Built-in Attribute Declarations

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

Property
Value
type
http://www.w3.org/2001/XMLSchema-instance
The built-in QName simple type definition
A Scope as follows:
Property
Value
global
Property
Value
nil
http://www.w3.org/2001/XMLSchema-instance
The built-in boolean simple type definition
A Scope as follows:
Property
Value
global
Property
Value
schemaLocation
http://www.w3.org/2001/XMLSchema-instance
An anonymous simple type definition, as follows:
A Scope as follows:
Property
Value
global
Property
Value
noNamespaceSchemaLocation
http://www.w3.org/2001/XMLSchema-instance
The built-in anyURI simple type definition
A Scope as follows:
Property
Value
global

previous sub-section next sub-section3.3 Element Declarations

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: Element Declaration, 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 }
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.
{nillable}
An xs:boolean value. Required.
{identity-constraint definitions}
A set of Identity-Constraint Definition components.
{substitution group affiliation}
An Element Declaration component. Optional.
{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, list, union}.
{disallowed substitutions}

A subset of {substitution, extension, restriction}.

{abstract}
An xs:boolean value. Required.
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} ofwith {variety} global identifies element declarations available for use in content models throughout the schema. Locally scoped declarations are available for use only within the complex typeComplex Type Definition or Model Group Definition identified by the {scope}'s {parent} property. This property is ·absent· in the case of declarations within named model groups: their scope will be determined when they are used in the construction of complex type definitions.

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.6.1)) can cause the ·governing type definition· and the declared {type definition} to be different.

If {nillable} is true, then an element 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.6.2)) even if it has no text or element content despite a {content type} which would otherwise require content. Formal details of element ·validation· are described in Element Locally Valid (Element) (§3.3.4).

{value constraint} establishes a default or fixed value for an element. If a {value constraint} with a {variety} ofdefault 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·. the element is treated as if the {value constraint}'s {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 identical to the supplied constraint value{value constraint}'s {value}.

Note: The provision of defaults for elements goes beyond what is possible in XML1.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·substitution groups·, if any, identified by {substitution group affiliation}{substitution group affiliations}. Potential membership is transitive but not symmetric; an element declaration is a potential member 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 therefrom. The explicit values of {substitution group exclusions} rule out element declarations having types which are extensions or restrictions respectively of {type definition}. If both values are specified, then the declaration must 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.6.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 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 {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:

XML Representation Summary: element Element Information Item

<element
  abstract = boolean : false
  block = (#all | List of (extension | restriction | substitution))
  default = string
  final = (#all | List of (extension | restriction))
  fixed = string
  form = (qualified | unqualified)
  id = ID
  maxOccurs = (nonNegativeInteger | unbounded)  : 1
  minOccurs = nonNegativeInteger : 1
  name = NCName
  nillable = boolean : false
  ref = QName
  substitutionGroup = List of QName
  targetNamespace = anyURI
  type = QName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, ((simpleType | complexType)?, alternative*, (unique | key | keyref)*))
</element>

Editorial Note: Priority Feedback Request

Earlier versions of this specification did not allow a targetNamespace attribute on element declarations; it has been added in this version to make restriction of complex types easier. The XML Schema Working Group has designated the targetNamespace attribute a ‘feature at risk’: it may be dropped from future drafts of this specification if implementation or usage experience shows that its costs outweigh its benefits. The XML Schema Working Group solicits input from implementors and users of this specification as to whether the addition of this attribute is desirable and acceptable.

If the <element> element information item has <schema> as its parent, the corresponding schema component is as follows:
Element Declaration Schema Component
Property
Representation
 
The ·actual value· of the name [attribute].
 
The ·actual value· of the targetNamespace [attribute] of the parent <schema> element information item, or ·absent· if there is none.
 
A Scope as follows
Property
Value
global
 
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]; 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 ofa 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 the declared {type definition}'s {content type} has {variety} simple, that {content type}'s {simple type definition}, or else the built-in string simple type definition).
Property
Value
either default or fixed, as appropriate
the ·actual value· (with respect to the ·effective simple type definition·) of thatthe [attribute]
 
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·. The ·annotation mapping· of the <element> element, as defined in XML Representation of Annotation Schema Components (§3.15.2).
otherwise if the <element> element information item has <complexType> or <group> as an ancestor and the ref [attribute] is absent, the corresponding schema components are as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all):
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 Element Declaration. See below.
An element declaration as in the first case above, with the exception of its {target namespace} and {scope} properties, which are as below:
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 is present and its ·actual value· is qualified
2.2 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 ancestor <schema> element information item, or ·absent· if there is none.
3 otherwise ·absent·.
 
A Scope as follows:
Property
Value
local
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> definitionelement information item), ·absent·the Model Group Definition corresponding to that item.
otherwise (the <element> element information item has <complexType> or <group> as an ancestor and the ref [attribute] is present), the corresponding schema component is as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all):
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].

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

<element>s within <schema> 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 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 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.

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

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 XML1.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:
<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: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 schemasdocuments: 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 beare absent, i.e. only minOccurs, maxOccurs, id and <annotation> are allowed in addition toto appear together with ref, along with <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 Let B be the {base type definition} of the Complex Type Definition corresponding to <complexType>. B's ·content model· contains, either directly, indirectly (that is, within the {particles} of a contained model group, recursively) or ·implicitly contains· an Element Declaration whose {name} and {target namespace} are the same as those of the Element Declaration corresponding to this <element>.
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
7 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·.

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 the {type table} of D.
2 If D has no {type table}, then S is the declared {type definition} of D.
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) that if D is valid, then S will be ·validly substitutable· for D's declared {type definition}, or else that S will be ·xsd: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's {alternatives} ·successfully selects· a type definition for E, then S is the type definition selected by the first such Type Alternative.
2 If no Type Alternative in T's {alternatives} ·successfully selects· a type definition, then S is the {type definition} of the {default type definition} of T.
[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, that is an [attribute] whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is 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). (Note: it follows then that the attribute's ·actual value· can be interpreted as denoting a ·local name· and a ·namespace name·, as described in QName Interpretation (§3.17.3).)
3 The ·local name· and a ·namespace name· ·resolve· to a type definition. It is this type definition which is the instance-specified type definition.
[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.
  2. S is ·validly substitutable· for T, subject to the blocking keywords of the {disallowed substitutions} of E's ·governing element declaration·, if any, or ·validly substitutable without limitation· for T (if no ·governing element declaration· is known).
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 ·context-determined type· of E.)
[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}.

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·.
2 Its {abstract} must beis 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 {nillable} is false, and there is 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 {nillable} is true and one of the following is true
3.2.1 There is no such attribute information item.
3.2.2 There is such an attribute information item, and its ·actual value· is false.
3.2.3 There is such an attribute information item, and its ·actual value· is true, and all of the following are true:
3.2.3.1 The element information item has no character or element information item [children].
3.2.3.2 There is 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)), of the ·actual value· of that attribute information item must resolve to a type definition, as defined in QName resolution (Instance) (§3.17.4)[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) (if it is a complex type definition), or given {disallowed substitutions} as defined in Type Derivation OK (Simple) (§3.16.6) (if it is a simple type definition).
[Definition:]  The phrase actual type definition occurs below. If the above three clauses are satisfied, this must be understood as referring to the ·local type definition·, otherwise to the {type definition}.
If there is an attribute information item named xsi:type among the [attributes] of E (i.e. one 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 E has an ·instance-specified type definition· which is not absent.
That is, the ·instance-specified type definition· ·overrides· the ·selected 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 applied, then all of the following must beare true:
5.1.1 If the ·actual type definition··governing type definition· is a ·local type definition·an ·instance-specified type definition·, then the canonical lexical representation ofdeclaration's {value constraint}value.'s {value} must beis a valid default for the ·actual type definition··governing type definition· as defined in Element Default Valid (Immediate) (§3.3.6).
5.1.2 The element information item with the canonical lexical representation of{lexical form} of thedeclaration's {value constraint}value.'s {value} used as its ·normalized value· must beis ·valid· with respect to the ·actual type definition··governing type definition· as defined by Element Locally Valid (Type) (§3.3.4).
5.2 If the declaration has no {value constraint}, or the item has either element or character [children], or clause 3.2 has applied, then all of the following must beare true:
5.2.1 The element information item must beis ·valid· with respect to the ·actual type definition··governing type definition· as defined by Element Locally Valid (Type) (§3.3.4).
5.2.2 If there is a fixed{value constraint}with {variety} fixed and clause 3.2 has not applied, then all of the following must beare true:
5.2.2.1 The element information item 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··governing type definition· is a Complex Type Definition whose {content type}ishas {variety} mixed, then the ·initial value· of the item must matchmatches the canonical lexical representation of{lexical form} of thedeclaration's {value constraint}value.'s {value}.
5.2.2.2.2 If the {content type} of the·actual type definition··governing type definition· is a Simple Type Definition or a Complex Type Definition whose {content type}is a simple type definitionhas {variety} simple, then the ·actual value· of the item must match↓↓is identical to thecanonical lexical representation of the {value constraint}value's {value}.
6 The element information item 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 item is the ·validation root·, then it must beis ·valid· per Validation Root Valid (ID/IDREF) (§3.3.4).
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).
Note: If an element has an xsi:type attribute whose value does not ·resolve· to a type definition, or if the type definition fails to ·override· the ·selected type definition·, then the ·selected type definition· of its ·governing element declaration· becomes the ·governing type definition·. The local validity of the element with respect to the ·governing type definition· is recorded in the [local type validity] property.
Validation Rule: Element Locally Valid (Type)
For an element information item to be locally ·valid· with respect to a type definition all of the following mustmust be true:
1 The type definition must not beis not ·absent·;
2 It must notdoes not have {abstract} with value true.
3 The appropriate case among the following must beis true:
3.1 If the type definition is a simple type definition, then all of the following must beare true:
3.1.1 The element information item's [attributes] must beare empty, 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 noNamespaceSchemaLocation.
3.1.2 The element information item must havehas no element information item [children].
3.1.3 If clause 3.2 of Element Locally Valid (Element) (§3.3.4) did not apply, then the ·normalized value· must beis ·valid· with respect to the type definition as defined by String Valid (§3.16.4).
3.2 If the type definition is a complex type definition, then the element information item must beis ·valid· with respect to the type definition as per Element Locally Valid (Complex Type) (§3.4.4);
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.
Note: Informally, this rule means that an element with an xsi:type attribute cannot be locally valid with respect to any type other than that named in the attribute.
Note:  This rule only covers the case when a ·governing element declaration· is not available. When a ·governing element declaration· is present, the same rule is checked in clause 4 of Element Locally Valid (Element) (§3.3.4).
Validation Rule: Validation Root Valid (ID/IDREF)
For an element information item 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 [ID/IDREF table] whose [binding] is the empty set.
2 There must beis no ID/IDREF binding in the item's [ID/IDREF table] whose [binding] has more than one member.
See ID/IDREF Table (§3.17.5) for the definition of ID/IDREF binding.
Note: The first clause above applies when there is a reference to an undefined ID. The second applies when there is a multiply-defined ID. They are separated out to ensure that distinct error codes (see Outcome Tabulations (normative) (§C)) are associated with these two cases.
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.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.
[Definition:]   The governing element declaration of an element information item, 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 its [local name] and [namespace name], provided that none of the following is true:
  1. it is ·attributed· to a skip ·wildcard particle·
  2. the processor has stipulated a type definition for it
  3. a ·non-absent· ·context-determined type· exists for it
If none of these apply, there is no ·governing element declaration· (or, in equivalent words, it is ·absent·).
[Definition:]   The governing type definition of an element information item, in a given schema-validity ·assessment· episode, is the first of the following which applies:
1 An ·instance-specified type definition· which ·overrides· a type definition stipulated by the processor (see Assessing Schema-Validity (§5.2)).
2 A type definition stipulated by the processor (see Assessing Schema-Validity (§5.2)).
4 The ·selected type definition· of the element information item.
5 The value ·absent· if the element information item is ·skipped·.
If none of these apply, 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:]   For an element information item's schema-validity to be strictly assessed all of the following mustmust be true:
1 One of the following must beis true:
1.1 All of the following must beare true:
1.1.1 A non-·absent··non-absent· element declaration must beis known for it, 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.4).
1.1.2 Its ·validity· with respect to that declaration must havehas been evaluated as per Element Locally Valid (Element) (§3.3.4).
1.1.3 If that evaluation involved the evaluation of Element Locally Valid (Type) (§3.3.4), clause 1 thereof must beis satisfied.
1.2 All of the following must beare true:
1.2.1
1.2.2 A non-·absent··non-absent· type definition is known for it, 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)), of the ·actual value· of that attribute information item resolve to a type definition, as defined in QName resolution (Instance) (§3.17.4)[Definition:]  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) (if it is a complex type definition), or given the empty set, as defined in Type Derivation OK (Simple) (§3.16.6) (if it is a simple type definition).
1.2.3 The 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)its ·governing type definition· has been evaluated as per Element Locally Valid (Type) (§3.3.4).
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), 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
For each of the attribute information items among its [attributes], the appropriate case among the following must beis true:
3.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 otherwise its schema-validity is not assessed.
4
For each of the element information items among its [children], the appropriate case among the following must beis true:
4.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).
4.2 If the child is ·attributed to· a skip Wildcard , then its schema-validity is not assessed.
4.3 otherwise its schema-validity is ·laxly assessed· with respect to ·xs:anyType·.
[Definition:]  If either case of clause 1 above holds, the element information item has been strictly assessed.
[Definition:]   If the item cannot be ·strictly assessed·, because neither clause 1.1 nor clause 1.2 above are is satisfied, and the item is not ·skipped·, anthe element information item's schema validity maymust be laxly assessed if its ·context-determined declaration· is not skip by ·validating· with respect to ↓↓ the ·ur-type definition··xs:anyType· as per Element Locally Valid (Type) (§3.3.4)and assessing schema-validity of its [attributes] and [children] as per clause 3 and clause 4 above. If the element information item is ·skipped·, it must not be laxly assessed.

Editorial Note: Priority Feedback Request

In version 1.0 of this specification, the fallback to lax validation described in the preceding paragraph was optional, not required. The XML Schema Working Group solicits input from implementors and users of this specification as to whether this change is desirable and acceptable.
Note:  When an element information item is ·strictly assessed· or ·laxly assessed·, clause 3 above requires that all xsi: [attributes] be assessed with respect to the corresponding attribute declarations from Built-in Attribute Declarations (§3.2.7). The result of such assessment is present in the ·post-schema-validation infoset·, as defined in Attribute Declaration Information Set Contributions (§3.2.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).
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

Schema Information Set Contribution: Assessment Outcome (Element)
Ifand only if the schema-validity of an element information item has been assessed as per Schema-Validity Assessment (Element) (§3.3.4), 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.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.
Schema Information Set Contribution: Validation Failure (Element)
Ifand only if the local ·validity·, as defined by Element Locally Valid (Element) (§3.3.4) above and/or Element Locally Valid (Type) (§3.3.4) 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) 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 have been checked and failed on the element information item, as defined by Identity-constraint Satisfied (§3.11.4).
Note:  If more than one identity constraint fails to be satisfied, it is ·implementation-dependent· which of the failed identity constraints are included here. As a result, processors may produce different values for this property.
[failed assertions]
A list of Assertions that have been checked and failed on the element information item, as defined by Assertion Satisfied (§3.13.4).
Note:  If more than one assertion fails to be satisfied, it is ·implementation-dependent· which of the failed assertions are included here. As a result, processors may produce different values for this property.
Schema Information Set Contribution: Element Declaration
Ifand only if a ·governing element declaration· is known for an element information itemis ·valid· with respect to an element declaration as per Element Locally Valid (Element) (§3.3.4), 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) 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 of Element Locally Valid (Element) (§3.3.4) 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 ·valid· as defined by Element Locally Valid (Element) (§3.3.4), then valid
2 otherwise (the item was ·invalid· as defined by Element Locally Valid (Element) (§3.3.4)) invalid.
Schema Information Set Contribution: Element Validated by Type
Ifand only if and only if a ·governing type definition· is known for an element information itemis ·valid· with respect to a ·type definition· as per Element Locally Valid (Type) (§3.3.4), 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) and Element Default Value (§3.3.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 clause 3.2 of Element Locally Valid (Element) (§3.3.4) above has not applied 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) 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) above has not applied and the the element's ·normalized 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 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 the {name} is not ·absent·. If the ·type definition·'s {name} property 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·.
[type fallback]
A keyword indicating whether the expected type definition was unavailable and the element had a fallback type as its ·governing type definition·
[type alternative]
If the element's ·governing element declaration· does not have a {type table}, then ·absent·; otherwise the first Type Alternative that ·successfully selected· the element's ·selected type definition·, if any; otherwise the {default type definition}.
[local type validity]
The appropriate case among the following:
1 If the element information item was ·valid· as defined by Element Locally Valid (Type) (§3.3.4), then valid
2 otherwise (the item was ·invalid· as defined by Element Locally Valid (Type) (§3.3.4)) invalid.
[descendent 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) 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· andthe ·governing type definition· is a simple type definitionwith {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}basic member of its transitive membership which actually ·validated· the element item's ·normalized value· [schema 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·.
[member type definition anonymous]
true if the {name} of the ·actual member type definition· is ·absent·, otherwise false.
[member type definition name]
The {name} of the ·actual member type definition·, 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:
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})