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 © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
↓XML Schema: Structures↓↑This document↑ specifies the ↓XML Schema definition language↓↑XML Schema Definition Language↑, which offers facilities for describing the structure and constraining the contents of XML↓ 1.0↓ documents, including those which exploit the XML Namespace facility. The schema language, which is itself ↑represented in an↑ XML↓ 1.0↓↑ vocabulary↑ and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML↓ 1.0↓ document type definitions (DTDs). This specification depends on ↓XML Schema↓↑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 is a ↑Last Call↑ Public Working Draft of ↓XML Schema 1.1↓↑W3C XML Schema Definition Language (XSDL) 1.1↑. It is here made available for review by W3C members and the public. ↓It is intended to give an indication of the W3C XML Schema Working Group's intentions for this new version of the XML Schema language and our progress in achieving them. It attempts to be complete in indicating what will change from version 1.0, but does not specify in all cases how things will change.↓↑XSDL 1.1 retains all the essential features of XSDL 1.0, but adds several new features to support functionality requested by users, fixes some errors in XSDL 1.0, and clarifies some wording.↑
all-groups
may now be extended. (This change is in addition to other changes
in all-groups described in Changes since version 1.0 (§G).)report element has been dropped
and the rules for evaluation of XPath expressions have been made
more explicit. These changes may help minimize confusion between
the assertions defined here and the assert and
report elements of Schematron, which can still be used
in <appinfo> elements, or separately.xs:ID.xsi:type have been
clarified.For those primarily interested in the changes since version 1.0, the ↑appendix↑ Changes since version 1.0 (§G)↓ appendix, which summarizes both changes already made and also those in prospect, with links to the relevant sections of this draft,↓ is the recommended starting point. ↑It summarizes both changes made since XSDL 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.
Please send comments on this Working Draft to www-xml-schema-comments@w3.org (archive).
The Last Call review period for this document extends until 8 November 2007. 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) Each Bugzilla entry and email message should contain only one comment.
Although feedback based on any aspect of this specification is welcome, there are certain aspects of the design presented herein for which the Working Group is particularly interested in feedback. These are designated "priority feedback" aspects of the design, and identified as such in editorial notes at appropriate points in this draft. Any feature mentioned in a priority feedback note should be considered a "feature at risk": the feature may be retained as is, modified, or dropped, depending on the feedback received from readers, schema authors, schema users, and implementors.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced by the W3C XML Schema Working Group as part of the W3C XML Activity. The goals of ↓the XML Schema language version↓↑XSDL↑ 1.1 are discussed in the ↑document↑ Requirements for XML Schema 1.1↓ document↓. 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-1.0.xml. Three kinds of changes are
highlighted: ↑new, added text↑, ↑changed
text↓, and ↓deleted
text↓.
This document sets out the structural part ↓(XML Schema: Structures)↓ of the ↓XML Schema definition language↓↑XML Schema Definition Language↑.
Chapter 2 presents a Conceptual Framework (§2) for ↓XML Schemas↓↑XSDL↑, including an introduction to the nature of ↓XML Schemas↓↑XSDL schemas↑ and an introduction to the ↓XML Schema↓↑XSDL↑ 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↑ ↓XML Schema↓↑XSDL schema↑ for an ↓XML Schema↓↑XSDL↑ 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 ↓Schemas↓↑Schema Documents (Structures)↑ (normative) (§A) for the XML representation of schemas and References (normative) (§B).
The non-normative appendices include the DTD for Schemas (non-normative) (§K) and a Glossary (non-normative) (§J).
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 !! 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 ↓XML Schema: Structures↓↑XSDL↑ 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 ↓may↓↑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 ↓XML Schema: Structures↓ formalism ↑defined here↑ to express syntactic, structural and value constraints applicable to its document instances. The ↓XML Schema: Structures↓↑XSDL↑ 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 ↓any application↓↑ applications↑. Some applications ↓may↓↑will↑ require constraint capabilities not expressible in this language, and so ↓may↓↑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: or the prefix xsd: 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.6). These
attributes are in the namespacewhose 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.1) uses
two 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.
fn bound to
http://www.w3.org/2005/xpath-functions (defined in
[Functions and Operators]html bound to
http://www.w3.org/1999/xhtmlmy (in examples) bound to the target namespace of
the example schema documentrddl bound to
http://www.rddl.org/vc bound to
http://www.w3.org/2007/XMLSchema-versioning (defined
in this and related specifications)xhtml bound to
http://www.w3.org/1999/xhtmlxlink bound to
http://www.w3.org/1999/xlinkxml bound to
http://www.w3.org/XML/1998/namespace (defined in
[XML 1.1] and [XML-Namespaces 1.1])xmlns bound to
http://www.w3.org/2000/xmlns/ (defined in [XML-Namespaces 1.1])xs bound to
http://www.w3.org/2001/XMLSchema (defined in this and
related specifications)xsd bound to
http://www.w3.org/2001/XMLSchema (defined in this and
related specifications)
Editorial Note: In its current
state, the status quo uses both the prefix xs and the
prefix xsd for the XSDL namespace. Once the Working
Group reaches a decision on the name of the language, the editors
expect to bring forward a proposal to unify all uses on a single
prefix; which prefix to use will depend on the Working Group's
decision.
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/TransformIn 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).
Editorial Note: Loose ends to be
tied up: (1) the example with a reference to
xsl:quantity lacks any binding for the prefix
xsl (and does XSL define a name
quantity); (2) We need references (informative?) to
the RDDL and XLink specs.
Sometimes other specifications or Application Programming Interfaces (APIs) need to refer to the XML Schema Definition Language in general, sometimes they need to refer to a specific version of the language. 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/XMLSchemahttp://www.w3.org/XML/XMLSchema/vX.Yhttp://www.w3.org/XML/XMLSchema/v1.0 identifies XSDL
version 1.0 and http://www.w3.org/XML/XMLSchema/v1.1
identifies XSDL version 1.1.http://www.w3.org/XML/XMLSchema/vX.Y/
NeX.Y of the XSDL specification.
For example, http://www.w3.org/XML/XMLSchema/v1.0/2e
identifies the second edition of XSDL version 1.0.http://www.w3.org/XML/XMLSchema/vX.Y/
Ne/yyyymmddX.Y of the XSDL 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 XSDL 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 XSDL version 1.0 Second
Edition Proposed Edited Recommendation (PER) published on 18 March
2004.Please see XSDL Language Identifiers (non-normative) (§N) 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],↓ ↑[XPath 2.0], ↑and [XML Schema: Datatypes].
See Required Information Set Items and Properties (normative) (§E) 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], [XML-Namespaces 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}.
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 ↓may determine↓↑determines↑ which of several different components ↓may arise↓↑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>.
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 following highlighting is used for non-normative commentary in this document:
↓Following [XML 1.1], w↓↑W↑ithin normative prose in this specification, the words may↓ and↓↑, 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].
↓Note however that this↓↑This↑ specification provides a definition of error and of conformant processors' responsibilities with respect to errors ↓(see↓↑in↑ Schemas and Schema-validity Assessment (§5)↓) which is considerably more complex than that of [XML 1.1]↓.
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 ↓may wish to first↓↑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 ↓XML Schema↓↑XSDL schema↑ ↓consists↓↑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 ↓may↓↑may↑ specify augmentations to those items and their descendants. This augmentation makes explicit information ↓which may have been↓ implicit in the original document, such as normalized and/or default values for attributes and elements and the types of element and attribute information items. ↑The input information set can also be 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 (§D.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 valid and its derivatives are used to refer to clause 1 above, the determination of local schema-validity.
Throughout this specification, [Definition:] the word assessment is used to refer to the overall process of local validation, schema-validity assessment and infoset augmentation.
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, ↓XML Schemas↓↑XSDL schemas↑ can be described in terms of an abstract data model. In defining ↓XML Schemas↓↑schemas↑ in terms of an abstract data model, this specification rigorously specifies the information which must be available to a conforming ↓XML Schema↓↑XSDL↑ 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 ↓comprise↓↑make up↑ the abstract data model of the schema. ↓[Definition:] An XML Schema is a set of ·schema components·↓↑[Definition:] An XSDL schema is a set of ·schema components·↑. There are ↓13↓↑14↑ kinds of component in all, falling into three groups. The primary components, which may (type definitions) or must (element and attribute declarations) have names, are as follows:
The secondary components, ↓which must have names, ↓are as follows:
Finally, the "helper" components provide small parts of other components; they are not independent of their context:
The name [Definition:] Component covers all the different kinds of 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↓↑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. In the case of declarations, this in turn determines the namespace name of, for example, the element information items it ↓may↓↑will↑ ·validate·.
·Validation·, defined in detail in Schema Component Details (§3), is a relation between information items and schema components. For example, an attribute information item ↓may ·validate·↓↑is ·validated·↑ with respect to an attribute declaration, a list of element information items ↓may ·validate·↓ 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 ↓a distinguished ·ur-type definition·,↓ ↑·xs:anyType·,↑ every ·type definition· is, by construction, either a ·restriction· or an ·extension· of some other type definition. The
graph of these relationships forms a tree known as the Type
Definition Hierarchy.
[Definition:] ↓A↓↑The↑ type definition used as the basis for an ·extension· or ·restriction· is known as the base type definition of that definition.
[Definition:] ↓A type definition whose declarations or facets are in a one-to-one relation with those of another specified type definition, with each in turn restricting the possibilities of the one it corresponds to,↓↑A type defined with the same constraints as its ·base type definition·, or with more,↑ is said to be a restriction. The ↓specific restrictions↓↑added constraints↑ might include narrowed ranges or reduced alternatives. ↓Members of a type, A, whose definition is a ·restriction· of the definition of another type, B, are always locally valid against type B as well.↓↑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 distinguished complex type definition, the ur-type definition, whose name is anyType in the XML Schema namespace, is present in each ·XML Schema·, serving as the root of the type definition hierarchy for that schema.
[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 XSDL namespace, is present in each ·XSDL 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 XSDL
namespace, is also present in each ·XSDL
schema·. The XSDL
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 xsd:anyType and
xsd: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.6).)
[Definition:] A type definition used as the basis for an ·extension· or ·restriction· is known as the base type definition of that definition.
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 ↓some particular
simple↓↑its↑
·base type
definition·. ↓For the built-in
primitive type definitions, this is
↓[Definition:] ↓the↓↑The↑
simple ur-type definition, a special ·restriction· of ↓the ·ur-type definition·↓↑·xs:anyType·↑, whose name is
anySimpleType in the XML Schema namespace↑ is the root of the
·Type Definition
Hierarchy· for the simple
type definitions↑. The ·simple ur-type definition· is considered to have an unconstrained
lexical space, and a value space consisting of the union of the
value spaces of all the built-in primitive datatypes and the set of
all lists of all members of the value spaces of all the built-in
primitive datatypes. ↑The built-in list datatypes all have the ·simple ur-type definition· as their ·base type definition·.↑
[Definition:] There is a further special datatype called anyAtomicType, a ·restriction· of the ·simple ur-type definition·, which is the ·base type definition· of all the primitive built-in datatypes. It too is considered to have an unconstrained lexical space. Its value space consists of the union of the value spaces of all the built-in primitive datatypes.
The mapping from lexical space to value space is unspecified for items whose type definition is the ·simple ur-type definition· ↑or ·anyAtomicType·↑. Accordingly this specification does not constrain processors' behavio↓u↓r in areas where this mapping is implicated, for example checking such items against enumerations, constructing default attributes or elements whose declared type definition is the ·simple ur-type definition· , checking identity constraints involving such items.
↓Simple types may also be defined↓↑[XML Schema: Datatypes] provides mechanisms for defining new simple type definitions by ·restricting· one of the built-in primitive or ordinary datatypes. 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 the ·simple ur-type definition·.
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↓↑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.↑ Future versions may allow more kinds
of extension, requiring more complex transformations to effect
casting.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).
In XML↓ 1.0↓, the name and content of an element must correspond exactly to the element type referenced in the corresponding content model.
[Definition:] Through the new mechanism of element substitution groups, ↓XML Schemas↓↑XSDL↑ provides a more powerful model 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↓↑·substitution group·↑. Other top-level element declarations, regardless of target namespace, can be designated as members of the ↓substitution group↓↑·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↓↑·substitution group·↑ as well.
All such members must have type definitions which are either the same as the head's type definition or restrictions or extensions of it. Therefore, although the names of elements can vary widely as new namespaces and members of the ↓substitution group↓↑·substitution group·↑ are defined, the content of member elements is strictly limited according to the type definition of the ↓substitution group↓↑·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 Gis 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, 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).
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 within a complex type definition is embedded within an attribute use, which specifies whether the declaration requires or merely allows its attribute, and whether it has a default or fixed value.
A wildcard is a special kind of particle which matches element and attribute information items dependent on their namespace name↑s↑↓,↓ ↓independently of↓↑and optionally on↑ their local names.
For detailed information on wildcards, see Wildcards (§3.10).
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]↓↑[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).
Editorial Note: Priority Feedback Request
Assertions are currently only allowed to be specified in complex types. It may be deemed useful also to include assertions in named model group definitions and/or attribute groups, or even simple types. The XML Schema Working Group solicits input from implementors and users of this specification on this question.