This is a
Public Working Draft of XML Schema 1.1. It
is here made
available for review by W3C members
This draft was published
on 31 August 2006.
The major changes since the previous draft are:
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. Several of the constraints imposed by version 1.0 of this
specification on Wildcards are now allowed in The value of The presentation of the Terms have been defined to describe different subsets of the
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 discussion of schema-validity assessment and the invocation
of conforming processors has been revised; additional invocation
patterns have been identified, and names have been given to
the different methods of invoking a processor. When an element cannot be strictly validated because no
element declaration or type definition is available
for it, fallback to lax validation (validating the element
against the built-in type The Unique Particle Attribution constraint has been relaxed.
It is no longer prohibited for a content model to have
element particles and wildcard particles which compete with
each other; competition is still prohibited between
element particles and between wildcard particles.
The exposition of the constraint has also been revised
for clarity. 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. A check-clause mechanism has been added. Complex types
may now include assertions about interrelations among their
attributes and descendants, which must be satisfied in order
for elements to be locally valid against the type.
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.
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 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 the XML Schema specification, including the XML transfer syntax for schemas itself.
Provision of support for co-occurrence constraints, that is constraints which make the presence of an attribute or element, or the values allowable for it, depend on the value or presence of other attributes or elements.
These goals are in
tension with one another
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
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:
All such issues are
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 XML Schema-aware processors are permitted to but need not behave as described.
It is recommended that conforming documents and XML Schema-aware processors behave as described, but there can be valid reasons for them not to; it is important that the full implications be understood and carefully weighed before adopting behavior at variance with the recommendation.
Conforming documents and XML Schema-aware processors are required to behave as described; otherwise they are in error.
Conforming documents and XML Schema-aware processors are forbidden to behave as described; if they do they are in error.
These definitions describe in
terms specific to this document the meanings assigned to
these terms by
This chapter gives an overview of
An XML Schema
Version 1.0 included several properties in the PSVI whose absence carried
information (e.g.
For 142, which mandates that insofar as possible absence of a property should not in general signify, when it does explicit 'if-and-only-if' language is required, the effect is distributed throughout the PSVI sub-sub-sections in section 3.
The Working Group appears to be close to consensus (although no final
decision has been made) on views which can be summarized thus:
We should eliminate any dependency on the absence of specific
properties (i.e. important situations should be describable
and distinguishable in terms of properties and their values,
without appeal to the absence of particular properties), or if
this proves unfeasible in particular cases we should say
explicitly that a property is present "if and only if" certain
conditions apply. Any remaining "if" (if any) would be a
true conditional, not an equivalence. Any specification of a class of processors (including ours) can
require specific additional information not in the PSVI, though
should note that interoperability is better if applications depend
only on the properties present in the PSVI as we define it. In our own specification of processor classes, we should be
explicit that processors may provide additional information.
(Or alternatively be explicit that they must not -- but the
chair believes the WG consensus was to allow it.)
For 144, a few general remarks here about flexible-but-firm conformance are wanted here; most of the new work should end up in section 4 and/or 5.
Schema-validity assessment has two aspects:
Determining local schema-validity, that is
whether an element or attribute information item satisfies the
constraints embodied in the relevant
components of an XML Schema; 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,
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
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.
Version 1.0 made clear that the
A major change in definition/presentation, with only modest changes
in consequences for schemas and validity, will be made, by
Clarifying: R restricts B: any EII that is locally valid [per R]
[-
A non-normative appendix will provide references to published algorithms for enforcing the constraint.
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
The mapping from lexical space to value space is
unspecified for items whose type definition is the
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 the
a restriction of a complex an
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.
This specification allows only appending, and not other kinds of
extensions. This decision
simplifies application processing required to cast instances from
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 information item to be 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.
An assertion is a predicate associated with a type,
which is checked for each instance of the type. Depending
on their formulation, assertions are either required to be
true of the instance, or required to be false. If an
element or attribute information item fails to satisfy an
assertion associated with a given type, then that information
item is not locally
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
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.
By separating the conformance requirements relating to the concrete
syntax of XML schema documents, this specification admits processors
which use schemas stored in optimized binary representations,
dynamically created schemas represented as programming language data
structures, or implementations in which particular schemas are
compiled into executable code such as C or Java. Such processors can
be said to be
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.
This specification must choose either to use the same namespace as XML Schema 1.0, or to use a different namespace, or to use more than one namespace. An explicit decision should be made.
http://www.w3.org/2001/XMLSchema-instance.
For brevity, the text and examples in this specification use the prefix
xsi: to stand for this latter namespace; in practice,
any prefix can be used. All schema processors have appropriate attribute
declarations for these attributes built in, see
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
Version 1.0 was deliberately reticent in stating identity conditions for components. With hindsight this was a mistake, and will be corrected.
Add {scope} property to type definition components
which will either be the enclosing element declaration or "global", by
analogy with element declarations {scope}. [For further
context, see
This change will solve the anonymous type equality problem by giving an
unequivocal answer to the who am I?
question for such types by way of the
answer Your identity is determined by your scope's identity.
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 implementation-defined whether a schema processor
uses the definition of legal character from
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 XML Schema namespace itself: these appear as annotations in the
corresponding schema component; All of them allow an
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).#x20s are collapsed to a single
#x20, and initial and/or final #x20s 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
Neither the prose of this specification nor the
schema for schema documents rules out XML representations of
attribute declarations containing both use='prohibited' and
fixed='...'. It
will be made clear that this is not an error and that
‘prohibited’ wins.
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 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 the
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 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
For an attribute information item to be locally The declaration Its The item's The item's
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 resolved to by its A declaration was stipulated by the processor (see Its Both
An attribute with no type declaration cannot be 'assessed', as defined by (Schema-Validity Assessment (Attribute)), so it will never have any PSVI properties, whereas it would be natural for it to have [validation attempted] = none and [validity] = notKnown. This will be fixed.
It is likely that the current backward-chaining approach to defining schema-validity assessment will be reworked, in which case this will get fixed as part of that.
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 an attribute information item is
If
The
If the
The first (
Also, if
If the attribute information item was not The item's The
All attribute declarations (see
The values of the properties of an attribute declaration
if there is a
If the
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.
There are four attribute declarations present in every schema by definition:
typehttp://www.w3.org/2001/XMLSchema-instancenilhttp://www.w3.org/2001/XMLSchema-instanceschemaLocationhttp://www.w3.org/2001/XMLSchema-instancehttp://www.w3.org/2001/XMLSchema-instancenoNamespaceSchemaLocationhttp://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:
The
A
A
An element information item is
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 substitution group, if any, identified
by
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 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
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 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 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
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 substitution group. Finally a type is defined which refers to facet, thereby
allowing period or encoding (or
any other member of the group).
In addition to the conditions imposed on If the item's parent is not One of If 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.
For an element information item to be locally 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 the declaration has a
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
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 http://www.w3.org/2001/XMLSchema-instance and whose type, nil, schemaLocation or noNamespaceSchemaLocation.
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
The schema-validity assessment of an element information item depends
on its
So for an element information item's schema-validity to be assessed
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 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 all the element information items among its
http://www.w3.org/2001/XMLSchema-instance and whose type.
If the item cannot be
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
If
If
the
The
If the
The first (
Also, if the declaration has a
Note that if an element is
If
the item is
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
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
Although extremely useful, wildcards have proved to interact in unfortunate ways with the Unique Particle Attribution and Element Declarations Consistent constraints, and this has limited their utility, particularly for use in allowing for extension and anticipating subsequent versions. The interpretation of wildcards will be changed to address these problems, without compromising backward compatibility.
The XML representation of a complex type definition.
A complex type definition schema component has the following properties:
Version 1.0 was inconsistent in providing for multiple sources of
annotation, particularly where components corresponded to multiple nested
elements in schema documents (e.g. Complex Type Definitions xs:complexType, xs:complexContent and
xs:restriction). This will change so that all components can have
multiple annotations, and annotations will be handled consistently across all
kinds of components.
Also applies anywhere else {annotations} plural appears — everywhere, in fact.
All components have an {annotations} property;
It contains a sequence of annotations;
Namely all annotations "scoped" by this component, but not "scoped" by any other component "further down".
The order of annotations within {annotations} is implementation-determined.
Note that when point 3 above mentions "annotations 'scoped' by . . ."
this means <annotation> elements
[
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
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 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 intensional intersection of 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
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 A particle whose properties are as follows:
A model group whose minOccurs 0;true11
Then the value of the property is
the
the the
the the
the type definition a a A model group whose true, otherwise base base true, otherwise 11base
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.
In addition to the conditions imposed on If the If the The type definition a complex type
definition whose only if the
only if the
If Although not explicitly ruled out either here or in The corresponding complex type definition component base base <xs:complexType . . .mixed='true' when the
For an element information item to be locally If the the element
information item has no character or element information item the the element information item has no element
information item the the
element information item has no character information item It is implementation-defined whether a schema processor supports
the definition of the the sequence of the element information item's element
information item For each attribute information item in the element information
item's there is among the the attribute information
There The
attribute information item The 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 The element information item is http://www.w3.org/2001/XMLSchema-instance and whose type, nil, schemaLocation or noNamespaceSchemaLocation,
When an
For each attribute use in the
Constructed default attribute information items in the PSVI did not have a [normalized value] property, only a [schema normalized value], making them incompatible with ordinary attribute infoitems. On balance, it seems sensible to correct this.
Add a [normalized value] property to the constructed attribute infoitem which arises when a default value is applied.
The
The
The
The
The nearest ancestor element information item with a
The added items
All complex type definitions (see
The values of the properties of a complex type definition
If the
If the the
The Its If it has an
The The
The
The
Both
The It This requirement ensures that nothing removed by a restriction
is subsequently added back by an extension. It is trivial to check if the
extension in question is the only extension in its Constructing the intermediate type definition to check this
constraint is straightforward: simply re-order the The the
The The
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 The complex type definition
The
In Members of a type, A, whose definition is a restriction of
the definition of another type, B, are always members of type B as well.
A type definition All element information items which are
When type definitions are assigned to children or attributes
of an element information item in the PSVI by both When element declarations are assigned to children or
attributes of an element information item in the PSVI by both
Either
It will be noted that valid restriction involves both a subset
relation on the set of elements valid against
In practice, it is difficult to enforce the definition above directly as a Constraint on Components, owing to a number of corner cases which are difficult to detect or describe concisely. The following constraint is the operationally normative statement.
Every element information item which is
If restriction
)
base
) if and only if
When the child sequence of an element information item Either explicitly present, or successfully located as a result of a
An undischarged a An undischarged
Either Either
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 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
Either Either
To restrict a complex type definition with a simple base type definition
to
The following constraint defines a relation appealed to elsewhere in this specification.
For a complex type definition (call it If
it it
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
substitution groups), that the type used is actually
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
There is a
The outer particle of
The inner particle of
The mixed content specification together with the
There is
The outer particle of
The inner particle of
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:
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
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 schemas does not allow
them on the child of
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
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
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
=1which is
Some corner cases, e.g. involving 'skip' wildcards, have emerged with
respect to this constraint. It will be restated at a higher level of
abstraction, in terms of desired outcome. See also
This constraint will be restated in terms of intended outcome, i.e. that (modulo the impact of xsi:type) validation of an EII with a type definition will always assign the same type definitions to elements or attributes of the same name.
If the all their all their
all their
A content model
Content models in which an
This constraint reconstructs for XML Schema the equivalent
constraints of
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
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 expanded name of E or the expanded name of E resolves to an element
declaration D2 which is substitutable for D.
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
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
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.=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
processContents