This is a
This draft was published
on 30 August 2007.
The major revisions since the previous draft include:
A mechanism for conditional type assignment has been defined;
this allows the Element declarations may now specify multiple substitution group
heads. A default attribute group may now be specified at the
schema-document level; all complex types defined in the schema
document will include that attribute group unless they specify
otherwise; this makes it easier to specify that particular
attributes are to be accepted by Content models may now be defined as Wildcards may now be defined which match only elements
Complex types whose content models are The assertions facility defined in the previous working draft
has been revised; the Elements may now have more than one attribute of type Various enhancements to the definition of the Some aspects of the use of A conditional-inclusion mechanism has been defined to allow
XSDL 1.1 processors to cope more successfully with constructs defined
in future versions of this specification, if any.
Schema authors can use this mechanism to define alternative
constructs depending on the version of the processor, so that the
same schema document can be usable with processors supporting
different versions of XSDL.
Numerous editorial changes and small bug fixes have been made
in the interests of clarity and correctness.
open
,
which means that elements other than those explicitly named
will be accepted during validation.
Several styles and degrees of openness are possible;
they can be configured at the level
of the schema document or of the complex type definition.
not-in-schema
wildcards).all
-groups
may now be extended. (This change is in addition to other changes
in all
-groups described in xs:ID
.
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 validation behavior across 1.0 and 1.1 implementations (except possibly in edge cases and in the details of the resulting PSVI);
The vast majority of schema documents conformant to
version 1.1 of this specification should also conform to
version 1.0, leaving aside any incompatibilities arising from
support for versioning
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:
xsd:
The namespace for schema documents is unchanged from version
1.0 of this specification, because any schema document valid
under the rules of version 1.0 has essentially the same
validation semantics under this specification as it did under
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.
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
xmlns
bound to
http://www.w3.org/2000/xmlns/
(defined in
xs
bound to http://www.w3.org/2001/XMLSchema
(defined in this and related specifications)xsd
bound to http://www.w3.org/2001/XMLSchema
(defined in this and related specifications)xs
and the prefix xsd
for
the 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
).
xsl:quantity
lacks any binding for
the prefix xsl
(and does XSL define a name
quantity
); (2) We need references (informative?)
to the RDDL and XLink specs.
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
Implementations
Some users will perhaps wish to accept only XML 1.1 input, or
only XML 1.0 input. Conforming implementations of this
specification which accept XML input
The section introduces the highlighting and typography as used in this document to present technical material.
Aspects of this document which the Working Group are committed to changing, but where (all) changes are not yet in place, are signalled by the appearance of an Issue, with a link to the associated version 1.1 Requirement, for example:
Special terms are defined at their point of introduction in the
text. For example
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
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
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 following highlighting is used for non-normative commentary in this document:
General comments directed to all readers.
Conforming documents and
It is recommended that conforming documents and
Conforming documents and
Conforming documents and
These definitions describe in terms
specific to this document the meanings assigned to these terms by
This chapter gives an overview of
An
Schema-validity assessment has two aspects:
Determining local schema-validity,
that is whether an element or attribute information item
satisfies the constraints embodied in the relevant components
of an Synthesizing an overall validation outcome for the
item, combining local schema-validity with the results of
schema-validity assessments of its descendants, if any, and
adding appropriate augmentations to the infoset to record this
outcome.
Throughout this specification,
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 components, are as follows:
Attribute group definitions
Identity-constraint definitions
Type alternatives
Model group definitions
Notation declarations
Finally, the helper
components provide small
parts of other components; they are not independent of their
context:
Annotations
Model groups
Particles
Wildcards
Attribute Uses
The name
During
On the other hand,
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 xsd:anyType
and
xsd: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
The mapping from lexical space to value space is unspecified
for items whose type definition is
The Working Group expects to return to this area in a future version of this specification.
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, the name
and content of an element
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,
denotes a set of sequences of element information items. Regarding
that set of sequences as a language, the set of sequences recognized
by a particle P may be written L(P).
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
Identity constraints currently uses XPath 1.0. This may change in future working drafts of this specification to use XPath 2.0. Such change will not affect evaluation of identity constraints, given the XPath subset it uses.
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.
For detailed information on Assertions, see
Assertions are currently only allowed to be specified in complex types. It may be deemed useful to also include assertions in named model group definitions and/or attribute groups, or even simple types, if proved useful.
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. XML validation augments the XML information set in similar
ways, for example by providing values for attributes not present
in instances, and by implicitly exploiting type information for
normalization or access. (As an example of the latter case,
consider the effect of NMTOKENS
on attribute white
space, and the semantics of ID
and
IDREF
.) By including schema information set
contributions, this specification makes explicit some features
that XML
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 and for XSDL-aware processors.
A It is valid with respect to the schema specified
in 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
Some Schema Representation Constraints cannot, in their current formulation, be checked against the schema document in isolation, but only in the context of the schema as a whole. It is a consequence that in some cases, the conformance of a schema document cannot be determined in isolation.
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
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
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
implicit in the
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 value is 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.
If the simple type definition used in an item's
There are three alternative validation rules which
These three levels of normalization correspond to the processing mandated
in XML for element content, CDATA attribute
content and tokenized
attributed content, respectively. See
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 the attribute
A
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
If the
name
targetNamespace
type
default
or a fixed
otherwise if the ref
use='prohibited'
, in which case the item
corresponds to nothing at all):
use
required
, otherwise
default
or a fixed
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
is present and its qualified
form
is absent and the attributeFormDefault
on the qualified
the targetNamespace
type
otherwise (the ref
use='prohibited'
, in which case the item
corresponds to nothing at all):
use
required
, otherwise
ref
default
or a fixed
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
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
In addition to the conditions imposed on If If the item's parent is not One of If
If
If
If the ancestor
Let 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
and fixed
and use
are both present,
use
prohibited
.
targetNamespace
is present then
name
is present.
form
is not present.
targetNamespace
targetNamespace
of
For an attribute information item to be locally The declaration Its The item's The item's
If the declaration is the built-in declaration for xsi:type
(
A declaration which was stipulated by the processor (see
Its A declaration
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 A declaration was stipulated by the processor (see 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
The
If
The first (
If
the attribute's
the
the
the
Also, if
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
For a Value Constraint to be a valid default with respect to a the Value Constraint's the Value Constraint's
xmlns
Not Allowed
The xmlns
.
The xmlns:*
.
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 not illegal for xsi:
attributes to specify default or fixed value
constraints (e.g. in a component corresponding to a schema document construct
of the form <xsd:attribute ref="xsi:type" default="xsd: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:
type
http://www.w3.org/2001/XMLSchema-instance
nil
http://www.w3.org/2001/XMLSchema-instance
schemaLocation
http://www.w3.org/2001/XMLSchema-instance
http://www.w3.org/2001/XMLSchema-instance
noNamespaceSchemaLocation
http://www.w3.org/2001/XMLSchema-instance
Element declarations provide for:
Local
Specifying default or fixed values for an element information items;
Establishing uniquenesses and reference constraint relationships among the values of related elements and attributes;
Controlling the substitutability of elements through the
mechanism of
XML representations of several different types of element declaration
The element declaration schema component has the following properties:
The
A
A
An element information item is xsi:type
attribute
If nil
from namespace
http://www.w3.org/2001/XMLSchema-instance
and value true
(see
The provision of defaults for elements goes beyond what is
possible in XML DTDs,
and does not exactly correspond to defaults for attributes. In
particular, an element with a non-empty
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
If the
name
targetNamespace
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
otherwise if the ref
minOccurs=maxOccurs=0
, in which case the item
corresponds to no component at all):
minOccurs
1
.maxOccurs
maxOccurs
1
. An element declaration as in the first case above, with the
exception of its
form
is present and its qualified
, or if form
is absent and
the elementFormDefault
on the
qualified
, then the
targetNamespace
targetNamespace
is present
its
targetNamespace
is not present and
form
is present and its qualified
form
is absent and the elementFormDefault
on the qualified
the targetNamespace
otherwise (the ref
minOccurs=maxOccurs=0
, in which case the item
corresponds to no component at all):
minOccurs
1
.maxOccurs
maxOccurs
1
.ref
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
As noted above the names for top-level element declarations are in a separate
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 below at
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
Let The corresponding particle and/or element declarations
satisfy the conditions set
out in
default
and fixed
ref
or name
ref
is present, then all of nillable
, default
,
fixed
, form
, block
and type
minOccurs
, maxOccurs
, id
ref
.targetNamespace
is present then
name
is present.
form
is not present.
targetNamespace
targetNamespace
of
test
When an element is
The
If D has a If
D has no It is a consequence of xsd:error
If at least one
If no
Among the element's attribute information items is one
named The The xsi:type
, that is an http://www.w3.org/2001/XMLSchema-instance
and whose type
.
S is the
S is Typically, T
would be the
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
For an element information item The declaration Its There is no such attribute information item. There is such an attribute information item, and its
There is such an attribute information item, and its
The element information item has no character or
element information item There is no If there is an attribute information
item among the element information item's The The The If there is an attribute information
item named E has an The If an the declaration
If the The element information item with the the declaration has no The element information item If there is a The element information item the the the the The element information item If the element information item is the http://www.w3.org/2001/XMLSchema-instance
and whose nil
.false
.true
, and
http://www.w3.org/2001/XMLSchema-instance
and whose type
, then
xsi:type
among the http://www.w3.org/2001/XMLSchema-instance
and whose type
), then
The
If an element has an xsi:type
attribute whose
value does not
For an element information item to be locally The type definition
It the type definition is a simple type
definition
The element information item's The element information item If the type definition is a complex type
definition the element information item
If the element information item has an Informally, this rule means that an element with an
This rule only covers the case when a http://www.w3.org/2001/XMLSchema-instance
and whose type
,
nil
, schemaLocation
or
noNamespaceSchemaLocation
.xsi:type
http://www.w3.org/2001/XMLSchema-instance
and whose type
) and does not have a
xsi:type
xsi:type
attribute cannot be locally valid
with respect to any type other than that named in the
attribute.
For an element information item which is the
There There
See
The first clause above applies when there is a reference to
an undefined ID. The second applies when there is a
multiply-defined ID. They are separated out to ensure that
distinct error codes (see
Although this rule applies at the
This reconstruction of ID/IDREF
functionality is imperfect in that if
the
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 A declaration was stipulated by the processor (see
A declaration has been established as its Its Its Its If that evaluation involved the evaluation of
It does not have a A A type definition was stipulated by the processor
(see There is an attribute information item among the
element information item's The The If there is also a processor-stipulated type
definition, the The element information item's The schema-validity of
For each of the attribute information items among its
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 http://www.w3.org/2001/XMLSchema-instance
and whose
type
.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
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
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
All element declarations (see
The values of the properties of an element declaration
If there is a
If there is a
If there is a
If the
The use of
If there is a
xsd:error
The following constraints define relations appealed to elsewhere in this specification.
For a the type definition is a simple type
definition
the type definition is a complex type definition
its the
For an element declaration (call it The blocking constraint does not contain
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 A A A
A
See
The XML representation for a complex type definition schema component is a
The XML representation for complex type definitions with
a
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
When the
base
If the
defaultAttributesApply
true
, and the defaultAttributes
ref
defaultAttributes
The set of attribute uses corresponding to the
The ref
If the type definition the what would have been the base
use
there is an a wildcard based
on the
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 the
the type definition that The value is then determined by
the
the the a wildcard whose (the base
the type definition base
starting from either
the simple type definition corresponding to the otherwise (base
the type definition base
starting from
the simple type definition corresponding to the
the type definition base
the
(the type definition base
When the
The property mappings below are xs:anyType
base
The set of attribute uses corresponding to the
The ref
The
The what would have been the base
use
the its the its mixed
mixed
false
.
There is no There is an There is a the particle
corresponding to the minOccurs
0
;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
the type definition a a A model group whose the the the a the a model group whose
a model group whose true
, otherwise base
base
true
, otherwise 1
1
base
base
1
1
1
the
the
the
the
the
the
appliesToEmpty
Then the value of the property is
the
the
the
a
mode
'none'
mode
If the
Aside from the simple coherence requirements enforced above, constraining
type definitions identified as restrictions to actually
The use
attribute of an
Careful consideration of the above concrete syntax reveals that
a type definition need consist of no more than a name, i.e. that
<complexType name="anyThing"/>
is allowed.
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.
A type definition for personal names, and a definition
A simplified type definition
A further illustration of the abbreviated form, with the
mixed
attribute appearing on complexType
itself.
A complex type definition that
To restrict away a local element declaration that
Without the specification of the notQName
attribute,
the restriction might or might not be valid, depending on whether
the schema has a top-level declaration for
If the schema does have a top-level declaration, then the restriction is valid.
If there is no such top-level declaration, the restriction
is not valid, because the base type computer
maps quietComputer
would
map them to a xs:anyType
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 The Although not explicitly ruled out either here or in The corresponding complex type definition component
If
If
If the base
base
mixed
<xs:complexType . . .mixed='true'
when the mode
'none'
, then there
mixed
CTD is
E's
xs:anyType
The constraint
The reference to
Similarly: Let D be an E's 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's
the
the xs:anyType
For an element information item If the the the It is the the sequence of For each attribute information item in there is among the the attribute information
There The
attribute information item The
It is a member of the complex type's
Its
Its
Its
Its 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
For a sequence S (possibly empty) of element information items
to be locally
the
S is
the
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
(the
S is a member of S1 × S2
S1 is
For every element E in S2, let S3 be
Every element in S2 is
When the
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 the
If the the
The Its If it has an
The The
The
The
Both
The
The
The
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
The the
The The xs:anyType
If the The 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 The The The The The The The The The Attempts to For every element information item
For any element The xs:anyType
either there is no sequence of element information items which is Using the name Every sequence of element information items which is
For all sequences of element information items
Every sequence of element information items which is
For all sequences of element information items restriction
)
base
) if and only if
When a sequence of an element information items Either explicitly present, or successfully located as a result of a
An undischarged a An undischarged
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
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 types definitions in question are the type definitions associated with
two attribute or element declarations, which are discovered to be the same
declaration); When they are the same by construction (for example, when an element's
type definition defaults to being the same type definition as that of its
substitution-group head or when a complex type definition inherits an attribute
declaration from its base type definition).
In other cases
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 as such.
The item's
For an attribute information item to be
None as such.
All attribute uses (see
The values of the properties of an attribute use
If the
If the
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 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
element information item.ref
It is a consequence of this rule and the rule in
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 addition to the conditions imposed on The corresponding attribute group definition, if any, Circular group reference is disallowed outside ref
ref
None as such.
None as such.
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
element information item.Otherwise, the item will have a ref
minOccurs=maxOccurs=0
, in which case the item
corresponds to no component at all):
minOccurs
1
.maxOccurs
maxOccurs
1
.ref
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 as such.
None as such.
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
.In addition to the conditions imposed on
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 content model to
have some paths which are neither complete paths, nor
prefixes of complete paths. For example, the content model
</a>
)
and (</a><b/>
) have paths in the content
model.
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 content model nevertheless have
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 content model P
<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 S (possibly empty) of element information items to be
locally
It is possible to define groups whose
None as such.
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
=1
which is
If the
If the
strict
, lax
,
or skip
particles, depending on the
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
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 whose
The product of the particle's 0
if there are no
0
if there are no
The effective total range of a particle whose
The product of the particle's 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 as such.
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
When the either the or 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,
When the
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
The length of the sequence If Each element information item in the sequence
the
The length of the sequence If For each element information item in the sequence
The element declaration is local (i.e. its
In this case the element declaration is the
The element declaration is top-level (i.e. its
In this case the element declaration is the The element declaration is top-level (i.e. its
In this case the In this case the element information item is
the
There is a If Each sub-sequence in the n
sub-sequences such that
n
is greater than or equal to 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 as such.
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.
Both The
=1
and its
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
A particle containing a wildcard, 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 namespace
the the namespace
"##any"
namespace
"##other"
the notNamespace
(neither namespace
nor notNamespace
is present)
neither namespace
nor notNamespace
is present
the empty set;
the namespace
"##any"
the empty set;
the 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
##defined
, the corresponding member is the keyword 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
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 (namespace name, local name) pair to be The namespace name is The constraint's
If the constraint's
For a value which is either a namespace name or The constraint The constraint
None as such.
All wildcards (see
The values of the properties of a wildcard
If
If
The namespace name of each
The following constraints define a relation appealed to elsewhere in this specification.
Both The Both
And Each
If
either both the two
a a either
a a
The O, O1, and O2 all have the same Either O1 or O2 has O, O1, and O2 all have O1 and O2 both have
The intersection of the
O also has Either O1 or O2 has
The set difference S1 minus S2 is the empty set,
and O has
O has
The
The keyword
If one
If a
In the case where there are more than two
either either both both a
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 intersection of O1's
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
.
Identity constraints currently uses XPath 1.0. This may change in future working drafts of this specification to use XPath 2.0. Such change will not affect evaluation of identity constraints, given the XPath subset it uses.
In
See
The XML representation for an identity-constraint definition schema
component is either a
If the ref
name
targetNamespace
schema
element information item.xpath
xpath
refer
Otherwise (the 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.
In addition to the conditions imposed on
One of
If
If
If
The corresponding identity-constraint definition ref
or name
is present, but not both.
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 to be locally Each node in the For each node in the
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
Because the validation of
Although this specification defines a
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
test
type
complexType
or simpleType
among the
In addition to the conditions imposed on
Every
The corresponding type alternative satisfies the conditions set out in
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 and its
An
The XPath expression
which is the value of the
true
and T is the 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
Assertion components constrain the existence and values of related elements and attributes.
The XML representations for
The
The assertion schema component has the following properties:
true
.
A false
.
Path steps are restricted to only match information items
within the element being
XPath
Operations are limited to those defined in this specification.
For example, comparison of
Functions are
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
test
Assertions, like identity constraints and conditional type
assignment, use
xpathDefaultNamespace
defaultXPathDefaultNamespace
##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.
In addition to the conditions imposed on
The If the If the true
(see below) without
raising any
true
or false
(see below) without raising any
true
.false
.
Evaluation of
The element information item 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. If
E's
E's
the
This partial
partial
partial
partial
true
or false
as if by a call to the XPath
When operands are compared
(see false
.
Although the rules
The Working Group is looking for ways to provide a typed value in cases where E has simple content.
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 xsd: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 as such.
All assertions (see
The values of the properties of an assertion
This constraint imposes distinct obligations on conforming schemas and on conforming processors.
An XPath expression in a conforming
schema The
A conforming processor
Any XPath expression valid according to
The It conforms to the following extended BNF:
It For readability, whitespace For readability, When tokenizing, the longest
possible token is always returned. If part of the restricted XPath matches If part of the restricted XPath matches If part of the restricted XPath matches the
The piece that matches The child
and/or attribute
axes
whose abbreviated form is as given above.QName
in the
QName
in the
QName
identifies a simple type definition.StringLiteral
is locally
Implementations
The definition of
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 NOTATION declarations.
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
name
targetNamespace
schema
element information item.system
public
In addition to the conditions imposed on
None as such.
Whenever an attribute information item is
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 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 as such.
None as such: the addition of annotations to the
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
As specified in
A
See
This section reproduces a version of material from
name
targetNamespace
the
the type definition base
the
{
}
, 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
then a set of
the
a set with one member, a
the empty set
A sequence of
the If the If the If the
If the
If the
the
the itemType
itemType
(that is, the In this case, a
If the
the
memberTypes
memberTypes
(that is, the In this case, a
In addition to the conditions imposed on The corresponding simple type definition, if any, If the If the
If the With the exception of base
itemType
memberTypes
simpleType
memberTypes
For a string to be locally It is schema-valid with respect to that definition as defined by
The definition is the string The definition is every whitespace-delimited substring of the string no further condition applies.
None as such.
All simple type definitions
The values of the properties of a simple type definition
All simple type definitions
The
There
the
The For each facet in the If there is a facet of the same kind in the
the
The the
The The
The The The Only For each facet in the The first case above will apply when a list is
the
the
All of the The
The The The Only For each facet in the The first case above will apply when a union is
.
"Valid restriction" of facet values in the above constraint means that the
facet in question satisfies the constraints given separately in the
appropriate subsection of
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
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 Additional constraint(s)
Every facet in
Every facet in Every facet in
xsd:anySimpleType
xs:anyType
The xs:anyType
xsd:anyAtomicType
xsd:error
A xsd:error
xsd:error
xsd:anySimpleType
The datatype xsd: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 xsd: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 xsd:error
is expected to be used
mostly in conditional type assignment. Whenever it serves as the
Simple type definitions
[as appropriate]
Similarly, simple type definitions
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
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.
In addition to the conditions imposed on
The corresponding schema satisfies the conditions set out in
If the
defaultAttributes
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
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
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
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 XSDL processor reads a
Every element in the
Where they appear, these attributes are treated as if
declared with type xsd:decimal
, and their
If
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 XSDL (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 XSDL 1.1. In such a case, a schema document
of the following form would be handled correctly by a
conforming XSDL 1.1 processor:
Even though the schema document as shown has two element
declarations for element
Whenever the attribute xsd:decimal
as per
<include>
)Schema components for a single target namespace can be
assembled from several
A schemaLocation
attributes, consisting of a URI
reference, identify other
The targetNamespace
as the targetNamespace
at all,
in which case the 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 schema corresponding to
The above rule applies recursively. For example, if
The The If a schema document is to be included in a way as described in 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
code
was ##other
or ##local
in a wildcard, because the result of the inclusion will not be the same as if
the schema document being included had a targetNamespace
It is schemaLocation
As discussed in
The above is carefully worded so that multiple
<redefine>
)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
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 successfully ref
name
attribute plus
target namespacename
attribute
plus target namespace successfully
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
<import>
)As described in
Some users of schemaLocation
attribute.
Although the function of
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 html:p
. If there were no component reference, then
the import would be unnecessary; no import is needed for use of a namespace
in a
The treatment of references as
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 document whose document element is
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
Unless directed otherwise, for example by the invoking application
or by command line option, processors
xsi:schemaLocation
and xsi:noNamespaceSchemaLocation
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.
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 type definition from among the 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
), 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 notion of
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
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.
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
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.
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 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 as those which cannot read schema
documents in XML form, and
processors as those which can.)
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
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
The
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
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 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
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 XSDL 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 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
changed and is now defined as the minimum subset of XPath
which conforming processors must support. Conforming
schema documents are not restricted to the subset; they
may use any legal XPath expression as an assertion
(although expressions outside the XPath subset defined
here may not be supported by all processors, just as an
integer value may be unsupported by some processors if it
lies outside the range which processors are required to
support). 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. 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 XSDL 1.0 forbad
multiple attributes of this type for compabitility
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. XSDL 1.0 had forbidden this, for
compatiblity 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. (XSDL 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 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.
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.
xsd: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. 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
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 text is now clearer in stating that error handling
by conforming processors is out of scope and not constrained
by this specification.
Schema assembly and composition:
When an
No The handling of Section http://www.w3.org/2001/XMLSchema
or http://www.w3.org/2001/XMLSchema-instance
.
In XSDL 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 xs:anyType
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 XSDL, 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 xsd: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 xsd: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 XSDL 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 XSDL 1.1, but has not been completed for inclusion here.
The constraint
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 one of whose They are both wildcards, 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