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

W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures
W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures
W3C Recommendation 5 April 2012
This version:
Latest version:
Previous version:
Editors (Version 1.1):
Shudi (Sandy) Gao 高殊镝, IBM

C. M. Sperberg-McQueen, Black Mesa Technologies LLC

Henry S. Thompson, University of Edinburgh

Editors (Version 1.0):
Henry S. Thompson, University of Edinburgh

Noah Mendelsohn, IBM (retired)

David Beech, Oracle Corporation (retired)

Murray Maloney, Muzmo Communications

Please refer to the
errata
for this document, which may
include some normative corrections.
See also
translations
This document is also available in these non-normative formats:
XML
XHTML with 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
W3C
MIT
ERCIM
Keio
), All Rights Reserved. W3C
liability
trademark
and
document use
rules apply.
Abstract
This
document specifies the XML Schema Definition Language,
which offers facilities for describing the structure and constraining the contents
of XML documents, including those which
exploit the XML Namespace facility. The schema language, which is itself
represented in
an XML vocabulary and uses
namespaces, substantially reconstructs and considerably
extends the capabilities found in XML
document type definitions (DTDs). This specification depends on
XML 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
This

W3C Recommendation
specifies

the W3C XML Schema Definition Language (XSD) 1.1.
It

is here made available for

use
by W3C members
and the public.
XSD 1.1 retains all the essential features of XSD 1.0
but adds several new features to support functionality
requested by users, fixes many errors in XSD 1.0, and
clarifies wording.
This draft was published on 5 April
2012. The major revisions since the previous public
working draft include the following:
Some minor errors, typographic and otherwise,
have been corrected.
For those primarily interested in the changes since version 1.0,
the appendix
Changes since version 1.0 (non-normative) (§G)
is the recommended starting
point. It summarizes both changes made since XSD 1.0 and some
changes which were expected (and predicted in earlier drafts of
this specification) but have not been made after all.
Accompanying versions of this document display in color all
changes to normative text since version 1.0 and since the previous
Working Draft.
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

If access to Bugzilla is not feasible, please send your comments
to the W3C XML Schema comments mailing list,
www-xml-schema-comments@w3.org
archive
and note explicitly that you have not made a Bugzilla entry for
the comment. Each Bugzilla entry and email message should contain
only one comment.
This document has been reviewed by W3C
Members, by software developers, and by other W3C groups and
interested parties, and is endorsed by the Director as a W3C
Recommendation. It is a stable document and may be used as
reference material or cited from another document. W3C's role in
making the Recommendation is to draw attention to the specification
and to promote its widespread deployment. This enhances the
functionality and interoperability of the Web.
An
implementation report
for XSD
1.1 was prepared and used in the
Director's decision to publish the previous version of this specification
as a Proposed Recommendation. The Director's decision to publish
this document as a W3C Recommendation is based on consideration
of reviews of the Proposed Recommendation by the public and by
the members of the W3C Advisory committee.
The W3C XML Schema Working Group intends to process comments
made about this recommendation, with any approved changes being
handled as errata to be published separately.
This document has been produced by the
W3C XML Schema Working Group
as part
of the W3C
XML
Activity
. The goals of XSD 1.1 are discussed in the
document
Requirements
for XML Schema 1.1
. The authors of this document are the
members of the XML Schema Working Group. Different parts of this specification have
different editors.
This document was produced by a group operating under the
5 February
2004 W3C Patent Policy
. W3C maintains a
public list of
any patent disclosures
made in connection with the deliverables
of the group; that page also includes instructions for disclosing a
patent. An individual who has actual knowledge of a patent which the
individual believes contains
Essential
Claim(s)
must disclose the information in accordance with
section
6 of the W3C Patent Policy
The English version of this specification is the only normative
version. Information about translations of this document is available
at
Table of Contents
Introduction
1.1
Introduction to Version 1.1
1.2
Purpose
1.3
Namespaces and Language Identifiers
XSD Namespaces
Namespaces with Special Status
Conventional Namespace Bindings
Schema Language Identifiers
1.4
Dependencies on Other Specifications
1.5
Documentation Conventions and Terminology
Conceptual Framework
2.1
Overview of XSD
2.2
XSD Abstract Data Model
Type Definition Components
Declaration Components
Model Group Components
Constraint Components
Group Definition Components
Annotation Components
2.3
Constraints and Validation Rules
2.4
Conformance
2.5
Schema-validity and documents
2.6
Names and Symbol Spaces
2.7
Schema-Related Markup in Documents Being Validated
xsi:type
xsi:nil
xsi:schemaLocation, xsi:noNamespaceSchemaLocation
2.8
Representation of Schemas on the World Wide Web
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
Schemas and Namespaces: Access and Composition
4.1
Layer 1: Summary of the Schema-validity Assessment Core
4.2
Layer 2: Schema Documents, Namespaces and Composition
Basic concepts of schema construction and composition
Conditional inclusion
Assembling a schema for a single target namespace from
multiple schema definition documents
()
Including modified component definitions ()
Overriding component definitions ()
References to schema components across namespaces ()
4.3
Layer 3: Schema Document Access and Web-interoperability
Standards for representation of schemas and retrieval of schema documents on the Web
How schema definitions are located on the Web
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
Schema for Schema Documents (Structures) (normative)
Outcome Tabulations (normative)
B.1
Validation Rules
B.2
Contributions to the post-schema-validation infoset
B.3
Schema Representation Constraints
B.4
Schema Component Constraints
Terminology for implementation-defined features (normative)
C.1
Subset of the Post-schema-validation Infoset
C.2
Terminology of schema construction
Identifying locations where components are sought
Identifying methods of indirection
Identifying the key for use in indirection
Identifying when to stop searching
Identifying how to react to failure
C.3
Other Implementation-defined Features
Required Information Set Items and Properties (normative)
Checklists of implementation-defined and implementation-dependent features (normative)
E.1
Checklist of implementation-defined features
E.2
Checklist of implementation-dependent features
Stylesheets for Composing Schema Documents (Normative)
F.1
Transformation for Chameleon Inclusion
F.2
Transformation for xs:override
Changes since version 1.0 (non-normative)
G.1
Changes made since version 1.0
Relationship between XSD and other specifications
XSD versions
Changes to content models
Assertions and XPath
Derivation of complex types
Changes to complex type definitions
ID, IDREF, and related types
Simple type definitions
Element declarations
Attribute declarations
Component structure
The process of validation
The post-schema-validation infoset
Conformance
Schema composition
Other substantive changes
Clarifications and editorial changes
G.2
Issues not resolved
Glossary (non-normative)
DTD for Schemas (non-normative)
Analysis of the Unique Particle Attribution Constraint (non-normative)
XSD Language Identifiers (non-normative)
References
L.1
Normative
L.2
Non-normative
Acknowledgements (non-normative)
1 Introduction
This document sets out the structural part of the XML Schema Definition Language.
Chapter 2 presents a
Conceptual Framework (§2)
for XSD, including an introduction to the
nature of XSD schemas and an introduction to the XSD
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 XSD schema for
an XSD 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 Schema Documents (Structures) (normative) (§A)
for the XML representation of
schemas and
Normative (§L.1)
The non-normative appendices include the
DTD for Schemas (non-normative) (§I)
and a
Glossary (non-normative) (§H)
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.
1.1 Introduction to Version 1.1
The Working Group has three main goals for this version of W3C
XML Schema:
Significant improvements in simplicity of design and
clarity of exposition
without
loss of backward
or
forward compatibility;
Provision of support for versioning of XML languages
defined using this
specification, including the XML vocabulary
specified here for use in schema documents.
Provision of support for
co-occurrence constraints, that is constraints which make the
presence of an attribute or element, or the values allowable
for it, depend on the value or presence of other attributes or
elements.
These goals are
in tension with one another. The Working Group's strategic guidelines
for changes between versions 1.0 and 1.1 can be summarized as follows:
Support
for versioning (acknowledging that this
may
be
slightly disruptive to the XML transfer syntax at the
margins)
Support for co-occurrence
constraints (which will certainly involve additions to the XML
transfer syntax, which will not be understood by 1.0
processors)
Bug fixes (unless in specific
cases we decide that the fix is too disruptive for a point
release)
Editorial changes
Design cleanup will possibly change behavior in edge
cases
Non-disruptive changes to type hierarchy
(to better support current and forthcoming international
standards and W3C recommendations)
Design cleanup will possibly change component structure
(changes to functionality restricted to edge cases)
No
significant changes in existing functionality
No changes
to XML transfer syntax except those required by version control
hooks, co-occurrence
constraints and bug fixes
The aim with regard
to compatibility is that
All schema documents conformant to version 1.0 of this
specification
[XSD 1.0 2E]
should also conform to version 1.1, and should
have the same
assessment
behavior across 1.0 and 1.1 implementations
(except possibly in edge cases and in the details of the
resulting PSVI);
The vast majority of schema documents conformant to
version 1.1 of this specification should also conform to
version 1.0, leaving aside any incompatibilities arising from
support for versioning or
co-occurrence constraints, and when they are
conformant to version 1.0 (or are made conformant by the
removal of versioning information), should have the same
assessment
behavior
across 1.0 and 1.1 implementations (again except possibly in
edge cases and in the details of the resulting PSVI);
1.2 Purpose
The purpose of
XML Schema Definition Language: Structures
is to define the nature of
XSD schemas and their component parts,
provide an inventory of XML markup constructs with which to
represent schemas, and define the application of schemas to XML
documents.
The purpose of an XSD 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 can also provide for
the specification of additional document information, such as
normalization and defaulting of attribute and element values.
Schemas have facilities for self-documentation. Thus,
XML Schema Definition Language: Structures
can
be used to define, describe and catalogue XML vocabularies for
classes of XML documents.
Any application that consumes well-formed XML can use the
formalism defined here to express
syntactic, structural and value constraints applicable to its
document instances. The XSD 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 applications. Some applications
will require constraint capabilities not expressible in this
language, and so will need to perform their own additional
validations.
1.3 Namespaces and Language Identifiers
1.3.1
XSD Namespaces
1.3.1.1
The Schema Namespace (xs)
1.3.1.2
The Schema Instance Namespace (xsi)
1.3.1.3
The Schema Versioning Namespace (vc)
1.3.2
Namespaces with Special Status
1.3.3
Conventional Namespace Bindings
1.3.4
Schema Language Identifiers
1.3.1 XSD Namespaces
1.3.1.1 The Schema Namespace (
xs
The XML representation of schema components uses a vocabulary
identified by the namespace name
For brevity, the text and examples in this specification use
the prefix
xs:
to stand for this
namespace; in practice, any prefix can be used.
Note:
The namespace for schema documents is unchanged from version
1.0 of this specification
[XSD 1.0 2E]
because any schema document valid
under the rules of version 1.0 has essentially the same
assessment
semantics under this specification as it did under
version 1.0 (Second Edition).
There are a few exceptions to this rule, involving errors in
version 1.0 of this specification which were not reparable by
errata and which have therefore been fixed only in this
version of this specification, not in version 1.0.
Note:
The data model used by
[XPath 2.0]
and other
specifications, namely
[XDM]
, makes use of
type labels in the
XSD namespace (
untyped
untypedAtomic
) which are not defined in this
specification; see the
[XDM]
specification for details of those types.
Users of the namespaces defined here should be aware, as a
matter of namespace policy, that more names
in this namespace may be given
definitions in future versions of this or other
specifications.
1.3.1.2 The Schema Instance Namespace (
xsi
This specification defines
several attributes for direct use in any XML documents, as
described in
Schema-Related Markup in Documents Being Validated (§2.7)
These attributes are in the namespace whose name is
For brevity, the text and examples in this specification use
the prefix
xsi:
to stand for this namespace; in
practice, any prefix can be used.
Users of the namespaces defined here should be aware, as a
matter of namespace policy, that more names
in this namespace may be given
definitions in future versions of this or other
specifications.
1.3.1.3 The Schema Versioning Namespace (
vc
The pre-processing of schema documents described in
Conditional inclusion (§4.2.2)
uses
attributes in the namespace
For brevity, the text and examples in this specification use
the prefix
vc:
to stand for this
namespace; in practice, any prefix can be used.
Users of the namespaces defined here should be aware, as a
matter of namespace policy, that more names in this namespace
may be given definitions in future versions of this or other
specifications.
1.3.2 Namespaces with Special Status
Except as otherwise specified elsewhere in this specification,
if components are
present
in a schema, or source
declarations are included in an XSD schema document, for
components in any of the following namespaces, then the
components, or the declarations,
should
agree with the
descriptions given in the relevant specifications and with the
declarations given in any applicable XSD schema documents
maintained by the World Wide Web Consortium for these
namespaces. If they do not, the effect is
implementation-dependent
and not defined by this specification.
Note:
Depending on implementation details, some processors may
be able to process and use (for example) variant forms of the
schema for schema documents devised for specialized purposes;
if so, this specification does not forbid the use of such variant
components. Other processors, however, may find it
impossible to validate and use alternative components for
these namespaces; this specification does not require them
to do so. Users who have an interest in such specialized
processing should be aware of the attending interoperability
problems and should exercise caution.
This flexibility does not extend to the components described in
this specification or in
[XML Schema: Datatypes]
as being
included in every schema, such as those for the primitive and
other built-in datatypes. Since those components are by
definition part of every schema, it is not possible to have
different components with the same
expanded names
present in
the schema without violating constraints defined elsewhere
against multiple components with the same
expanded names
Components and source declarations
must not
specify
as their
target namespace. If they do, then the schema
and/or schema document is in
error
Note:
Any confusion in the use, structure, or meaning of this namespace
would have catastrophic effects on the interpretability of
this specification.
1.3.3 Conventional Namespace Bindings
Several namespace prefixes are conventionally used in this
document for notational convenience. The following bindings are
assumed.
fn
bound to
(defined
in
[Functions and Operators]
html
bound to
my
(in examples) bound to the target namespace
of the example schema document
rddl
bound to
vc
bound to
(defined
in this and related specifications)
xhtml
bound to
xlink
bound to
xml
bound to
(defined in
[XML 1.1]
and
[XML Namespaces 1.1]
xs
bound to
(defined in this and related specifications)
xsi
bound to
(defined in this and
related specifications)
xsl
bound to
In practice, any prefix bound to the appropriate namespace
name
may
be used (unless otherwise specified by the definition
of the namespace in question, as for
xml
and
xmlns
).
1.3.4 Schema Language Identifiers
Sometimes other specifications or Application Programming
Interfaces (APIs) need to refer to the XML Schema Definition Language in
general, sometimes they need to refer to a specific version of
the language,
possibly even to a version defined in a superseded draft.
To make such references easy and enable consistent identifiers to be used, we provide the following
URIs to identify these
concepts.
Identifies the XML Schema Definition Language in general, without referring
to a specific version of it.
Identifies the language described in version
of the XSD specification. URIs of this form refer to
a numbered version
of the language in general. They do not distinguish among different working drafts or
editions of that version. For example,
identifies
XSD version 1.0 and
identifies
XSD version 1.1.
Identifies the language described in the
-th edition of version
of
the XSD specification. For example,
identifies the second edition of XSD version 1.0.
e/yyyymmdd
Identifies the language described in the
-th edition of version
of
the XSD specification published on the particular date
yyyy-mm-dd
. For example,
identifies the language
defined in the XSD version 1.0 Candidate
Recommendation (CR) published on 24 October 2000, and
identifies the language
defined in the XSD version 1.0 Second Edition Proposed
Edited Recommendation (PER)
published on 18 March 2004.
Please see
XSD Language Identifiers (non-normative) (§K)
for a
complete list of XML Schema Definition Language identifiers which exist to date.
1.4 Dependencies on Other Specifications
The definition of
XML Schema Definition Language: Structures
depends on the following
specifications:
[XML Infoset]
[XML Namespaces 1.1]
[XPath 2.0]
and
[XML Schema: Datatypes]
See
Required Information Set Items and Properties (normative) (§D)
for a tabulation of the
information items and properties specified in
[XML Infoset]
which this
specification requires as a precondition to schema-aware
processing.
[XML Schema: Datatypes]
defines some
datatypes which depend on definitions in
[XML 1.1]
and
[XML Namespaces 1.1]
; those definitions, and therefore
the datatypes based on them, vary between version 1.0 (
[XML 1.0]
[Namespaces in XML 1.0]
) and
version 1.1 (
[XML 1.1]
[XML Namespaces 1.1]
) of those specifications. In any
given schema-validity-
assessment
episode, the choice of the 1.0 or the 1.1 definition of those
datatypes is
implementation-defined
Conforming implementations of this specification
may
provide
either the 1.1-based datatypes or the 1.0-based datatypes, or
both. If both are supported, the choice of which datatypes to
use in a particular assessment episode
should
be under user
control.
Note:
It is a consequence of the
rule just given that implementations
may
provide the heuristic of using the 1.1
datatypes if the input is labeled as XML 1.1, and the 1.0
datatypes if the input is labeled 1.0. It should be noted
however that the XML version number is not required to be
present in the input to an assessment episode, and in any case
the heuristic
should
be subject to override by users, to
support cases where users wish to accept XML 1.1 input but
validate it using the 1.0 datatypes, or accept XML 1.0 input and
validate it using the 1.1 datatypes.
Note:
Some users will perhaps wish to accept only XML 1.1 input, or
only XML 1.0 input. The rules
just given ensure that conforming implementations of this
specification which accept XML input
may
accept XML 1.0, XML
1.1, or both and
may
provide user control over which versions
of XML to accept.
1.5 Documentation Conventions and Terminology
The section introduces the highlighting and typography as used
in this document to present technical material.
Unless otherwise noted, the entire text of
this specification is normative. Exceptions include:
notes
sections explicitly marked non-normative
examples and their commentary
informal descriptions of the consequences of rules
formally and normatively stated elsewhere (such informal
descriptions are typically introduced by phrases like
"Informally, ..." or "It is a
consequence of ... that ...")
Explicit statements that some material is normative are not
to be taken as implying that material not so described
is non-normative
(other than that mentioned in the list just given).
Special terms are defined at their point of introduction in the
text. For example
[Definition:]
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

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}
Component
component. Required.
An example property
References to properties of schema components are links to the
relevant definition as exemplified above, set off with curly
braces, for instance
{example property}
For a given component
, an expression
of the form "
{example property}
denotes the (value of the) property
{example property}
for component
The leading "
." (or more) is sometimes omitted,
if the identity of the component and any other omitted properties
is understood from the context.
This "dot operator" is left-associative, so
{p1}
{p2}
means the same as
"(
{p1}
) .
{p2}
and denotes the value of property
{p2}
within the component or
property record
which itself
is the value of
's
{p1}
property.
White space on either side of the dot operator has no significance
and is used (rarely) solely for legibility.
For components
and
, an expression
of the form "
{example property 1}
{example property 2}
means that
and
have the same value for the
property (or properties) in question. Similarly,
" means that
and
are
identical, and "
{example property}
" that
is the value of
{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
determines which of several
different components corresponds 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 Schema Documents (Structures) (normative) (§A)
. In the case of apparent
conflict, the
Schema for Schema 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
count
integer
size = (
large
medium
small
) : medium>
Content:
all
any
*)

Example
Schema Component
Property
Representation
{example property}
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

Unless otherwise specified, references to attribute values
are references to the
actual value
of the attribute information
item in question, not to its
normalized value
or to other forms
or varieties of "value" associated with it.
For a given element information item
, expressions of the
form "
has
att1
are short-hand for "there is an attribute information
item named
att1
among the
[attributes]
of
and
its
actual value
is
."
If the identity of
is clear from context, expressions
of the form "
att1
are sometimes used.
The form "
att1
" is also used
to specify that the
actual value
of
att1
is
not
References to properties of information items as defined in
[XML Infoset]
are notated as links to the relevant
section thereof, set off with square brackets, for example
[children]
Properties which this specification defines for information
items are introduced as follows:
PSVI Contributions for
example information items
[new property]
The value the property
gets.
References to properties of information items defined in this
specification are notated as links to their introduction as
exemplified above, set off with square brackets, for example
[new property]
The "dot operator" described above
for components and their properties is also used for information items
and their properties. For a given information item
, an expression
of the form "
[new property]
denotes the (value of the) property
[new property]
for item
Lists of normative constraints are typically introduced with
phrase like
"all of the following are true" (or "... apply"),
"one of the following is true",
"at least one of the following is true",
"one or more of the following is true",
"the appropriate case among the following is true",
etc.
The phrase "one of the following is true"
is used in cases where the authors believe the items listed
to be mutually exclusive (so that the distinction between
"exactly one" and "one or more"
does not arise). If the items in such a list are not in fact
mutually exclusive, the phrase "one of the following"
should be interpreted as meaning "one or more of the
following".
The phrase "the appropriate case among the following"
is used only when the cases are thought by the authors to be
mutually exclusive; if the cases in such a list are not in fact
mutually exclusive, the first applicable case should be
taken. Once a case has been encountered with a true condition,
subsequent cases
must
not be tested.
The following highlighting is used for non-normative commentary
in this document:
Note:
General comments directed to all readers.
Within normative prose in this
specification, the words
may
should
must
and
must not
are
defined as follows:
may
Schemas,
schema documents, and processors are
permitted to but need not behave as described.
should
It is recommended that schemas,
schema documents,
and

processors behave as described, but there
can be valid reasons for them not to; it is important that the
full implications be understood and carefully weighed before
adopting behavior at variance with the recommendation.
must
(Of schemas and
schema documents:)
Schemas and documents are required to behave as
described; otherwise they are in
error
(Of
processors:)
Processors are
required to behave as described.
must not
Schemas,
schema documents, and processors
are forbidden to behave as
described; schemas and documents which nevertheless
do so are in
error
error
A failure of a schema
or schema
document to conform to the rules of this
specification.
Except as otherwise specified,
processors
must
distinguish error-free (conforming) schemas
and schema documents used in
assessment
from those with errors;

if a schema used in
assessment
or a schema document used in constructing a schema
is in error,
processors
must
report the fact;
if more than one is in error, it is
implementation-dependent
whether more than one is reported as being in error.
If one or more of the constraint codes given
in
Outcome Tabulations (normative) (§B)
is applicable, it is
implementation-dependent
how many of them, and which,
are reported.
Note:
Failure of an XML document to be valid against a particular
schema is not (except for the special case of a schema
document consulted in the course of building a schema) in
itself a failure to conform to this specification and thus,
for purposes of this specification, not an error.
Note:
Notwithstanding the fact that (as just noted) failure to be
schema-valid is not a violation of this specification and
thus not strictly speaking an error as defined here,
the names of the PSVI properties
[schema error code]
(for attributes) and
[schema error code]
(for elements) are retained for
compatibility with other versions of this specification, and
because in many applications of XSD, non-conforming
documents
are
"in error" for
purposes of those applications.
deprecated
A feature or construct defined in this specification
described as
deprecated
is retained in this
specification for compatibility with previous versions
of the specification, and but its use is not advisable and
schema authors
should
avoid its use if possible.
Deprecation has no effect on the conformance of schemas
or schema documents which use deprecated features.
Since deprecated features are part of the specification,
processors
must
support them, although some processors
may
choose to issue warning messages when deprecated
features are encountered.
Features deprecated in this version of this specification
may be removed entirely in future versions, if any.
[Definition:]
user option
A choice left under the control of the user of a processor,
rather than being fixed for all users or uses of the processor.
Statements in this specification that "Processors
may
at user option" behave in a certain way mean that
processors
may
provide mechanisms to allow users
(i.e. invokers of the processor) to enable or disable the
behavior indicated. Processors which do not provide such
user-operable controls
must not
behave in the way indicated.
Processors which do provide such
user-operable controls
must
make it possible for the user
to disable the optional behavior.
Note:
The normal expectation is that the default setting for
such options will be to disable the optional
behavior in question,
enabling it only when the user explicitly requests it. This
is not, however, a requirement of conformance: if the
processor's documentation makes clear that the user can
disable the optional
behavior, then invoking the processor without
requesting that it be disabled can be taken as equivalent to
a request that it be enabled.
It is required,
however, that it in fact be possible for the user to disable the
optional behavior.
Note:
Nothing in this specification constrains the manner
in which processors allow users to control user options.
Command-line options, menu choices in a graphical user
interface, environment variables, alternative call patterns
in an application programming interface, and other
mechanisms may all be taken as providing user options.
These definitions describe in terms
specific to this document the meanings assigned to these terms by
[IETF RFC 2119]
. The specific wording follows
that of
[XML 1.1]
Where these terms appear without special highlighting,
they are used in their ordinary senses and do not express conformance
requirements. Where these terms appear highlighted within
non-normative material (e.g. notes), they are recapitulating
rules normatively stated elsewhere.
This
specification provides a
further description
of error and of conformant
processors' responsibilities with respect to errors in
Schemas and Schema-validity Assessment (§5)
2 Conceptual Framework
This chapter gives an overview of
XML Schema Definition Language: Structures
at the level of its
abstract data model.
Schema Component Details (§3)
provides details
on this model, including a normative representation in XML for the
components of the model. Readers interested primarily in learning
to write schema documents will 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.
2.1 Overview of XSD
An XSD schema is
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
to
specify additional information about
those items and their descendants. These augmentations
to the information set make explicit information that
was implicitly
present in the original
document (or in the original document
and the governing schema, taken together), such as normalized and/or default values for attributes
and elements and the types of element and attribute information
items. The input information set
is
also augmented with information about the validity of the
item, or about other properties described in this
specification.
[Definition:]
We refer to the augmented infoset which
results from conformant processing as defined in this
specification as the
post-schema-validation
infoset
, or
PSVI
. Conforming processors
may
provide
access to some or
all of the PSVI, as described in
Subset of the Post-schema-validation Infoset (§C.1)
. The mechanisms by which
processors provide such
access to the PSVI are neither defined nor constrained by this
specification.
[Definition:]
As it is used in this specification, the
term
schema-validity assessment
has three aspects:
Determining local schema-validity, that is
whether an element or attribute information item satisfies
the constraints embodied in the
relevant components of an
XSD schema
(specifically the
governing
element or attribute declaration and/or
governing
type definition);
Determining an
overall validation outcome for the item
by combining local schema-validity with
the results of schema-validity assessments of its
descendants, if any; and
Determining the appropriate
augmentations to the infoset (and, if desired, exposing them
to downstream applications in some way, to record this
outcome).
Throughout this specification,
[Definition:]
the word
assessment
is used to refer to the overall process of local validation,
recursive determination of
validation outcome, and infoset augmentation, i.e. as a short form for
schema-validity assessment
[Definition:]
Validation
is the process of determining
whether an XML document, an element information item, or an
attribute information item obeys the constraints expressed in a
schema; in the context of XSD, this amounts to calculating the
value of the appropriate item's
[validity]
property.
Note:
As just defined, validation produces not a binary result, but a
ternary one: if the information item is
strictly assessed
it will be either valid or invalid, but if no applicable
declaration is found, its validity will be unknown (and its
[validity]
property will have the
value
notKnown
). Whether in a particular application
notKnown
should be treated in the same way as
invalid
or differently is outside the scope of this
specification; sometimes one choice is appropriate,
sometimes the other.
Note:
In phrases such as "
validly substitutable
and "length valid restriction", the word
valid
is used in its ordinary English sense
of "conforming to some set of rules", not
necessarily limited to rules expressed in an XSD schema.
In general, a
valid document
is a document whose contents obey the constraints expressed in a
particular schema. Since a document may be validated against many
different schemas, it is often clearer to speak of a document
being valid
against a particular schema
. When this
specification is used, document validity can be defined
operationally in terms of the
post-schema-validation infoset
properties on the nodes of
the document (in particular [validity]). Several similar but distinct kinds of validity are
usefully distinguished, for which terms are defined below in
Schema-validity and documents (§2.5)
Because the [validity] property is part of the
post-schema-validation infoset
, it should be
evident that any full
assessment
of an item by definition
entails the
validation
of that item. Conversely, since the
[validity] property is recursive and
depends upon many other pieces of information which are part of
the
post-schema-validation infoset
validation
also typically entails at least partial
assessment
. The processes denoted by the two terms thus
overlap and are not always distinguishable; often the same
process can be referred to by either term. In this specification,
the term "
assessment
" is used when it is desired
to stress the calculation of the complete
post-schema-validation infoset
, including
properties whose values have no effect on validity.
The term "
validation
", in contrast, is used
when it is desired to focus primarily on the
validity
of the item, treating the other information generated in
the process as merely incidental.
Note:
When there is no particular
emphasis one way or the other, the choice of terms is
necessarily arbitrary, or grounded in the history of
this and related specifications. Historical reasons,
rather than connotation, determine the
use of the term "
validation
" instead of
assessment
" in terms like
post-schema-validation infoset
",
validation root
", and
"Validation Rules".
During
assessment
, some or
all of the element and attribute information items in the input
document are associated with declarations and/or type
definitions; these declarations and type definitions are then
used in the
assessment
of those items, in a
recursive process.
[Definition:]
The declaration associated with an information
item, if any, and with respect to which its validity is
assessed
in a given assessment episode
is said to
govern
the item, or to be its
governing
element or attribute declaration.
Similarly the type definition with respect to which the
type-validity of an item is assessed is its
governing
type definition.
Note:
See also the definitions of
governing element declaration
and
governing type definition
(for elements) and
governing attribute declaration
and
governing type definition
(for
attributes).
2.2 XSD Abstract Data Model
2.2.1
Type Definition Components
2.2.1.1
Type Definition Hierarchy
2.2.1.2
Simple Type Definition
2.2.1.3
Complex Type Definition
2.2.2
Declaration Components
2.2.2.1
Element Declaration
2.2.2.2
Element Substitution Group
2.2.2.3
Attribute Declaration
2.2.2.4
Notation Declaration
2.2.3
Model Group Components
2.2.3.1
Model Group
2.2.3.2
Particle
2.2.3.3
Attribute Use
2.2.3.4
Wildcard
2.2.4
Constraint Components
2.2.4.1
Identity-constraint Definition
2.2.4.2
Type Alternative
2.2.4.3
Assertion
2.2.4.4
Overlapping Functionality of Constraint Components
2.2.5
Group Definition Components
2.2.5.1
Model Group Definition
2.2.5.2
Attribute Group Definition
2.2.6
Annotation Components
This specification builds on
[XML 1.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
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, XSD schemas can be described in terms of
an abstract data model. In defining schemas in terms of
an abstract data model, this specification rigorously specifies
the information which
must
be available to a conforming
XSD 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 make up the abstract data model
of the schema.
[Definition:]
An
XSD schema
is a set of
schema components
. There are
several kinds of schema component, falling
into three groups. The primary schema components, which
may
(type
definitions) or
must
(element and attribute declarations) have
names, are as follows:
Simple type definitions
Complex type definitions
Attribute declarations
Element declarations
The secondary schema components, are as
follows:
Attribute group definitions
Identity-constraint definitions
Type alternatives
Assertions
Model group definitions
Notation declarations
Finally, the "helper" schema components provide small
parts of other schema components; they are dependent on their context:
Annotations
Model groups
Particles
Wildcards
Attribute Uses
The
name
[Definition:]
Component
covers all the different kinds of
schema component defined in this specification.
During
validation
[Definition:]
declaration
components are associated by (qualified) name to information items
being
validated
On the other hand,
[Definition:]
definition
components define internal
schema components that can be used in other schema
components
[Definition:]
Declarations
and definitions
may
and in
some cases
must
have and be identified by
name
s, 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.
An
expanded name
, as defined in
[XML Namespaces 1.1]
, is a pair consisting
of a namespace name, which
may
be
absent
, and a local
name. The
expanded name
of any component with both a
target namespace
property and a
component name
property is the pair
consisting of the values of those two properties.
The
expanded name
of a declaration is used to help
determine which information items will be
governed
by
the declaration.
Note:
At the abstract level, there is no requirement that the
components of a schema share a
target namespace
. Any schema for
use in
assessment
of documents
containing names from more than one namespace will of necessity
include components with different
target namespaces
. This contrasts
with the situation at the level of the XML representation of
components, in which each schema document contributes
definitions and declarations to a single target namespace.
Validation
, defined in detail
in
Schema Component Details (§3)
, is a relation between information
items and schema components. For example, an attribute
information item is
validated
with respect to an attribute declaration, a list of element
information items 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
xs:anyType
, every
type definition
is, by construction,
either a
restriction
or an
extension
of some
other type definition. The exception
xs:anyType
is a
restriction
of itself.
With the exception of the loop on
xs:anyType
, the
graph of these relationships forms
a tree known as the
Type Definition
Hierarchy
with
xs:anyType
as its
root
[Definition:]
The type definition used as the basis
for an
extension
or
restriction
is
known as the
base type definition
of that
definition
[Definition:]
If a type definition
can reach a type definition
by following
its base type definition chain, then
is said to be
derived
from
In most cases, a type definition is
derived from other type definitions. The only exception is
xs:anyType
, which is derived from itself.
[Definition:]
type defined with the same constraints as its
base type definition
, or with more, is
said to be a
restriction
The added constraints might include narrowed
ranges or reduced alternatives. Given two types
and
, if the definition of
is a
restriction
of the
definition of
, then members of type
are always locally
valid against type
as well.
[Definition:]
A complex
type definition which allows element or attribute content in
addition to that allowed by another specified type definition
is said to be an
extension
Note:
Conceptually, the definitions of
restriction
and
extension
overlap: given a
type
, a vacuous
restriction
of
and a vacuous
extension
of
will each
accept the same inputs as valid. The syntax specified
in this version of this specification, however, requires
that each type be defined either as a restriction
or as an extension, not both. Thus even though the
vacuous extension of
accepts the same inputs as
the vacuous restriction, it will not be accepted in
contexts which require restrictions of
[Definition:]
A special complex type
definition, (referred to in earlier versions of this
specification as 'the ur-type definition') whose
name is
anyType
in the XSD namespace, is
present in each
XSD schema
. The
definition of
anyType
serves as default
type definition for element declarations whose XML
representation does not specify one
[Definition:]
A special simple type
definition, whose name is
error
in the XSD
namespace, is also present in each
XSD schema
. The
XSD
error
type
has no valid instances. It can be used in any place where
other types are normally used; in particular, it can be used
in conditional type assignment to cause elements which satisfy
certain conditions to be invalid.
For brevity, the text and examples in this specification often
use the qualified names
xs:anyType
and
xs:error
for these type definitions. (In
practice, any appropriately declared prefix can be used, as
described in
Schema-Related Markup in Documents Being Validated (§2.7)
.)
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 its
base type definition
[Definition:]
special
restriction
of
xs:anyType
, whose name is
anySimpleType
in the
XSD namespace, is the root of the
Type Definition Hierarchy
for all simple type
definitions.
xs:anySimpleType
has a lexical space containing
all sequences of characters in the Universal Character
Set (UCS) and a value space containing all
atomic values
and all finite-length lists of
atomic values
As with
xs:anyType
, this
specification sometimes uses the qualified name
xs:anySimpleType
to designate this type
definition. The
built-in list datatypes all have
xs:anySimpleType
as their
base type
definition
[Definition:]
There is a further special datatype
called
anyAtomicType
, a
restriction
of
xs:anySimpleType
, which is the
base type definition
of all the primitive
datatypes.
This type definition is often referred
to simply as "
xs:anyAtomicType
".
It too is
considered to have an unconstrained lexical space. Its value
space consists of the union of the value spaces of all the
primitive datatypes.
[Definition:]
Datatypes can be
constructed
from other datatypes by
restricting
the value space or lexical space of a
{base type definition}
using zero or more
Constraining Facet
s, by specifying the new datatype as a
list
of items of some
{item type definition}
or by defining it as a
union
of some specified sequence of
{member type definitions}
The mapping from lexical space to value space is unspecified
for items whose type definition is
xs:anySimpleType
or
xs:anyAtomicType
. Accordingly
this specification does not constrain processors'
behavior in areas
where this mapping is implicated, for example checking such
items against enumerations, constructing default attributes or
elements whose declared type definition is
xs:anySimpleType
or
xs:anyAtomicType
checking identity constraints involving such items.
Note:
The Working Group expects to return to this area in a future
version of this specification.
[XML Schema: Datatypes]
provides mechanisms for defining new simple type definitions
by
restricting
some primitive
or ordinary datatype. It also
provides mechanisms for constructing new simple type
definitions whose members are lists of items
themselves constrained by some other simple type definition, or
whose membership is the union of the memberships of some other
simple type definitions. Such list and union simple type
definitions are also
restrictions
of
xs:anySimpleType
For detailed information on simple type definitions, see
Simple Type Definitions (§3.16)
and
[XML Schema: Datatypes]
. The
latter also defines an extensive inventory of pre-defined
simple types.
2.2.1.3 Complex Type Definition
A complex type definition is a set of attribute declarations
and a content type, applicable to the
[attributes]
and
[children]
of an element information item respectively. The
content type
may
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
xs:anyType
is
either
a restriction of a complex
base type
definition
or
an
extension
of
a simple or complex
base type
definition
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:
For the most part, this
specification allows only appending, and not other kinds of
extensions. This decision simplifies application processing
required to cast instances from

the derived type to the base type.

One special case allows the
extension of
all
-groups in ways that do not
guarantee that the new material occurs only at the end of
the content. Another
special case is extension via
Open Content
s in
interleave
mode.
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 declarations contribute to
validation
as part of model group
validation
, when their defaults
and type components are checked against an element information
item with a matching name and namespace, and by triggering
identity-constraint definition
validation
For detailed information on element declarations, see
Element Declarations (§3.3)
For an overview of identity constraints, see
Identity-constraint Definition (§2.2.4.1)
2.2.2.2 Element Substitution Group
When XML vocabularies are defined using
the
DTD syntax defined by
[XML 1.1]
a reference in a content model to a particular name is satisfied
only by an element in the XML document whose
name and content correspond exactly to those given in the
corresponding
element type
declaration
Note:
The "element type declaration"
of
[XML 1.1]
is not quite the same as the
governing type definition
as defined
in this specification:
[XML 1.1]
does not
distinguish between element declarations and
type definitions as
distinct kinds of object in the way that this specification
does. The "element type declaration" of
[XML 1.1]
specifies both the kinds of properties
associated in this specification with element declarations
and the kinds of properties associated here with
(complex) type definitions.
[Definition:]
Through the
mechanism of
element substitution
groups
, XSD provides a more powerful model
than DTDs do
supporting substitution of one named element for
another
. Any top-level element declaration can serve
as the defining member, or head, for an element
substitution group
Other top-level element declarations, regardless of target
namespace, can be designated as members of the
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
as well.
All such members
must
have type definitions which are
either the same as the head's type definition or derived
from it. Therefore, although the names of elements
can vary widely as new namespaces and members of the
substitution group
are defined, the content of member elements is
constrained by the type
definition of the
substitution group
head.
Note that element substitution groups are not represented as
separate components. They are specified in the property values
for element declarations (see
Element Declarations (§3.3)
).
2.2.2.3 Attribute Declaration
An attribute declaration is an association between a name and
a simple type definition, together with occurrence information
and (optionally) a default value. The association is either
global, or local to its containing complex type definition.
Attribute declarations contribute to
validation
as part of complex type
definition
validation
, when
their occurrence, defaults and type components are checked
against an attribute information item with a matching name and
namespace.
For detailed information on attribute declarations, see
Attribute Declarations (§3.2)
2.2.2.4 Notation Declaration
A notation declaration is an association between a name and
an identifier for a notation. For an attribute or element information item to
be
valid
with respect to a
NOTATION
simple type definition, its value
must
have been declared with a notation declaration.
For detailed information on notation declarations, see
Notation Declarations (§3.14)
2.2.3 Model Group Components
The model group, particle, and wildcard components
contribute to the portion of a complex type definition that
controls an element information item's content.
2.2.3.1 Model Group
A model group is a constraint in the form of a grammar
fragment that applies to lists of element information items. It
consists of a list of particles, i.e. element declarations,
wildcards and model groups. There are three varieties of model
group:
Sequence (the element information items match the
particles in sequential order);
Conjunction (the element information items match the
particles, in any order);
Disjunction (the element information items match
one or more
of the particles).
Each model group denotes a set of
sequences of element information items. Regarding that set of
sequences as a language, the set of sequences recognized by a
group
may be written
).
[Definition:]
A model group
is said to
accept
or
recognize
the members of
).
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
are themselves
Annotated Components
[Definition:]
basic term
is an
Element Declaration
or a
Wildcard
[Definition:]
basic
particle
is a
Particle
whose
{term}
is a
basic term
[Definition:]
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:
XSD
content models
are similar
to but more expressive than
[XML 1.1]
content models; unlike
[XML 1.1]
, XSD does not restrict the form of
content models
describing
mixed content.
Each content model, indeed each
particle and each term,
denotes a set of sequences of element information items. Regarding
that set of sequences as a language, the set of sequences recognized
by a particle
may be written
).
[Definition:]
A particle
is said to
accept
or
recognize
the members of
). Similarly, a term
accepts
or
recognizes
the members
of
).
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
) is locally valid against
. 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
is a member of
),
then it is necessarily possible to trace a path through the
basic particles
within
, with each item within
corresponding to a matching particle
within
. The sequence of particles within
corresponding to
is called the
path
of
in
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
in
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
used by a complex type definition is embedded within
an attribute use, which specifies whether the declaration
requires or merely allows its attribute, and whether it has a
default or fixed value.
2.2.3.4 Wildcard
A wildcard is a special kind of particle which matches element
and attribute information items dependent on their namespace
names and optionally on their local names.
For detailed information on wildcards, see
Wildcards (§3.10)
2.2.4 Constraint Components
This section describes constructs which
use
[XPath 2.0]
expressions to constrain the
input document; using them, certain rules can be expressed
conveniently which would be inconvenient or impossible to
express otherwise. Identity-constraint definitions are associated with
element declarations; assertions are associated with type
definitions; conditional type assignment using type alternatives
allows the type of an element instance to be chosen based on
properties of the element instance (in particular, based on the
values of its attributes).
2.2.4.1 Identity-constraint Definition
An identity-constraint definition is an association between a name
and one of several varieties of identity-constraint related to
uniqueness and reference. All the varieties use
[XPath 2.0]
expressions to pick out sets of information
items relative to particular target element information items
which are unique, or a key, or a
valid
reference, within a specified
scope. An element information item is only
valid
with respect to an element
declaration with identity-constraint definitions if those definitions
are all satisfied for all the descendants of that element
information item which they pick out.
For detailed information on identity-constraint definitions, see
Identity-constraint Definitions (§3.11)
Note:
In version 1.0 of this specification
[XSD 1.0 2E]
, identity constraints used
[XPath 1.0]
; they now use
[XPath 2.0]
2.2.4.2 Type Alternative
Type Alternative
component
(type alternative for short)
associates a type definition with a predicate.

Type alternatives are used in conditional
type assignment, in which the choice of
governing type definition
for elements governed by a particular element declaration
depends on properties of the document instance. An element
declaration may have a
{type table}
which contains a
sequence of type alternatives; the predicates on the alternatives
are tested, and when a predicate is satisfied, the type
definition paired with it is chosen as the element instance's
governing type definition
Note:
The provisions for conditional type assignment are inspired by,
but not identical to, those of
[SchemaPath]
For detailed information on Type Alternatives, see
Type Alternatives (§3.12)
2.2.4.3 Assertion
An assertion is a predicate associated with a type, which is
checked for each instance of the type. If an element or attribute information item
fails to satisfy an assertion associated with a given type,
then that information item is not locally
valid
with respect to that type.
For detailed information on Assertions, see
Assertions (§3.13)
2.2.4.4 Overlapping Functionality of Constraint Components
Many rules that can be enforced by identity constraints
and conditional type assignment can also be formulated
in terms of assertions. That is, the various constructs have
overlapping functionality.
The three forms of constraint differ from each other in various
ways which may affect the schema author's choice of formulation.
Most obviously, the
post-schema-validation infoset
will differ somewhat, depending
on which form of constraint is chosen.
Less obviously, identity constraints are associated with
element declarations, while assertions are associated with
type definitions. If it is desired to enforce a particular
property of uniqueness or referential integrity associated
with a particular element declaration
, of type
the schema author may often choose either an identity constraint
associated with
, or an assertion associated with
One obvious difference is that
elements substitutable for
are required to have types derived from
, but
are not required to enforce the identity constraints (or
the nillability) of
. If the constraint applicable to
should be enforced by elements substitutable for
, it
is often most convenient to formulate the constraint as
an assertion on
; conversely, if only some elements of
type
are intended to be subject to the constraint, or if
elements substitutable for
need not enforce the constraint, then it
will be more convenient to formulate the rule as an
identity constraint on
Similar considerations sometimes apply to the choice between
assertions and conditional type assignment.
Because identity constraints and conditional type assignment are
simpler and less variable than assertions, it may be easier
for software to exploit or optimize them. Assertions have
greater expressive power, which means they are often
convenient. The "rule of least power" applies here;
it is often preferable to use a less expressive notation in
preference to a more expressive one, when either will suffice.
See
[Rule of Least Power]
2.2.5 Group Definition Components
There are two kinds of convenience definitions provided to
enable the re-use of pieces of complex type definitions: model
group definitions and attribute group definitions.
2.2.5.1 Model Group Definition
A model group definition is an association between a name and
a model group, enabling re-use of the same model group in
several complex type definitions.
For detailed information on model group definitions, see
Model Group Definitions (§3.7)
2.2.5.2 Attribute Group Definition
An attribute group definition is an association between a
name and a set of attribute declarations, enabling re-use of
the same set in several complex type definitions.
For detailed information on attribute group definitions, see
Attribute Group Definitions (§3.6)
2.2.6 Annotation Components
An annotation is information for human and/or mechanical
consumers. The interpretation of such information is not defined
in this specification.
For detailed information on annotations, see
Annotations (§3.15)
2.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. They are located

in the sixth sub-section of the per-component
sections of
Schema Component Details (§3)
and tabulated in
Schema Component Constraints (§B.4)
Schema Representation Constraint
[Definition:]
Constraints on the representation of schema
components in XML beyond those which are expressed in
Schema for Schema Documents (Structures) (normative) (§A)
They are located
in the
third sub-section of the per-component sections of
Schema Component Details (§3)
and tabulated in
Schema Representation Constraints (§B.3)
Validation Rules
[Definition:]
Contributions to
validation
associated with schema
components. They are located

in the fourth sub-section of the
per-component sections of
Schema Component Details (§3)
and
tabulated in
Validation Rules (§B.1)
Schema Information Set Contribution
[Definition:]
Augmentations to
post-schema-validation infoset
s expressed by schema
components, which follow as a consequence of
assessment
They are 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 (§B.2)
The last of these, schema information set contributions, are
not as new as they might at first seem. XML validation augments the XML information set in similar
ways, for example by providing values for attributes not present
in instances, and by implicitly exploiting type information for
normalization or access. (As an example of the latter case,
consider the effect of
NMTOKENS
on attribute white
space, and the semantics of
ID
and
IDREF
.) By including schema information set
contributions, this specification makes explicit some features
that XML leaves implicit.
2.4 Conformance
Note:
Within the context of this
specification, conformance can be claimed for schema
documents, for schemas,
and for
processors.
schema document
conforms to this specification if and only if
all
of the following are true:
It is valid with respect to the
top-level element declaration for

in
the schema specified
in
Schema for Schema Documents (Structures) (normative) (§A)
That is,
when
assessed
using
element-driven validation
and stipulating the declaration for

, then
in its
post-schema-validation infoset
, the

element
has a
[validation attempted]
property with value
full
or
partial
and a
[validity]
property
with value
valid
No element in the schema document violates any of the
Schema Representation Constraints set out in
Schema Representation Constraints (§B.3)
unless that element has an

element as an ancestor.
Note:
Because elements within

do
not map to components, they are not required to
obey the Schema Representation Constraints.
If the schema document is invalid only
in consequence of invalid descendants of

elements, processors
may
treat the schema
document as valid. It is
implementation-defined
what effect, if any,
invalid

elements have on the
construction of schema components.
Note:
While conformance of schema documents is (with the exception just noted) a
precondition for the mapping from schema documents to schema
components described in this specification, conformance of the
schema documents does not guarantee that the result of that
mapping will be a schema that conforms to this specification.
Some constraints (e.g. the rule that there must be at most one
top-level element declaration with a particular
expanded name
can only be checked in the context of the schema as a whole.
Because component correctness
depends in part upon the other components present, the XML
mapping rules defined in this specification do not always map
conforming schema documents into components that satisfy all
constraints. In some cases, the mapping will produce components
which violate constraints imposed at the component level; in
others, no component at all will be produced.
Note:
In this version of this specification, Schema Representation
Constraints concern only properties of the schema document which
can be checked in isolation. In version 1.0 of this
specification, some Schema Representation Constraints could not
be checked against the schema document in isolation, and so it
was not always possible to say, for a given schema document,
whether it satisfied the constraints or not.
A schema conforms to this specification
if and only if it consists of components which individually and
collectively satisfy all the relevant constraints specified in
this document, including but not limited to all the
Schema Component Constraints
Note:
This specification defines no API or other interface
for interacting with schemas, so a conformance claim for
a schema is not normally testable in any standardized way.
However, if an interface is provided which enables a user
to interrogate various properties of the schema and check
their values, conformance can usefully be claimed for the
schema.
This specification distinguishes several
classes of conforming processors, which are defined in terms
of the following concepts.
[Definition:]
validator
(or
instance validator
) is a
processor which
validates
an XML instance document against a
conforming schema and distinguishes between valid documents
and others, for one or more of the definitions of validity
root-validity
deep validity
or
uniform validity
defined below in section
Schema-validity and documents (§2.5)
Conforming validators
may
additionally support other
definitions of validity defined in terms of the
post-schema-validation infoset
[Definition:]
schema-validity
assessor
(or just
assessor
is a processor which performs full or partial
schema-validity assessment
of an XML instance document,
element information item, or attribute information item,
with
reference to a conforming schema, and provides access to the
entirety of the resulting
post-schema-validation infoset
The means by which an
assessor
provides
access to the
post-schema-validation infoset
is
implementation-defined
[Definition:]
general-purpose
processor
is a
validator
or
assessor
which accepts schemas represented in the
form of XML documents as described in
Layer 2: Schema Documents, Namespaces and Composition (§4.2)
Note:
The
Schema Representation
Constraints
are to be enforced after, not
before, the
conditional-inclusion pre-processing
described in
Conditional inclusion (§4.2.2)
and the
chameleon pre-processing
described in
Assembling a schema for a single target namespace from
multiple schema definition documents

) (§4.2.3)
[Definition:]
schema processor which is not a
general-purpose
processor is a
special-purpose
processor.
Note:
By separating the conformance requirements relating to the
concrete syntax of
schema documents
, this specification
admits processors which use schemas stored in optimized binary
representations, dynamically created schemas represented as
programming language data structures, or implementations in
which particular schemas are compiled into executable code such
as C or Java. Such processors can be said
to conform to this
specification as
special-purpose
but not as
general-purpose
processors.
[Definition:]
Web-aware
processors are
network-enabled processors which are not only
general-purpose
but
which additionally
must
be capable of accessing schema
documents from the World Wide Web as described in
Representation of Schemas on the World Wide Web (§2.8)
and
How schema definitions are located on the Web (§4.3.2)
Note:
In version 1.0 of this specification the class of
general-purpose
processors
was termed
"conformant
to the XML Representation of Schemas". Similarly, the
class of
Web-aware
processors was
called "fully conforming".
Several important classes of processor
can be defined in terms of the concepts just given:
general-purpose validators
Validators
which accept arbitrary schemas expressed
in the form of sets of schema documents (i.e.,
are
general-purpose
); some
general-purpose validators may additionally be
Web-aware
general-purpose schema-validity assessors
Assessors
which accept arbitrary schemas expressed
in the form of sets of schema documents (i.e.,
are
general-purpose
); some
general-purpose assessors may additionally be
Web-aware
special-purpose validators
Validators
which do not accept arbitrary schemas expressed
in the form of sets of schema documents
Note:
Typically a special-purpose validator will either have a
built-in (hard-coded) schema, or else will accept arbitrary
schemas in some form other than schema documents.
other special-purpose tools
Processors (other than those otherwise defined) which
perform some task, service, or activity which depends at
least in part on the contents of some schema, and which
do so in ways which are consistent with the provisions of
this specification.
Note:
The class of
other
special-purpose tools
is not,
as defined here, a particularly informative description
of a piece of software. It is expected that other
specifications may wish to define processes depending
in part upon schemas, and to require that implementations
of those processes conform to this specification;
this conformance class provides a reference point for
such requirements, and for such claims of conformance.
A claim that a processor conforms to
this specification
must
specify to which processor classes
defined here the processor belongs.
Note:
Although this specification provides just these standard levels of
conformance, it is anticipated that other conventions can be
established in the future. There is no
need to modify or republish this specification to define such
additional levels of conformance.
See
Checklist of implementation-defined features (§E.1)
and
Terminology for implementation-defined features (normative) (§C)
for terminology and concepts which may be helpful in
defining the behavior of conforming processors and/or
claiming conformance to this specification.
2.5 Schema-validity and documents
As noted above, in general a document is
valid against
a particular schema
if it obeys the constraints imposed
by that schema. Depending on the nature of the application
and on the specific invariants to be enforced, different
forms of validity may be appropriately required by an
application, a specification, or other users of XSD.
This section defines terminology for use in describing the
requirements of applications or other technologies which use
XSD schema to describe constraints on XML documents.
Note:
Conformance to this specification cannot be claimed for XML
documents other than schema documents; this specification
imposes no requirements on documents, validity-related or
otherwise, and the terms defined in this section play
no role in conformance
to this specification. They are defined here for the
convenience of users of this specification who do wish to
impose specific requirements on documents.
The terms defined capture some commonly used requirements, but
the specification of which documents should be regarded as
acceptable for a specific application, or as conforming to a
given specification, is out of scope for this specification.
Applications and specifications which use XSD are free to
specify whatever constraints they see fit on documents; the
provision of terms for the concepts identified here should not
be taken to imply that other rules for document acceptability
are discouraged or inappropriate.
All the terms defined below require that the document's root
element be
assessed
using either
element-driven validation
(when the
intended root element of the schema is clearly specified ) or else
strict wildcard
validation
(if several different root elements are
acceptable).
root-valid document
A document is
root-valid
against a given
XSD schema if and only if after
assessment
the document's root
element has
[validity]
valid
and
[validation attempted]
full
or
partial
deep-valid document
A document is
deep-valid
against a given
XSD schema if and only if after
assessment
all
of the following are true:
The document's root element has
[validity]
valid
The document's root element has
[validation attempted]
full
or
partial
No element in the document has
[validity]
invalid
No attribute in the document has
[validity]
invalid
Note:
The second and third clauses are necessary to ensure that
invalid descendants of laxly validated elements are caught;
they do not cause their laxly validated ancestor to have
[validity]
invalid
uniformly valid document
A document is
uniformly valid
against a given
XSD schema if and only if after
assessment
all
of the following are true:
The document's root element has
[validity]
valid
The document's root element has
[validation attempted]
full
Note:
See
Assessment Outcome (Element) (§3.3.5.1)
for the definition
of the
[validation attempted]
property.)
It follows from the first and second clauses that every
element and attribute in the document has been
validated
and each of them is valid. (This distinguishes
uniform validity
from
deep validity
a deep-valid document may include elements and attributes
whose validity is
notKnown
, perhaps because they
are laxly
assessed
and no declarations were found for
them, or because they were
skipped
.)
Note:
The absence of error codes does not suffice to make a document
valid according to any of the definitions just given; the
[schema error code]
property will be empty (or
absent
) for any root element with
[validity]
notKnown
Validators which expose only the
[schema error code]
property and fail to distinguish in
their behavior between
[validity]
notKnown
and
[validity]
valid
can thus easily
mislead unwary users. A frequent cause of
[validity]
notKnown
is
the failure of the element information item to
match
any
declaration in the schema.
2.6 Names and Symbol Spaces
As discussed in
XSD Abstract Data Model (§2.2)
, most
schema components (
may
) 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

Within a given schema there are distinct symbol spaces
for each kind of named definition and declaration component identified
in
XSD Abstract Data Model (§2.2)
, except that
simple type definitions and complex type definitions share a
symbol space. Within a given symbol space, names
must
be unique;
as a consequence, each
expanded name
within a given
symbol space uniquely identifies a single component.
The same
expanded name
may
however appear in more than one symbol space without
conflict. For example, assuming that the namespace prefix
my
is bound to some particular namespace,
both a simple type definition and a top-level element declaration
can bear the name
my:abc
without conflict or
necessary relation between the two. But it is not possible
for both a simple type definition and a complex type
definition, or two distinct top-level element declarations,
to share the name
my:abc
Locally scoped attribute and element declarations are special
with regard to symbol spaces. Their names are not included
in the global symbol spaces for attribute and element names;
each complex type definition defines its own attribute symbol
space, and elements local to a complex type definition are
constrained by
Element Declarations Consistent (§3.8.6.3)
but not by means of symbol spaces. Their names
are not regarded as being in any particular symbol space.
So, for example, two
complex type definitions having the same target namespace can
contain a local attribute declaration for the unqualified name
"priority", or contain a local element declaration
for the name "address", without conflict or
necessary relation between the two.
2.7 Schema-Related Markup in Documents Being Validated
2.7.1
xsi:type
2.7.2
xsi:nil
2.7.3
xsi:schemaLocation, xsi:noNamespaceSchemaLocation
XML Schema Definition Language: Structures
defines
several attributes for direct use in any XML documents. These
attributes are in the schema instance namespace
) described in
The Schema Instance Namespace (
xsi
) (§1.3.1.2)
above. All schema processors
must
have appropriate attribute declarations for these attributes
built in, see
Attribute Declaration for the 'type' attribute (§3.2.7.1)
Attribute Declaration for the 'nil' attribute (§3.2.7.2)
Attribute Declaration for the 'schemaLocation' attribute (§3.2.7.3)
and
Attribute Declaration for the 'noNamespaceSchemaLocation' attribute (§3.2.7.4)
Note:
As described above (
Conventional Namespace Bindings (§1.3.3)
), the
attributes described in this section are referred to in this
specification as "
xsi:type
",
xsi:nil
", etc. This is shorthand for
"an attribute information item whose
[namespace
name]
is
and whose
[local
name]
is
type
" (or
nil
, etc.).
2.7.1 xsi:type
The
Simple Type Definition (§2.2.1.2)
or
Complex Type Definition (§2.2.1.3)
used in
validation
of an element is usually
determined by reference to the appropriate schema components. An
element information item in an instance
may
, however,
explicitly assert its type using the attribute
xsi:type
. The value of this attribute is a
QName
; see
QName resolution (Instance) (§3.17.6.3)
for the means by which the
QName
is associated with a type
definition.
2.7.2 xsi:nil
XML Schema Definition Language: Structures
introduces a mechanism for signaling that an element
must
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
can be
valid
without content if it has the attribute
xsi:nil
with the value
true
. An element so labeled
must
be empty, but can carry attributes if permitted by the
corresponding complex type.
2.7.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation
The
xsi:schemaLocation
and
xsi:noNamespaceSchemaLocation
attributes can be
used in a document to provide hints as to the physical location
of schema documents which can be used for
assessment
. See
How schema definitions are located on the Web (§4.3.2)
for details on the use of these
attributes.
Note:
The
xsi:schemaLocation
attribute typically appears
in XML document instances being
validated
; it is distinct from
the
schemaLocation
attribute defined for some
elements in schema documents (which is not always a hint
but sometimes a firm directive).
2.8 Representation of Schemas on the World Wide Web
On the World Wide Web, schemas are conventionally represented
as XML documents (preferably of MIME type
application/xml
or
text/xml
, but see
clause
1.1
of
Inclusion Constraints and Semantics (§4.2.3)
),
conforming to the specifications in
Layer 2: Schema Documents, Namespaces and Composition (§4.2)
. For
more information on the representation and use of schema
documents on the World Wide Web
see
Standards for representation of schemas and retrieval of schema documents on the Web (§4.3.1)
and
How schema definitions are located on the Web (§4.3.2)
3 Schema Component Details
3.1 Introduction
3.1.1
Components and Properties
3.1.2
XML Representations of Components
3.1.3
The Mapping between XML Representations and
Components
3.1.4
White Space Normalization during Validation
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
properties: their values and significance
XML representation and the mapping to properties
constraints on representation
validation rules
post-schema-validation infoset
contributions
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
may
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, decimal) 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
must not
exist, so in some cases re-entrant
chains of properties will exist.
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
property record
[Definition:]
Throughout this
specification, the term
absent
is used as a
distinguished property value denoting absence
. Again this should not be

interpreted as
constraining implementations, as for instance between using a
null
value for such properties or not representing
them at all.
[Definition:]
A property value
which is not
absent
is
present
Any property not 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 might 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
might 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 Schema Definition Language: Structures
is to define a set of schema
components that constrain the contents of instances and augment
the information sets thereof. Although no external
representation of schemas is required for this purpose, such
representations will obviously be widely used. To provide for
this in an appropriate and interoperable way, this specification
provides a normative XML representation for schemas which makes
provision for every kind of schema component.
[Definition:]
A document in this
form (i.e. a

element information item)
is a
schema document
. For the schema
document as a whole, and its constituents, the sections below
define correspondences between element information items (with
declarations in
Schema for Schema Documents (Structures) (normative) (§A)
and
DTD for Schemas (non-normative) (§I)
) and schema components. The key element information items in
the XML representation of a schema are in the XSD namespace, that
is their
[namespace
name]
is
. Although a common way of creating
the XML Infosets which are or contain
schema documents
will be
using an XML parser, this is not required: any mechanism which
constructs conformant infosets as defined in
[XML Infoset]
is a possible starting
point.
Two aspects of the XML representations of components presented
in the following sections are constant across them all:
All of them allow attributes qualified with namespace names
other than the XSD namespace itself: these appear as
annotations in the corresponding schema component;
All of them allow an

as their
first child, for human-readable documentation and/or
machine-targeted information.
A recurrent pattern in the XML
representation of schemas may also be mentioned here. In many
cases, the same element name (e.g.
element
or
attribute
or
attributeGroup
), serves
both to define a particular schema component and to incorporate
it by reference. In the first case the
name
attribute is required, in the second the
ref
attribute is required. These
two usages are mutually exclusive, and sometimes also depend on
context.
The descriptions of the XML representation
of components, and the
Schema Representation
Constraints
, apply to schema documents
after
not before, the
conditional-inclusion pre-processing
described in
Conditional inclusion (§4.2.2)
and the
chameleon pre-processing
described in
Assembling a schema for a single target namespace from
multiple schema definition documents

) (§4.2.3)
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
expressed in the
Schema for Schema Documents (Structures) (normative) (§A)
Neither the correspondences
described nor the XML Representation Constraints apply to
elements in the Schema namespace which occur as descendants
of

or

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 Schema Documents (Structures) (normative) (§A)
, there is always a simple type
definition associated with any such attribute information item.
[Definition:]
With reference to any
string, interpreted as denoting
an instance of a given datatype, the term
actual value
denotes the value to which the
lexical mapping
of that datatype maps the string.
In the case of attributes in
schema documents, the string used as the
lexical representation is normally the
normalized value
of the
attribute. The associated datatype is, unless otherwise specified,
the one identified in the declaration of the attribute, in the
schema for schema documents; in some cases (e.g. the
enumeration
facet, or fixed and default values
for elements and attributes) the associated datatype will
be a more specific one,
as specified in the appropriate
XML mapping rules. The
actual value
will often be a string, but can 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
assessed
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 will in some
cases be violated if one or more references cannot be
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
will 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 most
validation
purposes.
For the exception to this rule, see the
discussion of comments and processing instructions in
Assertion Satisfied (§3.13.4.1)
[Definition:]
The
normalized value
of an element or attribute
information item is an
initial value
which has been normalized
according to the value of the
whiteSpace facet
, and the values of any other
pre-lexical facets
, associated with the simple type definition used
in its
validation
. The keywords for
whitespace normalization have the following meanings:
preserve
No normalization is done, the
whitespace-normalized value
is the
initial value
replace
All occurrences of
#x9
(tab),
#xA
(line feed) and
#xD
(carriage
return) are replaced with
#x20
(space).
collapse
Subsequent to the replacements specified above under
replace
, contiguous sequences of
#x20
s are collapsed to a single
#x20
, and initial and/or final
#x20
s are deleted.
Similarly, the
normalized value
of any string with respect to a
given simple type definition is the string resulting from
normalization using the
whiteSpace facet
and any other
pre-lexical facets
, associated with that simple type definition.
When more than one
pre-lexical facet
applies, the
whiteSpace facet
is applied first; the order in which
implementation-defined
facets
are applied is
implementation-defined
If the simple type definition used in an item's
validation
is
xs:anySimpleType
then the
normalized value
must
be determined
as in the
preserve
case above.
There are three alternative validation rules which help supply the necessary background for the
above:
Attribute Locally Valid (§3.2.4.1)
(clause
),
Element Locally Valid (Type) (§3.3.4.4)
(clause
3.1.3
) or
Element Locally Valid (Complex Type) (§3.4.4.2)
(clause
1.2
).
These three levels of normalization correspond to the processing mandated
in XML 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
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, it
is possible that
further
normalization will
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.
3.2 Attribute Declarations
3.2.1
The Attribute Declaration Schema Component
3.2.2
XML Representation of Attribute Declaration Schema Components
3.2.2.1
Mapping Rules for Global Attribute Declarations
3.2.2.2
Mapping Rules for Local Attribute Declarations
3.2.2.3
Mapping Rules for References to Top-level Attribute Declarations
3.2.3
Constraints on XML Representations of Attribute Declarations
3.2.4
Attribute Declaration Validation Rules
3.2.4.1
Attribute Locally Valid
3.2.4.2
Governing Attribute Declaration and Governing Type Definition
3.2.4.3
Schema-Validity Assessment (Attribute)
3.2.5
Attribute Declaration Information Set Contributions
3.2.5.1
Assessment Outcome (Attribute)
3.2.5.2
Validation Failure (Attribute)
3.2.5.3
Attribute Declaration
3.2.5.4
Attribute Validated by Type
3.2.6
Constraints on Attribute Declaration Schema Components
3.2.6.1
Attribute Declaration Properties Correct
3.2.6.2
Simple Default Valid
3.2.6.3
xmlns Not Allowed
3.2.6.4
xsi: Not Allowed
3.2.7
Built-in Attribute Declarations
3.2.7.1
xsi:type
3.2.7.2
xsi:nil
3.2.7.3
xsi:schemaLocation
3.2.7.4
xsi:noNamespaceSchemaLocation
Attribute declarations provide for:
Local
validation
of attribute information item values using a simple type definition;
Specifying default or fixed values for attribute information items.
Example

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:
Attribute Declaration
, 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}
Simple Type Definition
component. Required.
{scope}
Scope
property record. Required.
{value constraint}
Value Constraint
property record. Optional.
{inheritable}
An xs:boolean value. Required.
Property Record:
Scope
{variety}
One of {
global
local
}. Required.
{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 each attribute validated
must
conform to the supplied
{type definition}
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.
For an attribute declaration
, if
{scope}
{variety}
global
, then
is available for use throughout the schema.
If
{scope}
{variety}
local
, then
is available for use only within (the
Complex Type Definition
or
Attribute Group Definition
{scope}
{parent}
The
{value constraint}
property reproduces the functions of
XML default and
#FIXED
attribute values. A
{variety}
of
default
specifies that the attribute is to
appear unconditionally in the
post-schema-validation infoset
, with
{value}
and
{lexical form}
used whenever the attribute is not
actually present;
fixed
indicates that the attribute
value if present
must
be equal or identical
to
{value}
, and if absent receives
{value}
and
{lexical form}
as for
default
. Note that
it is
values
that are checked, not
strings,
and that the test is for either equality or identity.
See
Annotations (§3.15)
for information on the role of the
{annotations}
property.
Note:
A more complete and formal presentation of the semantics of
{name}
{target namespace}
and
{value constraint}
is provided in
conjunction with other aspects of complex type
validation
(see
Element Locally Valid (Complex Type) (§3.4.4.2)
.)
[XML Infoset]
distinguishes attributes with names such as
xmlns
or
xmlns:xsl
from
ordinary attributes, identifying them as
[namespace attributes]
. Accordingly, it is unnecessary and in fact not possible for
schemas to contain attribute declarations corresponding to such
namespace declarations, see
xmlns
Not Allowed (§3.2.6.3)
. No means is provided in
this specification to supply a
default value for a namespace declaration.
3.2.2 XML Representation of Attribute Declaration Schema Components
The XML representation for an attribute declaration schema
component is an

element information item. It specifies a
simple type definition for an attribute either by reference or
explicitly, and
may
provide default information. The
correspondences between the properties of the information item
after the appropriate
pre-processing
and the
properties of the component are given in this section.
Attribute declarations can appear at the top level of a schema
document, or within complex type definitions, either as complete
(local) declarations, or by reference to top-level declarations,
or within attribute group definitions. For complete
declarations, top-level or local, the
type
attribute is used when the declaration can use a built-in or
pre-declared simple type definition. Otherwise an anonymous

is provided inline. When no simple type definition is
referenced or provided, the default is
xs:anySimpleType
, which
imposes no constraints at all.
XML Representation Summary
attribute
Element Information Item
default =
string
fixed =
string
form = (
qualified
unqualified
id =
ID
name =
NCName
ref =
QName
targetNamespace =
anyURI
type =
QName
use = (
optional
prohibited
required
) : optional
inheritable =
boolean
{any attributes with non-schema namespace . . .}
Content:
annotation
?,
simpleType
?)

An

element
maps to an attribute declaration, and
allows the type definition of that declaration to be specified either by
reference or by explicit inclusion.
Top-level

elements
(i.e. those which appear
within the schema document as
children of

elements) produce
global
attribute declarations;

within

or

produce
either attribute uses which contain
global
attribute
declarations (if there's a
ref
attribute) or local
declarations (otherwise). For complete declarations, top-level or local,
the
type
attribute is used when the declaration can use a
built-in or user-defined global type definition. Otherwise an anonymous

is provided inline.
Note:
Children of

are not strictly speaking top-level
declarations, but they will become top-level declarations if they
override corresponding declarations in the
target set
of their parent. See
Overriding component definitions (

) (§4.2.5)
for details.
Attribute information items
validated
by a top-level
declaration
must
be qualified with the
{target namespace}
of that
declaration. 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

, via its determination of
{target namespace}
The names for top-level attribute declarations are in their
own
symbol space
. The
names of locally-scoped attribute declarations reside in symbol
spaces local to the type definition which contains them.
The following sections specify several
sets of XML mapping rules which apply in different
circumstances.
If the

element information item
has

as its parent, then it maps to
global
Attribute Declaration
as described in
Mapping Rules for Global Attribute Declarations (§3.2.2.1)
If the

element
information item has

or

as an ancestor, and the
ref
[attribute]
is
absent, and the
use
[attribute]
is not
"prohibited"
, then it maps both to
an
Attribute Declaration
and to an
Attribute Use
component, as described in
Mapping Rules for Local Attribute Declarations (§3.2.2.2)
On
Attribute Use
components, see
Attribute Uses (§3.5)
If the

element
information item has

or

as an ancestor, and the
ref
[attribute]
is
present
, and the
use
[attribute]
is not
"prohibited"
, then it maps to
an
Attribute Use
component, as described in
Mapping Rules for References to Top-level Attribute Declarations (§3.2.2.3)
If the

element information item
has
use='prohibited'
, then it does not map to,
or correspond to, any schema component at all.
Note:
The
use
attribute is not allowed on
top-level

elements, so
this can only happen with

elements
appearing within a

or

element.
3.2.2.1 Mapping Rules for Global Attribute Declarations
If the

element information item has

as its parent, the corresponding schema
component is as follows:
XML Mapping Summary for
Attribute Declaration
Schema Component
Property
Representation
{name}
The
actual value
of the
name
[attribute]
{target namespace}
The
actual value
of the
targetNamespace
[attribute]
of the parent

element information item, or
absent
if there is none.
{type definition}
The simple type
definition corresponding to the

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
xs:anySimpleType
{scope}
Scope
as follows:
Property
Value
{variety}
global
{parent}
absent
{value constraint}
If there is a
default
or a
fixed
[attribute]
then a
Value Constraint
as follows, otherwise
absent
Property
Value
{variety}
either
default
or
fixed
, as appropriate
{value}
the
actual value
(with respect
to the
{type definition}
) of the
[attribute]
{lexical form}
the
normalized value
(with respect to the
{type definition}
) of the
[attribute]
{inheritable}
The
actual value
of the
inheritable
[attribute]
, if present, otherwise
false
{annotations}
The
annotation mapping
of the

element, as defined in
XML Representation of Annotation Schema Components (§3.15.2)
3.2.2.2 Mapping Rules for Local Attribute Declarations
If
the

element information item has

or

as
an ancestor and the
ref
[attribute]
is absent,
it maps both to an attribute
declaration (see
below
) and
to an attribute use with properties as follows
(unless
use='prohibited'
, in which case the item
corresponds to nothing at all):
XML Mapping Summary for
Attribute Use
Schema Component
Property
Representation
{required}
true
if
the

element has
use
required
, otherwise
false
{attribute declaration}
See the Attribute Declaration mapping
immediately below.
{value constraint}
If there is a
default
or a
fixed
[attribute]
then a
Value Constraint
as follows, otherwise
absent
Property
Value
{variety}
either
default
or
fixed
, as appropriate
{value}
the
actual value
of
the
[attribute]
(with respect to
{attribute declaration}
{type definition}
{lexical form}
the
normalized value
of the
[attribute]
(with respect to
{attribute declaration}
{type definition}
{inheritable}
The
actual value
of the
inheritable
[attribute]
, if present, otherwise
false
{annotations}
The same annotations as the
{annotations}
of
the Attribute Declaration. See below.
The

element also
maps to the
{attribute declaration}
of the attribute use, as follows:
XML Mapping Summary for
Attribute Declaration
Schema Component
Property
Representation
{name}
The
actual value
of the
name
[attribute]
{target namespace}
The appropriate
case
among the following:
If
targetNamespace
is present
then
its
actual value
If
targetNamespace
is not present and
one
of the following is true
2.1
form
qualified
2.2
form
is absent and the

ancestor has
attributeFormDefault
qualified
then
the
actual value
of the
targetNamespace
[attribute]
of the ancestor

element information
item, or
absent
if there
is none.
otherwise
absent
{type definition}
The simple type
definition corresponding to the

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
xs:anySimpleType
{scope}
Scope
as follows:
Property
Value
{variety}
local
{parent}
If the

element information item has

as an ancestor, the
Complex Type Definition
corresponding to that item, otherwise (the

element information item is within an

element information
item), the
Attribute Group Definition
corresponding to
that item.
{value constraint}
absent
{inheritable}
The
actual value
of the
inheritable
[attribute]
, if present, otherwise
false
{annotations}
The
annotation mapping
of the

element, as defined in
XML Representation of Annotation Schema Components (§3.15.2)
3.2.2.3 Mapping Rules for References to Top-level Attribute Declarations
If
the

element information item has

or

as an
ancestor and the
ref
[attribute]
is
present, it
maps to an attribute use with properties as follows
(unless
use='prohibited'
, in which case the item
corresponds to nothing at all):
XML Mapping Summary for
Attribute Use
Schema Component
Property
Representation
{required}
true
if
use
required
, otherwise
false
{attribute declaration}
The (top-level)
attribute declaration
resolved
to by the
actual value
of
the
ref
[attribute]
{value constraint}
If there is a
default
or a
fixed
[attribute]
then a
Value Constraint
as follows, otherwise
absent
Property
Value
{variety}
either
default
or
fixed
, as appropriate
{value}
the
actual value
of
the
[attribute]
(with respect to
{attribute declaration}
{type definition}
{lexical form}
the
normalized value
of the
[attribute]
(with respect to
{attribute declaration}
{type definition}
{inheritable}
The
actual value
of the
inheritable
[attribute]
, if present, otherwise
{attribute declaration}
{inheritable}
{annotations}
The
annotation mapping
of
the

element, as defined in
XML Representation of Annotation Schema Components (§3.15.2)
3.2.3 Constraints on XML Representations of Attribute Declarations
Schema Representation Constraint: Attribute Declaration Representation OK
In addition to the conditions imposed on

element
information items by the schema for schema documents,
all
of the following also apply:
default
and
fixed
must not
both be present.
If
default
and
use
are both present,
use
must
have the
actual value
optional
If the item's parent is not

, then
all
of the following
must
be true:
3.1
One of
ref
or
name
is present, but not both.
3.2
If
ref
is present, then all of

form
and
type
are absent.
The
type
attribute and a

child element
must not
both be present.
If
fixed
and
use
are both present,
use
must not
have the
actual value
prohibited
If the
targetNamespace
attribute
is present then
all
of the following
must
be true:
6.1
The
name
attribute
is present.
6.2
The
form
attribute
is absent.
6.3
If the ancestor

does not have a
targetNamespace
[attribute]
or its
actual value
is different from the
actual value
of
targetNamespace
of

, then
all
of the following are true:
6.3.1

has

as an ancestor
6.3.2
There is a

ancestor
between the

and the nearest

ancestor, and the
actual value
of the
base
[attribute]
of

does not
match
the
name of
xs:anyType
3.2.4 Attribute Declaration Validation Rules
3.2.4.1 Attribute Locally Valid
Informally, an attribute in an XML
instance is locally
valid
against an attribute declaration if and only if (a)
the name of the attribute matches
the name of the declaration, (b) after
whitespace normalization its
normalized value
is locally valid
against the type declared for the attribute, and
(c) the
attribute obeys any relevant value constraint. Additionally,
for
xsi:type
, it is required that the type named
by the attribute be present in the schema.
A logical prerequisite for checking the local validity of an
attribute against an attribute declaration is that the attribute
declaration itself and the type definition it identifies
both be present in the schema.
Local validity of attributes is
tested as part of schema-validity
assessment
of attributes
(and of the elements on which they occur), and the result
of the test is exposed in the
[validity]
property of the
post-schema-validation infoset
A more formal statement
is given in the following constraint.
Validation Rule: Attribute Locally Valid
For an attribute information item
to be locally
valid
with respect to an attribute declaration
all
of the following
must
be true:
is not
absent
(see
Missing Sub-components (§5.3)
for
how this can fail to be the case)
and
and
have the same
expanded name
{type definition}
is not
absent
's
initial value
is locally
valid
with respect to
{type definition}
as per
String Valid (§3.16.4)
If
{value constraint}
is present and
{value constraint}
{variety}
fixed
, then
's
actual value
is equal or
identical to
{value constraint}
{value}
If
is the built-in declaration for
xsi:type
Attribute Declaration for the 'type' attribute (§3.2.7.1)
), then
's
actual value
resolves
to a type definition.
3.2.4.2 Governing Attribute Declaration and Governing Type Definition
[Definition:]
In a given schema-validity
assessment
episode,
the
governing
declaration of an attribute
(its
governing attribute declaration
is the first of
the following which applies:
A declaration which was stipulated by the processor (see
Assessing Schema-Validity (§5.2)
).
Its
context-determined declaration
A declaration
resolved
to by its
[local
name]
and
[namespace
name]
provided the attribute
is not
skipped
and the processor has not
stipulated a type definition at the start of
assessment
If none of these applies, the attribute
has no
governing attribute declaration
(or, in equivalent words, the
governing attribute declaration
is
absent
).
Note:
As a consequence, unless
skipped
or stipulated otherwise, attributes
named
xsi:type
xsi:nil
xsi:schemaLocation
, or
xsi:noNamespaceSchemaLocation
are always governed by
their corresponding built-in declarations (see
Built-in Attribute Declarations (§3.2.7)
).
[Definition:]
The
governing type definition
of an
attribute, in a given schema-validity
assessment
episode, is
the first of the following which applies:
A type definition stipulated by the processor (see
Assessing Schema-Validity (§5.2)
).
The
{type definition}
of the
governing attribute declaration
If neither of these applies, there is no
governing type definition
(or, in equivalent words, it is
absent
).
3.2.4.3 Schema-Validity Assessment (Attribute)
Schema-validity assessment of an attribute information item
involves identifying its
governing attribute declaration
and checking its
local validity against the declaration. If the
governing type definition
is not present in the schema, then assessment is necessarily
incomplete.
Validation Rule: Schema-Validity Assessment (Attribute)
The schema-validity assessment of an attribute information item depends
on its local
validation
alone.
For an attribute information item's schema-validity to have been assessed
all
of the following
must
be true:
non-absent
attribute declaration
is known for it, namely its
governing
declaration.
Its local
validity
with respect to that
declaration
has
been evaluated as per
Attribute Locally Valid (§3.2.4.1)
Both clause
and clause
of
Attribute Locally Valid (§3.2.4.1)
are satisfied.
[Definition:]
For
attribute information items,
there is no difference between assessment and strict
assessment, so
the attribute information item has
been
strictly assessed
if and only if its schema-validity has been assessed.
3.2.5 Attribute Declaration Information Set Contributions
3.2.5.1 Assessment Outcome (Attribute)
Schema Information Set Contribution: Assessment Outcome (Attribute)
If the schema-validity of an attribute information item has been assessed
as per
Schema-Validity Assessment (Attribute) (§3.2.4.3)
, then in the
post-schema-validation infoset
it
has properties as follows:
PSVI Contributions for
attribute information items
[validation context]
The nearest ancestor element
information item with a
[schema information]
property.
[validity]
The appropriate
case
among the following:
If
it was
strictly assessed
then
the appropriate
case
among the following:
1.1
If
it was locally
valid
as defined by
Attribute Locally Valid (§3.2.4.1)
then
valid
1.2
otherwise
invalid
otherwise
notKnown
[validation attempted]
The appropriate
case
among the following:
If
it was
strictly assessed
then
full
otherwise
none
[schema specified]
infoset
. See
Attribute Default Value (§3.4.5.1)
for the other possible value.
3.2.5.2 Validation Failure (Attribute)
Schema Information Set Contribution: Validation Failure (Attribute)
If and only if the local
validity
, as defined
by
Attribute Locally Valid (§3.2.4.1)
above, of an attribute information item has been assessed,
then in the
post-schema-validation infoset
the item
has a property:
PSVI Contributions for
attribute information items
[schema error code]
The appropriate
case
among the following:
If
the item is
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) (§B)
) herein.
otherwise
absent
3.2.5.3 Attribute Declaration
Schema Information Set Contribution: Attribute Declaration
If and only if a
governing
declaration is known for an attribute information
item
then in the
post-schema-validation infoset
the attribute information item
has a
property:
PSVI Contributions for
attribute information items
[attribute declaration]
An
item isomorphic
to the
governing
declaration component itself.
[schema default]
If the attribute information item is
attributed
to an
Attribute Use
then the
{lexical form}
of the
effective value constraint
otherwise the
{lexical form}
of the
declaration's
{value constraint}
3.2.5.4 Attribute Validated by Type
Schema Information Set Contribution: Attribute Validated by Type
If and
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 the
properties:
PSVI Contributions for
attribute information items
[schema normalized value]
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]
An
item isomorphic
to
the
governing type definition
component.
[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 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
Note:
The
[type definition type]
[type definition namespace]
[type definition name]
, and
[type definition anonymous]
properties
are redundant with the
[type definition]
property;
they are defined for the convenience of implementations
which wish to expose those specific properties
but not the entire type definition.
If
the attribute's
initial value
is
valid
with respect to
the
governing type definition
as defined by
String Valid (§3.16.4)
and
the
governing type definition
has
{variety}
union
, then there are four additional properties:
PSVI Contributions for
attribute information items
[member type definition]
an
item isomorphic
to
the
validating type
of the
[schema actual value]
[member type definition namespace]
The
{target namespace}
of the
validating type
[member type definition anonymous]
true
if the
{name}
of the
validating type
is
absent
otherwise
false
[member type definition name]
The
{name}
of the
validating type
, if it is not
absent
. If it is
absent
, schema processors
may
, but need
not, provide a value unique to the definition.
It is
implementation-defined
whether a processor provides a name
for such a type definition. If a processor does provide a value in this
situation, the choice of what value to use is
implementation-dependent
The first (
item isomorphic
alternative
above is provided for applications such as query
processors which need access to the full range of details about an
item's
assessment
, for example the
type hierarchy; the second, for lighter-weight processors for whom
representing the significant parts of the type hierarchy as
information items might be a significant burden.
If
all
of the following are true:
the attribute's
normalized value
is
valid
with respect to the
governing type definition
One
of the following is true:
2.1
the
governing type definition
has
{variety}
list
2.2
the
governing type definition
has
{variety}
union
and the
validating type
of the
[schema actual value]
has
{variety}
list
the
{item type definition}
of the list type
(from the previous clause) has
{variety}
union
then there is an additional property:
PSVI Contributions for
attribute information items
[member type definitions]
a sequence of
Simple Type Definition
components, with the same length as the
[schema actual value]
, each one an
item isomorphic
to the
validating type
of the corresponding

item in the
[schema actual value]
See also
Attribute Default Value (§3.4.5.1)
Match Information (§3.4.5.2)
and
Schema Information (§3.17.5.1)
which describe
other information set contributions related to attribute information items.
3.2.6 Constraints on Attribute Declaration Schema Components
All attribute declarations (see
Attribute Declarations (§3.2)
must
satisfy the following constraints.
3.2.6.1 Attribute Declaration Properties Correct
Schema Component Constraint: Attribute Declaration Properties Correct
All
of the following
must
be true:
The values of the properties of an attribute declaration are as described in
the property tableau in
The Attribute Declaration Schema Component (§3.2.1)
, modulo the impact
of
Missing Sub-components (§5.3)
if there is a
{value constraint}
, then
it is a valid default with respect
to the
{type definition}
as
defined in
Simple Default Valid (§3.2.6.2)
Note:
The use of
ID
and related
types together with value constraints goes beyond what is possible with
XML DTDs, and
should
be avoided if compatibility with DTDs is desired.
3.2.6.2 Simple Default Valid
Schema Component Constraint: Simple Default Valid
For a
Value Constraint
to be
a valid default with respect to a
Simple Type Definition
all
of the following
must
be true:
{lexical form}
is
valid
with
respect to
as defined by
Datatype
Valid
in
[XML Schema: Datatypes]
{lexical form}
maps to
{value}
in the
value space of
3.2.6.3
xmlns
Not Allowed
Schema Component Constraint:
xmlns
Not Allowed
The
{name}
of an attribute declaration
must not
match
xmlns
Note:
The
{name}
of an attribute is an
NCName
, which implicitly
prohibits attribute declarations of the form
xmlns:*
3.2.6.4
xsi:
Not Allowed
Schema Component Constraint:
xsi:
Not Allowed
The
{target namespace}
of an attribute declaration,
whether local or top-level,
must not
match
(unless it is one of the four built-in declarations given in the next section).
Note:
This reinforces the special status of these attributes, so that they not
only
need
not be declared to be allowed in instances, but
in consequence of the rule just given
must not
be declared.
Note:
It is legal for
Attribute Use
s 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

),
but the practice is not recommended; including such attribute uses will tend
to mislead readers of the schema document, because the attribute uses would
have no effect; see
Element Locally Valid (Complex Type) (§3.4.4.2)
and
Attribute Default Value (§3.4.5.1)
for details.
3.2.7 Built-in Attribute Declarations
There are four attribute declarations present in every
schema by definition:
3.2.7.1
xsi:type
The
xsi:type
attribute
is used to signal use of a type other than the declared type of
an element. See
xsi:type (§2.7.1)
Attribute Declaration for the 'type' attribute
Property
Value
{name}
type
{target namespace}
{type definition}
The built-in
QName
simple
type definition
{scope}
Scope
as follows:
Property
Value
{variety}
global
{parent}
absent
{value constraint}
absent
{annotations}
the empty sequence
3.2.7.2
xsi:nil
The
xsi:nil
attribute
is used to signal that an element's content is "nil"
(or "null"). See
xsi:nil (§2.7.2)
Attribute Declaration for the 'nil' attribute
Property
Value
{name}
nil
{target namespace}
{type definition}
The built-in
boolean
simple
type definition
{scope}
Scope
as follows:
Property
Value
{variety}
global
{parent}
absent
{value constraint}
absent
{annotations}
the empty sequence
3.2.7.3
xsi:schemaLocation
The
xsi:schemaLocation
attribute
is used to signal possible locations of relevant schema documents.
See
xsi:schemaLocation, xsi:noNamespaceSchemaLocation (§2.7.3)
Attribute Declaration for the 'schemaLocation' attribute
Property
Value
{name}
schemaLocation
{target namespace}
{type definition}
An anonymous simple type definition, as follows:
Property
Value
{name}
absent
{target namespace}
{base type definition}
The built in
xs:anySimpleType
{facets}
absent
{variety}
list
{item type definition}
The built-in
anyURI
simple
type definition
{annotations}
the empty sequence
{scope}
Scope
as follows:
Property
Value
{variety}
global
{parent}
absent
{value constraint}
absent
{annotations}
the empty sequence
3.2.7.4
xsi:noNamespaceSchemaLocation
The
xsi:noNamespaceSchemaLocation
attribute
is used to signal possible locations of relevant schema documents.
See
xsi:schemaLocation, xsi:noNamespaceSchemaLocation (§2.7.3)
Attribute Declaration for the 'noNamespaceSchemaLocation' attribute
Property
Value
{name}
noNamespaceSchemaLocation
{target namespace}
{type definition}
The built-in
anyURI
simple
type definition
{scope}
Scope
as follows:
Property
Value
{variety}
global
{parent}
absent
{value constraint}
absent
{annotations}
the empty sequence
3.3 Element Declarations
3.3.1
The Element Declaration Schema Component
3.3.2
XML Representation of Element Declaration Schema Components
3.3.2.1
Common Mapping Rules for Element Declarations
3.3.2.2
Mapping Rules for Top-Level Element Declarations
3.3.2.3
Mapping Rules for Local Element Declarations
3.3.2.4
References to Top-Level Element Declarations
3.3.2.5
Examples of Element Declarations
3.3.3
Constraints on XML Representations of Element Declarations
3.3.4
Element Declaration Validation Rules
3.3.4.1
Selected and Instance-specified Type Definitions
3.3.4.2
Type Override and Valid Substitutability
3.3.4.3
Element Locally Valid (Element)
3.3.4.4
Element Locally Valid (Type)
3.3.4.5
Validation Root Valid (ID/IDREF)
3.3.4.6
Schema-Validity Assessment (Element)
3.3.5
Element Declaration Information Set Contributions
3.3.5.1
Assessment Outcome (Element)
3.3.5.2
Validation Failure (Element)
3.3.5.3
Element Declaration
3.3.5.4
Element Validated by Type
3.3.5.5
Element Default Value
3.3.5.6
Inherited Attributes
3.3.6
Constraints on Element Declaration Schema Components
3.3.6.1
Element Declaration Properties Correct
3.3.6.2
Element Default Valid (Immediate)
3.3.6.3
Substitution Group OK (Transitive)
3.3.6.4
Substitution Group
Element declarations provide for:
Local
validation
of element information item values using a type definition;
Specifying default or fixed values for 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

XML representations of several different types of element declaration
3.3.1 The Element Declaration Schema Component
The element declaration schema component has the following
properties:
Schema Component:
, a kind of
Term
{annotations}
A sequence of
Annotation
components.
{name}
An xs:NCName value. Required.
{target namespace}
An xs:anyURI value. Optional.
{type definition}
Type Definition
component. Required.
{type table}
Type Table
property record. Optional.
{scope}
Scope
property record. Required.
{value constraint}
Value Constraint
property record. Optional.
{nillable}
An xs:boolean value. Required.
{identity-constraint definitions}
A set of
Identity-Constraint Definition
components.
{substitution group affiliations}
A set of
Element Declaration
components.
{substitution group exclusions}
A subset of {
extension
restriction
}.
{disallowed substitutions}
A subset of {
substitution
extension
restriction
}.
{abstract}
An xs:boolean value. Required.
Property Record:
Type Table
{alternatives}
A sequence of
Type Alternative
components.
{default type definition}
Type Alternative
component. Required.
Property Record:
Scope
{variety}
One of {
global
local
}. Required.
{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
For an element declaration
, if
{scope}
{variety}
global
, then
is available for use throughout the schema.
If
{scope}
{variety}
local
, then
is available for use only within (the
Complex Type Definition
or
Model Group Definition
{scope}
{parent}
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 normally
required to satisfy the
{type definition}
. For such an
item, schema information set
contributions appropriate to the
{type definition}
are added to the
corresponding element information
item in the
post-schema-validation infoset
. The type
definition against which an element information item is
validated (its
governing type definition
) can be different from the
declared
{type definition}
. The
{type table}
property of an
Element Declaration
, which governs conditional type assignment, and
the
xsi:type
attribute of an element information item
(see
xsi:type (§2.7.1)
) can cause the
governing type definition
and the
declared
{type definition}
to be different.
If
{nillable}
is
true
, then
an element with no text or element
content can be
valid
despite a
{type definition}
which would otherwise require
content, if it carries the
attribute
xsi:nil
with the value
true
(see
xsi:nil (§2.7.2)
).
Formal details of element
validation
are described in
Element Locally Valid (Element) (§3.3.4.3)
[Definition:]
An
element information item
is
nilled
with respect to some element declaration
if and only if
all
of the following are true:
has
xsi:nil
true
{nillable}
true
If
is said to be
nilled
without the
identity of
being clear from the context, then
is assumed to
be
's
governing element declaration
{value constraint}
establishes a
default or fixed value for an element. If a
{value constraint}
with
{variety}
default
is present, and if the element being
validated
is
empty, then for
purposes of calculating the
[schema normalized value]
and other contributions to the
post-schema-validation infoset
the element is
treated as if
{value constraint}
{lexical form}
was
used as the content of the element. If
fixed
is specified, then the element's content
must
either be empty,
in which case
fixed
behaves as
default
, or its
value
must
be equal or identical to
{value constraint}
{value}
Note:
When a default value is supplied and used, as described in
the second sentence of the preceding paragraph, the default
value is used to calculate the
[schema normalized value]
, etc.,
but the actual content of the element is not changed: the
element contained no character information items in the input
information set, and it contains none in the PSVI.
Note:
The provision of defaults for elements goes beyond what is
possible in XML 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)
The
{substitution group affiliations}
property of an element declaration indicates
which
substitution groups
, if any, it can potentially be a member of.
Potential membership is transitive but not
symmetric; an element declaration is a potential member of any
group named in its
{substitution group affiliations}
, and
also of any group of which any entry
in its
{substitution group affiliations}
is a potential member. Actual
membership
may
be blocked by the effects of
{substitution group exclusions}
or
{disallowed substitutions}
, see below.
An empty
{substitution group exclusions}
allows a declaration to be named in the
{substitution group affiliations}
of other
element declarations having the same declared
{type definition}
or
some type
derived
therefrom.
The explicit values of
{substitution group exclusions}
extension
or
restriction
rule out element declarations having
types whose
derivation from
{type definition}
involves any
extension
steps, or
restriction
steps,
respectively.
The supplied values for
{disallowed substitutions}
determine whether an element declaration
appearing in a
content
model
will be prevented from additionally
validating
elements (a) with an
xsi:type (§2.7.1)
that identifies an
extension
or
restriction
of the type of the declared element,
and/or (b) from
validating
elements which are in the
substitution group
headed by the declared
element. If
{disallowed substitutions}
is empty, then
all
derived
types and
substitution group
members are allowed.
Element declarations for which
{abstract}
is
true
can appear in content models
only when substitution is allowed; such declarations
must 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 information
item. It specifies a type definition for an element either by
reference or explicitly, and
may
provide occurrence and
default information. The correspondences between the properties
of the information item
after the appropriate
pre-processing
and the
properties of the component(s) it
corresponds to are given in this section.
XML Representation Summary
element
Element Information Item
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
)*))

An

element
information item in a schema document
maps to an
element declaration and allows the
type definition of that declaration to be specified either by
reference or by explicit inclusion.
Top-level

elements
(i.e. those which appear within
the schema document as children of

elements)
produce
global
element declarations;

s within

or

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
user-defined global type definition. Otherwise an
anonymous

or

is provided inline.
Note:
Children of

are not strictly speaking top-level
declarations, but they will become top-level declarations if they
override corresponding declarations in the
target set
of their parent. See
Overriding component definitions (

) (§4.2.5)
for details.
Element information items
validated
by a top-level
declaration
must
be qualified with the
{target namespace}
of that
declaration.
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

, via its determination of
{target namespace}
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. The names of locally-scoped
element declarations need not be unique and thus
reside in no symbol space at all (but the element declarations are
constrained by
Element Declarations Consistent (§3.8.6.3)
).
Note that the above allows for two levels of defaulting for unspecified
type definitions. An

with no referenced or included type definition will
correspond to an element declaration which has

the
same type definition as the first
substitution-group head named in the
substitutionGroup
[attribute]
, if present,

otherwise
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
XML Representation of Identity-constraint Definition Schema Components (§3.11.2)
for


and

The following sections specify several
sets of XML mapping rules which apply in different circumstances.
If the

element information item has

as its parent, it maps to
an
Element Declaration
using the mappings described in
Common Mapping Rules for Element Declarations (§3.3.2.1)
and
Mapping Rules for Top-Level Element Declarations (§3.3.2.2)
If the

element information
item has

or

as an ancestor,
and the
ref
[attribute]
is absent,
and it does not have
minOccurs=maxOccurs=0
then it maps both to a
Particle
, as described
in
Mapping Rules for Local Element Declarations (§3.3.2.3)
, and also to an
Element Declaration
, using the mappings described in
Common Mapping Rules for Element Declarations (§3.3.2.1)
and
Mapping Rules for Local Element Declarations (§3.3.2.3)
If the

element information item has

or

as an
ancestor, and the
ref
[attribute]
is present,
and it does not have
minOccurs=maxOccurs=0
then it maps to a
Particle
as described in
References to Top-Level Element Declarations (§3.3.2.4)
If the

element information item has
minOccurs=maxOccurs=0
then it maps to no component at all.
Note:
The
minOccurs
and
maxOccurs
attributes are not allowed on top-level

elements, so in valid schema
documents this will happen only when the

element information item has

or

as an
ancestor.
3.3.2.1 Common Mapping Rules for Element Declarations
The following mapping rules apply
in all cases where an

element
maps to an
Element Declaration
component.
XML Mapping Summary for
Element Declaration
Schema Component
Property
Representation
{name}
The
actual value
of the
name
[attribute]
{type definition}
The first of the following
that applies:
The type definition corresponding to the

or

element information item in the
[children]
, if either is present.
The type definition
resolved
to by the
actual value
of
the
type
[attribute]
, if it is present.
The declared
{type definition}
of the
Element Declaration
resolved
to by the first
QName
in the
actual value
of the
substitutionGroup
[attribute]
, if present.
xs:anyType
{type table}
Type Table
corresponding to the

element
information
items among the
[children]
, if any, as follows, otherwise
absent
Property
Value
{alternatives}
A sequence of
Type Alternative
s, each corresponding, in
order, to one of
the

elements which have a
test
[attribute]
{default type definition}
Depends upon the final

element among the
[children]
. If it has no
test
[attribute]
, the final

maps to
the
{default type definition}
if it does have a
test
attribute, it is covered by
the rule for
{alternatives}
and
the
{default type definition}
is taken from the declared type of the
Element Declaration
So the value of the
{default type definition}
is given by
the appropriate
case
among the following:
If
the

has no
test
[attribute]
then
Type Alternative
corresponding to the

otherwise
(the

has a
test
) a
Type Alternative
with the following properties:
Property
Value
{test}
absent
{type definition}
the
{type definition}
property of
the parent
Element Declaration
{annotations}
the empty sequence.
{nillable}
The
actual value
of the
nillable
[attribute]
, if present, otherwise
false
{value constraint}
If there is a
default
or a
fixed
[attribute]
then a
Value Constraint
as follows, otherwise
absent
[Definition:]
Use the name
effective simple type
definition
for the declared
{type definition}
, if it is a
simple type definition,
or, if
{type definition}
{content type}
{variety}
simple
for
{type definition}
{content type}
{simple type definition}
or else for the built-in
string
simple
type definition).
Property
Value
{variety}
either
default
or
fixed
, as appropriate
{value}
the
actual value
(with respect
to the
effective simple type definition
) of the
[attribute]
{lexical form}
the
normalized value
(with respect to the
effective simple type definition
) of the
[attribute]
{identity- constraint definitions}
A set
consisting of the identity-constraint-definitions corresponding to
all the


and

element
information items in the
[children]
, if any, otherwise the
empty set.
{substitution group affiliations}
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.
{disallowed substitutions}
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

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:
If
the
EBV
is the empty string,
then
the empty set;
If
the
EBV
is
#all
then
extension
restriction
substitution
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

may
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).
{substitution group exclusions}
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
{abstract}
The
actual value
of the
abstract
[attribute]
, if present, otherwise
false
{annotations}
The
annotation mapping
of the

element
and any of its


and

[children]
with a
ref
[attribute]
, as defined in
XML Representation of Annotation Schema Components (§3.15.2)
3.3.2.2 Mapping Rules for Top-Level Element Declarations
If the

element information item has

as its parent,
it
maps to a
global
Element Declaration
using the mapping given
in
Common Mapping Rules for Element Declarations (§3.3.2.1)
supplemented by the following.
XML Mapping Summary for
Element Declaration
Schema Component
Property
Representation
{target namespace}
The
actual value
of the
targetNamespace
[attribute]
of the parent

element information item, or
absent
if there is none.
{scope}
Scope
as follows
Property
Value
{variety}
global
{parent}
absent
3.3.2.3 Mapping Rules for Local Element Declarations
If
the

element information
item has

or

as
an ancestor,
and the
ref
[attribute]
is absent,
and it does not have
minOccurs=maxOccurs=0

then it maps both to a
Particle
and to a local
Element Declaration
which is the
{term}
of that
Particle
. The
Particle
is as follows:
XML Mapping Summary for
Particle
Schema Component
Property
Representation
{min occurs}
The
actual value
of the
minOccurs
[attribute]
, if present, otherwise
{max occurs}
unbounded
, if the
maxOccurs
[attribute]
equals
unbounded
, otherwise the
actual value
of the
maxOccurs
[attribute]
, if present, otherwise
{term}
A (local) element declaration as
given below.
{annotations}
The same annotations as the
{annotations}
of the
{term}
The

element also maps to an
element declaration using the
mapping rules given in
Common Mapping Rules for Element Declarations (§3.3.2.1)
, supplemented by those
below:
XML Mapping Summary for
Element Declaration
Schema Component
Property
Representation
{target namespace}
The appropriate
case
among the following:
If
targetNamespace
is present
then
its
actual value
If
targetNamespace
is not present and
one
of the following is true
2.1
form
qualified
2.2
form
is absent and the

ancestor
has
elementFormDefault
qualified
then
the
actual value
of the
targetNamespace
[attribute]
of the ancestor

element
information item,
or
absent
if there is
none.
otherwise
absent
{scope}
Scope
as follows:
Property
Value
{variety}
local
{parent}
If the

element information item has

as an ancestor, the
Complex Type Definition
corresponding to that item, otherwise (the

element information item is within a named

element information
item), the
Model Group Definition
corresponding to
that item.
3.3.2.4 References to Top-Level Element Declarations
If the

element information
item has

or

as an
ancestor,
and the
ref
[attribute]
is
present,
and it does not have
minOccurs=maxOccurs=0

then it maps to
Particle
as follows.
XML Mapping Summary for
Particle
Schema Component
Property
Representation
{min occurs}
The
actual value
of the
minOccurs
[attribute]
, if present, otherwise
{max occurs}
unbounded
, if the
maxOccurs
[attribute]
equals
unbounded
, otherwise the
actual value
of the
maxOccurs
[attribute]
, if present, otherwise
{term}
The (top-level) element
declaration
resolved
to by the
actual value
of the
ref
[attribute]
{annotations}
The
annotation mapping
of
the

element, as defined in
XML Representation of Annotation Schema Components (§3.15.2)
3.3.2.5 Examples of Element Declarations
Example

. . .

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

. . .

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
. Two further
elements are declared, each a member of the
facet
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.
























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"

The
message
element itself uses
messageType
both as its declared type and
as its default type, and uses
test
attributes on its

[children]
to assign the appropriate
specialized message type to messages with the well known
values for the
kind
attribute.
Because the declared type and the default type are the same, the last

(without the
test
attribute)
can be omitted.








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
information items by the schema for schema documents:
all
of the following
must
be true:
default
and
fixed
are not
both present.
If the item's parent is not

, then
all
of the following are true:
2.1
One of
ref
or
name
is present, but not both.
2.2
If
ref
is present, then

no unqualified attributes are
present other than
minOccurs
maxOccurs
and
id
and no children in the Schema namespace (
xs
) other than

The

element does not have both a

or

child and a
type
attribute.
If
targetNamespace
is present then
all
of the following are true:
4.1
name
is present.
4.2
form
is not present.
4.3
If the ancestor

does not have a
targetNamespace
[attribute]
or its
actual value
is different from the
actual value
of
targetNamespace
of

, then
all
of the following are true:
4.3.1

has

as an ancestor
4.3.2
There is a

ancestor
between the

and the nearest

ancestor, and the
actual value
of the
base
[attribute]
of

does not
match
the
name of
xs:anyType
Every

element but
the last has a
test
[attribute]
; the last

element
may
have such an
[attribute]
3.3.4 Element Declaration Validation Rules
When an element is
assessed
, it is
first checked against its
governing element declaration
, if any; this in turn
entails checking it against its
governing type definition
. The
second step is recursive: the element's
[attributes]
and
[children]
are
assessed
in turn with respect to the declarations assigned to
them by their parent's
governing type definition
3.3.4.1 Selected and Instance-specified Type Definitions
The
governing type definition
of an element
is normally the declared
{type definition}
associated with the
governing element declaration
, but this may be
overridden
using conditional type assignment in the
Element Declaration
or using an
instance-specified type definition
, or both.
When the element is declared with
conditional type assignment, the
selected type definition
is used as the
governing type definition
unless
overridden
by an
instance-specified type definition
[Definition:]
The
selected type
definition
of an element information item
is a
type definition associated with
in the following way. Let
be the
governing element declaration
of
. Then:
If
has a
{type table}
, then
is the type
conditionally selected
for
by
{type table}
If
has no
{type table}
, then
is
{type definition}
If
has no
governing element declaration
, then
has no selected
type definition.
Note:
It is a consequence of
Element Declaration Properties Correct (§3.3.6.1)
that if
is valid, then
will be
validly substitutable
for
's

declared
{type definition}
, or else that
will be
xs:error
[Definition:]
Given a
Type Table
and an element
information item
conditionally selects
type
for
in
the following way. The
{test}
expressions in
's
{alternatives}
are evaluated, in order,
until one of the
Type Alternative
successfully selects
a type definition for
, or until
all have been tried without success. If any
Type Alternative
successfully selects
a type definition, none of the following
Type Alternative
s are tried. Then the type
conditionally
selected
for
by
is
as described in

the appropriate
case
among the following:
If at least one
Type Alternative
in
{alternatives}
successfully selects
a type definition for
, then
is the type definition selected by the first such
Type Alternative
If no
Type Alternative
in
{alternatives}
successfully selects
a type definition, then
is
{default type definition}
{type definition}
[Definition:]
An
instance-specified type definition
is a type definition associated with an element information
item in the following way:
Among the element's attribute information items is one
named
xsi:type
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)
The
actual value
(a
QName
resolves
to a type definition.
It is this type definition which is the
instance-specified type definition
3.3.4.2 Type Override and Valid Substitutability
[Definition:]
An
instance-specified type definition
is said to
override
another type definition
if and only
if all of the following are true:
is the
instance-specified type definition
on some element information item
. A
governing element declaration
may or may not be known for
is
validly substitutable
for
, subject to the blocking keywords of
the
{disallowed substitutions}
of
's
governing element declaration
, if any, or
validly
substitutable without limitation
for
(if no
governing element declaration
is known).
Note:
Typically,
would be the
governing type definition
for
if it were not
overridden. (This will be the case if
was stipulated by
the processor, as described in
Assessing Schema-Validity (§5.2)
, or
has a
governing element declaration
and
is its declared type, or
is the
locally declared type
of
.)
Note:
The use of the term "
override
to denote the relation between an
instance-specified type definition
and another type
has nothing to do with the

element; the two mechanisms are
distinct and unrelated.
[Definition:]
A type definition
is
validly substitutable
for another type
subject to a
set of blocking keywords
(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
and
are both complex
type definitions and
is validly derived from
subject to the
blocking keywords in the union of
and
{prohibited substitutions}
as defined in
Type Derivation OK (Complex) (§3.4.6.5)
or
is a complex type definition,
is a
simple type definition, and
is validly
derived
from
subject to the
blocking keywords in
, as defined in
Type Derivation OK (Complex) (§3.4.6.5)
or
is a simple type definition and
is
validly
derived
from
subject to the blocking keywords in
, as defined in
Type Derivation OK (Simple) (§3.16.6.3)
[Definition:]
If the set of keywords controlling whether
a type
is
validly substitutable
for another type
is the
empty set, then
is said to be
validly
substitutable
for
without limitation
or
absolutely
. The phrase
validly
substitutable
, without mention of any set of blocking
keywords, means "validly substitutable without
limitation".
Sometimes one type
is
validly substitutable
for another type
only if
is derived
from
by a chain of restrictions, or if
is a union type
and
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
is
validly
substitutable as a restriction
for another type
if
and only if
is
validly substitutable
for
, subject to the
blocking keywords {
extension
list
union
}.
3.3.4.3 Element Locally Valid (Element)
The concept of local validity of an
element information item against an element declaration is
an important part of the schema-validity
assessment
of elements. (The other important part is the recursive
assessment
of attributes and descendant elements.)
Local validity partially determines the element information item's
[validity]
property,
and fully determines the
[local element validity]
property, in the
post-schema-validation infoset
Informally, an element is locally valid
against an element declaration when:
The declaration is present in the schema
and the name of the element matches the name of the declaration.
The element is declared concrete (i.e. not abstract).
Any
xsi:nil
attribute on the element obeys the
rules. The element is allowed to have an
xsi:nil
attribute only if the element is declared nillable, and
xsi:nil = 'true'
is allowed only if the element
itself is empty. If the element declaration specifies a
fixed value for the element,
xsi:nil='true'
will make the element invalid.
Any
xsi:type
attribute present names a
type which is
validly substitutable
for the element's
declared
{type definition}
The element's content satisfies the appropriate constraints:
If the element is empty and the declaration specifies a
default value, the default is checked against the
appropriate type definitions.
Otherwise, the content of the element is checked against
the
governing type definition
; additionally, if the element
declaration specifies a fixed value, the content is
checked against that value.
The element satisfies all the identity constraints specified
on the element declaration.
Additionally, on the
validation root
, document-level
ID and IDREF constraints are checked.
The following validation rule gives
the normative formal definition of local validity of an element
against an element declaration.
Validation Rule: Element Locally Valid (Element)
For an element information item
to be locally
valid
with respect to an element
declaration
all
of the following
must
be true:
is not
absent
and
and
have the same
expanded name
{abstract}
false
One
of the following is true:
3.1
{nillable}
false
and
has no
xsi:nil
attribute.
3.2
{nillable}
true
and
one
of the following is true
3.2.1
has no
xsi:nil
attribute information item.
3.2.2
has
xsi:nil
false
3.2.3
has
xsi:nil
true
(that is,
is
nilled
), and
all
of the following are true:
3.2.3.1
has no character or element
information item
[children]
3.2.3.2
has no
{value constraint}
with
{variety}
fixed
If
has an
instance-specified type definition
, then
overrides
the
selected type definition
of
The appropriate
case
among the following is true:
5.1
If
has a
{value constraint}
, and
has neither
element nor character
[children]
, and
is not
nilled
with respect to
then
all
of the following are true:
5.1.1
If
's
governing type definition
is
an
instance-specified type definition
then
{value constraint}
is a valid default for the
governing type definition
as defined in
Element Default Valid (Immediate) (§3.3.6.2)
5.1.2
The element information item with
{value constraint}
{lexical form}
used as its
normalized value
is
locally
valid
with respect to
the
governing type definition
as defined
by
Element Locally Valid (Type) (§3.3.4.4)
5.2
If
has no
{value constraint}
, or
has either element or
character
[children]
, or
is
nilled
with respect to
then
all
of the following are true:
5.2.1
is locally
valid
with respect to the
governing type definition
as defined
by
Element Locally Valid (Type) (§3.3.4.4)
5.2.2
If
{value constraint}
{variety}
fixed
and
is not
nilled
with respect to
, then
all
of the following are true:
5.2.2.1
has no element
information item
[children]
5.2.2.2 The appropriate
case
among the following is true:
5.2.2.2.1
If
's
governing type definition
is a
Complex Type Definition
with
{content type}
{variety}
mixed
then
the
initial
value
of
matches
{value constraint}
{lexical form}
5.2.2.2.2
If
's
governing type definition
is a
Simple Type Definition
or a
Complex Type Definition
with
{content type}
{variety}
simple
then
the
actual value
of
is equal or identical to
{value constraint}
{value}
is
valid
with respect to each of the
{identity-constraint definitions}
as per
Identity-constraint Satisfied (§3.11.4)
If
is the
validation root
then it is
valid
per
Validation Root Valid (ID/IDREF) (§3.3.4.5)
Note:
If an element has an
xsi:type
attribute, the
type definition indicated by that attribute normally takes
precedence over the
selected type definition
which would otherwise
govern the element.
If an
xsi:type
attribute is present
and
resolves
to a known type definition, but
fails to
override
the
selected type definition
, then
is not
locally valid against
since
has failed to satisfy
clause

In this case
(or if
xsi:type
fails to
resolve
), the
governing type definition
of the
element is the
selected type definition
of its
governing element declaration
, and the element is
validated against that type as described in
clause
The local validity of the element
with respect to the
governing type definition
is recorded in the
[local type validity]
property.
The use of the
selected type definition
when the
instance-specified type definition
cannot be used
allows useful validation to proceed in some cases (not all) even
when the schema is incomplete. It also
helps ensure consistent typing for sub-elements
with the same name.
3.3.4.4 Element Locally Valid (Type)
The following validation rule specifies
formally what it means for an element to be locally valid
against a type definition. This concept is appealed to in the
course of checking an element's local validity against its
governing type definition
. It
is also part of schema-validity
assessment
of an element when the element is
laxly assessed
, by checking its local validity
against
xs:anyType
Informally, local validity against a type requires first
that the type definition be present in the schema and not declared abstract.
For a simple type definition, the element must lack attributes
(except for namespace declarations and the special attributes
in the
xsi
namespace) and child elements, and must
be type-valid against that simple type definition.
For a complex type definition, the element must
be locally valid against that complex type definition.
Validation Rule: Element Locally Valid (Type)
For an element information item
to be locally
valid
with respect to
a type definition
all
of the following
must
be true:
is not
absent
If
is a complex type definition, then
{abstract}
false
3 The appropriate
case
among the following is true:
3.1
If
is a simple type
definition,
then
all
of the following are true:
3.1.1
[attributes]
is empty, except for attributes named
xsi:type
xsi:nil
xsi:schemaLocation
, or
xsi:noNamespaceSchemaLocation
3.1.2
has no element
information item
[children]
3.1.3
If
is not
nilled
, then the
initial value
is
valid
with
respect to
as defined by
String Valid (§3.16.4)
3.2
If
is a complex type
definition,
then
is
locally
valid
with respect to
as per
Element Locally Valid (Complex Type) (§3.4.4.2)
3.3.4.5 Validation Root Valid (ID/IDREF)
The following validation rule
specifies document-level ID/IDREF constraints checked on the
validation root
if it is an element; this rule is not checked on other
elements. Informally, the requirement is that each ID
identifies a single element within the
validation root
and that each IDREF value matches one ID.
Validation Rule: Validation Root Valid (ID/IDREF)
For an element information item
which is the
validation root
to be
valid
all
of the following
must
be true:
There is no
ID/IDREF binding
in
[ID/IDREF table]
whose
[binding]
is the empty set.
There is no
ID/IDREF binding
in
[ID/IDREF table]
whose
[binding]
has more than one
member.
See
ID/IDREF Table (§3.17.5.2)
for the definition of
ID/IDREF binding
Note:
The first clause above is
violated when there is a reference to an undefined
ID.
The second is violated when there is
a multiply-defined ID. The
cases are separated out to ensure that distinct error
codes (see
Outcome Tabulations (normative) (§B)
) are associated with these
two cases.
Note:
Since an element governed by type
xs:ID
provides
a unique identifier for the element's parent element, it is not useful
to have an element governed by
xs:ID
when the element
has no parent element or when the parent element lies outside the
scope of validation.
In the following examples,
DOC
and
are governed by type
xs:anyType
the element
and the attribute
xml:id
are
governed by
xs:ID
, and the element
is governed by a complex type with simple content
derived from
xs:ID
In the document
abcd
the ID value '
abcd
' will normally be bound to
the
DOC
element. But if the
element is the validation root, then '
abcd
will have no element binding, because
DOC
is outside the scope of the validation episode.
So the first clause is violated and the document is invalid.
The superficially similar case

will, in contrast, be valid whether the
DOC
element
or the
element is the validation root. The
ID/IDREF table will have one entry in either case, binding
abcd
' to the
element.
For the document
xml:id="abcd">abcd
if
is the validation root, then the ID/IDREF table for the document
will have a single entry for '
abcd
and will be valid. The single binding comes from the
xml:id
attribute; the content of
produces no binding, just as the content of
above produces no binding.
But if
DOC
is the
validation root, then the ID/IDREF table for the document will
have two entries for '
abcd
' (one, from the
xml:id
attribute, binding '
abcd
' to
the
element, one from the content of
binding '
abcd
' to the
DOC
element) and
will be invalid.
Note:
Although this rule applies at the
validation root
, in
practice processors, particularly streaming processors,
will perhaps wish to detect and signal the
clause
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.
3.3.4.6 Schema-Validity Assessment (Element)
This section gives the top-level rule
for
assessment
of an element information item. Informally:
Assessment begins with the identification of a
governing element declaration
for the element and then checks that the
element is locally valid against the declaration; if no
governing element declaration
is available, a
governing type definition
can be
used instead.
The element's attributes are to be
assessed
recursively,
unless they match a
skip
wildcard and are thus
skipped
The element's children are to be
assessed
recursively,
unless they match a
skip
wildcard and are thus
skipped
. For each child element,
the
governing element declaration
is the one identified in the course
of checking the local validity of the parent, unless that
declaration is not available. If the
governing element declaration
is not
available, the element may still be
strictly assessed
if a
governing type definition
can be identified (e.g. via the
xsi:type
attribute), otherwise the element
will be
laxly assessed
[Definition:]
The
governing element declaration
of
an element information item
in a given schema-validity
assessment
episode, is the first of the following
which applies:
declaration stipulated by the processor (see
Assessing Schema-Validity (§5.2)
).
's
context-determined
declaration
A declaration
resolved
to by
's
[local name]
and
[namespace
name]
, provided that
is
attributed
either to a
strict
wildcard particle
or to a
lax
wildcard particle
A declaration
resolved
to by
's
[local
name]
and
[namespace
name]
, provided that
none
of the following is true:
4.1
is
skipped
4.2
the
processor has stipulated a type definition for
4.3
non-absent
locally declared type
exists for
If none of these
applies,
has
no
governing element declaration
(or, in equivalent words,
's
governing element declaration
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:
An
instance-specified type definition
which
overrides
a type
definition stipulated by the processor (see
Assessing Schema-Validity (§5.2)
).
A type definition stipulated by the processor (see
Assessing Schema-Validity (§5.2)
).
An
instance-specified type definition
which
overrides
the
selected type definition
of
The
selected type definition
of
The value
absent
if
is
skipped
An
instance-specified type definition
which
overrides
the
locally declared type
The
locally declared type
An
instance-specified type definition
If none of these
applies,
there is no
governing type definition
(or, in equivalent words, it is
absent
).
Validation Rule: Schema-Validity Assessment (Element)
The schema-validity assessment of an element information item
is performed as follows:
If
has a
governing element declaration
or a
governing type definition
then
must
be
strictly assessed
If
is
skipped
then
must not
be
assessed
Otherwise,
must
be
laxly assessed
[Definition:]
An element
information item
is said to be
strictly assessed
if and only if
all
of the following are true:
One
of the following is true:
1.1
All
of the following are true:
1.1.1
non-absent
element declaration
is known for
, namely its
governing
declaration.
1.1.2
's local
validity
with
respect to that declaration has been evaluated as per
Element Locally Valid (Element) (§3.3.4.3)
1.1.3
If that evaluation involved the evaluation of
Element Locally Valid (Type) (§3.3.4.4)
, clause
thereof is satisfied.
1.2
All
of the following are true:
1.2.1
does not have a
governing element declaration
1.2.2
non-absent
type definition is known for
, namely its
governing type definition
1.2.3
The local
validity
of
with respect to its
governing type definition
has been evaluated as
per
Element Locally Valid (Type) (§3.3.4.4)
For each of the attribute information items among
[attributes]
the appropriate
case
among the following is true:
2.1
If
the attribute has a
governing attribute declaration
then
its schema-validity is assessed with respect to that
declaration, as defined in
Schema-Validity Assessment (Attribute) (§3.2.4.3)
2.2
otherwise
its schema-validity is not assessed.
For each of the element information items among its
[children]
the appropriate
case
among the following is true:
3.1
If
the child has a
governing element declaration
or a
governing type definition
then
its schema-validity is assessed with respect to that
declaration or type definition, as defined in
Schema-Validity Assessment (Element) (§3.3.4.6)
3.2
If
the child is
attributed to
skip
Wildcard
then
its schema-validity is not assessed.
3.3
otherwise
its schema-validity is
laxly assessed
with
respect to
xs:anyType
[Definition:]
The schema validity of an element information item
is
said to be
laxly assessed
if and only if
both
of the following are true:
has neither a
governing element declaration
nor a
governing type definition
is locally
validated
with respect to
xs:anyType
as defined in
Element Locally Valid (Type) (§3.3.4.4)
, and the schema-validity of
's
[attributes]
and
[children]
is assessed as described in clause
and clause
of
Schema-Validity Assessment (Element) (§3.3.4.6)
Note:
It follows from the definitions given that no element
information item can be both
strictly assessed
and
laxly assessed
in the same schema-validity
assessment
episode.
3.3.5 Element Declaration Information Set Contributions
3.3.5.1 Assessment Outcome (Element)
Schema Information Set Contribution: Assessment Outcome (Element)
If and only if the schema-validity of an element information item
has been assessed as per
Schema-Validity Assessment (Element) (§3.3.4.6)
, 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:
If
it was
strictly assessed
then
the appropriate
case
among the following:
1.1
If
all
of the following are true:
1.1.1
One
of the following is true:
1.1.1.1
clause
1.1
of
Schema-Validity Assessment (Element) (§3.3.4.6)
applied and the item was
locally
valid
as defined by
Element Locally Valid (Element) (§3.3.4.3)
1.1.1.2
clause
1.2
of
Schema-Validity Assessment (Element) (§3.3.4.6)
applied and the item was
locally
valid
as defined by
Element Locally Valid (Type) (§3.3.4.4)
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) which is
attributed
to a
strict
wildcard particle
and whose
[validity]
is
notKnown
then
valid
1.2
otherwise
invalid
otherwise
notKnown
[validation attempted]
The appropriate
case
among the following:
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
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
otherwise
partial
3.3.5.2 Validation Failure (Element)
Schema Information Set Contribution: Validation Failure (Element)
If and only if the local
validity
as defined by
Element Locally Valid (Element) (§3.3.4.3)
above and/or
Element Locally Valid (Type) (§3.3.4.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:
If
the item is
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) (§B)
) herein.
otherwise
absent
[subsequence-valid]
The appropriate
case
among the following:
If
the element information item is locally
invalid
, because unexpected
attributes or elements were found among its
[attributes]
and
[children]
and
clause
of
Element Locally Valid (Complex Type) (§3.4.4.2)
would be
satisfied, if those unexpected attributes and
children (those with
[match information]
none
) were removed,
then
true
otherwise
false
[failed identity constraints]
A list of
Identity-Constraint Definition
s that are
not satisfied
by the element information item, as defined by
Identity-constraint Satisfied (§3.11.4)
Note:
In
principle, the value of this property includes all of the
Identity-Constraint Definition
s which are not satisfied for this element item;
in practice, some processors will expose a subset of the
items in this value, rather than the full value.
For example, a processor could choose not to check
further identity constraints after detecting the first
failure.
[failed assertions]
A list of
Assertion
s that are not
satisfied by the element information item, as defined by
Assertion Satisfied (§3.13.4.1)
Note:
In
principle, the value of this property includes all of the
Assertion
s which are not satisfied by this element item;
in practice, some processors will expose a subset of the items in this
value, rather than the full value. For example, a processor
could choose not to check further assertions after detecting the first
failure.
3.3.5.3 Element Declaration
Schema Information Set Contribution: Element Declaration
If and only if a
governing element declaration
is known
for an element information item, then in the
post-schema-validation infoset
the element
information item has the properties:
PSVI Contributions for
element information items
[element declaration]
an
item isomorphic
to the
governing
declaration
component itself
[nil]
true
if clause
3.2.3
of
Element Locally Valid (Element) (§3.3.4.3)
above is satisfied,
otherwise
false
[expected element declaration]
if the element information item is
attributed
to an
element particle
, then the
{term}
of that
Particle
, otherwise
absent
Note:
The
[element declaration]
either is the
same as or is in the
substitution group
of the
[expected element declaration]
[declared type]
an
item isomorphic
to the declared
{type definition}
of the
governing element declaration
[local element validity]
The appropriate
case
among the following:
If
the item was locally
valid
as defined by
Element Locally Valid (Element) (§3.3.4.3)
then
valid
otherwise
(the item was
locally
invalid
as defined by
Element Locally Valid (Element) (§3.3.4.3)
invalid
3.3.5.4 Element Validated by Type
Schema Information Set Contribution: Element Validated by Type
If and only if a
governing type definition
is known for an element
information item, then in the
post-schema-validation infoset
the item has
the properties:
PSVI Contributions for
element information items
[schema normalized value]
The appropriate
case
among the following:
If
the element information item is not
nilled
and either the
governing type definition
is a simple type definition or its
{content type}
has
{variety}
simple
then
the appropriate
case
among the following:
1.1
If
clause
5.1
of
Element Locally Valid (Element) (§3.3.4.3)
above has applied,
then
the
{lexical form}
of the
{value constraint}
1.2
If
clause
5.1
of
Element Locally Valid (Element) (§3.3.4.3)
above has
not
applied and
the
element's
initial value
is
valid
with respect to the simple
type definition as defined by
String Valid (§3.16.4)
then
the
normalized value
of the item as
validated
1.3
otherwise
absent
otherwise
absent
[schema actual value]
If the
[schema normalized value]
is not
absent
, then the corresponding
actual value
; otherwise
absent
[type definition]
An
item isomorphic
to
the
governing type definition
component
itself.
[type definition type]
simple
or
complex
, depending on the
[type definition]
[type definition namespace]
[type definition]
{target namespace}
[type definition anonymous]
true
if
[type definition]
{name}
is
absent
, otherwise
false
[type definition name]
If
[type definition]
{name}
is not
absent
, then
[type definition]
{name}
, otherwise
schema processors
may
, but
need not, provide a value unique to the definition. It
is
implementation-defined
whether a processor provides a name for
such a type definition. If a processor does
provide a value in this situation, the choice of what value
to use is
implementation-dependent
[type fallback]
A keyword indicating whether the expected type
definition was unavailable and the element had a fallback type
as its
governing type definition
declared
if the element information item has a
governing element declaration
which has no
{type table}
and also an
xsi:type
attribute which fails to
resolve
to
a type definition that
overrides
the
declared
{type definition}
selected
if the
element information item has a
governing element declaration
with a
{type table}
and also has an
xsi:type
attribute which fails to
resolve
to a type
definition that
overrides
the
selected type definition
lax
if the
element was
laxly assessed
using
xs:anyType
none
otherwise
[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:
If
the element information item was locally
valid
as defined by
Element Locally Valid (Type) (§3.3.4.4)
then
valid
otherwise
(the item was locally
invalid
as defined by
Element Locally Valid (Type) (§3.3.4.4)
invalid
[descendant validity]
The appropriate
case
among the following:
If
neither its
[children]
nor its
[attributes]
contains an
information item
(element or attribute
respectively) where either
's
[validity]
is
invalid
or
is
attributed
to a strict
wildcard particle
and
's
[validity]
is
notKnown
then
valid
otherwise
invalid
Note:
The
[type definition
type]
[type definition
namespace]
[type
definition name]
, and
[type definition anonymous]
properties are redundant with the
[type definition]
property; they are
defined for the convenience of implementations which wish to
expose those specific properties but not the entire type
definition.
Note:
When clause
5.1
of
Element Locally Valid (Element) (§3.3.4.3)
above
applies and the default or
fixed value constraint
{value}
is of type
QName
or
NOTATION
, it is
implementation-dependent
whether
namespace fixup
occurs;
if it does not, the prefix used in the lexical representation
(in
[schema normalized value]
) will not
necessarily map to the namespace name of the value (in
[schema actual value]
). To reduce problems and confusion, users may
prefer to ensure that the required namespace information item
is
present in the input
infoset.
If
the
[schema normalized value]
is not
absent
and
the
governing type definition
is
a simple type definition with
{variety}
union
or its
{content type}
has
{variety}
simple
and
{simple type definition}
a simple type definition with
{variety}
union
, then there
are four additional
properties:
PSVI Contributions for
element information items
[member type definition]
An
item
isomorphic
to the
validating type
of the
[schema actual value]
[member type definition namespace]
The
{target namespace}
of the
validating type
[member type definition anonymous]
true
if the
{name}
of the
validating type
is
absent
, otherwise
false
[member type definition name]
The
{name}
of the
validating type
, if it is not
absent
. If it is
absent
, schema processors
may
, but
need not, provide a value unique to the definition. It
is
implementation-defined
whether a processor provides a name for
such a type definition. If a processor does
provide a value in this situation, the choice of what value
to use is
implementation-dependent
The
[type definition]
property is provided for applications such as query
processors which need access to the full range of details about
an item's
assessment
, for
example the type hierarchy; the
[type definition type]
[type definition namespace]
[type definition name]
, and
[type definition anonymous]
properties are defined
for the convenience of those specifying
lighter-weight interfaces, in which
exposing the entire type hierarchy and full component details
might be a significant
burden.
If
all
of the following are true:
the
[schema normalized value]
is not
absent
One
of the following is true:
2.1
the simple type definition used to validate the
normalized value
(either the
governing type definition
or its
{simple type definition}
) has
{variety}
list
2.2
the simple type definition has
{variety}
union
and the
validating type
of the
[schema actual value]
has
{variety}
list
the
{item type definition}
of the list
type (from the previous clause) has
{variety}
union
then there is an additional property:
PSVI Contributions for
element information items
[member type definitions]
a sequence of
Simple Type Definition
components, with the same length
as the
[schema actual value]
, each one an
item isomorphic
to the
validating type
of the corresponding

item in the
[schema actual value]
Also, if the declaration has a
{value constraint}
, the item has a property:
PSVI Contributions for
element information items
[schema default]
The
{lexical form}
of the declaration's
{value constraint}
Note that if an element is
laxly assessed
, then the
[type definition]
and
[member type definition]
properties, or
their alternatives, are based on
xs:anyType
3.3.5.5 Element Default Value
Schema Information Set Contribution: Element Default Value
If and only if the local
validity
as defined by
Element Locally Valid (Element) (§3.3.4.3)
above, of an element
information item has been assessed, in the
post-schema-validation infoset
the item
has a property:
PSVI Contributions for
element information items
[schema specified]
The appropriate
case
among the following:
If
clause
5.1
of
Element Locally Valid (Element) (§3.3.4.3)
above applies,
then
schema
otherwise
infoset
See also
Match Information (§3.4.5.2)
Identity-constraint Table (§3.11.5)
Validated with Notation (§3.14.5)
and
Schema Information (§3.17.5.1)
, which describe other information set contributions
related to element information items.
3.3.5.6 Inherited Attributes
Schema Information Set Contribution: Inherited Attributes
[Definition:]
An attribute
information item
, whether explicitly specified in the input
information set or defaulted as described in
Attribute Default Value (§3.4.5.1)
, is
potentially inherited
by
an element information item
if and only if
all
of the following are true:
is among the
[attributes]
of one of
's ancestors.
and
have the same
[validation context]
One
of the following is true:
3.1
is
attributed to
an
Attribute Use
whose
{inheritable}
true
3.2
is
not
attributed to
any
Attribute Use
but
has a
governing attribute declaration
whose
{inheritable}
true
If and only if an element information item
is not
skipped
(that is, it is either
strictly
or
laxly
assessed), in the
post-schema-validation infoset
each of
's element information item
[children]
which is not
attributed to
skip
Wildcard
, has a
property:
PSVI Contributions for
element information items
[inherited attributes]
A list of attribute information items. An attribute information item
is included if and only if
all
of the following are true:
is
potentially inherited
by
Let
be
's
[owner element]
does not have the same
expanded name
as another attribute which is also
potentially inherited
by
and whose
[owner element]
is a descendant of
3.3.6 Constraints on Element Declaration Schema Components
All element declarations (see
Element Declarations (§3.3)
must
satisfy the following
constraint.
3.3.6.1 Element Declaration Properties Correct
Schema Component Constraint: Element Declaration Properties Correct
For
any element declaration
all
of the following
must
be true:
The values of
's properties
are as described in the property tableau in
The Element Declaration Schema Component (§3.3.1)
, modulo the
impact of
Missing Sub-components (§5.3)
If
has a
non-absent
{value constraint}
then
{value constraint}
is a valid default with
respect to
{type definition}
as defined in
Element Default Valid (Immediate) (§3.3.6.2)
If
{substitution group affiliations}
is
non-empty, then
{scope}
{variety}
global
For each member
of
{substitution group affiliations}
{type definition}
is
validly substitutable
for
{type definition}
subject to the blocking keywords
in
{substitution group exclusions}
There are no circular substitution groups.
That is, it is not possible to return to
by repeatedly following any member of the
{substitution group affiliations}
property.
If
{type table}
exists,
then
for each
Type Alternative
in
{type table}
{alternatives}
the
{test}
property is not
absent
If
{type table}
exists,
then for each
{type definition}
in
{type table}
{alternatives}
, and also for
{type table}
{default type definition}
{type definition}
one
of the following is true
7.1
is
validly substitutable
for
{type definition}
, subject
to the blocking keywords of
{disallowed substitutions}
7.2
is the type
xs:error
3.3.6.2 Element Default Valid (Immediate)
This and the following sections
define relations appealed to
elsewhere in this specification.
Schema Component Constraint: Element Default Valid (Immediate)
For a
Value Constraint
to be a
valid default with respect to a type definition
the appropriate
case
among the following
must
be true:
If
is a simple type
definition or a complex type
definition with
{content type}
{variety}
simple
then
is a valid default
with respect either
to
(if
is simple) or
(if
is complex) to
{content type}
{simple type definition}
as defined by
Simple Default Valid (§3.2.6.2)
If
is a complex type definition
with
{content type}
{variety}
simple
then
all
of the following are true:
2.1
{content type}
{variety}
mixed
2.2
The particle
{content type}
{particle}
is
emptiable
as defined by
Particle Emptiable (§3.9.6.3)
3.3.6.3 Substitution Group OK (Transitive)
Schema Component Constraint: Substitution Group OK (Transitive)
For an element declaration (call it
for member) to be
substitutable
for another element declaration (call it
for head)
at least
one
of the following
must
be true:
and
are the same element
declaration.
All
of the following are true:
2.1
{disallowed substitutions}
does not contain
substitution
2.2
There is a chain of
{substitution group affiliations}
properties from
to
, that is, either
{substitution group affiliations}
contains
, or
{substitution group affiliations}
contains a declaration whose
{substitution group affiliations}
contains
, or . . .
2.3
The set of all
{derivation method}
s involved in
the
derivation
of
{type definition}
from
{type definition}
does not
intersect with the union of
(1)
{disallowed substitutions}
(2)
{type definition}
{prohibited substitutions}
(if
{type definition}
is complex, otherwise
the empty set),
and
(3)
the
{prohibited substitutions}
(respectively the empty set) of any intermediate
declared
{type definition}
in the
derivation
of
{type definition}
from
{type definition}
3.3.6.4 Substitution Group
[Definition:]
One element declaration is
substitutable
for another if together they satisfy constraint
Substitution Group OK (Transitive) (§3.3.6.3)
[Definition:]
Every element declaration (call this
HEAD
) in the
{element declarations}
of a schema defines a
substitution
group
, a subset of those
{element declarations}
. An element declaration is in
the
substitution group
of
HEAD
if
and only if it is
substitutable
for
HEAD
3.4 Complex Type Definitions
3.4.1
The Complex Type Definition Schema Component
3.4.2
XML Representation of Complex Type Definition Schema Components
3.4.2.1
Common Mapping Rules for Complex Type Definitions
3.4.2.2
Mapping Rules for Complex Types with Simple Content
3.4.2.3
Mapping Rules for Complex Types with Complex Content
3.4.2.4
Mapping Rule for Attribute Uses Property
3.4.2.5
Mapping Rule for Attribute Wildcard Property
3.4.2.6
Examples of Complex Type Definitions
3.4.3
Constraints on XML Representations of Complex Type Definitions
3.4.4
Complex Type Definition Validation Rules
3.4.4.1
Locally Declared Type
3.4.4.2
Element Locally Valid (Complex Type)
3.4.4.3
Element Sequence Locally Valid (Complex Content)
3.4.4.4
Attribution
3.4.5
Complex Type Definition Information Set Contributions
3.4.5.1
Attribute Default Value
3.4.5.2
Match Information
3.4.6
Constraints on Complex Type Definition Schema Components
3.4.6.1
Complex Type Definition Properties Correct
3.4.6.2
Derivation Valid (Extension)
3.4.6.3
Derivation Valid (Restriction, Complex)
3.4.6.4
Content Type Restricts (Complex Content)
3.4.6.5
Type Derivation OK (Complex)
3.4.7
Built-in Complex Type Definition
Complex Type Definitions provide for:
Constraining element information items by providing
Attribute Declaration (§2.2.2.3)
s governing the appearance and content of
[attributes]
Constraining element information item
[children]
to be empty,
or to conform to a specified element-only or mixed content model, or else
constraining the character information item
[children]
to conform to a
specified simple type definition.
Constraining
elements and attributes to exist,
not to exist, or to have specified values, with
Assertion (§2.2.4.3)
s.
Using the mechanisms of
Type Definition Hierarchy (§2.2.1.1)
to
derive
a complex type from another simple or complex type.
Specifying
post-schema-validation infoset contributions
for elements.
Limiting the ability to
derive
additional types from a given complex type.
Controlling the permission to substitute, in an instance, elements of a
derived
type for elements declared in a content model to be of a given complex type.
Example









The XML representation of a complex type definition.
3.4.1 The Complex Type Definition Schema Component
A complex type definition schema component has the following
properties:
Schema Component:
Complex Type Definition
, a kind of
Type Definition
{annotations}
A sequence of
Annotation
components.
{name}
An xs:NCName value. Optional.
{target namespace}
An xs:anyURI value. Optional.
{base type definition}
type definition
component. Required.
{final}
A subset of {
extension
restriction
}.
{context}
Required if
{name}
is
absent
otherwise
must
be
absent
Either

an
Element Declaration
or a
Complex Type Definition
{derivation method}
One of {
extension
restriction
}. Required.
{abstract}
An xs:boolean value. Required.
{attribute uses}
A set of
Attribute Use
components.
{attribute wildcard}
Wildcard
component. Optional.
{content type}
Content Type
property record. Required.
{prohibited substitutions}
A subset of {
extension
restriction
}.
{assertions}
A sequence of
Assertion
components.
Property Record:
Content Type
{variety}
One of {
empty
simple
element-only
mixed
}. Required.
{particle}
Particle
component. Required if
{variety}
is
element-only
or
mixed
, otherwise
must
be
absent
{open content}
An
Open Content
property record. Optional if
{variety}
is
element-only
or
mixed
, otherwise
must
be
absent
{simple type definition}
Simple Type Definition
component. Required if
{variety}
is
simple
, otherwise
must
be
absent
Property Record:
Open Content
{mode}
One of {
interleave
suffix
}. Required.
{wildcard}
Wildcard
component. Required.
Complex type definitions are identified by their
{name}
and
{target namespace}
. Except
for anonymous complex type definitions (those with no
{name}
), since
type definitions (i.e. both simple and complex type definitions taken together)
must
be uniquely identified within an
XSD schema
, no complex type definition can have the same name as another
simple or complex type definition. Complex type
{name}
s and
{target namespace}
are provided for reference from
instances (see
xsi:type (§2.7.1)
), and for use in the XML
representation of schema components
(specifically in

). See
References to schema components across namespaces (

) (§4.2.6)
for the use of component
identifiers when importing one schema into another.
Note:
The
{name}
of a complex type is not
ipso
facto
the
[(local) name]
of the
element information items
validated
by that definition. The connection between a
name and a type definition is described in
Element Declarations (§3.3)
As described in
Type Definition Hierarchy (§2.2.1.1)
, each complex type is
derived
from a
{base type definition}
which is itself either a
Simple Type Definition (§2.2.1.2)
or a
Complex Type Definition (§2.2.1.3)
{derivation method}
specifies the means of
derivation
as either
extension
or
restriction
(see
Type Definition Hierarchy (§2.2.1.1)
).
A complex type with an empty specification for
{final}
can be used as a
{base type definition}
for other types
derived
by either of
extension or restriction; the explicit values
extension
, and
restriction
prevent further
derivations
by extension and restriction respectively. If all values are specified, then
[Definition:]
the complex type is said to be
final
, because no
further
derivations
are possible
. Finality is
not
inherited, that is, a type definition
derived
by restriction from a type
definition which is final for extension is not itself, in the absence of any
explicit
final
attribute of its own, final for anything.
The
{context}
property is only relevant for anonymous type
definitions, for which its value is the component in which this type
definition appears as the value of a property, e.g.
{type definition}
Complex types for which
{abstract}
is
true
have
no valid instances and thus cannot be used in the normal way as
the
{type definition}
for the
validation
of element information items (if for some reason an abstract
type is identified as the
governing type definition
of an element
information item, the item will invariably be invalid). It
follows that such
abstract types
must not
be referenced from an
xsi:type (§2.7.1)
attribute in an instance document. Abstract
complex types can be used as
{base type definition}
s, or even as
the declared
{type definition}
s of element declarations, provided in every
case a concrete
derived
type definition is used for
validation
, either via
xsi:type (§2.7.1)
or the operation of a
substitution group
{attribute uses}
are a set of attribute uses. See
Element Locally Valid (Complex Type) (§3.4.4.2)
and
Attribute Locally Valid (§3.2.4.1)
for details of attribute
validation
{attribute wildcard}
s provide a more flexible specification for
validation
of
attributes not explicitly included in
{attribute uses}

See
Element Locally Valid (Complex Type) (§3.4.4.2)
The Wildcard Schema Component (§3.10.1)
and
Wildcard allows Expanded Name (§3.10.4.2)
for formal
details of attribute wildcard
validation
{content type}
determines the
validation
of
[children]
of element information items. Informally:
{content type}
with
{variety}
empty
validates
elements
with no character or element information item
[children]
{content type}
with
{variety}
simple
validates
elements with character-only
[children]
using its
{simple type definition}
{content type}
with
{variety}
element-only
validates
elements with
[children]
that
conform to the
content model
supplied by its
{particle}
{content type}
with
{variety}
mixed
validates
elements whose element
[children]
(i.e. specifically ignoring other
[children]
such as character information items)
conform to the
content model
supplied by its
{particle}
{content type}
with
non-absent
{open content}
validates
elements with some
[children]
conforming to the
content model
and
others conforming to
the
{open content}
Note:
Not all combinations of
{derivation method}
and
{content type}
are compatible with all properties of the
{base type definition}
. For example,
it is not allowed to derive a complex type with complex content
from a simple type.
The XML mapping rules specified in the following
section
(in particular clause
of the rule for
the
{simple type definition}
in the rule for
{content type}
of complex types with simple content, and
clause
4.1
and
clause
4.2.1
of the rule for
{content type}
for complex types with complex content)
do not detect such incompatible combinations of properties;
in such cases the mapping rules will build a complex type
regardless of the fact that the properties specified are
incompatible. But the resulting complex type does
not satisfy component rules outlined in
Derivation Valid (Extension) (§3.4.6.2)
or
Derivation Valid (Restriction, Complex) (§3.4.6.3)
The
{prohibited substitutions}
property of a complex type definition
determines
whether type definitions derived from
are or are not
validly substitutable
for
. Examples include (but are not limited
to) the substitution of another type definition:
as the
governing type definition
of an element instance
when
is the
selected type definition
of
(often, the declared
{type definition}
of
's
governing element declaration
); this can occur when
specifies a type
definition using the
xsi:type
attribute;
see
xsi:type (§2.7.1)
as the
selected type definition
of an element instance
when
is the declared
{type definition}
of
's
governing element declaration
; this can occur when conditional type
assignment is used;
see
Type Alternatives (§3.12)
as the
governing type definition
of element instances
whose
governing element declaration
is included in a model group only
implicitly
by virtue of being included in the
substitution group
of
some element declaration present
directly
indirectly
in the model group, whose declared
{type definition}
is
as the
{type definition}
of an
Element Declaration
E1
where
E1
is contained in a
Complex Type Definition
is derived from another
Complex Type Definition
contains an
Element Declaration
E2
that has the same
expanded name
as
E1
E2
has
as its
{type definition}
If
{prohibited substitutions}
is empty,
then all such substitutions are allowed;
if it contains the keyword
restriction
, then no type definition is
validly substitutable
for
if its derivation from
involves
any restriction steps;
if
{prohibited substitutions}
contains
the keyword
extension
, then no type definition is
validly substitutable
for
if its derivation from
involves
any extension steps.
{assertions}
constrain

elements and attributes
to exist, not to exist, or to
have specified values.
Though specified as a sequence, the order
among the assertions is not significant during assessment.
See
Assertions (§3.13)
See
Annotations (§3.15)
for information on the role of the
{annotations}
property.
3.4.2 XML Representation of Complex Type Definition Schema Components
The XML representation for a complex type definition schema component is a

element information item.
The XML representation for complex type definitions with a
{content type}
with
{variety}
simple
is significantly different from that
of those with other
{content type}
s, and this is reflected in the presentation below,
which describes
the mappings for the two cases in separate subsections.
Common mapping rules are factored out and given in
separate sections.
As always, the mapping rules
given here apply after, not before, the appropriate
pre-processing
XML Representation Summary
complexType
Element Information Item
abstract =
boolean
: false
block =

#all
| List of (
extension
restriction
))
final =

#all
| List of (
extension
restriction
))
id =
ID
mixed =
boolean
name =
NCName
defaultAttributesApply =
boolean
: true
{any attributes with non-schema namespace . . .}
Content:
annotation
?, (
simpleContent
complexContent
| (
openContent
?, (
group
all
choice
sequence
)?, ((
attribute
attributeGroup
)*,
anyAttribute
?),
assert
*)))

Note:
It is
a consequence of the concrete syntax given above that
a top-level
type definition need consist of no more than a name, i.e. that

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

source declaration
has a

element as a child,
then it maps to a
Complex Type Definition
using the mapping
rules in
Mapping Rules for Complex Types with Simple Content (§3.4.2.2)
Common Mapping Rules for Complex Type Definitions (§3.4.2.1)
Mapping Rule for Attribute Uses Property (§3.4.2.4)
, and
Mapping Rule for Attribute Wildcard Property (§3.4.2.5)
If the

source declaration
has a

element as a child,
then it maps to a
Complex Type Definition
using the mapping
rules in
Mapping Rules for Complex Types with Explicit Complex Content (§3.4.2.3.1)
Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3)
Common Mapping Rules for Complex Type Definitions (§3.4.2.1)
Mapping Rule for Attribute Uses Property (§3.4.2.4)
, and
Mapping Rule for Attribute Wildcard Property (§3.4.2.5)
If the

source declaration
has neither a

nor a

element as a child,
then it maps to a
Complex Type Definition
using the mapping
rules in
Mapping Rules for Complex Types with Implicit Complex Content (§3.4.2.3.2)
Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3)
Common Mapping Rules for Complex Type Definitions (§3.4.2.1)
Mapping Rule for Attribute Uses Property (§3.4.2.4)
, and
Mapping Rule for Attribute Wildcard Property (§3.4.2.5)
Where convenient, the mapping rules are
described exclusively in terms of the schema document's
information set. The mappings, however, depend not only upon
the source declaration but also upon the schema context. Some
mappings, that is, depend on the properties of other components
in the schema. In particular, several of the mapping rules
given in the following sections depend upon the
{base type definition}
having
been identified before they apply.
3.4.2.1 Common Mapping Rules for Complex Type Definitions
Whichever
alternative for the content of

is
chosen, the following property mappings
apply.
Except where otherwise specified, attributes and child
elements are to be sought among the
[attributes]
and
[children]
of the

element.
XML Mapping Summary for
Complex Type Definition
Schema Component
Property
Representation
{name}
The
actual value
of the
name
[attribute]
if present, otherwise
absent
{target namespace}
The
actual value
of
the
targetNamespace
[attribute]
of the

ancestor element information item if present,
otherwise
absent
{abstract}
The
actual value
of the
abstract
[attribute]
, if present, otherwise
false
{prohibited substitutions}
A set
corresponding to the
actual value
of the
block
[attribute]
, if present, otherwise to the
actual value
of the
blockDefault
[attribute]
of the ancestor

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:
If
the
EBV
is the empty string,
then
the empty set;
If
the
EBV
is
#all
then
extension
restriction
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

may
include values other than
restriction
or
extension
, those values
are ignored in the determination of
{prohibited substitutions}
for complex type
definitions (they
are
used elsewhere).
{final}
As for
{prohibited substitutions}
above, but using the
final
and
finalDefault
[attributes]
in place of the
block
and
blockDefault
[attributes]
{context}
If the
name
[attribute]
is present, then
absent
, otherwise (among the ancestor element information
items there will be a nearest

),
the
Element Declaration
corresponding to
the nearest

information item among the
the ancestor element information items.
{assertions}
A sequence whose members are
Assertion
s drawn from the following sources, in order:
The
{assertions}
of the
{base type definition}
Assertion
s corresponding to
all the

element
information items among the
[children]
of


and

, if
any, in document
order.
{annotations}
The
annotation mapping
of the set of
elements containing the

, the

[child]
, if present, the

[children]
, if present, the

and

[children]
, if present, and their

and

[children]
, if present, and their

and

[children]
, if present,
as defined in
XML Representation of Annotation Schema Components (§3.15.2)
Note:
If the
{base type definition}
is a
complex type definition, then the
{assertions}
always
contain members of the
{assertions}
of the
{base type definition}
, no matter which
alternatives are chosen in the XML representation,

or


or

3.4.2.2 Mapping Rules for Complex Types with Simple Content
When the

source declaration has a

child, the
following elements are relevant
(as are


, and

),
and the
property
mappings are as below,
supplemented by the mappings in
Common Mapping Rules for Complex Type Definitions (§3.4.2.1)
Mapping Rule for Attribute Uses Property (§3.4.2.4)
and
Mapping Rule for Attribute Wildcard Property (§3.4.2.5)
Note that either

or

must
appear in
the content of

XML Representation Summary
simpleContent
Element Information Item et al.
id =
ID
{any attributes with non-schema namespace . . .}
Content:
annotation
?, (
restriction
extension
))

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

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

When
the

element has a

child, then
the

element maps to a complex type with
simple content, as follows.
XML Mapping Summary for
Complex Type Definition with simple content
Schema Component
Property
Representation
{base type definition}
The type
definition
resolved
to by the
actual value
of the
base
[attribute]
on the

or

element appearing as a child of

{derivation method}
If the

alternative
is chosen, then
restriction
, otherwise (the

alternative is
chosen)
extension
{content type}
Content Type
as follows:
Property
Value
{variety}
simple
{particle}
absent
{open content}
absent
{simple type definition}
the appropriate
case
among the following:
If
the
{base type definition}
is a
complex type definition whose own
{content type}
has
{variety}
simple
and the

alternative
is chosen,
then
let
be
1.1
the simple type definition corresponding to the

among the
[children]
of

if there is one;
1.2
otherwise (

has no

among its
[children]
), the
simple type definition which is the
{simple type definition}
of the
{content type}
of
the
{base type definition}
a simple type definition
as follows:
Property
Value
{name}
absent
{target namespace}
The
actual value
of the
targetNamespace
[attribute]
of the ancestor

element information item if present,
otherwise
absent
{final}
The empty set
{context}
The
Complex Type Definition
whose
{content type}
{simple type definition}
is being defined
{base type definition}
{facets}
a set of facet components corresponding
to the appropriate element information items among the

's
[children]
(i.e.
those which specify facets, if any), as defined in
Simple Type Restriction (Facets) (§3.16.6.4)
{fundamental facets}
Based on
{variety}
{facets}
{base type definition}
and
{member type definitions}
, a set of
Fundamental Facet
components, one each as
specified in
The ordered Schema
Component
The
bounded Schema Component
The cardinality Schema
Component
and
The
numeric Schema Component
{variety}
{variety}
{primitive type definition}
{primitive type definition}
{item type definition}
{item type definition}
{member type definitions}
{member type definitions}
{annotations}
The empty sequence
If
the
{base type definition}
is a
complex type definition whose own
{content type}
has
{variety}
mixed
and
{particle}
Particle
which is
emptiable
, as
defined in
Particle Emptiable (§3.9.6.3)
and the

alternative is chosen,
then
(let
be the simple type definition corresponding to
the

among the
[children]
of

if any, otherwise
xs:anySimpleType
) a simple type definition which
restricts
with a set of facet
components corresponding to the appropriate element
information items among the

's
[children]
(i.e. those
which specify facets, if any), as defined in
Simple Type Restriction (Facets) (§3.16.6.4)
Note:
If there is no

among the
[children]
of

(and if therefore
is
xs:anySimpleType
), the result will be a simple type definition component
which fails to obey the constraints on simple type definitions, including
for example clause
1.1
of
Derivation Valid (Restriction, Simple) (§3.16.6.2)
If
the
{base type definition}
is a
complex type definition whose own
{content type}
has
{variety}
simple
and the

alternative is chosen,
then
the
{simple type definition}
of the
{content type}
of
that complex type definition;
If
the
{base type definition}
is a
simple type definition and the

alternative is chosen,
then
that simple type definition;
otherwise
xs:anySimpleType
3.4.2.3 Mapping Rules for Complex Types with Complex Content
When the

element does not have a

child
element, then it maps to a complex type with complex
content. The
following elements are relevant (as are the


and

elements,
which are described
more fully in
XML Representation of Attribute Declaration Schema Components (§3.2.2)
Mapping Rule for Attribute Uses Property (§3.4.2.4)
, and
XML Representation of Wildcard Schema Components (§3.10.2)
, respectively, and which are

not repeated here), and the additional property
mappings are as below, supplemented
by the mappings in
Common Mapping Rules for Complex Type Definitions (§3.4.2.1)
Mapping Rule for Attribute Uses Property (§3.4.2.4)
Mapping Rule for Attribute Wildcard Property (§3.4.2.5)
Mapping Rules for Local Attribute Declarations (§3.2.2.2)
, and
Mapping Rules for References to Top-level Attribute Declarations (§3.2.2.3)
. Note that either

or

must
appear in
the content of

, but their
content
models are different in this case from the case above when they
occur as children of

XML Representation Summary
complexContent
Element Information Item et al.
id =
ID
mixed =
boolean
{any attributes with non-schema namespace . . .}
Content:
annotation
?, (
restriction
extension
))

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

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

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

Complex types with complex content can
be the image of two different forms of

element: one with a

child (discussed in
Mapping Rules for Complex Types with Explicit Complex Content (§3.4.2.3.1)
), and one with neither

nor

as a child (discussed in
Mapping Rules for Complex Types with Implicit Complex Content (§3.4.2.3.2)
).
The mapping of the
{content type}
is the same
in both cases; it is described in
Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3)
3.4.2.3.1 Mapping Rules for Complex Types with Explicit Complex Content
When the

source declaration has a

child, the following mappings apply, supplemented by those
specified in
Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3)
Common Mapping Rules for Complex Type Definitions (§3.4.2.1)
Mapping Rule for Attribute Uses Property (§3.4.2.4)
and
Mapping Rule for Attribute Wildcard Property (§3.4.2.5)
XML Mapping Summary for
Complex Type Definition with complex content
Schema Component
Property
Representation
{base type definition}
The type
definition
resolved
to by the
actual value
of the
base
[attribute]
{derivation method}
If the

alternative is chosen, then
restriction
, otherwise
(the

alternative is
chosen)
extension
3.4.2.3.2 Mapping Rules for Complex Types with Implicit Complex Content
When the

source declaration
has neither

nor

as a child, it is taken
as shorthand for complex content restricting
xs:anyType
. The mapping rules specific to this
situation are as follows; the mapping rules for properties
not described here are as given in
Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3)
Common Mapping Rules for Complex Type Definitions (§3.4.2.1)
Mapping Rule for Attribute Uses Property (§3.4.2.4)
and
Mapping Rule for Attribute Wildcard Property (§3.4.2.5)
XML Mapping Summary for
Complex Type Definition with complex content
Schema Component
Property
Representation
{base type definition}
xs:anyType
{derivation method}
restriction
3.4.2.3.3 Mapping Rules for Content Type Property of Complex Content
For complex types with complex content,
the
{content type}
property is
calculated as follows. (For the
{content type}
on complex types with simple content,
see
Mapping Rules for Complex Types with Simple Content (§3.4.2.2)
.)
Note:
The mapping rule below refers here and there to elements
not necessarily present within a

source declaration. For purposes of evaluating tests like
"If the
abc
attribute is present
on the
xyz
element", if no
xyz
element information item is present, then no
abc
attribute is present on the
(non-existent)
xyz
element.
When the mapping rule below refers to "the
[children]
", then for a

source declaration with a

child, then the
[children]
of

or

(whichever
appears as a child of

) are meant. If no

is present, then the
[children]
of
the

source
declaration itself are meant.
The mapping rule also refers to the value of the
{derivation method}
property, whose value is determined as specified in
the preceding sections.
XML Mapping Summary for
Complex Type Definition with complex content
Schema Component
Property
Representation
{content type}
[Definition:]
Let the
effective mixed
be
the appropriate
case
among the following:
1.1
If
the
mixed
[attribute]
is
present on

then
its
actual value
1.2
If
the
mixed
[attribute]
is
present on

then
its
actual value
1.3
otherwise
false
Note:
It is a consequence of clause
of
Complex Type Definition Representation OK (§3.4.3)
that
clause
1.1
and
clause
1.2
above will never contradict
each other in a conforming schema document.
[Definition:]
Let the
explicit content
be
the appropriate
case
among the following:
2.1
If
at least
one
of the following is true
2.1.1
There is no



or

among the
[children]
2.1.2
There is an

or

among the
[children]
with no
[children]
of its own excluding

2.1.3
There is among the
[children]

element

whose
minOccurs
[attribute]
has the
actual value
and which has no
[children]
of its own except for

2.1.4
The



or

element
among the
[children]
has a
maxOccurs
[attribute]
with an
actual value
of 0;
then
empty
2.2
otherwise
the particle corresponding to the



or

among the
[children]
[Definition:]
Let the
effective content
be
the appropriate
case
among the following:
3.1
If
the
explicit content
is
empty
then
the appropriate
case
among the following:
3.1.1
If
the
effective
mixed
is
true
then
A particle whose properties are as
follows:
Property
Value
{min occurs}
{max occurs}
{term}
a model group whose
{compositor}
is
sequence
and whose
{particles}
is empty.
3.1.2
otherwise
empty
3.2
otherwise
the
explicit content
[Definition:]
Let the
explicit content type
be
the appropriate
case
among the following:
4.1
If
{derivation method}
restriction
then
the appropriate
case
among the following:
4.1.1
If
the
effective
content
is
empty
then
Content Type
as follows:
Property
Value
{variety}
empty
{particle}
absent
{open content}
absent
{simple type definition}
absent
4.1.2
otherwise
Content Type
as follows:
Property
Value
{variety}
mixed
if
the
effective
mixed
is
true
, otherwise
element-only
{particle}
The
effective
content
{open content}
absent
{simple type definition}
absent
4.2
If
{derivation method}
extension
then
the appropriate
case
among the following:
4.2.1
If
the
{base type definition}
is a simple type
definition or is a complex type definition whose
{content type}
{variety}
empty
or
simple
then
Content Type
as per
clause
4.1.1
and clause
4.1.2
above;
4.2.2
If
the
{base type definition}
is a complex type
definition whose
{content type}
{variety}
element-only
or
mixed
and the
effective content
is
empty
then
{base type definition}
{content type}
4.2.3
otherwise
Content Type
as
follows:
Property
Value
{variety}
mixed
if
the
effective
mixed
is
true
, otherwise
element-only
{particle}
[Definition:]
Let the
base particle
be
the particle of the
{content type}
of the
{base type definition}
Then
the appropriate
case
among the following:
4.2.3.1
If
the
{term}
of
the
base particle
has
{compositor}
all
and the
explicit content
is empty,
then
the
base particle
4.2.3.2
If
the
{term}
of
the
base particle
has
{compositor}
all
and the
{term}
of the
effective content
also has
{compositor}
all
then
Particle
whose properties are
as follows:
{min occurs}
the
{min occurs}
of the
effective content
{max occurs}
{term}
a model group whose
{compositor}
is
all
and whose
{particles}
are the
{particles}
of the
{term}
of the
base particle
followed
by the
{particles}
of the
{term}
of the
effective content
4.2.3.3
otherwise
{min occurs}
{max occurs}
{term}
a model group whose
{compositor}
is
sequence
and whose
{particles}
are the
base particle
followed by the
effective content
{open content}
the
{open content}
of the
{content type}
of the
{base type definition}
{simple type definition}
absent
[Definition:]
Let the
wildcard element
be
the appropriate
case
among the following:
5.1
If
the

[child]
is present
then
the

[child]
5.2
If
the

[child]
is not
present,
the

ancestor has a

[child]
, and
one
of the following is true
5.2.1
the
explicit content type
has
{variety}
empty
5.2.2
the
explicit content type
has
{variety}
empty
and the

element has
appliesToEmpty
true
then
the

[child]
of the

5.3
otherwise
absent
Then the value of the property is
the appropriate
case
among the following:
6.1
If
the
wildcard element
is
absent
or is present and has
mode
'none'
then
the
explicit content type
6.2
otherwise
Property
Value
{variety}
The
{variety}
of the
explicit content type
if it's not
empty
otherwise
element-only
{particle}
The
{particle}
of the
explicit content type
if the
{variety}
of the
explicit content type
is not
empty
otherwise a
Particle
as follows:
Property
Value
{min occurs}
{max occurs}
{term}
a model group whose
{compositor}
is
sequence
and whose
{particles}
is empty.
{open content}
An
Open Content
as follows:
Property
Value
{mode}
The
actual value
of the
mode
[attribute]
of the
wildcard element
, if present,
otherwise
interleave
{wildcard}
Let
be the
wildcard corresponding to the

[child]
of the
wildcard element
If the
{open content}
of the
explicit content type
is
absent
, then
; otherwise
a wildcard whose
{process contents}
and
{annotations}
are those of
, and whose
{namespace constraint}
is the
wildcard union of the
{namespace constraint}
of
and
of
{open content}
{wildcard}
of
the
explicit content type
, as defined in
Attribute Wildcard Union (§3.10.6.3)
{simple type definition}
absent
Note:
It is a consequence of clause
4.2
above that
when a type definition is extended, the same particles appear
in both the base type definition and the extension;
the particles are reused without being copied.
3.4.2.4 Mapping Rule for Attribute Uses Property
Any

source declaration can have

and

elements as
children, or descendants. The

element is described in
XML Representation of Attribute Declaration Schema Components (§3.2.2)
and will not be repeated here.
XML Representation Summary
attributeGroup
Element Information Item
id =
ID
ref
QName
{any attributes with non-schema namespace . . .}
Content:
annotation
?)

The

and

elements map to
the
{attribute uses}
property of the
Complex Type Definition
component
as described below. This mapping rule
is the same for all complex type definitions.
Note:
In the following rule, references to "the
[children]
" refer to the
[children]
of
the

or

element (whichever
appears as a child of

or

in the

source declaration),
if present, otherwise to the
[children]
of the

source declaration itself.
The rule also refers to the value of the
{derivation method}
property, which is described elsewhere.
XML Mapping Summary for
Complex Type Definition (Attribute Uses)
Schema Component
Property
Representation
{attribute uses}
If the

ancestor has a
defaultAttributes
attribute, and the

element does not have
defaultAttributesApply
false
, then the
{attribute uses}
property is
computed as if there were an

[child]
with empty content
and a
ref
[attribute]
whose
actual value
is the
same as that of the
defaultAttributes
[attribute]
appearing after any other

[children]
. Otherwise proceed as if there were no such

[child]
Then the value is a union of sets of
attribute uses as follows
The set of attribute uses corresponding to the

[children]
, if any.
The
{attribute uses}
of the
attribute groups
resolved
to by the
actual value
s of the
ref
[attribute]
of the

[children]
, if any.
The attribute uses "inherited" from the
{base type definition}
, as described by the appropriate
case
among the following:
3.1
If
is a complex type definition and
{derivation method}
extension
then
the attribute
uses in
{attribute uses}
are inherited.
3.2
If
is a
complex type definition and
{derivation method}
restriction
then
the attribute uses in
{attribute uses}
are
inherited, with the exception of those with an
{attribute declaration}
whose
expanded name
is
one
of the following:
3.2.1
the
expanded name
of the
{attribute declaration}
of an attribute use
which has already been included in the set, following
the rules in clause
or clause
above;
3.2.2
the
expanded name
of the
{attribute declaration}
of what would have
been an attribute use corresponding to an

[child]
, if the

had not had
use
prohibited
Note:
This sub-clause handles the case where the
base type definition
allows the attribute
in question, but the restriction prohibits it.
3.3
otherwise
no attribute use
is inherited.
Note:
The
only
substantive function of the value
prohibited
for the
use
attribute of an

is in
establishing the correspondence between a complex type defined
by restriction and its XML representation. It serves to
prevent inheritance of an identically named attribute use from
the
{base type definition}
. Such an

does not correspond to any component, and
hence there is no interaction with either explicit or
inherited wildcards in the operation of
Complex Type Definition Validation Rules (§3.4.4)
or
Constraints on Complex Type Definition Schema Components (§3.4.6)
It is pointless, though not an
error, for the
use
attribute to have the value
prohibited
in other contexts (e.g. in complex type
extensions or named model group definitions), in which cases
the element is simply ignored, provided that
it does not violate other constraints in this
specification.
3.4.2.5 Mapping Rule for Attribute Wildcard Property
The
{attribute wildcard}
property of a
Complex Type Definition
depends on the

element which may be present
within the

element
or within the attribute groups referred to
within

The

element is described in the preceding section
Mapping Rule for Attribute Uses Property (§3.4.2.4)
and will not be repeated here.
Note:
The following mapping rule
is the same for all complex type definitions.
References to "the
[children]
" refer to the
[children]
of
the

or

element (whichever
appears as a child of

or

in the

source declaration),
if present, otherwise to the
[children]
of the

source declaration itself.
The rule also refers to the value of the
{derivation method}
property, which is described elsewhere.
XML Mapping Summary for
Complex Type Definition (Attribute Wildcard)
Schema Component
Property
Representation
{attribute wildcard}
If the

ancestor has a
defaultAttributes
attribute, and the

element does not have
defaultAttributesApply
false
, then the
{attribute wildcard}
property is computed
as if there were an

[child]
with empty content and a
ref
[attribute]
whose
actual value
is the same as that of the
defaultAttributes
[attribute]
appearing after any
other

[children]
. Otherwise proceed as if there were no such

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

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

An instance using this method might look like this:

25cm

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






Example

Albert
Arnold
Gore
Jr

A type definition for personal names, and a definition
derived
by
extension which adds a single element; an element declaration referencing the
derived
definition, and a
valid
instance thereof.
Example

Bill
Clinton

A simplified type definition
derived
from the base type from the previous example by restriction, eliminating
one optional child and
fixing another to occur exactly once; an element declared by reference to it,
and a
valid
instance thereof.
Example







An illustration of the abbreviated form, with the
mixed
attribute appearing on
complexType
itself.
Example










A complex type definition that

allows three explicitly declared child
elements, in the specified order (but not necessarily adjacent), and
furthermore allows additional elements of any name from any namespace other
than the target namespace to appear anywhere in the children.
Example
To restrict away a local element declaration that
competes
with
a wildcard, use a wildcard in the derived type that explicitly
disallows the element's
expanded name
. For example:





minOccurs="0"/>

minOccurs="0" maxOccurs="unbounded"/>

minOccurs="0" maxOccurs="unbounded"/>




The restriction type
quietComputer
has
lax
wildcard, which
matches
any element but one with the name
speaker
Without the specification of the
notQName
attribute,

the wildcard would
match
elements named
speaker
, as well. In that case, the restriction
would be valid only if there is a
top-level declaration for
speaker
that also has type
speakerType
or a type derived from it.
Otherwise, there would be instances locally valid against the restriction
quietComputer
that are not locally valid against the base type
computer
For example, if there is no
notQName
attribute on the wildcard and
no top-level declaration for
speaker
, then the following is allowed
by
quietComputer
, but not by
computer

The specific rule violated in this case
is clause
of
constraint
Content type restricts (Complex Content) (§3.4.6.4)
3.4.3 Constraints on XML Representations of Complex Type Definitions
Schema Representation Constraint: Complex Type Definition Representation OK
In addition to the conditions imposed on

element information items by the schema for schema documents,
all
of the following also apply:
If the

alternative is chosen,
the

element
must not
have
mixed
true
If

is present under

, then

no
facet-specifying element other than
xs:enumeration
xs:pattern
, or
xs:assertion
may
appear more than once
among the
[children]
of

If

is present
and has
mode
'none'
then there
must
be an

among the
[children]
of

If

is present
and has
mode
'none'
then there
must not
be an

among the
[children]
of

If the

alternative is chosen and the
mixed
[attribute]
is present on both

and

then
actual values
of those
[attributes]
must
be the same.
3.4.4 Complex Type Definition Validation Rules
3.4.4.1 Locally Declared Type
This section defines

the concept of
locally declared type
; this concept plays a role
in determining whether restrictions
and extensions of complex type definitions are legitimate.
The
locally declared type
is also used to help determine the
governing element declaration
and
governing type definition
of an element information item.
[Definition:]
Every
Complex Type Definition
determines a partial functional mapping from
element or attribute
information items (and their
expanded names
) to type
definitions. This mapping serves as a
locally declared type
for elements
and attributes which are allowed by
the
Complex Type Definition
The attribute case is simpler and will be taken first.
[Definition:]
For a given
Complex Type Definition
CTD
and a given attribute
information item
, the
locally declared type
of
within
CTD
is
the appropriate
case
among the following:
If
CTD
is
xs:anyType
then
absent
If
has the same
expanded name
as some
attribute declaration
which is the
{attribute declaration}
of some
Attribute Use
contained by
CTD
's
{attribute uses}
then
the
{type definition}
of
otherwise
the
locally declared type
of
within
CTD
{base type definition}
The definition for elements is slightly
more complex.
[Definition:]
For a given
Complex Type Definition
CTD
and a given element information item
, the
locally declared type
of
within
CTD
is
the appropriate
case
among the following:
If
CTD
is
xs:anyType
then
absent
If
has the same
expanded name
as
some element declaration
which is
contained
by
CTD
's
content model, whether
directly
indirectly
, or
implicitly
then
the
declared
{type definition}
of
otherwise
the
locally declared type
of
within
CTD
{base type definition}
Note:
The constraint
Element Declarations Consistent (§3.8.6.3)
ensures that even if there is more than one such declaration
, there will be just one type definition.
Note:
The reference to
implicit
containment ensures that if
has a
governing element declaration
substitutable
for a declaration
contained
by
CTD
's content model, a
locally declared type
is defined for
3.4.4.2 Element Locally Valid (Complex Type)
Validation Rule: Element Locally Valid (Complex Type)
For an element information item
to be locally
valid
with respect to a
complex type definition
all
of the following
must
be true:
If
is not
nilled
, then
all
of the following are true:
1.1
If
{content type}
{variety}
empty
then
has no character or element information item
[children]
1.2
If
{content type}
{variety}
simple
then
has no element
information item
[children]
, and the
initial value
of
is
valid
with respect
to
{content type}
{simple type definition}
as defined
by
String Valid (§3.16.4)
1.3
If
{content type}
{variety}
element-only
then
has no character information item
[children]
other
than those whose
[character code]
is defined as
white space
in
[XML 1.1]
1.4
If
{content type}
{variety}
element-only
or
{content type}
{variety}
mixed
then
the sequence of element
information items in
[children]
, if any, taken in order,
is
valid
with
respect to
{content type}
as defined in
Element Sequence Locally Valid (Complex Content) (§3.4.4.3)
For each attribute information item
in
[attributes]
excepting those named
xsi:type
xsi:nil
xsi:schemaLocation
, or
xsi:noNamespaceSchemaLocation
(see
Built-in Attribute Declarations (§3.2.7)
),
the appropriate
case
among the following is true:
2.1
If
there is among the
{attribute uses}
an
attribute use
whose
{attribute declaration}
has the same
expanded name
as
then
is locally
valid
with respect to
as per
Attribute Locally Valid (Use) (§3.5.4)
In this case
{attribute declaration}
is the
context-determined
declaration
for
with respect
to
Schema-Validity Assessment (Attribute) (§3.2.4.3)
and
Assessment Outcome (Attribute) (§3.2.5.1)
Also
is
attributed to
2.2
otherwise
all
of the following are true:
2.2.1
There is an
{attribute wildcard}
2.2.2
is
valid
with respect
to it as defined in
Item Valid (Wildcard) (§3.10.4.1)
In this case
is
attributed to
the
{attribute wildcard}
For each attribute use
in
{attribute uses}
if
{required}
true
then
{attribute declaration}
has the same
expanded name
as
one of the attribute information items in
[attributes]
Note:
It is a consequence that
(with few exceptions)
each such
will have
the matching attribute information item
attributed to
it by
clause
2.1
above.
The exceptions are
uses of
xsi:type
and the other
attributes named in
clause
2.1
; no
attribution
is performed for them.
For each
defaulted attribute
belonging to
the
{lexical form}
of
's
effective value constraint
is
valid
with
respect to
{attribute declaration}
{type definition}
as defined by
String Valid (§3.16.4)
Note:
When an
{attribute wildcard}
is
present, this does
not
introduce any ambiguity with
respect to how attribute information items for which an attribute use
is present amongst the
{attribute uses}
whose name and target namespace match are
assessed
. In such cases the attribute
use
always
takes precedence, and the
assessment
of such items stands or falls
entirely on the basis of the attribute use and its
{attribute declaration}
. This follows from the details of
clause
For each element information item in
[children]
and each attribute information item in
[attributes]
, if
neither the
governing type definition
nor the
locally declared type
is
absent
, then

the
governing type definition
is the same as, or is
validly substitutable
for, the
locally declared type
without limitation
is
valid
with respect to each of the assertions in
{assertions}
as
per
Assertion Satisfied (§3.13.4.1)
[Definition:]
defaulted attribute
belonging to an element information item
governed by
a complex type
is any
Attribute Use
for which
all
of the following are true:
is a member of
{attribute uses}
{required}
false
's
effective value constraint
is not
absent
{attribute declaration}
is not one
of the
Attribute Declaration
s from
Built-in Attribute Declarations (§3.2.7)
{attribute declaration}
does not match
any of the
attribute information items in
[attributes]
as per clause
2.1
of
Element Locally Valid (Complex Type) (§3.4.4.2)
above.
3.4.4.3 Element Sequence Locally Valid (Complex Content)
Validation Rule: Element Sequence Locally Valid (Complex Content)
For a sequence
(possibly empty) of element information items
to be locally
valid
with respect to a
Content Type
CT
the appropriate
case
among the following
must
be true:
If
CT
{open content}
is
absent
then
is
valid
with respect
to
CT
{particle}
, as defined in
Element Sequence Locally Valid (Particle) (§3.9.4.2)
If
CT
{open content}
{mode}
suffix
then
can be represented as two subsequences
S1
and
S2
(either can be empty) such that
all
of the following are true:
2.1
S1
S2
2.2
S1
is
valid
with respect
to
CT
{particle}
, as defined
in
Element Sequence Locally Valid (Particle) (§3.9.4.2)
2.3
If
S2
is not empty, let
be the first element
in
S2
, then
S1
does
not
have a
path
in
CT
{particle}
2.4
Every element in
S2
is
valid
with respect to the wildcard
CT
{open content}
{wildcard}
, as defined in
Item Valid (Wildcard) (§3.10.4.1)
otherwise
CT
{open content}
{mode}
interleave
can be represented as two subsequences
S1
and
S2
(either can be empty) such that
all
of the following are true:
3.1
is a member of
S1
S2
(where × is the interleave
operator, see
All-groups (§3.8.4.1.3)
3.2
S1
is
valid
with
respect to
CT
{particle}
, as
defined in
Element Sequence Locally Valid (Particle) (§3.9.4.2)
3.3
For every element
in
S2
, let
S3
be

the longest
prefix of
S1
where members of
S3
are before
in
, then
S3
does
not
have a
path
in
CT
{particle}
3.4
Every element in
S2
is
valid
with respect to the wildcard
CT
{open content}
{wildcard}
as defined in
Item Valid (Wildcard) (§3.10.4.1)
[Definition:]
A sequence of element information items is
locally valid
with
respect to a
Content Type
if and only if it satisfies
Element Sequence Locally Valid (Complex Content) (§3.4.4.3)
with respect to that
Content Type
3.4.4.4 Attribution
[Definition:]
During
validation
of an element
information item against its (complex)
governing type definition
associations
between element and attribute information items among the
[children]
and
[attributes]
on the one hand, and the attribute uses,
attribute wildcard, particles
and open content property record on the other, are
established. The element or attribute information item is
attributed to
the corresponding component.
When an attribute information item
has the same
expanded name
as
the
{attribute declaration}
of an
Attribute Use
, then the item is
attributed to
that
attribute use. Otherwise, if the item matches an attribute wildcard, as
described in
Item Valid (Wildcard) (§3.10.4.1)
, then the item is
attributed to
that wildcard. Otherwise the item is
not
attributed to
any component.
When a sequence
of
[child]
element information items are checked
against the
governing type definition
's
{content type}
CT
, let
S1
and
S2
be subsequences of
such that
is a member of
S1
S2
S1
is a prefix of some element sequence that is
locally valid
with respect to
CT
as defined in
Element Sequence Locally Valid (Complex Content) (§3.4.4.3)
for every element
in
S2
, let
S3
be

the longest
prefix of
S1
where members of
S3
are before
in
, then
S3
is
not
a prefix of any element sequence that is
locally valid
with respect to
CT
Then members of
S1
that form a
validation-path
in
CT
{particle}
(see
Element Sequence Locally Valid (Complex Content) (§3.4.4.3)
) are
attributed to
the particles they match up with in the
validation-path
. Other members of
S1
are
attributed to
the
{open content}
of
CT
Members of
S2
are
not
attributed to
any component.
Note:
The above definition
makes sure that
attribution
happens even when the
sequence of element information items is not
locally valid
with respect to a
Content Type
. For example, if a complex type definition has the
following content model:





and an input sequence

Then the element is
attributed
to the particle whose term is the
"a" element declaration. Similarly, is
attributed
to the "b"
particle.
[Definition:]
During
validation
, associations between
element and attribute information items among the
[children]
and
[attributes]
on the one hand, and element and attribute declarations on
the other, are also established. When an item is
attributed
to an
element particle
, then it is associated with the declaration which is the
{term}
of the particle. Similarly, when an
attribute information item is
attributed to
an
Attribute Use
then the item is associated with the
{attribute declaration}
of that
Attribute Use
. Such declarations are called the
context-determined declarations
See clause
2.1
(in
Element Locally Valid (Complex Type) (§3.4.4.2)
for attribute declarations, clause
(in
Element Sequence Locally Valid (Particle) (§3.9.4.2)
) for element declarations.
3.4.5 Complex Type Definition Information Set Contributions
3.4.5.1 Attribute Default Value
Schema Information Set Contribution: Attribute Default Value
For each
defaulted attribute
the
post-schema-validation infoset
has an attribute information item whose
properties are as below added to the
[attributes]
of the element
information item.
In addition, if necessary
namespace fixup
is performed on the element
information item for the
{attribute declaration}
's
{target namespace}
[local name]
The
{attribute declaration}
's
{name}
[namespace name]
The
{attribute declaration}
's
{target namespace}
[prefix]
If the
{attribute declaration}
has a
non-absent
{target namespace}
and the
[in-scope namespaces]
property binds
to one or more prefixes, then
a namespace prefix bound to
in the
[in-scope namespaces]
property
of the element information item in the
post-schema-validation infoset
If
more than one
prefix is
bound to
in the
[in-scope namespaces]
, it is
implementation-dependent
which of those prefixes is used.
If the
{attribute declaration}
has a
non-absent
{target namespace}
and no
prefix is bound to
in the
[in-scope namespaces]
property, then
(as described in the discussion of
namespace fixup
an
implementation-dependent
prefix.
Note:
In this case (i.e. when
namespace fixup
is performed), the
[in-scope namespaces]
property is also augmented and an appropriate
namespace attribute is added to the parent element's
[namespace attributes]
If the
{attribute declaration}
's
{target namespace}
is
absent
, then
absent
[normalized value]
The
effective value constraint
's
{lexical form}
[owner element]
The element information item being assessed.
[schema normalized value]
The
effective value constraint
's
{lexical form}
[schema actual value]
The
effective value constraint
's
{value}
[schema default]
The
effective value constraint
's
{lexical form}
[validation context]
The nearest ancestor element information item with a
[schema information]
property.
[validity]
valid
[validation attempted]
full
[schema specified]
schema
The added items

also
have
[type definition]
(and
[member type definition]
and
[member type definitions]
if appropriate) properties,
and
their lighter-weight alternatives, as specified in
Attribute Validated by Type (§3.2.5.4)
[Definition:]
When
default values are supplied for attributes,
namespace fixup
may be required, to ensure that the
post-schema-validation infoset
includes
the namespace bindings needed and maintains the consistency
of the namespace information in the infoset. To perform
namespace fixup on an element information item
for
a namespace
If the
[in-scope namespaces]
of
binds a prefix to
, no
namespace fixup is needed; the properties of
are not changed.
Otherwise, first select some prefix
which is not bound by
the
[in-scope namespaces]
of
(the choice of
prefix
is
implementation-dependent
).
Add an entry to the
[in-scope namespaces]
of
binding
to
Add a namespace attribute to the
[namespace attributes]
of
Maintain the consistency of the information set by adjusting
the namespace bindings on the descendants of
. This may
be done in either of two ways:
5.1
Add the binding of
to
to the
[in-scope namespaces]
of all
descendants of
, except where that binding is overridden
by another binding for
5.2
Add to the
[namespace attributes]
of each child of
a namespace
attribute which undeclares the binding for
(i.e. a
namespace attribute for prefix
whose
normalized value
is the empty string), unless that child already has a
namespace declaration for prefix
Note that this approach is possible
only if
[XML Namespaces 1.1]
is in use,
rather than
[Namespaces in XML 1.0]
The choice between the two methods of maintaining
consistency in the information set is
implementation-dependent
If the
namespace fixup
is occasioned by a defaulted attribute
with a non-absent target namespace, then (as noted above), the
[prefix]
of the attribute information item supplied
in the
post-schema-validation infoset
is set to
Note:
When a default value of type
QName
or
NOTATION
is applied,

it is
implementation-dependent
whether
namespace fixup
occurs; if it does not, the prefix
used in the lexical representation (in
[normalized value]
or
[schema normalized value]
) will
not necessarily map to the namespace name of the value
(in
[schema actual value]
).

To reduce problems and
confusion, users may prefer to ensure that the required namespace
information item is
present in the input infoset.
3.4.5.2 Match Information
Schema Information Set Contribution: Match Information
To allow users of the
post-schema-validation infoset
to distinguish element information
items which are
attributed
to
element particles
from those
attributed
to
wildcard particles
, if
and only if the
local
validity
of an element
information item has been assessed as defined by
Element Locally Valid (Complex Type) (§3.4.4.2)
then each attribute information item in its
[attributes]
has the following properties in the
post-schema-validation infoset
PSVI Contributions for
attribute information items
[attribute attribution]
The appropriate
case
among the following:
If
the attribute information item is
attributed
to
an
Attribute Use
then
an
item isomorphic
to
the
Attribute Use
If
the attribute information item is
attributed
to
an
{attribute wildcard}
then
an
item isomorphic
to
the attribute wildcard.
otherwise
(the item is not
attributed
to
an
Attribute Use
or an
{attribute wildcard}
absent
[match information]
A keyword indicating what kind of component the
attribute information item is
attributed
to.
The appropriate
case
among the following:
If
the item is
attributed
to an
Attribute Use
then
attribute
If
the item is
attributed
to a
strict
{attribute wildcard}
then
strict
If
the item is
attributed
to a
lax
{attribute wildcard}
then
lax
If
the item is
attributed
to a
skip
{attribute wildcard}
then
skip
otherwise
(the item is not
attributed
to
an
Attribute Use
or an
{attribute wildcard}
none
And each element information item in
its
[children]
has the following properties in the
post-schema-validation infoset
PSVI Contributions for
element information items
[element attribution]
The appropriate
case
among the following:
If
the element information item is
attributed
to
an
element particle
or a
wildcard particle
then
an
item isomorphic
to
the
Particle
If
the item is
attributed
to an
Open Content
then
an
item isomorphic
to
the
Open Content
otherwise
(the item is not
attributed
to
Particle
or an
Open Content
absent
[match information]
A keyword indicating what kind of
Particle
the
item is
attributed
to.
The appropriate
case
among the following:
If
the item is
attributed
to an
element particle
then
element
If
the item is
attributed
to a
strict
wildcard particle
then
strict
If
the item is
attributed
to a
lax
wildcard particle
then
lax
If
the item is
attributed
to a
skip
wildcard particle
then
skip
If
the item is
attributed
to an
Open Content
then
open
otherwise
(the item is not
attributed
to a
Particle
or
an
Open Content
none
3.4.6 Constraints on Complex Type Definition Schema Components
All complex type definitions (see
Complex Type Definitions (§3.4)
must
satisfy the following constraints.
3.4.6.1 Complex Type Definition Properties Correct
Schema Component Constraint: Complex Type Definition Properties Correct
All
of the following
must
be true:
The values of the properties of a complex type definition are as described in
the property tableau in
The Complex Type Definition Schema Component (§3.4.1)
, modulo the impact of
Missing Sub-components (§5.3)
If the
{base type definition}
is a simple type
definition, the
{derivation method}
is
extension
There are no circular
definitions, except for that of
xs:anyType
. That is, it is
possible to reach the definition of
xs:anyType
by repeatedly following the
{base type definition}
No two distinct members of the
{attribute uses}
have
{attribute declaration}
with the same
expanded name
If
{content type}
{open content}
is
non-absent
, then
{content type}
{variety}
is either
element-only
or
mixed
3.4.6.2 Derivation Valid (Extension)
Schema Component Constraint: Derivation Valid (Extension)
For every complex type
with
{base type definition}
where
{derivation method}
extension
the appropriate
case
among the following
must
be true:
If
is a complex type definition,
then
all
of the following are true:
1.1
{final}
does not contain
extension
1.2
{attribute uses}
is a subset of
{attribute uses}
That is, for every attribute use
in
{attribute uses}
there is an attribute use in
{attribute uses}
whose properties, recursively, are identical to
those of
1.3
If
has an
{attribute wildcard}
then
also
has one, and
{attribute wildcard}
{namespace constraint}
is a subset of
{attribute wildcard}
{namespace constraint}
, as
defined by
Wildcard Subset (§3.10.6.2)
1.4
One
of the following is true:
1.4.1
and
both
have
{content type}
{variety}
simple
and both have the same
{content type}
{simple type definition}
1.4.2
and
both have
{content type}
{variety}
empty
1.4.3
All
of the following are true:
1.4.3.1
{content type}
{variety}
element-only
or
mixed
1.4.3.2
One
of the following is true:
1.4.3.2.1
{content type}
{variety}
empty
1.4.3.2.2
All
of the following are true:
1.4.3.2.2.1
Both
and
have
{content type}
{variety}
mixed
or
both have
{content type}
{variety}
element-only
1.4.3.2.2.2
{content type}
{particle}
is a
valid
extension
of
{content type}
{particle}
as defined in
Particle Valid (Extension) (§3.9.6.2)
1.4.3.2.2.3
One or more
of the following is true:
1.4.3.2.2.3.1
{content type}
{open content}
(call it
BOT
) is
absent
1.4.3.2.2.3.2
{content type}
{open content}
(call it
EOT
) has
{mode}
interleave
1.4.3.2.2.3.3
Both
BOT
and
EOT
have
{mode}
suffix
1.4.3.2.2.4
If neither
BOT
nor
EOT
is
absent
, then
BOT
{wildcard}
{namespace constraint}
is a subset of
EOT
{wildcard}
{namespace constraint}
, as defined
by
Wildcard Subset (§3.10.6.2)
1.5
It is in principle
possible to
derive
in two steps, the first
an extension and the second a restriction (possibly
vacuous), from that type definition among its ancestors
whose
{base type definition}
is
xs:anyType
Note:
This requirement ensures that
nothing removed by a restriction is subsequently added
back by an extension in an incompatible way (for example,
with a conflicting type assignment or value
constraint).
Constructing the intermediate type definition to
check this constraint is straightforward: simply
re-order the
derivation
to put all the extension
steps first, then collapse them into a single
extension. If the resulting definition can be the
basis for a valid restriction to the desired
definition, the constraint is satisfied.
1.6
For any element or attribute information item, its
locally declared type
within
is
validly substitutable
for the
locally declared type
within
without limitation
, if neither is
absent
1.7
{assertions}
is a prefix of
{assertions}
If
is a simple type definition,
then
all
of the following are true:
2.1
{content type}
{variety}
simple
and
{content type}
{simple type definition}
2.2
{final}
does not contain
extension
[Definition:]
A complex type
is a
valid extension
of its
{base type definition}
if and only if
{derivation method}
extension
and
satisfies the constraint
Derivation Valid (Extension) (§3.4.6.2)
3.4.6.3 Derivation Valid (Restriction, Complex)
Schema Component Constraint: Derivation Valid (Restriction, Complex)
For every complex type
with
{base type definition}
where
{derivation method}
restriction
all
of the following
must
be true:
is a complex type definition whose
{final}
does not contain
restriction
One or more
of the following is true:
2.1
is
xs:anyType
2.2
All
of the following are true:
2.2.1
{content type}
{variety}
simple
2.2.2
One
of the following is true:
2.2.2.1
Let
be
{content type}
{simple type definition}
and
be
{content type}
{simple type definition}
Then
is validly derived from
as defined
in
Type Derivation OK (Simple) (§3.16.6.3)
2.2.2.2
{content type}
{variety}
mixed
and
{content type}
{particle}
is a
Particle
which is
emptiable
as
defined in
Particle Emptiable (§3.9.6.3)
2.3
All
of the following are true:
2.3.1
{content type}
{variety}
empty
2.3.2
One
of the following is true:
2.3.2.1
{content type}
{variety}
empty
2.3.2.2
{content type}
{variety}
element-only
or
mixed
, and
{content type}
{particle}
is a
Particle
which is
emptiable
as defined in
Particle Emptiable (§3.9.6.3)
2.4
All
of the following are true:
2.4.1
One
of the following is true:
2.4.1.1
{content type}
{variety}
element-only
and
{content type}
{variety}
element-only
or
mixed
2.4.1.2
and
both have
{content type}
{variety}
mixed
2.4.2
The
{content type}
of
restricts
that of
as defined
in
Content type restricts (Complex Content) (§3.4.6.4)
For every element information item
, if the
[attributes]
of
satisfy clause
and
clause
of
Element Locally Valid (Complex Type) (§3.4.4.2)
with respect to
, then they also satisfy the same
clauses with respect to
and for every attribute information item
in
[attributes]
's
default binding
for
subsumes
that defined by
For any element or
attribute information item, its
locally declared type
within
is
validly substitutable
for its
locally declared type
within
, subject to the blocking keywords
extension
list
union
}, if the item has a
locally declared type
both in
and in
{assertions}
is a prefix of
{assertions}
[Definition:]
A complex
type definition with
{derivation method}
restriction
is a
valid
restriction
of its
{base type definition}
if and only if the constraint
Derivation Valid (Restriction, Complex) (§3.4.6.3)
is
satisfied
Note:
Valid
restriction involves both a subset relation on the set of
elements valid against
and those valid against
, and a derivation relation, explicit in the
type hierarchy, between the types assigned to attributes and
child elements by
and those assigned to the same
attributes and children by
The constraint just given,
like other constraints on schemas,
must
be satisfied by every complex type
to which it
applies.
However, under certain conditions conforming processors
need not (although they
may
) detect some violations of this constraint.
If (1) the type definition being checked
has
{content type}
{particle}
{term}
{compositor}
all
and (2) an implementation is unable to determine

by examination of the schema in isolation
whether or not clause
2.4.2
is satisfied, then the implementation
may
provisionally accept the derivation.
If any instance encountered in the
assessment
episode
is valid against
but not against
{base type definition}
then the derivation of
does not satisfy this
constraint, the schema does not conform to this
specification, and no
assessment
can be performed
using that schema.
It is
implementation-defined
whether a processor (a) always
detects violations of clause
2.4.2
by examination of the schema in isolation, (b)
detects them only when some element information item
in the input document is valid against
but not
against
{base type definition}
, or (c) sometimes detects
such violations by examination of the schema in isolation
and sometimes not. In the latter case, the circumstances
in which the processor does one or the other are
implementation-dependent
3.4.6.4 Content Type Restricts (Complex Content)
Schema Component Constraint: Content type restricts (Complex Content)
[Definition:]
Content Type
(for "restriction")
with complex content (i.e. one with a
non-absent
{particle}
restricts
another
Content Type
(for
"base") with complex content
if and only if
all
of the following are true:
Every sequence of element information items which is
locally valid
with respect to
is also
locally valid
with respect to
For all sequences of element information items
ES
which are
locally valid
with respect to
, for all
elements
in
ES
's
default binding
for
subsumes
that defined by
[Definition:]
When a sequence of element information items
ES
is
locally valid
with respect to a
Content Type
CT
or when a set of attribute information items
AS
satisfies clause
and clause
of
Element Locally Valid (Complex Type) (§3.4.4.2)
with respect to a
Complex Type Definition
there is a (partial) functional mapping from
the element information items
in the sequence
ES
or the attribute information items in
AS
to a
default binding
for the item,
where the default binding is
an
Element Declaration
an
Attribute Use
or one
of the keywords
strict
lax
, or
skip
as follows:
When the item has a
governing element declaration
, the
default binding is that
Element Declaration
When the item has a
governing attribute declaration
and it is
attributed
to an
Attribute Use
, the default binding is
that
Attribute Use
When the item has a
governing attribute declaration
and it is
attributed
to an
attribute wildcard, the default binding is
an
Attribute Use
whose
{attribute declaration}
is the
governing attribute declaration
whose
{value constraint}
is
absent
, and
whose
{inheritable}
is the
governing attribute declaration
's
{inheritable}
(the other properties in the
Attribute Use
are not relevant).
When the item is
attributed
to a
strict
wildcard particle
or attribute wildcard
or an
Open Content
with a
strict
Wildcard
and
it does not have a
governing element declaration
or
governing attribute declaration
, then
the default binding is the keyword
strict
When the item is
attributed
to a
lax
wildcard particle
or attribute wildcard
or an
Open Content
with a
lax
Wildcard
and
it does not have a
governing element declaration
or
governing attribute declaration
, then
the default binding is

the keyword
lax
When the item is
attributed
to a
skip
wildcard particle
or attribute wildcard
or an
Open Content
with a
skip
Wildcard
then
the default binding is the keyword
skip
[Definition:]
default binding
(for general)
subsumes
another
default binding
(for specific) if and only if
one
of the following is true
is
skip
is
lax
and
is not
skip
Both
and
are
strict
and
are both Element Declarations and
all
of the following are true:
4.1
Either
{nillable}
true
or
{nillable}
false
4.2
Either
has no
{value constraint}
, or it is not
fixed
or
has a
fixed
{value constraint}
with
an equal or
identical
value.
4.3
{identity-constraint definitions}
is
a superset of
{identity-constraint definitions}
4.4
disallows a superset of the substitutions that
does.
4.5
's declared
{type definition}
is
validly substitutable as a restriction
for
's
declared
{type definition}
4.6
{type table}
and
{type table}
either are both
absent
or are both
present
and
equivalent
and
are both
Attribute Use
s and
all
of the following are true:
5.1
{attribute declaration}
{type definition}
is
validly
derived
from
{attribute declaration}
{type definition}
as
defined in
Type Derivation OK (Simple) (§3.16.6.3)
5.2
Let
GVC
be
's
effective value constraint
and
SVC
be
's
effective value constraint
, then
one or more
of the following is true:
5.2.1
GVC
is
absent
or has
{variety}
default
5.2.2
SVC
{variety}
fixed
and
SVC
{value}
is
equal or identical to
GVC
{value}
5.3
{inheritable}
{inheritable}
Note:
To restrict a complex type definition with a simple base type definition
to
empty
, use a simple type definition with a
fixed
value of
the empty string: this preserves the type information.
Note:
To restrict away a local element declaration that
competes
with
a wildcard, use a wildcard in the derived type that explicitly
disallows the element's
expanded name
. See the example given in
XML Representation of Complex Type Definition Schema Components (§3.4.2)
3.4.6.5 Type Derivation OK (Complex)
The following constraint defines a relation appealed to elsewhere
in this specification.
Schema Component Constraint: Type Derivation OK (Complex)
For a complex type definition (call it
, for
derived
) to be validly
derived
from a type definition (call this
, for base) subject to
the blocking keywords in
a subset of {
extension
restriction
all
of the following
must
be true:
If
and
are not the same type
definition, then the
{derivation method}
of
is not
in the subset.
One or more
of the following is true:
2.1
2.2
{base type definition}
2.3
All
of the following are true:
2.3.1
{base type definition}
xs:anyType
2.3.2
The appropriate
case
among the following is true:
2.3.2.1
If
{base type definition}
is complex,
then
it is validly
derived
from
subject to the subset as defined by this constraint.
2.3.2.2
If
{base type definition}
is simple,
then
it is validly
derived
from
subject to the subset as defined in
Type Derivation OK (Simple) (§3.16.6.3)
Note:
This constraint is used to check that when someone uses a type in a
context where another type was expected (either via
xsi:type
or
substitution groups
), that the type used is actually
derived
from the expected
type, and that that
derivation
does not involve a form of
derivation
which was
ruled out by the expected type.
Note:
The wording of clause
2.1
above appeals to a notion of component identity which
is only incompletely defined by this version of this specification.
In some cases, the wording of this specification does make clear the
rules for component identity. These cases include:
When they are both top-level components with the same component type,
namespace name, and local name;
When they are necessarily the same type definition (for example, when
the two type
definitions in question are the type definitions associated with
two attribute or element declarations, which are discovered to be the same
declaration);
When they are the same by construction (for example, when an element's
type definition defaults to being the same type definition as that of its
substitution-group head or when a complex type definition inherits an attribute
declaration from its base type definition).
In other cases
it is possible
that conforming implementations will
disagree as to whether components are identical.
Note:
When a complex type definition
is said to be
"validly
derived
" from a type definition
without mention of any specific set of blocking keywords,
or with the explicit phrase "without limitation",
then what is meant is that
is validly derived from
, subject to the empty set of blocking keywords,
i.e. without any particular limitations.
3.4.7 Built-in Complex Type Definition
There is a complex
type definition for
xs:anyType
present in every schema
by definition. It has the following properties:
Complex Type Definition of anyType
Property
Value
{name}
anyType
{target namespace}
{base type definition}
itself
{derivation method}
restriction
{content type}
Content Type
as follows:
Property
Value
{variety}
mixed
{particle}
Particle
with the properties shown
below in
Outer Particle for Content Type of anyType (§3.4.7)
{simple type definition}
absent
{attribute uses}
The empty set
{attribute wildcard}
a wildcard with the following properties::
Property
Value
{namespace constraint}
Namespace Constraint
with the following properties:
Property
Value
{variety}
any
{namespaces}
The empty set
{disallowed names}
The empty set
{process contents}
lax
{final}
The empty set
{context}
absent
{prohibited substitutions}
The empty set
{assertions}
The empty sequence
{abstract}
false
The outer particle of
xs:anyType
contains a sequence with a single term:
Outer Particle for Content Type of anyType
Property
Value
{min occurs}
{max occurs}
{term}
a model group with
the following properties:
Property
Value
{compositor}
sequence
{particles}
a list containing one particle with the properties shown
below in
Inner Particle for Content Type of anyType (§3.4.7)
The inner particle of
xs:anyType
contains a wildcard which matches any element:
Inner Particle for Content Type of anyType
Property
Value
{min occurs}
{max occurs}
unbounded
{term}
a wildcard with the following properties:
Property
Value
{namespace constraint}
Namespace Constraint
with the following properties:
Property
Value
{variety}
any
{namespaces}
The empty set
{disallowed names}
The empty set
{process contents}
lax
Note:
This specification does not provide an inventory of built-in complex
type definitions for use in user schemas. A preliminary library of complex type
definitions is available which includes both mathematical (e.g.
rational
) and utility (e.g.
array
) type definitions.
In particular, there is a
text
type definition which is recommended for use
as the type definition in element declarations intended for general text
content, as it makes sensible provision for various aspects of
internationalization. For more details, see the schema document for the type
library at its namespace name:
3.5 Attribute Uses
3.5.1
The Attribute Use Schema Component
3.5.2
XML Representation of Attribute Use Schema Components
3.5.3
Constraints on XML Representations of Attribute Uses
3.5.4
Attribute Use Validation Rules
3.5.5
Attribute Use Information Set Contributions
3.5.6
Constraints on Attribute Use Schema Components
An attribute use is a utility component which controls the occurrence and
defaulting behavior of attribute declarations. It plays the same role for
attribute declarations in complex types that particles play for element declarations.
Example

. . .




XML representations which all involve attribute uses, illustrating some of
the possibilities for controlling occurrence.
3.5.1 The Attribute Use Schema Component
The attribute use schema component has the following properties:
Schema Component:
Attribute Use
, a kind of
Annotated Component
{annotations}
A sequence of
Annotation
components.
{required}
An xs:boolean value. Required.
{attribute declaration}
An
Attribute Declaration
component. Required.
{value constraint}
Value Constraint
property record. Optional.
{inheritable}
An xs:boolean value. Required.
Property Record:
Value Constraint
{variety}
One of {
default
fixed
}. Required.
{value}
An
actual value
. Required.
{lexical form}
A character string. Required.
{required}
determines whether this use of an attribute
declaration requires an appropriate attribute information item to be present, or
merely allows it.
{attribute declaration}
provides the attribute declaration itself,
which will in turn determine the simple type definition used.
{value constraint}
allows for local
specification of a default or fixed value. This
must
be
consistent with that of the
{attribute declaration}
, in that if
the
{attribute declaration}
specifies
a fixed value, the only allowed
{value constraint}
is the same fixed value, or a value equal or
identical to it.
See
Annotations (§3.15)
for information on the role of the
{annotations}
property.
3.5.2 XML Representation of Attribute Use Schema Components
Attribute uses correspond to all uses of

which
allow a
use
attribute. These in turn correspond to
two
components in each case, an attribute use and its
{attribute declaration}
(although note the latter is not new when the attribute use is a reference to a top-level attribute declaration). The appropriate mapping is described in
XML Representation of Attribute Declaration Schema Components (§3.2.2)
3.5.3 Constraints on XML Representations of Attribute Uses
None as such.
3.5.4 Attribute Use Validation Rules
[Definition:]
The
effective value constraint
of an attribute use
is
{value constraint}
, if present, otherwise
{attribute declaration}
{value constraint}
, if present,
otherwise
the
effective value constraint
is
absent
Validation Rule: Attribute Locally Valid (Use)
For an attribute information item to be
valid
with respect to an attribute use
its
actual value
must
be equal or identical to the
{value}
of the attribute use's
{value constraint}
, if it is present and has
{variety}
fixed
3.5.5 Attribute Use Information Set Contributions
None as such.
3.5.6 Constraints on Attribute Use Schema Components
All attribute uses (see
Attribute Uses (§3.5)
must
satisfy the following constraints.
Schema Component Constraint: Attribute Use Correct
All
of the following
must
be true:
The values of the properties of an attribute use
are as
described in the property tableau in
The Attribute Use Schema Component (§3.5.1)
, modulo
the impact of
Missing Sub-components (§5.3)
If
{value constraint}
is
not
absent
, then it is a valid default with
respect to
{attribute declaration}
{type definition}
as defined in
Simple Default Valid (§3.2.6.2)
If
{attribute declaration}
has
{value constraint}
{variety}
fixed
and
itself has a
{value constraint}
, then
{value constraint}
{variety}
fixed
and
{value constraint}
{value}
is identical to
{attribute declaration}
{value constraint}
{value}
3.6 Attribute Group Definitions
3.6.1
The Attribute Group Definition Schema Component
3.6.2
XML Representation of Attribute Group Definition Schema Components
3.6.2.1
XML Mapping Rule for Named Attribute Groups
3.6.2.2
Common Rules for Attribute Wildcards
3.6.3
Constraints on XML Representations of Attribute Group Definitions
3.6.4
Attribute Group Definition Validation Rules
3.6.5
Attribute Group Definition Information Set
Contributions
3.6.6
Constraints on Attribute Group Definition Schema Components
A schema can name a group of attribute declarations so that they can be incorporated as a
group into complex type definitions.
Attribute group definitions do not participate in
validation
as such, but the
{attribute uses}
and
{attribute wildcard}
of one or
more complex type definitions
may
be constructed in whole or part by reference
to an attribute group. Thus, attribute group definitions provide a
replacement for some uses of XML's
parameter entity
facility.
Attribute group definitions are provided primarily for reference from the XML
representation of schema components
(see

and

).
Example


. . .

. . .


XML representations for attribute group definitions. The effect is as if the attribute
declarations in the group were present in the type definition.
The example above illustrates the pattern
mentioned in
XML Representations of Components (§3.1.2)
: The same
element, in this case
attributeGroup
, serves both to
define and to incorporate by reference. In the first
attributeGroup
element in the example, the
name
attribute is required and the
ref
attribute is forbidden; in the second the
ref
attribute is required, the
name
attribute is forbidden.
3.6.1 The Attribute Group Definition Schema Component
The attribute group definition schema component has the
following properties:
Schema Component:
Attribute Group Definition
, a kind of
Annotated Component
{annotations}
A sequence of
Annotation
components.
{name}
An xs:NCName value. Required.
{target namespace}
An xs:anyURI value. Optional.
{attribute uses}
A set of
Attribute Use
components.
{attribute wildcard}
Wildcard
component. Optional.
Attribute groups are identified by their
{name}
and
{target namespace}
; attribute group identities
must
be unique within an
XSD schema
. See
References to schema components across namespaces (

) (§4.2.6)
for the use of component
identifiers when importing one schema into another.
{attribute uses}
is
a set of
attribute uses, allowing
for local specification of occurrence and default or fixed values.
{attribute wildcard}
provides for an attribute wildcard to be included in an
attribute group.
See above under
Complex Type Definitions (§3.4)
for the
interpretation of
attribute wildcards during
validation
See
Annotations (§3.15)
for information on the role of the
{annotations}
property.
3.6.2 XML Representation of Attribute Group Definition Schema Components
3.6.2.1 XML Mapping Rule for Named Attribute Groups
The XML representation for an attribute group definition
schema component is an

element information item. It provides for naming a group of
attribute declarations and an attribute wildcard for use by
reference in the XML representation of complex type definitions
and other attribute group definitions. The correspondences between the
properties of the information item
after the appropriate
pre-processing
and the
properties of the
component it corresponds to are given in this section.
XML Representation Summary
attributeGroup
Element Information Item
id =
ID
name =
NCName
ref =
QName
{any attributes with non-schema namespace . . .}
Content:
annotation
?, ((
attribute
attributeGroup
)*,
anyAttribute
?))

When an

appears as a child of

or

, it corresponds to an
attribute group definition as below. When it appears as a
child of

or

, it does
not correspond to any component as such.
Note:
If the

is a child of

and it overrides a corresponding declaration in the
target set
of its parent,
it will also correspond to
an attribute group definition as shown below.
See
Overriding component definitions (

) (§4.2.5)
for details.
XML Mapping Summary for
Attribute Group Definition
Schema Component
Property
Representation
{name}
The
actual value
of the
name
[attribute]
{target namespace}
The
actual value
of the
targetNamespace
[attribute]
of the

ancestor

element information item if present, otherwise
absent
{attribute uses}
The union of the set of attribute uses corresponding to the

[children]
, if any, with the
{attribute uses}
of the attribute groups
resolved
to by the
actual value
s of the
ref
[attribute]
of the

[children]
, if any.
Note:
As described below, circular references from

to

are not errors.
{attribute wildcard}
The
Wildcard
determined by
applying the attribute-wildcard mapping described
in
Common Rules for Attribute Wildcards (§3.6.2.2)
to the

element information item.
{annotations}
The
annotation mapping
of the

element and
its

[children]
, if present,
as defined in
XML Representation of Annotation Schema Components (§3.15.2)
Note:
It is a consequence of this rule and the rule in
XML Representation of Complex Type Definition Schema Components (§3.4.2)
that any annotations specified in attribute group references are included in
the sequence of
Annotation
s of the enclosing
Complex Type Definition
or
Attribute Group Definition
components.
The rules given above for
{attribute uses}
and
{attribute wildcard}
specify that
if an

element
contains a reference
to another attribute group
(i.e.
's
[children]
include an

with a
ref
attribute pointing
at
), then
maps to an
Attribute Group Definition
component whose
{attribute uses}
reflect not only
the

[children]
of
but also those of
and of any

elements referred
to in
. The same is true for attribute groups referred to from
complex types.
Circular reference is
not
disallowed. That is, it
is not an error if
, or some

element referred to by
(directly, or indirectly at some
remove) contains a reference to
. An

element involved in such a reference cycle maps to a
component whose
{attribute uses}
and
{attribute wildcard}
properties
reflect all the

and

elements contained in, or referred to (directly or indirectly)
by elements in the cycle.
Note:
In version 1.0 of this specification, circular group reference was not
allowed except in the
[children]
of

As described above, this version allows it.
The effect is to take the transitive closure of the
reference relation between

elements and take into account
all their
{attribute uses}
and
{attribute wildcard}
properties.
3.6.2.2 Common Rules for Attribute Wildcards
The following mapping for attribute-wildcards forms part of the
XML mapping rules for different kinds of source declaration
(most prominently

). It can be
applied to any element which can have an

element as a child, and produces as a result either a
Wildcard
or the special value
absent
The mapping depends on the concept of the
local wildcard
[Definition:]
The
local wildcard
of
an element information item
is the appropriate
case
among the following:
If
has
an

child,
then
the
Wildcard
mapped to by the

element using the wildcard
mapping set out in
XML Representation of Wildcard Schema Components (§3.10.2)
otherwise
absent
The mapping is defined as follows:
Let
be the
local wildcard
Let
be a sequence containing all the
non-absent
{attribute wildcard}
of the attribute groups referenced
by
, in document order.
The value is then determined by the appropriate
case
among the following:
3.1
If
is empty,
then
the
local
wildcard
3.2
otherwise
the appropriate
case
among the following:
3.2.1
If
is
non-absent
then
a wildcard whose
properties are as follows:
Property
Value
{process contents}
{process contents}
{annotations}
{annotations}
{namespace constraint}
the
wildcard intersection

of
{namespace constraint}
and of the
{namespace constraint}
s of all
the the wildcards in
as defined in
Attribute Wildcard Intersection (§3.10.6.4)
3.2.2
otherwise
(no

is
present)
a wildcard whose properties are as follows:
Property
Value
{process contents}
The
{process contents}
of the first
wildcard in
{namespace constraint}
The wildcard intersection

of the
{namespace constraint}
of all the wildcards in
as defined in
Attribute Wildcard Intersection (§3.10.6.4)
{annotations}
The empty sequence
3.6.3 Constraints on XML Representations of Attribute Group Definitions
Schema Representation Constraint: Attribute Group Definition Representation OK
None as such.
3.6.4 Attribute Group Definition Validation Rules
None as such.
3.6.5 Attribute Group Definition Information Set
Contributions
None as such.
3.6.6 Constraints on Attribute Group Definition Schema Components
All attribute group definitions (see
Attribute Group Definitions (§3.6)
must
satisfy the following constraint.
Schema Component Constraint: Attribute Group Definition Properties Correct
All
of the following
must
be true:
The values of the properties of an attribute group definition
are as described in the property tableau in
The Attribute Group Definition Schema Component (§3.6.1)
, modulo the impact
of
Missing Sub-components (§5.3)
No two
distinct members of the
{attribute uses}
have
{attribute declaration}
s with the same
expanded name
3.7 Model Group Definitions
3.7.1
The Model Group Definition Schema Component
3.7.2
XML Representation of Model Group Definition Schema Components
3.7.3
Constraints on XML Representations of Model Group Definitions
3.7.4
Model Group Definition Validation Rules
3.7.5
Model Group Definition Information Set Contributions
3.7.6
Constraints on Model Group Definition Schema Components
A model group definition associates a name and optional annotations with
Model Group
By reference to the name, the entire model group can be incorporated by reference into
{term}
Model group definitions are provided
primarily for reference from the
XML Representation of Complex Type Definition Schema Components (§3.4.2)
(see

and

). Thus, model group definitions provide a
replacement for some uses of XML's
parameter entity
facility.
Example



. . .

A minimal model group is defined and used by reference, first as the whole
content model, then as one alternative in a choice.
3.7.1 The Model Group Definition Schema Component
The model group definition schema component has the following
properties:
Schema Component:
Model Group Definition
, a kind of
Annotated Component
{annotations}
A sequence of
Annotation
components.
{name}
An xs:NCName value. Required.
{target namespace}
An xs:anyURI value. Optional.
{model group}
Model Group
component. Required.
Model group definitions are identified by their
{name}
and
{target namespace}
; model group identities
must
be unique within an
XSD schema
. See
References to schema components across namespaces (

) (§4.2.6)
for the use of component
identifiers when importing one schema into another.
Model group definitions
per se
do not participate in
validation
, but the
{term}
of
a particle
may
correspond in whole or in part
to a model group from a model group definition.
{model group}
is the
Model Group
for which the model group definition provides a name.
See
Annotations (§3.15)
for information on the role of the
{annotations}
property.
3.7.2 XML Representation of Model Group Definition Schema Components
The XML representation for a model group definition schema component is a

element information item.
It provides for
naming a model group for use by reference in the XML representation of
complex type definitions and model groups. The correspondences between the
properties of the information item
after the appropriate
pre-processing
and the
properties of the component it corresponds to are given in this section.
XML Representation Summary
group
Element Information Item
id =
ID
maxOccurs =

nonNegativeInteger
unbounded
: 1
minOccurs =
nonNegativeInteger
: 1
name =
NCName
ref =
QName
{any attributes with non-schema namespace . . .}
Content:
annotation
?, (
all
choice
sequence
)?)

If

the item has

or

as its parent (in which case there will be a
name
[attribute]
then the item maps
to a model group definition component with properties as
follows:
Note:
If the item is a child of

, it will
also have a
name
[attribute]
; if it overrides
a corresponding declaration in the
target set
of its parent, it will also (in the
overridden schema document) map to a component as described
below. See
Overriding component definitions (

) (§4.2.5)
for details.
XML Mapping Summary for
Model Group Definition
Schema Component
Property
Representation
{name}
The
actual value
of the
name
[attribute]
{target namespace}
The
actual value
of
the
targetNamespace
[attribute]
of the

ancestor element information
item if present, otherwise
absent
{model group}
A model group which is
the
{term}
of a particle
corresponding to the


or

among the
[children]
(there
must
be exactly one).
{annotations}
The
annotation mapping
of the

element, as defined in
XML Representation of Annotation Schema Components (§3.15.2)
Otherwise,
if
the item
has
ref
[attribute]
and does
not
have
minOccurs=maxOccurs=0
, then
the

element maps
to a particle component with properties
as follows:
XML Mapping Summary for
Particle
Schema Component
Property
Representation
{min occurs}
The
actual value
of the
minOccurs
[attribute]
, if present, otherwise
{max occurs}
unbounded
, if the
maxOccurs
[attribute]
equals
unbounded
, otherwise the
actual value
of the
maxOccurs
[attribute]
, if present, otherwise
{term}
The
{model group}
of the model group definition
resolved
to by the
actual value
of the
ref
[attribute]
{annotations}
The
annotation mapping
of the

element, as defined in
XML Representation of Annotation Schema Components (§3.15.2)
Otherwise, the

has
minOccurs=maxOccurs=0
, in which
case it maps to no component at all.
Note:
The name of this section is slightly misleading, in that the
second, un-named, case above (with a
ref
and no
name
) is not really a named model group at all, but
a reference to one. Also note that in the first (named) case
above no reference is made to
minOccurs
or
maxOccurs
: this is because the schema for schema documents does not
allow them on the child of

when it is
named. This in
turn is because the
{min occurs}
and
{max occurs}
of the particles which
refer
to the definition are what count.
3.7.3 Constraints on XML Representations of Model Group Definitions
None as such.
3.7.4 Model Group Definition Validation Rules
None as such.
3.7.5 Model Group Definition Information Set Contributions
None as such.
3.7.6 Constraints on Model Group Definition Schema Components
All model group definitions (see
Model Group Definitions (§3.7)
must
satisfy the following constraint.
Schema Component Constraint: Model Group Definition Properties Correct
The values of the properties of a model group definition
must
be as described in
the property tableau in
The Model Group Definition Schema Component (§3.7.1)
, modulo the impact of
Missing Sub-components (§5.3)
3.8 Model Groups
3.8.1
The Model Group Schema Component
3.8.2
XML Representation of Model Group Schema Components
3.8.3
Constraints on XML Representations of Model Groups
3.8.4
Model Group Validation Rules
3.8.4.1
Language Recognition by Groups
3.8.4.2
Principles of Validation against Groups
3.8.4.3
Element Sequence Valid
3.8.5
Model Group Information Set Contributions
3.8.6
Constraints on Model Group Schema Components
3.8.6.1
Model Group Correct
3.8.6.2
All Group Limited
3.8.6.3
Element Declarations Consistent
3.8.6.4
Unique Particle Attribution
3.8.6.5
Effective Total Range (all and sequence)
3.8.6.6
Effective Total Range (choice)
When the
[children]
of element information items are not constrained
to be
empty
or by reference to a simple type definition
Simple Type Definitions (§3.16)
), the sequence of element
information item
[children]
content
may
be specified in
more detail with a model group. Because the
{term}
property of a particle can be a
model group, and model groups contain particles, model groups can indirectly
contain other model groups; the grammar for model groups
is therefore recursive.
[Definition:]
A model group
directly contains
the particles in the value of its
{particles}
property.
[Definition:]
A model group
indirectly contains
the particles, groups, wildcards, and
element declarations which are
contained
by the particles it
directly contains
[Definition:]
A model group
contains
the components which it either
directly contains
or
indirectly contains
Example

XML representations for the three kinds of model group, the third nested
inside the second.
3.8.1 The Model Group Schema Component
The model group schema component has the following
properties:
Schema Component:
Model Group
, a kind of
Term
{annotations}
A sequence of
Annotation
components.
{compositor}
One of {
all
choice
sequence
}. Required.
{particles}
A sequence of
Particle
components.
specifies a sequential (
sequence
),
disjunctive (
choice
) or conjunctive (
all
) interpretation of
the
{particles}
. This in turn
determines whether the element
information item
[children]
validated
by the model group
must
sequence
) correspond, in order, to the specified
{particles}
choice
) correspond
to exactly one of the specified
{particles}
all
) correspond to the specified
{particles}
. The elements can occur in any
order.
When two or more
element declarations contained
directly
indirectly
, or
implicitly
in the
{particles}
of a model group have identical names, the type definitions of those declarations
must
be the
same.
See
Annotations (§3.15)
for information on the role of the
{annotations}
property.
3.8.2 XML Representation of Model Group Schema Components
The XML representation for a model group schema component is
either an

, a

or a

element information item. The correspondences between the
properties of those information items
after the appropriate
pre-processing
and the
properties of the component they correspond to are given in this section.
XML Representation Summary
all
Element Information Item et al.
id =
ID
maxOccurs = (
) : 1
minOccurs = (
) : 1
{any attributes with non-schema namespace . . .}
Content:
annotation
?, (
element
any
group
)*)

id =
ID
maxOccurs =

nonNegativeInteger
unbounded
: 1
minOccurs =
nonNegativeInteger
: 1
{any attributes with non-schema namespace . . .}
Content:
annotation
?, (
element
group
choice
sequence
any
)*)

id =
ID
maxOccurs =

nonNegativeInteger
unbounded
: 1
minOccurs =
nonNegativeInteger
: 1
{any attributes with non-schema namespace . . .}
Content:
annotation
?, (
element
group
choice
sequence
any
)*)

Each of the
above items corresponds to a particle containing a model group,
with properties as follows (unless
minOccurs=maxOccurs=0
in which case the item corresponds to no component at all):
XML Mapping Summary for
Particle
Schema Component
Property
Representation
{min occurs}
The
actual value
of the
minOccurs
[attribute]
, if present, otherwise
{max occurs}
unbounded
, if the
maxOccurs
[attribute]
equals
unbounded
, otherwise the
actual value
of the
maxOccurs
[attribute]
, if present, otherwise
{term}
A model group as given below.
{annotations}
The same annotations as the
{annotations}
of
the model group. See below.
The particle just described has a
Model Group
as the value of its
{term}
property, as follows.
XML Mapping Summary for
Model Group
Schema Component
Property
Representation
{compositor}
One of
all
choice
sequence
depending on the element
information item.
{particles}
A sequence of particles
corresponding to all the





or

items among
the
[children]
, in order.
{annotations}
The
annotation mapping
of the


, or

element, whichever is present, as defined
in
XML Representation of Annotation Schema Components (§3.15.2)
3.8.3 Constraints on XML Representations of Model Groups
None as such.
3.8.4 Model Group Validation Rules
In order to define the validation rules for model
groups clearly, it will be useful to define some basic terminology;
this is done in the next two sections, before the validation rules
themselves are formulated.
3.8.4.1 Language Recognition by Groups
Each model group
denotes a language
), whose members are the sequences of element information items
accepted
by
Within
) a smaller language
) can be
identified, which is of particular importance for schema-validity
assessment. The difference between the two languages is that
) enforces some constraints which are ignored in the definition
of
).
Informally
) is the set of sequences which are accepted by a model
group if no account is taken of the schema component
constraint
Unique Particle Attribution (§3.8.6.4)
or the related provisions
in the validation rules which specify how to choose a unique
path
in a non-deterministic model group. By contrast,
) takes
account of those constraints and includes only the sequences which are
locally valid
against
. For all model groups
) is a
subset of
).
) and related concepts are described in this
section;
) is described in the next section,
Principles of Validation against Groups (§3.8.4.2)
[Definition:]
When a sequence
of element information
items is checked against a model group
, the sequence of
basic particles
which the items of
match, in order, is a
path
of
in
. For a given
and
, the
path of
in
is not necessarily unique.
Detailed rules for the matching, and thus for the construction of
paths, are given in
Language Recognition by Groups (§3.8.4.1)
and
Principles of Validation against Particles (§3.9.4.1)
Not every sequence has a path in every model group, but every
sequence accepted by the model group does have a path.
[Definition:]
For
a model group
and a sequence
in
), the path
of
in
is a
complete path
; prefixes of
complete paths which are themselves not complete paths
are
incomplete paths
For example, in the model group





the sequences (

and (

) have
paths
(the first a
complete path
and the second
an
incomplete path
),
but the sequences (

) and

) do not
have paths.
Note:
It is possible, but unusual, for a model group to
have some paths which are neither complete paths, nor
prefixes of complete paths. For example, the model group





accepts no sequences because the empty
choice
recognizes
no input sequences. But the sequences (

and (

) have paths in the model group.
The definitions of
) and
paths
in
, when
is a
basic term
or
basic particle
, are given in
Principles of Validation against Particles (§3.9.4.1)
. The definitions for groups are
given below.
3.8.4.1.1 Sequences
This section defines
), the set of
paths
in
, and
), if
is a sequence group.
If
is a
Model Group
and the
{compositor}
of
is
sequence
and the
{particles}
of
is the sequence
, ...,
, then
) is the set of sequences
+ ... +
Sn
(taking "+" as the concatenation operator), where
is in
) for 0 <
The sequence of sequences
, ...,
Sn
is a
partition
of
Less formally, when
is a sequence of
, ...
, then
) is the set of sequences formed by taking one sequence which is
accepted by
, then one accepted by
, and so on, up through
, and then concatenating them together in order.
[Definition:]
partition
of a sequence is a sequence of sub-sequences,
some or all of which
may
be empty, such that concatenating all
the sub-sequences yields the original sequence
When
is a sequence group
and
is a sequence of input items, the set of
paths
of
in
is the set of all
paths
+ ... +
, where
, and
+ ... +
(i.e.
, ...,
is
partition
of
), and
is in
) for 0 <
, and
is a
path
of
in
for 0 <
Example
By this definition, some sequences which do not satisfy the
entire model group nevertheless have
paths
in a model group.
For example, given the model group





and an input sequence

where
= 3,
= 2, then
is (

),
is (

),
and
has a
path
in
, even though
is not in
). The
path
has two items, first the
Particle
for the
element, then the
Particle
for the
element.
When
is a sequence group,
the set
) (the set of sequences
locally valid
against
) is the set of sequences
which
are in
) and which have a
validation-path
in
Informally,
) contains those sequences which are
accepted by
and for which no element information item
is ever
attributed to
wildcard particle
if it can, in
context, instead be
attributed to
an
element particle
There will invariably be a
partition
of
whose
members are
locally valid
against
{particles}
of
Note:
For sequences with more than one
path
in
the
attributions
of
the
validation-path
are used in validation and for determining
the contents of the
post-schema-validation infoset
. For example, if
is




then the sequence (

) has two
paths
in
, one containing just the
wildcard particle
and the other
containing just the
element particle
. It is the latter
which is a
validation-path
and which determines which
Particle
the item in the input is
attributed to
Note:
There are model groups for which some members of
) are not in
). For example, if
is




then the sequence (

) is in
), but not
in
), because the validation rules require that the first
be
attributed to
the
wildcard particle
In a
validation-path
the initial
will invariably be
attributed to
the
element particle
, and so no sequence
with an initial
can be
locally valid
against
this model group.
3.8.4.1.2 Choices
This section defines
), the set of
paths
in
, and
), if
is a choice group.
When the
{compositor}
of
is
choice
, and the
{particles}
of
is the sequence
, ...,
then
) is
) ∪
) ∪ ... ∪
),
and the set of
paths
of
in
is the set
∪ ... ∪
, where
is the set of
paths
of
in
, for
0 <
Less formally, when
is a choice of
, ...
, then
) contains any sequence accepted by any of the particles
, ...
and any
path
of
in any of the particles
, ...
is a
path
of
in
The set
) (the set of sequences
locally valid
against
) is the set of sequences
which
are in
) and which have a
validation-path
in
In effect, this means that if one of the choices in
attributes
an initial element information item to
wildcard particle
, and another
attributes
the same
item to an
element particle
, then the latter choice is used
for validation.
Note:
For example, if
is




then the
validation-path
for the sequence (

contains just the
element particle
and it is to the
element particle
that the input element will be
attributed
; the alternate
path
containing just the
wildcard particle
is not relevant for
validation as defined in this specification.
3.8.4.1.3 All-groups
This section defines
), the set of
paths
in
, and
), if
is an all-group.
When the
{compositor}
of
is
all
, and the
{particles}
of
is the sequence
, ...,
then
) is the set of sequences
× ... ×
Sn
(taking "×" as the interleave operator),
where
for 0 <
is in
).
The set of sequences
, ...,
Sn
} is a
grouping
of
The set of
paths
of
in
is
the set of all
paths
× ... ×
where
is a
path
of
in
for 0 <
Less formally, when
is an
all
-group of
, ...
, then
) is the set of sequences formed by taking one sequence which
is accepted by
then one accepted by
and so on, up through
, and then interleaving them
together. Equivalently,
) is the set of sequences
such that the set {
, ...,
Sn
} is a
grouping
of
, and
for 0 <
is in
).
[Definition:]
grouping
of a sequence is a set of sub-sequences, some or
all of which may be empty, such that each member of the original
sequence appears once and only once in one of the sub-sequences and
all members of all sub-sequences are in the original
sequence.
For example, given the model group





and an input sequence

where
= 3, then
is (

),
is (

),
and the
path
of
in
is the sequence containing first the
Particle
for the
element, then the
Particle
for the
element, then once more the
Particle
for the
element.
The set
) (the set of sequences
locally valid
against
) is the set of sequences
which
are in
) and which have a
validation-path
in
In effect, this means that if one of the
Particles
in
attributes
an element information item to
wildcard particle
, and a
competing
Particle
attributes
the same item to an
element particle
, then the
element particle
is used for validation.
Note:
For example, if
is




then
accepts sequences of length two, containing
one
element and one other element.
The other element can be anything at all, including a second
element. After the first
the
element particle
accepts no more elements
and so no longer
competes
with the
wildcard particle
So if the sequence (

is checked against
, in the
validation-path
the
first
element will be
attributed to
the
element particle
and the second to the
wildcard particle
If the intention is not to allow the second
use a wildcard that explicitly disallows it. That is,




Now the sequence (

) is not
accepted by the particle.
3.8.4.1.4 Multiple Paths in Groups
It is possible for a given sequence of element information items
to have multiple
paths
in a given model group
; this is
the case, for example, when
is ambiguous, as for example










which can match the sequence (

in more than one way.
It may also be the case with unambiguous model groups, if
they do not correspond to a
deterministic
expression (as it is termed in
[XML 1.1]
or a "1-unambiguous" expression, as it
is defined by
[Brüggemann-Klein / Wood 1998]
For example,




Note:
Because these model groups do not obey the
constraint
Unique Particle Attribution (§3.8.6.4)
, they cannot
appear in a conforming schema.
3.8.4.2 Principles of Validation against Groups
As noted above, each model group
denotes a
language
), whose members are sequences of element information
items. Each member of
) has one or more
paths
in
, as do
other sequences of element information items.
By imposing conditions on
paths
in a model group
it is possible to identify a set of
validation-paths
in
such that if
is a
model group which obeys the
Unique Particle Attribution (§3.8.6.4)
constraint, then
any sequence
has at most one
validation-path
in
The language
) can then be defined as the set of
sequences which have
validation-paths
in
[Definition:]
Two
Particles
and
contained in some
Particle
compete
with each other if and only if some sequence
of element information items has two
paths
in
which are
identical except that one path has
as its last item and the other
has
For example, in the content model







the sequence (

) has two paths,
one (
) consisting of the
Particle
whose
{term}
is
the declaration for
followed by the
Particle
whose
{term}
is
the declaration for
, and
a second (
) consisting of the
Particle
whose
{term}
is
the declaration for
followed by the
Particle
whose
{term}
is
the wildcard. The sequences
and
are
identical except for their last items, and so the
two
Particles
which are the last items of
and
are said to
compete
with each other.
By contrast, in the content model










the
Particles
for
and the
wildcard do not
compete
, because there is no
pair of
paths
in
which differ only in one
having the
element particle
for
and
the other having the
wildcard particle
[Definition:]
Two
(or more)
paths
of a sequence
in a
Particle
are
competing paths
if and only if
they are identical except for their final items, which
differ.
[Definition:]
For any sequence
of element
information items and any particle
, a
path
of
in
is a
validation-path
if and only if for each
prefix of the
path
which ends with a
wildcard particle
, the
corresponding prefix of
has no
competing path
which
ends with an
element particle
Note:
It is a consequence of the definition of
validation-path
that for
any content model
which obeys constraint
Unique Particle Attribution (§3.8.6.4)
and for any sequence
of
element information items,
has at most one
validation-path
in
[Definition:]
A sequence
of
element information items is
locally valid
against
a particle
if and only if
has a
validation-path
in
. The set of all such
sequences is written
).
3.8.4.3 Element Sequence Valid
Validation Rule: Element Sequence Valid
For a sequence
(possibly empty) of element information items to be
locally
valid
with respect to
a model group
must
be in
).
Note:
It is possible to define groups whose
{particles}
is empty. When a
choice
-group
has an empty
{particles}
property, then
) is the empty set.
When
is a
sequence
- or
all
-group with an empty
{particles}
property, then
) is the set containing the empty (zero-length) sequence.
3.8.5 Model Group Information Set Contributions
None as such.
3.8.6 Constraints on Model Group Schema Components
All model groups (see
Model Groups (§3.8)
must
satisfy the following constraints.
3.8.6.1 Model Group Correct
Schema Component Constraint: Model Group Correct
All
of the following
must
be true:
The values of the properties of a model group are as
described in the property tableau in
The Model Group Schema Component (§3.8.1)
, modulo the impact of
Missing Sub-components (§5.3)
There are no circular
groups. That is, within the
{particles}
of a group there
is no
particle at any depth whose
{term}
is the group itself.
3.8.6.2 All Group Limited
Schema Component Constraint: All Group Limited
When a model group has
{compositor}
all
, then
all
of the following
must
be true:
It appears only as the value of one or more of the following properties:
1.1
the
{model group}
property of a model group definition.
1.2
the
{term}
property of a
Particle
with
{max occurs}
= 1
which is

the
{particle}
of the
{content type}
of a complex
type definition.
1.3
the
{term}
property of a
Particle
with
{min occurs}
{max occurs}
= 1
, where
is among the
{particles}
of a
Model Group
whose
{compositor}
is
all
For every particle
in its
{particles}
if
{term}
is a model group,
then
{term}
{compositor}
all
3.8.6.3 Element Declarations Consistent
Schema Component Constraint: Element Declarations Consistent
If the
{particles}
property contains, either
directly, indirectly (that is, within the
{particles}
property of a
contained model group, recursively),
or
implicitly
, two or more
element
declarations with the same
expanded name
, then all their type
definitions
must
be the same top-level definition, that is,
all
of the following
must
be true:
All
their declared
{type definition}
s have a
non-absent
{name}
All
their
declared
{type definition}
s have the same
{name}
All
their
declared
{type definition}
s have the same
{target namespace}
All their
{type table}
s are either
all
absent
or else all are present and
equivalent
If
all
of the following are true:
The
{particles}
property contains (either directly,
indirectly, or
implicitly
) one or more
element declarations with the same
expanded name
call these element
declarations
EDS
At least
one
of the following is true
2.1
The
{particles}
property contains one or more
strict
or
lax
wildcard particles
which
match
2.2
The
Model Group
is the
{term}
of the
content model
of some
Complex Type Definition
CTD
and
CTD
{content type}
has an
{open content}
with a
strict
or
lax
Wildcard
which
matches
There exists a top-level element declaration
with the
expanded name
then the
{type table}
s of
EDS
and the
{type table}
of
must
either
all be
absent
or else all be present and
equivalent
[Definition:]
A list
of particles
implicitly contains
an element declaration if and only if a
member of the list contains that
element declaration in its
substitution group
[Definition:]
Type Table
T1
is
equivalent
to a
Type Table
T2
if and only if
all
of the following are true:
T1
{alternatives}
has the same length as
T2
{alternatives}
and their
corresponding entries are
equivalent
T1
{default type definition}
and
T2
{default type definition}
are
equivalent
[Definition:]
Any
Type Alternative
is
equivalent
to itself.
Otherwise, any
Type Alternative
T1
is
equivalent
to a different
Type Alternative
T2
if and only if
T1
{test}
and
T2
{test}
are true for the same
set of input element information items
and
T1
{type definition}
and
T2
{type definition}
accept
the same set of input information items as valid.
In the general case, equivalence and non-equivalence
can be difficult to establish.
It is
implementation-defined
under just what conditions a
processor detects that two type
alternatives are equivalent, but all
processors
must
detect
T1
and
T2
as
equivalent if
all
of the following are true:
T1
{test}
{namespace bindings}
and
T2
{test}
{namespace bindings}
have the same number of
Namespace Binding
s, and for each entry in
T1
{test}
{namespace bindings}
there is a corresponding entry in
T2
{test}
{namespace bindings}
with the same
{prefix}
and
{namespace}
T1
{test}
{default namespace}
and
T2
{test}
{default namespace}
either are both
absent
or have the same value.
T1
{test}
{base URI}
and
T2
{test}
{base URI}
either are both
absent
or have the same value.
T1
{test}
{expression}
and
T2
{test}
{expression}
have the same value.
T1
{type definition}
and
T2
{type definition}
are the same type definition.
A processor
may
treat two type alternatives as
non-equivalent if they do not satisfy the conditions just
given and the processor does not detect that they
are nonetheless equivalent.
Note:
In the general case, equivalence can be
difficult to prove, so the minimum required of implementations
is kept relatively simple. Schema authors can avoid
interoperability issues by ensuring that any type alternatives
for which equivalence must be established do satisfy
the tests above.
Implementations
may
recognize cases
when differences of namespace bindings, base URIs,
and white space in the XPath expression do not affect
the meaning of the expression.
3.8.6.4 Unique Particle Attribution
[Definition:]
An
element particle
is a
Particle
whose
{term}
is an
Element Declaration
[Definition:]
wildcard particle
is a
Particle
whose
{term}
is a
Wildcard
Wildcard particles may be
referred to as "strict", "lax",
or "skip" particles,
depending on the
{process contents}
property
of their
{term}
Schema Component Constraint: Unique Particle Attribution
A content model
must not
contain two
element particles
which
compete
with each other, nor two
wildcard particles
which
compete
with each other.
Note:
Content models in which an
element particle
and a
wildcard particle
compete
with each other are
not
prohibited.
In such cases, the
Element Declaration
is chosen;
see the definitions of
attribution
and
validation-path
Note:
This constraint reconstructs for XSD the equivalent
constraints of
[XML 1.1]
and SGML. See
Analysis of the Unique Particle Attribution Constraint (non-normative) (§J)
for further
discussion.
Since this constraint is expressed at the component level, it
applies to content models whose origins (e.g. via type
derivation
and
references to named model groups) are no longer evident. So particles at
different points in the content model are always distinct from one another,
even if they originated from the same named model group.
Note:
It is a consequence of
Unique Particle Attribution (§3.8.6.4)
, together with
the definition of
validation-path
, that any sequence
of element
information items has at most one
validation-path
in any particle
This means in turn that each item in
is attributed to at most one particle in
No item can match more than one
Wildcard
or more than one
Element Declaration
(because no two
wildcard particles
and no two
element particles
may
compete
), and if an item matches
both a
wildcard particle
and an
element particle
, it is
attributed
by
the rules for
validation-paths
to the
element particle
Note:
Because locally-scoped element declarations sometimes
have and sometimes do not have a
{target namespace}
, the scope of
declarations is
not
relevant to enforcing either
the
Unique Particle Attribution (§3.8.6.4)
constraint or the
Element Declarations Consistent (§3.8.6.3)
constraint.
3.8.6.5 Effective Total Range (
all
and
sequence
The following constraints define relations appealed to elsewhere in this specification.
Schema Component Constraint: Effective Total Range (
all
and
sequence
The effective total range of a particle
whose
{term}
is a group
whose
{compositor}
is
all
or
sequence
is a pair of minimum and maximum, as follows:
minimum
The product of
{min occurs}
and the
sum of the
{min occurs}
of every wildcard or element
declaration particle in
{particles}
and the minimum
part of the effective total range of each of the group particles in
{particles}
(or
if there are no
{particles}
).
maximum
unbounded
if the
{max occurs}
of any wildcard or element
declaration particle in
{particles}
or the maximum
part of the effective total range of any of the group particles in
{particles}
is
unbounded
or if any of those is non-zero
and
{max occurs}
unbounded
otherwise the product of
{max occurs}
and the
sum of the
{max occurs}
of every wildcard or element
declaration particle in
{particles}
and the maximum
part of the effective total range of each of the group particles in
{particles}
(or
if there are no
{particles}
).
3.8.6.6 Effective Total Range (
choice
Schema Component Constraint: Effective Total Range (
choice
The effective total range of a particle
whose
{term}
is a group
whose
{compositor}
is
choice
is a pair of minimum and maximum, as follows:
minimum
The product of
{min occurs}
and the
minimum of the
{min occurs}
of every wildcard or element
declaration particle in
{particles}
and
the minimum part of the effective total range of each of the group particles
in
{particles}
(or
if there are no
{particles}
).
maximum
unbounded
if the
{max occurs}
of any wildcard or element
declaration particle in
{particles}
or the maximum
part of the effective total range of any of the group particles in
{particles}
is
unbounded
or if any of those is non-zero and
{max occurs}
unbounded
otherwise the product of
{max occurs}
and the
maximum of the
{max occurs}
of every wildcard or element
declaration particle in
{particles}
and the maximum
part of the effective total range of each of the group particles in
{particles}
(or
if there are no
{particles}
).
3.9 Particles
3.9.1
The Particle Schema Component
3.9.2
XML Representation of Particle Schema Components
3.9.3
Constraints on XML Representations of Particles
3.9.4
Particle Validation Rules
3.9.4.1
Principles of Validation against Particles
3.9.4.2
Element Sequence Locally Valid (Particle)
3.9.4.3
Element Sequence Accepted (Particle)
3.9.5
Particle Information Set Contributions
3.9.6
Constraints on Particle Schema Components
3.9.6.1
Particle Correct
3.9.6.2
Particle Valid (Extension)
3.9.6.3
Particle Emptiable
As described in
Model Groups (§3.8)
, particles contribute
to the definition
of content models.
When an element is validated against a complex type,
its sequence of child elements is checked against the content model of
the complex type and the children are
attributed to
to
Particles
of the content model.
The attribution of items to
Particles
determines the calculation of the items'
context-determined
declarations
and thus partially determines the
governing
element declarations
for the children:
when
an element information item is
attributed to
an
element particle
, that
Particle
's
Element Declaration
or an
Element Declaration
substitutable
for it,
becomes
the item's
context-determined
declaration
and
thus normally its
governing element declaration
; when the item is
attributed to
wildcard particle
, the
governing element declaration
depends on the
{process contents}
property of the wildcard and
on
QName resolution (Instance) (§3.17.6.3)
Example

XML representations which all involve particles, illustrating some of
the possibilities for controlling occurrence.
3.9.1 The Particle Schema Component
The particle schema component has the following properties:
Schema Component:
Particle
, a kind of
Component
{min occurs}
An xs:nonNegativeInteger value. Required.
{max occurs}
Either a positive integer or
unbounded
. Required.
{term}
Term
component. Required.
{annotations}
A sequence of
Annotation
components.
In general, multiple element
information item
[children]
, possibly with intervening character
[children]
if the content type
is
mixed
, can be
validated
with
respect to a single particle. When the
{term}
is an element
declaration or wildcard,
{min occurs}
determines the minimum number of such element
[children]
that can occur. The number of such children
must
be greater than or equal to
{min occurs}
. If
{min occurs}
is
, then occurrence of such children is optional.
Again, when the
{term}
is an element
declaration or wildcard, the number of such element
[children]
must
be less than or equal to any numeric specification of
{max occurs}
; if
{max occurs}
is
unbounded
, then there is no
upper bound on the number of such children.
When the
{term}
is a model group, the permitted
occurrence range is determined by a combination of
{min occurs}
and
{max occurs}
and the occurrence ranges of the
{term}
's
{particles}
[Definition:]
A particle
directly contains
the component which is the value of its
{term}
property.
[Definition:]
A particle
indirectly contains
the particles, groups, wildcards, and
element declarations which are contained by the value of its
{term}
property.
[Definition:]
A particle
contains
the components which it either
directly contains
or
indirectly contains
See
Annotations (§3.15)
for information on the role of the
{annotations}
property.
3.9.2 XML Representation of Particle Schema Components
Particles in the schema typically
correspond to element
information items that can bear
minOccurs
and
maxOccurs
attributes in the schema document:
Local

, see
XML Representation of Element Declaration Schema Components (§3.3.2)
Model groups


, and

, see
XML Representation of Model Group Schema Components (§3.8.2)
Group references

, see
XML Representation of Model Group Definition Schema Components (§3.7.2)
Wildcard

, see
XML Representation of Wildcard Schema Components (§3.10.2)
Sometimes particles do not correspond to any of these
elements. For example, particles may be synthesized in complex
type extension.
3.9.3 Constraints on XML Representations of Particles
None as such.
3.9.4 Particle Validation Rules
3.9.4.1 Principles of Validation against Particles
Every particle
recognizes
some language
).
When
{min occurs}
and
{max occurs}
of
are
both 1,
) is the language of
's
{term}
as described in
Validation of Basic Terms (§3.9.4.1.2)
. The
following section (
Language Recognition for Repetitions (§3.9.4.1.1)
describes how more complicated counts are handled.
3.9.4.1.1 Language Recognition for Repetitions
When
{min occurs}
{max occurs}
and
{term}
then
) is the set of sequences
+ ... +
Sn
such that
is in
) for 0 <
Less formally:
) is
the
set of sequences which have
partitions
into
sub-sequences
for which each of the
subsequences
is in the language accepted by the
{term}
of
When
{min occurs}
and
{max occurs}
and
{term}
then
) is the set of sequences
, +
+ ... +
Sn
, i.e. the
set of sequences which have
partitions
into
sub-sequences
such that
and
(or
is
unbounded
and
is in
) for 0 <
When
{min occurs}
= 0,
then
) also includes the empty sequence.
If (1)
Particle
has
{min occurs}
{max occurs}
, and
{term}
and (2)
is a sequence of element information items
such that
+ ... +
Sn
(i.e.
, ...,
Sn
is
partition
of
),
and (3)
(or
is
unbounded
),
and (4)
is in
) for 0 <
then:
If
is a model group,
then the set of
paths
of
in
is the set of all
paths
such that
+ ... +
, where
is a
path
of
in
for 0 <
(For the definition of
paths
in model groups,
see
Language Recognition by Groups (§3.8.4.1)
.)
If
is a
basic term
, then the (sole)
path
of
in
is a sequence of
occurrences of
Note:
Informally: the path of an input sequence
in a
particle
may go through the
basic particles
in
as many times as is allowed by
{max occurs}
If the path goes through
more than once, each
time before the last one must correspond to a sequence
accepted by
{term}
because the last
iteration in the path
may not be complete, it need not be accepted by the
{term}
3.9.4.1.2 Validation of Basic Terms
In the preceding section (
Language Recognition for Repetitions (§3.9.4.1.1)
), the language
accepted
by a
Particle
is defined in terms of the language
accepted
by
's
{term}
. This section defines
) for
basic terms
for the definition of
) when
is a group,
see
Language Recognition by Groups (§3.8.4.1)
[Definition:]
For any
Element Declaration
, the language
accepted
by
is the set of all sequences of
length 1 whose sole member is an element information item which
matches
[Definition:]
An element information item
matches
an
Element Declaration
if and only if
one
of the following is true:
and
have the same
expanded name
The
expanded name
of
resolves
to an element
declaration
which is
substitutable
for
[Definition:]
An
expanded name
matches
an
NCName
and
a namespace name
NS
(or, equivalently,
and
NS
match
if and only if all of the following
are true:
The local name of
is identical to
Either the namespace name of
is identical to
NS
or else
has no namespace name (
is an unqualified
name) and
NS
is
absent
Note:
For convenience,
expanded names
are sometimes spoken of as
matching
Type Definition
, an
Element Declaration
, an
Attribute Declaration
or other schema component which has both a
{name}
and a
{target namespace}
property (or vice versa,
the component is spoken of as
matching
the
expanded name
), when what is meant
is, strictly speaking, that the
expanded name
matches
the
{name}
and
{target namespace}
properties of the component.
[Definition:]
For any
Wildcard
, the language
accepted
by
is the set of all sequences of
length 1 whose sole member is an element information item which
matches
[Definition:]
An element information item
matches
Wildcard
(or a
wildcard particle
whose
{term}
is
if and only if
is locally
valid
with respect to
, as defined in the validation rule
Item Valid (Wildcard) (§3.10.4.1)
[Definition:]
Two namespace
names
and
are said to
match
if and only if they are identical or both are
absent
For principles of validation when the
{term}
is a model group
instead of a
basic particle
, see
Language Recognition by Groups (§3.8.4.1)
and
Principles of Validation against Groups (§3.8.4.2)
3.9.4.2 Element Sequence Locally Valid (Particle)
Validation Rule: Element Sequence Locally Valid (Particle)
For a sequence (possibly empty) of element information items to be
locally
valid
with respect to a
Particle
all
of the following
must
be true:
The sequence must be accepted by the
Particle
, as defined
in
Element Sequence Accepted (Particle) (§3.9.4.3)
3.9.4.3 Element Sequence Accepted (Particle)
Validation Rule: Element Sequence Accepted (Particle)
For a sequence (possibly empty) of
element information items to be
accepted by a
Particle
the appropriate
case
among the following
must
be true:
If
{term}
is a
wildcard,
then
all
of the following are true:
1.1
The length of the sequence is greater than or
equal to
{min occurs}
1.2
If
{max occurs}
is a number,
then the length of
the sequence is less than or equal to the
{max occurs}
1.3
Each element information item in the sequence is
valid
with respect to the
wildcard as defined by
Item Valid (Wildcard) (§3.10.4.1)
In this case, each
element information item in the sequence is
attributed to
and has no
context-determined declaration
If
{term}
is an
element declaration
then
all
of the following are true:
2.1
The length of the sequence is greater than or
equal to
{min occurs}
2.2
If
{max occurs}
is a number,
then the length of
the sequence is less than or equal to the
{max occurs}
2.3
For each element information item
in the sequence
one or more
of the following is true:
2.3.1
has the same
expanded name
as
In this case
is the
context-determined declaration
for
with respect to
Schema-Validity Assessment (Element) (§3.3.4.6)
and
Assessment Outcome (Element) (§3.3.5.1)
2.3.2
is top-level (i.e.
{scope}
{variety}
global
), its
{disallowed substitutions}
does not contain
substitution
's
expanded name
resolves
to
an element declaration
[Definition:]
call this declaration the
substituting declaration
— and
is
substitutable
for
as defined in
Substitution Group OK (Transitive) (§3.3.6.3)
In this case
is the
context-determined declaration
for
with respect to
Schema-Validity Assessment (Element) (§3.3.4.6)
and
Assessment Outcome (Element) (§3.3.5.1)
In this case
is
attributed to
Note:
This clause is equivalent to requiring that the sequence
of length 1 containing
is in
If
{term}
is a model
group,
then
all
of the following are true:
3.1
There is a
partition
of the sequence
into
sub-sequences such that
is greater than or equal to
{min occurs}
3.2
If
{max occurs}
is a
number,
is less than or equal to
{max occurs}
3.3
Each sub-sequence in the
partition
is
valid
with respect to that model
group as defined in
Element Sequence Valid (§3.8.4.3)
In this case, the
element information items in each sub-sequence are
attributed to
Particles
within the model group which is the
{term}
, as described in
Language Recognition by Groups (§3.8.4.1)
Note:
The rule just given does not require that the
content model be deterministic. In practice, however,
most
non-determinism in content models is ruled out by the schema
component constraint
Unique Particle Attribution (§3.8.6.4)
Non-determinism can occur despite that constraint for
several reasons.
In some such cases,
some particular element information item may be accepted by either a
Wildcard
or an
Element Declaration
. In such situations,
the validation process defined in this specification matches the
element information item against the
Element Declaration
, both in
identifying the
Element Declaration
as the item's
context-determined declaration
and in choosing alternative paths through a content model.
Other cases of non-determinism involve nested particles each of
which has
{max occurs}
greater than 1,
where the input sequence can be partitioned in multiple ways.
In those cases, there is no fixed rule for eliminating the
non-determinism.
Note:
clause
and clause
2.3.2
do not
interact: an element information item validatable by a declaration
with a substitution group head is
not
validatable by a wildcard which accepts the head's
(namespace, name) pair but not its own.
3.9.5 Particle Information Set Contributions
None as such.
3.9.6 Constraints on Particle Schema Components
3.9.6.1 Particle Correct
All particles (see
Particles (§3.9)
must
satisfy the following constraint.
Schema Component Constraint: Particle Correct
All
of the following
must
be true:
The values of the properties of a particle are as described in
the property tableau in
The Particle Schema Component (§3.9.1)
, modulo the impact of
Missing Sub-components (§5.3)
If
{max occurs}
is not
unbounded
, that is, it has a
numeric value, then
all
of the following are true:
2.1
{min occurs}
is not greater than
{max occurs}
3.9.6.2 Particle Valid (Extension)
The following constraint
defines a
relation
appealed to elsewhere in this specification.
Schema Component Constraint: Particle Valid (Extension)
[Definition:]
For a particle
(call it
, for extension) to be a
valid extension
of
another particle (call it
, for base)
one or more
of the following is true:
They are the same particle.
{min occurs}
{max occurs}
= 1 and
{term}
is a
sequence
group whose
{particles}
' first member is a
particle all of whose properties, recursively, are
identical to those of
All
of the following are true:
3.1
{min occurs}
{min occurs}
3.2
Both
and
have
all
groups
as their
{term}
s.
3.3
The
{particles}
of
's
all
group is a prefix of the
{particles}
of
's
all
group.
3.9.6.3 Particle Emptiable
The following constraint defines a relation appealed
to elsewhere in this specification.
Schema Component Constraint: Particle Emptiable
[Definition:]
For a particle to be
emptiable
one or more
of the following is true:
Its
{min occurs}
is
Its
{term}
is a group and the minimum part of the
effective total range of that group, as defined by
Effective Total Range (
all
and
sequence
) (§3.8.6.5)
(if
the group is
all
or
sequence
) or
Effective Total Range (
choice
) (§3.8.6.6)
(if it is
choice
), is
3.10 Wildcards
3.10.1
The Wildcard Schema Component
3.10.2
XML Representation of Wildcard Schema Components
3.10.2.1
Mapping from

to a Particle
3.10.2.2
Mapping from

and

to a Wildcard Component
3.10.3
Constraints on XML Representations of Wildcards
3.10.4
Wildcard Validation Rules
3.10.4.1
Item Valid (Wildcard)
3.10.4.2
Wildcard allows Expanded Name
3.10.4.3
Wildcard allows Namespace Name
3.10.5
Wildcard Information Set Contributions
3.10.6
Constraints on Wildcard Schema Components
3.10.6.1
Wildcard Properties Correct
3.10.6.2
Wildcard Subset
3.10.6.3
Attribute Wildcard Union
3.10.6.4
Attribute Wildcard Intersection
In order to exploit the full potential for extensibility offered by XML
plus namespaces, more provision is needed than DTDs allow for targeted flexibility in content
models and attribute declarations. A wildcard provides for
validation
of
attribute and element information items dependent on their namespace
names
and optionally on their local names.
Example

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
notQName="xsl:comment xsl:fallback"/>

XML representations of the four basic types of wildcard, plus one attribute wildcard.
3.10.1 The Wildcard Schema Component
The wildcard schema component has the following properties:
Schema Component:
Wildcard
, a kind of
Term
{annotations}
A sequence of
Annotation
components.
{namespace constraint}
Namespace Constraint
property record. Required.
{process contents}
One of {
skip
strict
lax
}. Required.
Property Record:
Namespace Constraint
{variety}
One of {
any
enumeration
not
}. Required.
{namespaces}
A set each of whose members is either an xs:anyURI value or
the distinguished value
absent
. Required.
{disallowed names}
A set each of whose members is either an xs:QName value or
the keyword
defined
or the keyword
sibling
. Required.
{namespace constraint}
provides for
validation
of attribute and element items that:
{variety}
any
) have any namespace or are not
namespace-qualified;
{variety}
not
and
{namespaces}
a set whose members are either namespace names or
absent
) have any namespace
other than the specified namespaces and/or, if
absent
is included in the set, are
namespace-qualified;
(see this
example
, which accepts
only namespace-qualified names distinct from the target namespace; the
##local
" in the schema document
maps to the value
absent
in the
{namespace constraint}
property)
{variety}
enumeration
and
{namespaces}
a set
whose members are either namespace names or
absent
) have any of the specified
namespaces and/or, if
absent
is included in the set, are
unqualified.
{disallowed names}
contains
QName
members) have any
expanded name
other than the specified names.
{disallowed names}
contains the keyword
defined
) have any
expanded name
other than those matching the
names of global element or attribute declarations.
{disallowed names}
contains the keyword
sibling
) have
any
expanded name
other than those
matching the names of element or attribute declarations in
the containing complex type definition.
{process contents}
controls the impact on
assessment
of the information items allowed by wildcards, as follows:
strict
There
must
be a top-level declaration for the item
available, or the item
must
have an
xsi:type
, and the
item
must
be
valid
as
appropriate.
skip
No constraints at all: the item
must
simply be well-formed XML.
lax
If the item has a uniquely
determined declaration available, it
must
be
valid
with respect to
that
declaration, that is,
validate
if you can, don't worry if you can't.
See
Annotations (§3.15)
for information on the role of the
{annotations}
property.
3.10.2 XML Representation of Wildcard Schema Components
The XML representation for a wildcard schema component is an

or

element
information item.
XML Representation Summary
any
Element Information Item
id =
ID
maxOccurs =

nonNegativeInteger
unbounded
: 1
minOccurs =
nonNegativeInteger
: 1
namespace =

((
##any
##other
) | List of

anyURI
| (
##targetNamespace
##local
))
notNamespace = List of

anyURI
| (
##targetNamespace
##local
))
notQName = List of

QName
| (
##defined
##definedSibling
))
processContents = (
lax
skip
strict
) : strict
{any attributes with non-schema namespace . . .}
Content:
annotation
?)

XML Representation Summary
anyAttribute
Element Information Item
id =
ID
namespace =

((
##any
##other
) | List of

anyURI
| (
##targetNamespace
##local
))
notNamespace = List of

anyURI
| (
##targetNamespace
##local
))
notQName = List of

QName
##defined
processContents = (
lax
skip
strict
) : strict
{any attributes with non-schema namespace . . .}
Content:
annotation
?)

An

information item
corresponds both to a wildcard component and to
a particle containing that wildcard
(unless
minOccurs=maxOccurs=0
, in which case the
item corresponds to no component at
all).
The mapping rules are given in the following two subsections.
As always, the mapping rules
given here apply after, not before, the appropriate
pre-processing
Processors
may
issue a warning
if a list of
xs:anyURI
values in the
namespace
or
noNamespace
attributes includes any values beginning
with the string '
##
'.
Note:
Strings beginning with '
##
' are not
IRIs or URIS according to the definitions given in
the relevant RFCs (for references see
[XML Schema: Datatypes]
) and
users of this specification are discouraged from using
them as namespace names, to avoid confusion with the
keyword values defined by this specification.
3.10.2.1 Mapping from

to a Particle
The mapping from an

information item to a particle
is as follows.
XML Mapping Summary for
Particle
Schema Component
Property
Representation
{min occurs}
The
actual value
of the
minOccurs
[attribute]
, if present, otherwise
{max occurs}
unbounded
, if
maxOccurs
unbounded
otherwise the
actual value
of the
maxOccurs
[attribute]
, if present, otherwise
{term}
A wildcard as given
below.
{annotations}
The same annotations as the
{annotations}
of the wildcard. See below.
3.10.2.2 Mapping from

and

to a Wildcard Component
The mapping from an

information item to a wildcard component
is as follows. This mapping is also used for mapping

information items to wildcards,
although in some cases the result of the mapping is further
modified, as specified in the rules for

and

XML Mapping Summary for
Wildcard
Schema Component
Property
Representation
{namespace constraint}
Namespace Constraint
with
the following properties:
Property
Value
{variety}
the appropriate
case
among the following:
If
the
namespace
[attribute]
is
present,
then
the appropriate
case
among the following:
1.1
If
namespace
"##any"
then
any
1.2
If
namespace
"##other"
then
not
1.3
otherwise
enumeration
If
the
notNamespace
[attribute]
is present,
then
not
otherwise
(neither
namespace
nor
notNamespace
is present)
any
{namespaces}
the appropriate
case
among the following:
If
neither
namespace
nor
notNamespace
is present,
then
the empty set;
If
namespace
"##any"
then
the empty set;
If
namespace
"##other"
then
a set consisting of
absent
and, if the
targetNamespace
[attribute] of
the

ancestor element
information item is present, its
actual value
otherwise
a set whose members are namespace
names corresponding to the space-delimited substrings of
the
actual value
of the
namespace
or
notNamespace
[attribute]
(whichever is
present), except
4.1
if one such substring is
##targetNamespace
, the corresponding
member is the
actual value
of the
targetNamespace
[attribute]
of the

ancestor
element information item if present, otherwise
absent
4.2
if one such substring is
##local
, the
corresponding member is
absent
{disallowed names}
If the
notQName
[attribute]
is
present, then a set whose members
correspond to the items in the
actual value
of the
notQName
[attribute]
as follows.
If the item is a
QName
value (i.e. an
expanded name
), then that
QName
value is a member of the set.
If the item is the token "
##defined
",
then the keyword
defined
is a member of the set.
If the item is the token "
##definedSibling
",
then the keyword
sibling
is a member of the set.
If the
notQName
[attribute]
is not present, then
the empty set.
{process contents}
The
actual value
of the
processContents
[attribute]
, if present,
otherwise
strict
{annotations}
The
annotation mapping
of the

element, as defined in
XML Representation of Annotation Schema Components (§3.15.2)
Note:
When this rule is used for an attribute wildcard (see
XML Representation of Complex Type Definition Schema Components (§3.4.2)
), the
{annotations}
is the
annotation mapping
of the

element.
Wildcards are subject to the same ambiguity constraints
Unique Particle Attribution (§3.8.6.4)
) as other content model
particles:
If an instance element could match one
of two wildcards, within the content model of a type, that model
is in error.
3.10.3 Constraints on XML Representations of Wildcards
Schema Representation Constraint: Wildcard Representation OK
In addition to the conditions imposed on

and

element information items by the schema for schema documents,
namespace
and
notNamespace
attributes
must not
both be
present.
3.10.4 Wildcard Validation Rules
3.10.4.1 Item Valid (Wildcard)
Validation Rule: Item Valid (Wildcard)
For an element or attribute information item
to be locally
valid
with respect to a wildcard
all
of the following
must
be true:
The
expanded name
of
is
valid
with respect to
{namespace constraint}
, as defined in
Wildcard allows Expanded Name (§3.10.4.2)
If
{namespace constraint}
{disallowed names}
contains the keyword
defined
then
both
of the following are true:
2.1
If
is an element wildcard (i.e.,
appears in a
content model),
then
the
expanded name
of
does not
resolve
to an element declaration. (Informally, no such top-level element is
declared in the schema.)
2.2
If
is an attribute wildcard,
then
the
expanded name
of
does not
resolve
to an attribute declaration.
If
all
of the following are true:
3.1
{namespace constraint}
{disallowed names}
contains the keyword
sibling
3.2
is an element wildcard
3.3
is an element information item
3.4
has a
[parent]
that is
also an element information item
3.5
and
have the same
[validation context]
3.6
has an
governing type definition
(which is always a complex
type and contains
in its
content model
then
the
expanded name
of
does not
match
any
element declaration
contained
in the content model of
, whether
directly
indirectly
, or
implicitly
Informally, the keyword
sibling
disallows any element declared as
a possible sibling of the wildcard
When an element or attribute information
item is
attributed
to a wildcard and the preceding constraint
Item Valid (Wildcard) (§3.10.4.1)
) is satisfied, then the item has no
context-determined declaration
. Its
governing
declaration, if any, is found by matching its
expanded name
as described in
QName resolution (Instance) (§3.17.6.3)
Note that QName resolution is performed only if the item is
attributed
to
strict
or
lax
wildcard; if the wildcard has a
{process contents}
property of
skip
then the item has no
governing
declaration.
[Definition:]
An element or attribute information item is
skipped
if it
is
attributed
to a
skip
wildcard or if one of its ancestor
elements is.
3.10.4.2 Wildcard allows Expanded Name
Validation Rule: Wildcard allows Expanded Name
For an
expanded name
, i.e. a
(namespace name, local name) pair,
to be
valid
with respect to a
namespace constraint
all
of the following
must
be true:
The namespace name is
valid
with respect to
, as defined in
Wildcard allows Namespace Name (§3.10.4.3)
{disallowed names}
does not
contain
3.10.4.3 Wildcard allows Namespace Name
Validation Rule: Wildcard allows Namespace Name
For a value
which is either a namespace name or
absent
to be
valid
with respect to
namespace
constraint
(the
value of a
{namespace constraint}
one
of the following
must
be true:
{variety}
any
{variety}
not
and
is not identical to any of the members of
{namespaces}
{variety}
enumeration
, and
is
identical to one of the members of
{namespaces}
3.10.5 Wildcard Information Set Contributions
None as such.
3.10.6 Constraints on Wildcard Schema Components
3.10.6.1 Wildcard Properties Correct
All wildcards (see
Wildcards (§3.10)
must
satisfy
the following constraint.
Schema Component Constraint: Wildcard Properties Correct
All
of the following
must
be true:
The values of the properties of a wildcard are as
described in the property tableau in
The Wildcard Schema Component (§3.10.1)
, modulo the impact of
Missing Sub-components (§5.3)
If
{variety}
is
not
{namespaces}
has at least one member.
If
{variety}
is
any
{namespaces}
is
empty.
The namespace name of each
QName
member
in
{disallowed names}
is allowed by the
{namespace constraint}
, as defined in
Wildcard allows Namespace Name (§3.10.4.3)
Attribute wildcards do not contain
sibling
in their
{namespace constraint}
{disallowed names}
3.10.6.2 Wildcard Subset
The following constraints define a relation appealed to
elsewhere in this specification.
Schema Component Constraint: Wildcard Subset
[Definition:]
Given two
Namespace Constraint
sub
and
super
sub
is a
wildcard subset
of
super
if and only if
one
of the following is true
super
{variety}
any
Both
sub
and
super
have
{variety}
enumeration
, and
super
{namespaces}
is a superset of
sub
{namespaces}
sub
{variety}
enumeration
super
{variety}
not
, and the
{namespaces}
of the two are disjoint.
Both
sub
and
super
have
{variety}
not
, and
super
{namespaces}
is a subset of
sub
{namespaces}
And
all
of the following are true:
Each
QName
member
of
super
{disallowed names}
is not
allowed
by
sub
, as defined in
Wildcard allows Expanded Name (§3.10.4.2)
If
super
{disallowed names}
contains
defined
, then
sub
{disallowed names}
also contains
defined
If
super
{disallowed names}
contains
sibling
, then
sub
's
{disallowed names}
also contains
sibling
3.10.6.3 Attribute Wildcard Union
Schema Component Constraint: Attribute Wildcard Union
[Definition:]
Given three
Namespace Constraint
O1
, and
O2
is
the
wildcard union
of
O1
and
O2
if and only if, first, the
{variety}
and
{namespaces}
, and, second, the
{disallowed names}
of
are consistent
with
being the union of
O1
and
O2
, as that is defined
below.
The
{variety}
and
{namespaces}
of
are consistent
with
being the wildcard union of
O1
and
O2
if and
only if
one or more
of the following is true:
O1
, and
O2
all have
the same
{variety}
and
{namespaces}
Either
O1
{variety}
any
or
O2
{variety}
any
, and
{variety}
any
O1
, and
O2
all have
{variety}
enumeration
, and
{namespaces}
is the union of
O1
{namespaces}
and
O2
{namespaces}
O1
{variety}
O2
{variety}
not
, and
one
of the following is true
4.1
The intersection of the
{namespaces}
of
O1
and
O2
is the
empty set, and
{variety}
any
4.2
{variety}
not
, and
{namespaces}
is the non-empty
intersection of
O1
{namespaces}
and
O2
{namespaces}
Either
O1
or
O2
has
{variety}
not
and
{namespaces}
S1
, and
the other has
{variety}
enumeration
and
{namespaces}
S2
, and
one
of the following is true
5.1
The set difference
S1
minus
S2
is the empty set, and
{variety}
any
5.2
{variety}
not
and
{namespaces}
is
the non-empty set difference
S1
minus
S2
The
{disallowed names}
property of
is consistent with
being
the wildcard union of
O1
and
O2
if and only if
{disallowed names}
includes
all and only the
following:
QName
members of
O1
{disallowed names}
that are not allowed by
O2
, as
defined in
Wildcard allows Expanded Name (§3.10.4.2)
QName
members of
O2
{disallowed names}
that are not
allowed by
O1
The keyword
defined
if it is contained in both
O1
{disallowed names}
and
O2
{disallowed names}
Note:
When one of the wildcards has
defined
in
{disallowed names}
and the other does not, then
defined
is
not
included in the union. This may allow
QNames that are not allowed by either wildcard. This is to ensure
that all unions are expressible. If
defined
is intended to be
included, then it is necessary to have it in both wildcards.
In the case where there are more than two
Namespace Constraint
s to be combined, the wildcard
union is determined by identifying the wildcard union of two
of them as above, then the wildcard union of the result with
the third, and so on as required.
3.10.6.4 Attribute Wildcard Intersection
Schema Component Constraint: Attribute Wildcard Intersection
[Definition:]
Given three
Namespace Constraint
O1
, and
O2
is the
wildcard intersection
of
O1
and
O2
if and only if
both its
{variety}
and
{namespaces}
properties, on the
one hand, and its
{disallowed names}
property, on the other, are

consistent with
being the intersection
of
O1
and
O2
, as that is defined below.
The
{variety}
and
{namespaces}
of
are consistent
with
being the wildcard
intersection of
O1
and
O2
if and only if
one or more
of the following is true:
O1
, and
O2
have
the same
{variety}
and
{namespaces}
Either
O1
or
O2
has
{variety}
any
and
has
{variety}
and
{namespaces}
identical
to those of the other.
O1
, and
O2
all have
{variety}
enumeration
and
{namespaces}
is the intersection of the
{namespaces}
of
O1
and
O2
O1
, and
O2
all have
{variety}
not
and
{namespaces}
is the union of the
{namespaces}
of
O1
and
O2
Either
O1
or
O2
has
{variety}
not
and
{namespaces}
S1
and the other has
{variety}
enumeration
and
{namespaces}
S2
and
{variety}
enumeration
and
{namespaces}
= the
set difference
S2
minus
S1
The
{disallowed names}
property of
is consistent
with
being the wildcard
intersection of
O1
and
O2
if and only if
{disallowed names}
includes all and only the following:
QName
members of
O1
{disallowed names}
whose namespace names
are allowed by
O2
, as defined in
Wildcard allows Namespace Name (§3.10.4.3)
QName
members of
O2
{disallowed names}
whose namespace names
are allowed by
O1
The keyword
defined
if it is a member of either
{disallowed names}
In the case where there are more than two
Namespace Constraint
s to be combined, the wildcard
intersection is determined by identifying the wildcard intersection of two
of them as above, then the wildcard intersection of the result with
the third, and so on as required.
3.11 Identity-constraint Definitions
3.11.1
The Identity-constraint Definition Schema Component
3.11.2
XML Representation of Identity-constraint Definition Schema Components
3.11.3
Constraints on XML Representations of Identity-constraint Definitions
3.11.4
Identity-constraint Definition Validation Rules
3.11.5
Identity-constraint Definition Information Set Contributions
3.11.6
Constraints on Identity-constraint Definition Schema Components
3.11.6.1
Identity-constraint Definition Properties Correct
3.11.6.2
Selector Value OK
3.11.6.3
Fields Value OK
Identity-constraint definition components provide for uniqueness and
reference constraints with respect to the contents of multiple elements and attributes.
Example

XML representations for the three kinds of identity-constraint definitions.
3.11.1 The Identity-constraint Definition Schema Component
The identity-constraint definition schema component has the following
properties:
Schema Component:
Identity-Constraint Definition
, a kind of
Annotated Component
{annotations}
A sequence of
Annotation
components.
{name}
An xs:NCName value. Required.
{target namespace}
An xs:anyURI value. Optional.
{identity-constraint category}
One of {
key
keyref
unique
}. Required.
{selector}
An
XPath Expression
property record. Required.
{fields}
A sequence of
XPath Expression
property records.
{referenced key}
An
Identity-Constraint Definition
component.
Required if
{identity-constraint category}
is
keyref
otherwise (
{identity-constraint category}
is
key
or
unique
must
be
absent
If a value is present, its
{identity-constraint category}
must be
key
or
unique
Identity-constraint definitions are identified by their
{name}
and
{target namespace}
identity-constraint
definition identities
must
be unique within an
XSD schema
. See
References to schema components across namespaces (

) (§4.2.6)
for the use of component
identifiers when importing one schema into another.
Informally,
{identity-constraint category}
identifies the
identity-constraint
definition as playing one of
three roles:
unique
) the
identity-constraint
definition asserts uniqueness, with respect to the content
identified by
{selector}
, of the tuples resulting from
evaluation of the
{fields}
XPath expression(s).
key
) the
identity-constraint
definition asserts uniqueness as for
unique
key
further asserts that all selected content
actually has such tuples.
keyref
) the
identity-constraint
definition asserts a correspondence, with respect to the content
identified by
{selector}
, of the tuples resulting from
evaluation of the
{fields}
XPath expression(s), with those of the
{referenced key}
These constraints are specified alongside the specification of types for the
attributes and elements involved, i.e. something declared as of type integer
can also serve as a key. Each constraint declaration has a name, which exists in a
single symbol space for constraints. The
equality and inequality
conditions
appealed to in checking these constraints apply to the
values
of
the fields selected, not their
lexical representation, so that for example
3.0
and
would be conflicting keys if they were both
decimal, but non-conflicting if
they were both strings, or one was a string and one a decimal.
When equality and
identity differ for the simple types involved, all three
forms of identity-constraint test for
either
equality
or
identity
of values.
Overall the augmentations to XML's
ID/IDREF
mechanism are:
Functioning as a part of an identity-constraint is in addition to, not instead of,
having a type;
Not just attribute values, but also element content and combinations
of values and content can be declared to be unique;
Identity-constraints are specified to hold within the scope of particular elements;
(Combinations of) attribute values and/or element content can be
declared to be keys, that is, not only unique, but always present and non-nillable;
The comparison between
keyref
{fields}
and
key
or
unique
{fields}
is
performed
on typed values, not on the lexical representations of those values.
{selector}
specifies a restricted XPath
[XPath 2.0]
) expression relative to
instances of the element being declared. This
must
identify a

sequence of element nodes that are
contained within the declared element
to which the constraint applies.
{fields}
specifies XPath expressions relative to each
element selected by a
{selector}
Each
XPath expression in the
{fields}
property
must
identify
a single node (element or attribute),
whose content or value, which
must
be
of a simple type, is used in the constraint. It is possible to specify an
ordered list of
{fields}
s, to cater to multi-field keys,
keyrefs, and uniqueness constraints.
In order to reduce the burden on implementers, in particular
implementers of streaming processors, only restricted subsets of XPath
expressions are allowed in
{selector}
and
{fields}
. The details are given in
Constraints on Identity-constraint Definition Schema Components (§3.11.6)
Note:
Provision for multi-field keys etc. goes beyond what is supported by
xsl:key
Note:
In version 1.0 of this specification
[XSD 1.0 2E]
, identity constraints used
[XPath 1.0]
They now use
[XPath 2.0]
See
Annotations (§3.15)
for information on the role of the
{annotations}
property.
3.11.2 XML Representation of Identity-constraint Definition Schema Components
The XML representation for an identity-constraint definition schema
component is either a

, a

or a

element information
item. The correspondences between the properties of those
information items
after the appropriate
pre-processing
and the
properties of the component they
correspond to are as follows:
XML Representation Summary
unique
Element Information Item et al.
id =
ID
name =
NCName
ref =
QName
{any attributes with non-schema namespace . . .}
Content:
annotation
?, (
selector
field
+)?)

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

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

id =
ID
xpath
a subset of XPath expression, see below
xpathDefaultNamespace =

anyURI
| (
##defaultNamespace
##targetNamespace
##local
))
{any attributes with non-schema namespace . . .}
Content:
annotation
?)

id =
ID
xpath
a subset of XPath expression, see below
xpathDefaultNamespace =

anyURI
| (
##defaultNamespace
##targetNamespace
##local
))
{any attributes with non-schema namespace . . .}
Content:
annotation
?)

If the
ref
[attribute]
is absent,
the corresponding schema
component is as follows:
XML Mapping Summary for
Identity-constraint Definition
Schema Component
Property
Representation
{name}
The
actual value
of the
name
[attribute]
{target namespace}
The
actual value
of the
targetNamespace
[attribute]
of the

ancestor
element information item if present, otherwise
absent
{identity- constraint category}
One of
key
keyref
or
unique
, depending on the item.
{selector}
An
XPath Expression
property record, as described in
section
XML Representation of Assertion Schema Components (§3.13.2)
, with

as the "host element" and
xpath
as the designated
expression
[attribute]
{fields}
A sequence of
XPath Expression
property records, corresponding to the

element information item
[children]
, in order,
following the rules given in
XML Representation of Assertion Schema Components (§3.13.2)
with

as the "host element"
and
xpath
as the designated expression
[attribute]
{referenced key}
If the item is a

, the
identity-constraint definition
resolved
to by the
actual value
of the
refer
[attribute]
, otherwise
absent
{annotations}
The
annotation mapping
of the set of elements containing the


, or

element,
whichever is present, and the

and

[children]
, if present,
as defined in
XML Representation of Annotation Schema Components (§3.15.2)
Otherwise (the
ref
[attribute]
is
present), the corresponding schema component is the identity-constraint definition
resolved
to by the
actual value
of the
ref
[attribute]
Example


. . .

. . .

. . .

. . .









state
element is defined, which
contains a
code
child and some
vehicle
and
person
children. A
vehicle
in turn has a
plateNumber
attribute,
which is an integer, and a
state
attribute. State's
code
s are a key for them within the document. Vehicle's
plateNumber
s are a key for them within states, and
state
and
plateNumber
is asserted to be a
key
for
vehicle
within the document as a whole. Furthermore, a
person
element has
an empty
car
child, with
regState
and
regPlate
attributes, which are then asserted together to refer to
vehicle
s via the
carRef
constraint. The requirement
that a
vehicle
's
state
match its containing
state
's
code
is not expressed here.
Example



. . .



. . .

. . .



. . .

A list of
state
elements can appear as child elements
under
stateList
. A
key
constraint can be used to
ensure that there is no duplicate state
code
. We already
defined a
key
in the above example for the exact same purpose
(the key constraint is named "
state
"). We can reuse it
directly via the
ref
attribute on the
key
element.
3.11.3 Constraints on XML Representations of Identity-constraint Definitions
Schema Representation Constraint: Identity-constraint Definition Representation OK
In addition to the conditions imposed on


and

element
information items by the schema for schema documents,
all
of the following
must
be true:
One of
ref
or
name
is present, but not both.
If
name
is present, then

appears in
[children]
If
name
is present on

, then
refer
is also present.
If
ref
is present, then only
id
and

are
allowed to appear together with
ref
If
ref
is present, then the
{identity-constraint category}
of the identity-constraint
definition
resolved
to by the
actual value
of the
ref
[attribute]
matches the name of the
element information item.
3.11.4 Identity-constraint Definition Validation Rules
Validation Rule: Identity-constraint Satisfied
For an element information item
to be locally
valid
with respect to an identity-constraint
all
of the following
must
be true:
A data model instance is constructed
from the input information set, as described in
[XDM]
The
{selector}
, with
the element node corresponding to
as the
context node, evaluates to a
sequence of element nodes, as defined in
XPath Evaluation (§3.13.4.2)
[Definition:]
The
target node set
is the
set of nodes in that sequence, after omitting
all element nodes corresponding to element
information items that are
skipped
Each node in the
target node set
is
either the context node
or an
element node among its descendants.
For each node
in the
target node set
and each field
in
{fields}
, when
is taken as the context node
evaluates (as defined in
XPath Evaluation (§3.13.4.2)
) to a
sequence of nodes
contains zero or more
skipped
nodes, at most one node whose
governing
type
definition is either a simple type definition or a complex type
definition with
{variety}
simple
and no other nodes.
As a consequence, for each field
the sequence
contains at most
one node with a
non-absent
[schema actual
value]
. Call that one node's
[schema actual value]
).
[Definition:]
The
key-sequence
of
is the sequence
consisting of the values
), in the order of
the
{fields}
property.
Note:
The use of
[schema actual value]
in the definition of
key sequence
above means that
default
or
fixed
value constraints
may
play
a part in
key sequence
s.
Note:
In some cases, the
key-sequence
of node
will be
shorter than
{fields}
in length,
for example whenever any field evaluates to the empty sequence or to a
sequence consisting only of
skipped
or
nilled
nodes. In
such a case, the
key-sequence
of
does not
participate in value comparison, because
is not a member of the
qualified node set
. See below.
[Definition:]
The
qualified node set
is the subset
of the
target node set
consisting of those nodes
whose
key-sequence
has the same length as the
{fields}
The appropriate
case
among the following is true:
4.1
If
the
{identity-constraint category}
is
unique
then
no two members of the
qualified node set
have
key-sequences
whose members
are pairwise equal or identical,
as defined by
Equality
and
Identity
in
[XML Schema: Datatypes]
4.2
If
the
{identity-constraint category}
is
key
then
all
of the following are true:
4.2.1
The
target node set
and the
qualified node set
are equal, that is, every
member of the
target node set
is also a member of the
qualified node set
and
vice versa
4.2.2
No two members of the
qualified node set
have
key-sequences
whose members
are pairwise equal or identical,
as defined by
Equality
and
Identity
in
[XML Schema: Datatypes]
4.2.3
No element member of the
key-sequence
of any
member of the
qualified node set
was assessed as
valid
by reference to an element
declaration whose
{nillable}
is
true
4.3
If
the
{identity-constraint category}
is
keyref
then
for each member of the
qualified node set
(call this
the
keyref member
), there is a
node table
associated
with the
{referenced key}
in the
[identity-constraint table]
of
(see
Identity-constraint Table (§3.11.5)
, which is understood
as logically prior to this clause of this constraint,
below) and there is an entry in that table whose
key-sequence
is
equal or identical
to the
keyref member's
key-sequence
member for member,
as defined by
Equality
and
Identity
in
[XML Schema: Datatypes]
Note:
For
unique
identity constraints, the
qualified node set
is
allowed to be different from the
target node set
. That is, a
selected unique node may have fields that do not have corresponding
[schema actual value]
s.
Note:
Because the validation of
keyref
(see clause
4.3
) depends on finding appropriate entries in an
element information item's
node
table
, and
node
tables
are assembled strictly recursively from the
node tables of descendants, only element information items
within the sub-tree rooted at the element information item
being
validated
can be referenced successfully.
Note:
Although this specification defines a
post-schema-validation infoset
contribution
which would enable schema-aware processors to implement
clause
4.2.3
above (
Element Declaration (§3.3.5.3)
), processors are not required to provide
it. This clause can be read as if in the absence of this
infoset contribution, the value of the relevant
{nillable}
property
must
be available.
For purposes of checking
identity-constraints, single atomic values are not distinguished
from lists with single items. An atomic value
and a list
with a single item are treated as equal, for
purposes of this specification, if
is equal

to the atomic value which is the single item of
And similarly for identity.
3.11.5 Identity-constraint Definition Information Set Contributions
Schema Information Set Contribution: Identity-constraint Table
[Definition:]
An
eligible identity-constraint
of an element information item is
one such that clause
4.1
or clause
4.2
of
Identity-constraint Satisfied (§3.11.4)
is satisfied with respect to that
item and that constraint, or such that any of the element information
item
[children]
of that item have an
[identity-constraint table]
property whose value has an entry for
that constraint
[Definition:]
node
table
is a set of pairs each consisting of a
key-sequence
and an element node
Whenever an element information item has one or more
eligible identity-constraints
, in the
post-schema-validation infoset
that
element information item has a property as follows:
PSVI Contributions for
element information items
[identity-constraint table]
one
Identity-constraint Binding
information item for each
eligible identity-constraint
, with
properties as follows:
PSVI Contributions for
Identity-constraint Binding information items
[definition]
The
eligible identity-constraint
[node table]
node table
with one entry for every
key-sequence
(call it
) and
node (call it
) such that
one
of the following is true
There is an entry in one of the
node
tables
associated with the
[definition]
in an
Identity-constraint Binding
information item in at least one of the
[identity-constraint table]
s of the element information item
[children]
of the element information item whose
key-sequence
is
and whose node
is
appears with
key-sequence
in the
qualified node set
for the
[definition]
provided no two entries have the same
key-sequence
but distinct nodes. Potential
conflicts are resolved by not including any conflicting entries which
would have owed their inclusion to clause
above. Note
that if all the conflicting entries arose under clause
above, this means no entry at all will appear for the
offending
key-sequence
Note:
The complexity of the above arises from the fact that
keyref
identity-constraints can be defined on domains distinct from the
embedded domain of the identity-constraint they reference, or on domains which are the
same but self-embedding at some depth. In either case the
node
table
for the referenced identity-constraint needs to propagate upwards, with
conflict resolution.
The
Identity-constraint Binding
information item, unlike
others in this specification, is essentially an internal bookkeeping
mechanism. It is introduced to support the definition of
Identity-constraint Satisfied (§3.11.4)
above.
3.11.6 Constraints on Identity-constraint Definition Schema Components
3.11.6.1 Identity-constraint Definition Properties Correct
All identity-constraint definitions (see
Identity-constraint Definitions (§3.11)
must
satisfy the
following constraint.
Schema Component Constraint: Identity-constraint Definition Properties Correct
All
of the following
must
be true:
The values of the properties of an identity-constraint definition
are as described in the property tableau in
The Identity-constraint Definition Schema Component (§3.11.1)
, modulo the
impact of
Missing Sub-components (§5.3)
If the
{identity-constraint category}
is
keyref
, the cardinality of the
{fields}
is equal
to that of the
{fields}
of the
{referenced key}
3.11.6.2 Selector Value OK
Schema Component Constraint: Selector Value OK
All
of the following
must
be true:
The
{selector}
satisfies the constraint
XPath Valid (§3.13.6.2)
One or more
of the following is true:
2.1
Its
{expression}
conforms to the following extended BNF:
Selector XPath expressions
[1]
Selector
::=
Path
( '|'
Path
)*
[2]
Path
::=
('.' '//')?
Step
( '/'
Step
)*
[3]
Step
::=
'.' |
NameTest
[4]
NameTest
::=
QName
| '*' |
NCName
':*'
2.2
Its
{expression}
is an XPath expression
involving the
child
axis whose abbreviated
form is as given above.
For readability, whitespace
may
be used in selector XPath
expressions even though not explicitly allowed by the grammar:
whitespace
may
be freely added
within patterns before or after any
token
Lexical productions
[5]
token
::=
'.' | '/' | '//' | '|' | '@' |
NameTest
[6]
whitespace
::=
When tokenizing, the longest possible token is always returned.
[Definition:]
The subset of XPath defined in
Selector Value OK (§3.11.6.2)
is called the
selector subset
of XPath.
3.11.6.3 Fields Value OK
Schema Component Constraint: Fields Value OK
All
of the following
must
be true:
Each member of the
{fields}
satisfies the constraint
XPath Valid (§3.13.6.2)
For each member of the
{fields}
one or more
of the following is true:
2.1
Its
{expression}
conforms to the extended BNF given
above for
Selector
, with the following modification:
Path in Field XPath expressions
[7]
Path
::=
('.' '//')?
Step
'/' )* (
Step
| '@'
NameTest
This production differs from the one above in allowing the final
step to match an attribute node.
2.2
Its
{expression}
is an XPath expression involving the
child
and/or
attribute
axes whose abbreviated form is
as given above.
For readability, whitespace
may
be used in field XPath expressions even though not
explicitly allowed by the grammar:
whitespace
may
be freely added within patterns before or after any
token
When tokenizing, the longest possible token is always returned.
[Definition:]
The subset of XPath defined in
Fields Value OK (§3.11.6.3)
is called the
field subset
of XPath.
3.12 Type Alternatives
3.12.1
The Type Alternative Schema Component
3.12.2
XML Representation of Type Alternative Schema Components
3.12.3
Constraints on XML Representations of Type Alternatives
3.12.4
Type Alternative Validation Rules
3.12.5
Type Alternative Information Set Contributions
3.12.6
Constraints on Type Alternative Schema Components
Type Alternative components provide associations between boolean
conditions (as XPath expressions) and
Type Definition
s.
They are used in conditional type assignment.
3.12.1 The Type Alternative Schema Component
The type alternative schema component has the following properties:
Schema Component:
Type Alternative
, a kind of
Annotated Component
{annotations}
A sequence of
Annotation
components.
{test}
An
XPath Expression
property record. Optional.
{type definition}
Type Definition
component. Required.
Type alternatives can be used by an
Element Declaration
to specify a
condition (
{test}
) under which a particular type (
{type definition}
) is used
as the
governing type definition
for element information items governed by that
Element Declaration
. Each
Element Declaration
may
have multiple
Type Alternative
s in its
{type table}
3.12.2 XML Representation of Type Alternative Schema Components
The XML representation for a type
alternative schema component is an

element information item. The correspondences
between the properties of that information item
after the appropriate
pre-processing
and the
properties of the
component it corresponds to are as follows:
XML Representation Summary
alternative
Element Information Item
id =
ID
test =
an XPath expression
type =
QName
xpathDefaultNamespace =

anyURI
| (
##defaultNamespace
##targetNamespace
##local
))
{any attributes with non-schema namespace . . .}
Content:
annotation
?, (
simpleType
complexType
)?)

Each

element
maps to a
Type Alternative
component as follows.
XML Mapping Summary for
Type Alternative
Schema Component
Property
Representation
{test}
If the
test
[attribute]
is not present, then
absent
otherwise an
XPath Expression
property record, as described in
section
XML Representation of Assertion Schema Components (§3.13.2)
, with

as the "host element"
and
test
as the designated expression
[attribute]
{type definition}
The type definition
resolved
to by the
actual value
of the
type
[attribute]
, if one is present, otherwise the type definition corresponding
to the
complexType
or
simpleType
among the
[children]
of the

element.
{annotations}
The
annotation mapping
of the

element,
as defined in
XML Representation of Annotation Schema Components (§3.15.2)
3.12.3 Constraints on XML Representations of Type Alternatives
Schema Representation Constraint: Type
Alternative Representation OK
In addition to the conditions imposed
on

element information items by the schema for schema documents,
each

element
must
have
one (and only one)
of the following:
type
attribute, or a
complexType
child element, or a
simpleType
child element.
3.12.4 Type Alternative Validation Rules
[Definition:]
Type Alternative
successfully selects
Type Definition
for an
element information item
if and only if
{test}
evaluates to
true
and
{type definition}
The
{test}
is evaluated in the following way:
An instance of the
[XDM]
data model is constructed as
follows:
1.1
An information set is constructed by copying
the base information set properties
(and not any of the properties specific to
post-schema-validation infoset
) of the following
information items:
1.1.1
itself.
1.1.2
's
[attributes]
(but not its
[children]
).
1.1.3
's
[inherited attributes]
which do not
have the same
expanded names
as any of
's
[attributes]
They are copied as if they were among
's
[attributes]
and had
as their
[owner element]
When an attribute with a non-empty
[namespace name]
is copied,
namespace fixup
may need to be performed on the
resulting information set to ensure that a prefix
is bound to
the
[namespace name]
and the
[prefix]
of
the copied attribute is set to
[Definition:]
By
base information set properties
are meant the properties listed in
Required Information Set Items and Properties (normative) (§D)
1.2
In the copy of
, the
[parent]
property
is modified to have no value.
The
[children]
property
is modified to have the empty list as its value.
1.3
An
[XDM]
data model instance is constructed from
that information set, following the rules given in
[XDM]
The XPath expression
which is the value of the
{test}
, is evaluated
as described in
XPath Evaluation (§3.13.4.2)
If a
dynamic error
or a
type error
is raised during
evaluation, then the
{test}
is
treated as if it had evaluated (without
error) to
false
Note:
Dynamic errors
and
type errors
in
the evaluation of
{test}
expressions cause neither the
schema nor the document instance to be invalid. But
conforming processors
may
issue a warning if they occur.
However,
if type errors are
detected statically by the XPath processor, the effect is
the same as for other static errors in the XPath
expression.
Note:
As a consequence of the rules just given, the root node of the
[XDM]
instance is necessarily constructed from
the ancestors,
siblings, children, and descendants of
are
not represented in the data model instance, and they are thus
not accessible to the tests expressed in the
{test}
s in the
{type table}
. The element
and its
[attributes]
will be
represented in the data model instance by nodes labeled as
untyped. If the
{test}
expressions being evaluated include
comparisons which require type information, then explicit casts
will sometimes be necessary.
3.12.5 Type Alternative Information Set Contributions
None.
3.12.6 Constraints on Type Alternative Schema Components
All type alternatives (see
Type Alternatives (§3.12)
must
satisfy the following constraints.
Schema Component Constraint: Type Alternative Properties Correct
All
of the following
must
be true:
The values of the properties of a type alternatives

are as
described in the property tableau in
The Type Alternative Schema Component (§3.12.1)
modulo the impact of
Missing Sub-components (§5.3)
If the
{test}
is not
absent
, then it satisfies the constraint
XPath Valid (§3.13.6.2)
The
function
signatures
in the
static context
must
include signatures for
all
of the following:
2.1
The
fn:not
function
defined in the
[Functions and Operators]
specification.
2.2
Constructor functions for the built-in datatypes.
The further contents of
function
signatures
are
implementation-defined
A conforming processor
must
accept and process any XPath expression
conforming to the "required subset" of
[XPath 2.0]
defined
by the following grammar.
Note:
Any XPath expression containing no static errors as defined in
[XPath 2.0]
may
appear in a conforming schema. Conforming processors
may
but are not
required to support XPath expressions not belonging to the required
subset of XPath.
An XPath expression belongs to the required subset of XPath if and only
if
all
of the following are true:
The
{expression}
property of the
XPath Expression
is an XPath expression containing
no static errors, as defined in
[XPath 2.0]
One or more
of the following is true:
2.1
It conforms to the following extended BNF:
Test XPath expressions
[8]
Test
::=
OrExpr
[9]
OrExpr
::=
AndExpr
( 'or'
AndExpr
)*
[10]
AndExpr
::=
BooleanExpr
( 'and'
BooleanExpr
)*
[11]
BooleanExpr
::=
'('
OrExpr
')' |
BooleanFunction
ValueExpr
Comparator
ValueExpr
)?
[12]
BooleanFunction
::=
QName
'('
OrExpr
')'
[13]
Comparator
::=
'=' | '!=' | '<' | '<=' | '>' | '>='
[14]
ValueExpr
::=
CastExpr
ConstructorFunction
[15]
CastExpr
::=
SimpleValue
( 'cast' 'as' QName '?'? )?
[16]
SimpleValue
::=
AttrName
Literal
[17]
AttrName
::=
'@'
NameTest
[18]
ConstructorFunction
::=
QName
'('
SimpleValue
')'
2.2
It is an XPath expression involving the
attribute
axis
whose abbreviated form is as given above.
Note:
For readability,
[XPath 2.0]
allows whitespace to be
used between tokens in XPath expressions, even though this is not
explicitly shown in the grammar. For details of whitespace handling,
consult
[XPath 2.0]
Any strings matching the
BooleanFunction
production are function calls to
fn:not
defined in the
[Functions and Operators]
specification.
Any strings matching the
ConstructorFunction
production are function calls to constructor functions for the built-in
datatypes.
Note:
The minimal content of the
function
signatures
in the
static context
is given in clause
of
Type Alternative Properties Correct (§3.12.6)
fn:not
and
constructors for the built-in datatypes.
Note:
The above extended BNF is ambiguous. For example, the string
a:b('123')
" has 2 paths in the grammar, by matching either
BooleanFunction
or
ConstructorFunction
. The rules given
here require different function names for the productions. As a result, the
ambiguity can be resolved based on the function name.
Any explicit casts (i.e. any strings which match
the optional "
cast as
QName
in the
CastExpr
production)
are casts to built-in datatypes.
Note:
Implementations
may
choose to support a bigger subset of
[XPath 2.0]
Note:
The rule given above for the construction of the data model
instance has as a consequence that even when implementations
support full
[XPath 2.0]
expressions, it is not
possible to refer successfully to the children, siblings,
ancestors, etc. of the element whose type is being selected.
3.13 Assertions
3.13.1
The Assertion Schema Component
3.13.2
XML Representation of Assertion Schema Components
3.13.3
Constraints on XML Representations of Assertions
3.13.4
Assertion Validation Rules
3.13.4.1
Assertion Satisfied
3.13.4.2
XPath Evaluation
3.13.5
Assertion Information Set Contributions
3.13.6
Constraints on Assertion Schema Components
3.13.6.1
Assertion Properties Correct
3.13.6.2
XPath Valid
Assertion components constrain the existence and values of related
elements and attributes.
Example

The XML representation
for assertions.
The

element requires that the
value of the
min
attribute be less than or equal to that of the
max
attribute, and fails if that is not the case.
3.13.1 The Assertion Schema Component
The assertion schema component has the following properties:
Schema Component:
Assertion
, a kind of
Annotated Component
{annotations}
A sequence of
Annotation
components.
{test}
An
XPath Expression
property record. Required.
Property Record:
XPath Expression
{namespace bindings}
A set of
Namespace Binding
property records.
{default namespace}
An xs:anyURI value. Optional.
{base URI}
An xs:anyURI value. Optional.
{expression}
An
[XPath 2.0]
expression. Required.
Property Record:
Namespace Binding
{prefix}
An xs:NCName value. Required.
{namespace}
An xs:anyURI value. Required.
To check an assertion,
an instance of the XPath 2.0 data
model (
[XDM]
) is constructed,
in which the element
information item being
assessed
is the (parentless) root node,
and
elements and attributes are assigned types and values according to
XPath 2.0 data model construction rules, with some exceptions. See
Assertion Satisfied (§3.13.4.1)
for details about how the data model is
constructed.
When evaluated against this data model
instance,
{test}
evaluates to either
true
or
false
(if any other value is returned, it's converted to
either
true
or
false
as if by a call to the XPath
fn:boolean
function).
See
Annotations (§3.15)
for information on the role of
the
{annotations}
property.
3.13.2 XML Representation of Assertion Schema Components
The XML representation for an assertion schema component
is
an

element information item.
The correspondences between the properties of

that information item
after the appropriate
pre-processing
and the
properties of the component
it corresponds to are as follows:
XML Representation Summary
assert
Element Information Item
id =
ID
test
an XPath expression
xpathDefaultNamespace =

anyURI
| (
##defaultNamespace
##targetNamespace
##local
))
{any attributes with non-schema namespace . . .}
Content:
annotation
?)

The

element
maps to an
Assertion
component as follows.
XML Mapping Summary for
Assertion
Schema Component
Property
Representation
{test}
An
XPath Expression
property record, as described below,
with

as the "host element"
and
test
as the designated expression
[attribute]
{annotations}
The
annotation mapping
of the

element,

as defined in
XML Representation of Annotation Schema Components (§3.15.2)
Assertions, like identity constraints and conditional type
assignment, use
[XPath 2.0]
expressions.
The expression itself is recorded, together with relevant parts
of the context, in an
XPath Expression
property record.
The mapping is as described below; in each case, the XPath
expression itself is given in a
designated attribute
of
the appropriate "
host element
".
XML Mapping Summary for
XPath Expression
Property Record
Property
Representation
{namespace bindings}
A set of
Namespace Binding
property records. Each member
corresponds to an entry in the
[in-scope namespaces]
of
the host element, with
{prefix}
being the
[prefix]
and
{namespace}
the
[namespace
name]
{default namespace}
Let
be the
actual value
of the
xpathDefaultNamespace
[attribute]
, if
present on the host
element, otherwise that of the
xpathDefaultNamespace
[attribute]
of
the

ancestor. Then
the value is
the appropriate
case
among the following:
If
is
##defaultNamespace
then
the appropriate
case
among the following:
1.1
If
there is an entry in the
[in-scope namespaces]
of the host element whose
[prefix]
is
absent
then
the corresponding
[namespace
name]
1.2
otherwise
absent
If
is
##targetNamespace
then
the appropriate
case
among the following:
2.1
If
the
targetNamespace
[attribute]
is present on the

ancestor,
then
its
actual value
2.2
otherwise
absent
If
is
##local
then
absent
otherwise
is an xs:anyURI
value)
{base URI}
The
[base
URI]
of the host element.
{expression}
An XPath expression corresponding to the
actual value
of the
designated
[attribute]
of the host element.
Example





The value of the
min
attribute must be less than or equal to
that of the
max
attribute.
Note that the attributes are validated before the assertion
on the parent element is checked, so the typed values of the attributes
are available for comparison; it is not necessary to cast the values
to
int
or some other numeric type before comparing them.
Example







The value of the
length
attribute must be the same as
the number of occurrences of
entry
sub-elements.
3.13.3 Constraints on XML Representations of Assertions
None as such.
3.13.4 Assertion Validation Rules
3.13.4.1 Assertion Satisfied
Validation Rule: Assertion Satisfied
An element information item
is locally
valid
with respect to an
assertion if
and only if the
{test}
evaluates to
true
(see below) without raising
any
dynamic error
or
type
error
Evaluation of
{test}
is performed as defined
in
[XPath 2.0]
, with the following conditions:
A data model
instance (see
[XDM]
is constructed in the following way:
1.1
is validated

with respect to its
governing element declaration
, as defined
in
Element Locally Valid (Element) (§3.3.4.3)
, if the
governing element declaration
exists, otherwise

against
its
governing type definition
, as defined in
Element Locally Valid (Complex Type) (§3.4.4.2)
except that for
itself (though not for its element
information item descendants), clause
of
Element Locally Valid (Complex Type) (§3.4.4.2)
is skipped. (Informally,
the element is validated normally,
except that assertions are not checked.)
Note:
It is a consequence of this rule that the
[attributes]
and
[children]
of
will be validated in the usual way.
1.2
A "partial"
post-schema-validation infoset
describing the results
of this partial validation
of
is constructed. The
post-schema-validation infoset
properties
of
's
[children]
and
[attributes]
are defined in the
usual way. On
itself, all
post-schema-validation infoset
properties are supplied as described elsewhere in this specification
if their values are known. The element's
[validity]
property is given
the value
invalid
if and only if the element is known
to be invalid; otherwise it is given the value
notKnown
The element's
[validation attempted]
property
is given the value
partial
Note:
Since the assertions of its
governing type definition
have not been
checked,
has been only partially
validated, and can be known to be invalid, but not known to be
valid. The values of the
[validity]
and
[validation attempted]
properties
are set accordingly.
By default, comments and processing instructions are excluded from the
partial
post-schema-validation infoset
, but
at user
option
processors
may
retain comments
and processing instructions instead of excluding them.
Note:
If comments and processing instructions are retained, the
consequence will be that assertions are able to
test for their presence or absence and to examine their contents.
1.3
From the "partial"
post-schema-validation infoset
, a data model
instance is constructed as described in
[XDM]
The root node of the
[XDM]
instance is
constructed from
; the data model instance contains only
that node and nodes constructed from the
[attributes]
[children]
, and descendants of
Note:
It is a consequence of this construction that attempts
to refer, in an assertion, to the siblings or ancestors of
, or to any part of the input document outside of
itself, will be unsuccessful.
Such attempted references
are not in themselves errors, but the data model instance
used to evaluate them does not include any representation
of any parts of the document outside of
, so they
cannot be referred to.
The XPath expression
{test}
is evaluated, following the rules
given in
XPath Evaluation (§3.13.4.2)
, with the
following
conditions and modifications:
2.1
The root node of the
[XDM]
instance
described in clause
serves as the
context
node
for evaluation of the XPath
expression.
2.2
The
static context
is augmented with the variable "
$value
",
as described in
Assertion Properties Correct (§3.13.6.1)
2.3
The variable "
$value
" appears as a member
of the
variable values
in
the
dynamic context
. The
expanded QName
of that member has no namespace URI and has
value
" as the local name.
The
value
of the member is determined by the appropriate
case
among the following:
2.3.1
If
all
of the following are true:
2.3.1.1
's
[validity]
in the "partial"
post-schema-validation infoset
is not
invalid
2.3.1.2
's
[nil]
in the "partial"
post-schema-validation infoset
does not exist or has value
false
2.3.1.3
the
{content type}
of
's
governing type definition
has
{variety}
simple
then
the
value
is the
XDM representation
of
[schema actual value]
under the
{content type}
{simple type definition}
of
's
governing type definition
Note:
This clause provides type information to simple contents
of elements, to make type-aware comparisons and
operations possible without explicit casting in the
XPath expressions.
Note:
For complex types with simple content, the element node
may be referred to as "
", while
its content may be referred to as
$value
". Since the element node,
as a consequence of clause
1.2
, will normally have the type
annotation
anyType
, its
atomized
value will be a single atomic value of type
untypedAtomic
. By contrast,
$value
will be a sequence of one or more
atomic values, whose types are the most specific
(narrowest) built-in types available.
2.3.2
otherwise
(in the "partial"
post-schema-validation infoset
[validity]
invalid
or
[nil]
true
or
's
governing type definition
does not have
{content type}
{variety}
simple
the
value
is the empty sequence.
The evaluation result
is converted to either
true
or
false
as if by a call to the XPath
fn:boolean
function.
Note:
Although the rules
just given describe
how an
post-schema-validation infoset
and a
[XDM]
instance are constructed, processors are not required
to construct
actual data structures representing them.
However, the result of XPath evaluation
must
be the same as if such
post-schema-validation infoset
and
[XDM]
instance
data structures were
constructed.
3.13.4.2 XPath Evaluation
Validation Rule: XPath Evaluation
An
XPath Expression
property record
, with a context node
is evaluated as defined in
[XPath 2.0]
with a
static context
as described in
XPath Valid (§3.13.6.2)
(unless otherwise specified
elsewhere)
and with the following
dynamic context
(again, unless otherwise specified
elsewhere):
The
context item
is
The
context position
is 1.
The
context size
is
1.
The
variable values
is
the empty set.
The
function
implementations
include an implementation of every function
in the
function
signatures
of the
static context
See
XPath Valid (§3.13.6.2)
The
current dateTime
is
implementation-defined
, but is constant during an
assessment
episode.
The
implicit timezone
is
implementation-defined
, but is constant during an
assessment
episode.
The
available documents
is

the empty set.
The
available collections
is
the empty set.
10
The
default collection
is

the empty sequence.
It is
implementation-defined
(both in this specification and in
[XPath 2.0]
) when type errors are detected and whether,
when detected, they are treated as static or dynamic errors.
Note:
It is a consequence of this rule that a conforming processor which
treats a type error in an XPath expression as a dynamic error will
treat the expression as having evaluated to false, while a conforming
processor which treats type errors as static errors will report an
error in the schema.
3.13.5 Assertion Information Set Contributions
None as such.
3.13.6 Constraints on Assertion Schema Components
All assertions (see
Assertions (§3.13)
must
satisfy the following constraints.
3.13.6.1 Assertion Properties Correct
Schema Component Constraint: Assertion Properties Correct
All
of the following
must
be true:
The values of the properties of an assertion are as
described in the property tableau in
The Assertion Schema Component (§3.13.1)
modulo the impact of
Missing Sub-components (§5.3)
The
{test}
satisfies the constraint
XPath Valid (§3.13.6.2)

with the following modifications to the
static context
2.1
The
in-scope variables
is a set with a single member. The
expanded QName
of that
member has no namespace URI and has
value
as the local
name. The (static)
type
of the member is
anyAtomicType*
2.2
The
function signatures
includes signatures for
all
of the following:
2.2.1
Functions in the
namespace as defined in the
[Functions and Operators]
specification.
2.2.2
Constructor functions for the built-in datatypes.
Note:
The XDM type label
anyAtomicType*
simply says
that for static typing purposes the variable
$value
will have a value consisting of a sequence of zero or more
atomic values.
3.13.6.2 XPath Valid
Schema Component Constraint: XPath Valid
For an
XPath Expression
property record
to be valid,
all
of the following
must
be true:
The
{expression}
of
is a valid XPath
expression, as defined in
[XPath 2.0]
does not produce any
static
error
, under the following conditions
(except as specified elsewhere):
2.1
The
Static Typing
Feature
is disabled.
2.2
The
static context
is
given as follows:
2.2.1
XPath 1.0
compatibility mode
is
false
2.2.2
The
statically
known namespaces
is the
{namespace bindings}
of
2.2.3
The
default element/type
namespace
is the
{default namespace}
of
2.2.4
The
default function
namespace
is
2.2.5
The
in-scope schema definitions
are those components that are present in every schema by definition,
as defined in
Built-in Attribute Declarations (§3.2.7)
Built-in Complex Type Definition (§3.4.7)
and
Built-in Simple Type Definitions (§3.16.7)
2.2.6
The
in-scope variables
is the empty set.
2.2.7
The
context item
static type
is not applicable, because the
Static Typing
Feature
is disabled.
2.2.8
The
function
signatures
are
implementation-defined
Note:
If
belongs to an
Assertion
or a
Type Alternative
Assertion Properties Correct (§3.13.6.1)
and
Type Alternative Properties Correct (§3.12.6)
impose additional constraints on the set of required functions.
2.2.9
The
statically known
collations
are
implementation-defined
, but always include the
Unicode
codepoint collation
defined by
[Functions and Operators]
2.2.10
The
default collation
is the Unicode codepoint collation.
2.2.11
The
base URI
is the
{base URI}
of
2.2.12
The
statically known
documents
is
the empty set.
2.2.13
The
statically known
collections
is
implementation-defined
2.2.14
The
statically
known default collection type
is
implementation-defined
It is
implementation-defined
(both in this specification and in
[XPath 2.0]
) when type errors are detected and whether,
when detected, they are treated as static or dynamic errors.
Note:
It is a consequence of this rule that a conforming processor which
treats a type error in an XPath expression as a dynamic error will
treat the expression as having evaluated to false, while a conforming
processor which treats type errors as static errors will report an
error in the schema.
3.14 Notation Declarations
3.14.1
The Notation Declaration Schema Component
3.14.2
XML Representation of Notation Declaration Schema Components
3.14.3
Constraints on XML Representations of Notation Declarations
3.14.4
Notation Declaration Validation Rules
3.14.5
Notation Declaration Information Set Contributions
3.14.6
Constraints on Notation Declaration Schema Components
Notation declarations reconstruct XML NOTATION declarations.
Example

The XML representation of a notation declaration.
3.14.1 The Notation Declaration Schema Component
The notation declaration schema component has the following
properties:
Schema Component:
Notation Declaration
, a kind of
Annotated Component
{annotations}
A sequence of
Annotation
components.
{name}
An xs:NCName value. Required.
{target namespace}
An xs:anyURI value. Optional.
{system identifier}
An xs:anyURI value. Required if
{public identifier}
is
absent
, otherwise (
{public identifier}
is present) optional.
{public identifier}
A publicID value. Required if
{system identifier}
is
absent
, otherwise (
{system identifier}
is present) optional.
As defined in
[XML 1.0]
or
[XML 1.1]
Notation declarations do not participate in
validation
as such. They are referenced in the
course of
validating
strings as
members of the
NOTATION
simple type. An element or attribute information item with
its
governing
type definition or its
validating type
derived from the
NOTATION
simple type is
valid
only if its
value was among the enumerations of such simple type.
As a consequence such a value is required to be the
{name}
of a notation declaration.
See
Annotations (§3.15)
for information on the role of the
{annotations}
property.
3.14.2 XML Representation of Notation Declaration Schema Components
The XML representation for a notation declaration schema component is

element information item. The correspondences between the
properties of that information item
after the appropriate
pre-processing
and the
properties of the component it corresponds to are as follows:
XML Representation Summary
notation
Element Information Item
id =
ID
name
NCName
public =
token
system =
anyURI
{any attributes with non-schema namespace . . .}
Content:
annotation
?)

The

element
maps to a
Notation Declaration
component as follows.
XML Mapping Summary for
Notation Declaration
Schema Component
Property
Representation
{name}
The
actual value
of the
name
[attribute]
{target namespace}
The
actual value
of the
targetNamespace
[attribute]
of the

ancestor
element information item if present, otherwise
absent
{system identifier}
The
actual value
of the
system
[attribute]
, if present, otherwise
absent
{public identifier}
The
actual value
of the
public
[attribute]
, if present, otherwise
absent
{annotations}
The
annotation mapping
of the

element,
as defined in
XML Representation of Annotation Schema Components (§3.15.2)
Example
public="image/jpeg" system="viewer.exe" />

. . .

...
3.14.3 Constraints on XML Representations of Notation Declarations
None as such.
3.14.4 Notation Declaration Validation Rules
None as such.
3.14.5 Notation Declaration Information Set Contributions
Schema Information Set Contribution: Validated with Notation
Whenever an attribute information item is
valid
with respect to a
NOTATION
, in the
post-schema-validation infoset
its
parent element information item has the following
properties:
PSVI Contributions for
element information items
[notation]
An
item isomorphic
to the notation declaration
resolved
to by the
attribute item's
actual value
[notation system]
The value of the
{system identifier}
of that notation
declaration.
[notation public]
The value of the
{public identifier}
of that notation
declaration.
Note:
For compatibility, only one such attribute
should
appear
on any given element. If more than one such attribute
does
appear, which one supplies the infoset property or
properties above is not defined.
Note:
Element as well as attribute information items may be
valid
with respect to a
NOTATION
, but only attribute
information items cause a notation declaration to appear in the
post-schema-validation infoset
as a property of their parent.
3.14.6 Constraints on Notation Declaration Schema Components
All notation declarations (see
Notation Declarations (§3.14)
must
satisfy the following
constraint.
Schema Component Constraint: Notation Declaration Correct
The values of the properties of a notation declaration
must
be as described in the property tableau in
The Notation Declaration Schema Component (§3.14.1)
, modulo the impact of
Missing Sub-components (§5.3)
3.15 Annotations
3.15.1
The Annotation Schema Component
3.15.2
XML Representation of Annotation Schema Components
3.15.3
Constraints on XML Representations of Annotations
3.15.4
Annotation Validation Rules
3.15.5
Annotation Information Set Contributions
3.15.6
Constraints on Annotation Schema Components
Annotations provide for human- and machine-targeted annotations
of schema components.
Example
fn:note="special"> A type for
experts only
checkForPrimes

XML representations of three kinds of annotation.
3.15.1 The Annotation Schema Component
The annotation schema component has the following
properties:
Schema Component:
Annotation
, a kind of
Component
{application information}
A sequence of Element information items.
{user information}
A sequence of Element information items.
{attributes}
A set of Attribute information items.
{user information}
is intended for
human consumption,
{application information}
for automatic processing. In both cases,
provision is made for an optional URI reference to supplement the
local information, as the value of the
source
attribute of the respective element information items.
validation
does
not
involve dereferencing these
URIs, when present. In the case of
{user information}
, indication
should
be given as
to the identity of the (human) language used in the contents,
using the
xml:lang
attribute.
{attributes}
ensures that when
schema authors take advantage of the provision for adding
attributes from namespaces other than the XSD
namespace to schema documents, they are available within the
components corresponding to the element items where such
attributes appear.
Annotations do not participate in
validation
as such. Provided
an annotation itself satisfies all relevant
Schema Component Constraints
it
cannot
affect the
validation
of element information
items.
The mapping defined in this specification from XML representations to
components does not apply to XML elements contained within an

element; such elements do not correspond to
components, when the mapping defined here is used.
It is
implementation-defined
what effect, if any, the invalidity of
a descendant of

has on the
construction of schema components from the enclosing
schema document.
The name
[Definition:]
Annotated Component
covers all the different kinds of component which may
have annotations.
3.15.2 XML Representation of Annotation Schema Components
Annotation of schemas and schema components, with material for human or
computer consumption, is provided for by allowing application information and
human information at the beginning of most major schema elements, and anywhere
at the top level of schemas. The XML representation for an annotation schema component is
an

element information item. The correspondences between the
properties of that information item
after the appropriate
pre-processing
and the
properties of the component it corresponds to are as follows:
XML Representation Summary
annotation
Element Information Item et al.
id =
ID
{any attributes with non-schema namespace . . .}
Content:
appinfo
documentation
)*

source =
anyURI
{any attributes with non-schema namespace . . .}
Content:
{any}
)*

source =
anyURI
xml:lang =
language
{any attributes with non-schema namespace . . .}
Content:
{any}
)*

The

element and its
descendants map to an
Annotation
component as follows.
XML Mapping Summary for
Annotation
Schema Component
Property
Representation
{application information}
A sequence of
the

element information items from
among the
[children]
, in order, if any, otherwise the empty
sequence.
{user information}
A sequence of the

element information items from
among the
[children]
, in order, if any, otherwise the empty
sequence.
{attributes}
A set of attribute information items,
namely those allowed by the attribute wildcard in the type
definition for the

item itself or
for the
enclosing items which correspond to the component within which
the annotation component is located.
The annotation component corresponding to the

element in the example above will have one
element item in each of its
{user information}
and
{application information}
and one attribute
item in its
{attributes}
Virtually every kind of schema component defined in this specification
has an
{annotations}
property. When
the component is described in a schema document, the mapping from
the XML representation of the component to the
Annotation
components in the appropriate
{annotations}
property follows the rules described in the next paragraph.
[Definition:]
The
annotation
mapping
of a set of element information items
ES
is a sequence of annotations
AS
, with the following properties:
For every

element information item among the
[children]
of any element information item in
ES
, there
is a corresponding
Annotation
component in
AS
Note:
As noted above,
the
{attributes}
property of
each
Annotation
component includes
all
the attribute information items on the

element itself, on the
XML element which represents (and maps to) the
component being annotated, and on any intervening
XML elements, if those attribute information items
have
[namespace name]
different from the XSD namespace.
If any element information item
in
ES
has any attribute information items
such that
all
of the following are true:
2.1
is in
[attributes]
2.2
[namespace name]
is present and not the XSD namespace.
2.3
is not included in the
[attributes]
property
of any annotation component described in
clause
then for each such
, an
Annotation
component
will appear in
AS
, with
{application information}
and
{user information}
each being the empty sequence and
{attributes}
containing all and only those attribute information
items
among
[attributes]
AS
contains no other
Annotation
components.
[Definition:]
The
annotation
mapping
of a single element information item is the
annotation mapping
of the singleton set containing that
element.
Note:
The order of
Annotation
components within the sequence
is
implementation-dependent
Note:
When the input set has more than one
member, the
Annotation
components in the resulting sequence
do not record which element in the set they
correspond to. The attribute information items in the
{attributes}
of any
Annotation
similarly do not indicate which element information item in the
schema document was their parent.
3.15.3 Constraints on XML Representations of Annotations
None as such.
3.15.4 Annotation Validation Rules
None as such.
3.15.5 Annotation Information Set Contributions
None as such:
the addition of annotations to the
post-schema-validation infoset
is
covered by the
post-schema-validation infoset
contributions of the enclosing components.
3.15.6 Constraints on Annotation Schema Components
All annotations (see
Annotations (§3.15)
must
satisfy the following constraint.
Schema Component Constraint: Annotation Correct
The values of the properties of an annotation
must
be as described in
the property tableau in
The Annotation Schema Component (§3.15.1)
, modulo the impact of
Missing Sub-components (§5.3)
3.16 Simple Type Definitions
3.16.1
The Simple Type Definition Schema Component
3.16.2
XML Representation of Simple Type Definition Schema Components
3.16.2.1
Common mapping rules for Simple Type Definitions
3.16.2.2
Mapping Rules for Atomic Simple Type Definitions
3.16.2.3
Mapping Rules for Lists
3.16.2.4
Mapping Rules for Unions
3.16.3
Constraints on XML Representations of Simple Type Definitions
3.16.4
Simple Type Definition Validation Rules
3.16.5
Simple Type Definition Information Set
Contributions
3.16.6
Constraints on Simple Type Definition Schema Components
3.16.6.1
Simple Type Definition Properties Correct
3.16.6.2
Derivation Valid (Restriction, Simple)
3.16.6.3
Type Derivation OK (Simple)
3.16.6.4
Simple Type Restriction (Facets)
3.16.7
Built-in Simple Type Definitions
3.16.7.1
xs:anySimpleType
3.16.7.2
xs:anyAtomicType
3.16.7.3
xs:error
3.16.7.4
Built-in primitive datatypes
3.16.7.5
Other built-in datatypes
Note:
This section consists of a combination of copies of
normative material from
[XML Schema: Datatypes]
, for local cross-reference
purposes, and material
unique to this specification, relating to the interface between schema
components defined in this specification and the simple type definition component.
Simple type definitions provide for constraining character information item
[children]
of element and attribute
information items.
Example







The XML representation of a simple type definition.
3.16.1 The Simple Type Definition Schema Component
The simple type definition schema component has the following properties:
Schema Component:
Simple Type Definition
, a kind of
Type Definition
{annotations}
A sequence of
Annotation
components.
{name}
An xs:NCName value. Optional.
{target namespace}
An xs:anyURI value. Optional.
{final}
A subset of {
extension
restriction
list
union
}.
{context}
Required if
{name}
is
absent
otherwise
must
be
absent
Either an
Attribute Declaration

an
Element Declaration
Complex Type Definition
or a
Simple Type Definition
{base type definition}
Type Definition
component. Required.
With one exception, the
{base type definition}
of any
Simple Type Definition
is a
Simple Type Definition
. The exception is
xs:anySimpleType
, which has
xs:anyType
, a
Complex Type Definition
, as its
{base type definition}
{facets}
A set of
Constraining Facet
components.
{fundamental facets}
A set of
Fundamental Facet
components.
{variety}
One of {
atomic
list
union
}. Required for all
Simple Type Definition
except
xs:anySimpleType
in which it is
absent
{primitive type definition}
Simple Type Definition
component. With one exception, required if
{variety}
is
atomic
otherwise
must
be
absent
. The exception
is
xs:anyAtomicType
, whose
{primitive type definition}
is
absent
If
non-
absent
must
be a
primitive
definition.
{item type definition}
Simple Type Definition
component. Required if
{variety}
is
list
otherwise
must
be
absent
The value of this property
must
be
a primitive or ordinary simple type definition
with
{variety}
atomic
or
an ordinary simple type definition
with
{variety}
union
whose basic members are all atomic;
the value
must not
itself be
a list type
(have
{variety}
list
or have any basic members which are list types.
{member type definitions}
A sequence of primitive or ordinary
Simple Type Definition
components.
Must
be present
(but
may
be empty)
if
{variety}
is
union
otherwise
must
be
absent
The sequence may contain any primitive or ordinary simple type definition, but
must not
contain any special type definitions.
Simple types are identified by their
{name}
and
{target namespace}
. Except
for anonymous simple types (those with no
{name}
), since
type definitions (i.e. both simple and complex type definitions taken together)
must
be uniquely identified within an
XSD schema
, no simple type definition can have the same name as another
simple or complex type definition. Simple type
{name}
s and
{target namespace}
are provided for reference from
instances (see
xsi:type (§2.7.1)
), and for use in the XML
representation of schema components
(specifically in

and

). See
References to schema components across namespaces (

) (§4.2.6)
for the use of component
identifiers when importing one schema into another.
Note:
The
{name}
of a simple type is not
ipso
facto
the
[(local) name]
of the
element or attribute information items
validated
by that definition. The connection between a
name and a type definition is described in
Element Declarations (§3.3)
and
Attribute Declarations (§3.2)
A simple type definition with an empty specification for
{final}
can be used as the
{base type definition}
for other types
derived
by either of
extension or restriction, or as the
{item type definition}
in
the definition of a list, or in the
{member type definitions}
of
a union; the explicit values
extension
restriction
list
and
union
prevent further
derivations
by extension (to yield a complex type) and restriction (to yield a
simple type) and use in
constructing
lists and unions respectively.
{variety}
determines whether the simple type corresponds to
an
atomic
list
or
union
type as defined by
[XML Schema: Datatypes]
As described in
Type Definition Hierarchy (§2.2.1.1)
, every simple type definition is
restriction
of some other simple
type (the
{base type definition}
), which is
xs:anySimpleType
if and only if the type
definition in question is
xs:anyAtomicType
or a list or
union type definition which is not itself
derived
by restriction from a
list or union respectively.
A type definition
has
xs:anyAtomicType
as its
{base type definition}
if and only if it is one of the primitive datatypes. Each
atomic
type is ultimately a restriction of exactly one such
primitive datatype, which is its
{primitive type definition}
The
{facets}
property
contains a set of constraining facets which are used to specify
constraints on the datatype described by the simple type definition.
For
atomic
definitions, these are restricted
to those appropriate for the corresponding
{primitive type definition}
. Therefore, the value space
and lexical space (i.e. what is
validated
by any atomic simple
type) is determined by the pair (
{primitive type definition}
{facets}
).
Constraining facets are defined in
[XML Schema: Datatypes]
. All conforming
implementations of this specification
must
support all of the
facets defined in
[XML Schema: Datatypes]
. It is
implementation-defined
whether additional
facets are supported; if they are, the implementation
must
satisfy the rules for
implementation-defined
facets
described in
[XML Schema: Datatypes]
As specified in
[XML Schema: Datatypes]
list
simple type definitions
validate
space separated tokens, each of
which conforms to a specified simple type definition, the
{item type definition}
. The item type specified
must not
itself be a
list
type, and
must
be one of the types identified in
[XML Schema: Datatypes]
as a
suitable item type for a list simple type. In this case the
{facets}
apply to the list itself, and are restricted to those appropriate for lists.
union
simple type definition
validates
strings which satisfy at
least one of its
{member type definitions}
. As in the case of
list
, the
{facets}
apply to the union itself, and are restricted to those appropriate for unions.
xs:anySimpleType
or
xs:anyAtomicType
must
not
be named as the
{base type definition}
of any user-defined
atomic simple type definitions:
as they allow no constraining facets, this
would be incoherent.
See
Annotations (§3.15)
for information on the role of the
{annotations}
property.
3.16.2 XML Representation of Simple Type Definition Schema Components
As always, the mapping rules
given in this section apply after, not before, the appropriate
pre-processing
Note:
This section reproduces a version of material from
[XML Schema: Datatypes]
, for
local cross-reference purposes.
XML Representation Summary
simpleType
Element Information Item et al.
final =

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

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

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

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

The

element and its descendants
normally, when there are no errors, map to a
Simple Type Definition
component. The case in which
an
unknown
facet is used in the definition of a simple type
definition is handled specially: the

in question is not in error, but it does not map to any component at all.
Note:
The effect of the special handling of
unknown
facets is to
ensure (1) that
implementation-defined
facets which are not supported by
a particular implementation result in the types which depend upon them
not being present in the schema, and (2) that the presence of
references to
unknown
facets in a schema document does not prevent
the rest of the schema document being processed and used.
The following subsections define one set of common mapping
rules for simple type definitions, and three specialized
sets of mapping rules for atomic, list, and union datatypes,
respectively.
If the

element
has a

element among its children,
and the base type definition has
{variety}
atomic
then the mapping rules in
Common mapping rules for Simple Type Definitions (§3.16.2.1)
and
Mapping Rules for Atomic Simple Type Definitions (§3.16.2.2)
apply.
If the

element
has a

element among its children,
or if it has a

child
and the base type definition has
{variety}
list
then the mapping rules in
Common mapping rules for Simple Type Definitions (§3.16.2.1)
and
Mapping Rules for Lists (§3.16.2.3)
apply.
If the

element
has a

element among its children,
or if it has a

child
and the base type definition has
{variety}
union
then the mapping rules in
Common mapping rules for Simple Type Definitions (§3.16.2.1)
and
Mapping Rules for Unions (§3.16.2.4)
apply.
3.16.2.1 Common mapping rules for Simple Type Definitions
The following rules apply to all
simple type definitions.
XML Mapping Summary for
Simple Type Definition
Schema Component
Property
Representation
{name}
The
actual value
of the
name
[attribute]
if present on the

element,
otherwise
absent
{target namespace}
The
actual value
of the
targetNamespace
[attribute]
of
the ancestor

element information item if present,
otherwise
absent
{base type definition}
The appropriate
case
among the following:
If
the

alternative is chosen,
then
the type definition
resolved
to by the
actual value
of the
base
[attribute]
of

, if present, otherwise the
type definition corresponding to the

among
the
[children]
of

If
the

or

alternative is chosen,
then
xs:anySimpleType
{final}
A subset of
restriction
extension
list
union
, determined as follows.
[Definition:]
Let
FS
be
the
actual value
of the
final
[attribute]
if present, otherwise the
actual value
of the
finalDefault
[attribute]
of the ancestor
schema
element,
if present, otherwise the empty string.
Then the property value is
the appropriate
case
among the following:
If
FS
is the empty string,
then
the empty set;
If
FS
is

#all
",
then
restriction
extension
list
union
otherwise
Consider
FS
as
a space-separated list, and include
restriction
if

restriction
" is in that list, and similarly for
extension
list
and
union
{context}
The appropriate
case
among the following:
If
the
name
[attribute]
is present,
then
absent
otherwise
the appropriate
case
among the following:
2.1
If
the parent element information item is

then
the corresponding
Attribute Declaration
2.2
If
the parent element information item is

then
the corresponding
Element Declaration
2.3
If
the parent element information item is

or

then
the
Simple Type Definition
corresponding to the grandparent

element information item
2.4
If
the parent element information item
is

then
the
Element Declaration
corresponding to the
nearest enclosing

element information item
2.5
otherwise
(the parent element information item is

),
the appropriate
case
among the following:
2.5.1
If
the grandparent element information item is

then
the
Simple Type Definition
corresponding to the grandparent
2.5.2
otherwise
(the grandparent element information item
is

), the
Simple Type Definition
which is the
{content type}
{simple type definition}
of the
Complex Type Definition
corresponding to the great-grandparent

element information item.
{variety}
If the

alternative is chosen,
then
list
, otherwise if the

alternative is
chosen, then
union
, otherwise (the

alternative is chosen), then the
{variety}
of the
{base type definition}
{facets}
The appropriate
case
among the following:
If
the

alternative is chosen
and
the children of the

element are all
either

elements,

elements,
or elements which specify constraining facets
supported by the processor,
then
the set of
Constraining Facet
components
obtained by
overlaying
the
{facets}
of the
{base type definition}
with the
set of
Constraining Facet
components
corresponding to those
[children]
of

which specify facets, as defined in
Simple Type Restriction (Facets) (§3.16.6.4)
If
the

alternative is chosen
and
the children of the

element
include at least one element of which the processor has no
prior knowledge (i.e. not a

element,
an

element, or an element
denoting a constraining facet known to and
supported by the processor),
then
the

element
maps to no component at all (but is not in error solely on account of
the presence of the unknown element).
If
the

alternative is chosen,
then
a set with one member, a
whiteSpace
facet with
{value}
collapse
and
{fixed}
true
otherwise
the empty set
{fundamental facets}
Based on
{variety}
{facets}
{base type definition}
and
{member type definitions}
, a set of
Fundamental Facet
components, one
each as specified in
The ordered Schema Component
The bounded Schema Component
The cardinality Schema Component
and
The numeric Schema Component
{annotations}
The
annotation mapping
of the set of elements containing the

, and one of
the


or

[children]
whichever is present,
as defined in
XML Representation of Annotation Schema Components (§3.15.2)
3.16.2.2 Mapping Rules for Atomic Simple Type Definitions
The following rule applies if the
{variety}
is
atomic
[Definition:]
The
ancestors
of a
type definition
are its
{base type definition}
and the
ancestors
of its
{base type definition}
(The ancestors of a
Simple Type Definition
in the type hierarchy are themselves
type definitions
; they are distinct from
the XML elements which may be ancestors, in the XML document
hierarchy, of the

element which
declares
.)
XML Mapping Summary for
Atomic Simple Type Definition
Schema Component
Property
Representation
{primitive type definition}
From among the
ancestors
of this
Simple Type Definition
, that
Simple Type Definition
which corresponds to a
primitive
datatype.
3.16.2.3 Mapping Rules for Lists
If the
{variety}
is
list
, the following additional
property mapping

applies:
XML Mapping Summary for
List Simple Type Definition
Schema Component
Property
Representation
{item type definition}
The appropriate
case
among the following:
If
the
{base type definition}
is
xs:anySimpleType
then
the
Simple Type Definition
(a)
resolved
to by the
actual value
of the
itemType
[attribute]
of

or (b), corresponding to the

among
the
[children]
of

, whichever is present.
Note:
In
this case, a

element will invariably be present; it will
invariably have either an
itemType
[attribute]
or a

[child]
, but not both.
otherwise
(that is, the
{base type definition}
is not
xs:anySimpleType
), the
{item type definition}
of the
{base type definition}
Note:
In this case, a

element will invariably
be present.
3.16.2.4 Mapping Rules for Unions
If the
{variety}
is
union
, the following
additional property mapping applies:
XML Mapping Summary for
Union Simple Type Definition
Schema Component
Property
Representation
{member type definitions}
The appropriate
case
among the following:
If
the
{base type definition}
is
xs:anySimpleType
then
the sequence of
Simple Type Definition
s (a)
resolved
to by the items in the
actual value
of the
memberTypes
[attribute]
of

if any, and (b)
corresponding to the

s among
the
[children]
of

, if any, in order.
Note:
In
this case, a

element will invariably be present; it will
invariably have either a
memberTypes
[attribute]
or one or more

[children]
, or both.
otherwise
(that is, the
{base type definition}
is not
xs:anySimpleType
), the
{member type definitions}
of the
{base type definition}
Note:
In this case, a

element will invariably
be present.
3.16.3 Constraints on XML Representations of Simple Type Definitions
Schema Representation Constraint: Simple Type Definition Representation OK
In addition to the conditions imposed on

element information items by the schema for schema documents,
all
of the following
must
be true:
No two elements among the
[children]
of

have the same
expanded name
in the Schema (
xs
) namespace,
unless that
expanded name
is one of
xs:enumeration
xs:pattern
, or
xs:assertion
Note:
That is, most of the facets for simple types defined
by this specification are forbidden to occur more than once.
But


, and

may occur multiple times,
and facets defined in other namespaces and
made available as extensions to this specification
may occur multiple times.
If the

alternative is chosen,
it has
either a
base
[attribute]
or a

among its
[children]
, but not
both.
If the

alternative is chosen,
it has
either an
itemType
[attribute]
or a

among its
[children]
but not both.
If the

alternative is chosen, either it
has a non-empty
memberTypes
[attribute]
or it
has at least one
simpleType
[child]
3.16.4 Simple Type Definition Validation Rules
Validation Rule: String Valid
For a string
to be locally
valid
with respect to a simple type definition
all
of the following
must
be true:
The
normalized value
of
, is calculated using
the
whiteSpace facet
, and any other
pre-lexical facets
associated with
, as described in the definition
of the term "
normalized value
".
is schema-valid with respect to
as
defined by
Datatype
Valid
in
[XML Schema: Datatypes]
Let
be the
actual value
of
with respect to
. Then:
Every
ENTITY value
in
is a
declared entity name
[Definition:]
When a string
is schema-valid with respect to a simple type definition
as defined by
Datatype
Valid
with the corresponding
actual value
The
validating type
of
is
if
is not a union type,
otherwise the validating type is the
basic
member
of
's
transitive
membership
which actually
validated
If the
validating type
of
is a list type
and the
{item type definition}
of
is
, then the
validating type
of an (atomic) item value
occurring in
is
if
is not a union type, otherwise the validating type is the
basic member
of
's
transitive
membership
which actually
validated
the substring in
that corresponds to
[Definition:]
When the
validating type
of an
actual value
is
or is
derived
from a simple type definition
, the value is also
referred to as a
value
For example, an
ENTITY value
is an
actual value
whose
validating type
is or is derived from the
built-in simple type definition
ENTITY
and an
ID value
is one whose
validating type
is or is derived from
ID
[Definition:]
A string is a
declared entity name
if and only if it is equal to the
[name]
of some unparsed entity information item in the value of the
[unparsedEntities]
property of the document information item at the root of the infoset
containing the element or attribute information item whose
normalized value
the string is.
3.16.5 Simple Type Definition Information Set
Contributions
None as such.
3.16.6 Constraints on Simple Type Definition Schema Components
3.16.6.1 Simple Type Definition Properties Correct
All simple type definitions
must
satisfy both
the following constraints.
Schema Component Constraint: Simple Type Definition Properties Correct
All
of the following
must
be true:
The values of the properties of a simple type
definition are as described in the property tableau in
The Simple Type Definition
Schema Component
, modulo the impact of
Missing Sub-components (§5.3)
All simple type definitions are, or are
derived
ultimately from,
xs:anySimpleType
(so circular
definitions are disallowed). That is, it is possible
to reach a primitive datatype or
xs:anySimpleType
by

following the
{base type definition}
zero or more
times.
The
{final}
of the
{base type definition}
does not
contain
restriction
There is not
more than one member of
{facets}
of the same kind.
Each member of
{facets}
is
supported by the processor.
Note:
As specified normatively elsewhere, all conforming
processors
must
support the facets defined by
[XML Schema: Datatypes]
; support for additional facets is
implementation-defined
If a schema document applies an
unknown
facet,
the immediate result will be a violation of this constraint,
so that the simple type defined by means of that facet
will be excluded from the schema, and any references to it
will be treated as undischarged references.
3.16.6.2 Derivation Valid (Restriction, Simple)
Schema Component Constraint: Derivation Valid (Restriction, Simple)
For any
Simple Type Definition
whose
{base type definition}
is some
Simple Type Definition
the appropriate
case
among the following
must
be true:
If
{variety}
atomic
then
all
of the following are true:
1.1
Either
is
xs:anyAtomicType
, or else
is an atomic simple type
definition.
Note:
The type
xs:anyAtomicType
is an exception because its
{base type definition}
is
xs:anySimpleType
, whose
{variety}
is
absent
1.2
{final}
does not contain
restriction
1.3
For each facet in
{facets}
(call this
DF
all
of the following are true:
1.3.1
DF
is applicable to
, as specified in
Applicable
Facets
of
[XML Schema: Datatypes]
1.3.2
DF
satisfies the constraints
on facet components given in the appropriate subsection of
Constraining Facets
in
[XML Schema: Datatypes]
If
{variety}
list
then
all
of the following are true:
2.1
{item type definition}
is not a special type definition and either
{item type definition}
{variety}
atomic
or
{item type definition}
{variety}
union
and
there
are no
types whose
{variety}
is
list
among
the union's
transitive
membership
2.2 The appropriate
case
among the following is true:
2.2.1
If
is
xs:anySimpleType
then
all
of the following are true:
2.2.1.1
{item type definition}
{final}
does not contain
list
2.2.1.2
{facets}
contains only the
whiteSpace
facet component
with
{value}
collapse
and
{fixed}
true
2.2.2
otherwise
all
of the following are true:
2.2.2.1
{variety}
list
2.2.2.2
{final}
does not contain
restriction
2.2.2.3
{item type definition}
is validly
derived
from
{item type definition}
, as defined in
Type Derivation OK (Simple) (§3.16.6.3)
2.2.2.4
All facets in
{facets}
are applicable to
, as specified in
Applicable
Facets
2.2.2.5
All facets in
{facets}
satisfy the constraints on facet components given in the appropriate subsection
of
Constraining Facets
The first case above will apply when a list is
constructed
by
specifying an item type, the second when
derived
by restriction from another list.
If
{variety}
is
union
then
all
of the following are true:
3.1
{member type definitions}
does not contain a special type definition.
3.2 The appropriate
case
among the following is true:
3.2.1
If
is
xs:anySimpleType
then
all
of the following are true:
3.2.1.1
All of the
{member type definitions}
have a
{final}
which does not contain
union
3.2.1.2
{facets}
is empty.
3.2.2
otherwise
all
of the following are true:
3.2.2.1
{variety}
union
3.2.2.2
{final}
does not contain
restriction
3.2.2.3
Each type definition in
{member type definitions}
is validly
derived
from the corresponding type definition in
{member type definitions}
, as
defined in
Type Derivation OK (Simple) (§3.16.6.3)
3.2.2.4
All facets in
{facets}
are applicable to
, as specified in
Applicable
Facets
3.2.2.5
All facets in
{facets}
satisfy the constraints on facet components given in the appropriate subsection
of
Constraining Facets
The first case above will apply when a union is
constructed
by specifying one or more member types, the second
when
derived
by restriction from another union.
3.3
Neither
nor any type
derived
from it is a member of its
own
transitive
membership
[Definition:]
simple type definition
is a
valid restriction
of its
{base type definition}
if and only if
satisfies constraint
Derivation Valid (Restriction, Simple) (§3.16.6.2)
3.16.6.3 Type Derivation OK (Simple)
The following constraint defines relations appealed to elsewhere in
this specification.
Schema Component Constraint: Type Derivation OK (Simple)
For a simple type definition (call it
, for
derived
) to be validly
derived
from a type definition (call this
, for base) subject to a set of blocking keywords
drawn from the set {
extension
restriction
list
union
} (of which only
restriction
is actually relevant; call this set
one
of the following
must
be true:
They are the same type definition.
All
of the following are true:
2.1
restriction
is not in
, or in
{base type definition}
{final}
2.2
One or more
of the following is true:
2.2.1
{base type definition}
2.2.2
{base type definition}
is not
xs:anyType
and is validly
derived
from
given
as defined by this constraint.
2.2.3
{variety}
list
or
union
and
is
xs:anySimpleType
2.2.4
All
of the following are true:
2.2.4.1
{variety}
union
2.2.4.2
is validly
derived
from a type definition
in
's
transitive
membership
given
, as defined by this
constraint.
2.2.4.3
The
{facets}
property of
and of any
intervening
union
datatypes is empty.
Note:
It is a consequence of this requirement that the
value space
lexical space
, and
lexical
mapping
of
will be subsets of those of
Note:
With respect to clause
, see the Note on identity at
the end of
(§3.4.6.5)
above.
Note:
When a simple type definition
is said to be
"validly
derived
" from a type definition
without mention of any specific set of blocking keywords,
then what is meant is that
is validly derived from
, subject to the empty set of blocking keywords,
i.e. without any particular limitations.
Note:
It is a consequence of clause
2.2.4
that
the constraint
(§3.16.6.2)
can hold between
Simple Type Definition
in the
transitive membership
of a union type, and the union type,
even though neither is actually
derived
from the other. The
slightly misleading terminology is retained for historical reasons
and for compatibility with version 1.0 of this specification.
3.16.6.4 Simple Type Restriction (Facets)
Schema Component Constraint: Simple Type Restriction (Facets)
For a simple type definition (call it
) to restrict another simple type
definition (call it
) with a
set of facets (call this
all
of the following
must
be true:
The
{variety}
of
is the same as that of
If
{variety}
is
atomic
, the
{primitive type definition}
of
is the same as that of
The
{facets}
of
are the
{facets}
of
overlaid
with
Additional constraint(s) sometimes apply depending on the kind of
facet, see the appropriate sub-section of
4.3 Constraining
Facets
[Definition:]
Given two sets of facets
and
the result of
overlaying
with
is the set of facets
for which
all
of the following are true:
Every facet in
is in
Every facet in
is in
unless

it is of the same kind as some
facet in
in which case it is not included in
Every facet in
is required by clause
or clause
above.
3.16.7 Built-in Simple Type Definitions
3.16.7.1
xs:anySimpleType
The
Simple Type Definition
of
anySimpleType
is
present in every schema.
It has the following properties:
Simple Type Definition of anySimpleType
Property
Value
{name}
anySimpleType
{target namespace}
{final}
The empty set
{context}
absent
{base type definition}
xs:anyType
{facets}
The empty set
{fundamental facets}
The empty set
{variety}
absent
{primitive type definition}
absent
{item type definition}
absent
{member type definitions}
absent
{annotations}
The empty sequence
The definition
of
xs:anySimpleType
is the
root of the simple type definition
hierarchy, and as such mediates between the other simple type
definitions, which all eventually trace back to it via their
{base type definition}
properties,
and
xs:anyType
, which is
its
{base type definition}
3.16.7.2
xs:anyAtomicType
The
Simple Type Definition
of
anyAtomicType
is present in every schema.
It has the following properties:
Simple Type Definition of anyAtomicType
Property
Value
{name}
anyAtomicType
{target namespace}
{final}
The empty set
{context}
absent
{base type definition}
xs:anySimpleType
{facets}
The empty set
{fundamental facets}
The empty set
{variety}
atomic
{primitive type definition}
absent
{item type definition}
absent
{member type definitions}
absent
{annotations}
The empty sequence
3.16.7.3
xs:error
Simple Type Definition
for
xs:error
is present in every schema
by definition. It has the following properties:
Simple Type Definition of
xs:error
Property
Value
{name}
error
{target namespace}
{final}
extension
restriction
list
union
{context}
absent
{base type definition}
xs:anySimpleType
{facets}
The empty set
{fundamental facets}
The empty set
{variety}
union
{primitive type definition}
absent
{item type definition}
absent
{member type definitions}
The empty sequence
{annotations}
The empty sequence
Note:
The datatype
xs:error
has no valid instances
(i.e. it has an empty value space and an empty lexical space).
This is a natural consequence of its construction: a value is
a value of a union type if and only if it is a value of at
least one member of the
{member type definitions}
of the union. Since
xs:error
has
no member type definitions, there can be no values which are
values of at least one of its member types. And since the value
space is empty, the lexical space is also empty.
The type
xs:error
is expected to be used
mostly in conditional type assignment. Whenever it serves as the
governing
type definition for an attribute or element information
item, that item will be invalid.
3.16.7.4 Built-in primitive datatypes
Simple type definitions corresponding to all the built-in
primitive datatypes, namely
string
boolean
float
double
decimal
dateTime
duration
time
date
gMonth
gMonthDay
gDay
gYear
gYearMonth
hexBinary
base64Binary
anyURI
QName
and
NOTATION
(see the
Primitive
Datatypes
section of
[XML Schema: Datatypes]
) are present by
definition in
every schema
as follows:
Simple Type Definition corresponding to the built-in primitive datatypes
Property
Value
{name}
[as appropriate]
{target namespace}
{base type definition}
xs:anyAtomicType
{final}
The empty set
{variety}
atomic
{primitive type definition}
[this simple type
definition itself]
{facets}
{a
whitespace
facet with
[value]
collapse
and
[fixed]
true
in all cases except
string
, which has
[value]
preserve
and
[fixed]
false
{fundamental facets}
[as appropriate]
{context}
absent
{item type definition}
absent
{member type definitions}
absent
{annotations}
The empty sequence
All conforming implementations of this specification
must
support all the primitive datatypes defined in
[XML Schema: Datatypes]
It is
implementation-defined
whether additional primitive datatypes
are supported, and whether, if so, they are automatically
incorporated in every schema or not. If
implementation-defined
primitives are supported, the implementation
must
satisfy the rules for
implementation-defined
primitive datatypes
described in
[XML Schema: Datatypes]
[Definition:]
A type about which a processor possesses prior knowledge, and
which the processor can support without any declaration of the
type being supplied by the user, is said to be
automatically known
to the processor.
Note:
By their nature, primitive types can be supported by a
processor only if
automatically known
to that processor.
Types
automatically known
to a processor, whether primitive or
derived, can be included automatically by that processor in
all schemas, but need not be. It is possible, for example,
for a processor to have built-in prior knowledge of a set of
primitive and derived types, but to include them in the schema
only when the relevant namespace is explicitly imported, or a
given run-time option is selected, or on some other
conditions; such conditions are not defined by this
specification.
Note:
The definition of "
automatically known
" is not
intended to prevent implementations from allowing users
to specify new primitive types.
If an implementation defines a mechanism by which users can
define or supply an implementation of a primitive type, then
when those mechanisms are successfully used, such user-supplied
types are
automatically known
to the implementation, as that term is
used in this specification.
3.16.7.5 Other built-in datatypes
Similarly, simple type definitions corresponding to all the other built-in datatypes (see the
Other Built-in Datatypes
section
of
[XML Schema: Datatypes]
) are present by definition in
every schema, with properties as specified in
[XML Schema: Datatypes]
and as
represented in XML in
Illustrative XML representations for the built-in ordinary type definitions
Simple Type Definition corresponding to the built-in ordinary datatypes
Property
Value
{name}
[as appropriate]
{target namespace}
{base type definition}
[as specified in the appropriate
sub-section of
Other Built-in Datatypes
{final}
The empty set
{variety}
atomic
or
list
, as specified in the appropriate
sub-section of
Other Built-in Datatypes
{primitive type definition}
[if
{variety}
is
atomic
, then the
{primitive type definition}
of the
{base type definition}
, otherwise
absent
{facets}
[as specified in the appropriate
sub-section of
Other Built-in Datatypes
{fundamental facets}
[as specified in the appropriate
sub-section of
Other Built-in Datatypes
{context}
absent
{item type definition}
if
{variety}
is
atomic
, then
absent
, otherwise as specified in the appropriate
sub-section of
Other Built-in Datatypes
{member type definitions}
absent
{annotations}
As shown in the XML representations
of the ordinary built-in datatypes in
Illustrative XML representations for the built-in ordinary type definitions
All conforming implementations of this specification
must
support all the built-in datatypes defined in
[XML Schema: Datatypes]
It is
implementation-defined
whether additional derived types
are
automatically known
to the implementation without declaration
and whether, if so, they are automatically
incorporated in every schema or not.
3.17 Schemas as a Whole
3.17.1
The Schema Itself
3.17.2
XML Representations of Schemas
3.17.2.1
References to Schema Components
3.17.2.2
References to Schema Components from Elsewhere
3.17.3
Constraints on XML Representations of Schemas
3.17.4
Validation Rules for Schemas as a Whole
3.17.5
Schema Information Set Contributions
3.17.5.1
Schema Information
3.17.5.2
ID/IDREF Table
3.17.6
Constraints on Schemas as a Whole
3.17.6.1
Schema Properties Correct
3.17.6.2
QName resolution (Schema Document)
3.17.6.3
QName resolution (Instance)
A schema consists of a set of schema components.
Example
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.com/example">
. . .

The XML representation of the skeleton of a schema.
3.17.1 The Schema Itself
At the abstract level, the schema itself is just a container
for its components.
Schema Component:
Schema
, a kind of
Annotated Component
{annotations}
A sequence of
Annotation
components.
{type definitions}
A set of
Type Definition
components.
{attribute declarations}
A set of
Attribute Declaration
components.
{element declarations}
A set of
Element Declaration
components.
{attribute group definitions}
A set of
Attribute Group Definition
components.
{model group definitions}
A set of
Model Group Definition
components.
{notation declarations}
A set of
Notation Declaration
components.
{identity-constraint definitions}
A set of
Identity-Constraint Definition
components.
3.17.2 XML Representations of Schemas
A schema is represented in XML by one or more
schema documents
, that is, one or more

element information items. A
schema document
contains
representations for a collection of schema components, e.g. type
definitions and element declarations, which have a common
{target namespace}
. A
schema document
which has one or more

element information items corresponds to a schema with components
with more than one
{target
namespace}
, see
Import Constraints and Semantics (§4.2.6.2)
As always, the mapping rules
given in this section apply after, not before, the appropriate
pre-processing
XML Representation Summary
schema
Element Information Item et al.
attributeFormDefault = (
qualified
unqualified
) : unqualified
blockDefault =

#all
| List of (
extension
restriction
substitution
))
: ''
defaultAttributes =
QName
xpathDefaultNamespace =

anyURI
| (
##defaultNamespace
##targetNamespace
##local
))
: ##local
elementFormDefault = (
qualified
unqualified
) : unqualified
finalDefault =

#all
| List of (
extension
restriction
list
union
))
: ''
id =
ID
targetNamespace =
anyURI
version =
token
xml:lang =
language
{any attributes with non-schema namespace . . .}
Content:
((
include
import
redefine
override
annotation
)*, (
defaultOpenContent
annotation
*)?, ((
simpleType
complexType
group
attributeGroup
element
attribute
notation
),
annotation
*)*)

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

The

element information item
maps to a
Schema
component as follows.
XML Mapping Summary for
Schema
Schema Component
Property
Representation
{type definitions}
The simple and complex type definitions
corresponding to all the

and

element information items
in the
[children]
, if any, plus any

definitions brought in via

(see
Assembling a schema for a single target namespace from
multiple schema definition documents

) (§4.2.3)
),

(see
Overriding component definitions (

) (§4.2.5)
),

(see
Including modified component definitions (

) (§4.2.4)
),
and

(see
References to schema components across namespaces (

) (§4.2.6)
).
{attribute declarations}
The (top-level) attribute declarations corresponding to all
the

element information items in
the
[children]
, if any, plus any

declarations brought in via



, and

{element declarations}
The (top-level)
element declarations corresponding to all the

element information items in the
[children]
, if any, plus any

declarations brought in via



and

{attribute group definitions}
The attribute group definitions
corresponding to all the

element information items in the
[children]
, if any, plus any
definitions brought in via



, and

{model group definitions}
The model group definitions
corresponding to all the

element information items in the
[children]
, if any, plus any
definitions brought in via


and

{notation declarations}
The notation declarations
corresponding to all the

element information items in the
[children]
, if any, plus any
declarations brought in via



, and

{identity- constraint definitions}
The identity-constraint definitions corresponding to all the


, and

element information items anywhere
within the
[children]
, if any, plus any

definitions brought in via



, and

{annotations}
The
annotation mapping
of the set of elements containing the

and all the




and

[children]
, if any,
as defined in
XML Representation of Annotation Schema Components (§3.15.2)
Note that none of the attribute information items displayed
above correspond directly to properties of schemas. The
blockDefault
finalDefault
attributeFormDefault
elementFormDefault
and
targetNamespace
attributes are appealed to in the sub-sections above, as they
provide global information applicable to many
representation/component correspondences. The other attributes
id
and
version
) are for user
convenience, and this specification defines no semantics for
them.
The definition of the schema abstract data model in
XSD Abstract Data Model (§2.2)
makes clear that most components have a
{target namespace}
. Most components
corresponding to representations within a given

element information item will have a
{target namespace}
which corresponds to the
targetNamespace
attribute.
Since the empty string is not a legal namespace name,
supplying an empty string for
targetNamespace
is
incoherent, and is
not
the same as not specifying it
at all. The appropriate form of schema document corresponding to
schema
whose components have no
{target namespace}
is one which has no
targetNamespace
attribute specified at all.
Note:
[XML Namespaces 1.1]
discusses only instance document syntax for
elements and attributes; it therefore provides no direct framework for managing
the names of type definitions, attribute group definitions, and so on.
Nevertheless, the specification applies the target namespace facility uniformly to all
schema components, i.e. not only declarations but also definitions have a
{target namespace}
Although the example schema at the beginning of this section might be a complete XML document,

need not be the document element, but can appear within other documents.
Indeed there is no requirement that a schema correspond to a (text) document
at all: it could correspond to an element information item constructed 'by
hand', for instance via a DOM-conformant API.
Aside from

and

which do not correspond directly to any schema component at all, each
of the element information items which
may
appear in the content
of

corresponds to a schema component, and all except

are
named. The sections below present each such item in turn, setting out
the components to which it
corresponds.
3.17.2.1 References to Schema Components
Reference to schema components from a schema document is managed in
a uniform way, whether the component corresponds to an element
information item from the same schema document or is imported
References to schema components across namespaces (

) (§4.2.6)
) from an external schema
(which
may
, but need not, correspond to an actual schema
document). The form of all such references is a
QName
[Definition:]
QName
is a
name with an optional namespace qualification, as defined in
[XML Namespaces 1.1]
. When used in connection with the XML
representation of schema components or references to them, this refers
to the simple type
QName
as defined in
[XML Schema: Datatypes]
For brevity, the term
QName
is also used to refer to
actual values
in the value space of the
QName
simple type, which are
expanded names
with a
[Definition:]
local name
and a
[Definition:]
namespace name
[Definition:]
An
NCName
is
a name with no colon, as defined in
[XML Namespaces 1.1]
. When used in connection with the XML
representation of schema components in this specification, this refers
to the simple type
NCName
as defined in
[XML Schema: Datatypes]
Note:
It is
implementation-defined
whether a
schema processor supports the definitions of
QName
and
NCName
found in
[XML Namespaces 1.1]
or those found in
[Namespaces in XML 1.0]
or both.
[Definition:]
QName
in a schema document
resolves to
a component in a schema if and only if in the
context of that schema the QName and the component together satisfy the rule
QName resolution (Schema Document) (§3.17.6.2)
. A
QName
in
an input document, or a pair consisting of a local name and a namespace name,
resolves to
a component in a schema if and only if in the
context of that schema the QName (or the name + namespace pair) and the
component together satisfy the rule
QName resolution (Instance) (§3.17.6.3)
In each of the XML
representation expositions in the following sections, an attribute is shown as
having type
QName
if and only if it is
interpreted as referencing a schema component.
Example
xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns="http://www.example.com"
targetNamespace="http://www.example.com">
. . .

type="xsl:quantity"/>
. . .

The first of these is most probably a local reference, i.e. a reference
to a type
definition corresponding to a

element information item
located elsewhere in the schema document, the other two refer to type
definitions from schemas for other namespaces and assume that their namespaces
have been declared for import. See
References to schema components across namespaces (

) (§4.2.6)
for a discussion of importing.
3.17.2.2 References to Schema Components from Elsewhere
The names of schema components such as type definitions and element
declarations are not of type
ID
: they are not
unique within a schema, just within a symbol space. This means that simple
fragment identifiers using these names
will not work to reference schema components from outside
the context of schema documents.
The preferred way to refer to schema components
is to use
[XML Schema: Component Designators]
, which defines a mechanism to designate
schema components using the
xscd()
[XPointer]
scheme.
Alternatively, references to specific
element information items in the schema document can be interpreted as to their
corresponding schema documents. This can be done using mechanisms supported by
[XPointer]
, for example, by using shorthand pointers.
It is a matter for applications to specify whether they interpret
these
references
as being to the relevant element information item (i.e. without
special recognition of the relation of schema documents to schema components) or as being to the
corresponding schema component.
3.17.3 Constraints on XML Representations of Schemas
None as such.
3.17.4 Validation Rules for Schemas as a Whole
None as such.
3.17.5 Schema Information Set Contributions
3.17.5.1 Schema Information
Schema Information Set Contribution: Schema Information
Schema components provide a wealth of information about the
basis of
assessment
, which can often be useful for subsequent
processing. Reflecting component structure into a form suitable for
inclusion in the
post-schema-validation infoset
is the way this specification provides for
making this information available.
Accordingly,
[Definition:]
by an
item isomorphic
to a component is meant
an information item whose type is equivalent to the component's, with
one property per property of the component, with the same name, and
value either the same atomic value, or an information item
corresponding in the same way to its component value, recursively, as
necessary
The
validation root
has the following properties:
PSVI Contributions for
element or attribute information items
[schema information]
set of
namespace schema information
information
items, one for each namespace name which appears as the
{target namespace}
of any schema component in the
schema used for that assessment, and one for
absent
if any schema component in the schema
had no
{target namespace}
. Each
namespace schema information
information item has the
following properties and values:
PSVI Contributions for
namespace schema information information items
[schema namespace]
namespace name or
absent
[schema components]
A (possibly empty) set of schema component information
items, each one an
item isomorphic
to
a component whose
{target namespace}
is
the sibling
[schema namespace]
property above, drawn from
the schema used for
assessment
[schema documents]
(possibly empty) set of
schema document
information
items, with properties and values as follows, for each schema document
which contributed components to the schema, and whose
targetNamespace
matches the sibling
[schema namespace]
property above (or whose
targetNamespace
was
absent
but that contributed components to
that namespace by being

d by a schema document with that
targetNamespace
as per
Assembling a schema for a single target namespace from
multiple schema definition documents

) (§4.2.3)
):
PSVI Contributions for
schema document information items
[document location]
Either a URI reference, if available,
otherwise
absent
[document]
A document
information item, if available, otherwise
absent
The
[schema components]
property is provided for
processors which wish to provide a single access point to the
components of the schema which was used during
assessment
. Lightweight processors are free to leave it empty, but if it
is
provided, it
must
contain at a minimum all the top-level (i.e. named) components which actually figured in the
assessment
, either directly or (because an anonymous component which figured is contained within) indirectly.
3.17.5.2 ID/IDREF Table
Schema Information Set Contribution: ID/IDREF Table
In the
post-schema-validation infoset
a set of
ID/IDREF binding
information items
is
associated with the
validation root
PSVI Contributions for
element information items
[ID/IDREF table]
A (possibly empty) set of
ID/IDREF binding
information items, as specified below.
[Definition:]
Let the
eligible item set
be the set
consisting of every attribute or element
information item
for which
all
of the following are true:
its
[validation context]
is the
validation root
its
[schema actual value]
is
not
absent
its
governing
type definition
is the built-in simple type definition for
ID
IDREF
, or
IDREFS
or a type definition
derived
or
constructed
directly (in a single derivation step) or
indirectly (through one or more steps) from any
of these.
Note:
The use of
[schema actual value]
in the definition of
eligible item set
above means that
default
or
fixed
value constraints
may
play a
part in the
eligible item set
Note:
Element information items that have complex types with simple content
can appear in the
eligible item set
Then there is one
ID/IDREF binding
in the
[ID/IDREF table]
for every distinct string which is an
ID value
or an
IDREF value
in the
actual value
of a member of the
eligible item set
Each
ID/IDREF binding
has properties as follows:
PSVI Contributions for
ID/IDREF binding information items
[id]
The string identified above.
[binding]
A set consisting of every element information item for which
all
of the following are true:
its
[validation context]
is the
validation root
it has an attribute information item in
its
[attributes]
or an element information item in its
[children]
whose
actual value
is or contains
the
[id]
of
this
ID/IDREF binding
and the
corresponding type definition is or is
derived
from
ID
The net effect of the above is to have one entry for every string used as an
id, whether by declaration or by reference, associated with those elements, if
any, which actually purport to have that id. See
Validation Root Valid (ID/IDREF) (§3.3.4.5)
above
for the validation rule which actually checks for errors here.
Note:
The
ID/IDREF binding
information item, unlike most other aspects of this
specification, is essentially an internal bookkeeping mechanism. It is introduced to
support the definition of
Validation Root Valid (ID/IDREF) (§3.3.4.5)
above.
3.17.6 Constraints on Schemas as a Whole
3.17.6.1 Schema Properties Correct
All schemas (see
Schemas as a Whole (§3.17)
must
satisfy the following constraint.
Schema Component Constraint: Schema Properties Correct
All
of the following
must
be true:
The values of the properties of a schema are as described in
the property tableau in
The Schema Itself (§3.17.1)
, modulo the impact of
Missing Sub-components (§5.3)
None of the
{type definitions}
{attribute declarations}
{element declarations}
{attribute group definitions}
{model group definitions}
{notation declarations}
, or
{identity-constraint definitions}
properties contains two or more schema components with the
same
expanded name
3.17.6.2 QName resolution (Schema Document)
Schema Representation Constraint: QName resolution (Schema Document)
For a
QName
to resolve to a schema component of a specified kind
all
of the following
must
be true:
That component is a member of the value of the appropriate
property of the schema which corresponds to the schema
document within which the
QName
appears, that is
the appropriate
case
among the following is true:
1.1
If
the kind specified is simple or complex type definition,
then
the property is the
{type definitions}
1.2
If
the kind specified is attribute declaration,
then
the property is the
{attribute declarations}
1.3
If
the kind specified is element declaration,
then
the property is the
{element declarations}
1.4
If
the kind specified
is attribute group,
then
the property is the
{attribute group definitions}
1.5
If
the kind specified is
model group,
then
the property is the
{model group definitions}
1.6
If
the kind specified is notation declaration,
then
the property is the
{notation declarations}
1.7
If
the kind specified is identity-constraint
definition,
then
the property is
the
{identity-constraint definitions}
The
component's
{name}
matches the
local
name
of the
QName
The component's
{target namespace}
is identical to the
namespace name
of the
QName
The appropriate
case
among the following is true:
4.1
If
the
namespace name
of the
QName
is
absent
then
one
of the following is true
4.1.1
The

element information item of the schema document containing the
QName
has no
targetNamespace
[attribute]
4.1.2
The

element information item of the that schema document contains an

element
information item with no
namespace
[attribute]
4.2
otherwise
the
namespace name
of the
QName
is
the same as
one
of the following:
4.2.1
The
actual value
of the
targetNamespace
[attribute]
of
the

element information item of the schema document containing the
QName
4.2.2
The
actual value
of the
namespace
[attribute]
of some

element information item contained in the

element information item of that schema document.
4.2.3
4.2.4
3.17.6.3 QName resolution (Instance)
As the discussion above at
Schema Component Details (§3)
makes clear,
at the level of schema components and
validation
reference to components by name is normally not involved. In a
few cases, however, qualified names appearing in information items being
validated
must
be resolved to schema
components by such lookup. The following
constraint is appealed to in these cases.
Validation Rule: QName resolution (Instance)
A pair of a local name and a namespace name (or
absent
resolve to a schema component of a specified kind in the context of
validation
by appeal to the appropriate
property of the schema being used for the
assessment
. Each such property indexes components by name. The property to use is determined by the kind of component specified, that is,
the appropriate
case
among the following
must
be true:
If
the kind specified is simple or complex type definition,
then
the property is the
{type definitions}
If
the kind specified is attribute declaration,
then
the property is the
{attribute declarations}
If
the kind specified is element declaration,
then
the property is the
{element declarations}
If
the kind specified
is attribute group,
then
the property is the
{attribute group definitions}
If
the kind specified is
model group,
then
the property is the
{model group definitions}
If
the kind specified is notation declaration,
then
the property is the
{notation declarations}
The component resolved to is the entry in the table whose
{name}
matches the local name of the pair and whose
{target namespace}
is identical to the namespace name of the pair.
4 Schemas and Namespaces: Access and Composition
This chapter defines the mechanisms by which this specification establishes the necessary
precondition for
assessment
, namely access to
one or more schemas. This chapter also sets out in detail the relationship
between schemas and namespaces, as well as mechanisms for
modularization of schemas, including provision for incorporating definitions
and declarations from one schema in another, possibly with modifications.
Conformance (§2.4)
describes three levels of conformance for schema
processors, and
Schemas and Schema-validity Assessment (§5)
provides a formal definition of
assessment
. This section sets out
in detail the 3-layer architecture implied by the three conformance levels.
The layers
are:
The
assessment
core, relating schema components and instance
information items;
Schema representation: the connections between XML
representations and schema components, including the
relationships between namespaces and schema components;
XSD web-interoperability guidelines:
connections
from instance to schema (or schema document) and from schema document
to schema (or schema document) for the WWW.
Layer 1 specifies the manner in which a schema composed of schema components
can be applied to in the
assessment
of an
element information item. Layer 2 specifies the use of

elements in XML documents as the standard XML representation for
schema information in a broad range of computer systems and execution
environments. To support interoperation over the World Wide Web in particular,
layer 3 provides a set of conventions for schema reference on the
Web. Additional details on each of the three layers
are
provided in the sections below.
4.1 Layer 1: Summary of the Schema-validity Assessment Core
The fundamental purpose of the
assessment
core is to define
assessment
for a single
element information item and its descendants,
with respect to a
complex type
definition. All processors are required to implement this core predicate in a
manner which conforms exactly to this specification.
Assessment
is defined with reference to
an
XSD schema
(note
not
schema document
).
As specified above, each schema component is associated directly or
indirectly with a target namespace, or explicitly with no namespace. In the case of multi-namespace documents,
components for more than one target namespace will co-exist in a schema.
Processors have the option to assemble (and perhaps to optimize or
pre-compile) the entire schema prior to the start of an
assessment
episode, or to
gather the schema lazily as individual components are required. In all
cases it is required that:
The processor succeed in locating the
schema components
transitively required to complete an
assessment
(note that components derived
from
schema documents
can be integrated
with components obtained through other means);
no definition or declaration changes once it has been established;
if the processor chooses to acquire declarations and definitions
dynamically, that there be no side effects of such dynamic acquisition that
would cause the results of
assessment
to differ from that which would have
been obtained from the same schema components acquired in bulk.
Note:
the
assessment
core is defined in terms of schema components at the
abstract level, and no mention is made of the schema definition
syntax (i.e.

). Although many processors will acquire
schemas in this format, others
may
operate on compiled representations, on a
programmatic representation as exposed in some programming language, etc.
The obligation of a schema-aware processor as far as the
assessment
core is concerned is to implement one or more of the options for
assessment
given below in
Assessing Schema-Validity (§5.2)
. Neither the
choice of element information item for that
assessment
, nor which of the
means of initiating
assessment
are used, is within the scope of this specification.
Although
assessment
is defined recursively, it is also intended to be
implementable in streaming
processors. Such processors
may
choose to incrementally assemble the schema during
processing in response, for example, to encountering new namespaces.
The implication of the
invariants expressed above is that such incremental assembly
must
result in an
assessment
outcome that is the
same
as would
be given if
assessment
were
undertaken again
with the final, fully assembled schema.
4.2 Layer 2: Schema Documents, Namespaces and Composition
4.2.1
Basic concepts of schema construction and composition
4.2.2
Conditional inclusion
4.2.3
Assembling a schema for a single target namespace from
multiple schema definition documents
()
4.2.4
Including modified component definitions ()
4.2.5
Overriding component definitions ()
4.2.6
References to schema components across namespaces ()
4.2.6.1
Licensing References to Components Across Namespaces
4.2.6.2
Providing Hints for Imported Schema Document Locations
The sub-sections of
Schema Component Details (§3)
define an
XML representation for type definitions and element declarations and so on,
specifying their target namespace and collecting them into schema documents.

The following sections describe how to
assemble a complete schema from multiple sources.
Note:
The core
assessment
architecture requires that a complete schema with all the necessary
declarations and definitions be available.
This will
sometimes involve resolving both instance → schema
(or schema document)
and schema-document → schema
(or schema document) references.
As observed earlier in
Conformance (§2.4)
, the
precise mechanisms for resolving such references are expected to
evolve over time. In support of such evolution, this specification
observes the design principle that references from one schema document
to a schema use mechanisms that directly parallel those used to
reference a schema from an instance document.
Note:
In the sections below, "schemaLocation" really belongs at layer 3.
For convenience, it is documented with the layer 2 mechanisms of import and
include, with which it is closely associated.
4.2.1 Basic concepts of schema construction and composition
When a schema is assembled from multiple sources, those sources
can include both
schema documents
and other sources of
components. Several of the mechanisms described below
allow a
schema document
to refer to a schema, either
by giving the target namespace of its components,
or indirectly, by referring to a
schema document
(and
thus implicitly to the schema corresponding to that
schema document
).
The sections that follow appeal often to the following
concepts.
pre-processing
The pre-processing of a schema document before
attempting to map its contents into components,
or the pre-processing of a set of components
before they take their final form among the
components of a schema being constructed.
The following sections define several forms of
pre-processing, including:
conditional-inclusion pre-processing,
chameleon pre-processing,
redefinition pre-processing,
and
override pre-processing.
Conditional-inclusion pre-processing is always performed first;
the sequence in which other forms of pre-processing
are applied varies; details are given below.
conditional-inclusion pre-processing
The process of applying to a schema document the
filtering described in section
Conditional inclusion (§4.2.2)
This pre-processing is usually assumed silently; when
it is explicitly described, then
for a
schema document
, the result of conditional-inclusion
pre-processing of
is written "
ci
)".
immediate components
The immediate components of a
schema document
are the components corresponding to its definition and
declaration
[children]
; also written
immed
)".
inter-schema-document references
The



, and

elements defined below.
corresponding schema
The schema corresponding to a given
schema document
is the schema containing the built-in components,
the
automatically known
components automatically included
in the schema by the schema processor,
immed
and the
components included by virtue of the inter-schema-document
references included in
(for which see the rules below),
and no other components.
Also written
schema
)".
target namespace
The target namespace specified in a schema document
also written
tns
)".
chameleon pre-processing
The application, to a schema document
, of the
transformation specified in
Transformation for Chameleon Inclusion (§F.1)
with respect to some namespace
, so as to convert
it to use
as its target namespace;
also written
chameleon
)".
override pre-processing
The application, to a schema document
, of the
overrides specified in an

element
, using the rules specified in detail
in
Transformation for
xs:override
(§F.2)
also written
override
)".
redefine pre-processing
The application, to a schema
, of the
redefinitions specified in an

element
, using the rules specified in detail
in
Including modified component definitions (

) (§4.2.4)
also written
redefine
)".
Note:
This specification defines several attributes to allow
schema documents and XML instance documents to provide
information about the location of relevant schema components.
Experience has shown that the similarities and differences
among these attributes can be elusive for some readers; a
compact overview may be helpful.
The
xsi:schemaLocation
and
xsi:noNamespaceSchemaLocation
attributes
may validly appear on elements in an XML instance
document. They are technically
hints
conforming schema-aware processors
may
but need not
attempt to dereference the schema documents named
in these attributes and include the components described
there in the schema used for validation.
The
schemaLocation
attribute on the

element in a schema document is
similarly a hint: a conforming schema-aware
processor
may
but need not attempt to dereference
the schema document named by the attribute.
The
schemaLocation
attributes on the


, and

elements in a schema document, on the
other hand, are not hints: conforming processors
must
attempt
to de-reference the schema document named by the attribute.
For non-empty

elements, it is
an error for the attempt to fail; otherwise, the
attempt
must
be made but it is not an error for it
to fail.
In all cases, the use of the attribute in a document
indicates
the existence of a suitable schema document
at the location indicated. This is stated explicitly
below for some attributes, but not for all; where not
stated explicitly, the inference follows implicitly
from other rules.
4.2.2 Conditional inclusion
Whenever a conforming XSD processor reads a
schema document
in order to include the components defined
in it in a schema, it first performs on the schema document
the pre-processing described in this section.
Every element in the
schema document
is examined to
see whether any of
the attributes
vc:minVersion
vc:maxVersion
vc:typeAvailable
vc:typeUnavailable
vc:facetAvailable
, or
vc:facetUnavailable
appear among its
[attributes]
Where they appear, the
attributes
vc:minVersion
and
vc:maxVersion
are treated as if declared
with type
xs:decimal
, and their
actual values
are compared to a decimal
value representing the version of XSD supported by the
processor (here represented as a variable
). For processors
conforming to this version of this specification, the value of
is 1.1.
If
is less than the value of
vc:minVersion
, or
if
is greater than or equal to the value of
vc:maxVersion
then the element on which the attribute appears is
to be ignored, along with all its
attributes and
descendants.
The effect is that portions of the
schema document marked with
vc:minVersion
and/or
vc:maxVersion
are retained if
vc:minVersion
vc:maxVersion
Where they appear, the attributes
vc:typeAvailable
and
vc:typeUnavailable
are treated as if declared
with type
list of xs:QName
, and the items in their
actual values
are checked to see whether they name types
automatically known
to the processor. The attributes
vc:facetAvailable
and
vc:facetUnavailable
are similarly typed, and checked to see if they name facets
supported by the processor.
If an element in a schema document has any of the following:
vc:typeAvailable
, where any item in the
actual value
is
not
the
expanded name
of some type definition
automatically known
to the
processor
vc:typeUnavailable
, where

every item in the
actual value
is the
expanded name
of some type
definition
automatically known
to and supported by the processor
vc:facetAvailable
, where any item in the
actual value
is not the
expanded name
of some facet
known to and supported by the processor
vc:facetUnavailable
, where

every item in the
actual value
is the
expanded name
of some facet known to and supported
by the processor
then the element on which the attribute appears is to be
ignored, along with all its attributes and descendants.
Note:
It is expected that
vc:typeAvailable
etc. will be
most useful in testing for
implementation-defined
primitive datatypes
and facets, or for derived types for which the processor
supplies a definition automatically. The rules just given do
not, however, attempt to restrict their use to such tests. If
the
vc:typeAvailable
attribute is used with the
expanded name
associated with one of the built-in primitive datatypes, the
datatype will (in a conforming processor) always be available,
so the test is unlikely to filter out any elements, ever, from
the schema document. But such a usage is not in itself an
error.
Note:
The
expanded names
of the built-in datatypes are as specified
in
[XML Schema: Datatypes]
; the
expanded name
of any
implementation-defined
datatype
is required by
[XML Schema: Datatypes]
to be specified by the implementation.
Note:
The
expanded names
of the facets (built-in or
implementation-defined
are the
expanded names
of the elements used in XSD schema documents
to apply the facets, e.g.
xs:pattern
for the
pattern
facet.
Note:
It is a consequence of the rules given above that
if the
actual value
of
vc:typeAvailable
is the empty list
(i.e.
vc:typeAvailable=""
), then the corresponding element
is
not
ignored. (It does not list any type that is
not available.) Conversely, if the
actual value
of
vc:typeUnavailable
is the empty list, then the corresponding
element is ignored. Similar results hold for
vc:facetAvailable
and
vc:facetUnavailable
The pre-processing of a schema document
S1
results
in a second schema document
S2
, identical to
S1
except that all elements and
attributes in
S1
which are to be ignored
are absent from
S2
We write
S2
ci
S1
).
If the

element information item in
S1
is to be ignored, then
S2
is identical
to
S1
except that any attributes other than
targetNamespace
vc:minVersion
or
vc:maxVersion
are removed from its
[attributes]
, and its
[children]
is the empty sequence.
It is
S2
, not
S1
, which
is required to conform to this specification.
Note:
If
S1
contains no elements
or attributes to be ignored, then
S1
and
S2
are identical.
Except where conditional-inclusion pre-processing is
explicitly mentioned, references to
schema documents
elsewhere in this specification invariably refer to
the result of the pre-processing step described here,
not to its input, which need not, and in the general
case will not, always conform to the rules for
schema documents laid out in this specification.
Example
Suppose some future version of XSD (say, version 3.2)
introduces a new form of element declaration. A schema author
might wish to exploit that new form of declaration if
possible, but wish also to ensure that the schema
document can be handled successfully by a processor
written for XSD 1.1. In such a case, a schema document
of the following form would be handled correctly by a
conforming XSD 1.1 processor:
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning">

vc:minVersion="1.1"
vc:maxVersion="3.2">


...

Even though the schema document as shown has two element
declarations for element
and thus
violates clause
of constraint
Schema Properties Correct (§3.17.6.1)
, the pre-processing step
described in this section filters out the first element
declaration, making it possible for the resulting schema
document to be valid and to conform to this specification.
Note that the semantics of the
vc:maxVersion
attribute is
"exclusive". This makes it easier for schema authors to use this feature
without leaving gaps

in the numeric ranges used to select version numbers.
Example
Suppose that a processor supports an
implementation-defined
primitive
named
xpath_expression
in namespace
",
and is presented with the following schema document:
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning"
xmlns:tns="http://example.org/extension_types"
targetNamespace="http://example.org/extension_types" >

name="e" type="tns:xpath_expression" />
name="e" type="string" />

The effect of conditional inclusion is to include the
first declaration for
and omit the second, so
that the effective schema document, after pre-processing
for conditional inclusion, is:
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning"
xmlns:tns="http://example.org/extension_types"
targetNamespace="http://example.org/extension_types" >

name="e" type="tns:xpath_expression" />

A processor which does not support type "tns:xpath_expression",
by contrast, will use the other declaration for
type in the namespace in question
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning"
xmlns:tns="http://example.org/extension_types"
targetNamespace="http://example.org/extension_types" >

name="e" type="string" />

Schema Representation Constraint: Conditional Inclusion Constraints
Whenever the attribute
vc:minVersion
or
vc:maxVersion
appears on an element information item in a
schema document
, its
initial value
must
be locally
valid
with respect to
xs:decimal
as per
String Valid (§3.16.4)
Whenever any of the attributes
vc:typeAvailable
vc:typeUnavailable
vc:facetAvailable
, or
vc:facetUnavailable
appears on an element information item in a
schema document
, its
initial value
must
be locally
valid
with respect to a simple type definition with
{variety}
list
and
{item type definition}
xs:QName
, as per
String Valid (§3.16.4)
Any attribute from the
vc:
namespace that appears
on an element information item in a
schema document
should
be one of the attributes described
elsewhere in this document (i.e. one of
vc:minVersion
vc:maxVersion
vc:typeAvailable
vc:typeUnavailable
vc:facetAvailable
, or
vc:facetUnavailable
).
Note:
Processors are encouraged to issue warnings about
vc:
attributes other than those named,
but it is not an error for such
attributes to appear in a
schema document
. The rule just
given is formulated with a "
should
" and not
a "
must
" in order to preserve the ability of
future versions of this specification to add new attributes
to the schema-versioning namespace.
4.2.3 Assembling a schema for a single target namespace from
multiple schema definition documents

Schema components for a single target namespace can be
assembled from several
schema documents
, that is several

element information items:
XML Representation Summary
include
Element Information Item
id =
ID
schemaLocation
anyURI
{any attributes with non-schema namespace . . .}
Content:
annotation
?)


information item
may
contain any
number of

elements. Their
schemaLocation
attributes, consisting of a URI reference,
identify other
schema documents
, that is

information items.
If two

elements
specify the same schema location (after resolving
relative URI references) then they refer to the same schema document. If
they specify different schema locations, then they refer to different schema
documents, unless the implementation is able to determine that the two URIs
are references to the same resource.
If a
schema document
contains one or more

elements,
then
schema
) contains not only
immed
) but also all the components
of
schema
), for each
schema document
identified by an

element
child of
Such included schema
documents
must
either (a) have the same
targetNamespace
as
or (b) no
targetNamespace
at all,
in which case the
components included in
schema
) are
not those of
schema
) itself, but instead
those of
schema
chameleon
tns
),
)),
that is, the schema corresponding to the result of applying
chameleon pre-processing to
to convert it to
target namespace
tns
).
Schema Representation Constraint: Inclusion Constraints and Semantics
In addition to the conditions imposed on

element
information items by the schema for schema documents,
all
of the following also apply:
If the
actual value
of the
schemaLocation
[attribute]
successfully resolves
one or more
of the following is true:
1.1
It resolves to (a fragment of) a resource which is an
XML document (of type
application/xml
or
text/xml
with an XML declaration for
preference, but this is not required), which in turn
corresponds to a

element
information item in a well-formed information set.
1.2
It resolves to a

element
information item in a well-formed information set.
In either case call the


item
D2
and the

ing item's parent

item
D1
One
of the following
must
be true:
2.1
D2
has a
targetNamespace
[attribute]
, and its
actual value
is identical to the
actual value
of the
targetNamespace
[attribute]
of
D1
(which
must
have such an
[attribute]
).
2.2
Neither
D2
nor
D1
have a
targetNamespace
[attribute]
2.3
D2
has no
targetNamespace
[attribute]
(but
D1
does).
2.4
D2
does not exist (e.g. because the
actual value
of the
schemaLocation
[attribute]
does not
resolve successfully).
3 The appropriate
case
among the following
must
be true:
3.1
If
clause
2.1
or clause
2.2
above is satisfied,
then
all
of the following are true:
3.1.1
D2
corresponds to a conforming schema (call it
S2
).
3.1.2
The schema corresponding to
D1
includes not only definitions or
declarations corresponding to the appropriate members of its own
[children]
, but also components identical to all the
schema components
of
S2
(with the possible
exception of its
Schema
component).
3.2
If
clause
2.3
above is
satisfied,
then
all
of the following are true:
3.2.1
Let
D2′
be a

information item

obtained by performing on
D2
the transformation
specified in
Transformation for Chameleon Inclusion (§F.1)
D2′
corresponds to a conforming schema (call it
S2
).
Note:
The transformation in
Transformation for Chameleon Inclusion (§F.1)
(a) adds a
targetNamespace
[attribute]
to
D2
whose value is the same as that of the
targetNamespace
[attribute]
of
D1
, and (b) updates all unqualified
QName references so that their namespace names become the
actual value
of the
targetNamespace
[attribute]
Implementations need not use the
[XSLT 2.0]
stylesheet given in
Transformation for Chameleon Inclusion (§F.1)
as long as an equivalent result
is produced.
In particular, different
algorithms for generating a unique namespace
prefix
may
be used, even if they produce different
results.
3.2.2
The schema corresponding to
D1
includes not only definitions or
declarations corresponding to the appropriate members of its own
[children]
, but also components identical to all the
schema components
of
S2
(with the possible
exception of its
Schema
component).
Note:
The above rule applies recursively. For example, if
includes
and
includes
, where
has a
targetNamespace
[attribute]
, but neither
nor
does, then the effect is as if
included
B'
and
B'
included
C'
, where
B'
and
C'
are identical to
and
respectively,
except that they both have a
targetNamespace
[attribute]
the same as
's.
Note:
In this case, it is
D2′
, not
D2
, which is required
by clause
3.2.1
to correspond to a conforming schema.
In particular, it is not an error for
D2
to
fail to satisfy
all of the constraints governing schema documents, while
it
is
an error if
D2′
fails to satisfy them.
Note:
If
D2
imports the target namespace of
D1
, then
the effect of clause
3.2
will be to
cause an error owing to the violation of clause
of
Import Constraints and Semantics (§4.2.6.2)
(which forbids a schema document to
import its own target namespace). Other constraint
violations may also be brought about; caution is
advised.
It is
not
an error for the
actual value
of the
schemaLocation
[attribute]
to fail to resolve
at all,
in which case the corresponding inclusion
must not
be performed. It
is
an error for it to resolve but the rest of clause 1
above to fail to be satisfied. Failure to resolve is likely
to cause less than complete
assessment
outcomes, of course.
As discussed in
Missing Sub-components (§5.3)
QName
s in XML representations will
sometimes fail to
resolve
, rendering components incomplete
and unusable because of missing subcomponents. During schema
construction, implementations
must
retain
QName
values for such references, in case
an appropriately-named component becomes available to discharge the
reference by the time it is actually needed.
Absent
target
namespace
name
s of such as-yet unresolved reference
QName
s in

components
must
also be converted if clause
3.2
is
satisfied.
Note:
The above is carefully worded so that
multiple

ing of the same schema document will not
constitute a violation of
clause
of
Schema Properties Correct (§3.17.6.1)
, but
applications are allowed, indeed encouraged, to avoid

ing the
same schema document more than once to forestall the necessity
of establishing identity component by component.
If there is a sequence of schema documents
S1
S2
, ...
Sn
and a sequence of

elements
E1
E2
, ...
En
such that each
contains the corresponding
, and each
(where
points to
schema document
+ 1
, and
En
points to
S1
(i.e. if there is a cycle in the relation defined by the

element), then the same schema corresponds to all
of the schema documents
S1
, ...
Sn
in the cycle, and it includes the same
components as the schema corresponding
to
S1
in the similar case where
Sn
has no

element pointing at
S1
Note:
Informally:
cycles of

elements are legal, and
processors should guard against infinite loops.
4.2.4 Including modified component definitions (

Note:
The redefinition feature described in the remainder of this
section is
deprecated
and may be removed from future versions of
this specification. Schema authors are encouraged to avoid its
use in cases where interoperability or compatibility with later
versions of this specification are important.
In order to provide some support for evolution and versioning, it is
possible to incorporate components corresponding to a schema document
with modifications
. The modifications have a pervasive impact,
that is, only the redefined components are used, even when referenced from
other incorporated components, whether redefined themselves or not.
XML Representation Summary
redefine
Element Information Item
id =
ID
schemaLocation
anyURI
{any attributes with non-schema namespace . . .}
Content:
annotation
| (
simpleType
complexType
group
attributeGroup
))*


information item
may
contain any number of

elements. Their
schemaLocation
attributes, consisting of a URI reference, identify other
schema documents
, that is

information items.
If a schema document
contains a

element
pointing to some schema document
, then
schema
) contains not only the components in
immed
), but also
all the components (with the exception, in most cases,
of the schema-as-a-whole component) of
redefine
schema
)).
For any document
pointed at by a

element
in
, it
must
be the case either (a) that
tns
) =
tns
or else (b) that
tns
) is
absent
, in which case
schema
) includes not
redefine
schema
)) itself
but
redefine
schema
chameleon
tns
),
))).
That is, the redefinition pre-processing is applied not to the
schema corresponding to
but instead to the schema corresponding
to the schema document
chameleon
tns
),
),
which is the result of applying chameleon pre-processing to
to convert it to target namespace
tns
).
The definitions within the

element itself are
restricted to be redefinitions of components from the

schema document,
in terms of themselves
. That is,
Type
definitions
must
use themselves as their base type definition;
Attribute
group definitions and model group definitions
must
be supersets or subsets of their original
definitions, either by including exactly one
reference to themselves or by containing only (possibly restricted) components
which appear in a corresponding way in their

d selves.
Not all the components of the

schema document need be redefined.
This mechanism is intended to provide a declarative and modular approach to
schema modification, with functionality no different except in scope from what
would be achieved by wholesale text copying and redefinition by editing. In
particular redefining a type is not guaranteed to be side-effect free: it can
have unexpected impacts on other type definitions which are based
on the redefined one, even to the extent that some such definitions become
ill-formed.
Note:
The pervasive impact of redefinition reinforces the need for
implementations to adopt some form of lazy or 'just-in-time' approach to
component construction, which is also called for in order to avoid
inappropriate dependencies on the order in which definitions and references appear in (collections of) schema documents.
Example
v1.xsd:

v2.xsd:

The schema corresponding to
v2.xsd
has everything specified
by
v1.xsd
, with the
personName
type redefined, as
well as everything it specifies itself. According to
this schema, elements constrained
by the
personName
type
may
end with a
generation
element. This includes not only the
author
element, but also the
addressee
element.
Schema Representation Constraint: Redefinition Constraints and Semantics
In addition to the conditions imposed on

element information items by the schema for schema documents
all
of the following also apply:
If there are any element information items among the
[children]
other than

then the
actual value
of the
schemaLocation
[attribute]
must
successfully resolve.
If the
actual value
of the
schemaLocation
[attribute]
successfully resolves
one or more
of the following is true:
2.1
it resolves to (a fragment of) a resource which is an
XML document (see clause
1.1
of
Inclusion Constraints and Semantics (§4.2.3)
), which in turn
corresponds to a

element
information item in a well-formed information set.
2.2
It resolves to a

element
information item in a well-formed information set.
In either case call the


item
D2
and the

ing item's parent

item
D1
One
of the following
must
be true:
3.1
D2
has a
targetNamespace
[attribute]
, and its
actual value
is identical to the
actual value
of the
targetNamespace
[attribute]
of
D1
(which
must
have such an
[attribute]
).
3.2
Neither
D2
nor
D1
have a
targetNamespace
[attribute]
3.3
D2
has no
targetNamespace
[attribute]
(but
D1
does).
4 The appropriate
case
among the following
must
be true:
4.1
If
clause
3.1
or clause
3.2
above is satisfied,
then
4.1.1
D2
corresponds to a conforming schema (call it
S2
).
4.1.2
The schema corresponding to
D1
includes not only definitions or
declarations corresponding to the appropriate members of its own
[children]
, but also components identical to all the
schema components
of
S2
, with the
exception of those explicitly redefined
(see
Individual Component Redefinition (§4.2.4)
below
and with the possible
exception of the
Schema
component
of
S2
)).
4.2
If
clause
3.3
above is
satisfied,
then
4.2.1
Let
D2′
be a

information item

obtained by performing on
D2
the transformation
specified in
Transformation for Chameleon Inclusion (§F.1)
D2′
corresponds to a conforming schema (call it
S2
).
4.2.2
The schema corresponding to
D1
includes not only definitions or
declarations corresponding to the appropriate members of its own
[children]
, but also components identical to all the
schema components
of
S2
, with the
exception of those explicitly redefined
(see
Individual Component Redefinition (§4.2.4)
below).
Note:
In this case, it is
D2′
and not
D2
, which is required
by clause
4.2.1
to correspond to a conforming schema.
In particular, it is not an error for
D2
to
fail to satisfy
all of the constraints governing schema documents, while
it
is
an error if
D2′
fails to satisfy them.
Within the
[children]
, each

must
have a

among its
[children]
and
each

must
have a
restriction
or
extension
among its
grand-
[children]
the
actual value
of whose
base
[attribute]
must
be the same as the
actual value
of its own
name
attribute plus target namespace;
Within the
[children]
, for each

the appropriate
case
among the following
must
be true:
6.1
If
it has a

among its
contents at some level the
actual value
of whose
ref
[attribute]
is the same as the
actual value
of its own
name
attribute plus
target namespace
and that

does not have an

ancestor,
then
all
of the following are true:
6.1.1
It has exactly one such group.
6.1.2
The
actual value
of both that group's
minOccurs
and
maxOccurs
[attribute]
is
(or
absent
).
6.2
If
it has no such self-reference,
then
all
of the following are true:
6.2.1
The
actual value
of its own
name
attribute
plus target namespace successfully
resolves
to a
model group definition in
S2
6.2.2
The
{model group}
of the
model group definition which corresponds to it per
XML Representation of Model Group Definition Schema Components (§3.7.2)
accepts a subset of the element
sequences accepted by that model group definition in
S2
Within the
[children]
, for each

the appropriate
case
among the following
must
be true:
7.1
If
it has an

among its contents the
actual value
of whose
ref
[attribute]
is the same as the
actual value
of its own
name
attribute plus
target namespace,
then
it has exactly one such group.
7.2
If
it has no such self-reference,
then
all
of the following are true:
7.2.1
The
actual value
of its own
name
attribute
plus target namespace successfully
resolves
to an
attribute group definition in
S2
7.2.2
The
{attribute uses}
and
{attribute wildcard}
of the attribute group
definition which corresponds to it per
XML Representation of Attribute Group Definition Schema Components (§3.6.2)
viewed as the
{attribute uses}
and
{attribute wildcard}
of a
Complex Type Definition
and the
{attribute uses}
and
{attribute wildcard}
of that attribute group
definition in
S2
viewed as the
{attribute uses}
and
{attribute wildcard}
of the
{base type definition}
satisfy clause
of
Derivation Valid (Restriction, Complex) (§3.4.6.3)
Note:
An attribute group restrictively redefined per
clause
7.2
corresponds to an attribute
group whose
{attribute uses}
consist all and only of those attribute uses corresponding
to

s explicitly present among
the
[children]
of the

ing

. No inheritance from the

d attribute group occurs. Its
{attribute wildcard}
is
similarly based purely on an explicit

, if present.
Schema Representation Constraint: Individual Component Redefinition
Corresponding to each non-

member of the
[children]
of a

there are one or two schema components in
the

ing schema:
The

and

[children]
information items each
correspond to two components:
1.1
One component which corresponds to the top-level definition item with
the same
name
in
the

d schema document, as defined in
Schema Component Details (§3)
, except that its
{name}
is
absent
and its
{context}
is the redefining component, as defined in clause
1.2
below;
1.2
One component which corresponds to the information item itself, as defined
in
Schema Component Details (§3)
, except that its
{base type definition}
is
the component defined in clause
1.1
above.
This pairing ensures the coherence constraints on type definitions
are respected, while at the same time achieving the desired effect, namely that
references to names of redefined components in both the

ing and

d schema documents
resolve
to the redefined component
as specified in 1.2 above.
The

and

[children]
each correspond to a single component, as defined in
Schema Component Details (§3)
, except that if and when a self-reference based on a
ref
[attribute]
whose
actual value
is the same as the item's
name
plus target namespace is
resolved
, a component which corresponds to the top-level definition item of that name and the appropriate kind in
S2
is used.
In all cases there
must
be a top-level definition item of the appropriate name and kind in
the

d schema document.
Note:
The above is carefully worded so that
multiple equivalent

ing of the same schema document will not constitute a violation of
clause
of
Schema Properties Correct (§3.17.6.1)
, but applications are
allowed, indeed encouraged, to avoid

ing the same
schema document in the same way more than once to forestall the necessity of
establishing identity component by component (although this will have to be
done for the individual redefinitions themselves).
4.2.5 Overriding component definitions (

The

construct defined
in
Including modified component definitions (

) (§4.2.4)
is useful in schema evolution and versioning,
when it is desirable to have some guaranteed restriction or extension
relation between the old component and the redefined component.
But there are occasions when the schema author simply wants to
replace old components with new ones without any constraint.
Also, existing XSD processors
have implemented conflicting and non-interoperable interpretations
of

, and the

construct is
deprecated
The

construct defined in this section
allows such unconstrained replacement.
Note:
The name of the

element
has nothing to do with the use of the term
override
to denote the relation between an
instance-specified type definition
and another type. The two mechanisms are
distinct and unrelated.
XML Representation Summary
override
Element Information Item
id =
ID
schemaLocation
anyURI
{any attributes with non-schema namespace . . .}
Content:
annotation
| (
simpleType
complexType
group
attributeGroup
element
attribute
notation
))*


information item
may
contain any number of

elements. Their
schemaLocation
attributes, consisting of a URI reference, identify
("point to")
other
schema documents
that is

information items.
If a schema document
new
contains an

element
pointing to some schema document
old
, then
schema
new
) contains not only the components in
immed
new
),
but also the components in
schema
override
old
)).
For all such schema documents
old
it
must
be the case either (a) that
tns
old
) =
tns
new
),
or (b) that
tns
old
) is
absent
, in which case
schema
new
) contains not the components in
schema
override
old
)), but those in
schema
override
chameleon
tns
new
),
old
))).
That is, before the override pre-processsing is applied,
chameleon pre-processing is applied to
old
to convert it
to target namespace
tns
new
); the override
pre-processing is applied to the result, namely
chameleon
tns
new
),
old
).
Note:
If the above definition is naively translated into an
algorithm, the algorithm may fail to terminate in the case
where the graph of
include
and
override
references among schema documents contains cycles. To
guarantee termination, the algorithm must detect when it has
reached closure, that is, when further computation will have no
effect on the outcome. In particular, it is useful to recognize
(a) that it is possible to terminate as soon as conflicting
components have been generated (for example, two different type
definitions with the same name), and (b) that when
override
) (for some
and
) is
equivalent to
, no new schema
components will be contributed by further processing: this can
be detected either by comparing the input and output of the
override transformation using a comparator such as the
[XPath 2.0]
fn:deep-equal
function, or by observing the
conditions that cause
override
) to be
idempotent, for example the fact that
is empty.
The children of the

element
may
override any source declarations for
named
components which
appear among the
[children]
of the


, or

elements in the
target set
of
the

element information item..
[Definition:]
The
target set
of an

element information
item
contains
all
of the following:
The schema document identified by the
schemaLocation
attribute of
The schema document identified by the
schemaLocation
attribute of any

element information item
in a schema document contained in the
target set
of
The schema document identified by the
schemaLocation
attribute of any

element information item
in a schema document contained in the
target set
of
The
target set
of
contains no other schema documents.
Note:
The
target set
of an

element is
the transitive closure of the union of the inclusion relation (which contains
the pair (
S1
S2
) if and only if
S1
contains an

element pointing to
S2
) and the override relation (which contains
the pair (
S1
S2
) if and only if
S1
contains an

element pointing to
S2
). It does not include schema documents which
are pointed to by

or

elements,
unless they are also pointed to by

or

elements in the relevant schema documents.
Source declarations not present in the target set of
cannot
be overridden, even if they are present in other schema
documents consulted in the creation of the schema (e.g. in
schema documents pointed to by a

element). It is not an error for
an

element to contain a source declaration
which matches nothing in the target set, but it will be ignored;
in particular, it will not succeed in overriding source declarations
in schema documents not part of the target set.
Note:
The transformation described in
Transformation for
xs:override
(§F.2)
translates both

and

elements
into

elements. These

elements will, in turn, be handled by transforming their target schema
documents. Since every schema document in the target set of the original

element is the target of either an

element or of an

element, it follows that the
transformation described in
Transformation for
xs:override
(§F.2)
will be
applied to every schema document in the target set.
Note:
It is
not
forbidden for the schema document
containing
an

element
to be in the
target set
of
If applying the override transformation specified in
Transformation for
xs:override
(§F.2)
to
and
results in
a schema document equivalent to
(e.g. when none of the
[children]
of
, or of any

and

elements in
match any of the
[children]
of
, except
for the
[children]
of
themselves), then the effect is the same
as for a cyclic set of

references, or
as for multiple inclusions of the same document (as
described in the note at the end of
Assembling a schema for a single target namespace from
multiple schema definition documents

) (§4.2.3)
).
If applying the override transformation to
and
changes
any of the XML representations of components, then the effect of
being in the
target set
of
is the same
as if two different schema documents containing conflicting
definitions for the same components were included. ("As if"
is inexact; in this case what happens is, precisely,
that two schema documents with conflicting contents are
included.)
The definitions within the

element itself are
not
required to be similar in any way to
the
source declarations being
overridden. Not all the source declarations
of the overridden schema document need be
overridden.
As this mechanism is very similar to

, many similar
kinds of caution need to be taken in using

. Please
refer to
Including modified component definitions (

) (§4.2.4)
for details.
Example
v1.xsd:

v2.xsd:

The schema corresponding to
v1.xsd
has a complex type named
personName
with a sequence of
firstName
and
lastName
children. The schema corresponding to
v2.xsd
overrides
personName
, by providing a different sequence of
element children. All elements with the
personName
type are
now constrained to have the sequence of
givenName
and
surname
. This includes not only the
author
element, but also the
addressee
element.
Schema Representation Constraint: Override Constraints and Semantics
In addition to the conditions imposed on

element
information items by the schema for schema documents
all
of the following also apply:
If the
actual value
of the
schemaLocation
[attribute]
successfully resolves
one or more
of the following is true:
1.1
It resolves to (a fragment of) a resource which is an XML document (see
clause
1.1
of
Inclusion Constraints and Semantics (§4.2.3)
), which in turn
corresponds to a

element information item in a
well-formed information set.
1.2
It resolves to a

element information item in a
well-formed information set.
In either case call the overridden

item
old
and the overriding item's parent

item
new
One
of the following
must
be true:
2.1
old
has a
targetNamespace
[attribute]
, and its
actual value
is identical to the
actual value
of the
targetNamespace
[attribute]
of
new
(which
must
have such an
[attribute]
).
2.2
Neither
old
nor
new
have a
targetNamespace
[attribute]
2.3
old
has no
targetNamespace
[attribute]
(but
new
does).
3 The appropriate
case
among the following
must
be true:
3.1
If
clause
2.1
or clause
2.2
above is satisfied,
then
3.1.1
Let
old
be a

information item obtained by
performing on
old
the transformation
specified in
Transformation for
xs:override
(§F.2)
. Then
old
corresponds to a conforming schema (call it
old
).
3.1.2
The

element in schema document
new
pointing to
old
is replaced by an

element pointing to
old
and the inclusion is handled as described in
Assembling a schema for a single target namespace from
multiple schema definition documents

) (§4.2.3)
Note:
It is not necessary to perform a literal replacement
of the

element in
new
with an

element; any implementation technique
can be used as long as it produces the required result.
Note:
One effect of the rule just given is that
the schema corresponding to
new
includes not only definitions or
declarations corresponding to the appropriate members of its own
[children]
, but also components identical to all the
schema components
of
old
(with the possible
exception of the
Schema
component
of
old
).
Note:
Another effect is that if schema document
contains
a source declaration for a component
, and schema document
overrides
with its own declaration for
and schema document
in turn overrides
with a
third declaration for
, then in
calculating
schema
3.1.2.1
First, the override of
by
is handled. The
resulting schema document
′, a
modified version of
still contains an

element referring to
but the declaration for
contained in it has
been replaced by that specified in
3.1.2.2
Then, the override of
by
(the modified version of
is handled.
3.1.2.3
The resulting version of
, containing
the declaration for
originally present in
is included by
′,
which is itself included by
3.1.2.4
The resulting schema contains the version of
originally specified in schema document
(The references to "first" and
"then"
here refer to the logical precedence
of operations, not to a required order in which implementations
are required to perform particular tasks.)
3.2
If
clause
2.3
above is satisfied,
then
3.2.1
Let
old
be a

information item obtained by
performing on
old
first the transformation
specified in
Transformation for Chameleon Inclusion (§F.1)
and then the
transformation specified in
Transformation for
xs:override
(§F.2)
. Then
old
corresponds to a conforming schema (call it
S2
).
3.2.2
The

element in schema document
new
pointing to
old
is replaced by an

element pointing to
old
and the inclusion is handled as described in
Assembling a schema for a single target namespace from
multiple schema definition documents

) (§4.2.3)
Note:
The effect of applying the stylesheet in
Transformation for
xs:override
(§F.2)
is to make
old
identical to
old
except that some elements in
old
are replaced
or modified, as described in
Transformation for
xs:override
(§F.2)
Implementations do not have to use
[XSLT 2.0]
transformation, as long as the same result is produced.
Note:
It is
old
and not
old
, which is required to correspond to a
conforming schema. In particular, it is not an error for
old
to fail to
satisfy all of the constraints governing schema documents, while it
is
an error if
old
fails to satisfy them.
Note:
The effect of override pre-processing is that any declarations
and definitions contained within an

will
be substituted for matching declarations and definitions within
the target set; the resulting schema documents will then be
processed normally, as described in the relevant portions of this
specification. This has the effect that the rules for
document-level defaults (
elementFormDefault
attributeFormDefault
blockDefault
finalDefault
, and so on) are applied not in the
context of the document containing the

new
) but in the context of the document containing the
original overridden declaration or definition (
old
).
Unexpected results may be minimized if the children of an

are made independent of the document-level
defaults by explicitly specifying the desired values for
the properties in question.
Note:
In

, components are allowed or required to refer to
themselves. There is no similar special treatment in

Overriding components are constructed as if the overridden components had never
existed.
Note:
The above is carefully worded so that
multiple equivalent overrides of the
same schema document will not constitute a violation of clause
of
Schema Properties Correct (§3.17.6.1)
, but applications are allowed, indeed
encouraged, to avoid overriding the same schema document in the same way
more than once to forestall the necessity of establishing identity component
by component.
Note:
It is a consequence of the semantics of inclusion, as
defined in
Inclusion Constraints and Semantics (§4.2.3)
(in particular
clause
3.1.2
and
clause
3.2.2
);
redefinition, as defined in
Including modified component definitions (

) (§4.2.4)
import, as defined in
References to schema components across namespaces (

) (§4.2.6)
and overriding, as defined in this section,
that if the same schema document is both (a) included, imported, or
redefined, and (b) non-vacuously overridden, or if the same
schema document overridden twice in
different ways, then
the resulting schema will have duplicate and conflicting versions
of some components and will not be conforming,
just as if two different schema documents had been
included, with different declarations for the same
named
components.
4.2.6 References to schema components across namespaces (

As described in
XSD Abstract Data Model (§2.2)
, every top-level schema component is associated with
a target namespace (or, explicitly, with none). Furthermore,
each schema document carries on its

element
at most one
targetNamespace
attribute associating that document
with a target namespace. This section sets out
the
syntax and mechanisms by which references
may
be made from within a
schema document
to components

outside that document's target
namespace. Also included within the same syntax is an optional
facility for suggesting the URI of a
schema document
containing
definitions and declarations for components from the foreign
target namespace.
Note:
Some users of version 1.0 of this specification
[XSD 1.0 2E]
have mistakenly
assumed that the
primary purpose of the

is to cause retrieval of
a resource identified by the
schemaLocation
attribute.
Although the function of

is
unchanged in this version, the presentation below has been
reorganized to clarify the two separate purposes served by

, namely
(1) to license references, within a schema document, to
components in the imported namespace, and (2) to provide information
about the location of schema documents for imported namespaces.
XML Representation Summary
import
Element Information Item
id =
ID
namespace =
anyURI
schemaLocation =
anyURI
{any attributes with non-schema namespace . . .}
Content:
annotation
?)

The

element information item identifies namespaces
used in external references, i.e. those whose
QName
identifies them as coming from a
different namespace (or none) than the enclosing schema document's
targetNamespace
4.2.6.1 Licensing References to Components Across Namespaces
At least two conditions must be satisfied for a
reference to be made to a foreign component: (1)
there must be a
means of addressing such foreign components,
and
(2) there must be a signal to
schema-aware processors that a schema document contains such
references. The namespace
mechanisms defined by
[XML Namespaces 1.1]
satisfy the first requirement by allowing foreign components
to be addressed.
(How those components are located is governed by the
processor's strategies for locating schema components
in a given namespace, in which the
schemaLocation
attribute
on the

element can play a role;
see also
Terminology of schema construction
(§C.2)
.)

The

element information item
serves
to satisfy the second requirement, by identifying
namespaces used in external component
references, i.e. those whose
QName
identifies them as coming
from a namespace different from that of the enclosing schema
document's
targetNamespace

By contrast, a namespace used for other purposes in a schema document
need not be imported.
Note:
There is
no need, for example, to import the
namespace of a vocabulary such as XHTML
for use in schema

elements, unless that same namespace is also
used as the target namespace for component references.
If the schema document does refer to components in the XHTML
namespace, then the schema document
must
include an element of the form

(with the possible addition of a
schemaLocation
attribute
and annotations). As just described, this explicit import
makes it legitimate to refer to components in the XHTML namespace,
as base type definitions, or from within content models.
No import is needed in order to use XHTML to mark up the text
appearing within

elements, since
that usage does not require the schema being constructed to
include components from the XHTML namespace. (As a
practical matter, this saves the processor the effort to
locate a schema for the XHTML namespace.) Importing or
not importing the XHTML namespace in a schema document
has no effect on the validity of XHTML within

elements: elements in the XHTML
namespace (or any other namespace) are allowed within

or

element in the schema document, because the schema for
schema documents in
Schema for Schema Documents (Structures) (normative) (§A)
declares the type of those elements with a lax wildcard.
Also, importing the namespace affects the schema being
constructed, not the schema used to validate schema
documents. The latter is specified in
Schema for Schema Documents (Structures) (normative) (§A)
Note:
Different designs for namespace import could of course be
imagined. In particular, declaring a prefix for a namespace could
automatically import that namespace.
If each use of a foreign namespace within a schema document
implicitly imported that namespace into the schema being
constructed, then using XHTML for documentation would automatically
result in the inclusion of XHTML components in the schema
described by the schema document. The same logic would also
apply to any vocabulary used for documentation. Such automatic import
would lead processors to expend unnecessary extra effort
to find components for the documentation namespace and would in many
cases result in a schema which is not the one intended or desired
by the schema author.
Additionally, the requirement that the

element be used explicitly provides a modest level of
redundancy that makes it easier to detect some kinds of errors
in the schema document.
The
actual value
of
the
namespace
[attribute]
indicates that the containing schema document
may
contain
qualified references to schema components in that namespace (via one or more
prefixes declared with namespace declarations in the normal way). If that
attribute is absent, then the import allows unqualified reference to components
with no target namespace.
It is a consequence of rules defined elsewhere
that if references to components in a given namespace
appear in a schema document
then
must
contain an

element
importing
Otherwise, the references will fail to resolve; see
clause
of
QName resolution (Schema Document) (§3.17.6.2)
References in a schema document to foreign namespaces not imported
by that schema document (or otherwise accounted for by
QName resolution (Schema Document) (§3.17.6.2)
) are
not
"forward references" in the sense of
The Mapping between XML Representations and
Components (§3.1.3)
and are
not
handled as if they referred to
"missing components" in the sense of
Missing Sub-components (§5.3)
Note that components to be imported need not be in the form of a
schema document
and
need not in particular be declared in the particular schema document identified
by a
schemaLocation
attribute; the processor
is free to access or construct components using means of its own
choosing, whether or not a
schemaLocation
hint is provided.
Example
The same namespace can be used both as the namespace
of elements and attributes appearing in the schema document,
and in the course of
defining schema components in terms of foreign
components.
The import in this example is necessary because there is a reference to the element
component
xhtml:p
if there were no component reference, then
the import would be unnecessary; no import is needed for use of a namespace
in a

or similar schema document element or attribute name.
xmlns:xhtml="http://www.w3.org/1999/xhtml"
targetNamespace="uri:mywork" xmlns:my="uri:mywork">

[Some documentation for my schema]

. . .

. . .

Since
component references are given as
QNames
and since the default namespace declaration can
only be used for one of the target namespace and the XSD namespace
(which typically differ, except
in the case of the schema for schema documents),
either
internal references to the names being defined in a schema document
or
the schema declaration and definition elements themselves
will normally be explicitly qualified.
This example takes the first option — most other
examples in this specification have taken the second.
4.2.6.2 Providing Hints for Imported Schema Document Locations
The
actual value
of the
schemaLocation
attribute, if present on
an

element, gives a hint as to where a
serialization of a
schema document
with declarations and definitions for the
imported namespace (or none) can
possibly be found. When no
schemaLocation
[attribute]
is present, the schema author is leaving the
identification of that schema to the instance, application or user,
via the mechanisms described below in
Layer 3: Schema Document Access and Web-interoperability (§4.3)
. When a
schemaLocation
attribute
is present, it
must
contain a single URI reference which
the schema author warrants will resolve to a
serialization of a
schema document
containing
definitions and declarations of

component(s) in the

ed namespace.
Conformance profiles may further
restrict the use of the
schemaLocation
attribute. For example,
one profile might mandate that the hint be

honored by the schema software, perhaps calling for a
processor-dependent error should the URI fail to resolve,
or mandating that the hint agree with some expected URI value;
another profile might mandate that the hint not
be honored,

etc.
Note:
Since both the
namespace
and
schemaLocation
[attribute]
are optional, a bare

information item
is allowed. This simply allows unqualified reference to foreign
components with no target namespace without giving any hints as to where to find them.
Schema Representation Constraint: Import Constraints and Semantics
In addition to the conditions imposed on

element
information items by the schema for schema documents
all
of the following also apply:
The appropriate
case
among the following
must
be true:
1.1
If
the
namespace
[attribute]
is present,
then
its
actual value
does not match the
actual value
of the
enclosing

's
targetNamespace
[attribute]
1.2
If
the
namespace
[attribute]
is not present,
then
the enclosing

has a
targetNamespace
[attribute]
If the application schema reference strategy succeeds using the
actual value
s of
the
schemaLocation
and
namespace
[attributes]
one
of the following
must
be true:
2.1
The result is (a fragment of) a resource which is an XML document
(see clause
1.1
of
Inclusion Constraints and Semantics (§4.2.3)
), which in turn corresponds to a

element information item in a well-formed information set, which in turn
corresponds to a conforming schema.
2.2
The result is a

element information item in a well-formed information set, which in turn
corresponds to a conforming schema.
In either case call the

item
D2
and the conforming schema
S2
If
D2
exists, that is, clause
2.1
or clause
2.2
above were satisfied, then the appropriate
case
among the following
must
be true:
3.1
If
there is a
namespace
[attribute]
then
its
actual value
is identical to the
actual value
of the
targetNamespace
[attribute]
of
D2
3.2
If
there is no
namespace
[attribute]
then
D2
has no
targetNamespace
[attribute]
It is
not
an error for the application schema component reference strategy to fail.
It
is
an error for it to succeed but
the rest of clause
above to
fail to be satisfied. Failure is likely to cause
less than complete
assessment
outcomes, of course.
The
schema components
(that is
{type definitions}
{attribute declarations}
{element declarations}
{attribute group definitions}
{model group definitions}
{notation declarations}
) of a schema
corresponding to a

element information item with one or more

element information items
must
include not
only definitions or declarations corresponding to the appropriate
members of its
[children]
, but also, for each of those

element information items for which clause
above is satisfied, a set of
schema
components
identical to all the
schema
components
of
S2
(with the possible
exception of the
Schema
component
of
S2
).
Note:
The above is carefully worded so that
multiple

ing of the same schema document will not constitute a
violation of
clause
of
Schema Properties Correct (§3.17.6.1)
, but
applications are allowed, indeed encouraged, to avoid

ing the
same schema document more than once to forestall the necessity of
establishing identity component by component. Given that the
schemaLocation
[attribute]
is only a hint, it is open
to applications to ignore all but the first

for
a given namespace, regardless of the
actual value
of
schemaLocation
, but such a strategy risks
missing useful information when new
schemaLocation
s are
offered.
4.3 Layer 3: Schema Document Access and Web-interoperability
4.3.1
Standards for representation of schemas and retrieval of schema documents on the Web
4.3.2
How schema definitions are located on the Web
Layers 1 and 2 provide a framework for
assessment
and XML definition of schemas in a
broad variety of environments. Over time, it is possible that a range of standards and
conventions will evolve to support
interoperability of XSD implementations on the World Wide Web.
Layer 3 defines the minimum level of function required of all
conformant processors operating on the Web: it is intended that, over
time, future standards (e.g. XML Packages) for interoperability on the
Web and in other environments can be introduced without the need to
republish this specification.
4.3.1 Standards for representation of schemas and retrieval of schema documents on the Web
For interoperability, serialized
schema documents
, like all other Web
resources,
should
be identified by URI and
retrieved using the standard mechanisms of the Web (e.g. http, https,
etc.) Such documents on the Web
must
be part of XML documents (see
clause
1.1
of
Inclusion Constraints and Semantics (§4.2.3)
), and are represented in the standard XML
schema definition form described by layer 2 (that is as

element information items).
Note:
there will often be times when a schema document will be a
complete XML document whose document element is

. There will be
other occasions in which

items will be contained in other
documents, perhaps referenced using fragment and/or
[XPointer]
notation.
Note:
The variations among server software and web site administration policies
make it difficult to recommend any particular approach to retrieval requests
intended to retrieve serialized
schema documents
. An
Accept
header of
application/xml,
text/xml; q=0.9, */*
is perhaps a reasonable starting point.
4.3.2 How schema definitions are located on the Web
As described in
Layer 1: Summary of the Schema-validity Assessment Core (§4.1)
, processors are responsible for providing the
schema components (definitions and declarations) needed for
assessment
. This
section introduces a set of conventions to facilitate interoperability
for instance and schema documents retrieved and processed from the Web.
Note:
As discussed above in
Layer 2: Schema Documents, Namespaces and Composition (§4.2)
, other non-Web
mechanisms for delivering schemas for
assessment
exist, but are outside the scope of this
specification.
Processors on the Web are free to undertake
assessment
against arbitrary
schemas in any of the ways set out in
Assessing Schema-Validity (§5.2)
. However, it
is useful to have a common convention for determining the schema to use. Accordingly, general-purpose schema-aware processors (i.e. those not
specialized to one or a fixed set of pre-determined schemas)
undertaking
assessment
of an instance document on the web
must
behave as follows:
unless directed otherwise by the user,
assessment
is undertaken on the document
element information item of the
instance document;
unless directed otherwise by the user, the
processor is required to construct a schema corresponding to a schema document
whose
targetNamespace
is
identical to the
namespace name, if any, of the element information item on which
assessment
is undertaken.
The composition of the complete
schema for use in
assessment
is discussed in
Layer 2: Schema Documents, Namespaces and Composition (§4.2)
above.
The means used to locate appropriate schema document(s) are processor and
application dependent, subject to the following requirements:
Schemas are represented on the Web in the form specified above in
Standards for representation of schemas and retrieval of schema documents on the Web (§4.3.1)
The author of a document uses namespace declarations to
indicate the intended interpretation of names appearing therein;
it is possible but not guaranteed that
a schema is retrievable via
the namespace name. Accordingly whether a processor's default
behavior is or is not to attempt such dereferencing, it
must
always
provide for user-directed overriding of that default.
Note:
Experience suggests that it is not in all cases safe or desirable from
a performance point of view to dereference namespace names as a matter of course. User community and/or
consumer/provider agreements may
establish circumstances in which such dereference is a sensible
default strategy: this specification allows but does not require particular communities to
establish and implement such conventions. Users are always free to supply namespace names as schema location information when dereferencing
is
desired: see below.
On the other hand, in case a document author (human or not) created a
document with a particular schema in view, and warrants that some or
all of the document conforms to that schema, the
xsi:schemaLocation
and
xsi:noNamespaceSchemaLocation
[attributes]
are provided. The first records
the author's warrant with pairs of URI references (one for the namespace name, and
one for a hint as to the location of a schema document defining names for that
namespace name). The second similarly provides a URI reference as a hint as to
the location of a schema document with no
targetNamespace
[attribute]
Processors
may
attempt to dereference each schema document location URI in the
actual value
of such
xsi:schemaLocation
and
xsi:noNamespaceSchemaLocation
[attributes]
Schema processors
should
provide an option to
control whether they do so.
It is
not
an error for such
an attempt to fail, but failure may cause less than complete
assessment
outcomes.
Note:
Whether schema location information in the document
instance should or should not be dereferenced may vary with
the purpose in view.
When systems rely on an input document being schema-valid
with respect to a particular agreed-upon schema, it is
important that they be able to have complete control over the
choice of schema used in assessment and in particular that
they be able to instruct the processor
not
to
follow any
schemaLocation
hints in the input.
Otherwise, the input document could circumvent the agreement
and the consumer's validation of the input, by referring to
an alternative schema for the same namespaces, which declares
the input document schema-valid but which does not adhere to
the prior agreement between the data source and the data
consumer.
In other cases the purpose of assessment may be not to
enforce a prior agreement between data source and consumer,
but to annotate the input with type definitions and other
useful information from the
post-schema-validation infoset
. In such cases it will
often be better to follow the
schemaLocation
hints.
Users who need to exert control over the choice of schema can
normally be expected to be aware of the requirement;
conversely, users unaware of the issue will typically be
those who are not relying on the use of a particular schema
to enforce a specific agreement with the data source. Casual
users will often benefit from a default behavior of following
schemaLocation
hints.
Useful guidance on how to present this and other questions to
end users may be found in the W3C's User Agent Accessibility
Guidelines
[UAAG 1.0]
[UAAG 2.0]
When schema location values (i.e.
schemaLocation
attributes on



and

in schema documents, or
xsi:schemaLocation
and
xsi:noNamespaceSchemaLocation
attributes in instance documents) are dereferenced and the values are relative
references, then the
[base URI]
of the
[owner element]
must
be used to resolve the relative references.
According to the rules of
Layer 1: Summary of the Schema-validity Assessment Core (§4.1)
, the corresponding schema
may
be lazily assembled, but is otherwise
stable throughout
assessment
. Although schema location attributes can occur
on any element, and can be processed incrementally as discovered, their effect
is essentially global to the
assessment
. Definitions and declarations remain
in effect beyond the scope of the element on which the binding is declared.
Example
Multiple schema bindings can be declared using a single
attribute. For example consider a stylesheet:
xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/1999/XSL/Transform
The namespace names used in
schemaLocation
can, but need not
be identical to those actually qualifying the element within whose start tag
it is found or its other attributes. For example, as above, all
schema location information can be declared on the document element
of a document, if desired,
regardless of where the namespaces are actually used.
Improved or alternative conventions for Web interoperability can
be standardized in the future without reopening this specification. For
example, the W3C is currently considering initiatives to standardize the
packaging of resources relating to particular documents and/or namespaces: this
would be an addition to the mechanisms described here for layer 3. This
architecture also facilitates innovation at layer 2: for example, it would be
possible in the future to define an additional standard for the representation of
schema components which allowed e.g. type definitions to be specified piece by
piece, rather than all at once.
5 Schemas and Schema-validity Assessment
The architecture of schema-aware processing allows for a rich
characterization of XML documents: schema validity is not a binary
predicate.
This specification distinguishes between errors in schema
construction and structure, on the one hand, and schema validation
outcomes, on the other.
5.1 Errors in Schema Construction and Structure
Before
assessment
can be
attempted, a schema is required. Special-purpose applications are
free to determine a schema for use in
assessment
by whatever means are
appropriate, but general purpose processors
should
implement
and document a strategy for assembling a schema,
exploiting at least some if not all of the non-hard-coded
methods outlined in
Terminology of schema construction
(§C.2)
starting with the namespaces declared in the document whose
assessment
is being undertaken,
and the
actual value
s of the
xsi:schemaLocation
and
xsi:noNamespaceSchemaLocation
[attributes]
thereof, if any, along with any other information about schema
identity or schema document location provided by users in
application-specific ways, if any.
It is an error if a schema and all the components which are the
value of any of its properties, recursively, fail to satisfy all
the relevant Constraints on Schemas set out in
the subsections of
Schema Component Details (§3)
If a schema is derived from one or more schema documents (that
is, one or more

element information items)
based on the
correspondence rules set out in
Schema Component Details (§3)
and
Schemas and Namespaces: Access and Composition (§4)
, two additional conditions
hold; both apply to the
schema document after the conditional-inclusion
pre-processing described in
Conditional inclusion (§4.2.2)
is performed:
It is an error if any such schema document would not be
fully valid with respect to a schema corresponding to the
Schema for Schema Documents (Structures) (normative) (§A)
, that is, following
schema-validation with such a schema, the

element information items would have a
[validation attempted]
property with value
full
or
partial
and a
[validity]
property with value
valid
It is an error if any such schema document is or contains
any element information items which violate any of the
relevant Schema Representation Constraints set out in
Schema Representation Constraints (§B.3)
The cases described above are the only types of error
which this specification defines. With respect to the processes
of the checking of schema structure and the construction of
schemas corresponding to schema documents, this specification
imposes no restrictions on processors in the
presence of errors, beyond the
requirement that if there are errors in a schema, or in one
or more
schema documents used in constructing a schema, then a
conforming processor
must
report
the fact.
However, any further
operations performed in the
presence of errors are outside the scope of this specification
and are not
schema-validity
assessment
as that term is defined here.
5.2 Assessing Schema-Validity
With a schema which satisfies the conditions expressed in
Errors in Schema Construction and Structure (§5.1)
above, the schema-validity of an
element or attribute
information item (the
validation root
) can be assessed. Five
primary approaches to this are described
and given names here; conforming processors
may
but are not required
to provide interfaces so that they can be invoked in ways consistent
with any or all of these approaches.
type-driven validation
The user or application identifies a type definition from among the type
definitions of the schema. If the
validation root
is an element, then it is validated as described
in
Schema-Validity Assessment (Element) (§3.3.4.6)
(with the stipulated type definition
as the
governing type definition
); if it is an
attribute, then it is validated with respect to that type definition
as described in
String Valid (§3.16.4)
Note:
Top-level (named) types
should
be supported;
support for local types is optional.
element-driven validation
The user or application identifies an element declaration from among the element
declarations of the schema and the
item is validated as described in
Schema-Validity Assessment (Element) (§3.3.4.6)
(with
the stipulated element declaration as the
governing
declaration);
Note:
Top-level elements
should
be supported; support for local elements is optional.
attribute-driven validation
The user or application identifies an attribute declaration from
among the attribute declarations of the schema and the item is validated as described in
Schema-Validity Assessment (Attribute) (§3.2.4.3)
(with
the stipulated attribute declaration as its
governing
declaration);
lax wildcard validation
The processor starts from
Schema-Validity Assessment (Element) (§3.3.4.6)
with
no stipulated declaration or definition. If the
validation root
and the schema determine an
element declaration (by the name of the element), an attribute
declaration (by the name of the attribute), or a type definition (by
xsi:type
), then
strict
validation
is performed. If they do
not identify any declaration or definition, then
lax assessment
is
performed.
Note:
The name for this method of
invocation reflects the fact that it is analogous to the validation of
an element information item which matches a
lax
wildcard.
strict wildcard validation
The processor starts from
Schema-Validity Assessment (Element) (§3.3.4.6)
with no
stipulated declaration or definition. If the
validation root
and the schema determine an element declaration (by the name of the element),
an attribute declaration (by the name of the attribute), or a
type definition (via
xsi:type
), then
strict
validation is
performed; if they do not identify any declaration or
definition, then
lax assessment
is performed.
Note:
From the point of view of schema-validity assessment and the
resulting
post-schema-validation infoset
, lax and strict wildcard validation
produce
the same result.
The distinction is provided in order to provide two different terms
to express the different expectations of the invoking process.
In typical cases strict wildcard validation will be
performed when the invoking process expects the
validation root
to be declared and valid and will otherwise
report an error to its environment. If the absence of
a declaration for the
validation root
counts as a successful
outcome of validation, then it is preferable to use
lax wildcard
validation instead.
The name for this method of invocation
reflects the fact that it is analogous to the
validation of an element information item which matches a
strict
wildcard.
Note:
For type-, element-, and attribute-driven validation,
there is no requirement that the declaration or definition
identified by the user or application be a top-level
component of the schema. Mechanisms for referring to
other components are out of scope for this specification,
but see
[XML Schema: Component Designators]
[Definition:]
The element or attribute information item at which
assessment
begins is called the
validation root
The outcome of schema-validity
assessment will be manifest in the
[validation attempted]
and
[validity]
properties on the
validation root
, and if the
validation root
is an element information item then also
on its
[attributes]
and
[children]
, recursively, as
defined by
Assessment Outcome (Element) (§3.3.5.1)
and
Assessment Outcome (Attribute) (§3.2.5.1)
. There is no
requirement that input which is not schema-valid be rejected by an
application. It is up to applications to decide what
constitutes a successful outcome of
validation.
Note that every element and attribute information item
participating in the
assessment
will
also have a
[validation context]
property which refers back to the
validation root
Note:
This specification does not reconstruct the XML notion of
root
in either schemas or instances. Equivalent
functionality is provided for at
assessment
invocation, via
element-driven validation
above.
Note:
This specification has nothing normative to say about multiple
assessment
episodes. It should
however be clear from the above that if a processor restarts
assessment
with respect to a
post-schema-validation infoset
some
post-schema-validation infoset
contributions from the previous
assessment
are likely
to be overwritten. Restarting can
nonetheless be useful, particularly at a node whose
[validation attempted]
property is
none
, in which case there are three obvious cases in which
additional useful information could
result:
assessment
was not attempted
because of a
validation
failure, but
declarations and/or definitions are available for at least some of the
[children]
or
[attributes]
assessment
was not attempted
because a named definition or declaration was missing, but after
further effort the processor has retrieved it.
assessment
was not attempted
because it was
skipped
but the processor has at least some
declarations and/or definitions available for at least some of the
[children]
or
[attributes]
5.3 Missing Sub-components
At the beginning of
Schema Component Details (§3)
, attention is drawn to the
fact that most kinds of schema components have properties which are described therein
as having other components, or sets of other components, as values, but that
when components are constructed on the basis of their correspondence with
element information items in schema documents, such properties usually
correspond to
QNames
, and the
resolution
of such
QNames
can fail, resulting in one or more values of or containing
absent
where a component is mandated.
If at any time during
assessment
, an element or attribute
information item is being
validated
with respect to a component of
any kind any of whose properties has or contains such an
absent
value,
the
validation
is modified,
as following:
In the case of
attribute information items, the effect is as if
clause
of
Attribute Locally Valid (§3.2.4.1)
had
failed;
In the case of
element information items, the effect is as if
clause
of
Element Locally Valid (Element) (§3.3.4.3)
had
failed;
In the case of element information items, processors
must
fall back to
lax assessment
Because of the value specification for
[validation attempted]
in
Assessment Outcome (Element) (§3.3.5.1)
, if this situation ever arises, the
document as a whole cannot show a
[validation attempted]
of
full
References in a
Simple Type Definition
to
unknown
datatypes, or to
unknown
constraining facets, make the
simple type definition unusable in ways similar to
having
absent
property values. Often, such references will
result in component properties with
absent
values, but
not necessarily. In either case they,
and likewise any types derived or constructed from them,
are handled in the same way as described above for components
with
absent
property values.
5.4 Responsibilities of Schema-aware Processors
Schema-aware processors are responsible for processing XML documents,
schemas and schema documents, as appropriate given the level of conformance
(as defined in
Conformance (§2.4)
) they support,
consistently with the conditions set out above.
A Schema for Schema Documents (Structures) (normative)
The XML representation of the schema for schema documents is
presented here as a normative part of the specification, and as an
illustrative example of how the XML Schema Definition Language can define itself
using its own constructs. The names of XSD types,
elements, attributes and groups defined here are evocative of their
purpose, but are occasionally verbose.
There is some annotation in comments, but a fuller annotation will
require the use of embedded documentation facilities or a hyperlinked
external annotation for which tools are not yet readily available.
Like any other XML document, schema
documents may carry XML and document type declarations. An XML
declaration and a document type declaration are provided here for
convenience. Since this schema document describes the XSD
language, the
targetNamespace
attribute on the
schema
element refers to the XSD namespace
itself.
Schema documents conforming to this specification may be in XML
1.0 or XML 1.1. Conforming implementations may accept input in
XML 1.0 or XML 1.1 or both. See
Dependencies on Other Specifications (§1.4)
Independent copies of this material are
available in an undated (mutable) version at
and in a dated (immutable) version at
— the mutable version will be updated with future revisions of
this specification, and the immutable one will not.
Schema for schema documents

]>

elementFormDefault="qualified" xml:lang="EN"
targetNamespace="http://www.w3.org/2001/XMLSchema"
version="structures.xsd (rec-20120405)">


The schema corresponding to this document is normative,
with respect to the syntactic constraints it expresses in the
XML Schema Definition Language. The documentation (within 'documentation' elements)
below, is not normative, but rather highlights important aspects of
the W3C Recommendation of which this is a part.

See below (at the bottom of this document) for information about
the revision and namespace-versioning policy governing this
schema document.

The simpleType element and all of its members are defined
in datatypes.xsd


schemaLocation="http://www.w3.org/2001/xml.xsd">


Get access to the xml: attribute groups for xml:lang
as declared on 'schema' and 'documentation' below






This type is extended by almost all schema types
to allow attributes from other namespaces to be
added to user schemas.











This type is extended by all types which allow annotation
other than <schema> itself























This group is for the
elements which occur freely at the top level of schemas.
All of their types are based on the "annotated" type by extension.











This group is for the
elements which can self-redefine (see <redefine> below).











A utility type, not for public use









A utility type, not for public use









A utility type, not for public use

#all or (possibly empty) subset of {extension, restriction}















A utility type, not for public use











A utility type, not for public use

#all or (possibly empty) subset of {extension, restriction, list, union}














source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-schema"/>








maxOccurs="unbounded"/>



maxOccurs="unbounded"/>




default="" use="optional"/>
use="optional"/>
default="unqualified" use="optional"/>
default="unqualified" use="optional"/>

default="##local" use="optional"/>





































for maxOccurs












for all particles

use="optional"/>





for element, group and attributeGroup,
which both define and reference







'complexType' uses this

source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-anyAttribute"/>




use="optional"/>






minOccurs="0" maxOccurs="unbounded"/>

















This branch is short for
<complexContent>
<restriction base="xs:anyType">
...
</restriction>
</complexContent>















Will be restricted to required or prohibited





Not allowed if simpleContent child is chosen.
May be overridden by setting on complexContent child.


use="optional"/>


default="true" use="optional"/>

This choice is added simply to
make this a valid restriction per the REC

source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-complexContent"/>











Overrides any setting on complexType parent.








source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-openContent"/>

source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-defaultOpenContent"/>







default="false" use="optional"/>

This choice is added simply to
make this a valid restriction per the REC
















No typeDefParticle group reference











source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-simpleContent"/>














source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-complexType"/>





A utility type, not for public use

#all or (possibly empty) subset of {substitution, extension,
restriction}























The element element can be used either
at the top level to define an element-type binding globally,
or within a content model to either reference a globally-defined
element or type or declare an element-type binding locally.
The ref form is not allowed at the top level.








minOccurs="0" maxOccurs="unbounded"/>
maxOccurs="unbounded"/>

use="optional"/>
















minOccurs="0" maxOccurs="unbounded"/>
maxOccurs="unbounded"/>




















minOccurs="0" maxOccurs="unbounded"/>
maxOccurs="unbounded"/>










source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-element"/>





This type is used for 'alternative' elements.

















group type for explicit groups, named top-level groups and
group references

group type for the three kinds of group































This choice with min/max is here to
avoid a pblm with the Elt:All/Choice/Seq
Particle derivation constraint






















Only elements allowed inside































source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-choice"/>




source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-sequence"/>








use="optional"/>

use="optional"/>







simple type for the value of the 'namespace' attr of
'any' and 'anyAttribute'



Value is
##any - - any non-conflicting WFXML/attribute at all

##other - - any non-conflicting WFXML/attribute from
namespace other than targetNS

##local - - any unqualified non-conflicting WFXML/attribute

one or - - any non-conflicting WFXML/attribute from
more URI the listed namespaces
references
(space separated)

##targetNamespace or ##local may appear in the above list, to
refer to the targetNamespace of the enclosing
schema or an absent targetNamespace respectively




A utility type, not for public use

A utility type, not for public use

















A utility type, not for public use









A utility type, not for public use


















A utility type, not for public use



























source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-attribute"/>

id="attributeGroup">

source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-attributeGroup"/>




source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-include"/>











source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-redefine"/>

source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-override"/>
















source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-import"/>












source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-selector"/>







A subset of XPath expressions for use
in selectors
A utility type, not for public
use

A subset of XPath expressions for use
in fields
A utility type, not for public
use

The three kinds of identity constraints, all with
type of or derived from 'keybase'.










source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-unique"/>









source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-keyref"/>











source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-notation"/>














A utility type, not for public use

A public identifier, per ISO 8879





source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-appinfo"/>











source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-documentation"/>












source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-annotation"/>















notations for use within schema documents

system="http://www.w3.org/2000/08/XMLSchema.xsd"/>
system="http://www.w3.org/TR/1998/REC-xml-19980210"/>



Not the real urType, but as close an approximation as we can
get in the XML representation

In keeping with the XML Schema WG's standard versioning policy,
the material in this schema document will persist at the URI

At the date of issue it can also be found at the URI

The schema document at that URI may however change in the future,
in order to remain compatible with the latest version of XSD
and its namespace. In other words, if XSD or the XML Schema
namespace change, the version of this document at
the version at http://www.w3.org/2012/04/XMLSchema.xsd will not change.

Previous dated (and unchanging) versions of this schema document
include:

(XSD 1.1 Proposed Recommendation)

(XSD 1.1 Candidate Recommendation)

(XSD 1.1 Candidate Recommendation)

(XSD 1.0 Recommendation, Second Edition)

(XSD 1.0 Recommendation, First Edition)

B Outcome Tabulations (normative)
To facilitate consistent reporting of schema errors and
validation
failures, this section tabulates and provides unique names for all the
constraints listed in this document. Wherever such constraints have numbered
parts, reports
should
use the name given below plus the part number, separated
by a period ('.'). Thus for example
cos-ct-extends.1.2
should
be
used to report a violation of the clause
1.2
of
Derivation Valid (Extension) (§3.4.6.2)
B.1 Validation Rules
cvc-accept
Element Sequence Accepted (Particle)
cvc-assertion
Assertion Satisfied
cvc-assertions-valid
Assertions Valid
cvc-assess-attr
Schema-Validity Assessment (Attribute)
cvc-assess-elt
Schema-Validity Assessment (Element)
cvc-attribute
Attribute Locally Valid
cvc-au
Attribute Locally Valid (Use)
cvc-complex-content
Element Sequence Locally Valid (Complex Content)
cvc-complex-type
Element Locally Valid (Complex Type)
cvc-datatype-valid
Datatype Valid
cvc-elt
Element Locally Valid (Element)
cvc-enumeration-valid
enumeration valid
cvc-explicitTimezone-valid
explicitOffset Valid
cvc-facet-valid
Facet Valid
cvc-fractionDigits-valid
fractionDigits Valid
cvc-id
Validation Root Valid (ID/IDREF)
cvc-identity-constraint
Identity-constraint Satisfied
cvc-length-valid
Length Valid
cvc-maxExclusive-valid
maxExclusive Valid
cvc-maxInclusive-valid
maxInclusive Valid
cvc-maxLength-valid
maxLength Valid
cvc-minExclusive-valid
minExclusive Valid
cvc-minInclusive-valid
minInclusive Valid
cvc-minLength-valid
minLength Valid
cvc-model-group
Element Sequence Valid
cvc-particle
Element Sequence Locally Valid (Particle)
cvc-pattern-valid
pattern valid
cvc-resolve-instance
QName resolution (Instance)
cvc-simple-type
String Valid
cvc-totalDigits-valid
totalDigits Valid
cvc-type
Element Locally Valid (Type)
cvc-wildcard
Item Valid (Wildcard)
cvc-wildcard-name
Wildcard allows Expanded Name
cvc-wildcard-namespace
Wildcard allows Namespace Name
cvc-xpath
XPath Evaluation
B.2 Contributions to the post-schema-validation infoset
ID/IDREF binding information item properties
[binding]
ID/IDREF Table
[id]
ID/IDREF Table
Identity-constraint Binding information item properties
[definition]
Identity-constraint Table
[node table]
Identity-constraint Table
attribute information item properties
[attribute attribution]
Match Information
[attribute declaration]
Attribute Declaration
[match information]
Match Information
[member type definition]
Attribute Validated by Type
[member type definition anonymous]
Attribute Validated by Type
[member type definition name]
Attribute Validated by Type
[member type definition namespace]
Attribute Validated by Type
[member type definitions]
Attribute Validated by Type
[schema actual value]
Attribute Validated by Type
[schema default]
Attribute Declaration
[schema error code]
Validation Failure (Attribute)
[schema normalized value]
Attribute Validated by Type
[schema specified]
Assessment Outcome (Attribute)
[type definition]
Attribute Validated by Type
[type definition anonymous]
Attribute Validated by Type
[type definition name]
Attribute Validated by Type
[type definition namespace]
Attribute Validated by Type
[type definition type]
Attribute Validated by Type
[validation attempted]
Assessment Outcome (Attribute)
[validation context]
Assessment Outcome (Attribute)
[validity]
Assessment Outcome (Attribute)
element information item properties
[ID/IDREF table]
ID/IDREF Table
[declared type]
Element Declaration
[descendant validity]
Element Validated by Type
[element attribution]
Match Information
[element declaration]
Element Declaration
[expected element declaration]
Element Declaration
[failed assertions]
Validation Failure (Element)
[failed identity constraints]
Validation Failure (Element)
[identity-constraint table]
Identity-constraint Table
[inherited attributes]
Inherited Attributes
[local element validity]
Element Declaration
[local type validity]
Element Validated by Type
[match information]
Match Information
[member type definition]
Element Validated by Type
[member type definition anonymous]
Element Validated by Type
[member type definition name]
Element Validated by Type
[member type definition namespace]
Element Validated by Type
[member type definitions]
Element Validated by Type
[nil]
Element Declaration
[notation]
Validated with Notation
[notation public]
Validated with Notation
[notation system]
Validated with Notation
[schema actual value]
Element Validated by Type
[schema default]
Element Validated by Type
[schema error code]
Validation Failure (Element)
[schema normalized value]
Element Validated by Type
[schema specified]
Element Default Value
[subsequence-valid]
Validation Failure (Element)
[type alternative]
Element Validated by Type
[type definition]
Element Validated by Type
[type definition type]
Element Validated by Type
[type definition anonymous]
Element Validated by Type
[type definition name]
Element Validated by Type
[type definition namespace]
Element Validated by Type
[type fallback]
Element Validated by Type
[validation attempted]
Assessment Outcome (Element)
[validation context]
Assessment Outcome (Element)
[validity]
Assessment Outcome (Element)
element or attribute information item properties
[schema information]
Schema Information
namespace schema information information item properties
[schema components]
Schema Information
[schema documents]
Schema Information
[schema namespace]
Schema Information
schema document information item properties
[document]
Schema Information
[document location]
Schema Information
B.3 Schema Representation Constraints
src-attribute
Attribute Declaration Representation OK
src-attribute_group
Attribute Group Definition Representation OK
src-cip
Conditional Inclusion Constraints
src-ct
Complex Type Definition Representation OK
src-element
Element Declaration Representation OK
src-enumeration-value
Enumeration value
src-expredef
Individual Component Redefinition
src-identity-constraint
Identity-constraint Definition Representation OK
src-import
Import Constraints and Semantics
src-include
Inclusion Constraints and Semantics
src-list-itemType-or-simpleType
itemType attribute or simpleType child
src-override
Override Constraints and Semantics
src-pattern-value
Pattern value
src-redefine
Redefinition Constraints and Semantics
src-resolve
QName resolution (Schema Document)
src-restriction-base-or-simpleType
base attribute or simpleType child
src-simple-type
Simple Type Definition Representation OK
src-ta
Type
Alternative Representation OK
src-union-memberTypes-or-simpleTypes
memberTypes attribute or simpleType children
src-wildcard
Wildcard Representation OK
B.4 Schema Component Constraints
a-props-correct
Attribute Declaration Properties Correct
ag-props-correct
Attribute Group Definition Properties Correct
an-props-correct
Annotation Correct
as-props-correct
Assertion Properties Correct
au-props-correct
Attribute Use Correct
c-fields-xpaths
Fields Value OK
c-props-correct
Identity-constraint Definition Properties Correct
c-selector-xpath
Selector Value OK
cos-all-limited
All Group Limited
cos-applicable-facets
Applicable Facets
cos-assertions-restriction
Valid restriction of assertions
cos-aw-intersect
Attribute Wildcard Intersection
cos-aw-union
Attribute Wildcard Union
cos-choice-range
Effective Total Range (choice)
cos-content-act-restrict
Content type restricts (Complex Content)
cos-ct-derived-ok
Type Derivation OK (Complex)
cos-ct-extends
Derivation Valid (Extension)
cos-element-consistent
Element Declarations Consistent
cos-equiv-derived-ok-rec
Substitution Group OK (Transitive)
cos-group-emptiable
Particle Emptiable
cos-nonambig
Unique Particle Attribution
cos-ns-subset
Wildcard Subset
cos-particle-extend
Particle Valid (Extension)
cos-pattern-restriction
Valid restriction of pattern
cos-seq-range
Effective Total Range (all and sequence)
cos-st-derived-ok
Type Derivation OK (Simple)
cos-st-restricts
Derivation Valid (Restriction, Simple)
cos-valid-default
Element Default Valid (Immediate)
cos-valid-simple-default
Simple Default Valid
ct-props-correct
Complex Type Definition Properties Correct
derivation-ok-restriction
Derivation Valid (Restriction, Complex)
e-props-correct
Element Declaration Properties Correct
enumeration-required-notation
enumeration facet value required for NOTATION
enumeration-valid-restriction
enumeration valid restriction
fractionDigits-totalDigits
fractionDigits less than or equal to totalDigits
fractionDigits-valid-restriction
fractionDigits valid restriction
length-minLength-maxLength
length and minLength or maxLength
length-valid-restriction
length valid restriction
maxExclusive-valid-restriction
maxExclusive valid restriction
maxInclusive-maxExclusive
maxInclusive and maxExclusive
maxInclusive-valid-restriction
maxInclusive valid restriction
maxLength-valid-restriction
maxLength valid restriction
mg-props-correct
Model Group Correct
mgd-props-correct
Model Group Definition Properties Correct
minExclusive-less-than-equal-to-maxExclusive
minExclusive <= maxExclusive
minExclusive-less-than-maxInclusive
minExclusive < maxInclusive
minExclusive-valid-restriction
minExclusive valid restriction
minInclusive-less-than-equal-to-maxInclusive
minInclusive <= maxInclusive
minInclusive-less-than-maxExclusive
minInclusive < maxExclusive
minInclusive-minExclusive
minInclusive and minExclusive
minInclusive-valid-restriction
minInclusive valid restriction
minLength-less-than-equal-to-maxLength
minLength <= maxLength
minLength-valid-restriction
minLength valid restriction
n-props-correct
Notation Declaration Correct
no-xmlns
xmlns Not Allowed
no-xsi
xsi: Not Allowed
p-props-correct
Particle Correct
sch-props-correct
Schema Properties Correct
st-props-correct
Simple Type Definition Properties Correct
st-restrict-facets
Simple Type Restriction (Facets)
ta-props-correct
Type Alternative Properties Correct
timezone-valid-restriction
timezone valid restriction
totalDigits-valid-restriction
totalDigits valid restriction
w-props-correct
Wildcard Properties Correct
whiteSpace-valid-restriction
whiteSpace valid restriction
xpath-valid
XPath Valid
C Terminology for implementation-defined features (normative)
This section defines some terms for use in describing
choices made by implementations in areas where the
effect of XSD
features is explicitly
implementation-defined
Future versions of this specification are expected to use
the terminology defined here to specify conformance profiles.
Conformance profiles may also be defined by other specifications
without requiring any revision to this specification.
C.1 Subset of the Post-schema-validation Infoset
This specification defines a number of ways in which the
information set taken as input is augmented in the course
of schema-validity assessment. Conforming processors
may
provide access to some or all of this information; in the
interests of simplifying discussion and documentation, this
section defines names for several subsets of the PSVI, with
the intention of simplifying short-hand descriptions of
processors. These terms
may
be used to describe what parts of
the PSVI a particular schema processor provides access to, or
to specify requirements for processors, or for other purposes.
A processor provides access to a particular subset
of the PSVI if and only if it makes accessible some representation
of the information in question, for information items to which
it is applicable. (The properties labeled "if applicable"
or "where applicable" below are simply the most obvious
cases of properties which do not apply to every information item;
the same qualification implicitly applies to all properties listed
below.)
If other subsets of the PSVI prove important in practice it is
expected that definitions of those subsets
may
be provided by
other specifications or in later revisions of this one.
The definition in this section of a term denoting a particular
subset of the PSVI does not constitute a requirement that
conforming processors provide access to that subset.
root-validity subset
[Definition:]
The
root-validity subset
of the PSVI consists of the
following properties of the
validation root
[validity]
[validation attempted]
[schema error code]
, if applicable
instance-validity subset
[Definition:]
The
instance-validity subset
of the PSVI consists of
the
root-validity subset
, plus the following properties on elements,
wherever applicable:
[validity]
[validation attempted]
[notation system]
[notation public]
[schema error code]
and the following properties on attributes, wherever applicable:
[validity]
[validation attempted]
[schema error code]
type-aware subset
[Definition:]
The
type-aware subset
of the PSVI consists of the
instance-validity subset
, plus the following
items and properties.
It is intended that the type-aware subset of the PSVI include
all the information needed by schema-aware XQuery 1.0 or
XSLT 2.0 processors.
In each case, the information is to be provided in some
implementation-defined
representation. For elements:
[element attribution]
[element declaration]
[nil]
[type definition]
[member type definition]
(where applicable)
[schema normalized value]
(where applicable)
[schema actual value]
(where applicable)
and for attributes:
[attribute attribution]
[attribute declaration]
[type definition]
[member type definition]
(where applicable)
[schema normalized value]
(where applicable)
[schema actual value]
(where applicable)
Note:
In a future draft of this specification, it is expected that
a list of specific component properties to which access
should
or
must
be provided will be included. No such
list is present in the current draft; input from readers,
users, schema authors, and implementors as to what properties
are most usefully exposed in this subset would be very welcome.
lightweight type-aware subset
[Definition:]
The
lightweight type-aware subset
of the PSVI provides
the same information as the
type-aware subset
, except that instead of providing
direct access to schema components, it provides only their names and
related information.
For elements:
[match information]
[type definition name]
[type definition namespace]
[type definition type]
[type definition anonymous]
[member type definition name]
(where applicable)
[member type definition namespace]
(where applicable)
[member type definition anonymous]
(where applicable)
and for attributes:
[match information]
[type definition name]
[type definition namespace]
[type definition type]
[type definition anonymous]
[member type definition name]
(where applicable)
[member type definition namespace]
(where applicable)
[member type definition anonymous]
(where applicable)
full instance subset
[Definition:]
The
full instance subset
of the PSVI includes almost all
properties defined by this specification as applying to
element and attribute information items, but excludes
schema components. It
consists of
the
instance-validity subset
plus the following properties for elements:
[descendant validity]
[local element validity]
[local type validity]
[subsequence-valid]
[match information]
[type definition name]
[type definition namespace]
[type definition type]
[type definition anonymous]
[type fallback]
[type alternative]
[member type definition name]
(where applicable)
[member type definition namespace]
(where applicable)
[member type definition anonymous]
(where applicable)
[schema normalized value]
(where applicable)
[schema actual value]
(where applicable)
[schema default]
(where applicable)
[schema information]
some
implementation-defined
representation (including at least the
names of resources from which components were drawn)
and the following for attributes:
[match information]
[type definition name]
[type definition namespace]
[type definition type]
[type definition anonymous]
[member type definition name]
(where applicable)
[member type definition namespace]
(where applicable)
[member type definition anonymous]
(where applicable)
[schema normalized value]
[schema actual value]
(where applicable)
[schema default]
(where applicable)
[schema specified]
(where applicable)
full PSVI with components
The
full PSVI with components
consists of
every property and information item defined in this
specification.
In exposing element declarations, attribute declarations,
type definitions, and other components, processors
providing access to the full subset must provide some
representation for all of the defined properties of the
components. Note that although the properties are often
redundant with other information, it is not required that
the full subset include more than one representation of
redundant information.
Note:
The PSVI is a description of an information set,
not a specification of a data structure or an application-programming
interface. For convenience, this specification defines
in some cases more than one term for denoting a particular
piece of information: for example,
the
[type definition name]
property of an element and the
[name]
property of the
[type definition]
property of that element are the same piece of information.
If the
[type definition]
is
supplied, then the
[type
definition name]
is necessarily also available.
Similar observations can be made for other properties present in
the full-instance subset but not mentioned here. Processors
should
allow access to the information without requiring
users or applications to distinguish between the different
names or access paths under which it might be described in this
specification.
C.2
Terminology of schema construction
C.2.1
Identifying locations where components are sought
C.2.2
Identifying methods of indirection
C.2.3
Identifying the key for use in indirection
C.2.4
Identifying when to stop searching
C.2.5
Identifying how to react to failure
Conforming processors
may
implement any combination of the
following strategies for locating schema components, in any
order. They
may
also implement other strategies.
The terminology offered here is intended to be useful in
discussions of processor behavior, whether documenting
existing behavior or describing required behavior.
General-purpose processors
should
support multiple
methods for locating schema documents,
and
provide user
control over which methods are used and how to fall back in
case of failure.
C.2.1 Identifying locations where components are sought
Some terms describe how a processor identifies locations from
which schema components can be sought:
hard-coded schemas
Full knowledge of one or more schemas is built into the
processor. (Note: all processors are required to have some
built-in knowledge of of the built-in components.
General-purpose
processors
are additionally required to
be able to
validate
documents against the
XSD schema for schema documents.)
automatically known
components
Full knowledge of one or more components is
built into the processor; these components
may
be made available automatically by being included
by that processor in every schema it constructs,
or they
may
be included only under certain
implementation-defined
conditions (e.g. an explicit
import of the relevant namespace, or choice of
a specified invocation option).
Note:
All processors are
required to have some built-in knowledge of
of the built-in components.
hard-coded schema locations
A list of locations at which
schema documents will be sought is built into the processor.
Particular locations can be associated with specific
namespaces or can be used to seek any schema document.
named pairs
At invocation time, the user passes a set or
sequence of (namespace-name, schema document) pairs to the
processor, e.g. as a command-line option. (Can be used with
early or slow exit strategy.) The namespace name is used
as a check on the document, not as an instruction; if the
schema document has a target namespace which differs from
the namespace name specified, the processor signals an error.
schema documents
At invocation time, the user passes a set or sequence of schema
documents, or identifiers for schema documents (e.g. URIs), to the
processor, e.g. as a command-line option. Each schema document
is associated with its target namespace, if any.
(Can be used with early or
slow exit strategy.)
interactive inquiry
For each namespace, the processor asks
the user interactively (though mechanisms not specified
here) where to seek the required schema components.
Note:
This will perhaps be most useful as a fallback after other methods
have failed.
namespace name
For each namespace, the processor attempts
to dereference the namespace name; if a schema document is
returned, it is processed. If some other kind of resource representation is
returned, processors
may
interpret its content to locate a schema document.
Note:
For example, if a RDDL document is returned,
a processor
may
search the RDDL document for
rddl:resource
elements with the well-known property
xlink:role
= "
and then attempt to dereference the location(s) indicated on the
xlink:href
attribute of the link.
schemaLocation hints in XML instance document
For each namespace, if the input
document includes one or more schemaLocation hints for that
namespace, the processor attempts to dereference those
locations.
schemaLocation hints in schema documents
For each namespace, if a schema document being processed
includes one or more schemaLocation hints for that
namespace (e.g. on an
import
element,
the processor attempts to dereference those
locations.
local repository
For each namespace, a local repository of
schema components is consulted. In some situations the consultation
will require a key, in which see the terminology for indirection
given below.
C.2.2 Identifying methods of indirection
Some terms describe various methods of indirection through
local catalogs, search paths, or local repositories of schema
documents and/or schema components. In each of these, a
‘search key’ is assumed which helps to control the
indirection. Terms for different sorts of search key are
defined below.
path indirection
The processor has (hard-coded or accepted
as a parameter at invocation time or acquired from the
environment) a series of expressions into which a search key
is substituted. After substitution, each element of the
series is interpreted as a file-system path and a schema
document is sought at the location indicated by that path.
URI indirection
The processor has (hard-coded or accepted
as a parameter at invocation time or acquired from the
environment) a series of expressions into which a search key
is substituted. After substitution, each element of the
series is interpreted as a URI and a schema document is
sought at the location indicated by that path.
catalog indirection
The processor consults an OASIS catalog
(whose location can be hard-coded, passed as a parameter at
invocation time or acquired from the environment) using a
search key. The key can be sought for as a namespace name,
as a public identifier, or as a system identifier.
local repository indirection
A local repository of schema
components is consulted using a search key.
recursion
The location(s) returned by a catalog or other
indirection mechanism are not consulted immediately but
instead used as a key in a renewed indirection. Only after
the indirection mechanism fails to return a value is an
attempt made to dereference the last location returned.
non-recursion
The location(s) returned by a catalog or
other indirection mechanism are consulted immediately; they
are not used in recursive indirections.
C.2.3 Identifying the key for use in indirection
Locating schema components by means of any of the ‘indirect’
methods just identified will sometimes involve the specification of a
value of some kind as a search key. Processors
may
vary in
their choice of values to use as the key:
namespace key
The namespace name is used as a key.
location key
A location (e.g. a schema location hint or the
location specified in a catalog or by the user) is used as a
key.
C.2.4 Identifying when to stop searching
When more than one location is available for a given
namespace, two distinct behaviors can be distinguished; these
are orthogonal to other terms defined here:
early-exit
When more than one location is available for a
given namespace, the processor attempts each in turn. When
a location is successfully dereferenced and a schema
document is obtained, the later locations on the list are
ignored.
slow-exit
When more than one location is available for a
given namespace, the processor attempts each in turn. All
locations are tried, even if a schema document for the
namespace has been obtained.
C.2.5 Identifying how to react to failure
When a processor seeks schema components at a particular
location, but fails to find components of the namespace
in question at that location, several different
ways of responding to that failure can be distinguished:
error
The processor signals an error in some manner appropriate
to its construction and environment. Some processors
and some users will find it useful to distinguish fatal errors (which
cause processing to halt) from recoverable errors.
continue
The processor signals no fatal error and continues its search
for components in the namespace in question by attempting
another location.
C.3 Other Implementation-defined Features
This section defines terms intended to be useful in describing
other implementation-defined choices.
XML-1.0-based datatypes
The datatypes defined by
[XML Schema: Datatypes]
, taking
the relevant definitions from
[XML 1.0]
and
[Namespaces in XML 1.0]
for datatypes which depend on definitions from those specifications.
XML-1.1-based datatypes
The datatypes defined by
[XML Schema: Datatypes]
, taking
the relevant definitions from version 1.1 of
[XML 1.1]
and
[XML Namespaces 1.1]
for datatypes which depend on definitions from those specifications.
D Required Information Set Items and Properties (normative)
This specification requires as a precondition for
assessment
an information set as defined in
[XML Infoset]
which contains
at least the following
information items and properties:
Attribute Information Item
[local name]
[namespace name]
[normalized value]
[prefix]
[attribute type]
[owner element]
Character Information Item
[character code]
[parent]
Comment Information Item
[content]
[parent]
Element Information Item
[local name]
[namespace name]
[children]
[attributes]
[in-scope namespaces]
[namespace attributes]
[prefix]
[base URI]
[parent]
Namespace Information Item
[prefix]
[namespace name]
Processing Instruction Item
[target]
[content]
[base URI]
[parent]
In addition, infosets
should
support the
[unparsed entities]
property of the Document Information Item. Failure to do so will mean all
items of type
ENTITY
or
ENTITIES
will fail to
validate
. If the
[unparsed entities]
property is supported,
the following is also required:
Unparsed Entity Information Item
[name]
[system identifier]
[public identifier]
This specification does not require any destructive alterations to the input
information set: all the information set contributions specified herein are additive.
This appendix is intended to satisfy the requirements for
Conformance
to the
[XML Infoset]
specification.
E Checklists of implementation-defined and implementation-dependent features (normative)
E.1 Checklist of implementation-defined features
[Definition:]
An
implementation-defined
feature or behavior
may
vary among processors conforming to this
specification; the precise behavior is not specified by
this specification but
must
be specified by the
implementor for each particular conforming implementation.
(In the latter
respect,
implementation-defined
features differ
from
implementation-dependent
features.)
This appendix provides a summary of XSD
features whose effect is explicitly
implementation-defined
Any software which claims to conform to this specification
must
describe how these choices have been exercised, in
documentation which accompanies any conformance claim.
In describing the choices made for a given processor,
it is hoped that the terminology defined in
Terminology for implementation-defined features (normative) (§C)
will be found useful.
XSD 1.1 depends on other
specifications for the definitions of some data types
such as
string
QName
NCName
, and
for the definition of whitespace.
As noted in
Dependencies on Other Specifications (§1.4)
, it
is
implementation-defined
whether a schema processor
takes the definition of
string
from
[XML 1.1]
or from
[XML 1.0]
With regard to the other types which depend on other specifications
(e.g.
NCName
and related types),
all current editions of
[XML 1.0]
[XML 1.1]
[Namespaces in XML 1.0]
, and
[XML Namespaces 1.1]
have identical definitions of these constructs. Future editions, however, could
introduce changes. Implementations
may
support either the definitions in the
current specifications, or definitions in future specifications that supersede
them, or both. It is
implementation-defined
which.
It is
implementation-defined
whether a schema processor
can read schema documents in the form of XML documents.
(See
Conformance (§2.4)
.)
Whether a processor
is able to retrieve schema documents from the Web
is
implementation-defined
. (See
Conformance (§2.4)
which defines "
Web-aware
" processors
as processors
which can retrieve schema documents from the Web.)
The way in which a processor is invoked, and the way in
which values are specified for the schema to be used,
the information item to be validated,
and the declaration or definition with which to begin
validation, is
implementation-defined
. (See
Assessing Schema-Validity (§5.2)
.)
The manner in which a processor provides access to the
information items and properties in the PSVI to any
downstream or user applications, or to the invoker,
is
implementation-defined
(See
Conformance (§2.4)
.)
It is
implementation-defined
which
information items and properties in the PSVI
the processor provides access to, if any.
(See
Subset of the Post-schema-validation Infoset (§C.1)
for some subsets of the PSVI for
which this specification provides names and definitions.)
When the
post-schema-validation infoset
includes
[type definition name]
and
similar properties, it is
implementation-defined
whether
unique names are provided for anonymous type definitions.
The method used for assembling a set of schema components
for use in validation is
implementation-defined
(See
How schema definitions are located on the Web (§4.3.2)
for the normative prose and
Terminology of schema construction
(§C.2)
for some terminology which
can be used in describing implementation choices.)
It is
implementation-defined
whether a schema processor
provides a value for the
[type definition name]
and
[member type definition name]
properties of attribute and element information-items
(see
Attribute Validated by Type (§3.2.5.4)
and
Element Validated by Type (§3.3.5.4)
).
If it does so, the choice of name is
implementation-dependent
10
Everything
implementation-defined
in
[XML Schema: Datatypes]
is also
implementation-defined
in this specification.
Note:
This includes, but is not limited to, the choice
of
XML-1.0-based
or
XML-1.1-based
datatypes, or both;
support for
implementation-defined
primitive datatypes;
support for
implementation-defined
ordinary datatypes;
whether
implementation-defined
datatypes are automatically
declared or not;
whether
implementation-defined
datatypes are automatically
included in every schema or not;

support for
implementation-defined
constraining facets;
and
the order in which
implementation-defined
pre-lexical
facets are applied to literals.
See the
appendix
on
implementation-defined and implementation-dependent
features in
[XML Schema: Datatypes]
11
It is
implementation-defined
whether a processor detects
violations of clause
2.4.2
of
Derivation Valid (Restriction, Complex) (§3.4.6.3)
(a) always by examination of the schema in isolation,
(b) only when some element information item
in the input document is valid against its
governing type definition
but not against
{base type definition}
, or
(c) sometimes the one and sometimes the other.
In case (c), the circumstances
in which the processor does one or the other are
implementation-dependent
12
It is
implementation-defined
when a processor detects type errors
in XPath expressions and whether it treats type errors as
static or dynamic errors.
The values of current dateTime and implicit timezone are
also
implementation-defined
in the evaluation of XPath expressions,
as described in
XPath Evaluation (§3.13.4.2)
The values of various properties in
the static context used for XPath evaluation are
implementation-defined
as described in
XPath Valid (§3.13.6.2)
13
It is
implementation-defined
under what conditions a processor
will detect the equivalence of two distinct
Type Table
or
Type Alternative
components.
All processors
must
detect equivalence under certain
specified conditions, but the ability to detect equivalence
under other conditions is not constrained.
See
Element Declarations Consistent (§3.8.6.3)
14
It is
implementation-defined
what effect invalid elements within

have on the construction of
schema components from a schema document, and whether
a processor treats schema documents which are invalid
only in consequence of containing such invalid elements
as being in
error
or not.
15
It is
implementation-defined
whether an implementation
provides user options to retain comments and processing
instructions in the
[XDM]
data model
instance used for checking assertions, as described in
Assertion Satisfied (§3.13.4.1)
16
The function signatures available when XPath
expressions in type alternatives are evaluated
is
implementation-defined
, as described in
Constraints on Type Alternative Schema Components (§3.12.6)
E.2 Checklist of implementation-dependent features
[Definition:]
An
implementation-dependent
feature or behavior
may
vary among processors conforming to this
specification; the precise behavior is not specified by
this or any other W3C specification
and is not required to be specified by the implementor
for any particular implementation.
(In the latter
respect,
implementation-dependent
features differ
from
implementation-defined
features.)
This appendix provides a summary of XSD features whose
effect is explicitly
implementation-dependent
. Choices made by processors
in these areas are
not
required to be documented.
When a default value of type
QName
or
NOTATION
is applied to an
element or attribute information item, it is
implementation-dependent
whether
namespace fixup
occurs to ensure that the
{lexical form}
maps to the
{value}
When a default value is supplied for a defaulted attribute and more than
one prefix is bound to the namespace of the attribute in the
[in-scope namespaces]
, it is
implementation-dependent
which prefix is used for the
attribute.
When a default value is supplied for a defaulted attribute and
namespace fixup
is performed, it is
implementation-dependent
what prefix is used in the new
namespace information item.
When a default value is supplied for a defaulted attribute and
namespace fixup
is performed, it is
implementation-dependent
whether the consistency of the information set is preserved by (a) adding
the new binding to the descendants of the element on which the defaulted
attribute occurred, or by (b) undeclaring the new binding on the children
of that element. When
[Namespaces in XML 1.0]
rather than
[XML Namespaces 1.1]
is in use, namespace bindings cannot be
undeclared, so the behavior is
implementation-dependent
only for those
implementations which do support
[XML Namespaces 1.1]
If more than one
Identity-Constraint Definition
fails to be satisfied, it is
implementation-dependent
which of them are included in the
[failed identity constraints]
property of PSVI.
If more than one
Assertion
fails to be satisfied, it is
implementation-dependent
which of them are included in the
[failed assertions]
property of PSVI.
The order of
Annotation
components within various components'
{annotations} property is
implementation-dependent
If a name is supplied for anonymous components
(for example,
[type definition name]
and
[member type definition name]
properties in the
post-schema-validation infoset
), the choice of name is
implementation-dependent
If a processor detects
some violations of clause
2.4.2
of
Derivation Valid (Restriction, Complex) (§3.4.6.3)
by examination of the schema in isolation,
and others only when some element information item
in the input document is valid against its
governing type definition
but not against
{base type definition}
then the circumstances
in which the processor does one or the other are
implementation-dependent
F Stylesheets for Composing Schema Documents (Normative)
The transformations specified in the following sections
in the form of
[XSLT 2.0]
stylesheets are used when
assembling schemas from multiple schema documents. Implementations do not
have to perform
[XSLT 2.0]
transformation, or use
the stylesheets given here, as long as the
same result is produced.
F.1 Transformation for Chameleon Inclusion
When a

information item
D2
without a
targetNamespace
[attribute]
is included
Assembling a schema for a single target namespace from
multiple schema definition documents

) (§4.2.3)
), redefined
Including modified component definitions (

) (§4.2.4)
), or overridden
Overriding component definitions (

) (§4.2.5)
) by another

D1
with a
targetNamespace
[attribute]
, the following
transformation, specified here as an
[XSLT 2.0]
stylesheet, is applied to
D2
before its contents are mapped to schema
components. The
transformation performs two tasks:
Add a
targetNamespace
[attribute]
to
D2
, whose value
is the same as that of the
targetNamespace
[attribute]
of
D1
Update all QName references in
D2
that do not have a namespace name
so that their namespace names become the
actual value
of the
targetNamespace
[attribute]
Stylesheet for Chameleon Inclusion

xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:f="http://www.w3.org/2008/05/XMLSchema-misc"
version="2.0">

required="yes"/>
select="f:generateUniquePrefix(., 0)"/>

select="$newTargetNamespace"/>

select="$newTargetNamespace"/>

select="concat($prefixForTargetNamespace,
':',
local-name-from-QName(resolve-QName(string(.), ..)))"/>

select="resolve-QName(., $context)"
as="xs:QName"/>
select="if (namespace-uri-from-QName($oldValue) eq '')
then concat($prefixForTargetNamespace, ':',
local-name-from-QName($oldValue))
else string(.)"/>

select="if (starts-with(.,'##'))
then ()
else resolve-QName(., $context)"
as="xs:QName?"/>
select="if (starts-with(.,'##'))
then string(.)
else if ((namespace-uri-from-QName($oldValue) eq '')
or
empty(namespace-uri-from-QName($oldValue)))
then concat($prefixForTargetNamespace,
':',
local-name-from-QName($oldValue))
else string(.)"/>

select="distinct-values($xsd//*/in-scope-prefixes(.))"/>
select="xs:NCName(concat('p', $try))"/>

F.2 Transformation for
xs:override
When a

information item
D1
contains

elements, the transformation specified in the following
[XSLT 2.0]
stylesheet is performed once for
each such

element. It requires as
parameters (a) the

element in
D1
(call it
O1
) as the
overrideElement
parameter
and (b)
the

element of the schema document
D2
identified by the
schemaLocation
attribute of
O1
as the
overriddenSchema
parameter.
The transformation
produces another

element
D2′
which is equivalent
to
D2
except that some elements in
D2
are replaced

or modified.
The normative description of the transformation is given by the stylesheet
below; the transformation can also be described (non-normatively) in prose
as in the following paragraphs.
The
[attributes]
of
D2′
(for example,
targetNamespace
and
defaultAttributes
) are
copies of the
[attributes]
of
D2
For each element information item
E2
in the
[children]
of any

or

element information item within
D2
the appropriate
case
among the following is true:
If
E2
has element type






, or

, and
O1
has a child
E1
with the same element type
and the same value for its
name
attribute,
then
D2′
has a
copy of
E1
in the location corresponding to
E2
's
place in
D2
If
E2
has one of the
element types specified in clause
but
O1
has no
matching child,
then
D2′
has a copy of
E2
in the place
corresponding to the location of
E2
in
D2
If
E2
has element type

then
D2′
has an

element
with
schemaLocation
E2
schemaLocation
and
[children]
which are copies of
those of
O1
If
E2
has element type

then
D2′
has an

element
E2′
with
E2′
schemaLocation
E2
schemaLocation
and
[children]
which are drawn from among the
[children]
of
E2
and
O1
, as specified by
the appropriate
case
among the following:
4.1
If
a child of
E2
and a child of
O1
match as described
in clause
then
E2′
has a child

which is a copy of
the child of
O1
4.2
If
a child of
E2
matches no child of
O1
as described
in clause
then
(as described in clause
E2′
has a child
which is a copy of
the child of
E2
4.3
If
a child of
O1
matches no child of
E2
as described
in clause
then
E2′
has a child
which is a copy of
the child of
O1
Note:
Informally, the rule just given has the effect that
E2′
contains copies of
(a) all the
[children]
of
O1
, as well as of (b) all of
the
[children]
of
E2
which are not overridden by some child
of
O1
. The
copies
corresponding to
[children]
of
E2
come first, followed by the
copies of those
[children]
of
O1
which matched
nothing in
E2
If
E2
has any other element type,
then
D2′
has a copy of
E2
in the place
which corresponds to the location of
E2
in
D2
The base URI of
D2′
is the same
as that of
D2
Note:
Informally,
D2′
is like
D2
except that
(a) any elements matched by any
[children]
of
O1
are overridden (replaced) by the corresponding
[children]
of
O1
(b) any schema documents included by means of

elements
in
D2
are overridden (transformed) by
O1
instead of
being included without change,
and (c) any schema documents overridden by means of

elements
in
D2
are to be overridden (transformed) both as
specified in the

elements
in
D2
and as specified in
O1
; if both apply,
the information in
O1
takes precedence.
The result is that the transformation
described by
O1
is applied to all the document in the
target set
of
O1
Note:
Because
D2
and
D2′
have
the same base URI, relative references in
D2′
will
be unaffected by the transformation.
Stylesheet for
xs:override
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:f="http://www.w3.org/2008/05/XMLSchema-misc"
exclude-result-prefixes="f">

priority="5">

priority="3">


select="$overrideElement/*
[node-name(.)
= node-name($original)
and
f:componentName(.)
= f:componentName($original)]"/>

select="@schemaLocation, $overrideElement/*"/>

priority="5">








mode="copy-unmatched">
select="$overrideElement"/>
select="."/>

select="$overriddenOverride/*[
node-name(.)
= node-name($overriding)
and
f:componentName(.)
= f:componentName($overriding)
]"/>

G Changes since version 1.0 (non-normative)
G.1 Changes made since version 1.0
G.1.1
Relationship between XSD and other specifications
G.1.2
XSD versions
G.1.3
Changes to content models
G.1.4
Assertions and XPath
G.1.5
Derivation of complex types
G.1.6
Changes to complex type definitions
G.1.7
ID, IDREF, and related types
G.1.8
Simple type definitions
G.1.9
Element declarations
G.1.10
Attribute declarations
G.1.11
Component structure
G.1.12
The process of validation
G.1.13
The post-schema-validation infoset
G.1.14
Conformance
G.1.15
Schema composition
G.1.16
Other substantive changes
G.1.17
Clarifications and editorial changes
Note:
The grouping of changes
below is intended to
make the list easier to scan. It is an ad hoc grouping for
convenience to which no great significance should be attached.
Some changes could have been listed in more than one place; in
such cases the choice was arbitrary.
G.1.1 Relationship between XSD and other specifications
Changes to the
relationship between this and other specifications:
Support for XML 1.1 has been added.
It is now implementation defined whether datatypes dependent
on definitions in XML (
[XML 1.1]
[XML 1.0]
) and Namespaces in XML
[XML Namespaces 1.1]
[Namespaces in XML 1.0]
) use the definitions as
found in version 1.1 or version 1.0 of those specifications.
To reduce confusion and avert a widespread misunderstanding,
the normative references to various W3C specifications now state
explicitly that while the reference describes the particular edition
of a specification current at the time this specification is
published, conforming implementations of this specification
are not required to ignore later editions of the other
specification but instead
may
support later editions, thus
allowing users of this specification to benefit from corrections to other
specifications on which this one depends.
The XPath subset for selectors and fields in section
Selector Value OK (§3.11.6.2)
and
Fields Value OK (§3.11.6.3)
has been revised
to align its tokenization rules
better with
[XPath 2.0]
; this resolves issue
8454
Tokens in XPath subset for selectors/fields
G.1.2 XSD versions
Schema language versions:
A conditional inclusion mechanism is defined, roughly
analogous to the XSLT 2.0
use-when
attribute or
to the C preprocessor
#ifdef
construct. By
means of the
vc:minVersion
and
vc:maxVersion
attributes, a simple forward-processing
mechanism is supplied, so that conforming XSD 1.1 processors
can successfully ignore constructs introduced in
future versions (if any) of XSD, and so that schema authors
can define schemas which use newer constructs when available
but can fall back on older constructs when the newer
constructs are not available.
Identifiers for different versions of XSD are now defined
in section
Schema Language Identifiers (§1.3.4)
G.1.3 Changes to content models
Content models:
The
Unique Particle Attribution (§3.8.6.4)
constraint has been relaxed. While competition between two
element particles
is still forbidden, as is competition between
two
wildcard particles
, competition between an
element particle
and
wildcard particle
is no longer forbidden. In the course of
making this substantive change, some editorial changes have
also been made, in order to make the exposition clearer.
(Readers familiar with version 1.0 of this specification will
find that the constraint works in almost exactly the same way
as it did in 1.0, except that content models in which an input
item matches either a
wildcard particle
or an
element particle
are
now allowed.)
Content models may now use the

element to specify content
models with "open content". Such content
models allow elements
not explicitly mentioned in
the content model to appear in the document instance; it is
as if wildcards were automatically inserted at appropriate
points within the content model. By specifying what kind of
wildcard is implicitly inserted, the schema author can
adjust the degree of openness and determine what elements
are accepted by the open content; the schema author can also
specify that the content model should be open everywhere, or
only at the end. A schema-document wide default may be
set, which causes all content models to be open unless
otherwise specified.
Wildcards may now be defined which allow names in any
namespace but those in a set of proscribed namespaces.
(In version 1.0 of this specification, only a single
namespace, the target namespace of a schema document,
could be proscribed.) Also, wildcards can now be written
which match any element in a set of namespaces but
which exclude a particular set of qualified names from
matching the wildcard.
Finally,
the keyword
##definedSibling
can be used
to exclude all elements explicitly mentioned in
a content model (and all elements substitutable for
those elements).
Wildcards can now be defined which match any element
(in the specified namespaces) which does
not
match an element declaration in the schema (so-called
"not-in-schema" wildcards).
Several of the constraints imposed by version 1.0 of this
specification on
all
-groups have been relaxed:
Wildcards are now allowed in
all
groups.
The value of
maxOccurs
may now be greater than 1 on particles
in an
all
group. The elements which match a particular
particle need not be adjacent in the input.
all
groups can now be extended by adding more members to them.
Complex types whose content models are
all
-groups
can now be extended; the result is an
all
-group
(usually a larger one).
The discussion of checking content-type restriction
included in an appendix in earlier drafts of this specification
has now been removed, as have some references to published algorithms
for the problem. Several of the papers referred to are no longer
publicly accessible on the Web, and the changes made to the
Unique Particle Attribution (§3.8.6.4)
have in any case rendered those
algorithms obsolete. These changes resolve issue
6685
Appendix I Checking content-type restriction References Not Available
Group references are now allowed in

model groups.
Such
references
must
have
minOccurs=maxOccurs=1
and
must
refer
to other

groups.
(This change
resolves issue
7031 XSD 1.1 doesn't support conversion of xs:sequence to xs:all
because xs:all can't contain groups references
.)
G.1.4 Assertions and XPath
Assertions and rules for evaluation of XPaths
Support for check clauses to
implement some co-occurrence constraints has been added. Each
complex type can carry a list of assertions, which are checked
when the complex type is used to validate an element
information item.
The facility for assertions defined in the
working draft of 31 August 2006 has been revised.
The
report
element described in earlier
drafts has been removed. This involves no loss of functionality:
the same effect can be obtained by wrapping the test expression
on an

element in a negation.
The XPath subset defined for assertions has been

eliminated. (A somewhat smaller subset is now defined
for conditional type assignment.)
Rules are defined for the evaluation of XPath expressions
(in assertions, in conditional type assignment, or in
identity-constraint definitions).
The static and dynamic contexts for XPath evaluation
are explicitly specified.
Rules are provided for constructing the
[XDM]
data model instance against which the
XPath expressions
are to be evaluated. Different
rules apply in different situations:
When assertions on a complex type are evaluated,
only the subtree rooted in an element of that type is
mapped into the data model instance. References to
ancestor elements or other nodes outside the subtree
are not illegal but will not be effective.
For conditional type assignment, neither the
ancestors nor the children of the element in question
are included; the conditions for type assignment are
thus effectively restricted to the attributes of the
element.
For assertions on simple types, only the value
is provided; the dynamic context includes no
context item.
Rules for assigning types to the nodes of the
data model instance are defined. Again, the rules
differ for the different uses of XPaths:
When assertions are evaluated, all of the elements
and attributes descended from the element being
validated are typed in the normal way; this has the
effect that comparisons among attribute values (for
example) are performed in a way consistent with the
declarations of the attributes. The element node
itself, however, is not typed (since it has not yet
been completely validated).
For conditional type assignment, the nodes of the
data model instance are untyped.
The conceptual overview now included in
Constraint Components (§2.2.4)
some
discussion of the overlap in functionality
among identity constraints, conditional type assignment,
and assertions, and identifies some of the factors
which may be relevant in choosing among them; this
change resolves issue
5023
Relationship between identity constraints and assertions
The rules for the "available collections" and "default collection"
properties of the
[XPath 2.0]
dynamic context
have been simplified; these properties are now
required to be the empty set instead of being
implementation-defined
. This improves interoperability and
resolves issue
6540
Available documents in assertions
The
[XPath 2.0]
static context
used
for the evaluation of assertions has been clarified; it now
explicitly includes
the functions in the
[Functions and Operators]
fn
namespace and
constructors for all built-in types. This resolves issue
6541
Assertions and in-scope functions
G.1.5 Derivation of complex types
Derivation of complex types:
The rules for checking validity of complex-type restrictions
have been simplified by reformulating the constraint in terms
of local validity: the set of elements or attributes accepted
by a restriction as locally valid must be a subset of those accepted by its
base type. The rules for attributes have also been changed.
The complex rules involving matching up particles in the base type
and particles in the restriction, with their complex case by
case analysis, have been replaced by a statement of the
constraint which is shorter and more correct.
It is now possible to specify a target namespace for
local elements and attributes which differs from the target
namespace of the schema document itself, when restricting
a complex type which has local elements or attributes and
which itself is in another namespace. This should
simplify the reuse of types from other namespaces.
The rules for complex type restriction now allow identity
constraints on local elements. To make this possible,
identity constraints may now be given names and referred to
from elsewhere. Corresponding changes have been made in the
description of the
Schema
component and in the
rules for
QName
resolution
This draft clarifies the rule requiring that any complex
type derived by extension could, in principle, be derived in
three steps from
xs:anyType
(first a restriction step,
then an extension step, then a restriction step). A
misleading note about the purpose of this rule has been
deleted.
G.1.6 Changes to complex type definitions
Complex type definitions (miscellaneous changes):
Changes
have been made to
Locally Declared Type (§3.4.4.1)
Element Locally Valid (Complex Type) (§3.4.4.2)
, and
Derivation Valid (Restriction, Complex) (§3.4.6.3)
to require more consistency in type
assignment when elements with the same expanded name may
match both a local element declaration and a wildcard
in the same content model.
Conceptually, these
changes are related to
the constraint expressed in
Element Declarations Consistent (§3.8.6.3)
XSD 1.0 allows such content
models even if there is a discrepancy between the type
assigned to elements by the local element declarations
and by the top-level element declaration which
will govern elements which match the wildcard.
For compatibility reasons, such content models are still
allowed, but any element instance which matches the wildcard
is required to have a governing type definition compatible with
the type assigned by the local element declarations
matched by the element's expanded name.
The elements

and

are now forbidden
to have different values for the
mixed
attribute.
The constraint
Element Declarations Consistent (§3.8.6.3)
now
takes open content into account.
This change, together with the explicit exclusion of
skip wildcards from the constraint, resolves issue
5940
Element Declarations Consistent
The rules for restriction of complex types containing local
elements with conditional types have been simplified; this
resolves issue
12185
Conditional Type Assignment and substitutability
The text has been revised

to correct the terminology used to describe correct XPath
expressions and to specify that it is
implementation-defined
when type errors in XPath expressions are detected and
whether they are treated as static or dynamic errors.
This change
resolves issue
11073
Type errors during XPath evaluation
The description of assertions has been revised to make it
explicit that the data model instance constructed for testing
assertions has a parentless element node as its root, and not
an element node with a document node as its parent. This
change resolves issue
12127
"Root element" in assertion testing
G.1.7 ID, IDREF, and related types
ID, IDREF, and related types:
Certain constraints involving
ID
have been
extended to include lists of
ID
and unions including
ID
. See e.g.
Constraints on Attribute Declaration Schema Components (§3.2.6)
An element may now have multiple attributes of type
xs:ID
. Elements have always been able to have
multiple children of type
xs:ID
, but XSD 1.0 forbad
multiple attributes of this type for compatibility
with XML DTDs. (Schemas intended to be translatable into DTD
form should still avoid the practice.) This change should make
it easier for XML vocabularies to support both existing
ID attributes and
xml:ID
The validation rules for values of type
xs:IDREF
xs:ENTITY
, or
xs:ENTITIES
are now enforced on default values.
Elements and attributes of type
xs:ID
may now have
default or fixed values. XSD 1.0 had forbidden this, for
compatibility with XML DTDs.
The text has been revised to ensure that the special validation
rules for
xs:ID
xs:IDREF
xs:IDREFS
xs:ENTITY
, and
xs:ENTITIES
apply not only
to the built-in types themselves but also to types derived from them
by restriction, list construction, union, and extension.
This resolves issue
10662
Should IDREFS and ENTITIES be magic types?
G.1.8 Simple type definitions
Changes involving
simple type definitions and
related constraints:
A new type definition called
anyAtomicType
has been introduced into the type
hierarchy between
anySimpleType
and all the
atomic
built-in type definitions. See
Built-in Simple Type Definitions (§3.16.7)
An error in version 1.0 of this
specification relating to the construction of union types from
other union types has been corrected. Unions may now appear
as members of other unions, and all restrictions of unions are
correctly enforced;
the rule
Type Derivation OK (Simple) (§3.16.6.3)
has been
modified to ensure that member types are not
validly substitutable
for facet-restricted unions.
As a result,
xsi:type
may no longer be used, as in XSD 1.0,
to subvert restrictions of union types.
The requirement that a facet value be a "valid
restriction" of another, in the context of simple
type restriction, has been clarified.
No union type may be a member of its own transitive membership,
nor may any type derived from the union. (XSD 1.0 forbad
union datatypes to be members of other unions and thus had
no need to forbid this explicitly.)
Since not all datatypes have a
defined canonical representation for all of their values,
appeals to the canonical forms of values have been
eliminated.
Changes have been made to ensure that
the descriptions of the
Simple Type Definition
component and of
xs:anySimpleType
agree in all
details with those of
[XML Schema: Datatypes]
Equality and identity of lists have been clarified.
The fact that
xs:anyType
is its own base type
has been clarified
(addresses issue
6204
anyType/ur-Type: inconsistent whether it has a base-type
).
Enumerations, value constraints, and identity constraints now
accept
either
equal
or
identical
values as the same. This change resolves issue
9196
Enumeration and NaN
Changes have been made in section
Constraints on XML Representations of Simple Type Definitions (§3.16.3)
and section
Constraints on XML Representations of Complex Type Definitions (§3.4.3)
to make explicit that XML representations of
extension facets (facets in namespaces other than the Schema
namespace) are allowed to appear more than once in restrictions
of simple types. This resolves issue
11222
src-simple-type.1 should allow duplicate elements from
"##other" namespaces
G.1.9 Element declarations
Changes to element declarations:
A new form of co-occurrence constraint has now been defined,
by allowing the type assigned to element instances to
be conditional on properties of the instance (typically
attribute values). The addition of conditional type assignment
has entailed a number of changes:
Introduction of a
Type Table
property on element declarations,
to hold a sequence of
Type Alternative
s (condition - selected-type pairs) and a default
type definition.
Constraints on that table: all types named in the table (including
the default) must be
validly substitutable
for the
declared
{type definition}
Changes to the XML syntax and XML mapping rules
to allow expression of conditional type
bindings: the

element is added,
the content model of

is changed.
Validation rules for conditional types:

the definition of
governing type definition
is adjusted
to account for conditional type assignment.
Rules for evaluating the conditional typing tests
(more specifically, rules for constructing a temporary infoset
and then building the XDM instance and evaluating the
XPath expressions as defined elsewhere; priority of
tests is given by document order / component order).
PSVI changes to reflect details of the conditional typing:
a {type alternative} property is added, and the discussion of
[type fallback] now refers to the
selected type definition
rather than
to either the
declared
{type definition}
or to the
governing type definition
of the
element information item
Introduction of some terminology for discussing conditional
types
(define
selected type definition
conditionally selects
validly substitutable as a restriction
).
Rules for checking type restriction in the presence of conditional
types.
Introduction of a special
xs:error
type for use
in identifying conditionally assigned types which violate
restriction rules
Miscellaneous supporting editorial changes.
Element declarations may now specify multiple substitution-group
heads.
Abstract elements may now appear in substitution groups.
The treatment of type tables in
Element Declarations Consistent (§3.8.6.3)
has been
made more specific; this resolves issue
11076
Element Declarations Consistent: comparing type tables
G.1.10 Attribute declarations
Attributes:
Attribute declarations can now be marked
{inheritable}
(see
Inherited Attributes (§3.3.5.6)
and the values of inherited attributes are accessible in the XDM
data model instance constructed for conditional type assignment
(see
Type Alternatives (§3.12)
).
Among other consequences, this allows conditional type assignment
to be sensitive to the inherited value of
the
xml:lang
attribute and thus to the language of
the element's contents. This change was introduced to resolve issue
5003
Applicability of element to xml:lang
raised by the
W3C Internationalization Core Working Group
The rules for default attribute values now refer to the
effective value constraint
rather than to the
[Value Constraint]
; this resolves a bug
in the handling of default values for global attribute
declarations.
The text now makes clear that it is pointless (although
not illegal) for schema documents to supply default or fixed
values for
xsi:type
and other attributes in the
namespace
, since they
will not be applied.
Default attribute groups are now supported. The

element can carry a
defaultAttributes
attribute, which identifies a
named
Attribute Group Definition
; each complex type defined in
the schema document then automatically includes that
attribute group, unless this is overridden by the
defaultAttributesApply
attribute on the

element. Default attribute groups
make it easier to specify attributes which should be accepted
by every complex type in a schema (e.g.
xml:id
and
xml:lang
).
All wildcard unions are now expressible;
this change resolves issue
6163
3.10.6.3 Attribute Wildcard Union
As described in
XML Mapping Rule for Named Attribute Groups (§3.6.2.1)
circular references from

to

are now allowed;
all attribute groups in the cycle of references are included.
G.1.11 Component structure
Changes in the structure
of schema components:
Every component now has an
{annotations} property whose value is a sequence of annotation
elements and out-of-band attributes. See e.g.
The Complex Type Definition Schema Component (§3.4.1)
Annotations are no longer
allowed to vary in the part of a content model shared
by a complex type and its extensions. (This was never
possible in components specified using schema documents,
but was possible in "born-binary" components.)
{context}
property has been defined for the definitions of complex and
of simple types; this property simplifies testing for the
identity of anonymous type definitions. See e.g.
The Complex Type Definition Schema Component (§3.4.1)
. The {context} property
replaces the {scope} property found in some earlier drafts of
this document.
The
Schema
component has an
additional
{identity-constraint definitions}
property containing all the identity
constraints in the corresponding schema. See
The Schema Itself (§3.17.1)
and
XML Representations of Schemas (§3.17.2)
The underlying basis for the
definition of all the different kinds of components has
changed to make use of a regular and formal tabulation of
their properties. This has been achieved by introducing
property records
wherever version 1.0 had complex
property values. For example instead of describing the
{scope} property as having "either
global
or a
complex type definition" for its value, a
Scope
property record is called for, which in turn has its
own simple properties and values. See e.g.
The Element Declaration Schema Component (§3.3.1)
G.1.12 The process of validation
The process of validation:
When an
xsi:type
attribute appears on an element
and has a QName as its value,
but the QName does not resolve to
a known type definition,
the element is assigned a "fallback"
governing type definition
for validation. The
governing type definition
will be
the
selected type definition
or the declared
{type definition}
if available, and
xs:anyType
otherwise.
The validation process is now explicitly defined
as including the validation of the element and its descendants;
processors no longer have the implicit option
of skipping the element and its descendants.
Element information items which match no particle in a content
model are now to be validated using their
locally declared type
Earlier drafts did not specify what happened in such cases.
Lax assessment
is now required
when an element information item to be validated has neither
governing element declaration
nor a
governing type definition
; also, lax assessment
now requires that the
[children]
and
[attributes]
of the element
be assessed as well. In XSD 1.0 and in earlier drafts, lax
assessment was optional and did not require the
recursive assessment of
[children]
and
[attributes]
The text now specifies that
if an element has an
xsi:type
attribute
which does not
resolve
to a type definition,
then the
xsi:type
attribute is invalid.
The terminology of assessment has been changed to avoid the
suggestion that an element information item can be
strictly assessed
without being
assessed
An anomaly in the definition of
governing element declaration
has been corrected,
to ensure that elements matching strict or lax wildcards have
the appropriate global element declaration, if it exists, as their
governing element declaration
. (Resolves issue
7913
Strange result from definition of governing element declaration
.)
The usage of the terms "
validation
" and
assessment
" has been clarified, and definitions
of various forms of document validity have been added
for the convenience of users of this specification;
see
Schema-validity and documents (§2.5)
(Resolves issues
5164
validation vs assessment
and
6015
[schema11] valid (and its derivations) vs assessment as used in text
.)
The definition of
Element Locally Valid (Type) (§3.3.4.4)
has been changed to remove the rule that an element
with an
instance-specified type definition
cannot be locally valid against
any type definition other than the one specified in
the instance.

This resolves issue
11764
Unresolved xsi:type should not affect validity against a type
G.1.13 The
post-schema-validation infoset
Changes in the
description of the
post-schema-validation infoset
The presentation of the
post-schema-validation infoset
has been simplified by removing
the suggestion that the
post-schema-validation infoset
varies from processor to processor.
Instead, the exposition now makes clearer that the body of information
available in principle after schema-validity assessment is consistent
across all
processors; processors may make different subsets of the
post-schema-validation infoset
accessible to downstream applications, but when they do so
the variation reflects the implementors' decisions
about what information to expose, not variation in the information
in the
post-schema-validation infoset
Terms have been defined to describe different subsets of the
post-schema-validation infoset
which may be exposed by processors.
Provision is made for exposing the
actual values
of elements and
attributes in the
post-schema-validation infoset
, in the
{schema actual value}
property.
The
[element declaration]
property and various
other properties in the
post-schema-validation infoset
are now described as being
present in the
post-schema-validation infoset
whenever a
governing
declaration
and/or
governing
type definition is known for the item,
instead of only when the item is valid.
When the
governing
type definition of an attribute or element
information item is a list type whose item type is a union,
the
post-schema-validation infoset
now includes the
validating type
for
each item in the list.
When default values are supplied for attributes with
qualified names,
namespace fixup
is performed to ensure that the
[in-scope namespaces]
property of the attribute's host element has an
appropriate binding for the namespace name. It is
implementation-dependent
whether
namespace fixup
is also performed on descendants of that element
so as to retain consistency of the infoset.
Namespace fixup
may also be
helpful if the defaulted value is of type
QName
or
NOTATION
; it is
implementation-dependent
whether fixup is performed for such values.
Annotations given in the XML form of identity-constraint declarations
with
ref
attributes are now retained in the
post-schema-validation infoset
form of the containing element declaration. This change resolves
issue
6144
annotation on IDC with a 'ref' attribute is lost
G.1.14 Conformance
Changes to the
description of conformance:
The set of conformance classes
has been revised and clarified. Instead of
"minimally conforming",
"schema-document aware", and
"Web-aware" processors, this specification
now defines (in section
Conformance (§2.4)
) conformance classes for
general-purpose validators
general-purpose schema-validity assessors
special-purpose validators
, and
other special-purpose tools
together with terminology which may be useful in describing
particular processors.
This change resolves issue
7695
Conformance
A checklist has been included listing ways in which conforming
processors may vary from each other, and terminology has been
provided for some of the more important properties of conforming
processors, in an attempt to make it easier for implementors to
describe concisely which options their processors exercise, and
easier for users to describe what kinds of processor they
require.
The definition of
must
and
error
have been revised to
specify that conforming processors
must
detect and report
error in the schema or schema documents. The quality
and detail of the error messages are not constrained.
Implementations are now allowed to support primitive datatypes
and facets beyond those defined in
[XML Schema: Datatypes]
The validity requirements for schema documents are stated more
fully and correctly.
G.1.15 Schema composition
Schema assembly and composition:
The

construct is
deprecated
An

construct has been defined;
in some ways it resembles

but imposes no constraints on the new definitions provided
for components whose definitions are being overridden.
The discussion of

and

has been revised to eliminate an ambiguity in earlier versions of
this spec regarding the meaning of cyclic dependencies formed by
use of

and

: such
cyclic dependencies are now clearly allowed and have a well defined
meaning.
When an
xsi:schemaLocation
attribute provides
information about a schema document location for a
particular namespace, it is no longer an error for it to be
encountered after the first occurrence of an element or
attribute information item in that namespace.
Note, however, that if processing such an
xsi:schemaLocation
attribute causes new components to be added to the schema, then
the new components cannot change the assessment outcome of any
information items already seen before the element bearing
the
xsi:schemaLocation
attribute.
No

is needed in a schema document
in order to refer to components in namespaces
or
In XSD 1.0, the examples showed no such imports, but
there was no rule making it legal to omit the

The handling of "chameleon" inclusion and redefinition
in schema documents has been simplified. The new target
namespace affects any component or property which would have
the target namespace if the schema document specified one.
This change makes it easier to write assertions in schema
documents without a namespace which are intended to be
included by schema documents with varying target namespaces.
Section
Identifying how to react to failure (§C.2.5)
has now been added,
defining the terms
error
and
continue
for use in specifying what a processor does or should do
when it seeks components for a given namespace in a given location
but fails to find them there.
Schema processors are now explicitly recommended to provide
a user option to control whether the processor attempts to
dereference schema locations indicated in
schemaLocation
attributes in the instance document being validated; this resolves
issue
5476
xsi:schemaLocation should be a hint, should be MAY not SHOULD
The discussion of
schemaLocation
information in
How schema definitions are located on the Web (§4.3.2)
has been revised to try to make clearer
the motivation for recommending user control over whether
schema locations specified in the document instance should
or should not be dereferenced. The new text describes some
circumstances in which such schema locations typically should be
dereferenced and some in which they should not, and attempts to
set useful expectations for users and for implementors.
These changes are intended to resolve issue
6655
raised by the W3C Web Accessibility Initiative's

Protocols and
Formats Working Group.
The discussion of schema import in
Licensing References to Components Across Namespaces (§4.2.6.1)
now states more
clearly that references to components in external
namespaces are an error if the namespace is not imported;
this change addresses issue
5779
QName resolution and xs:import
Some errors in the XSLT stylesheet of appendix
Transformation for Chameleon Inclusion (§F.1)
have been corrected
(resolving issues
8573 F.1 Stylesheet for chameleons invalid
and
8574 F.1 Stylesheet for chameleons incomplete
).
The sections on the XML representation of components have been
revised to say explicitly that the constraints and mapping rules
defined there apply after, not before, pre-processing.
This change resolves issues
11179
minor editorial improvement : parent schema components of a named model group
and
11354
Mentions of "override" outside of the override section
G.1.16 Other substantive changes
Miscellaneous substantive changes:
The discussion of schema-validity assessment and the invocation
of conforming processors has been revised; additional invocation
patterns have been identified, and names have been given to
the different methods of invoking a processor.
When an element cannot be strictly validated because no
element declaration or type definition is available
for it, fallback to lax validation (validating the element
against the built-in type
xs:anyType
) is now required;
in earlier drafts of this document, fallback to lax validation
was optional.
The XML Representation Constraints no longer refer to the
component level; this makes it possible to test a schema
document in isolation to determine whether it conforms or
fails to conform to these rules.
The constraints on the XML representation of schemas have been
reformulated to allow them to be checked on schema documents in
isolation, rather than requiring knowledge of the rest of the schema
into which they will be embedded. The consequence is that
some errors are caught not in the XML representation constraints
but by having the XML mapping rules generate faulty components
so that the error can be detected at the component level.
These changes resolve issue
6235
Restriction from xs:anySimpleType
The

element is now declared with open
content in the schema for schema documents. This change
addresses issue
5930
defaultOpenContent in the S4SD
The setting
blockDefault="#all"
has been removed
from the schema for schema documents; this change resolves issue
6120
Reconsider blockDefault=#all
Namespace fixup is now explicitly required in some places where
it is needed but was not mentioned before; these changes resolve
issue
6445
Namespace fixup and default namespace
and issue
6465
Namespace fixup and inherited attributes
In the DTD for schema documents
DTD for Schemas (non-normative) (§I)
),
an error has been corrected in the declaration
of the
inheritable
attribute of
the
xs:attribute
element
(resolving issue
11070
DTD for schema documents: inheritable declared as %URIref
).
In the schema for schema documents, an error in the declaration of
xs:group
within the named model group
xs:allModel
has been corrected to make the type of
xs:all
a legal
restriction of its base type and make the schema for schema documents
conformant to this specification. This resolves issue
11092
Error in S4SD: complexType name="all" is not a valid restriction
G.1.17 Clarifications and editorial changes
Clarifications and other
editorial changes:
Each named constraint is now given in a separate section, to
simplify reference to them.
The XML mapping rules have been reorganized to make them
more perspicuous.
The keywords defined by
[IETF RFC 2119]
to
designate different levels of requirement have been

marked up to distinguish more
consistently between cases where their normative
meaning is
intended (e.g.
must
") and cases where the words are used in
its everyday sense without conformance implications (e.g.
"must"). See
Documentation Conventions and Terminology (§1.5)
A note has been added, warning that
the
replace
and
collapse
values
for whitespace handling are not a reliable means of
neutralizing the effects of word-wrapping and pretty-printing
of natural-language data and should not be used for that
purpose.
Several minor corrections and
clarifications have been made. The usage of some technical
terminology has been clarified, normalized, and aligned where
appropriate with the usage in
[XML Schema: Datatypes]
. Conditionals using
"if" have been rephrased to use "if and
only if" where appropriate.
The title of the specification has been changed, and the language
defined here is referred to as XSD, not using the name
"XML Schema". This may help reduce confusion between
the language defined here and the broader class of XML schema
languages in general.
Conformance-related language has been reviewed
to avoid confusion between the conformance-related usage of
the verbs
may
must
, and
should
, and other usages.
Various new terms have been defined, and some existing terms have
been redefined, to reduce confusion and improve legibility. In
some cases, existing terms which were felt insufficiently
informative have been replaced by new terms which may be more
useful.
Following the example of XQuery
1.0 and XSLT 2.0, the terms "
implementation-defined
" and
implementation-dependent
" have been defined and the two
concepts distinguished. The appendix contains lists both of
implementation-defined
and of
implementation-dependent
features.
The term "context-determined-declaration" has been
replaced with the term
locally declared type
; this resolves
issue
4690
Editorial: 'context-determined declarations' needs more work
The namespace prefixes used to refer to well known namespaces
have been changed and are now more consistent; this resolves issue
4316
Make sure namespace prefixes are used appropriately throughout
structures
Numerous small changes were made in the interests of clarity,
completeness, consistency, and precision, and to correct
typographical errors. These changes
resolve a number of issues, including:
5140
small editorial changes section 3.3
5148
inconsistent target ns description
5639
when is value V a valid restriction of value Y?
5800
Possibly revise list of required infoset properties
5916
Obsolete editorial note
5917
Typo in 3.1.1
5934
Typo concerning
6011
[schema11] base URI comments
6156
Typo in 3.4.2
6162
allows ##definedSibling
6165
Constraints on XML representation of anyAttribute
6166
Schema Component Model for Wildcards
6167
Attribute Wildcard Intersection
6170
Wildcards and defaultAttributes
6175
Wildcard overlap
6227
Type Derivation OK (simple)
; and
6233
Wrong pointer for [nil] PSVI property
Discussions of global components now
take into account
(addresses
issue
5918
Top level declarations
).
The usage of "
validation
",
assessment
", and related terms has been clarified
and made more consistent.
It has been clarified that fields of
identity constraint definitions can have complex types with simple
content.
The text concerning
xsi:type
attributes
and their effect has been clarified in
Element Locally Valid (Element) (§3.3.4.3)
. In particular, the
revisions attempt to make clearer just what happens
in cases where the
xsi:type
attribute in the document instance cannot be used
(because the type named is unknown, or otherwise
not usable). This resolves issue
11219 Editorial revision of Element Locally Valid (Element)
The text has been revised to make clearer that
declarations enclosed in an
xs:override
element
are handled using the
elementFormDefault
and
other schema-document-level defaults from the schema document
being overridden, not the schema document containing the
xs:override
element. This resolves issue
10652
xs:override and document-level defaults
The constraints forbidding the use of special types as
members of unions and item types for lists have been reformulated
as part of the definition of the simple type definition component.
This resolves issue
11103
Note in section 2.4.1 (Special datatypes as members of a union)
The treatment of elements in the Schema namespace occurring
within

elements has been clarified:
Such elements do not participate in the mapping
from XML representations to components as defined in this
specification (
The Mapping between XML Representations and
Components (§3.1.3)
The Annotation Schema Component (§3.15.1)
).
Such elements are not required to be valid or to
satisfy the XML Representation rules as a condition of
conformance for a schema document (
Conformance (§2.4)
The Annotation Schema Component (§3.15.1)
).
If such elements are invalid, the effect on
schema component construction is
implementation-defined
The Annotation Schema Component (§3.15.1)
Checklist of implementation-defined features (§E.1)
).
This change resolves issue
10125
Validation of the content of xs:annotation
A note has been added to the discussion of

elements to make it easier to
see how processors are expected to handle cycles in
references from one schema document to another.
This change resolves issue
12184 Circularity in xs:override
G.2 Issues not resolved
It may be useful
to mention some points
where possible changes to the
specification have been discussed, but on which no changes have,
in the end, been made. In some cases, this resulted from the
XML Schema Working Group's determination that no change was
desirable; in other cases, there was no consensus on the
desirability of change, or no consensus on what change should
be made.
As noted above, some restrictions on
all
groups have
been relaxed;
all
groups, however, must still be
top-level groups; they are not allowed to appear within
sequences or choice groups.
The namespace-related properties of the basic infoset are
fixed up
when
attributes with qualified names are assigned default values.
Other kinds of infoset fixup, however, are still not performed.
Attributes of type
ID
IDREF
IDREFS
, and
NOTATION
do not have
the same effect on the base infoset as they do if declared
in a DTD. (An infoset-to-infoset transformation can be
used to migrate the appropriate information into the base
infoset.)
Some existing implementations (and specifications) assume that
elements of type
xs:ID
uniquely identify themselves,
instead of uniquely identifying their parent. This version of
this specification reaffirms the existing rule, which is that
elements and attributes of type
xs:ID
uniquely
identify the parent element of the ID attribute or element.
The identity of components is still underspecified (although
a number of points have been clarified, e.g. by the specification
of the {scope} property), with the
result that some schemas can be interpreted either as conformant
or as non-conformant, depending on the interpretation of
the specification's appeals to component identity.
The constraint
Element Declarations Consistent (§3.8.6.3)
has been recast, but not at the higher level of abstraction
originally required and expected.
The account of schema composition given here has not
eliminated all the uncertainties present in XSD 1.0;
edge cases remain which different conformant implementations
will treat differently.
A systematic tabulation of error conditions and definition of
a new system of error codes was originally foreseen for XSD
1.1, but has not been completed for inclusion here. No further work in this area is
currently anticipated.
H Glossary (non-normative)
The listing below is for the benefit of readers of a printed version of this
document: it collects together all the definitions which appear in the
document above.
L(D)
For any
Element Declaration
, the language
accepted
by
is the set of all sequences of
length 1 whose sole member is an element information item which
matches
L(W)
For any
Wildcard
, the language
accepted
by
is the set of all sequences of
length 1 whose sole member is an element information item which
matches
NCName
An
NCName
is
a name with no colon, as defined in
[XML Namespaces 1.1]
. When used in connection with the XML
representation of schema components in this specification, this refers
to the simple type
NCName
as defined in
[XML Schema: Datatypes]
QName
QName
is a
name with an optional namespace qualification, as defined in
[XML Namespaces 1.1]
. When used in connection with the XML
representation of schema components or references to them, this refers
to the simple type
QName
as defined in
[XML Schema: Datatypes]
Schema Component Constraint
Constraints on the schema components themselves,
i.e. conditions components
must
satisfy to be components at
all. They are located

in the sixth sub-section of the per-component
sections of
Schema Component Details (§3)
and tabulated in
Schema Component Constraints (§B.4)
Schema Information Set Contribution
Augmentations to
post-schema-validation infoset
s expressed by schema
components, which follow as a consequence of
assessment
They are 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 (§B.2)
Schema Representation Constraint
Constraints on the representation of schema
components in XML beyond those which are expressed in
Schema for Schema Documents (Structures) (normative) (§A)
They are located
in the
third sub-section of the per-component sections of
Schema Component Details (§3)
and tabulated in
Schema Representation Constraints (§B.3)
Type Definition Hierarchy
Except for
xs:anyType
, every
type definition
is, by construction,
either a
restriction
or an
extension
of some
other type definition. The exception
xs:anyType
is a
restriction
of itself.
With the exception of the loop on
xs:anyType
, the
graph of these relationships forms
a tree known as the
Type Definition
Hierarchy
with
xs:anyType
as its
root
Validation Rules
Contributions to
validation
associated with schema
components. They are located

in the fourth sub-section of the
per-component sections of
Schema Component Details (§3)
and
tabulated in
Validation Rules (§B.1)
Web-aware
Web-aware
processors are
network-enabled processors which are not only
general-purpose
but
which additionally
must
be capable of accessing schema
documents from the World Wide Web as described in
Representation of Schemas on the World Wide Web (§2.8)
and
How schema definitions are located on the Web (§4.3.2)
XSD schema
An
XSD schema
is a set of
schema components
absent
Throughout this
specification, the term
absent
is used as a
distinguished property value denoting absence
accept
A model group
is said to
accept
or
recognize
the members of
).
accept
A particle
is said to
accept
or
recognize
the members of
). Similarly, a term
accepts
or
recognizes
the members
of
).
actual value
With reference to any
string, interpreted as denoting
an instance of a given datatype, the term
actual value
denotes the value to which the
lexical mapping
of that datatype maps the string.
ancestor
The
ancestors
of a
type definition
are its
{base type definition}
and the
ancestors
of its
{base type definition}
annotation mapping
The
annotation
mapping
of a set of element information items
ES
is a sequence of annotations
AS
, with the following properties:
For every

element information item among the
[children]
of any element information item in
ES
, there
is a corresponding
Annotation
component in
AS
Note:
As noted above,
the
{attributes}
property of
each
Annotation
component includes
all
the attribute information items on the

element itself, on the
XML element which represents (and maps to) the
component being annotated, and on any intervening
XML elements, if those attribute information items
have
[namespace name]
different from the XSD namespace.
If any element information item
in
ES
has any attribute information items
such that
all
of the following are true:
2.1
is in
[attributes]
2.2
[namespace name]
is present and not the XSD namespace.
2.3
is not included in the
[attributes]
property
of any annotation component described in
clause
then for each such
, an
Annotation
component
will appear in
AS
, with
{application information}
and
{user information}
each being the empty sequence and
{attributes}
containing all and only those attribute information
items
among
[attributes]
AS
contains no other
Annotation
components.
annotation mapping
The
annotation
mapping
of a single element information item is the
annotation mapping
of the singleton set containing that
element.
anyAtomicType
There is a further special datatype
called
anyAtomicType
, a
restriction
of
xs:anySimpleType
, which is the
base type definition
of all the primitive
datatypes.
anySimpleType
special
restriction
of
xs:anyType
, whose name is
anySimpleType
in the
XSD namespace, is the root of the
Type Definition Hierarchy
for all simple type
definitions.
xs:anySimpleType
has a lexical space containing
all sequences of characters in the Universal Character
Set (UCS) and a value space containing all
atomic values
and all finite-length lists of
atomic values
assessment
the word
assessment
is used to refer to the overall process of local validation,
recursive determination of
validation outcome, and infoset augmentation, i.e. as a short form for
schema-validity assessment
assessor
schema-validity
assessor
(or just
assessor
is a processor which performs full or partial
schema-validity assessment
of an XML instance document,
element information item, or attribute information item,
with
reference to a conforming schema, and provides access to the
entirety of the resulting
post-schema-validation infoset
The means by which an
assessor
provides
access to the
post-schema-validation infoset
is
implementation-defined
attributed to
During
validation
of an element
information item against its (complex)
governing type definition
associations
between element and attribute information items among the
[children]
and
[attributes]
on the one hand, and the attribute uses,
attribute wildcard, particles
and open content property record on the other, are
established. The element or attribute information item is
attributed to
the corresponding component.
automatically known
A type about which a processor possesses prior knowledge, and
which the processor can support without any declaration of the
type being supplied by the user, is said to be
automatically known
to the processor.
base particle
Let the
base particle
be
the particle of the
{content type}
of the
{base type definition}
base information set properties
By
base information set properties
are meant the properties listed in
Required Information Set Items and Properties (normative) (§D)
base type definition
The type definition used as the basis
for an
extension
or
restriction
is
known as the
base type definition
of that
definition
basic particle
basic
particle
is a
Particle
whose
{term}
is a
basic term
basic term
basic term
is an
Element Declaration
or a
Wildcard
compete
Two
Particles
and
contained in some
Particle
compete
with each other if and only if some sequence
of element information items has two
paths
in
which are
identical except that one path has
as its last item and the other
has
competing paths
Two
(or more)
paths
of a sequence
in a
Particle
are
competing paths
if and only if
they are identical except for their final items, which
differ.
complete path
For
a model group
and a sequence
in
), the path
of
in
is a
complete path
; prefixes of
complete paths which are themselves not complete paths
are
incomplete paths
component name
Declarations
and definitions
may
and in
some cases
must
have and be identified by
name
s, which are
NCNames as defined by
[XML Namespaces 1.1]
conditionally selects
Given a
Type Table
and an element
information item
conditionally selects
type
for
in
the following way. The
{test}
expressions in
's
{alternatives}
are evaluated, in order,
until one of the
Type Alternative
successfully selects
a type definition for
, or until
all have been tried without success. If any
Type Alternative
successfully selects
a type definition, none of the following
Type Alternative
s are tried. Then the type
conditionally
selected
for
by
is
as described in

the appropriate
case
among the following:
If at least one
Type Alternative
in
{alternatives}
successfully selects
a type definition for
, then
is the type definition selected by the first such
Type Alternative
If no
Type Alternative
in
{alternatives}
successfully selects
a type definition, then
is
{default type definition}
{type definition}
constructed
Datatypes can be
constructed
from other datatypes by
restricting
the value space or lexical space of a
{base type definition}
using zero or more
Constraining Facet
s, by specifying the new datatype as a
list
of items of some
{item type definition}
or by defining it as a
union
of some specified sequence of
{member type definitions}
contains
A model group
contains
the components which it either
directly contains
or
indirectly contains
contains
A particle
contains
the components which it either
directly contains
or
indirectly contains
content model
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
context-determined declaration
During
validation
, associations between
element and attribute information items among the
[children]
and
[attributes]
on the one hand, and element and attribute declarations on
the other, are also established. When an item is
attributed
to an
element particle
, then it is associated with the declaration which is the
{term}
of the particle. Similarly, when an
attribute information item is
attributed to
an
Attribute Use
then the item is associated with the
{attribute declaration}
of that
Attribute Use
. Such declarations are called the
context-determined declarations
declaration
declaration
components are associated by (qualified) name to information items
being
validated
declared entity name
A string is a
declared entity name
if and only if it is equal to the
[name]
of some unparsed entity information item in the value of the
[unparsedEntities]
property of the document information item at the root of the infoset
containing the element or attribute information item whose
normalized value
the string is.
default binding
When a sequence of element information items
ES
is
locally valid
with respect to a
Content Type
CT
or when a set of attribute information items
AS
satisfies clause
and clause
of
Element Locally Valid (Complex Type) (§3.4.4.2)
with respect to a
Complex Type Definition
there is a (partial) functional mapping from
the element information items
in the sequence
ES
or the attribute information items in
AS
to a
default binding
for the item,
where the default binding is
an
Element Declaration
an
Attribute Use
or one
of the keywords
strict
lax
, or
skip
as follows:
When the item has a
governing element declaration
, the
default binding is that
Element Declaration
When the item has a
governing attribute declaration
and it is
attributed
to an
Attribute Use
, the default binding is
that
Attribute Use
When the item has a
governing attribute declaration
and it is
attributed
to an
attribute wildcard, the default binding is
an
Attribute Use
whose
{attribute declaration}
is the
governing attribute declaration
whose
{value constraint}
is
absent
, and
whose
{inheritable}
is the
governing attribute declaration
's
{inheritable}
(the other properties in the
Attribute Use
are not relevant).
When the item is
attributed
to a
strict
wildcard particle
or attribute wildcard
or an
Open Content
with a
strict
Wildcard
and
it does not have a
governing element declaration
or
governing attribute declaration
, then
the default binding is the keyword
strict
When the item is
attributed
to a
lax
wildcard particle
or attribute wildcard
or an
Open Content
with a
lax
Wildcard
and
it does not have a
governing element declaration
or
governing attribute declaration
, then
the default binding is

the keyword
lax
When the item is
attributed
to a
skip
wildcard particle
or attribute wildcard
or an
Open Content
with a
skip
Wildcard
then
the default binding is the keyword
skip
defaulted attribute
defaulted attribute
belonging to an element information item
governed by
a complex type
is any
Attribute Use
for which
all
of the following are true:
is a member of
{attribute uses}
{required}
false
's
effective value constraint
is not
absent
{attribute declaration}
is not one
of the
Attribute Declaration
s from
Built-in Attribute Declarations (§3.2.7)
{attribute declaration}
does not match
any of the
attribute information items in
[attributes]
as per clause
2.1
of
Element Locally Valid (Complex Type) (§3.4.4.2)
above.
definition
definition
components define internal
schema components that can be used in other schema
components
definition of anyType
A special complex type
definition, (referred to in earlier versions of this
specification as 'the ur-type definition') whose
name is
anyType
in the XSD namespace, is
present in each
XSD schema
. The
definition of
anyType
serves as default
type definition for element declarations whose XML
representation does not specify one
derived
If a type definition
can reach a type definition
by following
its base type definition chain, then
is said to be
derived
from
directly contains
A model group
directly contains
the particles in the value of its
{particles}
property.
directly contains
A particle
directly contains
the component which is the value of its
{term}
property.
effective value constraint
The
effective value constraint
of an attribute use
is
{value constraint}
, if present, otherwise
{attribute declaration}
{value constraint}
, if present,
otherwise
the
effective value constraint
is
absent
element particle
An
element particle
is a
Particle
whose
{term}
is an
Element Declaration
element substitution group
Through the
mechanism of
element substitution
groups
, XSD provides a more powerful model
than DTDs do
supporting substitution of one named element for
another
equivalent type alternative
Any
Type Alternative
is
equivalent
to itself.
Otherwise, any
Type Alternative
T1
is
equivalent
to a different
Type Alternative
T2
if and only if
T1
{test}
and
T2
{test}
are true for the same
set of input element information items
and
T1
{type definition}
and
T2
{type definition}
accept
the same set of input information items as valid.
In the general case, equivalence and non-equivalence
can be difficult to establish.
It is
implementation-defined
under just what conditions a
processor detects that two type
alternatives are equivalent, but all
processors
must
detect
T1
and
T2
as
equivalent if
all
of the following are true:
T1
{test}
{namespace bindings}
and
T2
{test}
{namespace bindings}
have the same number of
Namespace Binding
s, and for each entry in
T1
{test}
{namespace bindings}
there is a corresponding entry in
T2
{test}
{namespace bindings}
with the same
{prefix}
and
{namespace}
T1
{test}
{default namespace}
and
T2
{test}
{default namespace}
either are both
absent
or have the same value.
T1
{test}
{base URI}
and
T2
{test}
{base URI}
either are both
absent
or have the same value.
T1
{test}
{expression}
and
T2
{test}
{expression}
have the same value.
T1
{type definition}
and
T2
{type definition}
are the same type definition.
A processor
may
treat two type alternatives as
non-equivalent if they do not satisfy the conditions just
given and the processor does not detect that they
are nonetheless equivalent.
equivalent type table
Type Table
T1
is
equivalent
to a
Type Table
T2
if and only if
all
of the following are true:
T1
{alternatives}
has the same length as
T2
{alternatives}
and their
corresponding entries are
equivalent
T1
{default type definition}
and
T2
{default type definition}
are
equivalent
extension
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
field subset of XPath
The subset of XPath defined in
Fields Value OK (§3.11.6.3)
is called the
field subset
of XPath.
final
the complex type is said to be
final
, because no
further
derivations
are possible
full instance subset
The
full instance subset
of the PSVI includes almost all
properties defined by this specification as applying to
element and attribute information items, but excludes
schema components. It
consists of
the
instance-validity subset
plus the following properties for elements:
general-purpose
general-purpose
processor
is a
validator
or
assessor
which accepts schemas represented in the
form of XML documents as described in
Layer 2: Schema Documents, Namespaces and Composition (§4.2)
governing
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.
governing attribute declaration
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:
A declaration which was stipulated by the processor (see
Assessing Schema-Validity (§5.2)
).
Its
context-determined declaration
A declaration
resolved
to by its
[local
name]
and
[namespace
name]
provided the attribute
is not
skipped
and the processor has not
stipulated a type definition at the start of
assessment
If none of these applies, the attribute
has no
governing attribute declaration
(or, in equivalent words, the
governing attribute declaration
is
absent
).
governing element declaration
The
governing element declaration
of
an element information item
in a given schema-validity
assessment
episode, is the first of the following
which applies:
declaration stipulated by the processor (see
Assessing Schema-Validity (§5.2)
).
's
context-determined
declaration
A declaration
resolved
to by
's
[local name]
and
[namespace
name]
, provided that
is
attributed
either to a
strict
wildcard particle
or to a
lax
wildcard particle
A declaration
resolved
to by
's
[local
name]
and
[namespace
name]
, provided that
none
of the following is true:
4.1
is
skipped
4.2
the
processor has stipulated a type definition for
4.3
non-absent
locally declared type
exists for
If none of these
applies,
has
no
governing element declaration
(or, in equivalent words,
's
governing element declaration
is
absent
).
governing type 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:
An
instance-specified type definition
which
overrides
a type
definition stipulated by the processor (see
Assessing Schema-Validity (§5.2)
).
A type definition stipulated by the processor (see
Assessing Schema-Validity (§5.2)
).
An
instance-specified type definition
which
overrides
the
selected type definition
of
The
selected type definition
of
The value
absent
if
is
skipped
An
instance-specified type definition
which
overrides
the
locally declared type
The
locally declared type
An
instance-specified type definition
If none of these
applies,
there is no
governing type definition
(or, in equivalent words, it is
absent
).
governing type definition
The
governing type definition
of an
attribute, in a given schema-validity
assessment
episode, is
the first of the following which applies:
A type definition stipulated by the processor (see
Assessing Schema-Validity (§5.2)
).
The
{type definition}
of the
governing attribute declaration
If neither of these applies, there is no
governing type definition
(or, in equivalent words, it is
absent
).
grouping
grouping
of a sequence is a set of sub-sequences, some or
all of which may be empty, such that each member of the original
sequence appears once and only once in one of the sub-sequences and
all members of all sub-sequences are in the original
sequence.
implementation-defined
An
implementation-defined
feature or behavior
may
vary among processors conforming to this
specification; the precise behavior is not specified by
this specification but
must
be specified by the
implementor for each particular conforming implementation.
implementation-dependent
An
implementation-dependent
feature or behavior
may
vary among processors conforming to this
specification; the precise behavior is not specified by
this or any other W3C specification
and is not required to be specified by the implementor
for any particular implementation.
implicitly contains
A list
of particles
implicitly contains
an element declaration if and only if a
member of the list contains that
element declaration in its
substitution group
indirectly contains
A model group
indirectly contains
the particles, groups, wildcards, and
element declarations which are
contained
by the particles it
directly contains
indirectly contains
A particle
indirectly contains
the particles, groups, wildcards, and
element declarations which are contained by the value of its
{term}
property.
initial value
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
instance-specified type definition
An
instance-specified type definition
is a type definition associated with an element information
item in the following way:
Among the element's attribute information items is one
named
xsi:type
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)
The
actual value
(a
QName
resolves
to a type definition.
It is this type definition which is the
instance-specified type definition
instance-validity subset
The
instance-validity subset
of the PSVI consists of
the
root-validity subset
, plus the following properties on elements,
wherever applicable:
item isomorphic to a component
by an
item isomorphic
to a component is meant
an information item whose type is equivalent to the component's, with
one property per property of the component, with the same name, and
value either the same atomic value, or an information item
corresponding in the same way to its component value, recursively, as
necessary
laxly assessed
The schema validity of an element information item
is
said to be
laxly assessed
if and only if
both
of the following are true:
has neither a
governing element declaration
nor a
governing type definition
is locally
validated
with respect to
xs:anyType
as defined in
Element Locally Valid (Type) (§3.3.4.4)
, and the schema-validity of
's
[attributes]
and
[children]
is assessed as described in clause
and clause
of
Schema-Validity Assessment (Element) (§3.3.4.6)
locally declared type
Every
Complex Type Definition
determines a partial functional mapping from
element or attribute
information items (and their
expanded names
) to type
definitions. This mapping serves as a
locally declared type
for elements
and attributes which are allowed by
the
Complex Type Definition
locally declared type
For a given
Complex Type Definition
CTD
and a given attribute
information item
, the
locally declared type
of
within
CTD
is
the appropriate
case
among the following:
If
CTD
is
xs:anyType
then
absent
If
has the same
expanded name
as some
attribute declaration
which is the
{attribute declaration}
of some
Attribute Use
contained by
CTD
's
{attribute uses}
then
the
{type definition}
of
otherwise
the
locally declared type
of
within
CTD
{base type definition}
locally declared type
For a given
Complex Type Definition
CTD
and a given element information item
, the
locally declared type
of
within
CTD
is
the appropriate
case
among the following:
If
CTD
is
xs:anyType
then
absent
If
has the same
expanded name
as
some element declaration
which is
contained
by
CTD
's
content model, whether
directly
indirectly
, or
implicitly
then
the
declared
{type definition}
of
otherwise
the
locally declared type
of
within
CTD
{base type definition}
locally valid
A sequence of element information items is
locally valid
with
respect to a
Content Type
if and only if it satisfies
Element Sequence Locally Valid (Complex Content) (§3.4.4.3)
with respect to that
Content Type
locally valid
A sequence
of
element information items is
locally valid
against
a particle
if and only if
has a
validation-path
in
. The set of all such
sequences is written
).
match
An element information item
matches
an
Element Declaration
if and only if
one
of the following is true:
and
have the same
expanded name
The
expanded name
of
resolves
to an element
declaration
which is
substitutable
for
match
An
expanded name
matches
an
NCName
and
a namespace name
NS
(or, equivalently,
and
NS
match
if and only if all of the following
are true:
The local name of
is identical to
Either the namespace name of
is identical to
NS
or else
has no namespace name (
is an unqualified
name) and
NS
is
absent
match
An element information item
matches
Wildcard
(or a
wildcard particle
whose
{term}
is
if and only if
is locally
valid
with respect to
, as defined in the validation rule
Item Valid (Wildcard) (§3.10.4.1)
match
Two namespace
names
and
are said to
match
if and only if they are identical or both are
absent
namespace fixup
When
default values are supplied for attributes,
namespace fixup
may be required, to ensure that the
post-schema-validation infoset
includes
the namespace bindings needed and maintains the consistency
of the namespace information in the infoset. To perform
namespace fixup on an element information item
for
a namespace
If the
[in-scope namespaces]
of
binds a prefix to
, no
namespace fixup is needed; the properties of
are not changed.
Otherwise, first select some prefix
which is not bound by
the
[in-scope namespaces]
of
(the choice of
prefix
is
implementation-dependent
).
Add an entry to the
[in-scope namespaces]
of
binding
to
Add a namespace attribute to the
[namespace attributes]
of
Maintain the consistency of the information set by adjusting
the namespace bindings on the descendants of
. This may
be done in either of two ways:
5.1
Add the binding of
to
to the
[in-scope namespaces]
of all
descendants of
, except where that binding is overridden
by another binding for
5.2
Add to the
[namespace attributes]
of each child of
a namespace
attribute which undeclares the binding for
(i.e. a
namespace attribute for prefix
whose
normalized value
is the empty string), unless that child already has a
namespace declaration for prefix
Note that this approach is possible
only if
[XML Namespaces 1.1]
is in use,
rather than
[Namespaces in XML 1.0]
The choice between the two methods of maintaining
consistency in the information set is
implementation-dependent
nilled
An
element information item
is
nilled
with respect to some element declaration
if and only if
all
of the following are true:
has
xsi:nil
true
{nillable}
true
normalized value
The
normalized value
of an element or attribute
information item is an
initial value
which has been normalized
according to the value of the
whiteSpace facet
, and the values of any other
pre-lexical facets
, associated with the simple type definition used
in its
validation
. The keywords for
whitespace normalization have the following meanings:
preserve
No normalization is done, the
whitespace-normalized value
is the
initial value
replace
All occurrences of
#x9
(tab),
#xA
(line feed) and
#xD
(carriage
return) are replaced with
#x20
(space).
collapse
Subsequent to the replacements specified above under
replace
, contiguous sequences of
#x20
s are collapsed to a single
#x20
, and initial and/or final
#x20
s are deleted.
Similarly, the
normalized value
of any string with respect to a
given simple type definition is the string resulting from
normalization using the
whiteSpace facet
and any other
pre-lexical facets
, associated with that simple type definition.
overlay
Given two sets of facets
and
the result of
overlaying
with
is the set of facets
for which
all
of the following are true:
Every facet in
is in
Every facet in
is in
unless

it is of the same kind as some
facet in
in which case it is not included in
Every facet in
is required by clause
or clause
above.
override
An
instance-specified type definition
is said to
override
another type definition
if and only
if all of the following are true:
is the
instance-specified type definition
on some element information item
. A
governing element declaration
may or may not be known for
is
validly substitutable
for
, subject to the blocking keywords of
the
{disallowed substitutions}
of
's
governing element declaration
, if any, or
validly
substitutable without limitation
for
(if no
governing element declaration
is known).
Note:
Typically,
would be the
governing type definition
for
if it were not
overridden. (This will be the case if
was stipulated by
the processor, as described in
Assessing Schema-Validity (§5.2)
, or
has a
governing element declaration
and
is its declared type, or
is the
locally declared type
of
.)
partition
partition
of a sequence is a sequence of sub-sequences,
some or all of which
may
be empty, such that concatenating all
the sub-sequences yields the original sequence
path
When a sequence
of element information
items is checked against a model group
, the sequence of
basic particles
which the items of
match, in order, is a
path
of
in
. For a given
and
, the
path of
in
is not necessarily unique.
Detailed rules for the matching, and thus for the construction of
paths, are given in
Language Recognition by Groups (§3.8.4.1)
and
Principles of Validation against Particles (§3.9.4.1)
post-schema-validation infoset
We refer to the augmented infoset which
results from conformant processing as defined in this
specification as the
post-schema-validation
infoset
, or
PSVI
potentially inherited
An attribute
information item
, whether explicitly specified in the input
information set or defaulted as described in
Attribute Default Value (§3.4.5.1)
, is
potentially inherited
by
an element information item
if and only if
all
of the following are true:
is among the
[attributes]
of one of
's ancestors.
and
have the same
[validation context]
One
of the following is true:
3.1
is
attributed to
an
Attribute Use
whose
{inheritable}
true
3.2
is
not
attributed to
any
Attribute Use
but
has a
governing attribute declaration
whose
{inheritable}
true
present
A property value
which is not
absent
is
present
property record
a property
value may itself be a collection of named values, which we call
property record
resolve
QName
in a schema document
resolves to
a component in a schema if and only if in the
context of that schema the QName and the component together satisfy the rule
QName resolution (Schema Document) (§3.17.6.2)
. A
QName
in
an input document, or a pair consisting of a local name and a namespace name,
resolves to
a component in a schema if and only if in the
context of that schema the QName (or the name + namespace pair) and the
component together satisfy the rule
QName resolution (Instance) (§3.17.6.3)
restriction
type defined with the same constraints as its
base type definition
, or with more, is
said to be a
restriction
root-validity subset
The
root-validity subset
of the PSVI consists of the
following properties of the
validation root
schema component
Schema
component
is the generic term for the building blocks
that make up the abstract data model
of the schema.
schema document
A document in this
form (i.e. a

element information item)
is a
schema document
schema-validity assessment
As it is used in this specification, the
term
schema-validity assessment
has three aspects:
Determining local schema-validity, that is
whether an element or attribute information item satisfies
the constraints embodied in the
relevant components of an
XSD schema
(specifically the
governing
element or attribute declaration and/or
governing
type definition);
Determining an
overall validation outcome for the item
by combining local schema-validity with
the results of schema-validity assessments of its
descendants, if any; and
Determining the appropriate
augmentations to the infoset (and, if desired, exposing them
to downstream applications in some way, to record this
outcome).
selected type definition
The
selected type
definition
of an element information item
is a
type definition associated with
in the following way. Let
be the
governing element declaration
of
. Then:
If
has a
{type table}
, then
is the type
conditionally selected
for
by
{type table}
If
has no
{type table}
, then
is
{type definition}
If
has no
governing element declaration
, then
has no selected
type definition.
selector subset of XPath
The subset of XPath defined in
Selector Value OK (§3.11.6.2)
is called the
selector subset
of XPath.
skipped
An element or attribute information item is
skipped
if it
is
attributed
to a
skip
wildcard or if one of its ancestor
elements is.
special-purpose
schema processor which is not a
general-purpose
processor is a
special-purpose
processor.
strictly assessed
An element
information item
is said to be
strictly assessed
if and only if
all
of the following are true:
One
of the following is true:
1.1
All
of the following are true:
1.1.1
non-absent
element declaration
is known for
, namely its
governing
declaration.
1.1.2
's local
validity
with
respect to that declaration has been evaluated as per
Element Locally Valid (Element) (§3.3.4.3)
1.1.3
If that evaluation involved the evaluation of
Element Locally Valid (Type) (§3.3.4.4)
, clause
thereof is satisfied.
1.2
All
of the following are true:
1.2.1
does not have a
governing element declaration
1.2.2
non-absent
type definition is known for
, namely its
governing type definition
1.2.3
The local
validity
of
with respect to its
governing type definition
has been evaluated as
per
Element Locally Valid (Type) (§3.3.4.4)
For each of the attribute information items among
[attributes]
the appropriate
case
among the following is true:
2.1
If
the attribute has a
governing attribute declaration
then
its schema-validity is assessed with respect to that
declaration, as defined in
Schema-Validity Assessment (Attribute) (§3.2.4.3)
2.2
otherwise
its schema-validity is not assessed.
For each of the element information items among its
[children]
the appropriate
case
among the following is true:
3.1
If
the child has a
governing element declaration
or a
governing type definition
then
its schema-validity is assessed with respect to that
declaration or type definition, as defined in
Schema-Validity Assessment (Element) (§3.3.4.6)
3.2
If
the child is
attributed to
skip
Wildcard
then
its schema-validity is not assessed.
3.3
otherwise
its schema-validity is
laxly assessed
with
respect to
xs:anyType
substitutable
One element declaration is
substitutable
for another if together they satisfy constraint
Substitution Group OK (Transitive) (§3.3.6.3)
substitution group
Every element declaration (call this
HEAD
) in the
{element declarations}
of a schema defines a
substitution
group
, a subset of those
{element declarations}
. An element declaration is in
the
substitution group
of
HEAD
if
and only if it is
substitutable
for
HEAD
successfully selects
Type Alternative
successfully selects
Type Definition
for an
element information item
if and only if
{test}
evaluates to
true
and
{type definition}
symbol space
this specification introduces the term
symbol
space
to denote a collection of names, each of which is
unique with respect to the others
target namespace
Several
kinds of component have a
target namespace
, which
is either
absent
or a
namespace name, also as defined by
[XML Namespaces 1.1]
target set
The
target set
of an

element information
item
contains
all
of the following:
The schema document identified by the
schemaLocation
attribute of
The schema document identified by the
schemaLocation
attribute of any

element information item
in a schema document contained in the
target set
of
The schema document identified by the
schemaLocation
attribute of any

element information item
in a schema document contained in the
target set
of
The
target set
of
contains no other schema documents.
type definition
This specification
uses the phrase
type definition
in cases where no
distinction need be made between simple and complex
types
type-aware subset
The
type-aware subset
of the PSVI consists of the
instance-validity subset
, plus the following
items and properties.
type-aware subset
The
lightweight type-aware subset
of the PSVI provides
the same information as the
type-aware subset
, except that instead of providing
direct access to schema components, it provides only their names and
related information.
typed value
When the
validating type
of an
actual value
is
or is
derived
from a simple type definition
, the value is also
referred to as a
value
user option
A choice left under the control of the user of a processor,
rather than being fixed for all users or uses of the processor.
Statements in this specification that "Processors
may
at user option" behave in a certain way mean that
processors
may
provide mechanisms to allow users
(i.e. invokers of the processor) to enable or disable the
behavior indicated. Processors which do not provide such
user-operable controls
must not
behave in the way indicated.
Processors which do provide such
user-operable controls
must
make it possible for the user
to disable the optional behavior.
Note:
The normal expectation is that the default setting for
such options will be to disable the optional
behavior in question,
enabling it only when the user explicitly requests it. This
is not, however, a requirement of conformance: if the
processor's documentation makes clear that the user can
disable the optional
behavior, then invoking the processor without
requesting that it be disabled can be taken as equivalent to
a request that it be enabled.
It is required,
however, that it in fact be possible for the user to disable the
optional behavior.
Note:
Nothing in this specification constrains the manner
in which processors allow users to control user options.
Command-line options, menu choices in a graphical user
interface, environment variables, alternative call patterns
in an application programming interface, and other
mechanisms may all be taken as providing user options.
valid
Validation
is the process of determining
whether an XML document, an element information item, or an
attribute information item obeys the constraints expressed in a
schema; in the context of XSD, this amounts to calculating the
value of the appropriate item's
[validity]
property.
valid extension
A complex type
is a
valid extension
of its
{base type definition}
if and only if
{derivation method}
extension
and
satisfies the constraint
Derivation Valid (Extension) (§3.4.6.2)
valid restriction
A complex
type definition with
{derivation method}
restriction
is a
valid
restriction
of its
{base type definition}
if and only if the constraint
Derivation Valid (Restriction, Complex) (§3.4.6.3)
is
satisfied
valid restriction
simple type definition
is a
valid restriction
of its
{base type definition}
if and only if
satisfies constraint
Derivation Valid (Restriction, Simple) (§3.16.6.2)
validating type
When a string
is schema-valid with respect to a simple type definition
as defined by
Datatype
Valid
with the corresponding
actual value
The
validating type
of
is
if
is not a union type,
otherwise the validating type is the
basic
member
of
's
transitive
membership
which actually
validated
If the
validating type
of
is a list type
and the
{item type definition}
of
is
, then the
validating type
of an (atomic) item value
occurring in
is
if
is not a union type, otherwise the validating type is the
basic member
of
's
transitive
membership
which actually
validated
the substring in
that corresponds to
validation root
The element or attribute information item at which
assessment
begins is called the
validation root
validation-path
For any sequence
of element
information items and any particle
, a
path
of
in
is a
validation-path
if and only if for each
prefix of the
path
which ends with a
wildcard particle
, the
corresponding prefix of
has no
competing path
which
ends with an
element particle
validator
validator
(or
instance validator
) is a
processor which
validates
an XML instance document against a
conforming schema and distinguishes between valid documents
and others, for one or more of the definitions of validity
root-validity
deep validity
or
uniform validity
defined below in section
Schema-validity and documents (§2.5)
Conforming validators
may
additionally support other
definitions of validity defined in terms of the
post-schema-validation infoset
validly substitutable
A type definition
is
validly substitutable
for another type
subject to a
set of blocking keywords
(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
and
are both complex
type definitions and
is validly derived from
subject to the
blocking keywords in the union of
and
{prohibited substitutions}
as defined in
Type Derivation OK (Complex) (§3.4.6.5)
or
is a complex type definition,
is a
simple type definition, and
is validly
derived
from
subject to the
blocking keywords in
, as defined in
Type Derivation OK (Complex) (§3.4.6.5)
or
is a simple type definition and
is
validly
derived
from
subject to the blocking keywords in
, as defined in
Type Derivation OK (Simple) (§3.16.6.3)
validly substitutable without limitation
If the set of keywords controlling whether
a type
is
validly substitutable
for another type
is the
empty set, then
is said to be
validly
substitutable
for
without limitation
or
absolutely
. The phrase
validly
substitutable
, without mention of any set of blocking
keywords, means "validly substitutable without
limitation".
validly substitutable as a restriction
A type definition
is
validly
substitutable as a restriction
for another type
if
and only if
is
validly substitutable
for
, subject to the
blocking keywords {
extension
list
union
}.
wildcard particle
wildcard particle
is a
Particle
whose
{term}
is a
Wildcard
Wildcard particles may be
referred to as "strict", "lax",
or "skip" particles,
depending on the
{process contents}
property
of their
{term}
xs:error
A special simple type
definition, whose name is
error
in the XSD
namespace, is also present in each
XSD schema
. The
XSD
error
type
has no valid instances. It can be used in any place where
other types are normally used; in particular, it can be used
in conditional type assignment to cause elements which satisfy
certain conditions to be invalid.
I DTD for Schemas (non-normative)
The DTD for schema documents is given below. Note there is
no
implication here that
schema
must
be the root element of a
document.
Independent copies of this material are
available in an undated (mutable) version at
and in a dated (immutable) version at
— the mutable version will be updated with future revisions of
this specification, and the immutable one will not.
Although this DTD is non-normative, any XML document which is
not valid per this DTD, given redefinitions in its internal subset of the
'p' and 's' parameter entities below appropriate to its namespace
declaration of the XSD namespace, is almost certainly not
a valid schema document, with the exception of documents with multiple namespace
prefixes for the XSD namespace itself. Accordingly
authoring
schema documents
using this DTD and DTD-based authoring tools, and
specifying it as the DOCTYPE of documents intended to be
schema documents
and validating them with a validating XML parser, are
sensible development strategies which users are encouraged to adopt
until XSD-based authoring tools and validators are more widely available.
DTD for Schema Documents

%attrDecls;, %assertions;)'>

%xs-datatypes;

(%defaultOpenContent;, (%annotation;)*)?,
((%simpleType; | %complexType;
| %element; | %attribute;
| %attributeGroup; | %group;
| %notation; ),
(%annotation;)*)* )>
targetNamespace %URIref; #IMPLIED
version CDATA #IMPLIED
%nds; %URIref; #FIXED 'http://www.w3.org/2001/XMLSchema'
xmlns CDATA #IMPLIED
finalDefault %complexDerivationSet; ''
blockDefault %blockSet; ''
id ID #IMPLIED
elementFormDefault %formValues; 'unqualified'
attributeFormDefault %formValues; 'unqualified'
defaultAttributes CDATA #IMPLIED
xpathDefaultNamespace CDATA '##local'
xml:lang CDATA #IMPLIED
%schemaAttrs;>

appliesToEmpty (true|false) 'false'
mode (interleave|suffix) 'interleave'
id ID #IMPLIED
%defaultOpenContentAttrs;>

(%simpleContent;|%complexContent;|
%particleAndAttrs;))>

name %NCName; #IMPLIED
id ID #IMPLIED
abstract %boolean; #IMPLIED
final %complexDerivationSet; #IMPLIED
block %complexDerivationSet; #IMPLIED
mixed (true|false) 'false'
defaultAttributesApply %boolean; 'true'
%complexTypeAttrs;>

mixed (true|false) #IMPLIED
id ID #IMPLIED
%complexContentAttrs;>

mode (none|interleave|suffix) 'interleave'
id ID #IMPLIED
%openContentAttrs;>

id ID #IMPLIED
%simpleContentAttrs;>

base %QName; #REQUIRED
id ID #IMPLIED

%extensionAttrs;>

(%alternative;)*,
(%unique; | %key; | %keyref;)*)>


name %NCName; #IMPLIED
id ID #IMPLIED
ref %QName; #IMPLIED
type %QName; #IMPLIED
minOccurs %nonNegativeInteger; #IMPLIED
maxOccurs CDATA #IMPLIED
nillable %boolean; #IMPLIED
substitutionGroup %QName; #IMPLIED
abstract %boolean; #IMPLIED
final %complexDerivationSet; #IMPLIED
block %blockSet; #IMPLIED
default CDATA #IMPLIED
fixed CDATA #IMPLIED
form %formValues; #IMPLIED
targetNamespace %URIref; #IMPLIED
%elementAttrs;>

(%simpleType; | %complexType;)?) >
test CDATA #IMPLIED
type %QName; #IMPLIED
xpathDefaultNamespace CDATA #IMPLIED
id ID #IMPLIED >

name %NCName; #IMPLIED
ref %QName; #IMPLIED
minOccurs %nonNegativeInteger; #IMPLIED
maxOccurs CDATA #IMPLIED
id ID #IMPLIED
%groupAttrs;>

minOccurs (0 | 1) #IMPLIED
maxOccurs (0 | 1) #IMPLIED
id ID #IMPLIED
%allAttrs;>

minOccurs %nonNegativeInteger; #IMPLIED
maxOccurs CDATA #IMPLIED
id ID #IMPLIED
%choiceAttrs;>

minOccurs %nonNegativeInteger; #IMPLIED
maxOccurs CDATA #IMPLIED
id ID #IMPLIED
%sequenceAttrs;>

namespace CDATA #IMPLIED
notNamespace CDATA #IMPLIED
notQName CDATA ''
processContents (skip|lax|strict) 'strict'
minOccurs %nonNegativeInteger; '1'
maxOccurs CDATA '1'
id ID #IMPLIED
%anyAttrs;>

namespace CDATA #IMPLIED
notNamespace CDATA #IMPLIED
notQName CDATA ''
processContents (skip|lax|strict) 'strict'
id ID #IMPLIED
%anyAttributeAttrs;>

name %NCName; #IMPLIED
id ID #IMPLIED
ref %QName; #IMPLIED
type %QName; #IMPLIED
use (prohibited|optional|required) #IMPLIED
default CDATA #IMPLIED
fixed CDATA #IMPLIED
form %formValues; #IMPLIED
targetNamespace %URIref; #IMPLIED
inheritable %boolean; #IMPLIED
%attributeAttrs;>

(%attribute; | %attributeGroup;)*,
(%anyAttribute;)?) >
name %NCName; #IMPLIED
id ID #IMPLIED
ref %QName; #IMPLIED
%attributeGroupAttrs;>

name %NCName; #IMPLIED
ref %QName; #IMPLIED
id ID #IMPLIED
%uniqueAttrs;>

name %NCName; #IMPLIED
ref %QName; #IMPLIED
id ID #IMPLIED
%keyAttrs;>

name %NCName; #IMPLIED
ref %QName; #IMPLIED
refer %QName; #IMPLIED
id ID #IMPLIED
%keyrefAttrs;>

xpath %XPathExpr; #REQUIRED
xpathDefaultNamespace CDATA #IMPLIED
id ID #IMPLIED
%selectorAttrs;>

xpath %XPathExpr; #REQUIRED
xpathDefaultNamespace CDATA #IMPLIED
id ID #IMPLIED
%fieldAttrs;>

test %XPathExpr; #REQUIRED
id ID #IMPLIED
xpathDefaultNamespace CDATA #IMPLIED
%assertAttrs;>

schemaLocation %URIref; #REQUIRED
id ID #IMPLIED
%includeAttrs;>

namespace %URIref; #IMPLIED
schemaLocation %URIref; #IMPLIED
id ID #IMPLIED
%importAttrs;>

%attributeGroup; | %group;)*>
schemaLocation %URIref; #REQUIRED
id ID #IMPLIED
%redefineAttrs;>

((%simpleType; | %complexType; | %group; | %attributeGroup;) |
%element; | %attribute; | %notation;)*)>
schemaLocation %URIref; #REQUIRED
id ID #IMPLIED
%overrideAttrs;>

name %NCName; #REQUIRED
id ID #IMPLIED
public CDATA #REQUIRED
system %URIref; #IMPLIED
%notationAttrs;>

source %URIref; #IMPLIED
id ID #IMPLIED
%appinfoAttrs;>

source %URIref; #IMPLIED
id ID #IMPLIED
xml:lang CDATA #IMPLIED
%documentationAttrs;>

'structures' 'http://www.w3.org/2001/XMLSchema.xsd' >
'REC-xml-1998-0210' 'http://www.w3.org/TR/1998/REC-xml-19980210' >

J Analysis of the Unique Particle Attribution Constraint (non-normative)
A specification of the import of
Unique Particle Attribution (§3.8.6.4)
which does
not appeal to a processing model is difficult. What follows is intended as
guidance, without claiming to be complete.
[Definition:]
Two non-group
particles
overlap
if
They are both element declaration particles whose declarations have the
same
expanded name
or
They are both element declaration particles

and one of them has the same
expanded name
as
an element declaration in the
other's
substitution group
or
They are both
global
element declaration particles and their
substitution groups
contain the same
element declaration.
or
They are both wildcards, and any one of the following is true of the wildcard intersection of their
{namespace constraint}
s as defined
in
Attribute Wildcard Intersection (§3.10.6.4)
It has
{variety}
any
It has
{variety}
not
It has
{variety}
enumeration
and
{namespaces}
≠ the empty set.
A content model will violate the unique attribution constraint if it
contains two particles which
overlap
and which either
are both in the
{particles}
of a
choice
or
all
group
or
may
validate
adjacent information items and the first has
{min occurs}
less than
{max occurs}
Two particles may
validate
adjacent information items if they are
separated by at most epsilon transitions in the most obvious transcription of a
content model into a finite-state automaton.
A precise formulation of this constraint can also be offered in terms of
operations on finite-state automaton: transcribe the content model into an
automaton in the usual way using epsilon transitions for optionality and
unbounded maxOccurs, unfolding other numeric occurrence ranges and treating the heads of
substitution groups
as if
they were choices over all elements in the group,
but
using not
element QNames as transition labels, but rather pairs of element QNames and
positions in the model. Determinize this automaton, treating wildcard transitions as
if
they were distinct from all other edge labels for the purposes of the
determinization. Now replace all
QName+position transition labels with the element QNames alone. If the result has any states
with two or more identical-QName-labeled transitions from it, or two
wildcard transitions whose intentional intersection is non-empty, the model does not
satisfy the Unique Attribution constraint.
K XSD Language Identifiers (non-normative)
This section defines identifiers for various versions of XSD,
including versions defined in superseded drafts,
to enable precise reference to versions when such reference is necessary.
XSD
XSD 1.0
XSD 1.1
XSD 1.0 First Edition
XSD 1.0 Second Edition
XSD 1.1 First Edition
XSD 1.0 in 6 May 1999 working draft
XSD 1.0 in 24 September 1999 working draft
XSD 1.0 in 5 November 1999 working draft
XSD 1.0 in 17 December 1999 working draft
XSD 1.0 in 25 February 2000 working draft
XSD 1.0 in 7 April 2000 working draft
XSD 1.0 in 22 September 2000 working draft
XSD 1.0 Candidate Recommendation (CR)
XSD 1.0 first Proposed Recommendation (PR)
XSD 1.0 second Proposed Recommendation (PR)
XSD 1.0 Recommendation
XSD 1.0 Second Edition Proposed Edited Recommendation (PER)
XSD 1.0 Second Edition Recommendation
XSD 1.1 in 16 July 2004 working draft
XSD 1.1 in 24 February 2005 working draft
XSD 1.1 in 16 January 2006 working draft
XSD 1.1 in 17 February 2006 working draft
XSD 1.1 in 30 March 2006 working draft
XSD 1.1 in 31 August 2006 working draft
XSD 1.1 in 30 August 2007 working draft
XSD 1.1 in 20 June 2008 working draft
XSD 1.1 in 30 January 2009 working draft
XSD 1.1 Candidate Recommendation, 30 April 2009
XSD 1.1 in working draft of 3 December 2009
XSD 1.1 in Candidate Recommendation draft of 21 July 2011
XSD 1.1 in Proposed Recommendation of 19 January 2012
XSD 1.1 in Recommendation of 5 April 2012
L References
L.1 Normative
The following documents, in whole or in
part, contain provisions which must be consulted in order to
understand fully or to implement some of the normative provisions
of this specification.
Functions and Operators
World Wide Web Consortium.
XQuery 1.0 and XPath 2.0 Functions and Operators
(Second Edition)
ed. Ashok Malhotra, Jim Melton, and Norman Walsh.

W3C Recommendation

14 December 2010. See
The edition cited is the one current at the date of publication of this
specification. Implementations
may
follow the edition cited and/or
any later edition(s); it is implementation-defined which.
IETF RFC 2119
Bradner, Scott.
RFC
2119: Key words for use in RFCs to Indicate Requirement Levels.
IETF (Internet Engineering Task Force), 1997. See
Namespaces in XML 1.0
World Wide Web Consortium.
Namespaces in XML
1.0 (Third Edition)
ed. Tim Bray et al.

W3C Recommendation 8 December 2009.

See
The edition cited is the one current at the date of publication of this
specification. Implementations
may
follow the edition cited and/or
any later edition(s); it is implementation-defined which.

For details of the
dependency of this specification on Namespaces in XML 1.0, see
Dependencies on Other Specifications (§1.4)
XDM
World Wide Web Consortium.
XQuery 1.0 and XPath 2.0 Data Model (XDM)
(Second Edition)
ed. Mary Fernández et al.

W3C Recommendation
14 December 2010. See
The edition cited is the one current at the date of publication of this
specification. Implementations
may
follow the edition cited and/or
any later edition(s); it is implementation-defined which.
XML 1.0
World Wide Web Consortium.
Extensible Markup Language (XML) 1.0 (Fifth Edition)
ed. Tim Bray et al.
W3C Recommendation 26 November 2008.

Available at
The edition cited is the one current at the date of publication of this
specification. Implementations
may
follow the edition cited and/or
any later edition(s); it is implementation-defined which.

For details of the dependency of this specification on XML 1.1,
see
Dependencies on Other Specifications (§1.4)
XML 1.1
World Wide Web Consortium.
Extensible Markup Language (XML) 1.1
(Second Edition)
ed. Tim Bray et al.
W3C Recommendation 16 August 2006,
edited in place 29 September 2006. Available at
The edition cited is the one current at the date of publication of this
specification. Implementations
may
follow the edition cited and/or
any later edition(s); it is implementation-defined which.

For
details of the dependency of this specification on XML
1.1, see
Dependencies on Other Specifications (§1.4)
XML Infoset
World Wide Web Consortium.
XML Information Set
(Second Edition)
ed. John Cowan and Richard Tobin

W3C Recommendation 4 February 2004.

Available at
The edition cited is the one current at the date of publication of this
specification. Implementations
may
follow the edition cited and/or
any later edition(s); it is implementation-defined which.
XML Namespaces 1.1
World Wide Web Consortium.
Namespaces in XML 1.1
(Second Edition)
ed. Tim Bray et al.
W3C Recommendation 16 August 2006.
Available at:
The edition cited is the one current at the date of publication of this
specification. Implementations
may
follow the edition cited and/or
any later edition(s); it is implementation-defined which.

For details of the dependency of this
specification on Namespaces in XML 1.1, see
Dependencies on Other Specifications (§1.4)
XML Schema: Datatypes
World Wide Web Consortium.
XML Schema
Version 1.1
Part 2: Datatypes
ed.
Dave Peterson,
Paul V. Biron and
Ashok Malhotra,
and C. M. Sperberg-McQueen

W3C Recommendation 5 April 2012.
See
The edition cited is the one current at the date of publication of this
specification. Implementations
may
follow the edition cited and/or
any later edition(s); it is implementation-defined which.
XPath 2.0
World Wide Web Consortium.
XML Path Language 2.0
(Second Edition)
ed. Anders Berglund et al.

W3C Recommendation
14 December 2010
(Link errors corrected 3 January 2011)
See
The edition cited is the one current at the date of publication of this
specification. Implementations
may
follow the edition cited and/or
any later edition(s); it is implementation-defined which.
XSLT 2.0
World Wide Web Consortium.
XSL Transformations (XSLT) Version 2.0
ed. Michael Kay.

W3C Recommendation
23 January 2007.
See
The edition cited is the one current at the date of publication of this
specification. Implementations
may
follow the edition cited and/or
any later edition(s); it is implementation-defined which.
L.2 Non-normative
Brüggemann-Klein / Wood 1998
Brüggemann-Klein, Anne, and
Derick Wood.
One-Unambiguous Regular Languages
Information and Computation
140 (1998): 229-253.
Also appears as 142 (1998): 182-206.
DCD
Bray, Tim, Charles Frankston, and Ashok Malhotra, ed.,
Document Content Description
for XML (DCD)

Submission to the World Wide Web Consortium 31-July-1998.
[A submission to W3C from International Business Machines
Corporation and Microsoft Corporation.]
See
DDML
Bourret, Ronald, et al., ed.,
Document Definition Markup Language
(DDML) Specification, Version 1.0
W3C Note, 19-Jan-1999.
[A submission to W3C from
GMD - Forschungszentrum Informationstechnik GmbH.]
See
Requirements for XML Schema 1.1
World Wide Web Consortium.
Requirements for XML
Schema 1.1
, ed. Charles Campbell, Ashok Malhotra, and
Priscilla Walmsley. W3C, 21 January 2003. See
Rule of Least Power
The Rule of Least Power
ed. Tim Berners-Lee
and Noah Mendelsohn.
W3C TAG Finding 23 February 2006.
See
SOX
Fuchs, Matthew, Murray Maloney, and Alex Milowski.
Schema for Object-oriented XML
Submitted to W3C 19980915.
[A submission to W3C by Veo Systems Inc.]

See
SOX-2
Davidson, Andrew, et al.
Schema for Object-oriented XML 2.0
See
SchemaPath
Marinelli, Paolo, Claudio Sacerdoti Coen, and Fabio Vitali.
SchemaPath, a
Minimal Extension to XML Schema for Conditional Constraints

In
Proceedings of the Thirteenth International World
Wide Web Conference
, New York: ACM Press, 2004,
pp. 164-174.

Available on the Web in the ACM Digital Library; citation at
UAAG 1.0
World Wide Web Consortium.
User Agent Accessibility Guidelines 1.0
ed. Ian Jacobs,
Jon Gunderson, and
Eric Hansen.
W3C Recommendation 17 December 2002.
See
UAAG 2.0
World Wide Web Consortium.
User Agent Accessibility Guidelines (UAAG) 2.0
ed. James Allan, Kelly Ford, and
Jeanne Spellman.
W3C Working Draft 19 July 2011.
See
XDR
Frankston, Charles, and Henry S. Thompson.
XML-Data Reduced

3 July 1998.
["This note is a refinement of
the January 1998 XML-Data submission
See
XML Schema Requirements
World Wide Web Consortium.
XML Schema Requirements
ed. Ashok Malhotra and Murray Maloney
W3C
Note 15 February 1999.
See
XML Schema: Component Designators
World Wide Web Consortium.
XML Schema: Component Designators
, ed. Mary
Holstege and Asir Vedamuthu.

W3C Candidate Recommendation 19 January 2010.
See
XML Schema: Primer
World Wide Web Consortium.
XML Schema Part 0: Primer
Second Edition
ed.
Priscilla Walmsley and
and David C. Fallside.W3C Recommendation 28 October 2004.
See
XML-Data
Layman, Andrew, et al.
XML-Data
W3C Note 05 Jan 1998.
[A submission to W3C by
Microsoft, ArborText, DataChannel, and Inso.]
See
XPath 1.0
World Wide Web Consortium.
XML Path Language
ed. James Clark and Steve DeRose

W3C Recommendation 16 November 1999.
See
XPointer
World Wide Web Consortium.
XPointer Framework
ed. Paul Grosso et al.
W3C Recommendation 25 March 2003. See
XSD 1.0 2E
World Wide Web Consortium.
XML Schema Part 1: Structures
Second Edition
ed. Henry S. Thompson et al.
W3C Recommendation 28 October 2004.
See
M Acknowledgements (non-normative)
The following contributed material to version 1.0 of this specification:
David Fallside, IBM
Scott Lawrence, Agranat Systems
Andrew Layman, Microsoft
Eve L. Maler, Sun Microsystems
Asir S. Vedamuthu, webMethods, Inc
The Working Group thanks the members of other W3C Working
Groups and industry experts in other forums who have contributed
directly or indirectly to the creation of this document and its
predecessor.
Since version 1.0 of this
specification was completed, David Beech and Noah Mendelsohn
have retired from the corporations which supported their
work as editors. The email addresses given for them are
those known at the time this document was published.
The work of C. M. Sperberg-McQueen
as a co-editor of this specification was supported by the World
Wide Web Consortium through January 2009 and again from June 2010
through May 2011, and from
February 2009 to the present by Black Mesa Technologies LLC.
At the time this document is published, the members
in good standing of the XML Schema Working Group are:
David Ezell, National Association of Convenience Stores (NACS) (
chair
Shudi (Sandy) Gao 高殊镝, IBM
Mary Holstege, Mark Logic
Sam Idicula, Oracle Corporation
Michael Kay, Invited expert
Jim Melton, Oracle Corporation
Dave Peterson, Invited expert
Liam Quin, W3C (
staff contact
C. M. Sperberg-McQueen, invited expert
Henry S. Thompson, University of Edinburgh
Kongyi Zhou, Oracle Corporation
The XML Schema Working Group has benefited in its work from the
participation and contributions of a number of people who are no
longer members of the Working Group in good standing at the time
of publication of this Working Draft. Their names are given below.
In particular we note
with sadness the accidental death of Mario Jeckle shortly before
publication of the first Working Draft of XML Schema 1.1.
Affiliations given are (among) those current at the time of the
individuals' work with the WG.
Paula Angerstein, Vignette Corporation
Leonid Arbouzov, Sun Microsystems
Jim Barnette, Defense Information Systems Agency (DISA)
David Beech, Oracle Corp.
Gabe Beged-Dov, Rogue Wave Software
Laila Benhlima, Ecole Mohammadia d'Ingenieurs Rabat (EMI)
Doris Bernardini, Defense Information Systems Agency (DISA)
Paul V. Biron, HL7; Invited expert
Don Box, DevelopMentor
Allen Brown, Microsoft
Lee Buck, TIBCO Extensibility
Greg Bumgardner, Rogue Wave Software
Dean Burson, Lotus Development Corporation
Charles E. Campbell, Invited expert
Oriol Carbo, University of Edinburgh
Wayne Carr, Intel
Peter Chen, Bootstrap Alliance and LSU
Tyng-Ruey Chuang, Academia Sinica
Tony Cincotta, NIST
David Cleary, Progress Software
Mike Cokus, MITRE
Dan Connolly, W3C (
staff contact
Ugo Corda, Xerox
Roger L. Costello, MITRE
Joey Coyle, Health Level Seven
Haavard Danielson, Progress Software
Josef Dietl, Mozquito Technologies
Kenneth Dolson, Defense Information Systems Agency (DISA)
Andrew Eisenberg, Progress Software
Rob Ellman, Calico Commerce
Tim Ewald, Developmentor
Alexander Falk, Altova GmbH
David Fallside, IBM
George Feinberg, Object Design
Dan Fox, Defense Logistics Information Service (DLIS)
Charles Frankston, Microsoft
Matthew Fuchs, Commerce One
Andrew Goodchild, Distributed Systems Technology Centre (DSTC Pty Ltd)
Xan Gregg, TIBCO Extensibility
Paul Grosso, Arbortext, Inc
Martin Gudgin, DevelopMentor
Ernesto Guerrieri, Inso
Dave Hollander, Hewlett-Packard Company (
co-chair
Nelson Hung, Corel
Jane Hunter, Distributed Systems Technology Centre (DSTC Pty Ltd)
Michael Hyman, Microsoft
Renato Iannella, Distributed Systems Technology Centre (DSTC Pty Ltd)
Mario Jeckle, DaimlerChrysler
Rick Jelliffe, Academia Sinica
Marcel Jemio, Data Interchange Standards Association
Simon Johnston, Rational Software
Kohsuke Kawaguchi, Sun Microsystems
Dianne Kennedy, Graphic Communications Association
Janet Koenig, Sun Microsystems
Setrag Khoshafian, Technology Deployment International (TDI)
Melanie Kudela, Uniform Code Council
Ara Kullukian, Technology Deployment International (TDI)
Andrew Layman, Microsoft
Dmitry Lenkov, Hewlett-Packard Company
Bob Lojek, Mozquito Technologies
John McCarthy, Lawrence Berkeley National Laboratory
Matthew MacKenzie, XML Global
Nan Ma, China Electronics Standardization Institute
Eve Maler, Sun Microsystems
Ashok Malhotra, IBM; Microsoft; Oracle
Murray Maloney, Muzmo Communication, acting for Commerce One
Paolo Marinelli, University of Bologna
Lisa Martin, IBM
Noah Mendelsohn, Lotus, IBM, invited expert
Adrian Michel, Commerce One
Alex Milowski, Invited expert
Don Mullen, TIBCO Extensibility
Ravi Murthy, Oracle
Murata Makoto, Xerox
Chris Olds, Wall Data
Frank Olken, Lawrence Berkeley National Laboratory
David Orchard, BEA Systems, Inc.
Paul Pedersen, Mark Logic Corporation
Shriram Revankar, Xerox
Mark Reinhold, Sun Microsystems
Jonathan Robie, Software AG
Cliff Schmidt, Microsoft
John C. Schneider, MITRE
Eric Sedlar, Oracle Corp.
Lew Shannon, NCR
Anli Shundi, TIBCO Extensibility
William Shea, Merrill Lynch
Jerry L. Smith, Defense Information Systems Agency (DISA)
John Stanton, Defense Information Systems Agency (DISA)
Tony Stewart, Rivcom
Bob Streich, Calico Commerce
William K. Stumbo, Xerox
Hoylen Sue, Distributed Systems Technology Centre (DSTC Pty Ltd)
Ralph Swick, W3C
John Tebbutt, NIST
Ross Thompson, Contivo
Matt Timmermans, Microstar
Jim Trezzo, Oracle Corp.
Steph Tryphonas, Microstar
Scott Tsao, The Boeing Company
Mark Tucker, Health Level Seven
Asir S. Vedamuthu, webMethods, Inc
Fabio Vitali, University of Bologna
Scott Vorthmann, TIBCO Extensibility
Priscilla Walmsley, XMLSolutions
Norm Walsh, Sun Microsystems
Cherry Washington, Defense Information Systems Agency (DISA)
Aki Yoshida, SAP AG
Stefano Zacchiroli, University of Bologna
Mohamed Zergaoui, Innovimax