This is a
This draft was published
on 30 January 2009.
Attribute declarations can now be marked
Among other consequences, this allows conditional type assignment
and assertions to be sensitive to the inherited value of
the Three priority feedback requests have been added in this draft
(and those in previous drafts have for the most part been retained).
They concern:
The This allows the use of The discussion of Schema processors are now explicitly recommended to provide
a user option to control whether the processor attempts to
dereference schema locations indicated in The semantics of attributes Schema processors are now encouraged to issue warnings for
unrecognized attributes in the The constraints on the XML representation of schemas have been
reformulated to allow them to be checked on schema documents in
isolation, rather than requiring knowledge of the rest of the schema
into which they will be embedded. The consequence is that
some errors are caught not in the XML representation constraints
but by having the XML mapping rules generate faulty components
so that the error can be detected at the component level.
These changes resolve issue
The formal grammar for the XPath expressions used in conditional
type assignment has been revised to allow both cast expressions
and constructor functions, and to resolve a formal ambiguity in
the earlier versions of the grammar; these changes resolve issue
The The setting Skip wildcards are now excluded from the
Annotations given in the XML form of identity-constraint declarations
with All wildcard unions are now expressible, and wildcard union
is used to combine multiple attribute wildcards,
rather than wildcard intersection; this change resolves issue
Namespace fixup is now explicitly required in some places where
it is needed but was not mentioned before; these changes resolve
issue
The term The namespace prefixes used to refer to well known namespaces
have been changed and are now more consistent; this resolves issue
Numerous small changes were made in the interests of clarity,
completeness, consistency, and precision, and to correct
typographical errors. These changes
resolve a number of issues, including:
vc:typeAvailable="A B C"
and
vc:typeUnavailable="A B C"
, respectively, then
exactly one of the two will be chosen. This change resolves issue
vc
namespace. Attributes
may be added to that namespace in the future, so unrecognized
attributes are not errors, but until that time, the presence of
unrecognized attributes is likely to indicate a problem in the input.
This change resolves issue
blockDefault="#all"
has been removed
from the schema for schema documents; this change resolves issue
context-determined-declaration
has been
replaced with the term
For those primarily interested in the changes since version 1.0,
the
Please send comments on this Working Draft to
Although feedback based on any
aspect of this specification is welcome, there are certain aspects of
the design presented herein for which the Working Group is
particularly interested in feedback. These are designated
priority feedback
aspects of the design, and
identified as such in editorial notes at appropriate points in this
draft.
feature
at risk
: the feature may be retained as is, modified, or
dropped, depending on the feedback received from readers,
schema authors, schema users, and implementors.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced by the
This document was produced by a group operating under the
The English version of this specification is the only normative
version. Information about translations of this document is available
at
Edinburgh, et al.: World-Wide Web Consortium, XML Schema Working Group, 2004.
Created in electronic form using XML, starting from
This document sets out the structural part
Chapter 2 presents a
Chapter 3,
Chapter 4 presents
Chapter 5 discusses
The normative appendices include a
The non-normative appendices include the
This document is primarily intended as a language definition
reference. As such, although it contains a few examples, it is
The Working Group has
Significant improvements in simplicity of design and
clarity of exposition
Provision of support for versioning of XML languages
defined using
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
Support for co-occurrence constraints (which will certainly involve additions to the XML transfer syntax, which will not be understood by 1.0 processors)
The
All schema documents conformant to version 1.0 of this
specification should also conform to version 1.1, and should
have the same
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
The purpose of
The purpose of an
Any application that consumes well-formed XML can use the
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.
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
The data model used by untyped
,
untypedAtomic
) which are not defined in this
specification; see the
Users of the namespaces defined here should be aware, as a
matter of namespace policy, that more names
xsi
)
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
vc
)
The pre-processing of schema documents described in
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.
Except as otherwise specified elsewhere in this specification,
if components are 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
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
Components and source declarations http://www.w3.org/2000/xmlns/
as their
target namespace. If they do, then the schema
and/or schema document is in
Any confusion in the use, structure, or meaning of this namespace would have catastrophic effects on the interpretability of this specification.
Several namespace prefixes are conventionally used in this
document for notational convenience. The following bindings are
assumed.fn
bound to
http://www.w3.org/2005/xpath-functions
(defined
in html
bound to
http://www.w3.org/1999/xhtml
my
(in examples) bound to the target namespace
of the example schema documentrddl
bound to
http://www.rddl.org/
vc
bound to
http://www.w3.org/2007/XMLSchema-versioning
(defined
in this and related specifications)xhtml
bound to
http://www.w3.org/1999/xhtml
xlink
bound to
http://www.w3.org/1999/xlink
xml
bound to
http://www.w3.org/XML/1998/namespace
(defined in
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 xml
and
xmlns
).
Sometimes other specifications or Application Programming
Interfaces (APIs) need to refer to the
Identifies the
Identifies the language described in version http://www.w3.org/
identifies
http://www.w3.org/
identifies
Identifies the language described in the
of
http://www.w3.org/
identifies the second edition of
Identifies the language described in the
of
yyyy-mm-dd
. For example,
http://www.w3.org/
identifies http://www.w3.org/
identifies
Please see
The definition of
See
Conforming implementations of this specification
Some users will perhaps wish to accept only XML 1.1 input, or
only XML 1.0 input.
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 ...
)
Special terms are defined at their point of introduction in the
text. For example
Non-normative examples are set off in boxes and accompanied by a brief explanation:
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:
An example property
References to properties of schema components are links to the
relevant definition as exemplified above, set off with curly
braces, for instance
For a given component C, an expression
of the form C.
denotes the (value of the) property
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.
means the same as
(C.
and denotes the value of property
For components C1 and C2, an expression
of the form C1 .
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.
that C2 is the value of
C1.
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
In the XML representation, bold-face attribute names (e.g.
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
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.
The illustrations are derived automatically from the
size
References to elements in the text are links to the relevant
illustration as exemplified above, set off with angle brackets,
for instance
Unless otherwise specified, references to attribute values
are references to the value
associated with it.
For a given element information item E, expressions of the
form E has
are short-hand for att1
= Vthere is an attribute information
item named
If the identity of E is clear from context, expressions
of the form att1
among the
are sometimes used.
The form att1
= V
is also used
to specify that the att1
≠ Vatt1
is
References to properties of information items as defined in
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
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 .
denotes the (value of the) property
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
The following highlighting is used for non-normative commentary in this document:
General comments directed to all readers.
It is recommended that
Conforming documents and
A failure of a schema
Except as otherwise specified,
processors
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.
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 in error
for
purposes of those applications.
A feature or construct defined in this specification
described as
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
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
Where these terms appear without special highlighting, they are used in their ordinary senses and do not express conformance requirements. Where these terms appear highlighted within non-normative material (e.g. notes), they are recapitulating rules normatively stated elsewhere.
This chapter gives an overview of
An
As it is used in this specification, the
term Determining local schema-validity, that is
whether an element or attribute information item satisfies
the constraints embodied in the relevant components of an
Throughout this specification,
Throughout this specification,
During See also the definitions of
This specification builds on
Just as
Simple type definitions
Complex type definitions
Attribute declarations
Element declarations
The secondary
Attribute group definitions
Identity-constraint definitions
Type alternatives
Model group definitions
Notation declarations
Finally, the helper
Annotations
Model groups
Particles
Wildcards
Attribute Uses
The
name
The
name
During
On the other hand,
An
At the abstract level, there is no requirement that the
components of a schema share a
The abstract model provides two kinds of type definition component: simple and complex.
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.
xs:anyType
error
For brevity, the text and examples in this specification often
use the qualified names xs:anyType
and
xs:error
for these type definitions. (In
practice, any appropriately declared prefix can be used, as
described in
A simple type definition is a set of constraints on strings
and information about the values they encode, applicable to the
Each simple type definition, whether built-in (that is,
defined in xs:anyType
xs:anySimpleType
xs:anyType
xs:anySimpleType
to designate this type
definition.xs:anySimpleType
xs:anySimpleType
.xs:anyAtomicType
The mapping from lexical space to value space is unspecified
for items whose type definition is xs:anySimpleType
xs:anyAtomicType
xs:anySimpleType
xs:anyAtomicType
The Working Group expects to return to this area in a future version of this specification.
xs:anySimpleType
For detailed information on simple type definitions, see
A complex type definition is a set of attribute declarations
and a content type, applicable to the
Each complex type definition other than a restriction of a complex an xs:anyType
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.
all
-groups in ways that do not
guarantee that the new material occurs only at the end of
the content.
For detailed information on complex type definitions, see
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.
An element declaration is an association of a name with a type definition, either simple or complex, an (optional) default value and a (possibly empty) set of identity-constraint definitions. The association is either global or scoped to a containing complex type definition. A top-level element declaration with name 'A' is broadly comparable to a pair of DTD declarations as follows, where the associated type definition fills in the ellipses:
Element declarations contribute to
For detailed information on element declarations, see
In XML
All such members
Note that element substitution groups are not represented as
separate components. They are specified in the property values
for element declarations (see
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
For detailed information on attribute declarations, see
A notation declaration is an association between a name and
an identifier for a notation. For an attribute NOTATION
simple type definition, its value
For detailed information on notation declarations, see
The model group, particle, and wildcard components contribute to the portion of a complex type definition that controls an element information item's content.
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).
For detailed information on model groups, see
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
The name
Each content model, indeed each
particle
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.
No assumption is made, in the definition above,
that the items in the sequence are themselves valid; only the
If a sequence S is a member of L(P),
then it is necessarily possible to trace a path through the
This
For detailed information on particles, see
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.
A wildcard is a special kind of particle which matches element
and attribute information items dependent on their namespace
name
For detailed information on wildcards, see
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
For detailed information on identity-constraint definitions, see
In
A
The provisions for conditional type assignment are inspired by,
but not identical to, those of
For detailed information on Type Alternatives, see
An assertion is a predicate associated with a type, which is
checked for each instance of the type. If an element or attribute information item
fails to satisfy an assertion associated with a given type,
then that information item is not locally
For detailed information on Assertions, see
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.
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
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
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
The
The preceding section focused on
The last of these, schema information set contributions, are
not as new as they might at first seem. XMLNMTOKENS
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
The Working Group expects to revise this discussion of
conformance in future. A sketch of relevant work can be found
in
Within the context of this
specification, conformance can be claimed for schema
documents
A It is valid with respect to No element in the schema document violates any of the
Schema Representation Constraints set out in
While conformance of schema documents is a precondition for
the mapping from schema documents to schema components described
in this specification, conformance of the schema documents does
not guarantee that the result of that mapping will be a schema
that conforms to this specification. Some constraints (e.g. the
rule that there must be at most one top-level element
declaration with a particular
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.
The
By separating the conformance requirements relating to the
concrete syntax of
In version 1.0 of this specification the class of conformant
to the XML Representation of Schemas
. Similarly, the
class of fully conforming
.
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
As discussed in 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
Therefore
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.
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.
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.http://www.w3.org/2001/XMLSchema-instance
) described in
As described above (
,
xsi:type
, etc. This is shorthand for
xsi:nil
an attribute information item whose
(or
http://www.w3.org/2001/XMLSchema-instance
and whose type
nil
, etc.).
Users of the namespaces defined here should be aware, as a matter of namespace policy, that more names may be defined in these namespaces in future versions of this or other specifications.
The xsi:type
. The value of this attribute is a
xsi:nil
with the value true
. An element so labeled
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
On the World Wide Web, schemas are conventionally represented
as XML documents (preferably of MIME type
application/xml
or text/xml
, but see
The following sections provide full details on the composition
of all schema components, together with their XML representations
and their contributions to properties: their values and significance XML representation and the mapping to properties constraints on representation validation rules constraints on the components themselves
Components are defined in terms of their properties, and each
property in turn is defined by giving its range, that is the
values it
A schema and its components as defined in this chapter are an
idealization of the information a schema-aware processor
requires: implementations are not constrained in how they
provide it. In particular, no implications about literal
embedding versus indirection follow from the use below of
language such as properties . . . having . . .
components as values
.
Component properties are simply named
values. Most properties have either other components or
literals (that is, strings or booleans or enumerated keywords)
for values, but in a few cases, where more complex values are
involved,
Any property
It is
The principal purpose of http://www.w3.org/2001/XMLSchema
. Although a common way of creating
the XML Infosets which are or contain
Two aspects of the XML representations of components presented
in the following sections are constant across them all:
All of them allow attributes qualified with namespace names
other than the All of them allow an
A recurrent pattern in the XML
representation of schemas may also be mentioned here. In many
cases, the same element name (e.g. element
or
attribute
or attributeGroup
), serves
both to define a particular schema component and to incorporate
it by reference. In the first case the name
attribute is required, in the second the ref
attribute is required. These
two usages are mutually exclusive, and sometimes also depend on
context.
The descriptions of the XML representation
of components, and the
For each kind of schema component there is a corresponding
normative XML representation. The sections below describe the
correspondences between the properties of each kind of schema
component on the one hand and the properties of information
items in that XML representation on the other, together with
constraints on that representation above and beyond those
The language used is as if the correspondences were mappings from XML representation to schema component, but the mapping in the other direction, and therefore the correspondence in the abstract, can always be constructed therefrom.
In discussing the mapping from XML representations to schema
components below, the value of a component property is often
determined by the value of an attribute information item, one of
the
Many properties are identified below as having other schema
components or sets of components as values. For the purposes of
exposition, the definitions in this section assume that (unless
the property is explicitly identified as optional) all such
values are in fact present. When schema components are
constructed from XML representations involving reference by name
to other components, this assumption
Forward reference to named definitions and declarations
Throughout this specification,
The above definition means that comments and processing instructions,
even in the midst of text, are ignored for all
No normalization is done, the
All occurrences of Subsequent to the replacements specified above under
#x9
(tab),
#xA
(line feed) and #xD
(carriage
return) are replaced with #x20
(space).#x20
s are collapsed to a single
#x20
, and initial and/or final
#x20
s are deleted.
When more than one
If the simple type definition used in an item's
xs:anySimpleType
There are three alternative validation rules which
These three levels of normalization correspond to the processing mandated
in XML
Even when DTD-based information
The values unwrap
text (i.e. undo the effects of
pretty-printing and word-wrapping). In some cases, especially
highly constrained data consisting of lists of artificial tokens
such as part numbers or other identifiers, this appearance is
correct. For natural-language data, however, the whitespace
processing prescribed for these values is not only unreliable but
will systematically remove the information needed to perform
unwrapping correctly. For Asian scripts, for example, a correct
unwrapping process will replace line boundaries not with blanks but
with zero-width separators or nothing. In consequence, it is
normally unwise to use these values for natural-language data, or
for any data other than lists of highly constrained tokens.
Attribute declarations provide for:
Local
Specifying default or fixed values for attribute information items.
The XML representation of an attribute declaration.
The attribute declaration schema component has the following properties:
The
The value of
A
A
For an attribute declaration A, if A.
#FIXED
attribute values.
See
A more complete and formal presentation of the semantics of
xmlns
or xmlns:xsl
from
ordinary attributes, identifying them as
The XML representation for an attribute declaration schema
component is an
Attribute declarations can appear at the top level of a schema
document, or within complex type definitions, either as complete
(local) declarations, or by reference to top-level declarations,
or within attribute group definitions. For complete
declarations, top-level or local, the type
attribute is used when the declaration can use a built-in or
pre-declared simple type definition. Otherwise an anonymous
xs:anySimpleType
The default when no simple type
definition is referenced or provided is
Attribute information items form
attributeFormDefault
The names for top-level attribute declarations are in their
own
The following sections specify several
sets of XML mapping rules which apply in different
circumstances.
If the If the On If the If the The ref
use
"prohibited"
, then it maps both to
an ref
use
"prohibited"
, then it maps to
an use='prohibited'
, then it does not map to,
or correspond to, any schema component at all.
use
attribute is not allowed on
top-level
If the
name
targetNamespace
type
xs:anySimpleType
default
or a fixed
inheritable
ref
use='prohibited'
, in which case the item
corresponds to nothing at all):
use
required
use
=
required
default
or a fixed
inheritable
The
name
form
is present and its qualified
, or if form
is absent and
the attributeFormDefault
on the
qualified
, then the
targetNamespace
targetNamespace
is present
its
targetNamespace
is not present and
form
= qualified
form
is absent and the attributeFormDefault
=
qualified
the targetNamespace
type
xs:anySimpleType
inheritable
ref
use='prohibited'
, in which case the item
corresponds to nothing at all):
use
required
use
=
required
ref
default
or a fixed
inheritable
In addition to the conditions imposed on If If the item's parent is not One of If
If
If
If the ancestor
There is a The corresponding attribute
declaration default
and fixed
default
and use
are both present,
use
optional
.ref
or name
ref
is present, then all of form
and type
type
fixed
and use
are both present,
use
prohibited
.
targetNamespace
name
form
targetNamespace
targetNamespace
of
xs:anyType
Informally, an attribute in an XML
instance is locally xsi:type
, it is required that the type named
by the attribute be present in the schema.
A logical prerequisite for checking the local validity of an
attribute against an attribute declaration is that the attribute
declaration itself and the type definition it identifies
both be present in the schema.
Local validity of attributes is
tested as part of schema-validity
A more formal statement is given in the following constraint.
For an attribute information item
If xsi:type
(
A declaration which was stipulated by the processor (see
Its A declaration
Schema-validity assessment of an attribute information item
involves identifying its
The schema-validity assessment of an attribute information item depends
on its
For an attribute information item's schema-validity to have been assessed
A A declaration which has been established as its A declaration Its Both
If the schema-validity of an attribute information item has been assessed
as per
it was
it was
it was
If
the item is
a list. Applications wishing to provide
information as to the reason(s) for the
If
If
Furthermore, the item
Either
or
The
If
The first (
If
the attribute's
the
the
the
Also, if the declaration has a
If the attribute information item was not The item's The
See also
All attribute declarations (see
The values of the properties of an attribute declaration if there is a If the
The use of
xmlns
Not Allowed
xmlns
Not Allowed
The xmlns
.
The xmlns:*
.
xsi:
Not Allowed
xsi:
Not Allowed
The http://www.w3.org/2001/XMLSchema-instance
(unless it is one of the four built-in declarations given in the next section).
This reinforces the special status of these attributes, so that they not
only xsi:type
or xsi:nil
, which would be
seriously misleading, as they would have no effect.
It is legal for xsi:
attributes to specify default or fixed value
constraints (e.g. in a component corresponding to a schema document construct
of the form <xs:attribute ref="xsi:type" default="xs:integer"/>
),
but the practice is not recommended; including such attribute uses will tend
to mislead readers of the schema document, because the attribute uses would
have no effect; see
There are four attribute declarations present in every schema by definition:
xsi:type
The xsi:type
attribute
is used to signal use of a type other than the declared type of
an element. See
type
http://www.w3.org/2001/XMLSchema-instance
xsi:nil
The xsi:nil
attribute
is used to signal that an element's content is nil
(or null
). See
nil
http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation
The xsi:schemaLocation
attribute
is used to signal possible locations of relevant schema documents.
See
schemaLocation
http://www.w3.org/2001/XMLSchema-instance
http://www.w3.org/2001/XMLSchema-instance
xs:anySimpleType
xsi:noNamespaceSchemaLocation
The xsi:noNamespaceSchemaLocation
attribute
is used to signal possible locations of relevant schema documents.
See
noNamespaceSchemaLocation
http://www.w3.org/2001/XMLSchema-instance
Element declarations provide for:
Local
Specifying default or fixed values for
Establishing uniquenesses and reference constraint relationships among the values of related elements and attributes;
Controlling the substitutability of elements through the
mechanism of
XML representations of several different types of element declaration
The element declaration schema component has the following properties:
For an element declaration E, if E.
A
An element information item is xsi:type
attribute
If nil
from namespace
http://www.w3.org/2001/XMLSchema-instance
and value true
(see xsi:nil
with the value
true
(see
D.xsi:nil
=
The provision of defaults for elements goes beyond what is
possible in XML
Element declarations are potential members of the
An empty
The supplied values for
Element declarations for which
See
The XML representation for an element declaration schema
component is an
ref
attribute) or local declarations (otherwise). For complete declarations, top-level or local, the type
attribute is used when the declaration can use a
built-in or pre-declared type definition. Otherwise an
anonymous
Element information items form
elementFormDefault
Note that the above allows for two levels of defaulting for unspecified
type definitions. An substitutionGroup
xs:anyType
name
attribute and no contents,
is also (nearly) the most general, validating any combination of text and
element content and allowing any attributes, and providing for recursive
validation where possible.
See
The following sections specify several
sets of XML mapping rules which apply in different circumstances.
If the If the If the If the The ref
minOccurs=maxOccurs=0
,
then it maps both to a ref
minOccurs=maxOccurs=0
,
then it maps to a minOccurs=maxOccurs=0
,
then it maps to no component at all.
The following mapping rules apply
in all cases where an
name
type
substitutionGroup
The type definition corresponding to the
The type definition type
The substitutionGroup
xs:anyType
test
the test
a
(the test
) a
nillable
default
or a fixed
substitutionGroup
substitutionGroup
block
blockDefault
the
the empty set;
the #all
{
}
;
a set with members drawn from the set
above, each being present or absent depending on whether
the Although the blockDefault
final
and finalDefault
block
and
blockDefault
{
}
.abstract
If the
targetNamespace
ref
minOccurs=maxOccurs=0
,minOccurs=maxOccurs=0
, in which case the item
corresponds to no component at all):
minOccurs
1
.maxOccurs
maxOccurs
1
.
form
is present
and its qualified
form
is
absent and elementFormDefault
on the qualified
targetNamespace
targetNamespace
is present
its
targetNamespace
is not present and
form
qualified
form
is absent and the elementFormDefault
=qualified
the targetNamespace
ref
minOccurs=maxOccurs=0
,minOccurs=maxOccurs=0
, in which case the item
corresponds to no component at all):
minOccurs
1
.maxOccurs
maxOccurs
1
.ref
The first example above declares an element whose type, by default, is
xs:anyType
The last two examples illustrate the use of local element declarations. Instances of myLocalElement
within
contextOne
will be constrained by myFirstType
,
while those within contextTwo
will be constrained by
mySecondType
.
The possibility that differing attribute declarations and/or content models
would apply to elements with the same name in different contexts is an
extension beyond the expressive power of a DTD in XML
An example from a previous version of the schema for datatypes. The
facet
type is defined
and the facet
element is declared to use it. The facet
element is abstract -- it's
facet
facet
, thereby
allowing period
or encoding
(or
any other member of the group).
The following example illustrates conditional type assignment
to an element, based on the value of one of the element's attributes.
Each instance of the message
element will be
assigned either to type messageType
or to a more
specific type derived from it.
The type messageType
accepts any well-formed XML
or character sequence as content, and carries a kind
attribute which can be used to describe the kind or format of
the message. The value of kind
is either one of a
few well known keywords or, failing that, any string.
Three restrictions of messageType
are defined, each
corresponding to one of the three well-known formats:
messageTypeString
for kind="string"
,
messageTypeBase64
for kind="base64"
and kind="binary"
, and
messageTypeXML
for kind="xml"
or
kind="XML"
.
The message
element itself uses
messageType
both as its declared type and
as its default type, and uses test
attributes on its
kind
attribute:
In addition to the conditions imposed on If the item's parent is not One of If
If
If the ancestor
There is a The corresponding particle and/or element declarations
default
and fixed
ref
or name
ref
is present, then all of nillable
, default
,
fixed
, form
, block
and type
minOccurs
, maxOccurs
, id
ref
type
and either type
attribute.targetNamespace
is present then
name
is present.
form
is not present.
targetNamespace
targetNamespace
of
xs:anyType
test
When an element is
The
If D has a If
D has no It is a consequence of xs:error
If at least one
If no
Among the element's attribute information items is one
named The The
xsi:type
.
S is the
S is Typically, T
would be the
The use of the term
to denote the relation between an
S and T are both complex
type definitions and S is validly derived from T
S is a complex type definition, T is a
simple type definition, and S is validly S is a simple type definition and S is
validly
validly substitutable without
limitation
.
Sometimes one type S is
The concept of local validity of an
element information item against an element declaration is
an important part of the schema-validity
Informally, an element is locally valid
against an element declaration when:
The declaration is present in the schema The element is declared concrete (i.e. not abstract). Any Any
The element's content satisfies the appropriate constraints:
If the element is empty and the declaration specifies a
default value, the default is checked against the
appropriate type definitions.
Otherwise, the content of the element is checked against
the
The element satisfies all the identity constraints specified
on the element declaration.
Additionally, on the xsi:nil
attribute on the element obeys the
rules. The element is allowed to have an xsi:nil
attribute only if the element is declared nillable, and
xsi:nil = 'true'
is allowed only if the element
itself is empty. If the element declaration specifies a
fixed value for the element, xsi:nil='true'
will make the element invalid.
xsi:type
attribute present names a
type which is
The following validation rule gives the normative formal definition of local validity of an element against an element declaration.
For an element information item there
The element information item There
If there is an attribute information item
among the element information item's The The The If E has an The If an
If The element information item with
If the the If http://www.w3.org/2001/XMLSchema-instance
and whose nil
.true
xsi:nil
attributexsi:nil
xsi:nil
= false
xsi:nil
= true
http://www.w3.org/2001/XMLSchema-instance
and whose type
, then
xsi:type
If an element has an xsi:type
attribute whose
value does not
The following validation rule specifies
formally what it means for an element to be locally valid
against a type definition. This concept is appealed to in the
course of checking an element's local validity against its
element declaration, but it is also part of schema-validity
xs:anyType
.
Informally, local validity against a type requires first
that the type definition be present in the schema and not declared abstract.
For a simple type definition, the element must lack attributes
(except for namespace declarations and the special attributes
in the xsi
namespace) and child elements, and must
be type-valid against that simple type definition.
For a complex type definition, the element must
be locally valid against that complex type definition.
Also, if the element has an xsi:type
attribute,
then it is not locally valid against any type other than the
one named by that attribute.
For an element information item
If T is a complex type definition, then
T.
If
If
This rule only covers the case when a http://www.w3.org/2001/XMLSchema-instance
and whose
type
,
nil
, schemaLocation
or
noNamespaceSchemaLocation
xsi:type
,
xsi:nil
,
xsi:schemaLocation
, or
xsi:noNamespaceSchemaLocation
xsi:type
xsi:type
The following validation rule
specifies document-level ID/IDREF constraints checked on the
For an element information item There There
See
The first clause above
Although this rule applies at the
This reconstruction of ID/IDREF
functionality is imperfect in that if
the
This section gives the top-level rule
for Assessment begins with the identification of a
The element's attributes are to be The element's children are to be xsi:type
attribute), otherwise the element
will be
A
declaration stipulated by the processor (see Its A declaration it is the
processor has stipulated a type definition a
An A type definition stipulated by the processor (see
An The An The An
The schema-validity assessment of an element information item
depends on its
A If that evaluation involved the evaluation of
A The
For each of the attribute information items among
the attribute has a
its schema-validity is assessed with respect to that
declaration, as defined in
its schema-validity is not assessed.
For each of the element information items among its
the child has a
its schema-validity is assessed with respect to that
declaration or type definition, as defined in
the child is
its schema-validity is not assessed.
its schema-validity is xs:anyType
xs:anyType
When an element information item is xsi:
In general if xsi:type
The
If
it was
Neither its Neither its
it was
it was not
If
the item is
a list. Applications wishing to provide
information as to the reason(s) for the
the element information item is locally
If
or
The
the item was
(the item was
If
the
the
the
xsi:type
attribute which fails to
xsi:type
attribute which fails to
xs:anyType
the element information item was
(the item was
neither its
Furthermore, the item has one of the following alternative sets of properties:
Either
or
The
When
If
The first (
If
the
the simple type
the simple type
the
Also, if the declaration has a
Note that if an element is xs:anyType
If
See also
A is among the
A and E have the same
A is
A is
If and only if an element information item P is not
A is
Let O be A's
All element declarations (see
The values of If If If there is a For each member M of E. If the The use of If xs:error
the the string the the
For an element declaration (call it There is a chain of The set of all
Define
The element declaration itself is in
Its It is validly substitutable for
Complex Type Definitions provide for:
Constraining element information items by providing
Constraining element information item
Constraining
elements and attributes
Using the mechanisms of
Specifying
Limiting the ability to
Controlling the permission to substitute, in an instance, elements of a
The XML representation of a complex type definition.
A complex type definition schema component has the following properties:
Complex type definitions are identified by their
The
As described in
A complex type with an empty specification for final
attribute of its own, final for anything.
The
Complex types for which
a set whose
members are either namespace names or
A A A A
A
Not all combinations of
as the as the as the
as the
E1 is contained in a
D is derived from another
B contains an
E2 has T as its xsi:type
attribute;
see
xsi:type
) or element substitution (substitution groups) appear in
the instance document. It has been changed to take effect whenever complex type
derivation is checked, including cases beyond type and element substitutions in
instance documents. In particular, it affects
See
The XML representation for a complex type definition schema component is a
The XML representation for complex type definitions with a
<complexType name="anyThing"/>
is allowed.
Aside from the simple coherence requirements outlined
The following sections describe
different sets of mapping rules for complex types; some
are common to all or many source declarations, others
only in specific circumstances.
If the If the If the
Where convenient, the mapping rules are
described exclusively in terms of the schema document's
information set. The mappings, however, depend not only upon
the source declaration but also upon the schema context. Some
mappings, that is, depend on the properties of other components
in the schema. In particular, several of the mapping rules
given in the following sections depend upon the
Whichever
alternative for the content of
name
targetNamespace
abstract
block
blockDefault
the
the empty set;
the #all
{
}
;
a set with members drawn from the set
above, each being present or absent depending on whether
the Although the blockDefault
final
and finalDefault
block
and
blockDefault
name
If the
When the
When
base
the
base
starting from either
the simple type definition corresponding to the
otherwise (base
the
base
xs:anySimpleType
If there is no xs:anySimpleType
the
base
the
(the
base
the
that simple type definition;
xs:anySimpleType
When the
Complex types with complex content can
be the image of two different forms of
When the
base
The set of attribute uses corresponding to the
The ref
The
The what would have been the base
use
When the xs:anyType
xs:anyType
For complex types with complex content,
the
The mapping rule below refers here and there to elements
not necessarily present within a If the
, if no abc
attribute is present
on the abc
attribute is present on the
(non-existent)
When the mapping rule below refers to the
, then for a
The mapping rule also refers to the value of the
the its the its mixed
mixed
false
.
It is a consequence of
There is no There is an the particle corresponding to the
minOccurs
0
and
which has no maxOccurs
There is no There is an There is a
the A particle whose properties are as
follows:
A model group whose minOccurs
0
;true
1
1
the The
the the
the
a the a the a A model group
whose the
the the
a the a model group whose
a model group whose true
, otherwise
true
, otherwise
base
base
true
, otherwise
1
1
base
1
1
1
the
the
the
the
appliesToEmpty
=
Then the value of the property is
the
the
the
a
mode
=
'none'
mode
It is a consequence of
Any
The
In the following rule, references to the
refer to the
The rule also refers to the value of the
defaultAttributes
attribute, and the defaultAttributesApply
=
false
,ref
defaultAttributes
The set of attribute uses corresponding to the
The ref
If the
the what would have been the base
use
The attribute uses T is a complex type definition and
the attribute
uses in T. T is a
complex type definition and
the attribute uses in
T. the the no attribute use
is inherited.inherited
from the
use
=
The use
attribute of an
use
attribute to have the value
The
The following mapping rule is the same for all complex type definitions.
References to the
refer to the
The rule also refers to the value of the
If the defaultAttributes
attribute, and the
defaultAttributesApply
= false
, then the
ref
defaultAttributes
there is an a wildcard based on the namespace
and
processContents
there are no the there are one or more
there is an a wildcard whose there is no a wildcard whose properties are as
follows:
The The
The value is then determined by
the
the
that The value is then determined by
the
the the a wildcard whose (the the the the the a wildcard whose
a wildcard whose base
Aside from the simple coherence requirements
enforced above, constraining type definitions identified as
restrictions to actually
Three approaches to defining a type for length: one with
character data content constrained by reference to
a built-in datatype, and one attribute, the other two using two
elements. length3
is the abbreviated alternative to
length2
: they correspond to identical type definition components.
The following declaration defines a type for specifications of length
by creating a complex type with simple content, with
xs:nonNegativeInteger
as the type of the
content, and a unit
attribute to give the
unit of measurement.
An instance using this type might look like this:
A second approach to defining length uses two elements, one for size and one for the unit of measure. The definition of the type and the declaration of the element might look like this:
An instance using this method might look like this:
A third definition of type leaves the base type implicit; at the component level, the following declaration is equivalent to the preceding one.
A type definition for personal names, and a definition
A simplified type definition
Amixed
attribute appearing on complexType
itself.
A complex type definition that
To restrict away a local element declaration that
The restriction type quietComputer
has
a speaker
.
Without the specification of the notQName
attribute,
speaker
, as well. In that case, the restriction
would be valid only if there is a
top-level declaration for speakerType
or a type derived from it.
Otherwise, there would be instances locally valid against the restriction
quietComputer
that are not locally valid against the base type
computer
.
For example, if there is no notQName
attribute on the wildcard and
no top-level declaration for quietComputer
, but not by computer
:
The specific rule violated in this case
is
In addition to the conditions imposed on If the If the The type definition a complex type definition whose only if the
only if the
If Although not explicitly ruled out either here or in
The corresponding complex type definition component If
If
If
If the base
mixed
= base
<xs:complexType . . .mixed='true'
when the
mode
≠ 'none'
mixed
The attribute case is simpler and will be taken first.
CTD is
A
the
the
xs:anyType
The definition for elements is slightly more complex.
CTD is
E
xs:anyType
The constraint
The reference to
Similarly: Let D be an E let D be any one of those E E let D be that top-level If E matches some D has a the D has no the If E matches no T is E has no the The constraint It is a consequence of the definition of xs:anyType
For a given
CTD is
A
the xs:anyType
xs:anySimpleType
For an element information item If the sequence of the sequence of element
information item For each attribute information item there is among the
There The For each attribute use U
in T. It is a consequence that each such U will have
the matching attribute information item
When an Let There If This clause serves to ensure that even via attribute
wildcards no element has more than one attribute of type ID, and that even when
an element legitimately lacks a declared attribute of type ID, a
wildcard-validated attribute
For each element information item in
http://www.w3.org/2001/XMLSchema-instance
and whose
type
, nil
,
schemaLocation
or noNamespaceSchemaLocation
xsi:type
, xsi:nil
,
xsi:schemaLocation
, or xsi:noNamespaceSchemaLocation
(see
When an
U is a member of T.
U.
U.
For a sequence S (possibly empty) of element information items
to be locally
S is
S can be represented as two subsequences S1 and
S2 (either can be empty) such that
S = S1 + S2
S1 is
If S2 is not empty, let E be the first element
in S2, then S1 + E does
Every element in S2 is
(
S is a member of S1 × S2
S1 is
For every element E in S2, let S3 be
Every element in S2 is
When
When a sequence S of
S is a member of S1 × S2
S1 is a prefix of some element sequence that is
for every element E in S2, let S3 be
The above definition
Given an element information item E and a complex type T,
let B be the T T S S T T B is T has T has xs:anyType
This constraint has (by
It also ensures (by
For each
In addition, if necessary
The
The
If the
If
more than one
The
The element information item being assessed.
The
The
The
The nearest ancestor element information item with a
The added items
If the Otherwise, first select some prefix P which is not bound by
the Add an entry to the Add a namespace attribute to the Maintain the consistency of the information set by adjusting
the namespace bindings on the descendants of E. This may
be done in either of two ways: Add the binding of P to N to the Add to the The choice between the two methods of maintaining
consistency in the information set is
When a default value of type
To allow users of the
the attribute information item is
an
the attribute information item is
an
(the item is not
the item is
the item is
the item is
the item is
(the item is not
And each element information item in
its
the element information item is
an
the item is
an
(the item is not
the item is
the item is
the item is
the item is
the item is
(the item is not
All complex type definitions (see
The values of the properties of a complex type definition
If the
xs:anyType
xs:anyType
If
B. If
The B and T both
have The B and T both have
The
T. The
B.
Both Both B and T have
The
T.
Both
If neither It This requirement ensures that
nothing removed by a restriction is subsequently added
back by an extension Constructing the intermediate type definition to
check this constraint is straightforward: simply
re-order the
For any element or attribute information item, its
B.
The
T.xs:anyType
For each attribute use (call this there is an attribute use in the
the For each attribute use in the If there is an The
The complex type definition's Unless the The
T. The
Let S
B. The
T. The B. The B. The
T. The
T and B both have
The The Attempts to For every element information item
For any element B.xs:anyType
The constraint just given,
like other constraints on schemas,
However, under certain conditions conforming processors
need not (although they
It is
This provision for validation-time checking of
this constraint on schemas is similar, in some ways,
to the validation-time checking of restrictions
involving conditional type assignment specified
in
The two cases differ, however, in that a failure
to satisfy
Every sequence of element information items which is
For all sequences of element information items restriction
)
base
)
When the item has a
When the item has a
When the item has a When the item is When the item is When the item is
Both Either
Either
G.
To restrict a complex type definition with a simple base type definition
to
To restrict away a local element declaration that
The following constraint defines a relation appealed to elsewhere in this specification.
For a complex type definition (call it If
it it xs:anyType
This constraint is used to check that when someone uses a type in a
context where another type was expected (either via xsi:type
or
The wording of When they are both top-level components with the same component type,
namespace name, and local name; When they are necessarily the same type definition (for example, when
the two type When they are the same by construction (for example, when an element's
type definition defaults to being the same type definition as that of its
substitution-group head or when a complex type definition inherits an attribute
declaration from its base type definition).
In other cases
When a complex type definition S is said to be
validly
from a type definition T,
without mention of any specific set of blocking keywords,
or with the explicit phrase without limitation
,
then what is meant is that S is validly derived from
T, subject to the empty set of blocking keywords,
i.e. without any particular limitations.
There is a complex
type definition xs:anyType
The outer particle of xs:anyType
The inner particle of xs:anyType
This specification does not provide an inventory of built-in complex
type definitions for use in user schemas. A preliminary library of complex type
definitions is available which includes both mathematical (e.g.
rational
) and utility (e.g. array
) type definitions.
In particular, there is a text
type definition which is recommended for use
as the type definition in element declarations intended for general text
content, as it makes sensible provision for various aspects of
internationalization. For more details, see the schema document for the type
library at its namespace name:
An attribute use is a utility component which controls the occurrence and defaulting behavior of attribute declarations. It plays the same role for attribute declarations in complex types that particles play for element declarations.
XML representations which all involve attribute uses, illustrating some of the possibilities for controlling occurrence.
The attribute use schema component has the following properties:
See
Attribute uses correspond to all uses of use
attribute. These in turn correspond to
None
The item's
For an attribute information item to be
None
All attribute uses (see
The values of the properties of an attribute use
If
If the
If U.
A schema can name a group of attribute declarations so that they
Attribute group definitions do not participate in
XML representations for attribute group definitions. The effect is as if the attribute declarations in the group were present in the type definition.
The example above illustrates the pattern
mentioned in attributeGroup
, serves both to
define and to incorporate by reference. In the first
attributeGroup
element in the example, the
name
attribute is required and the
ref
attribute is forbidden; in the second the
ref
attribute is required, the
name
attribute is forbidden.
The attribute group definition schema component has the following properties:
Attribute groups are identified by their
See
The XML representation for an attribute group definition
schema component is an
When an
name
targetNamespace
schema
ref
As described below, circular references from
It is a consequence of this rule and the rule in
The rules given above for
Circular reference is
The example above illustrates a pattern
which recurs in the XML representation of schemas: The same
element, in this case attributeGroup
, serves both
to define and to incorporate by reference. In the first case
the name
attribute is required, in the second the
ref
attribute is required, and the element name
, ref
,
In version 1.0 of this specification, circular group reference was not
allowed except in the
The following mapping for attribute-wildcards forms part of the
XML mapping rules for different kinds of source declaration
(most prominently
The mapping is defined as follows:
Let W be a sequence containing all the
The value is then determined by the a wildcard whose
(no
In addition to the conditions imposed on The corresponding attribute group definition, if any, If Circular group reference is disallowed outside ref
ref
None
None
None
All attribute group definitions (see
The values of the properties of an attribute group definition
A model group definition associates a name and optional annotations with
a
Model group definitions are provided
primarily for reference from the
A minimal model group is defined and used by reference, first as the whole content model, then as one alternative in a choice.
The model group definition schema component has the following properties:
Model group definitions are identified by their
Model group definitions
See
The XML representation for a model group definition schema component is a
If there is a
name
name
targetNamespace
schema
Otherwise,
ref
minOccurs=maxOccurs=0
minOccurs=maxOccurs=0
, in which
case the item corresponds to no component at all)
minOccurs
1
.maxOccurs
maxOccurs
1
.ref
Otherwise, the minOccurs=maxOccurs=0
, in which
case it maps to no component at all.
The name of this section is slightly misleading, in that the
second, un-named, case above (with a ref
and no
name
) is not really a named model group at all, but
a reference to one. Also note that in the first (named) case
above no reference is made to minOccurs
or
maxOccurs
: this is because the schema for schema
Given the constraints on its appearance
in content models, an
In addition to the conditions imposed on
None
None
None
All model group definitions (see
The values of the properties of a model group definition
When the
XML representations for the three kinds of model group, the third nested inside the second.
The model group schema component has the following properties:
specifies a sequential ( ( ( (=0
or
1
, =1
.
When two or more particles contained directly or indirectly in the
See
The XML representation for a model group schema component is
either an
Each of the
above items corresponds to a particle containing a model group,
with properties as follows (unless minOccurs=maxOccurs=0
,
in which case the item corresponds to no component at all):
minOccurs
1
.maxOccurs
maxOccurs
1
.The particle just described has a
In addition to the conditions imposed on
None
In order to define the validation rules for model groups clearly, it will be useful to define some basic terminology; this is done in the next two sections, before the validation rules themselves are formulated.
Each model group M denotes a language
L(M), whose members are the sequences of element information items
Within L(M) a smaller language V(M) can be
identified, which is of particular importance for schema-validity
assessment. The difference between the two languages is that
V(M) enforces some constraints which are ignored in the definition
of L(M).
Informally L(M) is the set of sequences which are accepted by a model
group if no account is taken of the schema component
constraint
the sequences (<a/><b/><c/>
)
and (<a/><b/>
) have <a/><b/><c/><d/>
) and
(<a/><x/>
) do not
It is possible, but unusual, for a <a
)
and (<a
) have paths in the
The definitions of L(M)
This section defines L(M)
If M is a +
as the concatenation operator), where
S
When M is a sequence group
and S is a sequence of input items, the set of j ≤ n, and S = S1 + S2 + ... + S S Q
By this definition, some sequences which do not satisfy the
entire
and an input sequence S
where n = 3, j = 2, then
S1 is (<a/>
),
S2 is (<b/>
),
and
S has a
When M is a sequence group,
the set V(M) (the set of sequences
For sequences with more than one <a/>
) has two
There are model groups for which some members of
L(M) are not in V(M). For example, if M is
<a/><a/>
) is in L(M), but not
in V(M), because the validation rules require that the first
This section defines L(M)
When the
The set V(M) (the set of sequences
For example, if M is
<a/>
)
contains just the
This section defines L(M)
When the ×
as the interleave operator),
where
for 0 < i ≤ n, S
Less formally, when M is an
For example, given the <a/><a/>
),
S2 is (<b/>
)
The set V(M) (the set of sequences
For example, if M is
The other element can be anything at all, including a second
<a/><a/>
)
is checked against M, in the
If the intention is not to allow the second <a/><a/>
) is not
accepted by the particle.
It is possible for a given sequence of element information items
to have multiple
which can match the sequence (<a/><b/>
)
in more than one way.
It may also be the case with unambiguous model groups, if
they do not correspond to a 1-unambiguous
expression, as it
is defined by
Because these model groups do not obey the
constraint
As noted above, each model group M denotes a
language L(M), whose members are sequences of element information
items. Each member of L(M) has one or more
By imposing conditions on
For example, in the content model
the sequence (<a/><b/>
) has two paths,
one (Q1) consisting of the
By contrast, in the content model
It is a consequence of the definition of
For a sequence (possibly empty) of element information items to be
locally the there the there the there n
n
n
n
Nothing in the above should be understood as ruling out groups whose
For a sequence S (possibly empty) of element information items to be
locally
It is possible to define groups whose
The above definition is implicitly non-deterministic, and should not be
taken as a
0
)
None
All model groups (see
The values of the properties of a model group
When a model group has It appears only as the value of one or both of the following properties: the the
The =1
which is 0
or 1
.
If the
If
The
At least
The
The
There exists a top-level element declaration G with the
strict
, lax
,
or skip
A content model
A content model
Content models in which an
This constraint reconstructs for
Since this constraint is expressed at the component level, it
applies to content models whose origins (e.g. via type
Content models in which an
This constraint reconstructs for
Since this constraint is expressed at the component level, it
applies to content models whose origins (e.g. via type
It is a consequence of
Because locally-scoped element declarations
The following constraints define relations appealed to elsewhere in this specification.
The effective total range of a particle
The product of 0
if there are no
0
if there are no
The effective total range of a particle
The product of 0
if there are no
0
if there are no
As described in
When an element is validated against a complex type,
its sequence of child elements is checked against the content model of
the complex type and the children are
XML representations which all involve particles, illustrating some of the possibilities for controlling occurrence.
The particle schema component has the following properties:
In general, multiple element
information item
Again, when the
When the
See
Particles correspond to all three elements (minOccurs
and maxOccurs
attributes.
These in turn correspond to
None
Every particle P
When
When
When
If (1) If T is a model group,
then the set of
If T is a
Informally: the path of an input sequence S in a
particle P may go through the
In the preceding section (
E and D have the same The
The local name of E is identical to N. Either the namespace name of E is identical to NS,
or else E has no namespace name (E is an unqualified
name) and NS is
For convenience,
For principles of validation when the
For a sequence (possibly empty) of element information items to be
locally The sequence must be accepted by the
For a sequence (possibly empty) of
element information items to be
accepted by a
The length of the sequence If Each element information item in the sequence
The length of the sequence If For each element information item In this case In this case In this case In this case
This clause is equivalent to requiring that the sequence
of length 1 containing E is in
There is a If Each sub-sequence in the n
n
n
The rule just given does not require that the
content model be deterministic. In practice, however,
most
non-determinism in content models is ruled out by the schema
component constraint
None
All particles (see
The values of the properties of a particle
If
The following constraints define relations appealed to elsewhere in this specification.
They are the same particle. E.
Both The
=1
and its
The approach to defining a type by restricting another type definition set out here is designed to ensure that types defined in this way are guaranteed to be a subset of the type they restrict. This is accomplished by requiring a clear mapping between the components of the base type definition and the restricting type definition. Permissible mappings are set out below via a set of recursive definitions, bottoming out in the obvious cases, e.g. where an (restricted) element declaration corresponds to another (base) element declaration with the same name and type but the same or wider range of occurrence.
The structural correspondence approach to guaranteeing the subset relation set out here is necessarily verbose, but has the advantage of being checkable in a straightforward way. The working group solicits feedback on how difficult this is in practice, and on whether other approaches are found to be viable.
They are the same particle. Any top-level element declaration particle (in Any pointless occurrences of The particle within which this The The particle within which this The particle within which this The The particle within which this 1
for each of the declarations in its 1
.0
.1
.
For a particle's occurrence range to be a valid restriction of another's
occurrence range
Its The other's Both
For an element declaration particle to be a The declarations' Both Either either
The above constraint on
For an element declaration particle to be a The element declaration's
For an element declaration particle to be a 1
and with
For a wildcard particle to be a Unless
The exception to the third clause above for
For a group particle to be a Every member of the The effective total range of the group, as defined by
For an There is a complete Each particle in the All particles in the
Although the
predecessor
and follows
are defined with respect
to the order of the lists which constitute
For a There is a complete
Although the
For a There is a complete functional mapping from the particles in the
No particle in the Each particle in the All particles in the
Although this clause allows reordering, because of the limits on the
contents of
For a There is a complete functional mapping from the particles in the
The pair consisting of the product of the This clause is in principle more restrictive than absolutely
necessary, but in practice will cover all the likely cases, and is much easier
to specify than the fully general version.
This case allows the unfolding
of iterated disjunctions
into sequences. It
Its Its 0
.0
.
In order to exploit the full potential for extensibility offered by XML
plus namespaces, more provision is needed than DTDs allow for targeted flexibility in content
models and attribute declarations. A wildcard provides for
XML representations of the four basic types of wildcard, plus one attribute wildcard.
The wildcard schema component has the following properties:
( ( ( ( ( (
(
(
There No constraints at all: the item If the item has a uniquely
determined declaration available, it xsi:type
, and the
item
See
The XML representation for a wildcard schema component is an
AminOccurs=maxOccurs=0
, in which case the
item corresponds to no component at
all)
The mapping from an
minOccurs
1
.maxOccurs
maxOccurs
= maxOccurs
1
.The mapping from an
namespace
targetNamespace
if one such substring is
if one such substring is ##targetNamespace
, the corresponding
member is the targetNamespace
##local
, the
corresponding member is
the namespace
namespace
= "##any"
namespace
= "##other"
the notNamespace
(neither namespace
nor
notNamespace
is present)
neither namespace
nor
notNamespace
is present
the empty set;
namespace
= "##any"
the empty set;
namespace
= "##other"
a set consisting targetNamespace
[attribute] of
the
a set whose members are namespace
names corresponding to the space-delimited substrings of
the if one such substring is
if one such substring is namespace
or
notNamespace
##targetNamespace
, the corresponding
member is the targetNamespace
##local
, the
corresponding member is
notQName
notQName
If the item is a
If the item is the token
,
then the keyword ##defined
If the item is the token
,
then the keyword ##definedSibling
notQName
processContents
When this rule is used for an attribute wildcard (see
Wildcards are subject to the same ambiguity constraints
(
In addition to the conditions imposed on The corresponding particle and model group satisfy the
conditions set out in namespace
and
notNamespace
attributes namespace
and notNamespace
are
not both present;
For an element or attribute information item to be locally
When this constraint applies
the item has no the item's the item's
When an element or attribute information
item is
For a The namespace name is C. C. W is an element wildcard (i.e., W appears in a
content model) E does not W is an attribute wildcard E does not
C.
W is an element wildcard
The item having E as its name is an element information item (call it I)
I has a
I and P have the same
P has an
E does not
Informally, the keyword
For a value The constraint The constraint is The value The value The constraint is
None
All wildcards (see
The values of the properties of a wildcard
If
If
The namespace name of each
Attribute wildcards do not contain
The following constraints define a relation appealed to elsewhere in this specification.
Both Both
And Each
If
If
either both the two either
the set the set the set the union is not expressible. the set whichever of either
the set the set
The O, O1, and O2 all have
the same Either O1 O, O1, and O2 all have
The intersection of the
O Either O1 or O2 has
The set difference S1 minus S2 is the empty set, and
O
O
The
The keyword
In the case where there are more than two
either either both the intersection of the two the intersection is not expressible. the one
The O, O1, and O2 have
the same Either O1 or O2 has O, O1, and O2 all have O, O1, and O2 all have
Either O1 or O2 has
The
The keyword
In the case where there are more than two
Identity-constraint definition components provide for uniqueness and reference constraints with respect to the contents of multiple elements and attributes.
XML representations for the three kinds of identity-constraint definitions.
The identity-constraint definition schema component has the following properties:
Identity-constraint definitions are identified by their
Informally, ( ( (
These constraints are specified along side the specification of types for the
attributes and elements involved, i.e. something declared as of type integer
3.0
and 3
would be conflicting keys if they were both
Overall the augmentations to XML's ID/IDREF
mechanism are:
Functioning as a part of an identity-constraint is in addition to, not instead of, having a type;
Not just attribute values, but also element content and combinations of values and content can be declared to be unique;
Identity-constraints are specified to hold within the scope of particular elements;
(Combinations of) attribute values and/or element content can be declared to be keys, that is, not only unique, but always present and non-nillable;
The comparison between
In order to reduce the burden on implementers, in particular
implementers of streaming processors, only restricted subsets of XPath
expressions are allowed in
Provision for multi-field keys etc. goes beyond what is supported by xsl:key
.
In
See
The XML representation for an identity-constraint definition schema
component is either a
ref
name
targetNamespace
schema
xpath
xpath
refer
ref
ref
A state
element is defined, which
contains a code
child and some vehicle
and person
children. A vehicle
in turn has a plateNumber
attribute,
which is an integer, and a state
attribute. State's
code
s are a key for them within the document. Vehicle's
plateNumber
s are a key for them within states, and
state
and
plateNumber
is asserted to be a vehicle
within the document as a whole. Furthermore, a person
element has
an empty car
child, with regState
and
regPlate
attributes, which are then asserted together to refer to
vehicle
s via the carRef
constraint. The requirement
that a vehicle
's state
match its containing
state
's code
is not expressed here.
A list of state
elements can appear as child elements
under stateList
. A code
. We already
defined a state
"). We can reuse it
directly via the ref
attribute on the key
element.
In addition to the conditions imposed on
One of
If
If
If
If ref
or name
is present, but not both.
name
is present, then name
is present on refer
is also present.
ref
is present, then only id
and ref
.
ref
is present, then the
ref
For an element information item Each node in the For each node in the The use of
the no two members of the the
The No two members of the No element member of the the for each member of the
The use of
For
Because the validation of
Although this specification defines a
For purposes of checking identity-constraints, single atomic values are not distinguished from lists with single items. An atomic value V and a list L with a single item are treated as equal , for purposes of this specification, if V is equal to the atomic value which is the single item of L.
Whenever an element information item has one or more
There is an entry in one of the
The complexity of the above arises from the fact that
The
All identity-constraint definitions (see
The values of the properties of an identity-constraint definition
If the
The
It
Itchild
axis whose abbreviated
form is as given above.
For readability, whitespace
When tokenizing, the longest possible token is always returned.
Each member of the
It Itchild
and/or attribute
axes whose abbreviated form is
as given above.
For readability, whitespace
When tokenizing, the longest possible token is always returned.
Type Alternative components provide associations between boolean
conditions (as XPath expressions) and
The type alternative schema component has the following properties:
Type alternatives can be used by an
The XML representation for a
Each
test
type
complexType
or simpleType
among the
In addition to the conditions imposed
on type
attribute, or a complexType
child element, or a
simpleType
child element. No
An instance of the
An information set is constructed by copying
E itself.
E's
E's
An
The XPath expression
which is the value of the
true
and false
.
As a consequence of the rules just given, the root node of the
None.
All type alternatives (see
The values of the properties of a type alternatives
If the The Constructor functions for the built-in datatypes.
A conforming processor
Any XPath expression valid according to
An XPath expression belongs to the required subset of XPath if and only
if
The
It conforms to the following extended BNF:
It is an XPath expression involving the
For readability,
If part of the restricted XPath matches
If part of the restricted XPath matches
Any explicit casts (i.e. any strings which match
the optional attribute
axis
whose abbreviated form is as given above.
QName
in the
QName
in the
cast as
Implementations
The rule given above for the construction of the data model
instance has as a consequence that even when implementations
support full
Assertion components constrain the existence and values of related elements and attributes.
The XML representations for assertions.
The
The assertion schema component has the following properties:
true
or false
(if any other value is returned, it's converted to
either true
or false
as if by a call to the XPath
See
The XML representation for an assertion schema component is
an
The
Assertions, like identity constraints and conditional type
assignment, use
xpathDefaultNamespace
xp athDefaultNamespace
##defaultNamespace
there is an entry in the
the corresponding
##targetNamespace
the its targetNamespace
##local
(
The value of the min
attribute must be less than or equal to
that of the max
attribute.
The value of the length
attribute must be the same as
the number of occurrences of entry
sub-elements.
None
true
(see below) without raising
any
Evaluation of
E is validated
It is a consequence of this rule that the A Since the assertions of its From the It is a consequence of this construction that attempts
to refer, in an assertion, to the siblings or ancestors of
E, or to any part of the input document outside of E
itself, will be unsuccessful.partial
partial
The root node of the The
The variable
E's
E's
the
the
This clause provides type information to simple contents
of elements, to make type-aware comparisons and
operations possible without explicit casting in the
XPath expressions.
For complex types with simple content, the element node
may be referred to as (in the
,
as described in
$value
appears as a member
of the $value
expanded QName
of that member has no namespace URI and has
as the local name.
The value
value
of the member is determined by partial
partial
value
is the
, while
its content may be referred to as
.
. Since the element node,
as a consequence of $value
anyType
, its untypedAtomic
. By contrast,
$value
will be a sequence of one or more
atomic values, whose types are the most specific
(narrowest) built-in types available.partial
value
is the empty sequence.
true
or false
as if by a call to the XPath
Although the rules
An The The The The The The The The The The
For interoperability, it is recommended that XPath processors
intending to support precisionDecimal as an additional
primitive data type follow the recommendations in xs:precisionDecimal
in the data model instance
and handled accordingly in XPath.
If the XPath processor does not support precisionDecimal,
As a consequence of the above variability, it is possible that XPath expressions that perform various kinds of type introspections will produce different results when different XPath processors are used. If the schema author wishes to ensure interoperable results, such introspections will need to be avoided.
None
All assertions (see
The values of the properties of an assertion are as
described in the property tableau in
The expanded QName
of that
member has no namespace URI and has value
as the local
name. The (static) type
of the member is
anyAtomicType*
The XDM type label anyAtomicType*
simply says
that for static typing purposes the variable $value
will have a value consisting of a sequence of zero or more
atomic values.
For an
The
X does not produce any
The
The The The The The The The The The
The The The The The http://www.w3.org/2005/xpath-functions
.http://www.w3.org/2005/xpath-functions/collation/codepoint
)
defined by
Notation declarations reconstruct XML
The XML representation of a notation declaration.
The notation declaration schema component has the following properties:
Notation declarations do not participate in
See
The XML representation for a notation declaration schema component is
a
The
name
targetNamespace
schema
system
public
In addition to the conditions imposed on
None
None
Whenever an attribute information item is
or
For compatibility, only one such attribute
Element as well as attribute information items may be
All notation declarations (see
The values of the properties of a notation declaration
Annotations provide for human- and machine-targeted annotations of schema components.
XML representations of three kinds of annotation.
The annotation schema component has the following properties:
source
attribute of the
respective element information items. xml:lang
attribute.
Annotations do not participate in
The name
Annotation of schemas and schema components, with material for human or
computer consumption, is provided for by allowing application information and
human information at the beginning of most major schema elements, and anywhere
at the top level of schemas. The XML representation for an annotation schema component is
an
The
The annotation component corresponding to the
Virtually every kind of schema component defined in this specification
has an
For every As described above (earlier in this section),
the
If there are any attribute information items
among the
AS contains no other
The order of
When the input set has more than one
member, the
In addition to the conditions imposed on
None
None
None
All annotations (see
The values of the properties of an annotation
This section consists of a combination of
Simple type definitions provide for constraining character information item
The XML representation of a simple type definition.
The simple type definition schema component has the following properties:
Simple types are identified by their
The
A simple type definition with an empty specification for
As described in xs:anySimpleType
xs:anyAtomicType
xs:anyAtomicType
The
Constraining facets are defined in
As specified in
A
xs:anySimpleType
xs:anyAtomicType
See
This section reproduces a version of material from
The
The effect of the special handling of
The following subsections define one set of common mapping
rules for simple type definitions, and three specialized
sets of mapping rules for atomic, list, and union datatypes,
respectively.
If the If the If the
The following rules apply to all simple type definitions.
name
targetNamespace
the
the type definition base
the
xs:anySimpleType
final
and finalDefault
block
and blockDefault
{
}
.{
}
, determined as follows.
the empty set;
#all
{
}
;
Consider
is in that list, and similarly for
restriction
the
the parent element information item is the corresponding the parent element information item is the corresponding the parent element information item is the (the parent element information item is the grandparent element information item is the (the grandparent element information item is
the
a set of
the
the children of the
the
the
a set with one member, a
the empty set
A sequence of
the If the If the If the
If the
the
the itemType
the
the
the xs:anySimpleType
the itemType
itemType
(that is, the In this case, a xs:anySimpleType
If the
the
memberTypes
the
the
the xs:anySimpleType
memberTypes
memberTypes
(that is, the In this case, a xs:anySimpleType
In addition to the conditions imposed on With the exception of The corresponding simple type definition, if any, If the If the
If the base
itemType
memberTypes
simpleType
memberTypes
For a string The every whitespace-delimited substring of
no further condition applies.
.
None
All simple type definitions
The values of the properties of a simple type
definition
All simple type definitions xs:anySimpleType
xs:anySimpleType
The
There
Each member of
As specified normatively elsewhere, all conforming
processors
Either D is
The type
For each facet in If there is a facet of the same kind in
B. Only All facets in For each facet in All facets in The first case above will apply when a list is
The
All of the
B. The Each type definition in
D. Only All facets in For each facet in All facets in The first case above will apply when a union is
xs:anyAtomicType
xs:anyAtomicType
xs:anySimpleType
xs:anySimpleType
xs:anySimpleType
The following constraint defines relations appealed to elsewhere in this specification.
For a simple type definition (call it They are the same type definition. The It is a consequence of this requirement that the xs:anyType
xs:anySimpleType
With respect to
When a simple type definition S is said to be
validly
from a type definition T,
without mention of any specific set of blocking keywords,
then what is meant is that S is validly derived from
T, subject to the empty set of blocking keywords,
i.e. without any particular limitations.
It is a consequence of
For a simple type definition (call it The If The The Additional constraint(s)
Every facet in
Every facet in Every facet in
xs:anySimpleType
xs:anyType
The xs:anySimpleType
xs:anyType
xs:anyAtomicType
xs:anySimpleType
xs:error
A xs:error
xs:error
xs:anySimpleType
The datatype xs:error
has no valid instances
(i.e. it has an empty value space and an empty lexical space).
This is a natural consequence of its construction: a value is
a value of a union type if and only if it is a value of at
least one member of the xs:error
has
no member type definitions, there can be no values which are
values of at least one of its member types. And since the value
space is empty, the lexical space is also empty.
The type xs:error
is expected to be used
mostly in conditional type assignment. Whenever it serves as the
Simple type definitions http://www.w3.org/2001/XMLSchema
), have an
xs:anyAtomicType
[as appropriate]
All conforming implementations of this specification
By their nature, primitive types can be supported by a
processor only if
Types
The definition of
is not
intended to prevent implementations from allowing users
to specify new primitive types.
If an implementation defines a mechanism by which users can
define or supply an implementation of a primitive type, then
when those mechanisms are successfully used, such user-supplied
types are
Similarly, simple type definitions
All conforming implementations of this specification
A schema consists of a set of schema components.
The XML representation of the skeleton of a schema.
At the abstract level, the schema itself is just a container for its components.
A schema is represented in XML by one or more
The
Note that none of the attribute information items displayed above
correspond directly to properties of schemas. The blockDefault
,
finalDefault
, attributeFormDefault
, elementFormDefault
and targetNamespace
attributes are appealed to in the sub-sections above, as they provide
global information applicable to many representation/component correspondences. The
other attributes (id
and version
) are for user
convenience, and this specification defines no semantics for them.
The definition of the schema abstract data model in targetNamespace
attribute.
Since the empty string is not a legal namespace name, supplying
an empty string for targetNamespace
is incoherent, and is targetNamespace
attribute specified at all.
Although the example schema at the beginning of this section might be a complete XML document,
Aside from
Reference to schema components from a schema document is managed in
a uniform way, whether the component corresponds to an element
information item from the same schema document or is imported
(
It is
In each of the XML
representation expositions in the following sections, an attribute is shown as
having type QName
if and only if it is
interpreted as referencing a schema component.
The first of these is most probably a local reference, i.e. a reference
to a type
definition corresponding to a
The names of schema components such as type definitions and element
declarations are not of type
There is currently no provision in the definition of the interpretation
of fragment identifiers for the text/xml
MIME type, which is the
MIME type for schemas, for referencing
schema components as such. However,
#xpointer(xs:schema/xs:element[@name="person"])
will uniquely identify
the representation of a top-level element declaration with name person
, and similar fragment
identifiers can obviously be constructed for the other global symbol spaces.
Short-form fragment identifiers id
attribute for the representations of all primary and secondary schema
components, which
It is a matter for applications to specify whether they interpret document-level references of either of the above varieties as being to the relevant element information item (i.e. without special recognition of the relation of schema documents to schema components) or as being to the corresponding schema component.
None
Where the type of an attribute information item in a document involved in
its
There its Its (its its there is a namespace in the its its ':'
).
In the absence of the
For a That component is a member of the value of the appropriate
property of the schema which corresponds to the schema
document within which the the kind specified is simple or complex type definition the property is the the kind specified is attribute declaration the property is the the kind specified is element declaration the property is the the kind specified
is attribute group the property is the the kind specified is
model group the property is the the kind specified is notation declaration the property is the The
component's The component's the
The The
the The The targetNamespace
namespace
targetNamespace
namespace
As the discussion above at
A
pair of a local name and a namespace name (or the kind specified is simple or complex type definition the property is the the kind specified is attribute declaration the property is the the kind specified is element declaration the property is the the kind specified
is attribute group the property is the the kind specified is
model group the property is the the kind specified is notation declaration the property is the
None
Schema components provide a wealth of information about the
basis of
Accordingly,
targetNamespace
matches the sibling targetNamespace
was targetNamespace
as per
The
In the
its it was successfully
its
if it is an element information item, then
The use of
Then there is one
the
Each
its
it has an attribute information item in
its
The net effect of the above is to have one entry for every string used as an
id, whether by declaration or by reference, associated with those elements, if
any, which actually purport to have that id. See
The
All schemas (see
The values of the properties of a schema
For a That component is a member of the value of the appropriate
property of the schema which corresponds to the schema
document within which the the kind specified is simple or complex type definition the property is the the kind specified is attribute declaration the property is the the kind specified is element declaration the property is the the kind specified
is attribute group the property is the the kind specified is
model group the property is the the kind specified is notation declaration the property is the The
component's The component's the
The The
the The The
targetNamespace
namespace
targetNamespace
namespace
http://www.w3.org/2001/XMLSchema
.
http://www.w3.org/2001/XMLSchema-instance
.
As the discussion above at
A pair of a local name and a namespace name (or the kind specified is simple or complex type definition the property is the the kind specified is attribute declaration the property is the the kind specified is element declaration the property is the the kind specified
is attribute group the property is the the kind specified is
model group the property is the the kind specified is notation declaration the property is the
This chapter defines the mechanisms by which this specification establishes the necessary
precondition for
The
Schema representation: the connections between XML representations and schema components, including the relationships between namespaces and schema components;
Layer 1 specifies the manner in which a schema composed of schema components
can be applied to in the
The fundamental purpose of the
As specified above, each schema component is associated directly or indirectly with a target namespace, or explicitly with no namespace. In the case of multi-namespace documents, components for more than one target namespace will co-exist in a schema.
Processors have the option to assemble (and perhaps to optimize or
pre-compile) the entire schema prior to the start of an
The processor succeed in locating the
no definition or declaration changes once it has been established;
if the processor chooses to acquire declarations and definitions
dynamically, that there be no side effects of such dynamic acquisition that
would cause the results of
the
The obligation of a schema-aware processor as far as the
Although
The sub-sections of
The core
In the sections below, "schemaLocation" really belongs at layer 3. For convenience, it is documented with the layer 2 mechanisms of import and include, with which it is closely associated.
Whenever a conforming XSD processor reads a
Every element in the
Where they appear, the
attributes xs:decimal
, and their
If
Where they appear, the attributes list of xs:QName
, and the items in their
If an element in a schema document has any of the following:
It is expected that
The
The xs:pattern
for the
It is a consequence of the rules given above that
if the vc:typeAvailable=""
), then the corresponding element
is
The pre-processing of a schema document S1 results
in a second schema document S2, identical to S1
except that all elements <schema>
element information item in S1 is to be ignored, then S2 is identical
to S1 except that any attributes other than
If S1 contains no elements
Except where conditional-inclusion pre-processing is
explicitly mentioned, references to
Suppose some future version of XSD (say, version 3.2)
introduces a new form of element declaration. A schema author
might wish to exploit that new form of declaration if
possible, but wish also to ensure that the schema
document can be handled successfully by a processor
written for XSD 1.1. In such a case, a schema document
of the following form would be handled correctly by a
conforming XSD 1.1 processor:
Even though the schema document as shown has two element
declarations for element
Note that the semantics of the
Suppose that a processor supports an xpath_expression
in namespace
,
and is presented with the following schema document:
http://example.org/extension_types
The effect of conditional inclusion is to include the
first declaration for
A processor which does not support type tns:xpath_expression
,
by contrast, will use the other declaration for
Whenever the attribute xs:decimal
as per
Whenever any of the attributes
xs:QName
, as per
Any attribute from the
Processors are encouraged to issue warnings about
vc:
namespace that appears
on an element information item in a
vc:
attributes other than those named,
but it is not an error for such
attributes to appear in a
and not
a
in order to preserve the ability of
future versions of this specification to add new attributes
to the schema-versioning namespace.
<include>
)Schema components for a single target namespace can be
assembled from several
A schemaLocation
attributes, consisting of a URI
reference, identify other
If two
targetNamespace
as targetNamespace
at all,
in which case targetNamespace
In addition to the conditions imposed on If the It resolves to (a fragment of) a resource which is an
XML document (of type It resolves to a Neither
The schema corresponding to
Let The transformation in
The schema corresponding to
The above rule applies recursively. For example, if
The The In this case, it is
If schemaLocation
application/xml
or
text/xml
with an XML declaration for
preference, but this is not required), which in turn
corresponds to a targetNamespace
targetNamespace
targetNamespace
targetNamespace
targetNamespace
targetNamespace
targetNamespace
targetNamespace
targetNamespace
targetNamespace
code
was
It is schemaLocation
As discussed in
The above is carefully worded so that multiple
If there is a sequence of schema documents S1, S2, ... Sn,
and a sequence of
Informally:
<redefine>
)The redefinition feature described in the remainder of this
section is
In order to provide some support for evolution and versioning, it is
possible to incorporate components corresponding to a schema document
A schemaLocation
attributes, consisting of a URI reference, identify other
The targetNamespace
as the targetNamespace
at all, in which case the targetNamespace
.
The definitions within the Type
definitions
Attribute
group definitions and model group definitions
This mechanism is intended to provide a declarative and modular approach to
schema modification, with functionality no different except in scope from what
would be achieved by wholesale text copying and redefinition by editing. In
particular redefining a type is not guaranteed to be side-effect free: it
The pervasive impact of redefinition reinforces the need for implementations to adopt some form of lazy or 'just-in-time' approach to component construction, which is also called for in order to avoid inappropriate dependencies on the order in which definitions and references appear in (collections of) schema documents.
The schema corresponding to v2.xsd
has everything specified
by v1.xsd
, with the personName
type redefined, as
well as everything it specifies itself. According to
this schema, elements constrained
by the personName
type generation
element. This includes not only the author
element, but also the
addressee
element.
In addition to the conditions imposed on If there are any element information items among the
If the it resolves to (a fragment of) a resource which is an
XML document (see It resolves to a Neither
The schema corresponding to
Let
The schema corresponding to In this case, it is Within the Within the it has a
It The it has no such self-reference
The The Within the it has an it it has no such self-reference
The The An attribute group restrictively redefined per
schemaLocation
schemaLocation
targetNamespace
targetNamespace
targetNamespace
targetNamespace
targetNamespace
restriction
or extension
among its
grand-base
name
attribute plus target namespace;ref
name
attribute plus
target namespaceminOccurs
and maxOccurs
1
(or name
attribute
plus target namespace ref
name
attribute plus
target namespacename
attribute
plus target namespace
Corresponding to each non-
The
One component which corresponds to the top-level definition item with
the same name
in
the
One component which corresponds to the information item itself, as defined
in
This pairing ensures the coherence constraints on type definitions
are respected, while at the same time achieving the desired effect, namely that
references to names of redefined components in both the
The ref
name
plus target namespace is
In all cases there
The above is carefully worded so that multiple equivalent
<override>
)
The <redefine>
construct defined
in
The name of the
to denote the relation between an
A schemaLocation
attributes, consisting of a URI reference, identify
point to
)
The targetNamespace
as the
overriding schema document, or (b) no targetNamespace
at all, in
which case the overridden schema document is converted to the overriding schema
document's targetNamespace
.
The
The schema document identified by the The schema document identified by the The schema document identified by the schemaLocation
attribute of E.schemaLocation
attribute of any schemaLocation
attribute of any
The
Source declarations not present in the target set of E cannot
be overridden, even if they are present in other schema
documents consulted in the creation of the schema (e.g. in
schema documents pointed to by a
It is
If applying the override transformation specified in
If applying the override transformation to D and E changes
any of the XML representations of components, then the effect of
D being in the As if
is inexact; in this case what happens is, precisely,
that two schema documents with conflicting contents are
included.)
The definitions within the
As this mechanism is very similar to
The schema corresponding to v1.xsd
has a complex type named
personName
with a sequence of firstName
and lastName
children. The schema corresponding to v2.xsd
overrides personName
, by providing a different sequence of
element children. All elements with the personName
type are
now constrained to have the sequence of givenName
and
surname
. This includes not only the author
element, but also the addressee
element.
In addition to the conditions imposed on
If there are any element information items among the
If the
It resolves to (a fragment of) a resource which is an XML document (see
It resolves to a
Neither
Let
The It is not necessary to perform a literal replacement
of the One effect of the rule just given is that
the schema corresponding to Another effect is that if schema document A contains
a source declaration for a component E, and schema document B
overrides A with its own declaration for E,
and schema document C in turn overrides B with a
third declaration for E, then
First, the override of B by C is handled. The
resulting schema document still contains an
Then, the override of A by (the modified version of) B
is handled. The resulting version of A, containing
the declaration for E originally present in C,
is included by the modified version of B,
which is itself included by C.
The resulting schema contains
the version of E originally specified in
schema document C.
Let
The
For each non-schemaLocation
schemaLocation
targetNamespace
targetNamespace
targetNamespace
targetNamespace
first
and
next
here refer to the logical precedence
of operations, not to a required order in which implementations
are required to perform particular tasks.)
The effect of applying the stylesheet in
It is
In
The above is carefully worded so that multiple equivalent overrides of the
same schema document will not constitute a violation of
It is a consequence of the semantics of inclusion, as
defined in
<import>
)As described in
Some users of schemaLocation
attribute.
Although the function of
Two things are required: not only a means of addressing such foreign components but also a signal to schema-aware processors that a schema document contains such references:
The targetNamespace
.
At least two conditions must be satisfied for a
reference to be made to a foreign component: there must be not only a
means of addressing such foreign components but also a signal to
schema-aware processors that a schema document contains such
references. Thus, the targetNamespace
.
By contrast, a namespace used for other purposes in a schema document
need not be imported. There is no need, for example, to import the
namespace of a vocabulary such as HTML for use in schema
The schemaLocation
attribute
The same namespace xhtml:p
.
The schemaLocation
schemaLocation
schemaLocation
Conformance profiles may further
restrict the use of the schemaLocation
attribute. For example,
one profile might mandate that the hint be
honored by the schema software, perhaps calling for a
processor-dependent error should the URI fail to resolve,
or mandating that the hint agree with some expected URI value;
another profile might mandate that the hint not
be honored,
etc.
Since both the namespace
and schemaLocation
<import/>
information item
is allowed. This simply allows unqualified reference to foreign
components with no target namespace without giving any hints as to where to find them.
In addition to the conditions imposed on the its the the enclosing If the application schema reference strategy The The If there is a its there is no namespace
targetNamespace
namespace
targetNamespace
schemaLocation
and namespace
namespace
targetNamespace
namespace
targetNamespace
It is
The
The above is carefully worded so that multiple schemaLocation
schemaLocation
, but such a strategy risks
missing useful information when new schemaLocation
s are
offered.
Layers 1 and 2 provide a framework for
For interoperability, serialized
there will often be times when a schema document will be a
complete XML
The variations among server software and web site administration policies
make it difficult to recommend any particular approach to retrieval requests
intended to retrieve serialized Accept
header of application/xml,
text/xml; q=0.9, */*
is perhaps a reasonable starting point.
As described in
As discussed above in
Processors on the Web are free to undertake unless directed otherwise by the user, unless directed otherwise by the user, the
processor is required to construct a schema corresponding to a schema document
whose targetNamespace
is
identical to the
namespace name, if any, of the element information item on which
The composition of the complete
schema for use in
Schemas are represented on the Web in the form specified above in
The author of a document uses namespace declarations to
indicate the intended interpretation of names appearing therein;
Experience suggests that it is not in all cases safe or desirable from
a performance point of view to dereference namespace names as a matter of course. User community and/or
consumer/provider agreements may
establish circumstances in which such dereference is a sensible
default strategy: this specification allows but does not require particular communities to
establish and implement such conventions. Users are always free to supply namespace names as schema location information when dereferencing
On the other hand, in case a document author (human or not) created a
document with a particular schema in view, and warrants that some or
all of the document conforms to that schema, the
schemaLocation
and noNamespaceSchemaLocation
http://www.w3.org/2001/XMLSchema-instance
) (hereafter
xsi:schemaLocation
and
xsi:noNamespaceSchemaLocation
) are provided. The first records
the author's warrant with pairs of URI references (one for the namespace name, and
one for a hint as to the location of a schema document defining names for that
namespace name). The second similarly provides a URI reference as a hint as to
the location of a schema document with no targetNamespace
xsi:schemaLocation
and xsi:noNamespaceSchemaLocation
When schema location values (i.e. schemaLocation
attributes on
xsi:schemaLocation
and xsi:noNamespaceSchemaLocation
attributes in instance documents) are dereferenced and the values are relative
references, then the
xsi:schemaLocation
and
xsi:noNamespaceSchemaLocation
Multiple schema bindings can be declared using a single attribute. For example consider a stylesheet:
The namespace names used in schemaLocation
can, but need not
be identical to those actually qualifying the element within whose start tag
it is found or its other attributes. For example, as above, all
schema location information can be declared on the document element
of a document, if desired,
regardless of where the namespaces are actually used.
Given a namespace name (or none) and (optionally) a URI reference
from
Do nothing, for instance because a schema containing components for the
given namespace name is already known to be available, or because it
is known in advance that no efforts to locate schema documents will be successful
(for
example in embedded systems);
Based on the location URI,
identify an existing schema document,
either as a resource which is an XML document or a
Based on the namespace name, identify an existing schema document,
either as a resource which is an XML document or a
Attempt to resolve the location URI,
to locate a
resource on the web which is or contains or references a
Attempt to resolve the namespace name to locate such a resource.
xsi:schemaLocation
or xsi:noNamespaceSchemaLocation
,
schema-aware processors
Improved or alternative conventions for Web interoperability can be standardized in the future without reopening this specification. For example, the W3C is currently considering initiatives to standardize the packaging of resources relating to particular documents and/or namespaces: this would be an addition to the mechanisms described here for layer 3. This architecture also facilitates innovation at layer 2: for example, it would be possible in the future to define an additional standard for the representation of schema components which allowed e.g. type definitions to be specified piece by piece, rather than all at once.
The architecture of schema-aware processing allows for a rich characterization of XML documents: schema validity is not a binary predicate.
This specification distinguishes between errors in schema construction and structure, on the one hand, and schema validation outcomes, on the other.
Before xsi:schemaLocation
and
xsi:noNamespaceSchemaLocation
It is an error if a schema and all the components which are the
value of any of its properties, recursively, fail to satisfy all
the relevant Constraints on Schemas set out in the last section
of each of the subsections of
If a schema is derived from one or more schema documents (that
is, one or more It is an error if any such schema document would not be
fully valid with respect to a schema corresponding to the
It is an error if any such schema document is or contains
any element information items which violate any of the
relevant Schema Representation Constraints set out in
The three cases described above are the only types of error
which this specification defines. With respect to the processes
of the checking of schema structure and the construction of
schemas corresponding to schema documents, this specification
imposes no restrictions on processors
With a schema which satisfies the conditions expressed in
The user or application identifies a Top-level (named) types The user or application identifies a Top-level elements
The user or application identifies an attribute declaration from
among the The processor starts from The name for this method of
invocation reflects the fact that it is analogous to the validation of
an element information item which matches a The processor starts from From the point of view of schema-validity assessment and the
resulting
In typical cases strict wildcard validation will be
performed when the invoking process expects the
The name for this method of invocation
reflects the fact that it is analogous to the
validation of an element information item which matches a
xsi:type
) or notxsi:type
), then
For type-, element-, and attribute-driven validation,
there is no requirement that the declaration or definition
identified by the user or application be a top-level
component of the schema. Mechanisms for referring to
other components are out of scope for this specification,
but see
The outcome of
Note that every element and attribute information item
participating in the
This specification does not reconstruct the XML
This specification has nothing normative to say about multiple
At the beginning of
If at any time during
In the case of
attribute information items, the effect is as if
In the case of
element information items, the effect is as if
In the case of element information items, processors
Because of the value specification for
References in a
Schema-aware processors are responsible for processing XML documents,
schemas and schema documents, as appropriate given the level of conformance
(as defined in
The XML representation of the schema for schema documents is
presented here as a normative part of the specification, and as an
illustrative example of how the
There is some annotation in comments, but a fuller annotation will require the use of embedded documentation facilities or a hyperlinked external annotation for which tools are not yet readily available.
Since a schema document is an XML document,
it has optional XML and doctype declarations that are provided here for
completeness. The root schema
element defines a new schema.
Since this is a schema for targetNamespace
references the
Like any other XML document, schema
documents may carry XML and document type declarations. An XML
declaration and a document type declaration are provided here for
convenience. Since this schema document describes the targetNamespace
attribute on the
schema
element refers to the
Schema documents conforming to this specification may be in XML
1.0 or XML 1.1. Conforming implementations may accept input in
XML 1.0 or XML 1.1 or both. See
And that is the end of the schema for schema documents.
To facilitate consistent reporting of schema errors and cos-ct-extends.1.2
This section defines some terms for use in describing
choices made by implementations in areas where the
effect of
Future versions of this specification are expected to use the terminology defined here to specify conformance profiles. Conformance profiles may also be defined by other specifications without requiring any revision to this specification.
This specification defines a number of ways in which the
information set taken as input is augmented in the course
of schema-validity assessment. Conforming processors if applicable
or where applicable
below are simply the most obvious
cases of properties which do not apply to every information item;
the same qualification implicitly applies to all properties listed
below.)
If other subsets of the PSVI prove important in practice it is
expected that definitions of those subsets
The definition in this section of a term denoting a particular subset of the PSVI does not constitute a requirement that conforming processors provide access to that subset.
In a future draft of this specification, it is expected that
a list of specific component properties to which access
The
In exposing element declarations, attribute declarations, type definitions, and other components, processors providing access to the full subset must provide some representation for all of the defined properties of the components. Note that although the properties are often redundant with other information, it is not required that the full subset include more than one representation of redundant information.
The PSVI is a description of an information set,
not a specification of a data structure or an application-programming
interface. For convenience, this specification defines
in some cases more than one term for denoting a particular
piece of information: for example,
the
Similar observations can be made for other properties present in
the full-instance subset but not mentioned here. Processors
Conforming processors
The terminology offered here is intended to be useful in discussions of processor behavior, whether documenting existing behavior or describing required behavior.
General-purpose processors
Some terms describe how a processor identifies locations from
which schema components can be sought:
Full knowledge of one or more schemas is
built into the processor. (Note: all processors are
required to have some built-in knowledge of
of the built-in components.
Full knowledge of one or more components is
built into the processor; these components
All processors are
required to have some built-in knowledge of
of the built-in components.
A list of locations at which
schema documents will be sought is built into the processor.
Particular locations can be associated with specific
namespaces or can be used to seek any schema document.
At invocation time, the user passes a set or
sequence of (namespace-name, schema document) pairs to the
processor, e.g. as a command-line option. (Can be used with
early or slow exit strategy.) The namespace name is used
as a check on the document, not as an instruction; if the
schema document has a target namespace which differs from
the namespace name specified, the processor signals an error.
At invocation time, the user passes a set or sequence of schema
documents, or identifiers for schema documents (e.g. URIs), to the
processor, e.g. as a command-line option. Each schema document
is associated with its target namespace, if any.
(Can be used with early or
slow exit strategy.)
For each namespace, the processor asks
the user interactively (though mechanisms not specified
here) where to seek the required schema components.
This will perhaps be most useful as a fallback after other methods
have failed.
For each namespace, the processor attempts
to dereference the namespace name; if a schema document is
returned, it is processed. If some other kind of resource representation is
returned, processors For example, if a RDDL document is returned,
a processor
For each namespace, if the input
document includes one or more schemaLocation hints for that
namespace, the processor attempts to dereference those
locations.
For each namespace, if a schema document being processed
includes one or more schemaLocation hints for that
namespace (e.g. on an
For each namespace, a local repository of
schema components is consulted. In some situations the consultation
will require a key, in which see the terminology for indirection
given below.
and then attempt to dereference the location(s) indicated on the
http://www.w3.org/2001/XMLSchema
import
element,
the processor attempts to dereference those
locations.
Some terms describe various methods of indirection through
local catalogs, search paths, or local repositories of schema
documents and/or schema components. In each of these, a
‘search key’ is assumed which helps to control the
indirection. Terms for different sorts of search key are
defined below.
The processor has (hard-coded or accepted
as a parameter at invocation time or acquired from the
environment) a series of expressions into which a search key
is substituted. After substitution, each element of the
series is interpreted as a file-system path and a schema
document is sought at the location indicated by that path.
The processor has (hard-coded or accepted
as a parameter at invocation time or acquired from the
environment) a series of expressions into which a search key
is substituted. After substitution, each element of the
series is interpreted as a URI and a schema document is
sought at the location indicated by that path.
The processor consults an OASIS catalog
(whose location can be hard-coded, passed as a parameter at
invocation time or acquired from the environment) using a
search key. The key can be sought for as a namespace name,
as a public identifier, or as a system identifier.
A local repository of schema
components is consulted using a search key.
The location(s) returned by a catalog or other
indirection mechanism are not consulted immediately but
instead used as a key in a renewed indirection. Only after
the indirection mechanism fails to return a value is an
attempt made to dereference the last location returned.
The location(s) returned by a catalog or
other indirection mechanism are consulted immediately; they
are not used in recursive indirections.
Locating schema components by means of any of the ‘indirect’
methods just identified will sometimes involve the specification of a
value of some kind as a search key. Processors
The namespace name is used as a key.
A location (e.g. a schema location hint or the
location specified in a catalog or by the user) is used as a
key.
When more than one location is available for a given
namespace, two distinct behaviors can be distinguished; these
are orthogonal to other terms defined here:
When more than one location is available for a
given namespace, the processor attempts each in turn. When
a location is successfully dereferenced and a schema
document is obtained, the later locations on the list are
ignored.
When more than one location is available for a
given namespace, the processor attempts each in turn. All
locations are tried, even if a schema document for the
namespace has been obtained.
When a processor seeks schema components at a particular
location, but fails to find components of the namespace
in question at that location, several different
ways of responding to that failure can be distinguished:
The processor signals an error in some manner appropriate
to its construction and environment. Some processors
and some users will find it useful to distinguish fatal errors (which
cause processing to halt) from recoverable errors.
The processor signals no fatal error and continues its search
for components in the namespace in question by attempting
another location.
This section defines terms intended to be useful in describing other implementation-defined choices.
The datatypes defined by
The datatypes defined by
This specification requires as a precondition for
In addition, infosets
This specification does not require any destructive alterations to the input information set: all the information set contributions specified herein are additive.
This appendix is intended to satisfy the requirements for
This appendix provides a summary of
In describing the choices made for a given processor,
it is hoped that the terminology defined in
For the datatypes defined by
It is
processors and
processors.)
Whether a
processors
as
The way in which a processor is invoked, and the way in
which values are specified for the schema to be used,
the information item to be validated,
and the declaration or definition with which to begin
validation, is
The manner in which a processor provides access to the
information items and properties in the PSVI to any
downstream or user applications, or to the invoker,
is
The
information items and properties in the PSVI to which
the processor provides access, if any, is
When the
The method used for assembling a set of schema components
for use in validation is
It is
Everything
This includes, but is not limited to, the choice
of
It is
This appendix provides a summary of
When a default value of type
When a default value is supplied for a defaulted attribute and
When a default value is supplied for a defaulted attribute and
When a default value is supplied for a defaulted attribute and
If more than one
If more than one
The order of
If a name is supplied for anonymous components
If a processor detects
some violations of
The transformations specified in the following sections
in the form of
When a
Add a
Update all QName references in targetNamespace
targetNamespace
targetNamespace
xs:override
overrideElement
parameter
and (b)
the overriddenSchema
parameter.
The transformation
produces another
For each element information item E2 in the E2 has element type E2 has element type a child of E2 and a child of O1 match as described
in O2 has
a child identical to the child of O1. a child of E2 matches no child of O1 as described
in (as described in a child of O1 matches no child of E2 as described
in
O2 has a child identical to the child of O1. Informally, the rule just given has the effect that O2
contains (a) all the
The base URI of
Informally,
The result is that the transformation
described by O1 is applied to all the document in the
Because
xs:override
Support for XML 1.1 has been added. It is
now implementation defined whether datatypes dependent on definitions
in XML (
Correction of an error in version 1.0 of this specification relating to the construction of union types from other union types. Unions may now appear as members of other unions, and all restrictions of unions are correctly enforced.
A
Since not all datatypes have a defined canonical representation for all of their values, appeals to the canonical forms of values have been eliminated.
Changes to ensure that the descriptions of
the
Addition of a note warning that the
Support for negative
wildcard has been expanded to handle multiple namespaces. Support has
also been added to specify a set of explicitly enumerated
The grouping of changes in the paragraphs below is intended to make the list easier to scan. It is an ad hoc grouping for convenience to which no great significance should be attached. Some changes could have been listed in more than one place; in such cases the choice was arbitrary.
Support for XML 1.1 has been added.
It is now implementation defined whether datatypes dependent
on definitions in XML (
Schema language versions: A conditional inclusion mechanism is defined, roughly
analogous to the XSLT 2.0
Identifiers for different versions of XSD are now defined
in section #ifdef
construct. By
means of the
Content models:
The Content models may now use the
Wildcards may now be defined which allow names in any
namespace but those in a set of proscribed namespaces.
(In version 1.0 of this specification, only a single
namespace, the target namespace of a schema document,
could be proscribed.) Also, wildcards can now be written
which match any element in a set of namespaces but
which exclude a particular set of qualified names from
matching the wildcard.
Wildcards can now be defined which match any element
(in the specified namespaces) which does Several of the constraints imposed by version 1.0 of this
specification on Wildcards are now allowed in The value of Complex types whose content models are open content
. Such content
models allow elements
not explicitly mentioned in
the content model to appear in the document instance; it is
as if wildcards were automatically inserted at appropriate
points within the content model. By specifying what kind of
wildcard is implicitly inserted, the schema author can
adjust the degree of openness and determine what elements
are accepted by the open content; the schema author can also
specify that the content model should be open everywhere, or
only at the end. A schema-document wide default may be
set, which causes all content models to be open unless
otherwise specified.not-in-schema
wildcards).all
-groups
can now be extended; the result is an all
-group
(usually a larger one).
Assertions and rules for evaluation of XPaths Support for check clauses to
implement some co-occurrence constraints has been added. Each
complex type can carry a list of assertions, which are checked
when the complex type is used to validate an element
information item. The facility for assertions defined in the
working draft of 31 August 2006 has been revised.
The The XPath subset defined for assertions has been
Rules are defined for the evaluation of XPath expressions
(in assertions, in conditional type assignment, or in
identity-constraint definitions).
The static and dynamic contexts for XPath evaluation
are explicitly specified.
Rules are provided for constructing the When assertions on a complex type are evaluated,
only the subtree rooted in an element of that type is
mapped into the data model instance. References to
ancestor elements or other nodes outside the subtree
are not illegal but will not be effective. For conditional type assignment, neither the
ancestors nor the children of the element in question
are included; the conditions for type assignment are
thus effectively restricted to the attributes of the
element. For assertions on simple types, only the value
is provided; the dynamic context includes no
context item. Rules for assigning types to the nodes of the
data model instance are defined. Again, the rules
differ for the different uses of XPaths: When assertions are evaluated, all of the elements
and attributes descended from the element being
validated are typed in the normal way; this has the
effect that comparisons among attribute values (for
example) are performed in a way consistent with the
declarations of the attributes. The element node
itself, however, is not typed (since it has not yet
been completely validated).
For conditional type assignment, the nodes of the
data model instance are untyped.
Derivation of complex types; The rules for checking validity of complex-type restrictions
have been simplified by reformulating the constraint in terms
of local validity: the set of elements or attributes accepted
by a restriction as locally valid must be a subset of those accepted by its
base type. The rules for attributes have also been changed. The complex rules involving matching up particles in the base type
and particles in the restriction, with their complex case by
case analysis, have been replaced by a statement of the
constraint which is shorter and more correct.
It is now possible to specify a target namespace for
local elements and attributes which differs from the target
namespace of the schema document itself, when restricting
a complex type which has local elements or attributes and
which itself is in another namespace. This should
simplify the reuse of types from other namespaces.
The rules for complex type restriction now allow identity
constraints on local elements. To make this possible,
identity constraints may now be given names and referred to
from elsewhere. Corresponding changes have been made in the
description of the
This draft clarifies the rule requiring that any complex
type derived by extension could, in principle, be derived in
three steps from xs:anyType
Complex type definitions (miscellaneous changes): The constraint
The elements
ID, IDREF, and related types:
Certain constraints involving
An element may now have multiple attributes of type
The validation rules for values of type Elements and attributes of type xs:ID
. Elements have always been able to have
multiple children of type xs:ID
, but XSD 1.0 forbad
multiple attributes of this type for compatibility
with XML DTDs. (Schemas intended to be translatable into DTD
form should still avoid the practice.) This change should make
it easier for XML vocabularies to support both existing
ID attributes and xs:IDREF
,
xs:ENTITY
, or xs:ENTITIES
are now enforced on default values.
xs:ID
may now have
default or fixed values. XSD 1.0 had forbidden this, for
compatibility with XML DTDs.
A new type definition called
An error in version 1.0 of this
specification relating to the construction of union types from
other union types has been corrected. Unions may now appear
as members of other unions, and all restrictions of unions are
correctly enforced, even when
The requirement that a facet value be a
No union type may be a member of its own transitive membership,
nor may any type derived from the union. (XSD 1.0 forbad
union datatypes to be members of other unions and thus had
no need to forbid this explicitly.)
Since not all datatypes have a
defined canonical representation for all of their values,
appeals to the canonical forms of values have been
eliminated. Changes have been made to ensure that
the descriptions of the Equality and identity of lists have been clarified.anyAtomicType
has been introduced into the type
hierarchy between anySimpleType
and all the
valid
restriction
of another, in the context of simple
type restriction, has been clarified.
xs:anySimpleType
Changes to element declarations:
A new form of co-occurrence constraint has now been defined,
by allowing the type assigned to element instances to
be conditional on properties of the instance (typically
attribute values). The addition of conditional type assignment
has entailed a number of changes:
Introduction of a Constraints on that table: all types named in the table (including
the default) must be Changes to the XML syntax and XML mapping rules
to allow expression of conditional type
bindings: the
Validation rules for conditional types: a validation-time
check on restrictions of complex types ensures that the
conditionally assigned types of their children are appropriately
related to the types assigned by their base type;
see
Rules for evaluating the conditional typing tests
(more specifically, rules for constructing a temporary infoset
and then building the XDM instance and evaluating the
XPath expressions as defined elsewhere; priority of
tests is given by document order / component order)
PSVI changes to reflect details of the conditional typing:
a {type alternative} property is added, and the discussion of
[type fallback] now refers to the Introduction of some terminology for discussing conditional
types
(define Rules for checking type restriction in the presence of conditional
types
Introduction of a special Miscellaneous supporting editorial changes
Element declarations may now specify multiple substitution-group
heads.
Abstract elements may now appear in substitution groups.
xs:error
Attributes:
The rules for default attribute values now refer to the
The text now makes clear that it is pointless (although
not illegal) for schema documents to supply default or fixed
values for
Default attribute groups are now supported. The
http://www.w3.org/2001/XMLSchema-instance
, since they
will not be applied.
Every component now has an
{annotations} property whose value is a sequence of annotation
elements and out-of-band attributes. See e.g. Annotations are no longer
allowed to vary in the part of a content model shared
by a complex type and its extensions. (This was never
possible in components specified using schema documents,
but was possible in A The The underlying basis for the
definition of all the different kinds of components has
changed to make use of a regular and formal tabulation of
their properties. This has been achieved by introducing
born-binary
components.)
The process of validation:
When an Element information items which match no particle in a content
model are now to be validated using their
The text now specifies that if an element has an
The terminology of assessment has been changed to avoid the
suggestion that an element information item can be
xsi:type
attribute appears on an element,
and has a QName as its value, but the QName does not resolve to a known
type definition, processors are now required
to fall back
to lax validation,
using the
Changes in the
description of the The presentation of the Terms have been defined to describe different subsets of the
Provision is made for exposing the
The
When the
When default values are supplied for attributes with
qualified names,
Changes to the
description of conformance:
The different levels of conformance have been given shorter
and more convenient names. A checklist has been included listing ways in which conforming
processors may vary from each other, and terminology has been
provided for some of the more important properties of conforming
processors, in an attempt to make it easier for implementors to
describe concisely which options their processors exercise, and
easier for users to describe what kinds of processor they
require. The definition of Implementations are now allowed to support primitive datatypes
and facets beyond those defined in The validity requirements for schema documents are stated more
fully and correctly.
Schema assembly and composition:
The An
When an
No The handling of Section http://www.w3.org/2001/XMLSchema
or http://www.w3.org/2001/XMLSchema-instance
.
In XSD 1.0, the examples showed no such imports, but
there was no rule making it legal to omit the chameleon
inclusion and redefinition
in schema documents has been simplified. The new target
namespace affects any component or property which would have
the target namespace if the schema document specified one.
This change makes it easier to write assertions in schema
documents without a namespace which are intended to be
included by schema documents with varying target namespaces.
Miscellaneous substantive changes:
The discussion of schema-validity assessment and the invocation
of conforming processors has been revised; additional invocation
patterns have been identified, and names have been given to
the different methods of invoking a processor. When an element cannot be strictly validated because no
element declaration or type definition is available
for it, fallback to lax validation (validating the element
against the built-in type The XML Representation Constraints no longer refer to the
component level; this makes it possible to test a schema
document in isolation to determine whether it conforms or
fails to conform to these rules.xs:anyType
Each named constraint is now given in a separate section, to
simplify reference to them. The XML mapping rules have been reorganized to make them
more perspicuous. The A note has been added, warning that
the Several minor corrections and
clarifications have been made. The usage of some technical
terminology has been clarified, normalized, and aligned where
appropriate with the usage in
The title of the specification has been changed, and the language
defined here is referred to as XSD, not using the name
Conformance-related language has been reviewed
to avoid confusion between the conformance-related usage of
the verbs Various new terms have been defined, and some existing terms have
been redefined, to reduce confusion and improve legibility. In
some cases, existing terms which were felt insufficiently
informative have been replaced by new terms which may be more
useful.
Following the example of XQuery
1.0 and XSLT 2.0, the terms
) and cases where the words are used in
its everyday sense without conformance implications (e.g.
must
)if
have been rephrased to use if and
only if
where appropriate.XML Schema
. This may help reduce confusion between
the language defined here and the broader class of XML schema
languages in general.
and
have been defined and the two
concepts distinguished. The appendix contains lists both of
As noted above, some restrictions on
The namespace-related properties of the basic infoset are
Other kinds of infoset fixup, however, are still not performed.
Attributes of type ID
, IDREF
,
IDREFS
, and NOTATION
do not have
the same effect on the base infoset as they do if declared
in a DTD. (An infoset-to-infoset transformation can be
used to migrate the appropriate information into the base
infoset.)
Some existing implementations (and specifications) assume that
elements of type xs:ID
uniquely identify themselves,
instead of uniquely identifying their parent. This version of
this specification reaffirms the existing rule, which is that
elements and attributes of type xs:ID
uniquely
identify the parent element of the ID attribute or element.
The identity of components is still underspecified (although a number of points have been clarified, e.g. by the specification of the {scope} property), with the result that some schemas can be interpreted either as conformant or as non-conformant, depending on the interpretation of the specification's appeals to component identity.
The constraint
The account of schema composition given here has not eliminated all the uncertainties present in XSD 1.0; edge cases remain which different conformant implementations will treat differently.
A systematic tabulation of error conditions and definition of
a new system of error codes was originally foreseen for XSD
1.1, but has not been completed for inclusion here.
The constraint
The following UML class diagram shows the interrelations of element declarations, simple and complex type definitions, and related component classes. In the interests of simplicity, a few liberties have been taken with the notation. For example, direct links are shown from Element Declaration to Simple Type Definition and Complex Type Definition, rather than a single link to a generic Type Definition class specialized by simple and complex types. Similarly, a particle in a content model has exactly one term, which is either an element declaration, a wildcard, or a model group, but this diagram does not show any class created as a generalization of these three.
The following UML class diagram shows the
relation of various component classes to the
The listing below is for the benefit of readers of a printed version of this document: it collects together all the definitions which appear in the document above.
The DTD for schema documents is given below. Note there is schema
Although this DTD is non-normative, any XML document which is
not valid per this DTD, given redefinitions in its internal subset of the
'p' and 's' parameter entities below appropriate to its namespace
declaration of the
A specification of the import of
They are both element declaration particles whose declarations have the
same They are both element declaration particles
They are both They are both wildcards, and It has It has It has One is a wildcard and the other an element declaration, and the
A content model will violate the unique attribution constraint if it
contains two particles which are both in the may
Two particles may
A precise formulation of this constraint can also be offered in terms of
operations on finite-state automaton: transcribe the content model into an
automaton in the usual way using epsilon transitions for optionality and
unbounded maxOccurs, unfolding other numeric occurrence ranges and treating the heads of
The following contributed material to version 1.0 of this specification:
The Working Group thanks the members of other W3C Working Groups and industry experts in other forums who have contributed directly or indirectly to the creation of this document and its predecessor.
At the time this Working Draft is published, the members in good standing of the XML Schema Working Group are:
The XML Schema Working Group has benefited in its work from the participation and contributions of a number of people who are no longer members of the Working Group in good standing at the time of publication of this Working Draft. Their names are given below. In particular we note with sadness the accidental death of Mario Jeckle shortly before publication of the first Working Draft of XML Schema 1.1. Affiliations given are (among) those current at the time of the individuals' work with the WG.