1 Introduction
This document sets out the structural part (XML Schema: Structures) of the XML Schema definition language.
Chapter 2 presents a Conceptual Framework (§2) for XML Schemas, including
an introduction to the nature of XML Schemas and an introduction
to the XML Schema 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 XML Schema
for an XML Schema 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
the XML Schema specification, including the XML transfer syntax for
schemas itself.
- Provision of support for co-occurrence constraints, that is
constraints which make the presence of an attribute or element,
or the values allowable for it, depend on the value or presence
of other attributes or elements.
These goals are in
tension with one another.
The Working Group's strategic guidelines for changes between
versions 1.0 and 1.1 can be summarized
as follows:
- 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: Structures is to define the nature of XML 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 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 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: 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 to express syntactic, structural and value constraints applicable to
its document instances. The XML Schema: Structures 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. Some applications may require constraint capabilities not
expressible in this language, and so may need to perform their own additional
validations.
1.3 Dependencies on Other Specifications
The definition of XML Schema: 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:
Implementations may provide the heuristic of using the 1.1 datatypes
if the input is labeled as XML 1.1, and the 1.0 datatypes if the input
is labeled 1.0. It should be noted however that the XML version number is
not required to be present in the input to an assessment episode, and in
any case the heuristic should be subject to override by users, to
support cases where users wish to accept XML 1.1 input but validate it
using the 1.0 datatypes, or accept XML 1.0 input and validate it using
the 1.1 datatypes.
↑
↑
Note:
Some users will perhaps wish to accept only XML 1.1 input, or only XML
1.0 input. Conforming implementations of this specification which accept
XML input may accept XML 1.0, XML 1.1, or both and may provide user
control over which versions of XML to accept.
↑
1.4 Documentation Conventions and Terminology
The section introduces the highlighting and typography as used in
this document to present technical material.
↑
Aspects of this document which the Working Group are committed to
changing, but where (all) changes are not yet in place, are signalled by the
appearance of an Issue, with a link to the associated version 1.1 Requirement,
for example:
↑
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}.
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 which of several different components
may arise, 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>.
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 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 are permitted to but need not behave as described.
↑
should
It is recommended that conforming documents and
XML Schema-aware processors behave as described, but there can
be valid reasons for them not to; it is important that the
full implications be understood and carefully weighed before
adopting behavior at variance with the recommendation.
↑
must
Conforming documents and XML Schema-aware processors are required to behave as described; otherwise they are in error.
↑
must not
Conforming documents and XML Schema-aware processors are forbidden
to behave as described; if they do they are in error.
↑
↑
These definitions describe in
terms specific to this document the meanings assigned to
these terms by [IETF RFC 2119].
The specific wording follows that of
[XML 1.1].
↑
↓Note however that
this↓↑This↑ specification
provides a definition 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: 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 read [XML Schema: Primer] for a tutorial introduction, and
only then consult the sub-sections of
Schema Component Details (§3) named XML Representation of
... for the details.
2.1 Overview of XML Schema
An XML 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 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.↑
Issue (RQ-142i):
Issue 2846 (RQ-142 PSVI properties),
Issue 2822 (RQ-144 required properties)Version 1.0 included several properties in the PSVI whose absence carried
information (e.g. [type definition]), while at the
same time not being completely clear about which PSVI properties, if any, were
required. The Working Group intends to eliminate the former and clarify the latter.Resolution:
For 142, which mandates that insofar as possible absence of a property
should not in general signify, when it does explicit 'if-and-only-if' language
is required, the effect is distributed throughout the PSVI sub-sub-sections in
section 3.
The Working Group appears to be close to consensus (although no final
decision has been made) on views which can be summarized thus:
- We should eliminate any dependency on the absence of specific
properties (i.e. important situations should be describable
and distinguishable in terms of properties and their values,
without appeal to the absence of particular properties), or if
this proves unfeasible in particular cases we should say
explicitly that a property is present "if and only if" certain
conditions apply. Any remaining "if" (if any) would be a
true conditional, not an equivalence.
- Any specification of a class of processors (including ours) can
require specific additional information not in the PSVI, though
should note that interoperability is better if applications depend
only on the properties present in the PSVI as we define it.
- In our own specification of processor classes, we should be
explicit that processors may provide additional information.
(Or alternatively be explicit that they must not -- but the
chair believes the WG consensus was to allow it.)
For 144, a few general remarks here about flexible-but-firm conformance
are wanted here; most of the new work should end up in section 4 and/or 5.
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;
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.
2.2 XML Schema 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 can be described in terms of an
abstract data model. In defining XML Schemas in terms of an abstract
data model, this specification rigorously specifies the information which
must be available to a conforming XML Schema 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 the abstract data model of the schema.
[Definition:]
An XML Schema is a
set of ·schema components·. There are
↓13↓↑14↑ kinds of
component in all, falling into three groups. The primary components,
which may
(type definitions) or must (element and attribute declarations) have names,
are as follows:
- Simple type definitions
- Complex type definitions
- Attribute declarations
- Element declarations
The secondary components,
↓which must have names, ↓are as follows:
- Attribute group definitions
- Identity-constraint definitions
- ↑Assertions↑
- Model group definitions
- Notation declarations
Finally, the "helper" components provide small parts of
other components; they are not independent of their context:
- Annotations
- Model groups
- Particles
- Wildcards
- Attribute Uses
The name [Definition:] Component
covers all the different kinds of component defined in this specification.
During ·validation·, [Definition:] declaration components are associated by
(qualified) name to information items being ·validated·.
On the other hand, [Definition:] definition components define
internal schema components that can be used in other schema components.
[Definition:] Declarations and
definitions 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· 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·, 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‡
†A type defined by appropriate use of facets or
declarations so as to validate a subset of
what another type definition validates, with consistent PSVI outcomes, is a
restriction of the other type†.
‡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 members of type B as well.‡
Issue (RQ-17i):Issue 2820 (RQ-17 simplify restriction rules)Version 1.0 made clear that the intention
for derivation by restriction was that restrictions validated a subset of what their
base validated. However, the constructive rules for what constituted valid content model
restrictions for complex type definition not only failed to enforce this
completely correctly, but also ruled out various cases which evidently should
have been allowed. The Working Group has decided to shift to a much higher
level statement of what constitutes a valid restriction, appealing directly to
the subset requirement, in order to address these problems.Resolution:
A major change in definition/presentation, with only modest changes
in consequences for schemas and validity, will be made, by
defining restriction for complex type definitions in terms of the desired result, that is that
all members of a restricted type are members of its base type. In the
normative part of the spec. this will be done by appeal to local validity.
"Clarifying: R restricts B: any EII that is locally valid [per R]
must also be locally valid [per B], with side conditions on properties on terms
you appeal to [to] get same child allowed by two content models."
[-F2F
2004-03-12, section Subsumption (W3C-member-only link)]
A non-normative appendix will provide references to published
algorithms for enforcing the constraint.
[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‡†rootType† 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 further
special complex type definition, whose name is anyType in the XML Schema
namespace, is also present in each ·XML Schema·.
The definition of anyType serves as default type
definition for element declarations whose XML representation does not specify
one.
†
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↓↑The↑ simple
ur-type definition, a special ·restriction· of the
·ur-type
definition·, whose name is anySimpleType in the XML
Schema namespace↑ is the root of the
·Type Definition Hierarchy· for the simple type
definitions↑. The ·simple ur-type
definition· is considered to have an unconstrained lexical space, and
a value space consisting of the union of the value spaces of all the built-in
primitive datatypes and the set of all lists of all members of the value spaces
of all the built-in primitive datatypes.↑ The
built-in list datatypes all have the ·simple ur-type
definition· as their ·base type
definition·.↑
The mapping from lexical space to value space is
unspecified for items whose type definition is the
·simple ur-type definition·↑or ·anyAtomicType·↑.
Accordingly this specification does not constrain processors' 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·, checking
identity constraints involving such items.
Note: The Working Group expects to return to this area in a future
version of this specification.
↓Simple types may
also be defined↓↑[XML Schema: Datatypes] provides
mechanisms for defining new simple type definitions by ·restricting· one of the built-in primitive or ordinary datatypes. It also provides mechanisms for constructing new simple type definitions↑ whose members are lists of items
themselves constrained by some other simple type definition, or whose
membership is the union of the memberships of some other simple type
definitions. Such list and union simple type definitions are also ·restrictions· of the ·simple ur-type
definition·.
For detailed information on simple type definitions, see Simple Type Definitions (§3.15) 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 the
·ur-type definition· is either
or
A
complex type which extends another does so by having additional content model
particles at the end of the other definition's content model,
or by having additional attribute declarations, or both.
Note: This specification allows only appending, and not other kinds of
extensions. This decision
simplifies application processing required to cast instances from
derived to
base type. Future versions may allow more kinds of extension, requiring more
complex transformations to effect casting.
For detailed information on complex type definitions, see Complex Type Definitions (§3.4).
2.2.2 Declaration Components
There are three kinds of declaration component: element, attribute, and
notation. Each is described in a section below. Also included is a discussion
of element substitution groups, which is a feature provided in conjunction with
element declarations.
2.2.2.1 Element Declaration
An element declaration is an association of a name with a type definition, either simple or
complex, an (optional) default value and a (possibly empty) set of identity-constraint
definitions. The association is either global or scoped to a containing complex type definition. A
top-level element declaration with name 'A' is broadly comparable to a pair of
DTD declarations as follows, where the associated type definition
fills in the ellipses:
<!ELEMENT A . . .>
<!ATTLIST A . . .>
Element declarations contribute to
·validation· as part of model group ·validation·, when their defaults and type components are checked against an element
information item with a matching name and namespace, and by triggering
identity-constraint definition ·validation·.
For detailed information on element declarations, see Element Declarations (§3.3).
2.2.2.2 Element Substitution Group
In XML↓ 1.0↓, the name and content of an element must correspond exactly to the element type referenced in the corresponding content model.
[Definition:] Through
the new mechanism of element substitution groups, XML Schemas provides a more powerful model supporting substitution of one named element for another.
Any top-level element declaration can serve as the defining member, or
head, for an element substitution group. 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
restrictions or extensions of 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 strictly limited according to 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 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.13).
2.2.3 Model Group Components
The model group, particle, and wildcard components contribute to
the portion of a complex type definition that controls an element
information item's content.
2.2.3.1 Model Group
A model group is a constraint in the form of a grammar fragment that applies to
lists of element information items. It consists of a list of particles, i.e.
element declarations, wildcards and model groups. There are three varieties of
model group:
- Sequence (the element information items
match the particles in sequential order);
- Conjunction (the element information items match the
particles, in any order);
- Disjunction (the element information items match
one of the particles).
↑
Each model group denotes a set of sequences
of element information items. Regarding
that set of sequences as a language, the set of sequences recognized
by a group G may be written L(G).
[Definition:] A model group Gis said to
accept or recognize the members of
L(G).
↑
For detailed information on model groups, see Model Groups (§3.8).
2.2.3.2 Particle
A particle is a term in the grammar for element content, consisting of
either an element
declaration, a wildcard or a model group, together with
occurrence constraints. Particles contribute to
·validation· as part of complex type definition ·validation·, when they allow anywhere
from zero to many element information items or sequences thereof, depending on
their contents and occurrence
constraints.
The name [Definition:] Term is used to refer to any of the three kinds of
components which can appear in particles. All ·Terms· are themselves ·Annotated
Components·. ↑[Definition:] A basic term is an
Element Declaration or a Wildcard. [Definition:] A basic
particle is a Particle whose {term} is a ·basic term·.↑
[Definition:] A particle can
be used in a complex type definition to constrain the ·validation· of the [children] of an element
information item; such a particle is called a content
model.
↑
Each content model, indeed each particle,
denotes a set of sequences of element information items. Regarding
that set of sequences as a language, the set of sequences recognized
by a particle P may be written L(P).
[Definition:] A particle P is said to
accept or recognize the members of
L(P).
↑
↑
Note: The language accepted by a content model plays a role in determining
whether an element information item is locally valid or not: if the
appropriate content model does not accept the sequence of elements
among its children, then the element information item is not locally
valid. (Some additional constraints must also be met: not every
sequence in
L(
P) is locally valid against
P. See
Principles of Validation against Groups (§3.8.4.2).)
No assumption is made, in the definition above,
that the items in the sequence are themselves valid; only the
expanded names of the items in the sequence are relevant in
determining whether the sequence is accepted by a particle.
Their validity does affect whether their parent is (recursively)
valid as well as locally valid.
↑
↑
If a sequence S is a member of L(P), then it
is necessarily possible to trace a path through the
·basic particles·
within P, with each item within S corresponding to a matching particle
within P. The sequence of particles within P corresponding to S
is called the ·path· of S in P.
↑
↑
Note: This
·path· has nothing to do
with
[XPath] or XPath expressions. When there
may otherwise be danger of confusion, the
·path· described here
may be referred to as the
·match path· of
S in
P.
↑
For detailed information on particles, see Particles (§3.9).
2.2.3.3 Attribute Use
An attribute use plays a role similar to that of a particle, but for
attribute declarations: an attribute declaration within a complex type definition
is embedded within an attribute use, which specifies whether the declaration
requires or merely allows its attribute, and whether it has a default or fixed value.
2.2.3.4 Wildcard
A wildcard is a special kind of particle which matches element and attribute
information items dependent on their namespace name↑s↑↓,↓
↓independently of↓↑and optionally on↑ their local names.
For detailed information on wildcards, see Wildcards (§3.10).
2.2.4 ↓Identity-constraint Definition↓↑Constraint↑ Components
2.2.4.1 ↑Identity-constraint Definition↑
An identity-constraint definition is an association between a name and one of
several varieties of
identity-constraint related to uniqueness and reference. All the
varieties use [XPath] 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:
Identity constraints currently uses XPath 1.0. This may change in future working drafts
of this specification to use XPath 2.0. Such change will not affect evaluation of
identity constraints, given the XPath subset it uses.
↑
↑
2.2.4.2 Assertion
An assertion is a predicate associated with a type,
which is checked for each instance of the type. Depending
on their formulation, assertions are either required to be
true of the instance, or required to be false. 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.12).
Note:
Assertions are currently only allowed to be specified in complex types.
It may be deemed useful to also include assertions in named model group
definitions and/or attribute groups, or even simple types, if proved
useful.
↑
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.14).
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
Schema Representation Constraint
Schema Information Set
Contribution
The last of these, schema information set
contributions, are not as new as they might at first seem. XML↓ 1.0↓
validation augments the XML↓ 1.0↓ information set in similar ways,
for example by
providing values for attributes not present in instances, and by implicitly
exploiting type information for normalization or access.
(As an example of the latter case, consider the
effect of NMTOKENS on attribute white space, and the semantics of
ID and IDREF.) By including schema
information set contributions, this specification makes explicit some features
that XML↓ 1.0↓ ↓left↓↑leaves↑ implicit.
2.4 Conformance
This specification describes three levels of conformance for schema aware processors.
The first is
required of all processors. Support for the other two will depend on the application environments
for which the processor is intended.
[Definition:] Minimally
conforming processors must completely and
correctly implement the ·Schema Component
Constraints·, ·Validation Rules·,
and ·Schema Information
Set Contributions· contained in this specification.
[Definition:] ·Minimally conforming·
processors which accept schemas represented in the form of XML
documents as described in Layer 2: Schema Documents, Namespaces and Composition (§4.2) are additionally
said to ↓provide conformance to
the XML Representation of Schemas↓↑be schema-document aware↑.
Such processors must, when processing schema documents, completely
and correctly implement all ·Schema
Representation Constraints· in this specification, and must
adhere exactly to the specifications in Schema Component Details (§3)
for mapping the contents
of such documents to ·schema components· for
use in ·validation· and ·assessment·.
Note: By separating the conformance requirements relating to the concrete
syntax of XML schema documents, this specification admits processors
which use schemas stored in optimized binary representations,
dynamically created schemas represented as programming language data
structures, or implementations in which particular schemas are
compiled into executable code such as C or Java. Such processors can
be said to be
·minimally
conforming· but not necessarily
↓in ·conformance to the XML
Representation of Schemas·↓↑·schema-document aware·↑.
[Definition:] ↓Fully conforming↓↑Web-aware↑ processors are
network-enabled processors which are not only both ·minimally conforming· and
·↓in
conformance to the XML Representation of Schemas↓↑schema-document aware↑·, but
which additionally must be capable of accessing schema documents
from the World Wide Web ↓according
to↓↑as described in↑
Representation of Schemas on the World Wide Web (§2.7) and How schema definitions are located on the Web (§4.3.2).
.
↑
Note: In version 1.0 of this specification the class of
·schema-document aware· processors was termed
"conformant to the XML Representation of Schemas".
Similarly, the class of
·Web-aware·
processors was called "fully conforming".
↑
Note: Although this specification provides just these three
standard levels of conformance, it is anticipated that other
conventions can be established in the future. For example, the World
Wide Web Consortium is considering conventions for packaging on the
Web a variety of resources relating to individual documents and
namespaces. Should such developments lead to new conventions for
representing schemas, or for accessing them on the Web, new levels of
conformance can be established and named at that time. There is no
need to modify or republish this specification to define such
additional levels of conformance.
See Schemas and Namespaces: Access and Composition (§4) for a more detailed explanation of the
mechanisms supporting these levels of conformance.
2.5 Names and Symbol Spaces
As discussed in XML Schema 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. A symbol space is similar to
the non-normative concept of namespace
partition introduced in [XML-Namespaces 1.1].
There is a single distinct symbol space within a given ·target namespace· for each kind of
definition and declaration component identified in XML Schema Abstract Data Model (§2.2), except that within
a target namespace, simple type definitions and complex type
definitions share a symbol space. Within a given symbol space, names
are unique, but the same name may appear in more than one symbol
space without conflict. For example, the same name can appear in both
a type definition and an element declaration, without conflict or
necessary relation between the two.
Locally scoped attribute and element
declarations are special with regard to symbol spaces.
Every complex type definition defines its own local attribute and element declaration symbol
spaces, where these symbol spaces are distinct from each other and from any of the other
symbol spaces. So, for example, two complex type definitions having
the same target namespace can contain
a local attribute declaration for the unqualified name "priority", or contain a local element declaration
for the name "address", without conflict or necessary relation between
the two.
2.6 Schema-Related Markup in
Documents Being Validated
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.
Issue (RQ-153i):Issue 3047 (RQ-153 XSD 1.1 namespace)This specification must choose either to use the same namespace as XML
Schema 1.0, or to use a different namespace, or to use more than one namespace.
An explicit decision should be made.
XML Schema: Structures also defines several attributes for direct use in any XML documents. These attributes are in a different namespace,
which has the namespace name http://www.w3.org/2001/XMLSchema-instance.
For brevity, the text and examples in this specification use the prefix
xsi: to stand for this latter namespace; in practice,
any prefix can be used. All schema processors have appropriate attribute
declarations for these attributes built in, see Attribute Declaration for the 'type' attribute (§3.2.7),
Attribute Declaration for the 'nil' attribute (§3.2.7), Attribute Declaration for the 'schemaLocation' attribute (§3.2.7) and Attribute Declaration for the 'noNamespaceSchemaLocation' attribute (§3.2.7).
2.6.2 xsi:nil
XML Schema: Structures introduces a mechanism for signaling that an element
↓should↓↑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 may be
·valid· without
content if it has the attribute xsi:nil with the value
true. An element so labeled must be empty, but can
carry attributes if permitted by the corresponding complex type.
2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation
The xsi:schemaLocation and xsi:noNamespaceSchemaLocation
attributes can be used in a document to provide
hints as to the physical location of schema documents which may
be used for ·assessment·.
See How schema definitions are located on the Web (§4.3.2) for details on the use of these attributes.