1 Introduction
This document sets out the structural part ↓(XML Schema: Structures)↓ of the ↓XML Schema definition language↓↑XML Schema Definition Language↑.
Chapter 2 presents a Conceptual Framework (§2) for ↓XML Schemas↓↑XSD↑, including an introduction to the
nature of ↓XML Schemas↓↑XSD schemas↑ and an introduction to the ↓XML Schema↓↑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↑ ↓XML Schema↓↑XSD schema↑ for
an ↓XML Schema↓↑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 ↓Schemas↓↑Schema Documents (Structures)↑ (normative) (§A) for the XML representation of
schemas and
References (normative) (§B).
The non-normative appendices include the DTD for Schemas (non-normative) (§L) and a Glossary (non-normative) (§K).
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 should also conform to version 1.1, and should
have the same validation behavior across 1.0 and 1.1 implementations
(except possibly in edge cases and in the details of the
resulting PSVI);
The vast majority of schema documents conformant to
version 1.1 of this specification should also conform to
version 1.0, leaving aside any incompatibilities arising from
support for versioning or
co-occurrence constraints, and when they are
conformant to version 1.0 (or are made conformant by the
removal of versioning information), should have the same
validation behavior
across 1.0 and 1.1 implementations (again except possibly in
edge cases and in the details of the resulting PSVI);
↑
1.2 Purpose
The purpose of XML Schema↑ Definition Language↑: Structures is to define the nature of
↓XML schemas↓↑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 ↓XML Schema: Structures↓↑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 ↓may↓↑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
↓XML Schema: Structures↓ formalism ↑defined here↑ to express
syntactic, structural and value constraints applicable to its
document instances. The ↓XML Schema: Structures↓↑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 ↓any application↓↑applications↑. Some applications
↓may↓↑will↑ require constraint capabilities not expressible in this
language, and so ↓may↓↑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)
The XML representation of schema components uses a vocabulary
identified by the namespace name http://www.w3.org/2001/XMLSchema.
For brevity, the text and examples in this specification use
the prefix xs: to stand for this
namespace; in practice, any prefix can be used.
Note:
The namespace for schema documents is unchanged from version
1.0 of this specification, because any schema document valid
under the rules of version 1.0 has essentially the same
validation semantics under this specification as it did under
version 1.0 (Second Edition).
There are a few exceptions to this rule, involving errors in
version 1.0 of this specification which were not reparable by
errata and which have therefore been fixed only in this
version of this specification, not in version 1.0.
Note:
The data model used by
[XPath 2.0] and other
specifications, namely
[XDM], makes use of
type labels in the
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.6).
These attributes are in the namespace whose name is http://www.w3.org/2001/XMLSchema-instance.
For brevity, the text and examples in this specification use
the prefix xsi: to stand for this namespace; in
practice, any prefix can be used.
Users of the namespaces defined here should be aware, as a
matter of namespace policy, that more names
in this namespace may be given
definitions in future versions of this or other
specifications.
1.3.1.3 The Schema Versioning Namespace (vc)
The pre-processing of schema documents described in
Conditional inclusion (§4.2.1) uses
attributes in the namespace
http://www.w3.org/2007/XMLSchema-versioning.
For brevity, the text and examples in this specification use
the prefix vc: to stand for this
namespace; in practice, any prefix can be used.
Users of the namespaces defined here should be aware, as a
matter of namespace policy, that more names in this namespace
may be given definitions in future versions of this or other
specifications.
1.3.2 Namespaces with Special Status
Except as otherwise specified elsewhere in this specification,
if components are
·present· in a schema, or source
declarations are included in an XSD schema document, for
components in any of the following namespaces, then the
components, or the declarations,
should agree with the
descriptions given in the relevant specifications and with the
declarations given in any applicable XSD schema documents
maintained by the World Wide Web Consortium for these
namespaces. If they do not, the effect is
·implementation-dependent·
and not defined by this specification.
http://www.w3.org/XML/1998/namespace
http://www.w3.org/2001/XMLSchema
http://www.w3.org/2001/XMLSchema-instance
http://www.w3.org/2007/XMLSchema-versioning
Note: Depending on implementation details, some processors may
be able to process and use (for example) variant forms of the
schema for schema documents devised for specialized purposes;
if so, this specification does not forbid the use of such variant
components. Other processors, however, may find it
impossible to validate and use alternative components for
these namespaces; this specification does not require them
to do so. Users who have an interest in such specialized
processing should be aware of the attending interoperability
problems and should exercise caution.
This flexibility does not extend to the components described in
this specification or in
[XML Schema: Datatypes] as being
included in every schema, such as those for the primitive and
other built-in datatypes. Since those components are by
definition part of evey schema, it is not possible to have
different components with the same
expanded names present in
the schema without violating constraints defined elsewhere
against multiple components with the same
expanded names.
Components and source declarations must not specify
http://www.w3.org/2000/xmlns/ as their
target namespace. If they do, then the schema
and/or schema document is in ·error·.
Note: Any confusion in the use, structure, or meaning of this namespace
would have catastrophic effects on the interpretability of
this specification.
1.3.3 Conventional Namespace Bindings
Several namespace prefixes are conventionally used in this
document for notational convenience. The following bindings are
assumed.
html bound to
http://www.w3.org/1999/xhtml
my (in examples) bound to the target namespace
of the example schema document
rddl bound to
http://www.rddl.org/
vc bound to
http://www.w3.org/2007/XMLSchema-versioning (defined
in this and related specifications)
xhtml bound to
http://www.w3.org/1999/xhtml
xlink bound to
http://www.w3.org/1999/xlink
xs bound to http://www.w3.org/2001/XMLSchema
(defined in this and related specifications)
xsi bound to
http://www.w3.org/2001/XMLSchema-instance (defined in this and
related specifications)
xsl bound to
http://www.w3.org/1999/XSL/Transform
In practice, any prefix bound to the appropriate namespace
name may be used (unless otherwise specified by the definition
of the namespace in question, as for xml and
xmlns).
1.3.4 Schema Language Identifiers
Sometimes other specifications or Application Programming
Interfaces (APIs) need to refer to the XML Schema Definition Language in
general, sometimes they need to refer to a specific version of
the language. To make such references easy and enable consistent identifiers to be used, we provide the following
URIs to identify these
concepts.
http://www.w3.org/XML/XMLSchema
Identifies the XML Schema Definition Language in general, without referring
to a specific version of it.
http://www.w3.org/XML/XMLSchema/vX.Y
Identifies the language described in version X.Y of the XSD specification. URIs of this form refer to
a numbered version
of the language in general. They do not distinguish among different working drafts or
editions of that version. For example,
http://www.w3.org/XML/XMLSchema/v1.0 identifies
XSD version 1.0 and http://www.w3.org/XML/XMLSchema/v1.1 identifies
XSD version 1.1.
http://www.w3.org/XML/XMLSchema/vX.Y/Ne
Identifies the language described in the N-th edition of version X.Y of
the XSD specification. For example, http://www.w3.org/XML/XMLSchema/v1.0/2e
identifies the second edition of XSD version 1.0.
http://www.w3.org/XML/XMLSchema/vX.Y/Ne/yyyymmdd
Identifies the language described in the N-th edition of version
X.Y of
the XSD specification published on the particular date
yyyy-mm-dd. For example,
http://www.w3.org/XML/XMLSchema/v1.0/1e/20001024
identifies the language
defined in the XSD version 1.0 Candidate
Recommendation (CR) published on 24 October 2000, and
http://www.w3.org/XML/XMLSchema/v1.0/2e/20040318
identifies the language
defined in the XSD version 1.0 Second Edition Proposed
Edited Recommendation (PER)
published on 18 March 2004.
Please see XSD Language Identifiers (non-normative) (§O) 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],↓ ↑[XPath 2.0],
↑and
[XML Schema: Datatypes].
See Required Information Set Items and Properties (normative) (§E) for a tabulation of the
information items and properties specified in [XML-Infoset] which this
specification requires as a precondition to schema-aware
processing.
↑
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:] a term is something used with a
special meaning. The definition is labeled as such
and the term it defines is displayed in boldface. The end of the
definition is not specially marked in the displayed or printed
text. Uses of defined terms are links to their definitions, set
off with middle dots, for instance ·term·.
Non-normative examples are set off in boxes and accompanied by
a brief explanation:
<schema targetNamespace="http://www.example.com/XMLSchema/1.0/mySchema">
And an explanation of the example.
The definition of each kind of schema component consists of a
list of its properties and their contents, followed by
descriptions of the semantics of the properties:
References to properties of schema components are links to the
relevant definition as exemplified above, set off with curly
braces, for instance
{example property}.
↑
For a given component C, an expression
of the form "C.{example property}"
denotes the (value of the) property
{example property} for component C.
The leading "C." (or more) is sometimes omitted,
if the identity of the component and any other omitted properties
is understood from the context.
This "dot operator" is left-associative, so
"C.{p1}.{p2}"
means the same as
"(C.{p1}) .
{p2}"
and denotes the value of property {p2}
within the component or ·property record· which itself
is the value of C's {p1} property.
White space on either side of the dot operator has no significance
and is used (rarely) solely for legibility.
↑
↑
For components C1 and C2, an expression
of the form "C1 . {example property 1} = C2 . {example property 2}"
means that C1 and C2 have the same value for the
property (or properties) in question. Similarly,
"C1 = C2" means that C1 and C2 are
identical, and "C1.{example property}
= C2" that C2 is the value of
C1.{example property}.
↑
The correspondence between an element information item which is
part of the XML representation of a schema and one or more schema
components is presented in a tableau which illustrates the
element information item(s) involved. This is followed by a
tabulation of the correspondence between properties of the
component and properties of the information item. Where context
↓may determine↓↑determines↑ which of several
different components ↓may
arise↓↑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.
<example
count = integer
size = (large | medium | small) : medium>
Content: (all | any*)
</example>
Property
Representation
Description of what
the property corresponds to, e.g. the value of the
size [attribute]
References to elements in the text are links to the relevant
illustration as exemplified above, set off with angle brackets,
for instance <example>.
↑
Unless otherwise specified, references to attribute values
are references to the ·actual value· of the attribute information
item in question, not to its ·normalized value· or to other forms
or varieties of "value" associated with it.
For a given element information item E, expressions of the
form "E has att1 = V"
are short-hand for "there is an attribute information
item named att1 among the [attributes] of E and
its ·actual value·
is V."
If the identity of E is clear from context, expressions
of the form "att1 = V"
are sometimes used.
The form "att1 ≠ V" is also used
to specify that the ·actual value· of att1 is
not V.
↑
References to properties of information items as defined in
[XML-Infoset] are notated as links to the relevant
section thereof, set off with square brackets, for example
[children].
Properties which this specification defines for information
items are introduced as follows:
References to properties of information items defined in this
specification are notated as links to their introduction as
exemplified above, set off with square brackets, for example
[new property].
↑
The "dot operator" described above
for components and their properties is also used for information items
and their properties. For a given information item I, an expression
of the form "I . [new property]"
denotes the (value of the) property
[new property] for item I.
↑
↑
Lists of normative constraints are typically introduced with
phrase like
"all of the following are true" (or "... apply"),
"one of the following is true",
"at least one of the following is true",
"one or more of the following is true",
"the appropriate case among the following is true",
etc.
The phrase "one of the following is true"
is used in cases where the authors believe the items listed
to be mutually exclusive (so that the distinction between
"exactly one" and "one or more"
does not arise). If the items in such a list are not in fact
mutually exclusive, the phrase "one of the following"
should be interpreted as meaning "one or more of the
following".
The phrase "the appropriate case among the following"
is used only when the cases are thought by the authors to be
mutually exclusive; if the cases in such a list are not in fact
mutually exclusive, the first applicable case should be
taken. Once a case has been encountered with a true condition,
subsequent cases must not be tested.
↑
The following highlighting is used for non-normative commentary
in this document:
Note: General comments directed to all readers.
↓Following [XML 1.1], w↓↑W↑ithin normative prose in this
specification, the words may↓
and↓↑,
should↑↑,↑
must↑ and must not↑ are
defined as follows:
may
↓Conforming documents
and XML Schema-aware
processors↓↑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
↓
Conforming documents and
XML Schema-aware processors are required to behave as
described; otherwise they are in error.
↓
↑
(Of schemas and
schema documents:)
Schemas and documents are required to behave as
described; otherwise they are in
·error·.
↑
↑
(Of
processors:)
Processors are
required to behave as described.
↑
↑
must not
Schemas,
schema documents, and processors
are forbidden to behave as
described; schemas and documents which nevertheless
do so are in
·error·.
↑
↑
A failure of a schema
or schema
document to conform to the rules of this
specification.
Except as otherwise specified,
processors
must distinguish error-free (conforming) schemas
and schema documents used in
·assessment· from those with errors;
if a schema used in
·assessment·
or a schema document used in constructing a schema
is in error,
processors
must report the fact;
if more than one is in error, it is
·implementation-dependent·
whether more than one is reported as being in error.
If one or more of the constraint codes given
in
Outcome Tabulations (normative) (§C) is applicable, it is
·implementation-dependent· how many of them, and which,
are reported.
Note: Failure of an XML document to be valid against a particular
schema is not (except for the special case of a schema
document consulted in the course of building a schema) in
itself a failure to conform to this specification and thus,
for purposes of this specification, not an error.
Note: Notwithstanding the fact that (as just noted) failure to be
schema-valid is not a violation of this specification and
thus not strictly speaking an error as defined here,
the names of the PSVI properties
[schema error code] (for attributes) and
[schema error code] (for elements) are retained for
compatibility with other versions of this specification, and
because in many applications of XSD, non-conforming
documents
are "in error" for
purposes of those applications.
↑
↑
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.
↑
↑
These definitions describe in terms
specific to this document the meanings assigned to these terms by
[IETF RFC 2119]. The specific wording follows
that of [XML 1.1].
↑
↑
Where these terms appear without special highlighting,
they are used in their ordinary senses and do not express conformance
requirements. Where these terms appear highlighted within
non-normative material (e.g. notes), they are recapitulating
rules normatively stated elsewhere.
↑
↓Note however that
this↓↑This↑
specification provides a ↓definition↓
↑further description↑
of error and of conformant
processors' responsibilities with respect to errors ↓(see↓↑in↑
Schemas and Schema-validity Assessment (§5)↓) which is
considerably more complex than that of [XML 1.1]↓.
2 Conceptual Framework
This chapter gives an overview of XML Schema↑ Definition Language↑: Structures at the level of its
abstract data model. Schema Component Details (§3) provides details
on this model, including a normative representation in XML for the
components of the model. Readers interested primarily in learning
to write schema documents ↓may wish to
first↓↑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 ↓XML Schema↓↑XSD↑
An ↓XML Schema↓↑XSD schema↑ ↓consists↓↑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
↓may↓↑may↑
specify augmentations to those items and their descendants. This
augmentation makes explicit information ↓which may have been↓ implicit in the original
document, such as normalized and/or default values for attributes
and elements and the types of element and attribute information
items. ↑The input information set
can also be augmented with information about the validity of the
item, or about other properties described in this
specification.↑ [Definition:] We refer to the augmented infoset which
results from conformant processing as defined in this
specification as the post-schema-validation
infoset, or PSVI. ↑Conforming processors may provide
access to some or
all of the PSVI, as described in Subset of the Post-schema-validation Infoset (§D.1). The mechanisms by which
processors provide such
access to the PSVI are neither defined nor constrained by this
specification.↑
As it is used in this specification, the
term
schema-validity assessment has two aspects:
1
Determining local schema-validity, that is
whether an element or attribute information item satisfies
the constraints embodied in the relevant components of an
↓XML Schema↓↑XSD schema↑;2 Synthesizing an overall validation
outcome for the item, combining local schema-validity with
the results of schema-validity assessments of its
descendants, if any, and adding appropriate augmentations to
the infoset to record this
outcome.
Throughout this specification, [Definition:] the word valid and its derivatives are
used to refer to clause 1 above, the
determination of local schema-validity.
Throughout this specification, [Definition:] the word assessment is used to
refer to the overall process of local validation,
schema-validity assessment and infoset
augmentation.
↑
During
·assessment·, some or
all of the element and attribute information items in the input
document are associated with declarations and/or type
definitions; these declarations and type definitions are then
used in the
·assessment· of those items, in a
recursive process.
[Definition:] The declaration associated with an information
item, if any, and with respect to which its validity is ·assessed· in a given assessment episode
is said to govern the item, or to be its
governing element or attribute declaration.
Similarly the type definition with respect to which the
type-validity of an item is assessed is its
governing type definition.
↑
2.2 ↓XML Schema↓↑XSD↑ Abstract Data Model
This specification builds on [XML 1.1] and
[XML-Namespaces 1.1]. The concepts and definitions used
herein regarding XML are framed at the abstract level of
information
items as defined in [XML-Infoset]. By
definition, this use of the infoset provides a
priori guarantees of well-formedness
(as defined in [XML 1.1]) and namespace
conformance (as defined in [XML-Namespaces 1.1]) for all candidates for ·assessment· and for all
·schema documents·.
Just as [XML 1.1] and
[XML-Namespaces 1.1] can be described in terms of
information items, ↓XML Schemas↓↑XSD schemas↑ can be described in terms of
an abstract data model. In defining ↓XML Schemas↓↑schemas↑ in terms of
an abstract data model, this specification rigorously specifies
the information which must be available to a conforming
↓XML Schema↓↑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 ↓comprise↓↑make up↑ the abstract data model
of the schema. ↓[Definition:] An XML Schema is a set
of ·schema components·↓↑[Definition:] An XSD schema is a set of ·schema components·↑. There are
↓13 kinds of component in all↓↑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, ↓which must have names, ↓are as
follows:
Finally, the "helper" ↑schema↑ components provide small
parts of other ↑schema↑ components; they are ↓not independent of↓↑dependent on↑ their context:
Annotations
Model groups
Particles
Wildcards
Attribute Uses
↓
The
name [Definition:] Component covers all the different kinds of
component defined in this specification.
↓
↑
The
name [Definition:] Component covers all the different kinds of
schema component defined in this specification.
↑
During ·validation·, [Definition:] declaration
components are associated by (qualified) name to information items
being ·validated·.
On the other hand, [Definition:] definition components define internal
schema components that can be used in other schema
components.
[Definition:] Declarations
and definitions ↓may↓↑may↑ ↑and in
some cases must↑ have and be identified by
names, which are
NCNames as defined by [XML-Namespaces 1.1].
[Definition:] Several
kinds of component have a target namespace, which
is either ·absent· or a
namespace name, also as defined by [XML-Namespaces 1.1]. The ·target namespace· serves to identify
the namespace within which the association between the component
and its name exists.
↓In the case
of declarations, this in turn
determines the namespace name of, for example, the element
information items it may ·validate·.↓
Note: At the abstract level, there is no requirement that the
components of a schema share a
·target namespace·. Any schema for
use in
·assessment· of documents
containing names from more than one namespace will of necessity
include components with different
·target namespaces·. This contrasts
with the situation at the level of the XML representation of
components, in which each schema document contributes
definitions and declarations to a single target namespace.
·Validation·, defined in detail
in Schema Component Details (§3), is a relation between information
items and schema components. For example, an attribute
information item ↓may ·validate·↓↑is ·validated·↑
with respect to an attribute declaration, a list of element
information items ↓may ·validate·↓ with respect to a
content model, and so on. The following sections briefly
introduce the kinds of components in the schema abstract data
model, other major features of the abstract model, and how they
contribute to ·validation·.
2.2.1 Type Definition Components
The abstract model provides two kinds of type definition
component: simple and complex.
[Definition:] This specification
uses the phrase type definition in cases where no
distinction need be made between simple and complex
types.
Type definitions form a hierarchy with a single root. The
subsections below first describe characteristics of that
hierarchy, then provide an introduction to simple and complex
type definitions themselves.
2.2.1.1 Type Definition Hierarchy
[Definition:] Except for ↓a distinguished ·ur-type
definition·,↓ ↑·xs:anyType·,↑ every ·type definition· is, by construction,
either a ·restriction· or an
·extension· of some
other type definition. The graph of these relationships forms
a tree known as the Type Definition
Hierarchy.
[Definition:] ↓A↓↑The↑ type definition used as the basis
for an ·extension· or
·restriction· is
known as the base type definition of that
definition.
[Definition:] ↓A type
definition whose declarations or facets are in a one-to-one
relation with those of another specified type definition,
with each in turn restricting the possibilities of the one
it corresponds to,↓↑A
type defined with the same constraints as its ·base type definition·, or with more,↑ is
said to be a restriction. The ↓specific restrictions↓↑added constraints↑ might include narrowed
ranges or reduced alternatives. ↓Members of a type, A, whose definition is a
·restriction· of
the definition of another type, B, are always locally valid
against type B as well.↓↑Given two types A and B, if the definition of
A is a ·restriction· of the
definition of B, then members of type A are always locally
valid against type B as well.↑
[Definition:] A complex
type definition which allows element or attribute content in
addition to that allowed by another specified type definition
is said to be an extension.
↓
[Definition:] A distinguished complex type definition, the
ur-type definition, whose name is anyType in the
XML Schema namespace, is present in each ·XML Schema·,
serving as the root of the type definition hierarchy for that
schema.
↓
↑
[Definition:] A special complex type
definition, (referred to in earlier versions of this
specification as 'the ur-type definition') whose
name is anyType in the 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.
↑
2.2.1.2 Simple Type Definition
A simple type definition is a set of constraints on strings
and information about the values they encode, applicable to the
·normalized value· of an attribute information item or of an element
information item with no element children. Informally, it
applies to the values of attributes and the text-only content
of elements.
Each simple type definition, whether built-in (that is,
defined in [XML Schema: Datatypes]) or user-defined, is a ·restriction· of ↓some particular simple↓↑its↑ ·base type definition·.
↓For the built-in primitive type
definitions, this is ↓↓[Definition:] the simple ur-type
definition, a special ·restriction· of the ·ur-type definition·, whose
name is anySimpleType in the XML Schema
namespace. The ·simple ur-type definition· is
considered to have an unconstrained lexical space, and a value
space consisting of the union of the value spaces of all the
built-in primitive datatypes and the set of all lists of all
members of the value spaces of all the
built-in primitive
datatypes.↓ ↑[Definition:] A
special ·restriction· of
·xs:anyType·, whose name is
anySimpleType in the
XSD namespace, is the root of the ·Type Definition Hierarchy· for all simple type
definitions. ·xs:anySimpleType· has a lexical space containing
all sequences of characters in the Universal Character
Set (UCS) and a value space containing all
atomic values
and all finite-length lists of
atomic values.
As with ·xs:anyType·, this
specification sometimes uses the qualified name
xs:anySimpleType to designate this type
definition.↑ ↑The
built-in list datatypes all have ·xs:anySimpleType· as their
·base type
definition·.↑
↑
[Definition:] There is a further special datatype
called anyAtomicType, a
·restriction· of
·xs:anySimpleType·, which is the ·base type definition·
of all the primitive
datatypes. This type definition is often referred
to simply as "xs:anyAtomicType".
It too is
considered to have an unconstrained lexical space. Its value
space consists of the union of the value spaces of all the
primitive datatypes.
↑
The mapping from lexical space to value space is unspecified
for items whose type definition is ↓the ·simple ur-type definition·↓↑·xs:anySimpleType·↑ ↑or ·xs:anyAtomicType·↑. Accordingly
this specification does not constrain processors'
behavio↓u↓r in areas
where this mapping is implicated, for example checking such
items against enumerations, constructing default attributes or
elements whose declared type definition is ↓the ·simple ur-type definition·↓↑·xs:anySimpleType·↑
↑or ·xs:anyAtomicType·↑,
checking identity constraints involving such items.
Note: The Working Group expects to return to this area in a future
version of this specification.
↓Simple types may also be
defined↓↑[XML Schema: Datatypes]
provides mechanisms for defining new simple type definitions
by ·restricting·
some primitive
or ordinary datatype. It also
provides mechanisms for constructing new simple type
definitions↑ whose members are lists of items
themselves constrained by some other simple type definition, or
whose membership is the union of the memberships of some other
simple type definitions. Such list and union simple type
definitions are also ·restrictions· of
↓the ·simple ur-type definition·↓↑·xs:anySimpleType·↑.
For detailed information on simple type definitions, see
Simple Type Definitions (§3.16) and [XML Schema: Datatypes]. The
latter also defines an extensive inventory of pre-defined
simple types.
2.2.1.3 Complex Type Definition
A complex type definition is a set of attribute declarations
and a content type, applicable to the [attributes] and
[children] of an element information item respectively. The
content type ↓may↓↑may↑ require the [children] to contain
neither element nor character information items (that is, to be
empty),