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 (normative) (§A) for the XML representation of schemas and
References (normative) (§B).
The non-normative appendices include the DTD for Schemas (non-normative) (§H) and a Glossary (non-normative) (§G).
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 two 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.
These goals are slightly in tension with one another -- the following
summarizes the Working Group's strategic guidelines for changes
between versions 1.0 and 1.1:
- Add support for versioning (acknowledging that this may
be slightly disruptive to the XML transfer syntax at the margins)
- Allow bug fixes (unless in specific cases we decide that the fix
is too disruptive for a point release)
- Allow editorial changes
- Allow design cleanup to change behavior in edge cases
- Allow relatively non-disruptive changes to type hierarchy (to
better support current and forthcoming international standards and
W3C recommendations)
- Allow design cleanup to change component structure (changes
to functionality restricted to edge cases)
- Do not allow any significant changes in functionality
- Do not allow any changes to XML transfer syntax except those
required by version control hooks and bug fixes
The overall aim as regards 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 behaviour 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,
and when they are conformant to version 1.0 (or are made
conformant by the removal of versioning information), should have
the same validation behaviour 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.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:
All such issues are tabluated in Outstanding issues (§E.2)
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 Schemas: 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.
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 [IETF RFC 2119], within normative prose in this specification, the words
may, 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.
- 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.
This specification provides a definition 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: 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 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. [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.
Issue (RQ-142i):RQ-142 (PSVIProp),
RQ-144 (WhichPSVIPropertiesReqd)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' langauge
is required, the effect is distributed throughout the PSVI sub-sub-sections in
section 3.
MSM proposed the following summary of our views; we appear to be close
to consensus, though perhaps not quite ready to make a final decision:
- 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] and
[XML-Namespaces]. 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]) and namespace
conformance (as defined in [XML-Namespaces]) for
all candidates for ·assessment· and for all ·schema documents·.
Just as [XML] and
[XML-Namespaces] 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.
Issue (CC):2003-06-13 minutes (Component cleanup)Some aspects of the abstract components used to organise this
specification have proved clumsy and/or susceptible to improvement. The way in
which components and their properties are referenced in constraints and
validation rules is sometimes irritatingly verbose. Where-ever possible these
problems should be addressed.Resolution:
Changes to the component structure which do not produce
substantially different functionality (i.e. change behavior only in
edge cases) [are consistent with our overall goals]. Such changes might be made in order to make the
component structure easier to understand, reason about, document,
or talk about. This class is not, however, restricted to changes
which do not affect the information-theoretic information content
of the component structure. That is, it may contain changes
that go beyond renaming or other changes which do not affect
information content.
These changes will be disruptive to (some) implementors, but (MSM
suggested) not to all users, and probably not to any (or: many)
users.
The editor intends under this heading to make the presentation of
components much more systematic, because auto-generated from an XML-notated
explicit definition of components and properties, for example:
<component name="Attribute Declaration" base="Component"
abstract="false" abbrev="ad">
<property name="type definition" valueType="component" arity="singleton"
type="Simple Type Definition" required="true"/>
. . .
The editor also intends to introduce a number of 'micro-components',
replacing all values with complicated value types, e.g. replacing "A pair consisting of a value and one of default, fixed." with a
Value Contstraint micro-component.
[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 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
- 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
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 have and be identified by names, which are NCNames as defined by [XML-Namespaces].
[Definition:] Several kinds
of component have a target namespace, which is either
·absent· or a namespace name, also as
defined by [XML-Namespaces]. 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
Issue (RQ-120i):RQ-120 (term-derived)There is an inconsistency in the use of the word 'derived' and related
words between parts 1 and 2 of version 1.0: Sometimes it refers only to types
defined by
restriction and/or extension, but other times includes lists and unions as
well. This terminological problem, and the underlying conceptual issue, should
be addressed.Resolution:
http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004May/0007.html, http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004May/0009.html
In anticipation of a change in this area, the editor has replaced all
occurrences of 'derived' and related words with one of two entity references:
&derived; for restriction and extension only, and &constructedDiff; for
restriction, extension, list and union. The former is defined to be
'derived' for now, the latter a diff-marked replacement of 'derived'
by 'constructed'.
[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 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, is said to be a restriction.
The specific restrictions 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):RQ-17 (restrictn-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 (member only)]
A non-normative appendix will provide summarys of and references to two published
algorithms for enforcing the constraint as newly defined.
[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 type definition used as the
basis for an ·extension· or
·restriction· is known as
the base type definition of that definition.
2.2.1.2 Simple Type Definition
A simple type definition is a set of constraints on strings and information about the values they encode, applicable to the ·normalized value· of an attribute
information item or of an element information item with no element children.
Informally, it applies to the values of attributes and the text-only content of elements.
Each simple type definition, whether built-in (that is, defined in [XML Schemas: Datatypes]) or
user-defined, is a ·restriction· of some particular
simple ·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.
The mapping from lexical space to value space is
unspecified for items whose type definition is the
·simple ur-type definition·.
Accordingly this specification does not constrain processors' behaviour in
areas where this mapping is implicated, for example checking such items against
enumerations, constructing default attributes or elements whose declared type
definition is the
·simple ur-type definition·, checking
identity constraints involving such items.
Note: The Working Group expects to return to this area in a future
version of this specification.
Simple types may
also be defined 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.14) and [XML Schemas: 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), 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, 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.12).
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).
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.
[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.
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, independently
of their local names.
For detailed information on wildcards, see Wildcards (§3.10).
2.2.4 Identity-constraint Definition Components
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).
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.13).
2.3 Constraints and Validation Rules
The [XML] specification describes two kinds of
constraints on XML documents: well-formedness and
validity constraints. Informally, the well-formedness constraints
are those imposed by the definition of XML itself (such as the rules for the
use of the < and > characters and the rules for proper nesting of
elements), while validity constraints are the further constraints on document
structure provided by a particular DTD.
The preceding section focused on ·validation·, that is
the constraints on information items which schema components supply. In fact
however this specification provides four different kinds of normative statements about schema
components, their representations in XML and their contribution to the
·validation· of information items:
- Schema Component Constraint
- [Definition:] Constraints on the schema components themselves, i.e.
conditions components must satisfy to be components at all. Located in the
sixth sub-section of the per-component sections of Schema Component Details (§3)
and tabulated in Schema Component Constraints (§C.4).
- Schema Representation Constraint
- [Definition:] Constraints on the
representation of schema components in XML beyond those which are expressed
in Schema for Schemas (normative) (§A). Located in the
third sub-section of the per-component sections of Schema Component Details (§3)
and tabulated in Schema Representation Constraints (§C.3).
- Validation Rules
- [Definition:] Contributions to ·validation· associated
with schema components. Located in the
fourth sub-section of the per-component sections of Schema Component Details (§3)
and tabulated in Validation Rules (§C.1).
- Schema Information Set
Contribution
- [Definition:] Augmentations to ·post-schema-validation infoset·s
expressed by schema components, which follow
as a consequence of ·validation· and/or ·assessment·.
Located in the
fifth sub-section of the per-component sections of Schema Component Details (§3)
and tabulated in Contributions to the post-schema-validation infoset (§C.2).
The last of these, schema information set
contributions, are not as new as they might at first seem. 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
This specification describes three levels of conformance for schema aware processors. The first is
required of all processors. Support for the other two will depend on the application environments
for which the processor is intended.
[Definition:] Minimally conforming processors must completely and
correctly implement the ·Schema Component
Constraints·, ·Validation Rules·,
and ·Schema Information
Set Contributions· contained in this specification.
[Definition:] ·Minimally conforming· processors which accept
schemas represented in the form of XML documents as described in Layer 2: Schema Documents, Namespaces and Composition (§4.2) are
additionally said to provide conformance to the XML Representation of Schemas.
Such processors must, when processing schema documents, completely and
correctly implement all ·Schema Representation
Constraints· in this specification, and must adhere exactly to the
specifications in Schema Component Details (§3) for mapping the contents of
such documents to ·schema
components· for use in ·validation· and ·assessment·.
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·.
[Definition:] Fully conforming
processors are network-enabled processors which are not only both ·minimally conforming· and ·in conformance to the XML Representation of Schemas·, but which additionally must be capable of accessing
schema documents from the World Wide Web according to Representation of Schemas on the World Wide Web (§2.7) and How schema definitions are located on the Web (§4.3.2).
.
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].
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):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 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.