Please refer to the errata for this document, which may include some normative corrections.
See also translations.
This document is also available in these non-normative formats: XML, XHTML with changes since version 1.0 marked, XHTML with changes since previous Working Draft marked, Independent copy of the schema for schema documents, Independent copy of the DTD for schema documents, Independent tabulation of components and microcomponents, and List of translations.
Copyright © 2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document specifies the XML Schema Definition Language, which offers facilities for describing the structure and constraining the contents of XML documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in an XML vocabulary and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML document type definitions (DTDs). This specification depends on XML Schema Definition Language 1.1 Part 2: Datatypes.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This W3C Recommendation specifies the W3C XML Schema Definition Language (XSD) 1.1. It is here made available for use by W3C members and the public. XSD 1.1 retains all the essential features of XSD 1.0 but adds several new features to support functionality requested by users, fixes many errors in XSD 1.0, and clarifies wording.
For those primarily interested in the changes since version 1.0, the appendix Changes since version 1.0 (non-normative) (§G) is the recommended starting point. It summarizes both changes made since XSD 1.0 and some changes which were expected (and predicted in earlier drafts of this specification) but have not been made after all. Accompanying versions of this document display in color all changes to normative text since version 1.0 and since the previous Working Draft.
Comments on this document should be made in W3C's public installation of Bugzilla, specifying "XML Schema" as the product. Instructions can be found at http://www.w3.org/XML/2006/01/public-bugzilla. If access to Bugzilla is not feasible, please send your comments to the W3C XML Schema comments mailing list, www-xml-schema-comments@w3.org (archive) and note explicitly that you have not made a Bugzilla entry for the comment. Each Bugzilla entry and email message should contain only one comment.
This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
An implementation report for XSD 1.1 was prepared and used in the Director's decision to publish the previous version of this specification as a Proposed Recommendation. The Director's decision to publish this document as a W3C Recommendation is based on consideration of reviews of the Proposed Recommendation by the public and by the members of the W3C Advisory committee.
The W3C XML Schema Working Group intends to process comments made about this recommendation, with any approved changes being handled as errata to be published separately.
This document has been produced by the W3C XML Schema Working Group as part of the W3C XML Activity. The goals of XSD 1.1 are discussed in the document Requirements for XML Schema 1.1. The authors of this document are the members of the XML Schema Working Group. Different parts of this specification have different editors.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
The English version of this specification is the only normative version. Information about translations of this document is available at http://www.w3.org/2003/03/Translations/byTechnology?technology=xmlschema.
The presentation of this document has been augmented to
identify changes from a previous version, controlled by dg-statusquo-color-201201.xml
. Three kinds of changes are highlighted:
↑new, added text↑,
↑changed text↓, and
↓deleted text↓.
This document sets out the structural part of the XML Schema Definition Language.
Chapter 2 presents a Conceptual Framework (§2) for XSD, including an introduction to the nature of XSD schemas and an introduction to the XSD abstract data model, along with other terminology used throughout this document.
Chapter 3, Schema Component Details (§3), specifies the precise semantics of each component of the abstract model, the representation of each component in XML, with reference to a DTD and an XSD schema for an XSD document type, along with a detailed mapping between the elements and attribute vocabulary of this representation and the components and properties of the abstract model.
Chapter 4 presents Schemas and Namespaces: Access and Composition (§4), including the connection between documents and schemas, the import, inclusion and redefinition of declarations and definitions and the foundations of schema-validity assessment.
Chapter 5 discusses Schemas and Schema-validity Assessment (§5), including the overall approach to schema-validity assessment of documents, and responsibilities of schema-aware processors.
The normative appendices include a Schema for Schema Documents (Structures) (normative) (§A) for the XML representation of schemas and Normative (§L.1).
The non-normative appendices include the DTD for Schemas (non-normative) (§I) and a Glossary (non-normative) (§H).
This document is primarily intended as a language definition reference. As such, although it contains a few examples, it is not primarily designed to serve as a motivating introduction to the design and its features, or as a tutorial for new users. Rather it presents a careful and fully explicit definition of that design, suitable for guiding implementations. For those in search of a step-by-step introduction to the design, the non-normative [XML Schema: Primer] is a much better starting point than this document.
The Working Group has three main goals for this version of W3C XML Schema:
These goals are in tension with one another. The Working Group's strategic guidelines for changes between versions 1.0 and 1.1 can be summarized as follows:
The aim with regard to compatibility is that
The purpose of XML Schema Definition Language: Structures is to define the nature of XSD schemas and their component parts, provide an inventory of XML markup constructs with which to represent schemas, and define the application of schemas to XML documents.
The purpose of an XSD schema is to define and describe a class of XML documents by using schema components to constrain and document the meaning, usage and relationships of their constituent parts: datatypes, elements and their content and attributes and their values. Schemas can also provide for the specification of additional document information, such as normalization and defaulting of attribute and element values. Schemas have facilities for self-documentation. Thus, XML Schema Definition Language: Structures can be used to define, describe and catalogue XML vocabularies for classes of XML documents.
Any application that consumes well-formed XML can use the formalism defined here to express syntactic, structural and value constraints applicable to its document instances. The XSD formalism allows a useful level of constraint checking to be described and implemented for a wide spectrum of XML applications. However, the language defined by this specification does not attempt to provide all the facilities that might be needed by applications. Some applications will require constraint capabilities not expressible in this language, and so will need to perform their own additional validations.
xs
)
The XML representation of schema components uses a vocabulary
identified by the namespace name http://www.w3.org/2001/XMLSchema
.
For brevity, the text and examples in this specification use
the prefix xs:
to stand for this
namespace; in practice, any prefix can be used.
untyped
,
untypedAtomic
) which are not defined in this
specification; see the [XDM]
specification for details of those types.
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.
xsi
)This specification defines
several attributes for direct use in any XML documents, as
described in Schema-Related Markup in Documents Being Validated (§2.7).
These attributes are in the namespace whose name is 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 in this namespace may be given definitions in future versions of this or other specifications.
vc
)
The pre-processing of schema documents described in
Conditional inclusion (§4.2.2) uses
attributes in the namespace
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.
http://www.w3.org/XML/1998/namespace
http://www.w3.org/2001/XMLSchema
http://www.w3.org/2001/XMLSchema-instance
http://www.w3.org/2007/XMLSchema-versioning
Components and source declarations must not specify
http://www.w3.org/2000/xmlns/
as their
target namespace. If they do, then the schema
and/or schema document is in ·error·.
html
bound to
http://www.w3.org/1999/xhtml
my
(in examples) bound to the target namespace
of the example schema documentrddl
bound to
http://www.rddl.org/
vc
bound to
http://www.w3.org/2007/XMLSchema-versioning
(defined
in this and related specifications)xhtml
bound to
http://www.w3.org/1999/xhtml
xlink
bound to
http://www.w3.org/1999/xlink
xs
bound to http://www.w3.org/2001/XMLSchema
(defined in this and related specifications)xsi
bound to
http://www.w3.org/2001/XMLSchema-instance
(defined in this and
related specifications)xsl
bound to
http://www.w3.org/1999/XSL/Transform
In practice, any prefix bound to the appropriate namespace
name may be used (unless otherwise specified by the definition
of the namespace in question, as for xml
and
xmlns
).
Sometimes other specifications or Application Programming Interfaces (APIs) need to refer to the XML Schema Definition Language in general, sometimes they need to refer to a specific version of the language↑, possibly even to a version defined in a superseded draft↑. To make such references easy and enable consistent identifiers to be used, we provide the following URIs to identify these concepts.
http://www.w3.org/XML/XMLSchema
http://www.w3.org/XML/XMLSchema/vX.Y
http://www.w3.org/XML/XMLSchema/v1.0
identifies
XSD version 1.0 and http://www.w3.org/XML/XMLSchema/v1.1
identifies
XSD version 1.1.
http://www.w3.org/XML/XMLSchema/vX.Y/Ne
X.Y
of
the XSD specification. For example, http://www.w3.org/XML/XMLSchema/v1.0/2e
identifies the second edition of XSD version 1.0.
http://www.w3.org/XML/XMLSchema/vX.Y/Ne/yyyymmdd
X.Y
of
the XSD specification published on the particular date
yyyy-mm-dd
. For example,
http://www.w3.org/XML/XMLSchema/v1.0/1e/20001024
identifies the language
defined in the XSD version 1.0 Candidate
Recommendation (CR) published on 24 October 2000, and
http://www.w3.org/XML/XMLSchema/v1.0/2e/20040318
identifies the language
defined in the XSD version 1.0 Second Edition Proposed
Edited Recommendation (PER)
published on 18 March 2004.
Please see XSD Language Identifiers (non-normative) (§K) for a complete list of XML Schema Definition Language identifiers which exist to date.
The definition of XML Schema Definition Language: Structures depends on the following specifications: [XML Infoset], [XML Namespaces 1.1], [XPath 2.0], and [XML Schema: Datatypes].
See Required Information Set Items and Properties (normative) (§D) for a tabulation of the information items and properties specified in [XML Infoset] which this specification requires as a precondition to schema-aware processing.
[XML Schema: Datatypes] defines some datatypes which depend on definitions in [XML 1.1] and [XML Namespaces 1.1]; those definitions, and therefore the datatypes based on them, vary between version 1.0 ([XML 1.0], [Namespaces in XML 1.0]) and version 1.1 ([XML 1.1], [XML Namespaces 1.1]) of those specifications. In any given schema-validity-·assessment· episode, the choice of the 1.0 or the 1.1 definition of those datatypes is ·implementation-defined·.
Conforming implementations of this specification may provide either the 1.1-based datatypes or the 1.0-based datatypes, or both. If both are supported, the choice of which datatypes to use in a particular assessment episode should be under user control.
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 [Definition:] a term is something used with a special meaning. The definition is labeled as such and the term it defines is displayed in boldface. The end of the definition is not specially marked in the displayed or printed text. Uses of defined terms are links to their definitions, set off with middle dots, for instance ·term·.
Non-normative examples are set off in boxes and accompanied by a brief explanation:
<schema targetNamespace="http://www.example.com/XMLSchema/1.0/mySchema">
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:
References to properties of schema components are links to the relevant definition as exemplified above, set off with curly braces, for instance {example property}.
For a given component C, an expression of the form "C.{example property}" denotes the (value of the) property {example property} for component C. The leading "C." (or more) is sometimes omitted, if the identity of the component and any other omitted properties is understood from the context. This "dot operator" is left-associative, so "C.{p1}.{p2}" means the same as "(C.{p1}) . {p2}" and denotes the value of property {p2} within the component or ·property record· which itself is the value of C's {p1} property. White space on either side of the dot operator has no significance and is used (rarely) solely for legibility.
For components C1 and C2, an expression of the form "C1 . {example property 1} = C2 . {example property 2}" means that C1 and C2 have the same value for the property (or properties) in question. Similarly, "C1 = C2" means that C1 and C2 are identical, and "C1.{example property} = C2" that C2 is the value of C1.{example property}.
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 determines which of several different components corresponds to the source declaration, several tabulations, one per context, are given. The property correspondences are normative, as are the illustrations of the XML representation element information items.
In the XML representation, bold-face attribute names (e.g.
count below) indicate a required attribute
information item, and the rest are optional. Where an attribute
information item has an enumerated type definition, the values
are shown separated by vertical bars, as for 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 [XML Schema: Datatypes], a hyperlink
to
its definition therein is given.
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.
example
Element Information ItemReferences to elements in the text are links to the relevant illustration as exemplified above, set off with angle brackets, for instance <example>.
Unless otherwise specified, references to attribute values
are references to the ·actual value· of the attribute information
item in question, not to its ·normalized value· or to other forms
or varieties of "value" associated with it.
For a given element information item E, expressions of the
form "E has att1
= V"
are short-hand for "there is an attribute information
item named att1
among the [attributes] of E and
its ·actual value·
is V."
If the identity of E is clear from context, expressions
of the form "att1
= V"
are sometimes used.
The form "att1
≠ V" is also used
to specify that the ·actual value· of att1
is
not V.
References to properties of information items as defined in [XML Infoset] are notated as links to the relevant section thereof, set off with square brackets, for example [children].
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 [new property].
The "dot operator" described above for components and their properties is also used for information items and their properties. For a given information item I, an expression of the form "I . [new property]" denotes the (value of the) property [new property] for item I.
Lists of normative constraints are typically introduced with phrase like "all of the following are true" (or "... apply"), "one of the following is true", "at least one of the following is true", "one or more of the following is true", "the appropriate case among the following is true", etc. The phrase "one of the following is true" is used in cases where the authors believe the items listed to be mutually exclusive (so that the distinction between "exactly one" and "one or more" does not arise). If the items in such a list are not in fact mutually exclusive, the phrase "one of the following" should be interpreted as meaning "one or more of the following". The phrase "the appropriate case among the following" is used only when the cases are thought by the authors to be mutually exclusive; if the cases in such a list are not in fact mutually exclusive, the first applicable case should be taken. Once a case has been encountered with a true condition, subsequent cases must not be tested.
The following highlighting is used for non-normative commentary in this document:
Within normative prose in this specification, the words may, should, must and must not are defined as follows:
These definitions describe in terms specific to this document the meanings assigned to these terms by [IETF RFC 2119]. The specific wording follows that of [XML 1.1].
Where these terms appear without special highlighting, they are used in their ordinary senses and do not express conformance requirements. Where these terms appear highlighted within non-normative material (e.g. notes), they are recapitulating rules normatively stated elsewhere.
This specification provides a further description of error and of conformant processors' responsibilities with respect to errors in Schemas and Schema-validity Assessment (§5).
This chapter gives an overview of XML Schema Definition Language: Structures at the level of its abstract data model. Schema Component Details (§3) provides details on this model, including a normative representation in XML for the components of the model. Readers interested primarily in learning to write schema documents will find it most useful first to read [XML Schema: Primer] for a tutorial introduction, and only then to consult the sub-sections of Schema Component Details (§3) named XML Representation of ... for the details.
An XSD schema is a set of components such as type definitions and element declarations. These can be used to assess the validity of well-formed element and attribute information items (as defined in [XML Infoset]), and furthermore to specify additional information about those items and their descendants. These augmentations to the information set make explicit information that was implicitly present in the original document (or in the original document and the governing schema, taken together), such as normalized and/or default values for attributes and elements and the types of element and attribute information items. The input information set is also augmented with information about the validity of the item, or about other properties described in this specification. [Definition:] We refer to the augmented infoset which results from conformant processing as defined in this specification as the post-schema-validation infoset, or PSVI. Conforming processors may provide access to some or all of the PSVI, as described in Subset of the Post-schema-validation Infoset (§C.1). The mechanisms by which processors provide such access to the PSVI are neither defined nor constrained by this specification.
Throughout this specification, [Definition:] the word assessment is used to refer to the overall process of local validation, recursive determination of validation outcome, and infoset augmentation, i.e. as a short form for "·schema-validity assessment·".
In general, a valid document is a document whose contents obey the constraints expressed in a particular schema. Since a document may be validated against many different schemas, it is often clearer to speak of a document being valid against a particular schema. When this specification is used, document validity can be defined operationally in terms of the ·post-schema-validation infoset· properties on the nodes of the document (in particular [validity]). Several similar but distinct kinds of validity are usefully distinguished, for which terms are defined below in Schema-validity and documents (§2.5).
This specification builds on [XML 1.1] and [XML Namespaces 1.1]. The concepts and definitions used herein regarding XML are framed at the abstract level of information items as defined in [XML Infoset]. By definition, this use of the infoset provides a priori guarantees of well-formedness (as defined in [XML 1.1]) and namespace conformance (as defined in [XML Namespaces 1.1]) for all candidates for ·assessment· and for all ·schema documents·.
Just as [XML 1.1] and [XML Namespaces 1.1] can be described in terms of information items, XSD schemas can be described in terms of an abstract data model. In defining schemas in terms of an abstract data model, this specification rigorously specifies the information which must be available to a conforming XSD processor. The abstract model for schemas is conceptual only, and does not mandate any particular implementation or representation of this information. To facilitate interoperation and sharing of schema information, a normative XML interchange format for schemas is provided.
[Definition:] Schema component is the generic term for the building blocks that make up the abstract data model of the schema. [Definition:] An XSD schema is a set of ·schema components·. There are several kinds of schema component, falling into three groups. The primary schema components, which may (type definitions) or must (element and attribute declarations) have names, are as follows:
The secondary schema components, are as follows:
Finally, the "helper" schema components provide small parts of other schema components; they are dependent on their context:
The name [Definition:] Component covers all the different kinds of schema component defined in this specification.
During ·validation·, [Definition:] declaration components are associated by (qualified) name to information items being ·validated·.
On the other hand, [Definition:] definition components define internal schema components that can be used in other schema components.
[Definition:] Declarations and definitions may and in some cases must have and be identified by names, which are NCNames as defined by [XML Namespaces 1.1].
[Definition:] Several kinds of component have a target namespace, which is either ·absent· or a namespace name, also as defined by [XML Namespaces 1.1]. The ·target namespace· serves to identify the namespace within which the association between the component and its name exists.
An expanded name, as defined in [XML Namespaces 1.1], is a pair consisting of a namespace name, which may be ·absent·, and a local name. The expanded name of any component with both a ·target namespace· property and a ·component name· property is the pair consisting of the values of those two properties. The expanded name of a declaration is used to help determine which information items will be ·governed· by the declaration.
·Validation·, defined in detail in Schema Component Details (§3), is a relation between information items and schema components. For example, an attribute information item is ·validated· with respect to an attribute declaration, a list of element information items with respect to a content model, and so on. The following sections briefly introduce the kinds of components in the schema abstract data model, other major features of the abstract model, and how they contribute to ·validation·.
The abstract model provides two kinds of type definition component: simple and complex.
[Definition:] This specification uses the phrase type definition in cases where no distinction need be made between simple and complex types.
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.
[Definition:] Except for ·xs:anyType
·, every ·type definition· is, by construction,
either a ·restriction· or an
·extension· of some
other type definition. The exception
·xs:anyType
· is a ·restriction· of itself.
With the exception of the loop on ·xs:anyType
·, the
graph of these relationships forms
a tree known as the Type Definition
Hierarchy with ·xs:anyType
· as its
root.
[Definition:] The type definition used as the basis
for an ·extension· or
·restriction· is
known as the base type definition of that
definition.
[Definition:]
If a type definition D can reach a type definition B by following
its base type definition chain, then D is said to be
derived from B.
In most cases, a type definition is
derived from other type definitions. The only exception is
·xs:anyType
·, which is derived from itself.
[Definition:] A type defined with the same constraints as its ·base type definition·, or with more, is said to be a restriction. The added constraints might include narrowed ranges or reduced alternatives. Given two types A and B, if the definition of A is a ·restriction· of the definition of B, then members of type A are always locally valid against type B as well.
[Definition:] A complex type definition which allows element or attribute content in addition to that allowed by another specified type definition is said to be an extension.
[Definition:] A special complex type definition, (referred to in earlier versions of this specification as 'the ur-type definition') whose name is anyType in the XSD namespace, is present in each ·XSD schema·. The definition of anyType serves as default type definition for element declarations whose XML representation does not specify one.
[Definition:] A special simple type
definition, whose name is error in the XSD
namespace, is also present in each ·XSD schema·. The
XSD error
type
has no valid instances. It can be used in any place where
other types are normally used; in particular, it can be used
in conditional type assignment to cause elements which satisfy
certain conditions to be invalid.
For brevity, the text and examples in this specification often
use the qualified names xs:anyType
and
xs:error
for these type definitions. (In
practice, any appropriately declared prefix can be used, as
described in Schema-Related Markup in Documents Being Validated (§2.7).)
A simple type definition is a set of constraints on strings and information about the values they encode, applicable to the ·normalized value· of an attribute information item or of an element information item with no element children. Informally, it applies to the values of attributes and the text-only content of elements.
Each simple type definition, whether built-in (that is,
defined in [XML Schema: Datatypes]) or user-defined, is a ·restriction· of its ·base type definition·.
[Definition:] A
special ·restriction· of
·xs:anyType
·, whose name is
anySimpleType in the
XSD namespace, is the root of the ·Type Definition Hierarchy· for all simple type
definitions. ·xs:anySimpleType
· has a lexical space containing
all sequences of characters in the Universal Character
Set (UCS) and a value space containing all
atomic values
and all finite-length lists of
atomic values.
As with ·xs:anyType
·, this
specification sometimes uses the qualified name
xs:anySimpleType
to designate this type
definition. The
built-in list datatypes all have ·xs:anySimpleType
· as their
·base type
definition·.
[Definition:] There is a further special datatype
called anyAtomicType, a
·restriction· of
·xs:anySimpleType
·, which is the ·base type definition·
of all the primitive
datatypes. This type definition is often referred
to simply as "xs:anyAtomicType
".
It too is
considered to have an unconstrained lexical space. Its value
space consists of the union of the value spaces of all the
primitive datatypes.
[Definition:] Datatypes can be constructed from other datatypes by restricting the value space or lexical space of a {base type definition} using zero or more Constraining Facets, by specifying the new datatype as a list of items of some {item type definition}, or by defining it as a union of some specified sequence of {member type definitions}.
The mapping from lexical space to value space is unspecified
for items whose type definition is ·xs:anySimpleType
· or ·xs:anyAtomicType
·. Accordingly
this specification does not constrain processors'
behavior in areas
where this mapping is implicated, for example checking such
items against enumerations, constructing default attributes or
elements whose declared type definition is ·xs:anySimpleType
·
or ·xs:anyAtomicType
·,
checking identity constraints involving such items.
[XML Schema: Datatypes]
provides mechanisms for defining new simple type definitions
by ·restricting·
some primitive
or ordinary datatype. It also
provides mechanisms for constructing new simple type
definitions whose members are lists of items
themselves constrained by some other simple type definition, or
whose membership is the union of the memberships of some other
simple type definitions. Such list and union simple type
definitions are also ·restrictions· of
·xs:anySimpleType
·.
For detailed information on simple type definitions, see Simple Type Definitions (§3.16) and [XML Schema: Datatypes]. The latter also defines an extensive inventory of pre-defined simple types.
A complex type definition is a set of attribute declarations and a content type, applicable to the [attributes] and [children] of an element information item respectively. The content type may require the [children] to contain neither element nor character information items (that is, to be empty), or to be a string which belongs to a particular simple type, or to contain a sequence of element information items which conforms to a particular model group, with or without character information items as well.
xs:anyType
· is
either
all
-groups in ways that do not
guarantee that the new material occurs only at the end of
the content. Another
special case is extension via Open Contents in interleave
mode. For detailed information on complex type definitions, see Complex Type Definitions (§3.4).
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 A . . .> <!ATTLIST A . . .>
Element declarations contribute to ·validation· as part of model group ·validation·, when their defaults and type components are checked against an element information item with a matching name and namespace, and by triggering identity-constraint definition ·validation·.
For detailed information on element declarations, see Element Declarations (§3.3). For an overview of identity constraints, see Identity-constraint Definition (§2.2.4.1).
[Definition:] Through the mechanism of element substitution groups, XSD provides a more powerful model than DTDs do supporting substitution of one named element for another. Any top-level element declaration can serve as the defining member, or head, for an element ·substitution group·. Other top-level element declarations, regardless of target namespace, can be designated as members of the ·substitution group· headed by this element. In a suitably enabled content model, a reference to the head ·validates· not just the head itself, but elements corresponding to any other member of the ·substitution group· as well.
All such members must have type definitions which are either the same as the head's type definition or derived from it. Therefore, although the names of elements can vary widely as new namespaces and members of the ·substitution group· are defined, the content of member elements is constrained by the type definition of the ·substitution group· head.
Note that element substitution groups are not represented as separate components. They are specified in the property values for element declarations (see Element Declarations (§3.3)).
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 ·validation· as part of complex type definition ·validation·, when their occurrence, defaults and type components are checked against an attribute information item with a matching name and namespace.
For detailed information on attribute declarations, see Attribute Declarations (§3.2).
A notation declaration is an association between a name and
an identifier for a notation. For an attribute or element information item to
be ·valid· with respect to a
NOTATION
simple type definition, its value must
have been declared with a notation declaration.
For detailed information on notation declarations, see Notation Declarations (§3.14).
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:
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). [Definition:] A model group G is said to accept or recognize the members of L(G).
For detailed information on model groups, see Model Groups (§3.8).
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 ·validation· as part of complex type definition ·validation·, when they allow anywhere from zero to many element information items or sequences thereof, depending on their contents and occurrence constraints.
The name [Definition:] Term is used to refer to any of the three kinds of components which can appear in particles. All ·Terms· are themselves ·Annotated Components·. [Definition:] A basic term is an Element Declaration or a Wildcard. [Definition:] A basic particle is a Particle whose {term} is a ·basic term·.
Each content model, indeed each particle and each term, 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). [Definition:] A particle P is said to accept or recognize the members of L(P). Similarly, a term T accepts or recognizes the members of L(T).
If a sequence S is a member of L(P), then it is necessarily possible to trace a path through the ·basic particles· within P, with each item within S corresponding to a matching particle within P. The sequence of particles within P corresponding to S is called the ·path· of S in P.
For detailed information on particles, see Particles (§3.9).
An attribute use plays a role similar to that of a particle, but for attribute declarations: an attribute declaration used by 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 names and optionally on their local names.
For detailed information on wildcards, see Wildcards (§3.10).
This section describes constructs which use [XPath 2.0] expressions to constrain the input document; using them, certain rules can be expressed conveniently which would be inconvenient or impossible to express otherwise. Identity-constraint definitions are associated with element declarations; assertions are associated with type definitions; conditional type assignment using type alternatives allows the type of an element instance to be chosen based on properties of the element instance (in particular, based on the values of its attributes).
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 [XPath 2.0] expressions to pick out sets of information items relative to particular target element information items which are unique, or a key, or a ·valid· reference, within a specified scope. An element information item is only ·valid· with respect to an element declaration with identity-constraint definitions if those definitions are all satisfied for all the descendants of that element information item which they pick out.
For detailed information on identity-constraint definitions, see Identity-constraint Definitions (§3.11).
A Type Alternative component (type alternative for short) associates a type definition with a predicate. Type alternatives are used in conditional type assignment, in which the choice of ·governing type definition· for elements governed by a particular element declaration depends on properties of the document instance. An element declaration may have a {type table} which contains a sequence of type alternatives; the predicates on the alternatives are tested, and when a predicate is satisfied, the type definition paired with it is chosen as the element instance's ·governing type definition·.
For detailed information on Type Alternatives, see Type Alternatives (§3.12).
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 ·valid· with respect to that type.
For detailed information on Assertions, see Assertions (§3.13).
Many rules that can be enforced by identity constraints and conditional type assignment can also be formulated in terms of assertions. That is, the various constructs have overlapping functionality. The three forms of constraint differ from each other in various ways which may affect the schema author's choice of formulation.
Most obviously, the ·post-schema-validation infoset· will differ somewhat, depending on which form of constraint is chosen.
Less obviously, identity constraints are associated with element declarations, while assertions are associated with type definitions. If it is desired to enforce a particular property of uniqueness or referential integrity associated with a particular element declaration E, of type T, the schema author may often choose either an identity constraint associated with E, or an assertion associated with T. One obvious difference is that elements substitutable for E are required to have types derived from T, but are not required to enforce the identity constraints (or the nillability) of E. If the constraint applicable to E should be enforced by elements substitutable for E, it is often most convenient to formulate the constraint as an assertion on T; conversely, if only some elements of type T are intended to be subject to the constraint, or if elements substitutable for E need not enforce the constraint, then it will be more convenient to formulate the rule as an identity constraint on E.
Similar considerations sometimes apply to the choice between assertions and conditional type assignment.
Because identity constraints and conditional type assignment are simpler and less variable than assertions, it may be easier for software to exploit or optimize them. Assertions have greater expressive power, which means they are often convenient. The "rule of least power" applies here; it is often preferable to use a less expressive notation in preference to a more expressive one, when either will suffice. See [Rule of Least Power].
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 Model Group Definitions (§3.7).
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 Attribute Group Definitions (§3.6).
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 Annotations (§3.15).
The [XML 1.1] specification describes two kinds of constraints on XML documents: well-formedness and validity constraints. Informally, the well-formedness constraints are those imposed by the definition of XML itself (such as the rules for the use of the < and > characters and the rules for proper nesting of elements), while validity constraints are the further constraints on document structure provided by a particular DTD.
The preceding section focused on ·validation·, that is the constraints on information items which schema components supply. In fact however this specification provides four different kinds of normative statements about schema components, their representations in XML and their contribution to the ·validation· of information items:
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 leaves implicit.
Within the context of this specification, conformance can be claimed for schema documents, for schemas, and for processors.
If the schema document is invalid only in consequence of invalid descendants of <annotation> elements, processors may treat the schema document as valid. It is ·implementation-defined· what effect, if any, invalid <annotation> elements have on the construction of schema components.
A schema conforms to this specification if and only if it consists of components which individually and collectively satisfy all the relevant constraints specified in this document, including but not limited to all the ·Schema Component Constraints·.
This specification distinguishes several classes of conforming processors, which are defined in terms of the following concepts.
[Definition:] A validator (or instance validator) is a processor which ·validates· an XML instance document against a conforming schema and distinguishes between valid documents and others, for one or more of the definitions of validity (·root-validity·, ·deep validity·, or ·uniform validity·) defined below in section Schema-validity and documents (§2.5). Conforming validators may additionally support other definitions of validity defined in terms of the ·post-schema-validation infoset·.
[Definition:] A schema-validity assessor (or just assessor) is a processor which performs full or partial ·schema-validity assessment· of an XML instance document, element information item, or attribute information item, with reference to a conforming schema, and provides access to the entirety of the resulting ·post-schema-validation infoset·. The means by which an ·assessor· provides access to the ·post-schema-validation infoset· is ·implementation-defined·.
[Definition:] A general-purpose processor is a ·validator· or ·assessor· which accepts schemas represented in the form of XML documents as described in Layer 2: Schema Documents, Namespaces and Composition (§4.2).
<include>
) (§4.2.3).
[Definition:] A schema processor which is not a ·general-purpose· processor is a special-purpose processor.
[Definition:] Web-aware processors are network-enabled processors which are not only ·general-purpose· but which additionally must be capable of accessing schema documents from the World Wide Web as described in Representation of Schemas on the World Wide Web (§2.8) and How schema definitions are located on the Web (§4.3.2). .
Several important classes of processor can be defined in terms of the concepts just given:
A claim that a processor conforms to this specification must specify to which processor classes defined here the processor belongs.
See Checklist of implementation-defined features (§E.1) and Terminology for implementation-defined features (normative) (§C) for terminology and concepts which may be helpful in defining the behavior of conforming processors and/or claiming conformance to this specification.
As noted above, in general a document is valid against a particular schema if it obeys the constraints imposed by that schema. Depending on the nature of the application and on the specific invariants to be enforced, different forms of validity may be appropriately required by an application, a specification, or other users of XSD. This section defines terminology for use in describing the requirements of applications or other technologies which use XSD schema to describe constraints on XML documents.
All the terms defined below require that the document's root element be ·assessed· using either ·element-driven validation· (when the intended root element of the schema is clearly specified ) or else ·strict wildcard validation· (if several different root elements are acceptable).
As discussed in XSD Abstract Data Model (§2.2), most schema components (may) have ·names·. If all such names were assigned from the same "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 ·target namespace·.
Therefore [Definition:] this specification introduces the term symbol
space to denote a collection of names, each of which is
unique with respect to the others.
Within a given schema there are distinct symbol spaces
for each kind of named definition and declaration component identified
in XSD Abstract Data Model (§2.2), except that
simple type definitions and complex type definitions share a
symbol space. Within a given symbol space, names
must be unique;
as a consequence, each expanded name within a given
symbol space uniquely identifies a single component.
The same expanded name may however appear in more than one symbol space without
conflict. For example, assuming that the namespace prefix
my
is bound to some particular namespace,
both a simple type definition and a top-level element declaration
can bear the name my:abc
without conflict or
necessary relation between the two. But it is not possible
for both a simple type definition and a complex type
definition, or two distinct top-level element declarations,
to share the name my:abc
.
Locally scoped attribute and element declarations are special with regard to symbol spaces. Their names are not included in the global symbol spaces for attribute and element names; each complex type definition defines its own attribute symbol space, and elements local to a complex type definition are constrained by Element Declarations Consistent (§3.8.6.3), but not by means of symbol spaces. Their names are not regarded as being in any particular symbol space. 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.
XML Schema Definition Language: Structures defines
several attributes for direct use in any XML documents. These
attributes are in the schema instance namespace
(http://www.w3.org/2001/XMLSchema-instance
) described in The Schema Instance Namespace (xsi
) (§1.3.1.2) above. All schema processors
must
have appropriate attribute declarations for these attributes
built in, see Attribute Declaration for the 'type' attribute (§3.2.7.1),
Attribute Declaration for the 'nil' attribute (§3.2.7.2), Attribute Declaration for the 'schemaLocation' attribute (§3.2.7.3) and
Attribute Declaration for the 'noNamespaceSchemaLocation' attribute (§3.2.7.4).
xsi:type
",
"xsi:nil
", etc. This is shorthand for
"an attribute information item whose [namespace
name] is
http://www.w3.org/2001/XMLSchema-instance
and whose [local
name] is type
" (or
nil
, etc.).
The Simple Type Definition (§2.2.1.2) or Complex Type Definition (§2.2.1.3) used in ·validation· of an element is usually
determined by reference to the appropriate schema components. An
element information item in an instance may, however,
explicitly assert its type using the attribute
xsi:type
. The value of this attribute is a ·QName·; see QName resolution (Instance) (§3.17.6.3) for the means by which the ·QName· is associated with a type
definition.
XML Schema Definition Language: Structures introduces a mechanism for signaling that an element
must be accepted as ·valid·
when it has no content despite a content type which does not
require or even necessarily allow empty content. An element
can be ·valid·
without content if it has the attribute xsi:nil
with the value true
. An element so labeled must
be empty, but can carry attributes if permitted by the
corresponding complex type.
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 can be used for ·assessment·. See How schema definitions are located on the Web (§4.3.2) for details on the use of these
attributes.
xsi:schemaLocation
attribute typically appears
in XML document instances being ·validated·; it is distinct from
the schemaLocation
attribute defined for some
elements in schema documents (which is not always a hint
but sometimes a firm directive).On the World Wide Web, schemas are conventionally represented
as XML documents (preferably of MIME type
application/xml
or text/xml
, but see
clause 1.1 of Inclusion Constraints and Semantics (§4.2.3)),
conforming to the specifications in Layer 2: Schema Documents, Namespaces and Composition (§4.2). For
more information on the representation and use of schema
documents on the World Wide Web
see Standards for representation of schemas and retrieval of schema documents on the Web (§4.3.1) and
How schema definitions are located on the Web (§4.3.2).
Components are defined in terms of their properties, and each property in turn is defined by giving its range, that is the values it may have. This can be understood as defining a schema as a labeled directed graph, where the root is a schema, every other vertex is a schema component or a literal (string, boolean, decimal) and every labeled edge is a property. The graph is not acyclic: multiple copies of components with the same name in the same ·symbol space· must not exist, so in some cases re-entrant chains of properties will exist.
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, [Definition:] a property value may itself be a collection of named values, which we call a property record.
[Definition:] Throughout this specification, the term absent is used as a distinguished property value denoting absence. Again this should not be interpreted as constraining implementations, as for instance between using a null value for such properties or not representing them at all. [Definition:] A property value which is not ·absent· is present.
Any property not defined as optional is always present; optional properties which are not present are taken to have ·absent· as their value. Any property identified as a having a set, subset or list value might have an empty value unless this is explicitly ruled out: this is not the same as ·absent·. Any property value identified as a superset or subset of some set might be equal to that set, unless a proper superset or subset is explicitly called for. By 'string' in Part 1 of this specification is meant a sequence of ISO 10646 characters identified as legal XML characters in [XML 1.1].
The principal purpose of XML Schema Definition Language: Structures is to define a set of schema
components that constrain the contents of instances and augment
the information sets thereof. Although no external
representation of schemas is required for this purpose, such
representations will obviously be widely used. To provide for
this in an appropriate and interoperable way, this specification
provides a normative XML representation for schemas which makes
provision for every kind of schema component. [Definition:] A document in this
form (i.e. a <schema> element information item)
is a schema document. For the schema
document as a whole, and its constituents, the sections below
define correspondences between element information items (with
declarations in
Schema for Schema Documents (Structures) (normative) (§A) and DTD for Schemas (non-normative) (§I)) and schema components. The key element information items in
the XML representation of a schema are in the XSD namespace, that
is their [namespace
name] is
http://www.w3.org/2001/XMLSchema
. Although a common way of creating
the XML Infosets which are or contain ·schema documents· will be
using an XML parser, this is not required: any mechanism which
constructs conformant infosets as defined in [XML Infoset] is a possible starting
point.
A recurrent pattern in the XML
representation of schemas may also be mentioned here. In many
cases, the same element name (e.g. element
or
attribute
or attributeGroup
), serves
both to define a particular schema component and to incorporate
it by reference. In the first case the name
attribute is required, in the second the ref
attribute is required. These
two usages are mutually exclusive, and sometimes also depend on
context.
The descriptions of the XML representation
of components, and the ·Schema Representation
Constraints·, apply to schema documents after,
not before, the
·conditional-inclusion pre-processing·
described in Conditional inclusion (§4.2.2) and the
·chameleon pre-processing·
described in Assembling a schema for a single target namespace from
multiple schema definition documents
(<include>
) (§4.2.3).
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 expressed in the Schema for Schema Documents (Structures) (normative) (§A). Neither the correspondences described nor the XML Representation Constraints apply to elements in the Schema namespace which occur as descendants of <appinfo> or <documentation>.
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 [attributes] of an element information item. Since schema documents are constrained by the Schema for Schema Documents (Structures) (normative) (§A), there is always a simple type definition associated with any such attribute information item. [Definition:] With reference to any string, interpreted as denoting an instance of a given datatype, the term actual value denotes the value to which the lexical mapping of that datatype maps the string. In the case of attributes in schema documents, the string used as the lexical representation is normally the ·normalized value· of the attribute. The associated datatype is, unless otherwise specified, the one identified in the declaration of the attribute, in the schema for schema documents; in some cases (e.g. the enumeration facet, or fixed and default values for elements and attributes) the associated datatype will be a more specific one, as specified in the appropriate XML mapping rules. The ·actual value· will often be a string, but can also be an integer, a boolean, a URI reference, etc. This term is also occasionally used with respect to element or attribute information items in a document being ·assessed·.
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 will in some cases be violated if one or more references cannot be ·resolved·. This specification addresses the matter of missing components in a uniform manner, described in Missing Sub-components (§5.3): no mention of handling missing components will be found in the individual component descriptions below.
Forward reference to named definitions and declarations is allowed, both within and between ·schema documents·. By the time the component corresponding to an XML representation which contains a forward reference is actually needed for ·validation·, it is possible that an appropriately-named component will have become available to discharge the reference: see Schemas and Namespaces: Access and Composition (§4) for details.
Throughout this specification, [Definition:] the initial value of some attribute information item is the value of the [normalized value] property of that item. Similarly, the initial value of an element information item is the string composed of, in order, the [character code] of each character information item in the [children] of that element information item.
The above definition means that comments and processing instructions, even in the midst of text, are ignored for most ·validation· purposes. For the exception to this rule, see the discussion of comments and processing instructions in Assertion Satisfied (§3.13.4.1).
#x9
(tab),
#xA
(line feed) and #xD
(carriage
return) are replaced with #x20
(space).#x20
s are collapsed to a single
#x20
, and initial and/or final
#x20
s are deleted.When more than one pre-lexical facet applies, the whiteSpace facet is applied first; the order in which ·implementation-defined· facets are applied is ·implementation-defined·.
If the simple type definition used in an item's
·validation· is ·xs:anySimpleType
·,
then the
·normalized value· must be determined
as in the preserve case above.
There are three alternative validation rules which help supply the necessary background for the above: Attribute Locally Valid (§3.2.4.1) (clause 3), Element Locally Valid (Type) (§3.3.4.4) (clause 3.1.3) or Element Locally Valid (Complex Type) (§3.4.4.2) (clause 1.2).
These three levels of normalization correspond to the processing mandated in XML for element content, CDATA attribute content and tokenized attributed content, respectively. See Attribute Value Normalization in [XML 1.1] for the precedent for replace and collapse for attributes. Extending this processing to element content is necessary to ensure consistent ·validation· semantics for simple types, regardless of whether they are applied to attributes or elements. Performing it twice in the case of attributes whose [normalized value] has already been subject to replacement or collapse on the basis of information in a DTD is necessary to ensure consistent treatment of attributes regardless of the extent to which DTD-based information has been made use of during infoset construction.
Attribute declarations provide for:
<xs:attribute name="age" type="xs:positiveInteger" use="required"/>
The attribute declaration schema component has the following properties:
The {name} property must match the local part of the names of attributes being ·validated·.
The value of each attribute validated must conform to the supplied {type definition}.
A ·non-absent· value of the {target namespace} property provides for ·validation· of namespace-qualified attribute information items (which must be explicitly prefixed in the character-level form of XML documents). ·Absent· values of {target namespace} ·validate· unqualified (unprefixed) items.
For an attribute declaration A, if A.{scope}.{variety} = global, then A is available for use throughout the schema. If A.{scope}.{variety} = local, then A is available for use only within (the Complex Type Definition or Attribute Group Definition) A.{scope}.{parent}.
The
{value constraint} property reproduces the functions of
XML default and
#FIXED
attribute values. A {variety} of
default specifies that the attribute is to
appear unconditionally in the ·post-schema-validation infoset·, with {value} and {lexical form} used whenever the attribute is not
actually present; fixed indicates that the attribute
value if present must be equal or identical
to {value}, and if absent receives {value} and {lexical form} as for default. Note that
it is values that are checked, not
strings,
and that the test is for either equality or identity.
See Annotations (§3.15) for information on the role of the {annotations} property.
[XML Infoset] distinguishes attributes with names such as xmlns
or xmlns:xsl
from
ordinary attributes, identifying them as [namespace attributes]. Accordingly, it is unnecessary and in fact not possible for
schemas to contain attribute declarations corresponding to such
namespace declarations, see xmlns
Not Allowed (§3.2.6.3). No means is provided in
this specification to supply a
default value for a namespace declaration.
The XML representation for an attribute declaration schema component is an <attribute> element information item. It specifies a simple type definition for an attribute either by reference or explicitly, and may provide default information. The correspondences between the properties of the information item after the appropriate ·pre-processing· and the properties of the component are given in this section.
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
<simpleType> is provided inline. When no simple type definition is
referenced or provided, the default is ·xs:anySimpleType
·, which
imposes no constraints at all.
attribute
Element Information ItemAn <attribute> element maps to an attribute declaration, and allows the type definition of that declaration to be specified either by reference or by explicit inclusion.
Top-level
<attribute> elements
(i.e. those which appear
within the schema document as
children of
<schema>
elements) produce
global attribute declarations;
<attribute>s
within
<attributeGroup> or <complexType> produce
either attribute uses which contain global attribute
declarations (if there's a 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 user-defined global type definition. Otherwise an anonymous
<simpleType> is provided inline.
<override>
) (§4.2.5) for details.
Attribute information items ·validated· by a top-level
declaration must be qualified with the
{target namespace} of that
declaration. If the
{target namespace} is ·absent·, the item must be
unqualified. Control over whether attribute
information items ·validated· by a local declaration must be
similarly qualified or not is provided by the form
[attribute], whose default is provided by the
attributeFormDefault
[attribute] on the enclosing
<schema>, via its determination of
{target namespace}.
The names for top-level attribute declarations are in their own ·symbol space·. The names of locally-scoped attribute declarations reside in symbol spaces local to the type definition which contains them.
ref
[attribute] is
absent, and the use
[attribute] is not
"prohibited"
, then it maps both to
an Attribute Declaration and to an Attribute Use
component, as described in
Mapping Rules for Local Attribute Declarations (§3.2.2.2).
ref
[attribute] is
·present·, and the use
[attribute] is not
"prohibited"
, then it maps to
an Attribute Use
component, as described in
Mapping Rules for References to Top-level Attribute Declarations (§3.2.2.3).
use='prohibited'
, then it does not map to,
or correspond to, any schema component at all.
use
attribute is not allowed on
top-level <attribute> elements, so
this can only happen with <attribute> elements
appearing within a <complexType>
or <attributeGroup> element.
If the <attribute> element information item has <schema> as its parent, the corresponding schema component is as follows:
targetNamespace
[attribute] of the parent
<schema> element information item, or ·absent· if there is none.type
[attribute], if present, otherwise
·xs:anySimpleType
·.default
or a fixed
[attribute],
then a Value Constraint as follows, otherwise ·absent·.
If
the <attribute> element information item has
<complexType> or <attributeGroup> as
an ancestor and the ref
[attribute] is absent,
it maps both to an attribute
declaration (see below) and
to an attribute use with properties as follows
(unless use='prohibited'
, in which case the item
corresponds to nothing at all):
default
or a fixed
[attribute],
then a Value Constraint
as follows, otherwise ·absent·.
The <attribute> element also maps to the {attribute declaration} of the attribute use, as follows:
targetNamespace
is present
, then
its ·actual value·.
targetNamespace
is not present and
one of the following is trueform
= qualified
form
is absent and the <schema> ancestor has
attributeFormDefault
=
qualified
targetNamespace
[attribute] of the ancestor <schema>
element information
item, or ·absent· if there
is none.
type
[attribute], if present, otherwise
·xs:anySimpleType
·.
If
the
<attribute> element information item has
<complexType> or <attributeGroup> as an
ancestor and the ref
[attribute] is
present, it
maps to an attribute use with properties as follows
(unless use='prohibited'
, in which case the item
corresponds to nothing at all):
use
=
required
, otherwise
false.default
or a fixed
[attribute],
then a Value Constraint
as follows, otherwise ·absent·.
inheritable
[attribute], if present, otherwise
{attribute declaration}.{inheritable}.default
and fixed
must not both be present.default
and use
are both present,
use
must have the ·actual value· optional
.ref
or name
is present, but not both.ref
is present, then all of <simpleType>,
form
and type
are absent.type
attribute and a
<simpleType> child element
must not both be present.fixed
and use
are both present,
use
must not have the ·actual value· prohibited
.
targetNamespace
attribute
is present then
all of the following must be true:name
attribute
is present.
form
attribute
is absent.
targetNamespace
[attribute] or its ·actual value·
is different from the ·actual value· of targetNamespace
of
<attribute>, then
all of the following are true:base
[attribute] of
<restriction> does not
·match· the
name of ·xs:anyType
·.
Informally, an attribute in an XML
instance is locally ·valid·
against an attribute declaration if and only if (a)
the name of the attribute matches
the name of the declaration, (b) after
whitespace normalization its ·normalized value· is locally valid
against the type declared for the attribute, and
(c) the
attribute obeys any relevant value constraint. Additionally,
for xsi:type
, it is required that the type named
by the attribute be present in the schema.
A logical prerequisite for checking the local validity of an
attribute against an attribute declaration is that the attribute
declaration itself and the type definition it identifies
both be present in the schema.
Local validity of attributes is tested as part of schema-validity ·assessment· of attributes (and of the elements on which they occur), and the result of the test is exposed in the [validity] property of the ·post-schema-validation infoset·.
A more formal statement is given in the following constraint.
xsi:type
(Attribute Declaration for the 'type' attribute (§3.2.7.1)), then A's ·actual value·
·resolves· to a type definition.
xsi:type
, xsi:nil
,
xsi:schemaLocation
, or
xsi:noNamespaceSchemaLocation
are always governed by
their corresponding built-in declarations (see
Built-in Attribute Declarations (§3.2.7)).
Schema-validity assessment of an attribute information item involves identifying its ·governing attribute declaration· and checking its local validity against the declaration. If the ·governing type definition· is not present in the schema, then assessment is necessarily incomplete.
[Definition:] For attribute information items, there is no difference between assessment and strict assessment, so the attribute information item has been strictly assessed if and only if its schema-validity has been assessed.
See also Attribute Default Value (§3.4.5.1), Match Information (§3.4.5.2) and Schema Information (§3.17.5.1), which describe other information set contributions related to attribute information items.
All attribute declarations (see Attribute Declarations (§3.2)) must satisfy the following constraints.
xsi:
Not Allowedxsi:
Not Allowedhttp://www.w3.org/2001/XMLSchema-instance
(unless it is one of the four built-in declarations given in the next section).xsi:
attributes to specify default or fixed value
constraints (e.g. in a component corresponding to a schema document construct
of the form <xs:attribute ref="xsi:type" default="xs:integer"/>
),
but the practice is not recommended; including such attribute uses will tend
to mislead readers of the schema document, because the attribute uses would
have no effect; see Element Locally Valid (Complex Type) (§3.4.4.2) and
Attribute Default Value (§3.4.5.1) for details.There are four attribute declarations present in every schema by definition:
xsi:type
The xsi:type
attribute
is used to signal use of a type other than the declared type of
an element. See xsi:type (§2.7.1).
xsi:nil
The xsi:nil
attribute
is used to signal that an element's content is "nil"
(or "null"). See xsi:nil (§2.7.2).
nil
http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation
The xsi:schemaLocation
attribute
is used to signal possible locations of relevant schema documents.
See xsi:schemaLocation, xsi:noNamespaceSchemaLocation (§2.7.3).
schemaLocation
http://www.w3.org/2001/XMLSchema-instance
http://www.w3.org/2001/XMLSchema-instance
xs:anySimpleType
·xsi:noNamespaceSchemaLocation
The xsi:noNamespaceSchemaLocation
attribute
is used to signal possible locations of relevant schema documents.
See xsi:schemaLocation, xsi:noNamespaceSchemaLocation (§2.7.3).
noNamespaceSchemaLocation
http://www.w3.org/2001/XMLSchema-instance
Element declarations provide for:
<xs:element name="PurchaseOrder" type="PurchaseOrderType"/> <xs:element name="gift"> <xs:complexType> <xs:sequence> <xs:element name="birthday" type="xs:date"/> <xs:element ref="PurchaseOrder"/> </xs:sequence> </xs:complexType> </xs:element>
The element declaration schema component has the following properties:
The {name} property must match the local part of the names of element information items being ·validated·.
For an element declaration E, if E.{scope}.{variety} = global, then E is available for use throughout the schema. If E.{scope}.{variety} = local, then E is available for use only within (the Complex Type Definition or Model Group Definition) E.{scope}.{parent}.
A ·non-absent· value of the {target namespace} property provides for ·validation· of namespace-qualified element information items. ·Absent· values of {target namespace} ·validate· unqualified items.
An element information item is normally
required to satisfy the {type definition}. For such an
item, schema information set
contributions appropriate to the {type definition} are added to the
corresponding element information
item in the ·post-schema-validation infoset·. The type
definition against which an element information item is
validated (its
·governing type definition·) can be different from the
declared {type definition}. The {type table} property of an Element Declaration, which governs conditional type assignment, and
the xsi:type
attribute of an element information item
(see xsi:type (§2.7.1)) can cause the ·governing type definition· and the
declared {type definition} to be different.
If {nillable} is true, then
an element with no text or element
content can be ·valid·
despite a
{type definition}
which would otherwise require
content, if it carries the
attribute xsi:nil
with the value
true
(see xsi:nil (§2.7.2)).
Formal details of element ·validation· are described in
Element Locally Valid (Element) (§3.3.4.3).
xsi:nil
= true. {value constraint} establishes a default or fixed value for an element. If a {value constraint} with {variety} = default is present, and if the element being ·validated· is empty, then for purposes of calculating the [schema normalized value] and other contributions to the ·post-schema-validation infoset· the element is treated as if {value constraint}.{lexical form} was used as the content of the element. If fixed is specified, then the element's content must either be empty, in which case fixed behaves as default, or its value must be equal or identical to {value constraint}.{value}.
{identity-constraint definitions} express constraints establishing uniquenesses and reference relationships among the values of related elements and attributes. See Identity-constraint Definitions (§3.11).
The {substitution group affiliations} property of an element declaration indicates which ·substitution groups·, if any, it can potentially be a member of. Potential membership is transitive but not symmetric; an element declaration is a potential member of any group named in its {substitution group affiliations}, and also of any group of which any entry in its {substitution group affiliations} is a potential member. Actual membership may be blocked by the effects of {substitution group exclusions} or {disallowed substitutions}, see below.
An empty {substitution group exclusions} allows a declaration to be named in the {substitution group affiliations} of other element declarations having the same declared {type definition} or some type ·derived· therefrom. The explicit values of {substitution group exclusions}, extension or restriction, rule out element declarations having types whose derivation from {type definition} involves any extension steps, or restriction steps, respectively.
The supplied values for {disallowed substitutions} determine whether an element declaration appearing in a ·content model· will be prevented from additionally ·validating· elements (a) with an xsi:type (§2.7.1) that identifies an extension or restriction of the type of the declared element, and/or (b) from ·validating· elements which are in the ·substitution group· headed by the declared element. If {disallowed substitutions} is empty, then all ·derived· types and ·substitution group· members are allowed.
Element declarations for which {abstract} is true can appear in content models only when substitution is allowed; such declarations must not themselves ever be used to ·validate· element content.
See Annotations (§3.15) for information on the role of the {annotations} property.
The XML representation for an element declaration schema component is an <element> element information item. It specifies a type definition for an element either by reference or explicitly, and may provide occurrence and default information. The correspondences between the properties of the information item after the appropriate ·pre-processing· and the properties of the component(s) it corresponds to are given in this section.
element
Element Information ItemAn <element> element information item in a schema document maps to an element declaration and allows the type definition of that declaration to be specified either by reference or by explicit inclusion.
Top-level <element>
elements
(i.e. those which appear within
the schema document as children of
<schema>
elements)
produce
global element declarations; <element>s within <group> or <complexType> produce either particles which contain global element declarations (if there's a 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
user-defined global type definition. Otherwise an
anonymous <simpleType> or <complexType> is provided inline.
<override>
) (§4.2.5) for details.
Element information items ·validated· by a top-level
declaration must be qualified with the
{target namespace} of that
declaration.
If the
{target namespace} is ·absent·,
the item must be unqualified.
Control over whether element information items ·validated· by a local declaration must be similarly qualified or not
is provided by the form
[attribute], whose default is provided
by the elementFormDefault
[attribute] on the enclosing <schema>, via its determination of {target namespace}.
The names for top-level element declarations are in a separate ·symbol space· from the symbol spaces for the names of type definitions, so there can (but need not be) a simple or complex type definition with the same name as a top-level element. The names of locally-scoped element declarations need not be unique and thus reside in no symbol space at all (but the element declarations are constrained by Element Declarations Consistent (§3.8.6.3)).
Note that the above allows for two levels of defaulting for unspecified
type definitions. An <element> with no referenced or included type definition will
correspond to an element declaration which has
the
same type definition as the first
substitution-group head named in the
substitutionGroup
[attribute], if present,
otherwise ·xs:anyType
·.
This has the important consequence that the minimum valid element declaration,
that is, one with only a 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 XML Representation of Identity-constraint Definition Schema Components (§3.11.2) for <key>, <unique> and <keyref>.
ref
[attribute] is absent,
and it does not have minOccurs=maxOccurs=0
,
then it maps both to a Particle, as described
in Mapping Rules for Local Element Declarations (§3.3.2.3), and also to an
Element Declaration, using the mappings described in
Common Mapping Rules for Element Declarations (§3.3.2.1) and
Mapping Rules for Local Element Declarations (§3.3.2.3).
ref
[attribute] is present,
and it does not have minOccurs=maxOccurs=0
,
then it maps to a Particle
as described in References to Top-Level Element Declarations (§3.3.2.4).minOccurs=maxOccurs=0
,
then it maps to no component at all.minOccurs
and maxOccurs
attributes are not allowed on top-level
<element> elements, so in valid schema
documents this will happen only when the <element> element information item has
<complexType> or <group> as an
ancestor.
The following mapping rules apply in all cases where an <element> element maps to an Element Declaration component.
type
[attribute], if it is present.
substitutionGroup
[attribute], if present.
xs:anyType
·.
test
[attribute].
test
[attribute], the final <alternative> maps to
the {default type definition};
if it does have a test
attribute, it is covered by
the rule for {alternatives} and
the {default type definition}
is taken from the declared type of the Element Declaration.
So the value of the {default type definition}
is given by
the appropriate case among the following:test
[attribute], then a Type Alternative corresponding to the <alternative>.test
) a Type Alternative with the following properties: default
or a fixed
[attribute],
then a Value Constraint as follows, otherwise ·absent·. [Definition:] Use the name effective simple type
definition for the declared {type definition}, if it is a
simple type definition,
or, if {type definition}.{content type}.{variety} = simple,
for {type definition}.{content type}.{simple type definition},
or else for the built-in
string simple
type definition).
substitutionGroup
[attribute], if present,
otherwise the empty set.block
[attribute], if present, otherwise on the ·actual value· of the
blockDefault
[attribute] of the ancestor
<schema> element information item, if present,
otherwise on the empty string. Call this the
EBV (for effective block value). Then the
value of this property is
the appropriate case among the following:#all
, then {
extension,
restriction,
substitution}
;blockDefault
[attribute] of
<schema> may include values other than
extension, restriction or
substitution, those values are ignored in the
determination of {disallowed substitutions} for element
declarations (they are used elsewhere).final
and finalDefault
[attributes] in place of the block
and
blockDefault
[attributes] and with the relevant
set being {
extension,
restriction}
.ref
[attribute], as defined in XML Representation of Annotation Schema Components (§3.15.2).
If the <element> element information item has <schema> as its parent, it maps to a global Element Declaration, using the mapping given in Common Mapping Rules for Element Declarations (§3.3.2.1), supplemented by the following.
targetNamespace
[attribute] of the parent
<schema> element information item, or ·absent· if there is none.
If
the <element> element information
item has
<complexType> or <group> as
an ancestor,
and the ref
[attribute] is absent,
and it does not have
minOccurs=maxOccurs=0
,
then it maps both to a
Particle and to a local
Element Declaration which is the {term}
of that Particle. The Particle
is as follows:
maxOccurs
[attribute] equals
unbounded, otherwise the ·actual value· of the
maxOccurs
[attribute], if present, otherwise
1
.The <element> element also maps to an element declaration using the mapping rules given in Common Mapping Rules for Element Declarations (§3.3.2.1), supplemented by those below:
targetNamespace
is present
, then
its ·actual value·.
targetNamespace
is not present and
one of the following is trueform
= qualified
form
is absent and the <schema>
ancestor
has elementFormDefault
=
qualified
targetNamespace
[attribute]
of the ancestor <schema> element
information item,
or ·absent· if there is
none.
If the
<element> element information
item has
<complexType> or <group> as an
ancestor,
and the ref
[attribute] is
present,
and it does not have
minOccurs=maxOccurs=0
,
then it maps to
a Particle as follows.
maxOccurs
[attribute] equals
unbounded, otherwise the ·actual value· of the
maxOccurs
[attribute], if present, otherwise
1
.<xs:element name="unconstrained"/> <xs:element name="emptyElt"> <xs:complexType> <xs:attribute ...>. . .</xs:attribute> </xs:complexType> </xs:element> <xs:element name="contextOne"> <xs:complexType> <xs:sequence> <xs:element name="myLocalElement" type="myFirstType"/> <xs:element ref="globalElement"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="contextTwo"> <xs:complexType> <xs:sequence> <xs:element name="myLocalElement" type="mySecondType"/> <xs:element ref="globalElement"/> </xs:sequence> </xs:complexType> </xs:element>
xs:anyType
·.
The second uses an embedded anonymous complex
type definition.myLocalElement
within
contextOne
will be constrained by myFirstType
,
while those within contextTwo
will be constrained by
mySecondType
. <xs:complexType name="facet"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="value" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="facet" type="xs:facet" abstract="true"/> <xs:element name="encoding" substitutionGroup="xs:facet"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:facet"> <xs:sequence> <xs:element ref="annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="value" type="xs:encodings"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="period" substitutionGroup="xs:facet"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:facet"> <xs:sequence> <xs:element ref="annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="value" type="xs:duration"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <xs:complexType name="datatype"> <xs:sequence> <xs:element ref="facet" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="optional"/> . . . </xs:complexType>
facet
type is defined
and the facet
element is declared to use it. The facet
element is abstract -- it's
only defined to stand as the head for a ·substitution group·. Two further
elements are declared, each a member of the facet
·substitution group·. Finally a type is defined which refers to facet
, thereby
allowing either period
or encoding
(or
any other member of the group).message
element will be
assigned either to type messageType
or to a more
specific type derived from it.
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.<xs:complexType name="messageType" mixed="true"> <xs:sequence> <xs:any processContents="skip" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="kind"> <xs:simpleType> <xs:union> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="string"/> <xs:enumeration value="base64"/> <xs:enumeration value="binary"/> <xs:enumeration value="xml"/> <xs:enumeration value="XML"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:union> </xs:simpleType> </xs:attribute> <xs:anyAttribute processContents="skip"/> </xs:complexType>
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"
.
<xs:complexType name="messageTypeString"> <xs:simpleContent> <xs:restriction base="messageType"> <xs:simpleType> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name="messageTypeBase64"> <xs:simpleContent> <xs:restriction base="messageType"> <xs:simpleType> <xs:restriction base="xs:base64Binary"/> </xs:simpleType> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name="messageTypeXML"> <xs:complexContent> <xs:restriction base="messageType"> <xs:sequence> <xs:any processContents="strict"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType>
message
element itself uses
messageType
both as its declared type and
as its default type, and uses test
attributes on its
<alternative> [children] to assign the appropriate
specialized message type to messages with the well known
values for the kind
attribute.
Because the declared type and the default type are the same, the last
<alternative> (without the test
attribute)
can be omitted.<xs:element name="message" type="messageType"> <xs:alternative test="@kind='string'" type="messageTypeString"/> <xs:alternative test="@kind='base64'" type="messageTypeBase64"/> <xs:alternative test="@kind='binary'" type="messageTypeBase64"/> <xs:alternative test="@kind='xml'" type="messageTypeXML"/> <xs:alternative test="@kind='XML'" type="messageTypeXML"/> <xs:alternative type="messageType"/> </xs:element>
default
and fixed
are not
both present.ref
or name
is present, but not both.ref
is present, then
no unqualified attributes are
present other than minOccurs
, maxOccurs
,
and id
,
and no children in the Schema namespace (xs
) other than
<annotation>.type
attribute.targetNamespace
is present then
all of the following are true:name
is present.
form
is not present.
targetNamespace
[attribute] or its ·actual value·
is different from the ·actual value· of targetNamespace
of
<element>, then
all of the following are true:base
[attribute] of
<restriction> does not
·match· the
name of ·xs:anyType
·.
test
[attribute]; the last
<alternative> element may have such an [attribute].When an element is ·assessed·, it is first checked against its ·governing element declaration·, if any; this in turn entails checking it against its ·governing type definition·. The second step is recursive: the element's [attributes] and [children] are ·assessed· in turn with respect to the declarations assigned to them by their parent's ·governing type definition·.
The ·governing type definition· of an element is normally the declared {type definition} associated with the ·governing element declaration·, but this may be ·overridden· using conditional type assignment in the Element Declaration or using an ·instance-specified type definition·, or both. When the element is declared with conditional type assignment, the ·selected type definition· is used as the ·governing type definition· unless ·overridden· by an ·instance-specified type definition·.
xs:error
·.[Definition:] If the set of keywords controlling whether a type S is ·validly substitutable· for another type T is the empty set, then S is said to be validly substitutable for T without limitation or absolutely. The phrase validly substitutable, without mention of any set of blocking keywords, means "validly substitutable without limitation".
Sometimes one type S is ·validly substitutable· for another type T only if S is derived from T by a chain of restrictions, or if T is a union type and S a member type of the union. The concept of ·valid substitutability· is appealed to often enough in such contexts that it is convenient to define a term to cover this specific case. [Definition:] A type definition S is validly substitutable as a restriction for another type T if and only if S is ·validly substitutable· for T, subject to the blocking keywords {extension, list, union}.
The concept of local validity of an element information item against an element declaration is an important part of the schema-validity ·assessment· of elements. (The other important part is the recursive ·assessment· of attributes and descendant elements.) Local validity partially determines the element information item's [validity] property, and fully determines the [local element validity] property, in the ·post-schema-validation infoset·.
xsi:nil
attribute on the element obeys the
rules. The element is allowed to have an xsi:nil
attribute only if the element is declared nillable, and
xsi:nil = 'true'
is allowed only if the element
itself is empty. If the element declaration specifies a
fixed value for the element, xsi:nil='true'
will make the element invalid.
xsi:type
attribute present names a
type which is ·validly substitutable· for the element's
declared {type definition}.The following validation rule gives the normative formal definition of local validity of an element against an element declaration.
xsi:nil
attribute.xsi:nil
attribute information item.xsi:nil
= false
.xsi:nil
= true
(that is, E is ·nilled·), and
all of the following are true:xsi:type
attribute, the
type definition indicated by that attribute normally takes
precedence over the ·selected type definition· which would otherwise
govern the element.
If an xsi:type
attribute is present
and ·resolves·
to a known type definition, but
fails to ·override· the
·selected type definition·, then E is not
locally valid against D,
since E has failed to satisfy
clause 4.
In this case
(or if xsi:type
fails to
·resolve·), the ·governing type definition· of the
element is the ·selected type definition· of its
·governing element declaration·, and the element is
validated against that type as described in
clause 5.
The local validity of the element
with respect to the ·governing type definition· is recorded in the
[local type validity]
property.
The use of the ·selected type definition· when the
·instance-specified type definition· cannot be used
allows useful validation to proceed in some cases (not all) even
when the schema is incomplete. It also
helps ensure consistent typing for sub-elements
with the same name.
The following validation rule specifies
formally what it means for an element to be locally valid
against a type definition. This concept is appealed to in the
course of checking an element's local validity against its
·governing type definition·. It
is also part of schema-validity
·assessment· of an element when the element is
·laxly assessed·, by checking its local validity
against xs:anyType
.
Informally, local validity against a type requires first
that the type definition be present in the schema and not declared abstract.
For a simple type definition, the element must lack attributes
(except for namespace declarations and the special attributes
in the xsi
namespace) and child elements, and must
be type-valid against that simple type definition.
For a complex type definition, the element must
be locally valid against that complex type definition.
xsi:type
,
xsi:nil
,
xsi:schemaLocation
, or
xsi:noNamespaceSchemaLocation
.The following validation rule specifies document-level ID/IDREF constraints checked on the ·validation root· if it is an element; this rule is not checked on other elements. Informally, the requirement is that each ID identifies a single element within the ·validation root·, and that each IDREF value matches one ID.
xs:ID
provides
a unique identifier for the element's parent element, it is not useful
to have an element governed by xs:ID
when the element
has no parent element or when the parent element lies outside the
scope of validation.DOC
and Y
are governed by type ·xs:anyType
·,
the element X
and the attribute xml:id
are
governed by xs:ID
, and the element
Z
is governed by a complex type with simple content
derived from xs:ID
.<DOC><X>abcd</X></DOC>
,
the ID value 'abcd
' will normally be bound to
the DOC
element. But if the X
element is the validation root, then 'abcd
'
will have no element binding, because DOC
is outside the scope of the validation episode.
So the first clause is violated and the document is invalid.<DOC><Y xml:id="abcd"/></DOC>
will, in contrast, be valid whether the DOC
element
or the Y
element is the validation root. The
ID/IDREF table will have one entry in either case, binding
'abcd
' to the Y
element.
<DOC><Z
xml:id="abcd">abcd</Z></DOC>
,
if Z
is the validation root, then the ID/IDREF table for the document
will have a single entry for 'abcd
'
and will be valid. The single binding comes from the
xml:id
attribute; the content of
Z
produces no binding, just as the content of
X
above produces no binding.DOC
is the
validation root, then the ID/IDREF table for the document will
have two entries for 'abcd
' (one, from the
xml:id
attribute, binding 'abcd
' to
the Z
element, one from the content of Z
binding 'abcd
' to the DOC
element) and
will be invalid.
ID/IDREF
functionality is imperfect in that if
the ·validation root· is not the document element of an XML
document, the results will not necessarily be the same as
those a validating parser would give were the document to have
a DTD with equivalent declarations.xsi:type
attribute), otherwise the element
will be ·laxly assessed·.
xs:anyType
·.
xs:anyType
· as defined in
Element Locally Valid (Type) (§3.3.4.4), and the schema-validity of
E's [attributes] and [children]
is assessed as described in clause 2 and clause 3
of Schema-Validity Assessment (Element) (§3.3.4.6).xsi:type
attribute which fails to ·resolve· to
a type definition that ·overrides· the
declared {type definition}
xsi:type
attribute which fails to ·resolve· to a type
definition that ·overrides· the ·selected type definition·
xs:anyType
·
xs:anyType
·.See also Match Information (§3.4.5.2), Identity-constraint Table (§3.11.5), Validated with Notation (§3.14.5), and Schema Information (§3.17.5.1), which describe other information set contributions related to element information items.
All element declarations (see Element Declarations (§3.3)) must satisfy the following constraint.
xs:error
·.This and the following sections define relations appealed to elsewhere in this specification.
[Definition:] One element declaration is substitutable for another if together they satisfy constraint Substitution Group OK (Transitive) (§3.3.6.3).
[Definition:] Every element declaration (call this HEAD) in the {element declarations} of a schema defines a substitution group, a subset of those {element declarations}. An element declaration is in the substitution group of HEAD if and only if it is ·substitutable· for HEAD.
Complex Type Definitions provide for:
<xs:complexType name="PurchaseOrderType"> <xs:sequence> <xs:element name="shipTo" type="USAddress"/> <xs:element name="billTo" type="USAddress"/> <xs:element ref="comment" minOccurs="0"/> <xs:element name="items" type="Items"/> </xs:sequence> <xs:attribute name="orderDate" type="xs:date"/> </xs:complexType>
A complex type definition schema component has the following properties:
Either an Element Declaration or a Complex Type Definition.
Complex type definitions are identified by their {name} and {target namespace}. Except
for anonymous complex type definitions (those with no {name}), since
type definitions (i.e. both simple and complex type definitions taken together) must be uniquely identified within an ·XSD schema·, no complex type definition can have the same name as another
simple or complex type definition. Complex type {name}s and {target namespace}s
are provided for reference from
instances (see xsi:type (§2.7.1)), and for use in the XML
representation of schema components
(specifically in <element>). See References to schema components across namespaces (<import>
) (§4.2.6) for the use of component
identifiers when importing one schema into another.
As described in Type Definition Hierarchy (§2.2.1.1), each complex type is ·derived· from a {base type definition} which is itself either a Simple Type Definition (§2.2.1.2) or a Complex Type Definition (§2.2.1.3). {derivation method} specifies the means of ·derivation· as either extension or restriction (see Type Definition Hierarchy (§2.2.1.1)).
A complex type with an empty specification for {final} can be used as a
{base type definition} for other types ·derived· by either of
extension or restriction; the explicit values extension, and restriction prevent further
·derivations· by extension and restriction respectively. If all values are specified, then [Definition:] the complex type is said to be
final, because no
further ·derivations· are possible. Finality is not
inherited, that is, a type definition ·derived· by restriction from a type
definition which is final for extension is not itself, in the absence of any
explicit final
attribute of its own, final for anything.
The {context} property is only relevant for anonymous type definitions, for which its value is the component in which this type definition appears as the value of a property, e.g. {type definition}.
Complex types for which {abstract} is true have no valid instances and thus cannot be used in the normal way as the {type definition} for the ·validation· of element information items (if for some reason an abstract type is identified as the ·governing type definition· of an element information item, the item will invariably be invalid). It follows that such abstract types must not be referenced from an xsi:type (§2.7.1) attribute in an instance document. Abstract complex types can be used as {base type definition}s, or even as the declared {type definition}s of element declarations, provided in every case a concrete ·derived· type definition is used for ·validation·, either via xsi:type (§2.7.1) or the operation of a ·substitution group·.
{attribute uses} are a set of attribute uses. See Element Locally Valid (Complex Type) (§3.4.4.2) and Attribute Locally Valid (§3.2.4.1) for details of attribute ·validation·.
{attribute wildcard}s provide a more flexible specification for ·validation· of attributes not explicitly included in {attribute uses}. See Element Locally Valid (Complex Type) (§3.4.4.2), The Wildcard Schema Component (§3.10.1) and Wildcard allows Expanded Name (§3.10.4.2) for formal details of attribute wildcard ·validation·.
xsi:type
attribute;
see xsi:type (§2.7.1);
{assertions} constrain elements and attributes to exist, not to exist, or to have specified values. Though specified as a sequence, the order among the assertions is not significant during assessment. See Assertions (§3.13).
See Annotations (§3.15) for information on the role of the {annotations} property.
The XML representation for a complex type definition schema component is a <complexType> element information item.
The XML representation for complex type definitions with a {content type} with {variety} simple is significantly different from that of those with other {content type}s, and this is reflected in the presentation below, which describes the mappings for the two cases in separate subsections. Common mapping rules are factored out and given in separate sections. As always, the mapping rules given here apply after, not before, the appropriate ·pre-processing·.
complexType
Element Information Item<complexType name="anyThing"/>
is allowed.
Where convenient, the mapping rules are described exclusively in terms of the schema document's information set. The mappings, however, depend not only upon the source declaration but also upon the schema context. Some mappings, that is, depend on the properties of other components in the schema. In particular, several of the mapping rules given in the following sections depend upon the {base type definition} having been identified before they apply.
Whichever alternative for the content of <complexType> is chosen, the following property mappings apply. Except where otherwise specified, attributes and child elements are to be sought among the [attributes] and [children] of the <complexType> element.
targetNamespace
[attribute] of the <schema> ancestor element information item if present,
otherwise ·absent·.block
[attribute], if present, otherwise to the ·actual value· of the
blockDefault
[attribute] of the ancestor
<schema> element information item, if present,
otherwise on the empty string. Call this the
EBV (for effective block value). Then the
value of this property is
the appropriate case among the following:#all
, then {
extension,
restriction}
;blockDefault
[attribute] of
<schema> may include values other than
restriction or extension, those values
are ignored in the determination of {prohibited substitutions} for complex type
definitions (they are used elsewhere).final
and finalDefault
[attributes] in place of the block
and
blockDefault
[attributes].name
[attribute] is present, then ·absent·, otherwise (among the ancestor element information
items there will be a nearest <element>),
the Element Declaration
corresponding to
the nearest <element>
information item among the
the ancestor element information items.
When the <complexType> source declaration has a <simpleContent> child, the following elements are relevant (as are <attribute>, <attributeGroup>, and <anyAttribute>), and the property mappings are as below, supplemented by the mappings in Common Mapping Rules for Complex Type Definitions (§3.4.2.1), Mapping Rule for Attribute Uses Property (§3.4.2.4), and Mapping Rule for Attribute Wildcard Property (§3.4.2.5). Note that either <restriction> or <extension> must appear in the content of <simpleContent>.
simpleContent
Element Information Item et al.When the <complexType> element has a <simpleContent> child, then the <complexType> element maps to a complex type with simple content, as follows.
base
[attribute]
on the
<restriction> or
<extension> element appearing as a child of
<simpleContent>
targetNamespace
[attribute] of the ancestor
<schema> element information item if present,
otherwise ·absent·xs:anySimpleType
·) a simple type definition which
restricts SB with a set of facet
components corresponding to the appropriate element
information items among the <restriction>'s [children] (i.e. those
which specify facets, if any), as defined in Simple Type Restriction (Facets) (§3.16.6.4);
xs:anySimpleType
·), the result will be a simple type definition component
which fails to obey the constraints on simple type definitions, including
for example clause 1.1 of
Derivation Valid (Restriction, Simple) (§3.16.6.2).
xs:anySimpleType
·.When the <complexType> element does not have a <simpleContent> child element, then it maps to a complex type with complex content. The following elements are relevant (as are the <attribute>, <attributeGroup>, and <anyAttribute> elements, which are described more fully in XML Representation of Attribute Declaration Schema Components (§3.2.2), Mapping Rule for Attribute Uses Property (§3.4.2.4), and XML Representation of Wildcard Schema Components (§3.10.2), respectively, and which are not repeated here), and the additional property mappings are as below, supplemented by the mappings in Common Mapping Rules for Complex Type Definitions (§3.4.2.1), Mapping Rule for Attribute Uses Property (§3.4.2.4), Mapping Rule for Attribute Wildcard Property (§3.4.2.5), Mapping Rules for Local Attribute Declarations (§3.2.2.2), and Mapping Rules for References to Top-level Attribute Declarations (§3.2.2.3). Note that either <restriction> or <extension> must appear in the content of <complexContent>, but their content models are different in this case from the case above when they occur as children of <simpleContent>.
complexContent
Element Information Item et al.Complex types with complex content can be the image of two different forms of <complexType> element: one with a <complexContent> child (discussed in Mapping Rules for Complex Types with Explicit Complex Content (§3.4.2.3.1)), and one with neither <simpleContent> nor <complexContent> as a child (discussed in Mapping Rules for Complex Types with Implicit Complex Content (§3.4.2.3.2)). The mapping of the {content type} is the same in both cases; it is described in Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3).
When the <complexType> source declaration has a <complexContent> child, the following mappings apply, supplemented by those specified in Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3), Common Mapping Rules for Complex Type Definitions (§3.4.2.1), Mapping Rule for Attribute Uses Property (§3.4.2.4), and Mapping Rule for Attribute Wildcard Property (§3.4.2.5).
When the <complexType> source declaration
has neither <simpleContent> nor
<complexContent> as a child, it is taken
as shorthand for complex content restricting
·xs:anyType
·. The mapping rules specific to this
situation are as follows; the mapping rules for properties
not described here are as given in
Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3),
Common Mapping Rules for Complex Type Definitions (§3.4.2.1),
Mapping Rule for Attribute Uses Property (§3.4.2.4),
and
Mapping Rule for Attribute Wildcard Property (§3.4.2.5).
For complex types with complex content, the {content type} property is calculated as follows. (For the {content type} on complex types with simple content, see Mapping Rules for Complex Types with Simple Content (§3.4.2.2).)
abc
attribute is present
on the xyz
element", if no xyz
element information item is present, then no
abc
attribute is present on the
(non-existent) xyz
element.false
.minOccurs
[attribute]
has the ·actual value· 0
and which has no
[children] of its own except for <annotation>;
maxOccurs
[attribute] with an ·actual value· of 0;true
, then A particle whose properties are as
follows:
true
, otherwise
element-onlytrue
, otherwise
element-only
appliesToEmpty
= true
mode
= 'none'
, then
the ·explicit content type·.
mode
[attribute]
of the ·wildcard element·, if present,
otherwise interleave.
Any <complexType> source declaration can have <attribute> and <attributeGroup> elements as children, or descendants. The <attribute> element is described in XML Representation of Attribute Declaration Schema Components (§3.2.2) and will not be repeated here.
attributeGroup
Element Information ItemThe <attribute> and <attributeGroup> elements map to the {attribute uses} property of the Complex Type Definition component as described below. This mapping rule is the same for all complex type definitions.
If the
<schema> ancestor has a
defaultAttributes
attribute, and the <complexType> element does not have
defaultAttributesApply
=
false
, then the {attribute uses}
property is
computed as if there were an
<attributeGroup> [child] with empty content
and a ref
[attribute] whose ·actual value· is the
same as that of the
defaultAttributes
[attribute] appearing after any other
<attributeGroup>
[children]. Otherwise proceed as if there were no such
<attributeGroup> [child].
ref
[attribute] of the <attributeGroup>
[children], if any.use
=
prohibited.use
attribute of an
<attribute> is in
establishing the correspondence between a complex type defined
by restriction and its XML representation. It serves to
prevent inheritance of an identically named attribute use from
the {base type definition}. Such an <attribute> does not correspond to any component, and
hence there is no interaction with either explicit or
inherited wildcards in the operation of Complex Type Definition Validation Rules (§3.4.4) or Constraints on Complex Type Definition Schema Components (§3.4.6).
It is pointless, though not an
error, for the use
attribute to have the value
prohibited in other contexts (e.g. in complex type
extensions or named model group definitions), in which cases
the <attribute> element is simply ignored, provided that
it does not violate other constraints in this
specification.The {attribute wildcard} property of a Complex Type Definition depends on the <anyAttribute> element which may be present within the <complexType> element or within the attribute groups referred to within <complexType>. The <attributeGroup> element is described in the preceding section Mapping Rule for Attribute Uses Property (§3.4.2.4) and will not be repeated here.
If the <schema> ancestor has a
defaultAttributes
attribute, and the
<complexType> element does not have
defaultAttributesApply
= false
, then the
{attribute wildcard} property is computed
as if there were an <attributeGroup>
[child] with empty content and a ref
[attribute]
whose ·actual value· is the same as that of the
defaultAttributes
[attribute] appearing after any
other <attributeGroup>
[children]. Otherwise proceed as if there were no such
<attributeGroup> [child].
The following declaration defines a type for specifications of length
by creating a complex type with simple content, with
xs:nonNegativeInteger
as the type of the
content, and a unit
attribute to give the
unit of measurement.
<xs:complexType name="length1"> <xs:simpleContent> <xs:extension base="xs:nonNegativeInteger"> <xs:attribute name="unit" type="xs:NMTOKEN"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:element name="width" type="length1"/>
An instance using this type might look like this:
<width unit="cm">25</width>
A second approach to defining length uses two elements, one for size and one for the unit of measure. The definition of the type and the declaration of the element might look like this:
<xs:complexType name="length2"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:element name="size" type="xs:nonNegativeInteger"/> <xs:element name="unit" type="xs:NMTOKEN"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="depth" type="length2"/>
An instance using this method might look like this:
<depth> <size>25</size><unit>cm</unit> </depth>
A third definition of type leaves the base type implicit; at the component level, the following declaration is equivalent to the preceding one.
<xs:complexType name="length3"> <xs:sequence> <xs:element name="size" type="xs:nonNegativeInteger"/> <xs:element name="unit" type="xs:NMTOKEN"/> </xs:sequence> </xs:complexType>
<xs:complexType name="personName"> <xs:sequence> <xs:element name="title" minOccurs="0"/> <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="surname"/> </xs:sequence> </xs:complexType> <xs:complexType name="extendedName"> <xs:complexContent> <xs:extension base="personName"> <xs:sequence> <xs:element name="generation" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="addressee" type="extendedName"/> <addressee> <forename>Albert</forename> <forename>Arnold</forename> <surname>Gore</surname> <generation>Jr</generation> </addressee>
<xs:complexType name="simpleName"> <xs:complexContent> <xs:restriction base="personName"> <xs:sequence> <xs:element name="forename" minOccurs="1" maxOccurs="1"/> <xs:element name="surname"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="who" type="simpleName"/> <who> <forename>Bill</forename> <surname>Clinton</surname> </who>
<xs:complexType name="paraType" mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="emph"/> <xs:element ref="strong"/> </xs:choice> <xs:attribute name="version" type="xs:decimal"/> </xs:complexType>
mixed
attribute appearing on complexType
itself.<xs:complexType name="name"> <xs:openContent> <xs:any namespace="##other" processContents="skip"/> </xs:openContent> <xs:sequence> <xs:element name="given" type="xs:string"/> <xs:element name="middle" type="xs:string" minOccurs="0"/> <xs:element name="family" type="xs:string"/> </xs:sequence> </xs:complexType>
<xs:complexType name="computer"> <xs:all> <xs:element name="CPU" type="CPUType"/> <xs:element name="memory" type="memoryType"/> <xs:element name="monitor" type="monitorType"/> <xs:element name="speaker" type="speakerType" minOccurs="0"/> <!-- Any additional information about the computer --> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:all> </xs:complexType> <xs:complexType name="quietComputer"> <xs:complexContent> <xs:restriction base="computer"> <xs:all> <xs:element name="CPU" type="CPUType"/> <xs:element name="memory" type="memoryType"/> <xs:element name="monitor" type="monitorType"/> <!-- Any additional information about the computer --> <xs:any processContents="lax" notQName="speaker" minOccurs="0" maxOccurs="unbounded"/> </xs:all> </xs:restriction> </xs:complexContent> </xs:complexType>
quietComputer
has
a lax wildcard, which ·matches· any element but one with the name
speaker
.notQName
attribute,
the wildcard would ·match· elements named
speaker
, as well. In that case, the restriction
would be valid only if there is a
top-level declaration for speaker
that also has type
speakerType
or a type derived from it.
Otherwise, there would be instances locally valid against the restriction
quietComputer
that are not locally valid against the base type
computer
.notQName
attribute on the wildcard and
no top-level declaration for speaker
, then the following is allowed
by quietComputer
, but not by computer
:
<speaker xsi:type="xs:string"/>
mixed
= true.
xs:enumeration
,
xs:pattern
, or
xs:assertion
may appear more than once
among the [children] of
<restriction>.
mode
≠ 'none'
,
then there
must be an <any> among the [children] of
<openContent>.
mode
= 'none'
,
then there must not be an <any> among the [children] of
<openContent>.
mixed
[attribute] is present on both
<complexType> and <complexContent>,
then ·actual values· of those [attributes]
must be the same.
This section defines the concept of ·locally declared type·; this concept plays a role in determining whether restrictions and extensions of complex type definitions are legitimate. The ·locally declared type· is also used to help determine the ·governing element declaration· and ·governing type definition· of an element information item.
[Definition:] Every Complex Type Definition determines a partial functional mapping from element or attribute information items (and their expanded names) to type definitions. This mapping serves as a locally declared type for elements and attributes which are allowed by the Complex Type Definition.
The attribute case is simpler and will be taken first.
The definition for elements is slightly more complex.
xsi:type
, xsi:nil
,
xsi:schemaLocation
, or xsi:noNamespaceSchemaLocation
(see Built-in Attribute Declarations (§3.2.7)),
the appropriate case among the following is true:xsi:type
and the other
attributes named in
clause 2.1; no
·attribution·
is performed for them.
[Definition:] A sequence of element information items is locally valid with respect to a Content Type if and only if it satisfies Element Sequence Locally Valid (Complex Content) (§3.4.4.3) with respect to that Content Type.
[Definition:] During ·validation· of an element information item against its (complex) ·governing type definition·, associations between element and attribute information items among the [children] and [attributes] on the one hand, and the attribute uses, attribute wildcard, particles and open content property record on the other, are established. The element or attribute information item is attributed to the corresponding component.
When an attribute information item has the same expanded name as the {attribute declaration} of an Attribute Use, then the item is attributed to that attribute use. Otherwise, if the item matches an attribute wildcard, as described in Item Valid (Wildcard) (§3.10.4.1), then the item is attributed to that wildcard. Otherwise the item is not attributed to any component.
<xs:sequence> <xs:element name="a"/> <xs:element name="b"/> <xs:element name="c"/> </xs:sequence>and an input sequence
<a/><b/><d/>Then the element <a> is ·attributed· to the particle whose term is the "a" element declaration. Similarly, <b> is ·attributed· to the "b" particle.
[Definition:] During ·validation·, associations between element and attribute information items among the [children] and [attributes] on the one hand, and element and attribute declarations on the other, are also established. When an item is ·attributed· to an ·element particle·, then it is associated with the declaration which is the {term} of the particle. Similarly, when an attribute information item is ·attributed to· an Attribute Use, then the item is associated with the {attribute declaration} of that Attribute Use. Such declarations are called the context-determined declarations. See clause 2.1 (in Element Locally Valid (Complex Type) (§3.4.4.2)) for attribute declarations, clause 2 (in Element Sequence Locally Valid (Particle) (§3.9.4.2)) for element declarations.
All complex type definitions (see Complex Type Definitions (§3.4)) must satisfy the following constraints.
xs:anyType
·. That is, it is
possible to reach the definition of
·xs:anyType
· by repeatedly following the
{base type definition}.xs:anyType
·.[Definition:] A complex type T is a valid extension of its {base type definition} if and only if T.{derivation method} = extension and T satisfies the constraint Derivation Valid (Extension) (§3.4.6.2).
xs:anyType
·.The constraint just given, like other constraints on schemas, must be satisfied by every complex type T to which it applies.
However, under certain conditions conforming processors need not (although they may) detect some violations of this constraint. If (1) the type definition being checked has T . {content type} . {particle} . {term} . {compositor} = all and (2) an implementation is unable to determine by examination of the schema in isolation whether or not clause 2.4.2 is satisfied, then the implementation may provisionally accept the derivation. If any instance encountered in the ·assessment· episode is valid against T but not against T.{base type definition}, then the derivation of T does not satisfy this constraint, the schema does not conform to this specification, and no ·assessment· can be performed using that schema.
It is ·implementation-defined· whether a processor (a) always detects violations of clause 2.4.2 by examination of the schema in isolation, (b) detects them only when some element information item in the input document is valid against T but not against T.{base type definition}, or (c) sometimes detects such violations by examination of the schema in isolation and sometimes not. In the latter case, the circumstances in which the processor does one or the other are ·implementation-dependent·.
The following constraint defines a relation appealed to elsewhere in this specification.
xs:anyType
·.xsi:type
or
·substitution groups·), that the type used is actually ·derived· from the expected
type, and that that ·derivation· does not involve a form of ·derivation· which was
ruled out by the expected type.There is a complex
type definition for ·xs:anyType
· present in every schema
by definition. It has the following properties:
The outer particle of ·xs:anyType
· contains a sequence with a single term:
The inner particle of ·xs:anyType
· contains a wildcard which matches any element:
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: http://www.w3.org/2001/03/XMLSchema/TypeLibrary.xsd.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.
<xs:complexType> . . . <xs:attribute ref="xml:lang" use="required"/> <xs:attribute ref="xml:space" default="preserve"/> <xs:attribute name="version" type="xs:decimal" fixed="1.0"/> </xs:complexType>
The attribute use schema component has the following properties:
{required} determines whether this use of an attribute declaration requires an appropriate attribute information item to be present, or merely allows it.
{attribute declaration} provides the attribute declaration itself, which will in turn determine the simple type definition used.
{value constraint} allows for local specification of a default or fixed value. This must be consistent with that of the {attribute declaration}, in that if the {attribute declaration} specifies a fixed value, the only allowed {value constraint} is the same fixed value, or a value equal or identical to it.
See Annotations (§3.15) for information on the role of the {annotations} property.
Attribute uses correspond to all uses of <attribute> which
allow a use
attribute. These in turn correspond to
two components in each case, an attribute use and its {attribute declaration} (although note the latter is not new when the attribute use is a reference to a top-level attribute declaration). The appropriate mapping is described in XML Representation of Attribute Declaration Schema Components (§3.2.2).
[Definition:] The effective value constraint of an attribute use U is U.{value constraint}, if present, otherwise U.{attribute declaration}.{value constraint}, if present, otherwise the effective value constraint is ·absent·.
All attribute uses (see Attribute Uses (§3.5)) must satisfy the following constraints.
A schema can name a group of attribute declarations so that they can be incorporated as a group into complex type definitions.
Attribute group definitions do not participate in ·validation· as such, but the {attribute uses} and {attribute wildcard} of one or more complex type definitions may be constructed in whole or part by reference to an attribute group. Thus, attribute group definitions provide a replacement for some uses of XML's parameter entity facility. Attribute group definitions are provided primarily for reference from the XML representation of schema components (see <complexType> and <attributeGroup>).
<xs:attributeGroup name="myAttrGroup"> <xs:attribute . . ./> . . . </xs:attributeGroup> <xs:complexType name="myelement"> . . . <xs:attributeGroup ref="myAttrGroup"/> </xs:complexType>
The example above illustrates the pattern
mentioned in XML Representations of Components (§3.1.2): The same
element, in this case attributeGroup
, serves both to
define and to incorporate by reference. In the first
attributeGroup
element in the example, the
name
attribute is required and the
ref
attribute is forbidden; in the second the
ref
attribute is required, the
name
attribute is forbidden.
The attribute group definition schema component has the following properties:
Attribute groups are identified by their {name} and {target namespace}; attribute group identities must be unique within an ·XSD schema·. See References to schema components across namespaces (<import>
) (§4.2.6) for the use of component
identifiers when importing one schema into another.
{attribute uses} is a set of attribute uses, allowing for local specification of occurrence and default or fixed values.
{attribute wildcard} provides for an attribute wildcard to be included in an attribute group. See above under Complex Type Definitions (§3.4) for the interpretation of attribute wildcards during ·validation·.
See Annotations (§3.15) for information on the role of the {annotations} property.
The XML representation for an attribute group definition schema component is an <attributeGroup> element information item. It provides for naming a group of attribute declarations and an attribute wildcard for use by reference in the XML representation of complex type definitions and other attribute group definitions. The correspondences between the properties of the information item after the appropriate ·pre-processing· and the properties of the component it corresponds to are given in this section.
attributeGroup
Element Information ItemWhen an <attributeGroup> appears as a child of <schema> or <redefine>, it corresponds to an attribute group definition as below. When it appears as a child of <complexType> or <attributeGroup>, it does not correspond to any component as such.
<override>
) (§4.2.5) for details.
targetNamespace
[attribute] of the
<schema> ancestor
element information item if present, otherwise ·absent·.ref
[attribute] of the <attributeGroup>
[children], if any.
The rules given above for
{attribute uses}
and {attribute wildcard} specify that
if an <attributeGroup> element A contains a reference
to another attribute group B (i.e. A's [children] include an
<attributeGroup> with a ref
attribute pointing
at B), then A maps to an Attribute Group Definition component whose
{attribute uses} reflect not only
the <attribute> [children] of A but also those of
B and of any <attributeGroup> elements referred
to in B. The same is true for attribute groups referred to from
complex types.
Circular reference is not disallowed. That is, it is not an error if B, or some <attributeGroup> element referred to by B (directly, or indirectly at some remove) contains a reference to A. An <attributeGroup> element involved in such a reference cycle maps to a component whose {attribute uses} and {attribute wildcard} properties reflect all the <attribute> and <any> elements contained in, or referred to (directly or indirectly) by elements in the cycle.
All attribute group definitions (see Attribute Group Definitions (§3.6)) must satisfy the following constraint.
A model group definition associates a name and optional annotations with a Model Group. By reference to the name, the entire model group can be incorporated by reference into a {term}.
Model group definitions are provided primarily for reference from the XML Representation of Complex Type Definition Schema Components (§3.4.2) (see <complexType> and <group>). Thus, model group definitions provide a replacement for some uses of XML's parameter entity facility.
<xs:group name="myModelGroup"> <xs:sequence> <xs:element ref="someThing"/> . . . </xs:sequence> </xs:group> <xs:complexType name="trivial"> <xs:group ref="myModelGroup"/> <xs:attribute .../> </xs:complexType> <xs:complexType name="moreSo"> <xs:choice> <xs:element ref="anotherThing"/> <xs:group ref="myModelGroup"/> </xs:choice> <xs:attribute .../> </xs:complexType>
The model group definition schema component has the following properties:
Model group definitions are identified by their {name} and {target namespace}; model group identities must be unique within an ·XSD schema·. See References to schema components across namespaces (<import>
) (§4.2.6) for the use of component
identifiers when importing one schema into another.
Model group definitions per se do not participate in ·validation·, but the {term} of a particle may correspond in whole or in part to a model group from a model group definition.
{model group} is the Model Group for which the model group definition provides a name.
See Annotations (§3.15) for information on the role of the {annotations} property.
The XML representation for a model group definition schema component is a <group> element information item. It provides for naming a model group for use by reference in the XML representation of complex type definitions and model groups. The correspondences between the properties of the information item after the appropriate ·pre-processing· and the properties of the component it corresponds to are given in this section.
group
Element Information ItemIf
the item has <schema>
or <redefine>
as its parent (in which case there will be a
name
[attribute],
then the item maps
to a model group definition component with properties as
follows:
name
[attribute]; if it overrides
a corresponding declaration in the ·target set· of its parent, it will also (in the
overridden schema document) map to a component as described
below. See Overriding component definitions (<override>
) (§4.2.5) for details.
targetNamespace
[attribute] of the
<schema>
ancestor element information
item if present, otherwise ·absent·.Otherwise,
if
the item
has
a ref
[attribute]
and does not have minOccurs=maxOccurs=0
, then
the <group> element maps
to a particle component with properties
as follows:
maxOccurs
[attribute] equals
unbounded, otherwise the ·actual value· of the
maxOccurs
[attribute], if present, otherwise
1
.ref
[attribute]Otherwise, the <group>
has minOccurs=maxOccurs=0
, in which
case it maps to no component at all.
ref
and no
name
) is not really a named model group at all, but
a reference to one. Also note that in the first (named) case
above no reference is made to minOccurs
or
maxOccurs
: this is because the schema for schema documents does not
allow them on the child of <group> when it is
named. This in
turn is because the {min occurs} and
{max occurs} of the particles which
refer to the definition are what count.All model group definitions (see Model Group Definitions (§3.7)) must satisfy the following constraint.
When the [children] of element information items are not constrained to be empty or by reference to a simple type definition (Simple Type Definitions (§3.16)), the sequence of element information item [children] content may be specified in more detail with a model group. Because the {term} property of a particle can be a model group, and model groups contain particles, model groups can indirectly contain other model groups; the grammar for model groups is therefore recursive. [Definition:] A model group directly contains the particles in the value of its {particles} property. [Definition:] A model group indirectly contains the particles, groups, wildcards, and element declarations which are ·contained· by the particles it ·directly contains·. [Definition:] A model group contains the components which it either ·directly contains· or ·indirectly contains·.
<xs:group name="otherPets"> <xs:all> <xs:element name="birds"/> <xs:element name="fish"/> </xs:all> </xs:group> <xs:all> <xs:element ref="cats"/> <xs:element ref="dogs"/> <xs:group ref="otherPets"/> </xs:all> <xs:sequence> <xs:choice> <xs:element ref="left"/> <xs:element ref="right"/> </xs:choice> <xs:element ref="landmark"/> </xs:sequence>
The model group schema component has the following properties:
When two or more element declarations contained ·directly·, ·indirectly·, or ·implicitly· in the {particles} of a model group have identical names, the type definitions of those declarations must be the same.
See Annotations (§3.15) for information on the role of the {annotations} property.
The XML representation for a model group schema component is either an <all>, a <choice> or a <sequence> element information item. The correspondences between the properties of those information items after the appropriate ·pre-processing· and the properties of the component they correspond to are given in this section.
all
Element Information Item et al.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):
maxOccurs
[attribute] equals unbounded, otherwise the ·actual value· of the maxOccurs
[attribute], if present, otherwise 1
.The particle just described has a Model Group as the value of its {term} property, as follows.
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 ·accepted· by M.
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 Unique Particle Attribution (§3.8.6.4) or the related provisions in the validation rules which specify how to choose a unique ·path· in a non-deterministic model group. By contrast, V(M) takes account of those constraints and includes only the sequences which are ·locally valid· against M. For all model groups M, V(M) is a subset of L(M). L(M) and related concepts are described in this section; V(M) is described in the next section, Principles of Validation against Groups (§3.8.4.2).
[Definition:] When a sequence S of element information items is checked against a model group M, the sequence of ·basic particles· which the items of S match, in order, is a path of S in M. For a given S and M, the path of S in M is not necessarily unique. Detailed rules for the matching, and thus for the construction of paths, are given in Language Recognition by Groups (§3.8.4.1) and Principles of Validation against Particles (§3.9.4.1). Not every sequence has a path in every model group, but every sequence accepted by the model group does have a path. [Definition:] For a model group M and a sequence S in L(M), the path of S in M is a complete path; prefixes of complete paths which are themselves not complete paths are incomplete paths. For example, in the model group
<xs:sequence> <xs:element name="a"/> <xs:element name="b"/> <xs:element name="c"/> </xs:sequence>
the sequences (<a/><b/><c/>
)
and (<a/><b/>
) have ·paths·
(the first a ·complete path· and the second
an ·incomplete path·),
but the sequences (<a/><b/><c/><d/>
) and
(<a/><x/>
) do not
have paths.
<xs:sequence> <xs:element name="a"/> <xs:element name="b"/> <xs:choice/> </xs:sequence>accepts no sequences because the empty
choice
recognizes
no input sequences. But the sequences (<a/>
)
and (<a/><b/>
) have paths in the model group.The definitions of L(M) and ·paths· in M, when M is a ·basic term· or a ·basic particle·, are given in Principles of Validation against Particles (§3.9.4.1). The definitions for groups are given below.
This section defines L(M), the set of ·paths· in M, and V(M), if M is a sequence group.
If M is a Model Group, and the {compositor} of M is sequence, and the {particles} of M is the sequence P1, P2, ..., Pn, then L(M) is the set of sequences S = S1 + S2 + ... + Sn (taking "+" as the concatenation operator), where Si is in L(Pi) for 0 < i ≤ n. The sequence of sequences S1, S2, ..., Sn is a ·partition· of S. Less formally, when M is a sequence of P1, P2, ... Pn, then L(M) is the set of sequences formed by taking one sequence which is accepted by P1, then one accepted by P2, and so on, up through Pn, and then concatenating them together in order.
[Definition:] A partition of a sequence is a sequence of sub-sequences, some or all of which may be empty, such that concatenating all the sub-sequences yields the original sequence.
<xs:sequence> <xs:element name="a"/> <xs:element name="b"/> <xs:element name="c"/> </xs:sequence>
<a/><b/>
When M is a sequence group, the set V(M) (the set of sequences ·locally valid· against M) is the set of sequences S which are in L(M) and which have a ·validation-path· in M. Informally, V(M) contains those sequences which are accepted by M and for which no element information item is ever ·attributed to· a ·wildcard particle· if it can, in context, instead be ·attributed to· an ·element particle·. There will invariably be a ·partition· of S whose members are ·locally valid· against {particles} of M.
<xs:sequence> <xs:any minOccurs="0"/> <xs:element name="a" minOccurs="0"/> </xs:sequence>then the sequence (
<a/>
) has two ·paths·
in M, one containing just the ·wildcard particle· and the other
containing just the ·element particle·. It is the latter
which is a ·validation-path· and which determines which
Particle the item in the input is ·attributed to·.
<xs:sequence> <xs:any minOccurs="0"/> <xs:element name="a"/> </xs:sequence>then the sequence (
<a/><a/>
) is in L(M), but not
in V(M), because the validation rules require that the first
a
be ·attributed to· the ·wildcard particle·.
In a ·validation-path· the initial a
will invariably be
·attributed to· the ·element particle·, and so no sequence
with an initial a
can be ·locally valid· against
this model group.This section defines L(M), the set of ·paths· in M, and V(M), if M is a choice group.
When the {compositor} of M is choice, and the {particles} of M is the sequence P1, P2, ..., Pn, then L(M) is L(P1) ∪ L(P2) ∪ ... ∪ L(Pn), and the set of ·paths· of S in P is the set Q = Q1 ∪ Q2 ∪ ... ∪ Qn, where Qi is the set of ·paths· of S in Pi, for 0 < i ≤ n. Less formally, when M is a choice of P1, P2, ... Pn, then L(M) contains any sequence accepted by any of the particles P1, P2, ... Pn, and any ·path· of S in any of the particles P1, P2, ... Pn is a ·path· of S in P.
The set V(M) (the set of sequences ·locally valid· against M) is the set of sequences S which are in L(M) and which have a ·validation-path· in M. In effect, this means that if one of the choices in M ·attributes· an initial element information item to a ·wildcard particle·, and another ·attributes· the same item to an ·element particle·, then the latter choice is used for validation.
<xs:choice> <xs:any/> <xs:element name="a"/> </xs:choice>then the ·validation-path· for the sequence (
<a/>
)
contains just the ·element particle· and it is to the
·element particle· that the input element will be
·attributed·; the alternate ·path·
containing just the ·wildcard particle· is not relevant for
validation as defined in this specification.
This section defines L(M), the set of ·paths· in M, and V(M), if M is an all-group.
When the {compositor} of M is all, and the {particles} of M is the sequence P1, P2, ..., Pn, then L(M) is the set of sequences S = S1 × S2 × ... × Sn (taking "×" as the interleave operator), where for 0 < i ≤ n, Si is in L(Pi). The set of sequences {S1, S2, ..., Sn} is a ·grouping· of S. The set of ·paths· of S in P is the set of all ·paths· Q = Q1 × Q2 × ... × Qn, where Qi is a ·path· of Si in Pi, for 0 < i ≤ n.
Less formally, when M is an all-group of P1, P2, ... Pn, then L(M) is the set of sequences formed by taking one sequence which is accepted by P1, then one accepted by P2, and so on, up through Pn, and then interleaving them together. Equivalently, L(M) is the set of sequences S such that the set {S1, S2, ..., Sn} is a ·grouping· of S, and for 0 < i ≤ n, Si is in L(Pi).
[Definition:] A grouping of a sequence is a set of sub-sequences, some or all of which may be empty, such that each member of the original sequence appears once and only once in one of the sub-sequences and all members of all sub-sequences are in the original sequence.
<xs:all> <xs:element name="a" minOccurs="0" maxOccurs="5"/> <xs:element name="b" minOccurs="1" maxOccurs="1"/> <xs:element name="c" minOccurs="0" maxOccurs="5"/> </xs:all>and an input sequence S
<a/><b/><a/>where n = 3, then S1 is (
<a/><a/>
),
S2 is (<b/>
),
and the ·path· of
S in M is the sequence containing first the Particle
for the a
element, then the Particle for the
b
element, then once more the
Particle for the a
element.
The set V(M) (the set of sequences ·locally valid· against M) is the set of sequences S which are in L(M) and which have a ·validation-path· in M. In effect, this means that if one of the Particles in M ·attributes· an element information item to a ·wildcard particle·, and a ·competing· Particle ·attributes· the same item to an ·element particle·, then the ·element particle· is used for validation.
<xs:all> <xs:any/> <xs:element name="a"/> </xs:all>then M accepts sequences of length two, containing one
a
element and one other element.
a
element. After the first a
the ·element particle· accepts no more elements
and so no longer ·competes· with the ·wildcard particle·.
So if the sequence (<a/><a/>
)
is checked against M, in the ·validation-path· the
first a
element will be ·attributed to·
the ·element particle· and the second to the
·wildcard particle·.
a
,
use a wildcard that explicitly disallows it. That is,
<xs:all> <xs:any notQName="a"/> <xs:element name="a"/> </xs:all>Now the sequence (
<a/><a/>
) is not
accepted by the particle.
It is possible for a given sequence of element information items to have multiple ·paths· in a given model group M; this is the case, for example, when M is ambiguous, as for example
<xs:choice> <xs:sequence> <xs:element ref="my:a" maxOccurs="unbounded"/> <xs:element ref="my:b"/> </xs:sequence> <xs:sequence> <xs:element ref="my:a"/> <xs:element ref="my:b" maxOccurs="unbounded"/> </xs:sequence> </xs:choice>
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 deterministic
expression (as it is termed in [XML 1.1])
or a "1-unambiguous" expression, as it
is defined by [Brüggemann-Klein / Wood 1998].
For example,
<xs:sequence> <xs:element name="a" minOccurs="0"/> <xs:element name="a"/> </xs:sequence>
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 ·paths· in M, as do other sequences of element information items.
By imposing conditions on ·paths· in a model group M it is possible to identify a set of ·validation-paths· in M, such that if M is a model group which obeys the Unique Particle Attribution (§3.8.6.4) constraint, then any sequence S has at most one ·validation-path· in M. The language V(M) can then be defined as the set of sequences which have ·validation-paths· in M.
[Definition:] Two Particles P1 and P2 contained in some Particle P compete with each other if and only if some sequence S of element information items has two ·paths· in P which are identical except that one path has P1 as its last item and the other has P2.
For example, in the content model
<xs:sequence> <xs:element name="a"/> <xs:choice> <xs:element name="b"/> <xs:any/> </xs:choice> </xs:sequence>
the sequence (<a/><b/>
) has two paths,
one (Q1) consisting of the Particle whose {term} is
the declaration for a
followed by the
Particle whose {term} is
the declaration for b
, and
a second (Q2) consisting of the Particle whose {term} is
the declaration for a
followed by the
Particle whose {term} is
the wildcard. The sequences Q1 and Q2 are
identical except for their last items, and so the
two Particles which are the last items of Q1 and
Q2 are said to ·compete· with each other.
<xs:choice> <xs:sequence> <xs:element name="a"/> <xs:element name="b"/> </xs:sequence> <xs:sequence> <xs:element name="c"/> <xs:any/> </xs:sequence> </xs:choice>the Particles for
b
and the
wildcard do not ·compete·, because there is no
pair of ·paths· in P which differ only in one
having the ·element particle· for b
and
the other having the ·wildcard particle·.
[Definition:] Two (or more) ·paths· of a sequence S in a Particle P are competing paths if and only if they are identical except for their final items, which differ.
[Definition:] For any sequence S of element information items and any particle P, a ·path· of S in P is a validation-path if and only if for each prefix of the ·path· which ends with a ·wildcard particle·, the corresponding prefix of S has no ·competing path· which ends with an ·element particle·.
[Definition:] A sequence S of element information items is locally valid against a particle P if and only if S has a ·validation-path· in P. The set of all such sequences is written V(P).
All model groups (see Model Groups (§3.8)) must satisfy the following constraints.
= 1
which is
the {particle}
of the {content type} of a complex
type definition.=
{max occurs} = 1
, where
P is among the {particles} of a
Model Group whose {compositor} is
all.[Definition:] An element particle is a Particle whose {term} is an Element Declaration. [Definition:] A wildcard particle is a Particle whose {term} is a Wildcard. Wildcard particles may be referred to as "strict", "lax", or "skip" particles, depending on the {process contents} property of their {term}.
The following constraints define relations appealed to elsewhere in this specification.
0
if there are no
{particles}).0
if there are no
{particles}).0
if there are no {particles}).0
if there are no {particles}).As described in Model Groups (§3.8), particles contribute to the definition of content models.
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 ·attributed to· to Particles of the content model. The attribution of items to Particles determines the calculation of the items' ·context-determined declarations· and thus partially determines the ·governing element declarations· for the children: when an element information item is ·attributed to· an ·element particle·, that Particle's Element Declaration, or an Element Declaration ·substitutable· for it, becomes the item's ·context-determined declaration· and thus normally its ·governing element declaration·; when the item is ·attributed to· a ·wildcard particle·, the ·governing element declaration· depends on the {process contents} property of the wildcard and on QName resolution (Instance) (§3.17.6.3).
<xs:element ref="egg" minOccurs="12" maxOccurs="12"/> <xs:group ref="omelette" minOccurs="0"/> <xs:any maxOccurs="unbounded"/>
The particle schema component has the following properties:
In general, multiple element information item [children], possibly with intervening character [children] if the content type is mixed, can be ·validated· with respect to a single particle. When the {term} is an element declaration or wildcard, {min occurs} determines the minimum number of such element [children] that can occur. The number of such children must be greater than or equal to {min occurs}. If {min occurs} is 0, then occurrence of such children is optional.
Again, when the {term} is an element declaration or wildcard, the number of such element [children] must be less than or equal to any numeric specification of {max occurs}; if {max occurs} is unbounded, then there is no upper bound on the number of such children.
When the {term} is a model group, the permitted occurrence range is determined by a combination of {min occurs} and {max occurs} and the occurrence ranges of the {term}'s {particles}.
[Definition:] A particle directly contains the component which is the value of its {term} property. [Definition:] A particle indirectly contains the particles, groups, wildcards, and element declarations which are contained by the value of its {term} property. [Definition:] A particle contains the components which it either ·directly contains· or ·indirectly contains·.
See Annotations (§3.15) for information on the role of the {annotations} property.
minOccurs
and maxOccurs
attributes in the schema document:Every particle P ·recognizes· some language L(P). When {min occurs} and {max occurs} of P are both 1, L(P) is the language of P's {term}, as described in Validation of Basic Terms (§3.9.4.1.2). The following section (Language Recognition for Repetitions (§3.9.4.1.1)) describes how more complicated counts are handled.
When P.{min occurs} = P.{max occurs} = n, and P.{term} = T, then L(P) is the set of sequences S = S1 + S2 + ... + Sn such that Si is in L(T) for 0 < i ≤ n. Less formally: L(P) is the set of sequences which have ·partitions· into n sub-sequences for which each of the n subsequences is in the language accepted by the {term} of P.
When P.{min occurs} = j and P.{max occurs} = k, and P.{term} = T, then L(P) is the set of sequences S = S1, + S2 + ... + Sn, i.e. the set of sequences which have ·partitions· into n sub-sequences such that n ≥ j and n ≤ k (or k is unbounded) and Si is in L(T) for 0 < i ≤ n.
When P.{min occurs} = 0, then L(P) also includes the empty sequence.
In the preceding section (Language Recognition for Repetitions (§3.9.4.1.1)), the language L(P) ·accepted· by a Particle P is defined in terms of the language ·accepted· by P's {term}. This section defines L(T) for ·basic terms·; for the definition of L(T) when T is a group, see Language Recognition by Groups (§3.8.4.1).
[Definition:] For any Element Declaration D, the language L(D) ·accepted· by D is the set of all sequences of length 1 whose sole member is an element information item which ·matches· D.
[Definition:] For any Wildcard W, the language L(W) ·accepted· by W is the set of all sequences of length 1 whose sole member is an element information item which ·matches· W.
[Definition:] An element information item E matches a Wildcard W (or a ·wildcard particle· whose {term} is W) if and only if E is locally ·valid· with respect to W, as defined in the validation rule Item Valid (Wildcard) (§3.10.4.1).
[Definition:] Two namespace names N1 and N2 are said to match if and only if they are identical or both are ·absent·.
For principles of validation when the {term} is a model group instead of a ·basic particle·, see Language Recognition by Groups (§3.8.4.1) and Principles of Validation against Groups (§3.8.4.2).
All particles (see Particles (§3.9)) must satisfy the following constraint.
The following constraint defines a relation appealed to elsewhere in this specification.
The following constraint defines a relation appealed to elsewhere in this specification.
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 ·validation· of attribute and element information items dependent on their namespace names and optionally on their local names.
<xs:any processContents="skip"/> <xs:any namespace="##other" processContents="lax"/> <xs:any namespace="http://www.w3.org/1999/XSL/Transform" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" notQName="xsl:comment xsl:fallback"/> <xs:any notNamespace="##targetNamespace ##local"/> <xs:anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/>
The wildcard schema component has the following properties:
A set each of whose members is either an xs:anyURI value or the distinguished value ·absent·. Required.
##local
" in the schema document
maps to the value ·absent· in the
{namespace constraint}
property)xsi:type
, and the
item must be ·valid· as
appropriate.See Annotations (§3.15) for information on the role of the {annotations} property.
The XML representation for a wildcard schema component is an <any> or <anyAttribute> element information item.
any
Element Information ItemanyAttribute
Element Information ItemAn <any> information item
corresponds both to a wildcard component and to
a particle containing that wildcard
(unless minOccurs=maxOccurs=0
, in which case the
item corresponds to no component at
all).
The mapping rules are given in the following two subsections.
As always, the mapping rules
given here apply after, not before, the appropriate
·pre-processing·.
Processors may issue a warning
if a list of xs:anyURI
values in the
namespace
or noNamespace
attributes includes any values beginning
with the string '##
'.
##
' are not
IRIs or URIS according to the definitions given in
the relevant RFCs (for references see [XML Schema: Datatypes]) and
users of this specification are discouraged from using
them as namespace names, to avoid confusion with the
keyword values defined by this specification.
The mapping from an <any> information item to a particle is as follows.
maxOccurs
= unbounded,
otherwise the ·actual value· of the
maxOccurs
[attribute], if present, otherwise
1
.The mapping from an <any> information item to a wildcard component is as follows. This mapping is also used for mapping <anyAttribute> information items to wildcards, although in some cases the result of the mapping is further modified, as specified in the rules for <attributeGroup> and <complexType>.
namespace
[attribute] is
present, then
the appropriate case among the following:namespace
= "##any"
, then any;namespace
= "##other"
, then not;notNamespace
[attribute]
is present, then
not;
namespace
nor
notNamespace
is present) any.namespace
nor
notNamespace
is present, then the empty set;namespace
= "##any"
, then the empty set;namespace
= "##other"
, then a set consisting of
·absent·
and, if the targetNamespace
[attribute] of
the <schema> ancestor element
information item is present, its ·actual value·;namespace
or
notNamespace
[attribute] (whichever is
present), except
##targetNamespace
, the corresponding
member is the ·actual value· of the
targetNamespace
[attribute] of the
<schema> ancestor
element information item if present, otherwise
·absent·;##local
, the
corresponding member is ·absent·.notQName
[attribute] is
present, then a set whose members
correspond to the items in the
·actual value· of the notQName
[attribute],
as follows.
##defined
",
then the keyword defined is a member of the set.##definedSibling
",
then the keyword sibling is a member of the set.notQName
[attribute] is not present, then
the empty set.
Wildcards are subject to the same ambiguity constraints (Unique Particle Attribution (§3.8.6.4)) as other content model particles: If an instance element could match one of two wildcards, within the content model of a type, that model is in error.
namespace
and
notNamespace
attributes must not both be
present.
When an element or attribute information item is ·attributed· to a wildcard and the preceding constraint (Item Valid (Wildcard) (§3.10.4.1)) is satisfied, then the item has no ·context-determined declaration·. Its ·governing· declaration, if any, is found by matching its expanded name as described in QName resolution (Instance) (§3.17.6.3). Note that QName resolution is performed only if the item is ·attributed· to a strict or lax wildcard; if the wildcard has a {process contents} property of skip, then the item has no ·governing· declaration.
[Definition:] An element or attribute information item is skipped if it is ·attributed· to a skip wildcard or if one of its ancestor elements is.
All wildcards (see Wildcards (§3.10)) must satisfy the following constraint.
The following constraints define a relation appealed to elsewhere in this specification.