This is a
This draft was published
on 30 August 2007.
The major revisions since the previous draft include:
A mechanism for conditional type assignment has been defined;
this allows the Element declarations may now specify multiple substitution group
heads. A default attribute group may now be specified at the
schema-document level; all complex types defined in the schema
document will include that attribute group unless they specify
otherwise; this makes it easier to specify that particular
attributes are to be accepted by Content models may now be defined as Wildcards may now be defined which match only elements
Complex types whose content models are The assertions facility defined in the previous working draft
has been revised; the Elements may now have more than one attribute of type Various enhancements to the definition of the Some aspects of the use of A conditional-inclusion mechanism has been defined to allow
XSDL 1.1 processors to cope more successfully with constructs defined
in future versions of this specification, if any.
Schema authors can use this mechanism to define alternative
constructs depending on the version of the processor, so that the
same schema document can be usable with processors supporting
different versions of XSDL.
Numerous editorial changes and small bug fixes have been made
in the interests of clarity and correctness.
open
,
which means that elements other than those explicitly named
will be accepted during validation.
Several styles and degrees of openness are possible;
they can be configured at the level
of the schema document or of the complex type definition.
not-in-schema
wildcards).all-groups
may now be extended. (This change is in addition to other changes
in all-groups described in xs:ID.
For those primarily interested in the changes since version 1.0,
the
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 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
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: xsd:
The namespace for schema documents is unchanged from version
1.0 of this specification, because any schema document valid
under the rules of version 1.0 has essentially the same
validation semantics under this specification as it did under
The data model used by untyped,
untypedAtomic) which are not defined in this
specification; see the
Users of the namespaces defined here should be aware, as a
matter of namespace policy, that more names
xsi)
http://www.w3.org/2001/XMLSchema-instance.
For brevity, the text and examples in this specification use
the prefix xsi: to stand for this namespace; in
practice, any prefix can be used.
Users of the namespaces defined here should be aware, as a
matter of namespace policy, that more names
vc)
The pre-processing of schema documents described in
http://www.w3.org/2007/XMLSchema-versioning.
For brevity, the text and examples in this specification use
the prefix vc: to stand for this
namespace; in practice, any prefix can be used.
Users of the namespaces defined here should be aware, as a matter of namespace policy, that more names in this namespace may be given definitions in future versions of this or other specifications.
Several namespace prefixes are conventionally used in this
document for notational convenience. The following bindings are
assumed.fn bound to
http://www.w3.org/2005/xpath-functions (defined
in html bound to
http://www.w3.org/1999/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)xsd bound to http://www.w3.org/2001/XMLSchema
(defined in this and related specifications)xs and the prefix xsd for
the xsi bound to
http://www.w3.org/2001/XMLSchema-instance (defined in this and
related specifications)xsl bound to
http://www.w3.org/1999/XSL/Transform
In practice, any prefix bound to the appropriate namespace
name xml and
xmlns).
xsl:quantity lacks any binding for
the prefix xsl (and does XSL define a name
quantity); (2) We need references (informative?)
to the RDDL and XLink specs.
Sometimes other specifications or Application Programming
Interfaces (APIs) need to refer to the
Identifies the
Identifies the language described in version http://www.w3.org/ identifies
http://www.w3.org/ identifies
Identifies the language described in the 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
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.
Special terms are defined at their point of introduction in the
text. For example
Non-normative examples are set off in boxes and accompanied by a brief explanation:
And an explanation of the example.
The definition of each kind of schema component consists of a list of its properties and their contents, followed by descriptions of the semantics of the properties:
An example property
References to properties of schema components are links to the
relevant definition as exemplified above, set off with curly
braces, for instance
The correspondence between an element information item which is
part of the XML representation of a schema and one or more schema
components is presented in a tableau which illustrates the
element information item(s) involved. This is followed by a
tabulation of the correspondence between properties of the
component and properties of the information item. Where context
In the XML representation, bold-face attribute names (e.g.
size
below; if there is a default value, it is shown following a
colon. Where an attribute information item has a built-in simple
type definition defined in
The allowed content of the information item is shown as a
grammar fragment, using the Kleene operators ?,
* and +. Each element name therein is
a hyperlink to its own illustration.
The illustrations are derived automatically from the
size References to elements in the text are links to the relevant
illustration as exemplified above, set off with angle brackets,
for instance
References to properties of information items as defined in
Properties which this specification defines for information items are introduced as follows:
References to properties of information items defined in this
specification are notated as links to their introduction as
exemplified above, set off with square brackets, for example
The following highlighting is used for non-normative commentary in this document:
General comments directed to all readers.
Conforming documents and
It is recommended that conforming documents and
Conforming documents and
Conforming documents and
These definitions describe in terms
specific to this document the meanings assigned to these terms by
This chapter gives an overview of
An
Schema-validity assessment has two aspects:
Determining local schema-validity,
that is whether an element or attribute information item
satisfies the constraints embodied in the relevant components
of an Synthesizing an overall validation outcome for the
item, combining local schema-validity with the results of
schema-validity assessments of its descendants, if any, and
adding appropriate augmentations to the infoset to record this
outcome.
Throughout this specification,
Throughout this specification,
During See also the definitions of
This specification builds on
Just as
Simple type definitions
Complex type definitions
Attribute declarations
Element declarations
The secondary components, are as follows:
Attribute group definitions
Identity-constraint definitions
Type alternatives
Model group definitions
Notation declarations
Finally, the helper
components provide small
parts of other components; they are not independent of their
context:
Annotations
Model groups
Particles
Wildcards
Attribute Uses
The name
During
On the other hand,
At the abstract level, there is no requirement that the
components of a schema share a
The abstract model provides two kinds of type definition component: simple and complex.
Type definitions form a hierarchy with a single root. The subsections below first describe characteristics of that hierarchy, then provide an introduction to simple and complex type definitions themselves.
xs:anyType
error
For brevity, the text and examples in this specification often
use the qualified names xsd:anyType and
xsd:error for these type definitions. (In
practice, any appropriately declared prefix can be used, as
described in
A simple type definition is a set of constraints on strings
and information about the values they encode, applicable to the
Each simple type definition, whether built-in (that is,
defined in xs:anyType
The mapping from lexical space to value space is unspecified
for items whose type definition is
The Working Group expects to return to this area in a future version of this specification.
For detailed information on simple type definitions, see
A complex type definition is a set of attribute declarations
and a content type, applicable to the
Each complex type definition other than a restriction of a complex an xs:anyType
A complex type which extends another does so by having
additional content model particles at the end of the other
definition's content model, or by having additional attribute
declarations, or both.
all-groups in ways that do not
guarantee that the new material occurs only at the end of
the content.
For detailed information on complex type definitions, see
There are three kinds of declaration component: element, attribute, and notation. Each is described in a section below. Also included is a discussion of element substitution groups, which is a feature provided in conjunction with element declarations.
An element declaration is an association of a name with a type definition, either simple or complex, an (optional) default value and a (possibly empty) set of identity-constraint definitions. The association is either global or scoped to a containing complex type definition. A top-level element declaration with name 'A' is broadly comparable to a pair of DTD declarations as follows, where the associated type definition fills in the ellipses:
Element declarations contribute to
For detailed information on element declarations, see
In XML, the name
and content of an element
All such members
Note that element substitution groups are not represented as
separate components. They are specified in the property values
for element declarations (see
An attribute declaration is an association between a name and
a simple type definition, together with occurrence information
and (optionally) a default value. The association is either
global, or local to its containing complex type definition.
Attribute declarations contribute to
For detailed information on attribute declarations, see
A notation declaration is an association between a name and
an identifier for a notation. For an attribute NOTATION simple type definition, its value
For detailed information on notation declarations, see
The model group, particle, and wildcard components contribute to the portion of a complex type definition that controls an element information item's content.
A model group is a constraint in the form of a grammar fragment that applies to lists of element information items. It consists of a list of particles, i.e. element declarations, wildcards and model groups. There are three varieties of model group:
Sequence (the element information items match the particles in sequential order);
Conjunction (the element information items match the particles, in any order);
Disjunction (the element information items match one of the particles).
Each model group denotes a set of
sequences of element information items. Regarding that set of
sequences as a language, the set of sequences recognized by a
group G may be written L(G).
For detailed information on model groups, see
A particle is a term in the grammar for element content,
consisting of either an element declaration, a wildcard or a
model group, together with occurrence constraints.
Particles contribute to
The name
Each content model, indeed each particle,
denotes a set of sequences of element information items. Regarding
that set of sequences as a language, the set of sequences recognized
by a particle P may be written L(P).
The language accepted by a content model plays a role in determining
whether an element information item is locally valid or not: if the
appropriate content model does not accept the sequence of elements
among its children, then the element information item is not locally
valid.
No assumption is made, in the definition above,
that the items in the sequence are themselves valid; only the
If a sequence S is a member of L(P),
then it is necessarily possible to trace a path through the
This
For detailed information on particles, see
An attribute use plays a role similar to that of a particle, but for attribute declarations: an attribute declaration within a complex type definition is embedded within an attribute use, which specifies whether the declaration requires or merely allows its attribute, and whether it has a default or fixed value.
A wildcard is a special kind of particle which matches element
and attribute information items dependent on their namespace
name
For detailed information on wildcards, see
An identity-constraint definition is an association between a name
and one of several varieties of identity-constraint related to
uniqueness and reference. All the varieties use
For detailed information on identity-constraint definitions, see
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 and for XSDL-aware processors.
A It is valid with respect to the schema specified
in No element in the schema document violates any of the
Schema Representation Constraints set out in
While conformance of schema documents is a precondition for
the mapping from schema documents to schema components described
in this specification, conformance of the schema documents does
not guarantee that the result of that mapping will be a schema
that conforms to this specification. Some constraints (e.g. the
rule that there must be at most one top-level element
declaration with a particular
Some Schema Representation Constraints cannot, in their current formulation, be checked against the schema document in isolation, but only in the context of the schema as a whole. It is a consequence that in some cases, the conformance of a schema document cannot be determined in isolation.
This specification describes three levels of conformance for schema aware processors. The first is required of all processors. Support for the other two will depend on the application environments for which the processor is intended.
The
By separating the conformance requirements relating to the
concrete syntax of
In version 1.0 of this specification the class of conformant
to the XML Representation of Schemas
. Similarly, the
class of fully conforming
.
Although this specification provides just these three standard levels of conformance, it is anticipated that other conventions can be established in the future. For example, the World Wide Web Consortium is considering conventions for packaging on the Web a variety of resources relating to individual documents and namespaces. Should such developments lead to new conventions for representing schemas, or for accessing them on the Web, new levels of conformance can be established and named at that time. There is no need to modify or republish this specification to define such additional levels of conformance.
See
As discussed in pool
, then it would be
impossible to have, for example, a simple type definition and an
element declaration both with the name title
in a
given
Therefore
Locally scoped attribute and element declarations are special
with regard to symbol spaces. Every complex type definition
defines its own local attribute and element declaration symbol
spaces, where these symbol spaces are distinct from each other
and from any of the other symbol spaces. So, for example, two
complex type definitions having the same target namespace can
contain a local attribute declaration for the unqualified name
priority
, or contain a local element declaration
for the name address
, without conflict or
necessary relation between the two.
http://www.w3.org/2001/XMLSchema-instance) described in
The xsi:type. The value of this attribute is a
xsi:nil
with the value true. An element so labeled
The xsi:schemaLocation and
xsi:noNamespaceSchemaLocation attributes can be
used in a document to provide hints as to the physical location
of schema documents which
On the World Wide Web, schemas are conventionally represented
as XML documents (preferably of MIME type
application/xml or text/xml, but see
The following sections provide full details on the composition
of all schema components, together with their XML representations
and their contributions to properties: their values and significance XML representation and the mapping to properties constraints on representation validation rules constraints on the components themselves
Components are defined in terms of their properties, and each
property in turn is defined by giving its range, that is the
values it
A schema and its components as defined in this chapter are an
idealization of the information a schema-aware processor
requires: implementations are not constrained in how they
provide it. In particular, no implications about literal
embedding versus indirection follow from the use below of
language such as properties . . . having . . .
components as values
.
Component properties are simply named
values. Most properties have either other components or
literals (that is, strings or booleans or enumerated keywords)
for values, but in a few cases, where more complex values are
involved,
Any property
It is
The principal purpose of http://www.w3.org/2001/XMLSchema. Although a common way of creating
the XML Infosets which are or contain
Two aspects of the XML representations of components presented
in the following sections are constant across them all:
All of them allow attributes qualified with namespace names
other than the All of them allow an
The descriptions of the XML representation
of components, and the
For each kind of schema component there is a corresponding
normative XML representation. The sections below describe the
correspondences between the properties of each kind of schema
component on the one hand and the properties of information
items in that XML representation on the other, together with
constraints on that representation above and beyond those
implicit in the
The language used is as if the correspondences were mappings from XML representation to schema component, but the mapping in the other direction, and therefore the correspondence in the abstract, can always be constructed therefrom.
In discussing the mapping from XML representations to schema
components below, the value of a component property is often
determined by the value of an attribute information item, one of
the
Many properties are identified below as having other schema
components or sets of components as values. For the purposes of
exposition, the definitions in this section assume that (unless
the property is explicitly identified as optional) all such
values are in fact present. When schema components are
constructed from XML representations involving reference by name
to other components, this assumption
Forward reference to named definitions and declarations
Throughout this specification,
The above definition means that comments and processing instructions,
even in the midst of text, are ignored for all
No normalization is done, the value is the All occurrences of Subsequent to the replacements specified above under #x9 (tab), #xA (line feed) and
#xD (carriage return) are replaced with #x20 (space).#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
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
targetNamespace is present
its
targetNamespace is not present and
form is present and its qualified
form is absent and the attributeFormDefault on the qualified
the targetNamespace
type otherwise (the ref use='prohibited', in which case the item
corresponds to nothing at all):
use
required, otherwise
ref default or a fixed
Attribute declarations can appear at the top level of a schema document, or within complex
type definitions, either as complete (local) declarations, or by reference to top-level
declarations, or within attribute group definitions. For complete declarations, top-level or local, the type attribute is used when the declaration can use a
built-in or pre-declared simple type definition. Otherwise an
anonymous
The default when no simple type definition is referenced or
provided is
Attribute information items form attributeFormDefault
The names for top-level attribute declarations are in their own
In addition to the conditions imposed on If If the item's parent is not One of If
If
If
If the ancestor
Let The corresponding attribute
declaration default and fixed default and use are both present,
use optional.ref or name ref is present, then all of form and type type and fixed and use are both present,
use prohibited.
targetNamespace is present then
name is present.
form is not present.
targetNamespace targetNamespace of
For an attribute information item to be locally The declaration Its The item's The item's
If the declaration is the built-in declaration for xsi:type
(
A declaration which was stipulated by the processor (see
Its A declaration
The schema-validity assessment of an attribute information item depends
on its
For an attribute information item's schema-validity to have been assessed
A 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
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
It is not illegal for xsi: attributes to specify default or fixed value
constraints (e.g. in a component corresponding to a schema document construct
of the form <xsd:attribute ref="xsi:type" default="xsd:integer"/>),
but the practice is not recommended; including such attribute uses will tend
to mislead readers of the schema document, because the attribute uses would
have no effect; see
There are four attribute declarations present in every schema by definition:
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 xsi:type attribute
If nil from namespace
http://www.w3.org/2001/XMLSchema-instance and value true
(see
The provision of defaults for elements goes beyond what is
possible in XML DTDs,
and does not exactly correspond to defaults for attributes. In
particular, an element with a non-empty
Element declarations are potential members of the
An empty
The supplied values for
Element declarations for which
See
The XML representation for an element declaration schema
component is an
If the
name targetNamespace 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 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
targetNamespace is present
its
targetNamespace is not present and
form is present and its qualified
form is absent and the elementFormDefault on the qualified
the targetNamespace
otherwise (the ref minOccurs=maxOccurs=0, in which case the item
corresponds to no component at all):
minOccurs 1.maxOccurs maxOccurs 1.ref ref attribute) or local declarations (otherwise). For complete declarations, top-level or local, the type attribute is used when the declaration can use a
built-in or pre-declared type definition. Otherwise an
anonymous
Element information items form elementFormDefault
As noted above the names for top-level element declarations are in a separate
Note that the above allows for two levels of defaulting for unspecified
type definitions. An substitutionGroup xs: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 first example above declares an element whose type, by default, is
xs:anyType
The last two examples illustrate the use of local element declarations. Instances of myLocalElement within
contextOne will be constrained by myFirstType,
while those within contextTwo will be constrained by
mySecondType.
The possibility that differing attribute declarations and/or content models would apply to elements with the same name in different contexts is an extension beyond the expressive power of a DTD in XML.
An example from a previous version of the schema for datatypes. The
facet type is defined
and the facet element is declared to use it. The facet element is abstract -- it's
facet facet, thereby
allowing period or encoding (or
any other member of the group).
The following example illustrates conditional type assignment
to an element, based on the value of one of the element's attributes.
Each instance of the message element will be
assigned either to type messageType or to a more
specific type derived from it.
The type messageType accepts any well-formed XML
or character sequence as content, and carries a kind
attribute which can be used to describe the kind or format of
the message. The value of kind is either one of a
few well known keywords or, failing that, any string.
Three restrictions of messageType are defined, each
corresponding to one of the three well-known formats:
messageTypeString for kind="string",
messageTypeBase64 for kind="base64"
and kind="binary", and
messageTypeXML for kind="xml" or
kind="XML".
The message element itself uses
messageType both as its declared type and
as its default type, and uses test attributes on its
kind attribute:
In addition to the conditions imposed on If the item's parent is not One of If
If
If the ancestor
Let The corresponding particle and/or element declarations
satisfy the conditions set
out in default and fixed
ref or name ref is present, then all of nillable, default,
fixed, form, block and type
minOccurs, maxOccurs, id
ref.targetNamespace is present then
name is present.
form is not present.
targetNamespace targetNamespace of
test
When an element is
The
If D has a If
D has no It is a consequence of xsd:error
If at least one
If no
Among the element's attribute information items is one
named The The xsi:type, that is an http://www.w3.org/2001/XMLSchema-instance and whose type.
S is the
S is Typically, T
would be the
S and T are both complex
type definitions and S is validly derived from T
S is a complex type definition, T is a
simple type definition, and S is validly S is a simple type definition and S is
validly
validly substitutable without
limitation
.
Sometimes one type S is
For an element information item The declaration Its There is no such attribute information item. There is such an attribute information item, and its
There is such an attribute information item, and its
The element information item has no character or
element information item There is no If there is an attribute information
item named E has an The If an the declaration
If the The element information item with the the declaration has no The element information item If there is a The element information item the the the the The element information item If the element information item is the http://www.w3.org/2001/XMLSchema-instance and whose nil.false.true, and
xsi:type among the http://www.w3.org/2001/XMLSchema-instance and whose type), then
The
If an element has an xsi:type attribute whose
value does not
For an element information item to be locally The type definition
It the type definition is a simple type
definition
The element information item's The element information item If the type definition is a complex type
definition the element information item
If the element information item has an Informally, this rule means that an element with an
This rule only covers the case when a http://www.w3.org/2001/XMLSchema-instance and whose type,
nil, schemaLocation or
noNamespaceSchemaLocation.xsi:type
http://www.w3.org/2001/XMLSchema-instance and whose type) and does not have a
xsi:type
xsi:type attribute cannot be locally valid
with respect to any type other than that named in the
attribute.
For an element information item which is the
There There
See
The first clause above applies when there is a reference to
an undefined ID. The second applies when there is a
multiply-defined ID. They are separated out to ensure that
distinct error codes (see
Although this rule applies at the
This reconstruction of ID/IDREF functionality is imperfect in that if
the
A
declaration stipulated by the processor (see Its A
declaration it is the
processor has stipulated a type definition a
An
A type definition stipulated by the processor (see
An The
An
The An
The schema-validity assessment of an element information item
depends on its
A Its If that evaluation involved the evaluation of
It does not have a A The element information item's
For each of the attribute information items among its
the attribute has a
its schema-validity is assessed with respect to that
declaration, as defined in
its schema-validity is not assessed.
For each of the element information items among its
the child has a
its schema-validity is assessed with respect to that
declaration or type definition, as defined in
the child is
its schema-validity is not assessed.
its schema-validity is 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 the properties of an element declaration
If there is a
If there is a
If there is a
If there is a
xsd:error
The following constraints define relations appealed to elsewhere in this specification.
For a the type definition is a simple type
definition
the type definition is a complex type definition
its the
For an element declaration (call it The blocking constraint does not contain
There is a chain of The set of all
Complex Type Definitions provide for:
Constraining element information items by providing
Constraining element information item
Constraining
elements and attributes
Using the mechanisms of
Specifying
Limiting the ability to
Controlling the permission to substitute, in an instance, elements of a
The XML representation of a complex type definition.
A complex type definition schema component has the following properties:
Complex type definitions are identified by their
The
As described in
A complex type with an empty specification for final attribute of its own, final for anything.
The
Complex types for which
A A A A
A
See
The XML representation for a complex type definition schema component is a
The XML representation for complex type definitions with
a
Whichever alternative for the content of
name targetNamespace abstract
block blockDefault the
the empty set;
the #all
{};
a set with members drawn from the set above, each being present or
absent depending on whether the Although the blockDefault
final and finalDefault block and blockDefault
name When the
base
If the
defaultAttributesApplytrue, and the defaultAttributesref defaultAttributes
The set of attribute uses corresponding to the
The ref
If the type definition the what would have been the base use
there is an a wildcard based
on the
there are no the there are one or more
there is an a wildcard whose there is no a wildcard whose properties are as follows:
The The
The value is then determined by
the the the
the type definition that The value is then determined by
the
the the a wildcard whose (the base
the type definition base
starting from either
the simple type definition corresponding to the otherwise (base
the type definition base
starting from
the simple type definition corresponding to the
the type definition base
the
(the type definition base
When the
The property mappings below are xs:anyType
base the its the its mixed mixed false.
There is no There is an There is a the particle
corresponding to the minOccurs 0;maxOccurs
the A particle whose properties are as follows:
A model group whose true11
the
the the
the the
the type definition a a the the the a the a model group whose
a model group whose true, otherwise base base true, otherwise base 111
the
the
the
the
the
the
appliesToEmpty
Then the value of the property is
the
the
the
a
mode 'none'
mode
If the
Aside from the simple coherence requirements enforced above, constraining
type definitions identified as restrictions to actually
The use attribute of an
Careful consideration of the above concrete syntax reveals that
a type definition need consist of no more than a name, i.e. that
<complexType name="anyThing"/> is allowed.
Three approaches to defining a type for length: one with
character data content constrained by reference to
a built-in datatype, and one attribute, the other two using two
elements. length3 is the abbreviated alternative to
length2: they correspond to identical type definition components.
A type definition for personal names, and a definition
A simplified type definition
A further illustration of the abbreviated form, with the
mixed attribute appearing on complexType itself.
A complex type definition that
To restrict away a local element declaration that
Without the specification of the notQName attribute,
the restriction might or might not be valid, depending on whether
the schema has a top-level declaration for
If the schema does have a top-level declaration, then the restriction is valid.
If there is no such top-level declaration, the restriction
is not valid, because the base type computer
maps quietComputer would
map them to a xs:anyType
In addition to the conditions imposed on If the If the The type definition a complex type
definition whose only if the
only if the
If The The corresponding complex type definition component
If
If
If the base base mixed mode 'none', then there
mixed
CTD is
E's
xs:anyType
The constraint
The reference to
Similarly: Let D be an E's let D be any one of those E E let D be that top-level If E matches some D has a the D has no the If E matches no T is E has no the The constraint It is a consequence of the definition of xs:anyType
For a given
CTD is
A's
the
the xs:anyType
For an element information item If the the the It is the the sequence of For each attribute information item in there is among the the attribute information
There The
attribute information item The
It is a member of the complex type's
Its
Its
Its
Its When an
For each element information item in
xsi:type, xsi:nil,
xsi:schemaLocation, or xsi:noNamespaceSchemaLocation
(see
For a sequence S (possibly empty) of element information items
to be locally
the
S is
the
S can be represented as two subsequences S1 and
S2 (either can be empty) such that
S = S1 + S2
S1 is
If S2 is not empty, let E be the first element
in S2, then S1 + E does
Every element in S2 is
(the
S is a member of S1 × S2
S1 is
For every element E in S2, let S3 be
Every element in S2 is
When the
When a sequence S of
S is a member of S1 × S2
S1 is a prefix of some element sequence that is
for every element E in S2, let S3 be
The above definition
Given an element information item E and a complex type T,
let B be the T T S S T T B is T has T has xs:anyType
This constraint has (by
It also ensures (by
For each
In addition, if necessary
The
The
If the
If
more than one
The
The element information item being assessed.
The
The
The
The nearest ancestor element information item with a
The added items
also
have
If the Otherwise, first select some prefix P which is not bound by
the Add an entry to the Add a namespace attribute to the Maintain the consistency of the information set by adjusting
the namespace bindings on the descendants of E. This may
be done in either of two ways: Add the binding of P to N to the Add to the The choice between the two methods of maintaining
consistency in the information set is
When a default value of type
To allow users of the
the attribute information item is
an
the attribute information item is
an
(the item is not
the item is
the item is
the item is
the item is
(the item is not
And each element information item in
its
the element information item is
an
the item is
an
(the item is not