This is a
This draft was published
on 20 June 2008.
The minimal subset of XPath which processors were required
to support for assertions has been eliminated; processors
must support all of XPath.
A new wildcard keyword The definitions of An The XML Representation Constraints no longer refer to
the component level; they can now be checked for
schema documents in isolation.
Numerous editorial changes and clarifications have been
made and numerous small errors corrected.
For those primarily interested in the changes since version 1.0,
the
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 of the
Chapter 2 presents a
Chapter 3,
Chapter 4 presents
Chapter 5 discusses
The normative appendices include a
The non-normative appendices include the
This document is primarily intended as a language definition
reference. As such, although it contains a few examples, it is
The Working Group has
Significant improvements in simplicity of design and
clarity of exposition
Provision of support for versioning of XML languages
defined using
Provision of support for co-occurrence constraints, that is constraints which make the presence of an attribute or element, or the values allowable for it, depend on the value or presence of other attributes or elements.
These goals are
in tension with one another
Support for co-occurrence constraints (which will certainly involve additions to the XML transfer syntax, which will not be understood by 1.0 processors)
The
All schema documents conformant to version 1.0 of this
specification should also conform to version 1.1, and should
have the same
The vast majority of schema documents conformant to
version 1.1 of this specification should also conform to
version 1.0, leaving aside any incompatibilities arising from
support for versioning
The purpose of
The purpose of an
Any application that consumes well-formed XML can use the
formalism
xs)
The XML representation of schema components uses a vocabulary
identified by the namespace name http://www.w3.org/2001/XMLSchema.
For brevity, the text and examples in this specification use
the prefix xs: to stand for this
namespace; in practice, any prefix can be used.
The namespace for schema documents is unchanged from version
1.0 of this specification, because any schema document valid
under the rules of version 1.0 has essentially the same
The data model used by untyped,
untypedAtomic) which are not defined in this
specification; see the
Users of the namespaces defined here should be aware, as a
matter of namespace policy, that more names
xsi)
http://www.w3.org/2001/XMLSchema-instance.
For brevity, the text and examples in this specification use
the prefix xsi: to stand for this namespace; in
practice, any prefix can be used.
Users of the namespaces defined here should be aware, as a
matter of namespace policy, that more names
vc)
The pre-processing of schema documents described in
http://www.w3.org/2007/XMLSchema-versioning.
For brevity, the text and examples in this specification use
the prefix vc: to stand for this
namespace; in practice, any prefix can be used.
Users of the namespaces defined here should be aware, as a matter of namespace policy, that more names in this namespace may be given definitions in future versions of this or other specifications.
Except as otherwise specified elsewhere in this specification,
if components are http://www.w3.org/XML/1998/namespacehttp://www.w3.org/2001/XMLSchemahttp://www.w3.org/2001/XMLSchema-instancehttp://www.w3.org/2007/XMLSchema-versioning
Depending on implementation details, some processors may be able to process and use (for example) variant forms of the schema for schema documents devised for specialized purposes; if so, this specification does not forbid the use of such variant components. Other processors, however, may find it impossible to validate and use alternative components for these namespaces; this specification does not require them to do so. Users who have an interest in such specialized processing should be aware of the attending interoperability problems and should exercise caution.
This flexibility does not extend to the components described in
this specification or in
Components and source declarations http://www.w3.org/2000/xmlns/ as their
target namespace. If they do, then the schema
and/or schema document is in
Any confusion in the use, structure, or meaning of this namespace would have catastrophic effects on the interpretability of this specification.
Several namespace prefixes are conventionally used in this
document for notational convenience. The following bindings are
assumed.fn bound to
http://www.w3.org/2005/xpath-functions (defined
in html bound to
http://www.w3.org/1999/xhtmlmy (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/xhtmlxlink bound to
http://www.w3.org/1999/xlinkxml 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)xsi bound to
http://www.w3.org/2001/XMLSchema-instance (defined in this and
related specifications)xsl bound to
http://www.w3.org/1999/XSL/Transform
In practice, any prefix bound to the appropriate namespace
name xml and
xmlns).
Sometimes other specifications or Application Programming
Interfaces (APIs) need to refer to the
Identifies the
Identifies the language described in version http://www.w3.org/ identifies
http://www.w3.org/ identifies
Identifies the language described in the http://www.w3.org/
identifies the second edition of
Identifies the language described in the yyyy-mm-dd. For example,
http://www.w3.org/
identifies http://www.w3.org/
identifies
Please see
The definition of
See
Conforming implementations of this specification
Some users will perhaps wish to accept only XML 1.1 input, or
only XML 1.0 input.
The section introduces the highlighting and typography as used in this document to present technical material.
Unless otherwise noted, the entire text of
this specification is normative. Exceptions include:
notes sections explicitly marked non-normative examples and their commentary informal descriptions of the consequences of rules
formally and normatively stated elsewhere (such informal
descriptions are typically introduced by phrases like
Informally, ...
or It is a
consequence of ... that ...
)
Special terms are defined at their point of introduction in the
text. For example
Non-normative examples are set off in boxes and accompanied by a brief explanation:
And an explanation of the example.
The definition of each kind of schema component consists of a list of its properties and their contents, followed by descriptions of the semantics of the properties:
An example property
References to properties of schema components are links to the
relevant definition as exemplified above, set off with curly
braces, for instance
For a given component C, an expression
of the form C.
denotes the (value of the) property
C.
(or more) is sometimes omitted,
if the identity of the component and any other omitted properties
is understood from the context.
This dot operator
is left-associative, so
C.
means the same as
(C.
and denotes the value of property
For components C1 and C2, an expression
of the form C1 .
means that C1 and C2 have the same value for the
property (or properties) in question. Similarly,
C1 = C2
means that C1 and C2 are
identical, and C1.
that C2 is the value of
C1.
The correspondence between an element information item which is
part of the XML representation of a schema and one or more schema
components is presented in a tableau which illustrates the
element information item(s) involved. This is followed by a
tabulation of the correspondence between properties of the
component and properties of the information item. Where context
In the XML representation, bold-face attribute names (e.g.
size
below; if there is a default value, it is shown following a
colon. Where an attribute information item has a built-in simple
type definition defined in
The allowed content of the information item is shown as a
grammar fragment, using the Kleene operators ?,
* and +. Each element name therein is
a hyperlink to its own illustration.
The illustrations are derived automatically from the
size References to elements in the text are links to the relevant
illustration as exemplified above, set off with angle brackets,
for instance
Unless otherwise specified, references to attribute values
are references to the value
associated with it.
For a given element information item E, expressions of the
form E has
are short-hand for att1 = Vthere is an attribute information
item named
If the identity of E is clear from context, expressions
of the form att1 among the
are sometimes used.
The form att1 = V
is also used
to specify that the att1 ≠ Vatt1 is
References to properties of information items as defined in
Properties which this specification defines for information items are introduced as follows:
References to properties of information items defined in this
specification are notated as links to their introduction as
exemplified above, set off with square brackets, for example
The dot operator
described above
for components and their properties is also used for information items
and their properties. For a given information item I, an expression
of the form I .
denotes the (value of the) property
Lists of normative constraints are typically introduced with
phrase like
all of the following are true
(or ... apply
),
one of the following is true
,
at least one of the following is true
,
one or more of the following is true
,
the appropriate case among the following is true
,
etc.
The phrase one of the following is true
is used in cases where the authors believe the items listed
to be mutually exclusive (so that the distinction between
exactly one
and one or more
does not arise). If the items in such a list are not in fact
mutually exclusive, the phrase one of the following
should be interpreted as meaning one or more of the
following
.
The phrase the appropriate case among the following
is used only when the cases are thought by the authors to be
mutually exclusive; if the cases in such a list are not in fact
mutually exclusive, the first applicable case should be
taken. Once a case has been encountered with a true condition,
subsequent cases
The following highlighting is used for non-normative commentary in this document:
General comments directed to all readers.
It is recommended that
A failure of a schema
Except as otherwise specified,
processors
Failure of an XML document to be valid against a particular schema is not (except for the special case of a schema document consulted in the course of building a schema) in itself a failure to conform to this specification and thus, for purposes of this specification, not an error.
Notwithstanding the fact that (as just noted) failure to be
schema-valid is not a violation of this specification and
thus not strictly speaking an error as defined here,
the names of the PSVI properties in error
for
purposes of those applications.
A feature or construct defined in this specification
described as
Deprecation has no effect on the conformance of schemas
or schema documents which use deprecated features.
Since deprecated features are part of the specification,
processors
Features deprecated in this version of this specification may be removed entirely in future versions, if any.
These definitions describe in terms
specific to this document the meanings assigned to these terms by
Where these terms appear without special highlighting, they are used in their ordinary senses and do not express conformance requirements. Where these terms appear highlighted within non-normative material (e.g. notes), they are recapitulating rules normatively stated elsewhere.
This chapter gives an overview of
An
As it is used in this specification, the
term Determining local schema-validity, that is
whether an element or attribute information item satisfies
the constraints embodied in the relevant components of an
Throughout this specification,
Throughout this specification,
During See also the definitions of
This specification builds on
Just as
Simple type definitions
Complex type definitions
Attribute declarations
Element declarations
The secondary
Attribute group definitions
Identity-constraint definitions
Type alternatives
Model group definitions
Notation declarations
Finally, the helper
Annotations
Model groups
Particles
Wildcards
Attribute Uses
The
name
During
On the other hand,
An
At the abstract level, there is no requirement that the
components of a schema share a
The abstract model provides two kinds of type definition component: simple and complex.
Type definitions form a hierarchy with a single root. The subsections below first describe characteristics of that hierarchy, then provide an introduction to simple and complex type definitions themselves.
xs:anyType
error
For brevity, the text and examples in this specification often
use the qualified names xs:anyType and
xs:error for these type definitions. (In
practice, any appropriately declared prefix can be used, as
described in
A simple type definition is a set of constraints on strings
and information about the values they encode, applicable to the
Each simple type definition, whether built-in (that is,
defined in xs:anyTypexs:anySimpleTypexs:anyTypexs:anySimpleType to designate this type
definition.xs:anySimpleType
xs:anySimpleType
.xs:anyAtomicType
The mapping from lexical space to value space is unspecified
for items whose type definition is xs:anySimpleTypexs:anyAtomicTypexs:anySimpleTypexs:anyAtomicType
The Working Group expects to return to this area in a future version of this specification.
xs:anySimpleType
For detailed information on simple type definitions, see
A complex type definition is a set of attribute declarations
and a content type, applicable to the
Each complex type definition other than a restriction of a complex an xs:anyType
A complex type which extends another does so by having
additional content model particles at the end of the other
definition's content model, or by having additional attribute
declarations, or both.
all-groups in ways that do not
guarantee that the new material occurs only at the end of
the content.
For detailed information on complex type definitions, see
There are three kinds of declaration component: element, attribute, and notation. Each is described in a section below. Also included is a discussion of element substitution groups, which is a feature provided in conjunction with element declarations.
An element declaration is an association of a name with a type definition, either simple or complex, an (optional) default value and a (possibly empty) set of identity-constraint definitions. The association is either global or scoped to a containing complex type definition. A top-level element declaration with name 'A' is broadly comparable to a pair of DTD declarations as follows, where the associated type definition fills in the ellipses:
Element declarations contribute to
For detailed information on element declarations, see
In XML, 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
The language accepted by a content model plays a role in determining
whether an element information item is locally valid or not: if the
appropriate content model does not accept the sequence of elements
among its children, then the element information item is not locally
valid.
No assumption is made, in the definition above,
that the items in the sequence are themselves valid; only the
If a sequence S is a member of L(P),
then it is necessarily possible to trace a path through the
This
For detailed information on particles, see
An attribute use plays a role similar to that of a particle, but for attribute declarations: an attribute declaration within a complex type definition is embedded within an attribute use, which specifies whether the declaration requires or merely allows its attribute, and whether it has a default or fixed value.
A wildcard is a special kind of particle which matches element
and attribute information items dependent on their namespace
name
For detailed information on wildcards, see
An identity-constraint definition is an association between a name
and one of several varieties of identity-constraint related to
uniqueness and reference. All the varieties use
For detailed information on identity-constraint definitions, see
In
A
The provisions for conditional type assignment are inspired by,
but not identical to, those of
For detailed information on Type Alternatives, see
An assertion is a predicate associated with a type, which is
checked for each instance of the type. If an element or attribute information item
fails to satisfy an assertion associated with a given type,
then that information item is not locally
For detailed information on Assertions, see
There are two kinds of convenience definitions provided to enable the re-use of pieces of complex type definitions: model group definitions and attribute group definitions.
A model group definition is an association between a name and a model group, enabling re-use of the same model group in several complex type definitions.
For detailed information on model group definitions, see
An attribute group definition is an association between a name and a set of attribute declarations, enabling re-use of the same set in several complex type definitions.
For detailed information on attribute group definitions, see
An annotation is information for human and/or mechanical consumers. The interpretation of such information is not defined in this specification.
For detailed information on annotations, see
The
The preceding section focused on
The last of these, schema information set contributions, are
not as new as they might at first seem. 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
A It is valid with respect to No element in the schema document violates any of the
Schema Representation Constraints set out in
While conformance of schema documents is a precondition for
the mapping from schema documents to schema components described
in this specification, conformance of the schema documents does
not guarantee that the result of that mapping will be a schema
that conforms to this specification. Some constraints (e.g. the
rule that there must be at most one top-level element
declaration with a particular
This specification describes three levels of conformance for schema aware processors. The first is required of all processors. Support for the other two will depend on the application environments for which the processor is intended.
The
By separating the conformance requirements relating to the
concrete syntax of
In version 1.0 of this specification the class of conformant
to the XML Representation of Schemas
. Similarly, the
class of fully conforming
.
Although this specification provides just these three standard levels of conformance, it is anticipated that other conventions can be established in the future. For example, the World Wide Web Consortium is considering conventions for packaging on the Web a variety of resources relating to individual documents and namespaces. Should such developments lead to new conventions for representing schemas, or for accessing them on the Web, new levels of conformance can be established and named at that time. There is no need to modify or republish this specification to define such additional levels of conformance.
See
As discussed in pool
, then it would be
impossible to have, for example, a simple type definition and an
element declaration both with the name title
in a
given
Therefore
Locally scoped attribute and element declarations are special
with regard to symbol spaces. Every complex type definition
defines its own local attribute and element declaration symbol
spaces, where these symbol spaces are distinct from each other
and from any of the other symbol spaces. So, for example, two
complex type definitions having the same target namespace can
contain a local attribute declaration for the unqualified name
priority
, or contain a local element declaration
for the name address
, without conflict or
necessary relation between the two.
http://www.w3.org/2001/XMLSchema-instance) described in
As described above (
,
xsi:type
, etc. This is shorthand for
xsi:nilan attribute information item whose
(or
http://www.w3.org/2001/XMLSchema-instance and whose typenil, etc.).
The xsi:type. The value of this attribute is a
xsi:nil
with the value true. An element so labeled
The xsi:schemaLocation and
xsi:noNamespaceSchemaLocation attributes can be
used in a document to provide hints as to the physical location
of schema documents which
On the World Wide Web, schemas are conventionally represented
as XML documents (preferably of MIME type
application/xml or text/xml, but see
The following sections provide full details on the composition
of all schema components, together with their XML representations
and their contributions to properties: their values and significance XML representation and the mapping to properties constraints on representation validation rules constraints on the components themselves
Components are defined in terms of their properties, and each
property in turn is defined by giving its range, that is the
values it
A schema and its components as defined in this chapter are an
idealization of the information a schema-aware processor
requires: implementations are not constrained in how they
provide it. In particular, no implications about literal
embedding versus indirection follow from the use below of
language such as properties . . . having . . .
components as values
.
Component properties are simply named
values. Most properties have either other components or
literals (that is, strings or booleans or enumerated keywords)
for values, but in a few cases, where more complex values are
involved,
Any property
It is
The principal purpose of http://www.w3.org/2001/XMLSchema. Although a common way of creating
the XML Infosets which are or contain
Two aspects of the XML representations of components presented
in the following sections are constant across them all:
All of them allow attributes qualified with namespace names
other than the All of them allow an
A recurrent pattern in the XML
representation of schemas may also be mentioned here. In many
cases, the same element name (e.g. element or
attribute or attributeGroup), serves
both to define a particular schema component and to incorporate
it by reference. In the first case the name
attribute is required, in the second the ref
attribute is required. These
two usages are mutually exclusive, and sometimes also depend on
context.
The descriptions of the XML representation
of components, and the
For each kind of schema component there is a corresponding
normative XML representation. The sections below describe the
correspondences between the properties of each kind of schema
component on the one hand and the properties of information
items in that XML representation on the other, together with
constraints on that representation above and beyond those
The language used is as if the correspondences were mappings from XML representation to schema component, but the mapping in the other direction, and therefore the correspondence in the abstract, can always be constructed therefrom.
In discussing the mapping from XML representations to schema
components below, the value of a component property is often
determined by the value of an attribute information item, one of
the
Many properties are identified below as having other schema
components or sets of components as values. For the purposes of
exposition, the definitions in this section assume that (unless
the property is explicitly identified as optional) all such
values are in fact present. When schema components are
constructed from XML representations involving reference by name
to other components, this assumption
Forward reference to named definitions and declarations
Throughout this specification,
The above definition means that comments and processing instructions,
even in the midst of text, are ignored for all
No normalization is done, the
All occurrences of Subsequent to the replacements specified above under
#x9 (tab),
#xA (line feed) and #xD (carriage
return) are replaced with #x20
(space).#x20s are collapsed to a single
#x20, and initial and/or final
#x20s are deleted.
When more than one
If the simple type definition used in an item's
xs:anySimpleType
There are three alternative validation rules which
These three levels of normalization correspond to the processing mandated
in XML 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
A
For an attribute declaration A, if A.
#FIXED attribute values.
See
A more complete and formal presentation of the semantics of
xmlns or xmlns:xsl from
ordinary attributes, identifying them as
The XML representation for an attribute declaration schema
component is an
Attribute declarations can appear at the top level of a schema
document, or within complex type definitions, either as complete
(local) declarations, or by reference to top-level declarations,
or within attribute group definitions. For complete
declarations, top-level or local, the type
attribute is used when the declaration can use a built-in or
pre-declared simple type definition. Otherwise an anonymous
xs:anySimpleType
Attribute information items form
attributeFormDefault
The names for top-level attribute declarations are in their
own
The following sections specify several
sets of XML mapping rules which apply in different
circumstances.
If the If the On If the If the The ref use "prohibited", then it maps both to
an ref use "prohibited", then it maps to
an use='prohibited', then it does not map to,
or correspond to, any schema component at all.
use attribute is not allowed on
top-level
If the
name targetNamespace type xs:anySimpleTypedefault or a fixed ref use='prohibited', in which case the item
corresponds to nothing at all):
use =
requireddefault or a fixed The
name
targetNamespace is present
its
targetNamespace is not present and
form
= qualified form is absent and the attributeFormDefault =
qualified
the targetNamespace
type xs:anySimpleType
ref use='prohibited', in which case the item
corresponds to nothing at all):
use =
requiredref default or a fixed In addition to the conditions imposed on If If the item's parent is not One of If
If
If
If the ancestor
There is a default and fixed default and use are both present,
use optional.ref or name ref is present, then all of form and type type fixed and use are both present,
use prohibited.
targetNamespace name form targetNamespace targetNamespace of
xs:anyType
Informally, an attribute in an XML
instance is locally xsi:type, it is required that the type named
by the attribute be present in the schema.
A logical prerequisite for checking the local validity of an
attribute against an attribute declaration is that the attribute
declaration itself and the type definition it identifies
both be present in the schema.
Local validity of attributes is
tested as part of schema-validity
A more formal statement is given in the following constraint.
For an attribute information item
If xsi:type
(
A declaration which was stipulated by the processor (see
Its A declaration
Schema-validity assessment of an attribute information item
involves identifying its
The schema-validity assessment of an attribute information item depends
on its
For an attribute information item's schema-validity to have been assessed
A 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
See also
All attribute declarations (see
The values of the properties of an attribute declaration if there is a
The use of
xmlns Not Allowed
xmlns Not Allowed
The xmlns.
The xmlns:*.
xsi: Not Allowed
xsi: Not Allowed
The http://www.w3.org/2001/XMLSchema-instance
(unless it is one of the four built-in declarations given in the next section).
This reinforces the special status of these attributes, so that they not
only
It is legal for xsi: attributes to specify default or fixed value
constraints (e.g. in a component corresponding to a schema document construct
of the form <xs:attribute ref="xsi:type" default="xs:integer"/>),
but the practice is not recommended; including such attribute uses will tend
to mislead readers of the schema document, because the attribute uses would
have no effect; see
There are four attribute declarations present in every schema by definition:
xsi:type
The xsi:type attribute
is used to signal use of a type other than the declared type of
an element. See
typehttp://www.w3.org/2001/XMLSchema-instancexsi:nil
The xsi:nil attribute
is used to signal that an element's content is nil
(or null
). See
nilhttp://www.w3.org/2001/XMLSchema-instancexsi:schemaLocation
The xsi:schemaLocation attribute
is used to signal possible locations of relevant schema documents.
See
schemaLocationhttp://www.w3.org/2001/XMLSchema-instancehttp://www.w3.org/2001/XMLSchema-instancexs:anySimpleTypexsi:noNamespaceSchemaLocation
The xsi:noNamespaceSchemaLocation attribute
is used to signal possible locations of relevant schema documents.
See
noNamespaceSchemaLocationhttp://www.w3.org/2001/XMLSchema-instanceElement 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:
For an element declaration E, if E.
A
An element information item is xsi:type attribute
If xsi:nil with the value
true (see
D.xsi:nil =
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
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:anyTypename 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 following sections specify several
sets of XML mapping rules which apply in different circumstances.
If the If the If the If the The ref minOccurs=maxOccurs=0,
then it maps both to a ref minOccurs=maxOccurs=0,
then it maps to a minOccurs=maxOccurs=0,
then it maps to no component at all.
The following mapping rules apply
in all cases where an
name 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 block
blockDefault the
the empty set;
the #all
{};
a set with members drawn from the set
above, each being present or absent depending on whether
the Although the blockDefault
final and finalDefault
block and
blockDefault {}.abstract If the
targetNamespace
ref minOccurs=maxOccurs=0,
minOccurs 1.maxOccurs maxOccurs 1.
targetNamespace is present
its
targetNamespace is not present and
form
qualified
form is absent and the elementFormDefault =qualified
the targetNamespace
ref minOccurs=maxOccurs=0,
minOccurs 1.maxOccurs maxOccurs 1.ref The first example above declares an element whose type, by default, is
xs:anyType
The last two examples illustrate the use of local element declarations. Instances of myLocalElement within
contextOne will be constrained by myFirstType,
while those within contextTwo will be constrained by
mySecondType.
The possibility that differing attribute declarations and/or content models would apply to elements with the same name in different contexts is an extension beyond the expressive power of a DTD in XML.
An example from a previous version of the schema for datatypes. The
facet type is defined
and the facet element is declared to use it. The facet element is abstract -- it's
facet facet, thereby
allowing period or encoding (or
any other member of the group).
The following example illustrates conditional type assignment
to an element, based on the value of one of the element's attributes.
Each instance of the message element will be
assigned either to type messageType or to a more
specific type derived from it.
The type messageType accepts any well-formed XML
or character sequence as content, and carries a kind
attribute which can be used to describe the kind or format of
the message. The value of kind is either one of a
few well known keywords or, failing that, any string.
Three restrictions of messageType are defined, each
corresponding to one of the three well-known formats:
messageTypeString for kind="string",
messageTypeBase64 for kind="base64"
and kind="binary", and
messageTypeXML for kind="xml" or
kind="XML".
The message element itself uses
messageType both as its declared type and
as its default type, and uses test attributes on its
kind attribute:
In addition to the conditions imposed on If the item's parent is not One of If
If
If the ancestor
There is a default and fixed
ref or name ref is present, then all of nillable, default,
fixed, form, block and type
minOccurs, maxOccurs, id
ref.type attribute.targetNamespace is present then
name is present.
form is not present.
targetNamespace targetNamespace of
xs:anyTypetest
When an element is
The
If D has a If
D has no It is a consequence of xs:error
If at least one
If no
Among the element's attribute information items is one
named The The
xsi:type.
S is the
S is Typically, T
would be the
The use of the term
to denote the relation between an
S and T are both complex
type definitions and S is validly derived from T
S is a complex type definition, T is a
simple type definition, and S is validly S is a simple type definition and S is
validly
validly substitutable without
limitation
.
Sometimes one type S is
The concept of local validity of an
element information item against an element declaration is
an important part of the schema-validity
Informally, an element is locally valid
against an element declaration when:
The declaration is present in the schema The element is declared concrete (i.e. not abstract). Any Any
The element's content satisfies the appropriate constraints:
If the element is empty and the declaration specifies a
default value, the default is checked against the
appropriate type definitions.
Otherwise, the content of the element is checked against
the
The element satisfies all the identity constraints specified
on the element declaration.
Additionally, on the xsi:nil attribute on the element obeys the
rules. The element is allowed to have an xsi:nil
attribute only if the element is declared nillable, and
xsi:nil = 'true' is allowed only if the element
itself is empty. If the element declaration specifies a
fixed value for the element, xsi:nil='true'
will make the element invalid.
xsi:type attribute present names a
type which is
The following validation rule gives the normative formal definition of local validity of an element against an element declaration.
For an element information item
If E has an The If an
If The element information item with
If the the If xsi:nil attributexsi:nilxsi:nil = falsexsi:nil
= truexsi:type
If an element has an xsi:type attribute whose
value does not
The following validation rule specifies
formally what it means for an element to be locally valid
against a type definition. This concept is appealed to in the
course of checking an element's local validity against its
element declaration, but it is also part of schema-validity
xs:anyType.
Informally, local validity against a type requires first
that the type definition be present in the schema and not declared abstract.
For a simple type definition, the element must lack attributes
(except for namespace declarations and the special attributes
in the xsi namespace) and child elements, and must
be type-valid against that simple type definition.
For a complex type definition, the element must
be locally valid against that complex type definition.
Also, if the element has an xsi:type attribute,
then it is not locally valid against any type other than the
one named by that attribute.
For an element information item
If T is a complex type definition, then
T.
If
If
This rule only covers the case when a xsi:type,
xsi:nil,
xsi:schemaLocation, or
xsi:noNamespaceSchemaLocationxsi:type xsi:type
The following validation rule
specifies document-level ID/IDREF constraints checked on the
For an element information item There There
See
The first clause above
Although this rule applies at the
This reconstruction of ID/IDREF functionality is imperfect in that if
the
This section gives the top-level rule
for Assessment begins with the identification of a
The element's attributes are to be The element's children are to be xsi:type attribute), otherwise the element
will be
A
declaration stipulated by the processor (see Its A declaration it is the
processor has stipulated a type definition a
An A type definition stipulated by the processor (see
An The An The An
The schema-validity assessment of an element information item
depends on its
A If that evaluation involved the evaluation of
A The
For each of the attribute information items among
the attribute has a
its schema-validity is assessed with respect to that
declaration, as defined in
its schema-validity is not assessed.
For each of the element information items among its
the child has a
its schema-validity is assessed with respect to that
declaration or type definition, as defined in
the child is
its schema-validity is not assessed.
its schema-validity is xs:anyType
xs:anyType
When an element information item is xsi:
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
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 If If For each member M of E. If xs:error
For an element declaration (call it
There is a chain of The set of all
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
Not all combinations of
The as the as the as the xsi:type attribute;
see
See
The XML representation for a complex type definition schema component is a
The XML representation for complex type definitions with a
<complexType name="anyThing"/> is allowed.
Aside from the simple coherence requirements outlined
The following sections describe
different sets of mapping rules for complex types; some
are common to all or many source declarations, others
only in specific circumstances.
If the If the If the
Where convenient, the mapping rules are
described exclusively in terms of the schema document's
information set. The mappings, however, depend not only upon
the source declaration but also upon the schema context. Some
mappings, that is, depend on the properties of other components
in the schema. In particular, several of the mapping rules
given in the following sections depend upon the
Whichever
alternative for the content of
name targetNamespace abstract block
blockDefault the
the empty set;
the #all
{};
a set with members drawn from the set
above, each being present or absent depending on whether
the Although the blockDefault
final and finalDefault
block and
blockDefault name
If the
When the
When
base the
starting from either
the simple type definition corresponding to the
otherwise (
the
xs:anySimpleType
the
the
the
that simple type definition;
xs:anySimpleType
When the
Complex types with complex content can
be the image of two different forms of
When the
base When the xs:anyType
xs:anyTypeFor complex types with complex content,
the
The mapping rule below refers here and there to elements
not necessarily present within a If the
, if no abc attribute is present
on the abc attribute is present on the
(non-existent)
When the mapping rule below refers to the
, then for a
The mapping rule also refers to the value of the
the its the its mixed mixed false.
It is a consequence of
There is no There is an the particle corresponding to the
minOccurs
0 and
which has no maxOccurs