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 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 1.1↓↑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-200608.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 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/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
xml
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/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
).
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/XMLSchema
http://www.w3.org/XML/XMLSchema/vX.Y
http://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/
Ne
X.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/yyyymmdd
X.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.
Aspects of this document which the Working Group are committed to changing, but where (all) changes are not yet in place, are signalled by the appearance of an Issue, with a link to the associated version 1.1 Requirement, for example:
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:
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].
This specification provides a definition 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 ↓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↑ 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 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, 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:] 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 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. ↓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).)
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:] 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' 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 the ·simple ur-type definition· , checking identity constraints involving such items.
[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, 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 names 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. ↓Depending on their formulation, assertions are either required to be true of the instance, or required to be false.↓ If an element or attribute information item fails to satisfy an assertion associated with a given type, then that information item is not locally ·valid· with respect to that type.
For detailed information on Assertions, see Assertions (§3.13).
↑Editorial Note: Priority Feedback Request↑
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 and for XSDL-aware processors.
This specification describes three levels of conformance for schema aware processors. The first is required of all processors. Support for the other two will depend on the application environments for which the processor is intended.
[Definition:] Minimally conforming processors must completely and correctly implement the ·Schema Component Constraints·, ·Validation Rules·, and ·Schema Information Set Contributions· contained in this specification.
[Definition:] ·Minimally conforming· processors which accept schemas represented in the form of XML documents as described in Layer 2: Schema Documents, Namespaces and Composition (§4.2) are additionally said to be schema-document aware. Such processors must, when processing schema documents, completely and correctly implement ↑(or enforce)↑ all ·Schema Representation Constraints· in this specification, and must adhere exactly to the specifications in Schema Component Details (§3) for mapping the contents of such documents to ·schema components· for use in ·validation· and ·assessment·.
[Definition:] A ·minimally conforming· processor which is not ·schema-document aware· is said to be a non-schema-document-aware processor.
[Definition:] Web-aware processors are network-enabled processors which are not only both ·minimally conforming· and ·schema-document aware·, 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.7) and How schema definitions are located on the Web (§4.3.2). .
See Schemas and Namespaces: Access and Composition (§4) for a more detailed explanation of the mechanisms supporting these levels of conformance.
As discussed in ↓XML Schema↓↑XSDL↑ Abstract Data Model (§2.2), most schema components (↓may↓↑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. ↓A symbol space is similar to the non-normative concept of namespace partition introduced in [XML-Namespaces 1.1].↓ There is a single distinct symbol space within a given ·target namespace· for each kind of definition and declaration component identified in ↓XML Schema↓↑XSDL↑ Abstract Data Model (§2.2), except that within a target namespace, simple type definitions and complex type definitions share a symbol space. Within a given symbol space, names are unique, but the same name may appear in more than one symbol space without conflict. For example, the same name can appear in both a type definition and an element declaration, without conflict or necessary relation between the two.
Locally scoped attribute and element declarations are special with regard to symbol spaces. Every complex type definition defines its own local attribute and element declaration symbol spaces, where these symbol spaces are distinct from each other and from any of the other symbol spaces. So, for example, two complex type definitions having the same target namespace can contain a local attribute declaration for the unqualified name "priority", or contain a local element declaration for the name "address", without conflict or necessary relation between the two.
The XML representation of schema components uses a vocabulary
identified by the namespace name
http://www.w3.org/2001/XMLSchema
. For brevity, the
text and examples in this specification use the prefix
xs:
to stand for this namespace; in practice, any
prefix can be used.
XML Schema↑ Definition Language↑:
Structures ↓also↓ defines several attributes for
direct use in any XML documents. ↓These attributes are in a
different namespace, which has the namespace name
http://www.w3.org/2001/XMLSchema-instance
. For
brevity, the text and examples in this specification use the prefix
xsi:
to stand for this latter namespace; in practice,
any prefix can be used.↓↑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 have appropriate
attribute declarations for these attributes built in, see Attribute Declaration for the 'type'
attribute (§3.2.7), Attribute Declaration for the 'nil' attribute
(§3.2.7), Attribute Declaration for the 'schemaLocation' attribute
(§3.2.7) and Attribute Declaration for the
'noNamespaceSchemaLocation' attribute (§3.2.7).
Users of the namespaces defined here should be aware, as a matter of namespace policy, that more names may be defined in these namespaces in future versions of this or other specifications.
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 Interpretation (§3.17.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
↓may
be↓↑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 ↓may↓↑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.
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.2)), 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↓↑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. Equality of components for the purposes of this specification is always defined as equality of names (including target namespaces) within symbol spaces.
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 interpreting as constraining implementations, as for instance between using a null value for such properties or not representing them at all.
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 may 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 may 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) (§K)) and schema components. ↓All
the↓↑The key↑ element information items
in the XML representation of a schema ↓must be↓↑are↑
in the ↓XML
Schema↓↑XSDL↑
namespace, that is their [namespace name] ↓must be↓↑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.
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.1).
For each kind of schema component there is a corresponding normative XML representation. The sections below describe the correspondences between the properties of each kind of schema component on the one hand and the properties of information items in that XML representation on the other, together with constraints on that representation above and beyond those implicit in the Schema for Schema Documents (Structures) (normative) (§A).
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:] The phrase actual value is used to refer to the member of the value space of the simple type definition associated with an attribute information item which corresponds to its ·normalized value·. This will often be a string, but ↓may↓↑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 ·validated·.
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 ↓may↓↑will in some cases↑ be violated if one or more references cannot be ↓resolved↓↑·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 ↓may↓↑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 all ·validation· purposes.
#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.If the simple type definition used in an item's ·validation· is the ·simple ur-type definition·, then the ·normalized value· must be determined as in the preserve case above.
There are three alternative validation rules which ↓may↓↑help↑ supply the necessary background for the above: Attribute Locally Valid (§3.2.4) (clause 3), Element Locally Valid (Type) (§3.3.4) (clause 3.1.3) or Element Locally Valid (Complex Type) (§3.4.4) (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 a 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 the attribute 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.
A {scope} with {variety} global identifies attribute declarations available for use in complex type definitions throughout the schema. Locally scoped declarations are available for use only within the ↓complex type definition↓↑Complex Type Definition or Attribute Group Definition↑ identified by the {scope}'s {parent} property. ↓ This property is ·absent· in the case of declarations within attribute group definitions: their scope will be determined when they are used in the construction of complex type definitions.↓
{value constraint} 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 identical to {value}, and if
absent receives {value} and {lexical form} as for default. Note
that it is values that are checked, not strings.
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). 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↓↑may↑ provide default information. The correspondences between the properties of the information item and properties of the component are as follows:
attribute
Element Information
Item<attribute
default = string
fixed = string
form = (qualified |
unqualified)
id = ID
name = NCName
ref = QName
targetNamespace = anyURI
type = QName
use = (optional | prohibited |
required) : optional
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, simpleType?)
</attribute>
Editorial Note: Priority Feedback Request
Earlier versions of
this specification did not allow a targetNamespace
attribute on attribute declarations; it has been added in this
version to make restriction of complex types easier. The XML Schema
Working Group has designated the targetNamespace
attribute a ‘feature at risk’: it may be dropped from
future drafts of this specification if implementation or usage
experience shows that its costs outweigh its benefits. The XML
Schema Working Group solicits input from implementors and users of
this specification as to whether the addition of this attribute is
desirable and acceptable.
targetNamespace
[attribute] of the parent <schema>
element information item, or ·absent· if there is none.type
[attribute], if present, otherwise the
·simple ur-type
definition·.default
or a
fixed
[attribute], then a Value Constraint as follows,
otherwise ·absent·.
ref
[attribute] is absent, it corresponds
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·.
form
is present and its
·actual value· is qualified
, or if
form
is absent and the ·actual
value· of
attributeFormDefault
on the <schema> ancestor is
qualified
, then the ·actual
value· of the
targetNamespace
[attribute] of the parent <schema>
element information item, or ·absent· if there is none, otherwise ·absent·.targetNamespace
is
present , then its ·actual value·.targetNamespace
is
not present and one of the following is true
form
is absent and the
·actual value· of attributeFormDefault
on
the <schema> ancestor is qualified
targetNamespace
[attribute] of the ancestor <schema>
element information item, or ·absent· if there is none.type
[attribute], if present, otherwise the
·simple ur-type
definition·.ref
[attribute] is present), it corresponds
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·.
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.
The default when no simple type definition is referenced or provided is the ·simple ur-type definition·, which imposes no constraints at all.
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.
default
and fixed
must not both be present.ref
or
name
is present, but not both.targetNamespace
is present
then all of the following must
be true:
name
is present.form
is not present.targetNamespace
[attribute] or its ·actual value· is different from the ·actual value· of targetNamespace
of
<attribute>, then all of the following are
true:
xsi:type
(Attribute Declaration for the 'type' attribute
(§3.2.7)), then the item's ·actual
value· ·resolves· to a type definition.[Definition:] The governing type definition of an attribute, in a given schema-validity ·assessment· episode, is the {type definition} of the ·governing attribute declaration·, unless the processor has stipulated another type definition at the start of ·assessment· (see Assessing Schema-Validity (§5.2)), in which case it is the stipulated type definition.
See also Attribute Default Value (§3.4.5), Match Information (§3.4.5) and Schema Information (§3.17.5), 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
Allowedhttp://www.w3.org/2001/XMLSchema-instance
(unless it
is one of the four built-in declarations given in the next
section).
xsi:type
or xsi:nil
, which would be
seriously misleading, as they would have no
effect.↓xsi:
attributes to specify default or fixed value
constraints (e.g. in a component corresponding to a schema document
construct of the form <xsd:attribute ref="xsi:type"
default="xsd:integer"/>
), but the practice is not
recommended; including such attribute uses will tend to mislead
readers of the schema document, because the attribute uses would
have no effect; see Element Locally Valid (Complex Type) (§3.4.4) and
Attribute Default Value
(§3.4.5) for details.There are four attribute declarations present in every schema by definition:
type
http://www.w3.org/2001/XMLSchema-instance
nil
http://www.w3.org/2001/XMLSchema-instance
schemaLocation
http://www.w3.org/2001/XMLSchema-instance
http://www.w3.org/2001/XMLSchema-instance
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·.
A {scope} with {variety} global identifies element declarations available for use in content models throughout the schema. Locally scoped declarations are available for use only within the ↓complex type↓↑Complex Type Definition or Model Group Definition↑ identified by the {scope}'s {parent} property. ↓ This property is ·absent· in the case of declarations within named model groups: their scope will be determined when they are used in the construction of complex type definitions.↓
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 ↓·valid·
only if it satisfies↓↑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.6.1)) can
cause the ·governing type
definition· and the declared
{type
definition} to be different. ↑
If {nillable} is true, then an element can
also be ·valid·
if it carries the namespace qualified attribute with [local name] nil
from
namespace http://www.w3.org/2001/XMLSchema-instance
and value true
(see xsi:nil (§2.6.2)) even if it has no text or element
content despite a {content type} which would otherwise require
content. Formal details of element ·validation· are described in Element Locally Valid (Element) (§3.3.4).
{value constraint} establishes a default or fixed value for an element. If a {value constraint} with a {variety} of default is present, and if the element being ·validated· is empty, then ↓the {value constraint}'s {lexical form} becomes the [schema normalized value] of the ·validated· element in the ·post-schema-validation infoset·.↓ ↑the element is treated as if the {value constraint}'s {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 identical to the {value constraint}'s {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).
Element declarations are potential members of the ↓substitution group↓↑·substitution groups·↑, if any, identified by ↓{substitution group affiliation}↓↑{substitution group affiliations}↑. Potential membership is transitive but not symmetric; an element declaration is a potential member of any group of which ↑any entry in↑ its ↓{substitution group affiliation}↓↑{substitution group affiliations}↑ is a potential member. Actual membership ↓may↓↑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 ↓nominated as↓↑named in↑ the ↓{substitution group affiliation}↓↑{substitution group affiliations}↑ of other element declarations having the same ↑declared ↑{type definition} or ↓types↓↑some type↑ derived therefrom. The explicit values of {substitution group exclusions} rule out element declarations having types which are extensions or restrictions respectively of {type definition}. ↓If both values are specified, then the declaration must not be nominated as the {substitution group affiliation} of any other declaration.↓
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.6.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↓↑·substitution group·↑ headed by the declared element. If {disallowed substitutions} is empty, then all derived types and ↓substitution group↓↑·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↓↑may↑ provide occurrence and default information. The correspondences between the properties of the information item and properties of the component(s) it corresponds to are as follows:
element
Element Information
Item<element
abstract = boolean : false
block = (#all | List of
(extension | restriction |
substitution))
default = string
final = (#all | List of
(extension | restriction))
fixed = string
form = (qualified |
unqualified)
id = ID
maxOccurs = (nonNegativeInteger | unbounded)
: 1
minOccurs = nonNegativeInteger : 1
name = NCName
nillable = boolean : false
ref = QName
substitutionGroup = List of QName
targetNamespace = anyURI
type = QName
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, ((simpleType |
complexType)?, alternative*, (unique | key | keyref)*))
</element>
Editorial Note: Priority Feedback Request
Earlier versions of
this specification did not allow a targetNamespace
attribute on element declarations; it has been added in this
version to make restriction of complex types easier. The XML Schema
Working Group has designated the targetNamespace
attribute a ‘feature at risk’: it may be dropped from
future drafts of this specification if implementation or usage
experience shows that its costs outweigh its benefits. The XML
Schema Working Group solicits input from implementors and users of
this specification as to whether the addition of this attribute is
desirable and acceptable.
targetNamespace
[attribute] of the parent <schema>
element information item, or ·absent· if there is none.type
[attribute], otherwise the {type
definition} of the element declaration ·resolved· to by the ·actual
value· of the
substitutionGroup
[attribute], if present, otherwise the
·ur-type
definition·.↓ ↑The first of the
following that applies:↑
type
[attribute], if it is present.substitutionGroup
[attribute], if present.xs:anyType
·.test
[attribute].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 the
↑declared ↑{type
definition}'s {content type} has {variety} simple, that
{content
type}'s {simple type definition}, or else the built-in
string simple type definition).
substitutionGroup
[attribute], if present, otherwise
·absent·.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↓↑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] is absent, the
corresponding schema components are 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
.form
is present and its
·actual value· is qualified
, or if
form
is absent and the ·actual
value· of
elementFormDefault
on the <schema> ancestor is
qualified
, then the ·actual
value· of the
targetNamespace
[attribute] of the parent <schema>
element information item, or ·absent· if there is none, otherwise ·absent·.targetNamespace
is
present , then its ·actual value·.targetNamespace
is
not present and one of the following is true
form
is absent and the
·actual value· of elementFormDefault
on
the <schema> ancestor is qualified
targetNamespace
[attribute] of the ancestor <schema>
element information item, or ·absent· if there is none.ref
[attribute] is present), the
corresponding schema component is 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
.<element> corresponds to an element declaration, and allows the type definition of that declaration to be specified either by reference or by explicit inclusion.
<element>s within <schema> 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 pre-declared type definition. Otherwise an anonymous
<simpleType> or <complexType> is provided
inline.
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}.
As noted above 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. As with attribute names, the names of locally-scoped element declarations with no {target namespace} reside in symbol spaces local to the type definition which contains them.
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 head of its substitution group if it
identifies one, ↓ ↑the same type definition
as the first substitution-group head named in the
substitutionGroup
[attribute], if
present,↑ otherwise ↓the ·ur-type definition·↓↑·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 below at XML Representation of Identity-constraint Definition Schema Components (§3.11.2) for <key>, <unique> and <keyref>.
<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↓↑·substitution
group·↑.
Two further elements are declared, each a member of the
facet
↓substitution group↓↑·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:<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:element>
default
and fixed
are not both present.ref
or
name
is present, but not both.ref
is present, then all
of <complexType>, <simpleType>, <key>,
<keyref>, <unique>, nillable
,
default
, fixed
, form
,
block
and type
are absent, i.e. only
minOccurs
, maxOccurs
, id
and
<annotation> are allowed to appear together with
ref
.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:
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·.
xsd:error
·.xsi:type
, that is an [attribute] whose [namespace name] is identical to
http://www.w3.org/2001/XMLSchema-instance
and whose
[local name] is
type
.[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}.
http://www.w3.org/2001/XMLSchema-instance
and whose
[local name] is
nil
.false
.true
, and all of
the following are true:
http://www.w3.org/2001/XMLSchema-instance
and whose
[local name] is
type
, then all of the following are true:
xsi:type
among the [attributes] of E (i.e. one
whose [namespace name] is identical to
http://www.w3.org/2001/XMLSchema-instance
and whose
[local name] is
type
), then all of the following are true:
xsi:type
attribute whose value does not ·resolve· to a type definition, or if the type
definition fails to ·override· the ·selected
type definition·, then the
·selected type
definition· of its ·governing element declaration· becomes the ·governing type
definition·. The local
validity of the element with respect to the ·governing type
definition· is recorded in
the [local type validity] property.http://www.w3.org/2001/XMLSchema-instance
and whose
[local name] is one of
type
, nil
, schemaLocation
or
noNamespaceSchemaLocation
.xsi:type
[attribute] (one whose [namespace name] is identical to
http://www.w3.org/2001/XMLSchema-instance
and whose
[local name] is
type
) and does not have a ·governing element declaration·, then the ·actual
value· of
xsi:type
·resolves· to the type definition.xsi:type
attribute cannot be
locally valid with respect to any type other than that named in the
attribute.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.http://www.w3.org/2001/XMLSchema-instance
and whose
[local name] is
type
.xs:anyType
·.xs:anyType
·↑ as per Element Locally Valid (Type)
(§3.3.4)↑ and assessing schema-validity of its [attributes] and [children] as per clause 3 and clause 4 above. If the element information item is ·skipped·, it must
not be laxly assessed↑.
Editorial Note: Priority Feedback Request
In version 1.0 of this specification, the fallback to lax validation described in the preceding paragraph was optional, not required. The XML Schema Working Group solicits input from implementors and users of this specification as to whether this change is desirable and acceptable.
xsi:
[attributes] be assessed with respect
to the corresponding attribute declarations from Built-in Attribute Declarations
(§3.2.7). The result of such assessment is present in the
·post-schema-validation infoset·, as defined in Attribute Declaration Information Set Contributions
(§3.2.5).xsi:type
[attribute] is involved, however,
clause 1.2 takes precedence, as is
made clear in Element Locally Valid
(Element) (§3.3.4).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), Identity-constraint Table (§3.11.5), Validated with Notation (§3.14.5), and Schema Information (§3.17.5), which describe other information set contributions related to element information items.
All element declarations (see Element Declarations (§3.3)) must satisfy the following constraint.
xsd:error
·.↑The following constraints define relations appealed to elsewhere in this specification.
[Definition:] One element declaration is ↓validly↓ substitutable for another if together they satisfy constraint Substitution Group OK (Transitive) (§3.3.6).
[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 ↓·XML
Schema·↓↑·XSDL 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.6.1)), and for use in the XML
representation of schema components (specifically in <element>). See References to schema
components across namespaces (<import>
)
(§4.2.4) 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 ↓must not be used as the {type definition} for the ·validation· of element information items↓↑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 ↓they↓↑such abstract types↑ must not be referenced from an xsi:type (§2.6.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.6.1) or the operation of a ↓substitution group↓↑·substitution group·↑.
{attribute uses} are a set of attribute uses. See Element Locally Valid (Complex Type) (§3.4.4) and Attribute Locally Valid (§3.2.4) 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), The Wildcard Schema Component (§3.10.1) and Wildcard allows Expanded Name (§3.10.4) for formal details of attribute wildcard ·validation·.
{prohibited substitutions} determine whether an element declaration appearing in a · content model· is prevented from additionally ·validating· element items with an xsi:type (§2.6.1) attribute that identifies a complex type definition derived by extension or restriction from this definition, or element items in a ↓substitution group↓↑·substitution group·↑ whose type definition is similarly derived: If {prohibited substitutions} is empty, then all such substitutions are allowed, otherwise, the derivation method(s) it names are disallowed.
{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 displays first the elements involved in the first case, then those for the second. The property mapping is shown once for each case.
complexType
Element Information
Item<complexType
abstract = boolean : false
block = (#all | List of
(extension | restriction))
final = (#all | List of
(extension | restriction))
id = ID
mixed = boolean : false
name = NCName
defaultAttributesApply = boolean : true
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, (simpleContent | complexContent | (openContent?, (group | all | choice | sequence)?, ((attribute |
attributeGroup)*, anyAttribute?), assert*)))
</complexType>
targetNamespace
[attribute] of the <schema>
ancestor element information item if present, otherwise ·absent·.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}
;blockDefault
[attribute] of <schema>
↓may↓↑may↑ include values other than
restriction orextension, 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 (the parent element
information item will be <element>), the Element Declaration corresponding to
that parent information item.<simpleContent
id = ID
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, (restriction | extension))
</simpleContent>
<restriction
base = QName
id = ID
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, (simpleType?,
(minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | maxScale | minScale | length | minLength | maxLength | enumeration | whiteSpace | pattern)*)?, ((attribute |
attributeGroup)*, anyAttribute?), assert*)
</restriction>
<extension
base = QName
id = ID
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, ((attribute |
attributeGroup)*, anyAttribute?), assert*)
</extension>
<attributeGroup
id = ID
ref = QName
{any attributes with non-schema namespace . .
.}>
Content: (annotation?)
</attributeGroup>
<anyAttribute
id = ID
namespace = ((##any | ##other) |
List of (anyURI | (##targetNamespace |
##local)) )
notNamespace = List of (anyURI | (##targetNamespace |
##local))
notQName = List of (QName | ##defined)
processContents = (lax | skip |
strict) : strict
{any attributes with non-schema namespace . .
.}>
Content: (annotation?)
</anyAttribute>
If the defaultAttributesApply
[attribute] of the <complexType> element is not present or has
·actual value· true
, and the <schema>
ancestor has an defaultAttributes
attribute, then
properties {attribute uses} and {attribute wildcard} are 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]. Otherwise proceed as if
there were no such <attributeGroup> [child].
ref
[attribute] of the <attributeGroup> [children], if any.base
[attribute] is a complex type
definition, the {attribute uses} of that type definition, unless
the <restriction> alternative is chosen, in
which case some members of that type definition's {attribute
uses} must not be included, namely
those whose {attribute declaration}'s {name} and {target
namespace} are the same as one of the following:
use
[attribute] of the relevant <attribute> among the [children] of <restriction> being
prohibited.base
[attribute] is a complex type
definition with an {attribute wildcard}, then that
{attribute wildcard}.base
[attribute] is a complex type
definition whose own {content type} has {variety} simple and the
<restriction> alternative is chosen, then
starting from either
base
[attribute]base
[attribute] is a complex type
definition whose own {content type} has {variety} mixed and
{particle}
a Particle which is
·emptiable·, as defined in Particle Emptiable
(§3.9.6) and the <restriction> alternative is chosen, then
starting from the simple type definition corresponding to the
<simpleType> among the [children] of <restriction> (which must be present) a simple type definition which
restricts that simple type definition 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);base
[attribute] is a complex type
definition (whose own {content type} must
have {variety} simple, see below) and the
<extension> alternative is chosen, then the
{simple type definition} of the {content type}
of that complex type definition;base
[attribute] is a simple type definition
and the <extension> alternative is chosen), then
that simple type definition.xs:anyType
·↑, and the details of
the mappings must be modified as
necessary.<complexContent
id = ID
mixed = boolean
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, (restriction | extension))
</complexContent>
<restriction
base = QName
id = ID
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, openContent?, (group | all | choice | sequence)?, ((attribute |
attributeGroup)*, anyAttribute?), assert*)
</restriction>
<extension
base = QName
id = ID
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, openContent?, ((group | all | choice | sequence)?, ((attribute |
attributeGroup)*, anyAttribute?), assert*))
</extension>
<openContent
id = ID
mode = (none | interleave |
suffix) : interleave
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, any?)
</openContent>
ref
[attribute] of the <attributeGroup> [children], if any.base
[attribute], unless the <restriction> alternative is chosen, in which case
some members of that type definition's {attribute
uses} must not be included, namely
those whose {attribute declaration}'s {name} and {target
namespace} are the same as one of the following:
use
[attribute] of the relevant <attribute> among the [children] of <restriction> being
prohibited.false
.minOccurs
[attribute] has the ·actual value· 0
;maxOccurs
[attribute] with an ·actual value· of 0;minOccurs
[attribute] has the ·actual value· 0
;true
,
then A particle whose properties are as follows:
true
, otherwise
element-onlybase
[attribute]base
[attribute] has a {content type}
with {variety} empty or simple,
then a Content
Type as per clause 4.1.2
above;true
, otherwise
element-onlybase
[attribute] followed by the ·effective content·.base
[attribute]. Then the
appropriate case among the following:
appliesToEmpty
[attribute] is truemode
[attribute] is 'none'
,
then a Content
Type as follows:
mode
[attribute] of the ·wildcard element·, if present, otherwise
interleave.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).Careful consideration of the above concrete syntax reveals that
a type definition need consist of no more than a name, i.e. that
<complexType name="anyThing"/>
is allowed.
<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"/> <width unit="cm">25</width> <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"/> <depth> <size>25</size><unit>cm</unit> </depth> <xs:complexType name="length3"> <xs:sequence> <xs:element name="size" type="xs:nonNegativeInteger"/> <xs:element name="unit" type="xs:NMTOKEN"/> </xs:sequence> </xs:complexType>
length3
is the abbreviated alternative to
length2
: they correspond to identical type definition
components.<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"/> <xs:element name="memory"/> <xs:element name="monitor"/> <xs:element name="speaker" minOccurs="0"/> <!-- Any additional information about the computer --> <xs:any processContents="lax"/> </xs:all> </xs:complexType> <xs:complexType name="quietComputer"> <xs:complexContent> <xs:restriction base="computer"> <xs:all> <xs:element name="CPU"/> <xs:element name="memory"/> <xs:element name="monitor"/> <!-- Any additional information about the computer --> <xs:any processContents="lax" notQName="speaker"/> </xs:all> </xs:restriction> </xs:complexContent> </xs:complexType>
notQName
attribute, the restriction might or might not
be valid, depending on whether the schema has a top-level
declaration for speaker
.computer
maps speaker
elements in the
input to a ·default
binding· consisting of the
element declaration for speaker
, while the restricted
type quietComputer
would map them to a ·default binding· consisting of ·xs:anyType
·. The base type's ·default binding· does not subsume the restriction's
·default
binding·, so the restriction
fails to satisfy clause 2.2 of constraint Content type restricts
(§3.4.6).base
[attribute] must be a complex type definition↑ whose {content type}
does not have {variety}
simple↑;base
[attribute] is one of the
following:
<xs:complexType . .
.mixed='true'
when the <simpleContent> alternative
is chosen has no effect on the corresponding component, and
should be avoided. This may be ruled
out in a subsequent version of this specification.mode
[attribute] is not 'none'
,
then there must 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.http://www.w3.org/2001/XMLSchema-instance
and whose
[local name] is one of
type
, nil
, schemaLocation
or
noNamespaceSchemaLocation
↓
↑named 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:
[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) 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 attribute uses, attribute wildcards, particles and open contents on the other, are established. The element or attribute information item is attributed to the corresponding component.
When the expanded name of an attribute information item ·matches· the {name} and {target namespace} of 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), then the item is attributed to that wildcard. Otherwise the item is not attributed to any component.
<xsd:sequence> <xsd:element name="a"/> <xsd:element name="b"/> <xsd:element name="c"/> </xsd: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)) for attribute declarations, clause 2 (in Element Sequence Locally Valid (Particle) (§3.9.4.2)) for element declarations.
↑Editorial Note: Priority Feedback Request↑
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 ↓·ur-type
definition·↓↑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 has a {derivation method} of extension and satisfies the constraint Derivation Valid (Extension) (§3.4.6).
The following constraint defines a relation appealed to elsewhere in this specification.
xsi:type
or ↓substitution
groups↓↑·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.Note:
The wording of clause 2.1 above appeals to a notion of component identity which is only incompletely defined by this version of this specification. In some cases, the wording of this specification does make clear the rules for component identity. These cases include:There is a complex type definition ↓nearly equivalent to the
·ur-type definition·↓↑for ·xs:anyType
·↑ present in every
schema by definition. It has the following properties:
The outer particle of ↓·anyType·↓↑·xs:anyType
·↑ contains a sequence
with a single term:
The inner particle of ↓·anyType·↓↑·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.
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 is its {value constraint}, if present, otherwise its {attribute declaration}'s {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 ↓may↓↑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↓↑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 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 ↓·XML
Schema·↓↑·XSDL schema·↑. See References to schema
components across namespaces (<import>
)
(§4.2.4) for the use of component identifiers when
importing one schema into another.
{attribute uses} is a set 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 and properties of the component it corresponds to are as follows:
attributeGroup
Element
Information Item<attributeGroup
id = ID
name = NCName
ref = QName
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, ((attribute |
attributeGroup)*, anyAttribute?))
</attributeGroup>
targetNamespace
[attribute] of the ↓parent↓↑ancestor↑ schema
element information item.ref
[attribute] of the <attributeGroup> [children], if any.The example above illustrates a pattern which recurs in the XML
representation of schemas: The same element, in this case
attributeGroup
, serves both to define and to
incorporate by reference. In the first case the name
attribute is required, in the second the ref
attribute
is required, and the element must be
empty. These two are mutually exclusive, and also conditioned by
context: the defining form, with a name
, must occur at the top level of a schema, whereas
the referring form, with a ref
, must occur within a complex type definition or an
attribute group definition.
ref
[attribute] which ↓resolves↓↑·resolves·↑ to the component
corresponding to this <attributeGroup>. Indirect
circularity is also ruled out. That is, when QName resolution (Schema Document) (§3.17.3)
is applied to a ·QName· arising from any <attributeGroup>s with a ref
[attribute] among the [children], it must not be the case that a ·QName·
is encountered at any depth which ↓resolves↓↑·resolves·↑ to the component
corresponding to this <attributeGroup>.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 Definitions (§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 ↓·XML
Schema·↓↑·XSDL schema·↑. See References to schema
components across namespaces (<import>
)
(§4.2.4) 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↓↑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 and properties of the component it corresponds to are as follows:
group
Element Information
Item<group
id = ID
maxOccurs = (nonNegativeInteger | unbounded)
: 1
minOccurs = nonNegativeInteger : 1
name = NCName
ref = QName
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, (all | choice | sequence)?)
</group>
name
[attribute] (in which case the item
will have <schema> or <redefine> as parent), then the
item corresponds to a model group definition component with
properties as follows:targetNamespace
[attribute] of the ↓parent↓↑ancestor↑ schema
element information item.ref
[attribute], in which case it
corresponds to a particle component 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
.ref
[attribute]The name of this section is slightly misleading, in that the
second, un-named, case above (with a ref
and no
name
) is not really a named model group at all, but a
reference to one. Also note that in the first (named) case above no
reference is made to minOccurs
or
maxOccurs
: this is because the schema for
schema↓s↓↑
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.
Given the constraints on its appearance in content models, an <all> must only occur as the only item in the [children] of a named model group definition or a content model: see Constraints on Model Group Schema Components (§3.8.6).
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↓↑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 content models 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:all> <xs:element ref="cats"/> <xs:element ref="dogs"/> </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:
=0
or 1
, {max
occurs}=1
.When two or more particles contained directly or indirectly in the {particles} of a model group have identically named element declarations as their {term}, the type definitions of those declarations must be the same. By 'indirectly' is meant particles within the {particles} of a group which is itself the {term} of a directly contained particle, and so on recursively.
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 and properties of the component they correspond to are as follows:
all
Element Information
Item<all
id = ID
maxOccurs = 1 : 1
minOccurs = (0 |
1) : 1
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, ( | element |
any)*)
</all>
<choice
id = ID
maxOccurs = (nonNegativeInteger | unbounded)
: 1
minOccurs = nonNegativeInteger : 1
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, (element | group | choice | sequence |
any)*)
</choice>
<sequence
id = ID
maxOccurs = (nonNegativeInteger | unbounded)
: 1
minOccurs = nonNegativeInteger : 1
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, (element | group | choice | sequence |
any)*)
</sequence>
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
.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) or the related provisions in the validation rules which specify how to choose a unique ·path· in a non-deterministic content model. 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 P, the path of S in P 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 content model, but every sequence accepted by the content model does have a path. [Definition:] For a content model 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 content model
<xsd:sequence> <xsd:element name="a"/> <xsd:element name="b"/> <xsd:element name="c"/> </xsd: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.
<xsd:sequence> <xsd:element name="a"/> <xsd:element name="b"/> <xsd:choice/> </xsd:sequence>accepts no sequences because the empty
choice
recognizes no input sequences. But the sequences
(</a>
) and (</a><b/>
)
have paths in the content model.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↓↑may↑ be empty, such that concatenating all the sub-sequences yields the original sequence.
<xsd:sequence> <xsd:element name="a"/> <xsd:element name="b"/> <xsd:element name="c"/> </xsd: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 the sub-sequences of P.
<xsd:sequence> <xsd:any minOccurs="0"/> <xsd:element name="a" minOccurs="0"/> </xsd: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·.<xsd:sequence> <xsd:any minOccurs="0"/> <xsd:element name="a"/> </xsd: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.
<xsd:choice> <xsd:any/> <xsd:element name="a"/> </xsd: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.
<xsd:all> <xsd:element name="a" minOccurs="0" maxOccurs="5"> <xsd:element name="b" minOccurs="1" maxOccurs="1"> <xsd:element name="c" minOccurs="0" maxOccurs="5"> </xsd:element> </xsd: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 P 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.
<xsd:all> <xsd:any/> <xsd:element name="a"/> </xsd:all>then M accepts sequences of length two, containing one
a
element and one other element. The other element can
be anything at all, including a second 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,
<xsd:all> <xsd:any notQName="a"/> <xsd:element name="a"/> </xsd: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
<xsd:choice> <xsd:sequence> <xsd:element ref="my:a" maxOccurs="unbounded"/> <xsd:element ref="my:b"/> </xsd:sequence> <xsd:sequence> <xsd:element ref="my:a"/> <xsd:element ref="my:b" maxOccurs="unbounded"/> </xsd:sequence> </xsd: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 [One-Unambiguous Regular Languages]↑.
For example,
<xsd:sequence> <xsd:element name="a" minOccurs="0"/> <xsd:element name="a"/> </xsd: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) 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
<xsd:sequence> <xsd:element name="a"/> <xsd:choice> <xsd:element name="b"/> <xsd:any/> </xsd:choice> </xsd: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.
<xsd:choice> <xsd:sequence> <xsd:element name="a"/> <xsd:element name="b"/> </xsd:sequence> <xsd:sequence> <xsd:element name="c"/> <xsd:any/> </xsd:sequence> </xsd: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.[Definition:] The attributions of a sequence S of element information items, when S is checked against a particle P, are the ·element· or ·wildcard particles· in P with which the items in S are matched. It is the sequence of these Particles which forms the ·path· of S in P. When Particle is non-deterministic, then each element information item in S is attributed to to the Particle it matches up with in the unique ·validation-path·, not to any other Particle. Element information items are attributed to ·element particles· only when the element's expanded name ·matches· the {term} of the Particle, and to ·wildcard particles· only then the element's namespace ·matches· the Wildcard. In addition, the ·attribution· of element information items to Particles must respect the structure (sequence, choice, {min occurs} and {max occurs}, etc.) of the Particle and of Particles nested within its {term}. The rules are given in more detail in Language Recognition by Groups (§3.8.4.1) and Language Recognition for Repetitions (§3.9.4.1), and in Validation Rule Element Sequence Accepted (Particle) (§3.9.4.2).
[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 ↓partially↓ determines the calculation of the items' ·context-determined declarations·↑and thus partially determines the ·governing element declarations· for the children↑: ↓W↓↑w↑hen 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 ↓·context-determined declaration·↓↑·governing element declaration·↑ depends on the ↓variety↓↑{process contents} property↑ of the wildcard↑ and on QName resolution (Instance) (§3.17.4)↑.
<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.
Particles correspond to all three elements (<element>
not immediately within <schema>, <group> not immediately within
<schema> and <any>) which allow minOccurs
and maxOccurs
attributes. These in turn correspond to
two components in each case, a particle and its {term}. The appropriate
mapping is described in XML
Representation of Element Declaration Schema Components
(§3.3.2), XML
Representation of Model Group Schema Components (§3.8.2)
and XML Representation of
Wildcard Schema Components (§3.10.2) respectively.
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}. The following section (Language Recognition for Repetitions (§3.9.4.1)) describes how more complicated counts are handled.
When {min occurs} of P = {max occurs} of P = n, and T is the {term} of P, then L(P) is the set of sequences S = S1 + S2 + ... + Snsuch 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 {min occurs} = j and {max occurs} = k, and T is the {term} of P, 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 {min occurs} = 0, then L(P) also includes the empty sequence.
When the {term} of a Particle P is a Wildcard W, then L(P) is the set of all sequences of length 1 whose sole member is an element information item E 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 W allows the [namespace name] of E, as defined in the validation rule Wildcard allows Namespace Name (§3.10.4).
[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).
n
sub-sequences such that n
is greater than or equal to
{min
occurs}.All particles (see Particles (§3.9)) must satisfy the following constraints.
The following constraints define relations appealed to elsewhere in this specification.
=1
and
its {term} is a
sequence group whose {particles}' first member is a particle
all of whose properties, recursively, are identical to those of
B, with the exception of {annotation} properties.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"/> <xs:anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/>
The wildcard schema component has the following properties:
xsi:type
,
and the item must be ·valid·
as appropriate.See Annotations (§3.15) for information on the role of the {annotations} property.
↑Editorial Note: Priority Feedback Request↑
The XML representation for a wildcard schema component is an <any> or <anyAttribute> element information item. The correspondences between the properties of an <any> information item and properties of the components it corresponds to are as follows (see <complexType> and <attributeGroup> for the correspondences for <anyAttribute>):
any
Element Information
Item<any
id = ID
maxOccurs = (nonNegativeInteger | unbounded)
: 1
minOccurs = nonNegativeInteger : 1
namespace = ((##any | ##other) |
List of (anyURI | (##targetNamespace |
##local)) )
notNamespace = List of (anyURI | (##targetNamespace |
##local))
notQName = List of (QName | ##defined)
processContents = (lax | skip |
strict) : strict
{any attributes with non-schema namespace . .
.}>
Content: (annotation?)
</any>
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
.namespace
[attribute] is present, then the
appropriate case among the following:
notNamespace
[attribute] is present, then
not;namespace
nor notNamespace
is present)
any.namespace
nor notNamespace
is present, then the empty
set;namespace
[attribute] is present and its ·actual value· is "##other"
, then
a set consisting ·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 are QName values corresponding to the space-delimited
substrings of the ·actual value· of the notQName
[attribute]↓ if
present↓, ↑except if one such
substring is ##defined
, the corresponding member is
the keyword defined,↑ otherwise
↑(the
notQName
[attribute] is not
present)↑ the empty set.Wildcards are subject to the same ambiguity constraints (Unique Particle Attribution (§3.8.6)) 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
are not both present;When an element or attribute information item is ·attributed· to a wildcard and the preceding constraint (Item Valid (Wildcard) (§3.10.4)) 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.4). 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.
Identity-constraint definition components provide for uniqueness and reference constraints with respect to the contents of multiple elements and attributes.
<xs:key name="fullName"> <xs:selector xpath=".//person"/> <xs:field xpath="forename"/> <xs:field xpath="surname"/> </xs:key> <xs:keyref name="personRef" refer="fullName"> <xs:selector xpath=".//personPointer"/> <xs:field xpath="@first"/> <xs:field xpath="@last"/> </xs:keyref> <xs:unique name="nearlyID"> <xs:selector xpath=".//*"/> <xs:field xpath="@id"/> </xs:unique>
The identity-constraint definition schema component has the following properties:
A restricted XPath (XML Path Language, James Clark and Steve DeRose, eds., W3C, 16 November 1999.) expression.
If a value is present, its {identity-constraint category} must be key or unique.
Identity-constraint definitions are identified by their {name} and {target
namespace}; Identity-constraint definition identities
must be unique within an ↓·XML
Schema·↓↑·XSDL schema·↑. See References to schema
components across namespaces (<import>
)
(§4.2.4) for the use of component identifiers when
importing one schema into another.
These constraints are specified along side the specification of
types for the attributes and elements involved, i.e. something
declared as of type integer ↓may↓↑can↑
also serve as a key. Each constraint declaration has a name, which
exists in a single symbol space for constraints. The identity
conditions appealed to in checking these constraints apply to the
values of the fields selected, not their lexical
representation, so that for example 3.0
and
3
would be conflicting keys if they were both decimal,
but non-conflicting if they were both strings, or one was a string
and one a decimal.
Overall the augmentations to XML's ID/IDREF
mechanism are:
{selector} specifies a restricted XPath (↓[XPath]↓↑[XPath 2.0]↑) expression relative to instances of the element being declared. This must identify a ↓node set of subordinate elements (i.e.↓ ↑sequence of element nodes that are↑ contained within the declared element↓)↓ to which the constraint applies.
{fields} specifies XPath expressions relative to each element selected by a {selector}. This must identify a single node (element or attribute) whose content or value, which must be of a simple type, is used in the constraint. It is possible to specify an ordered list of {fields}s, to cater to multi-field keys, keyrefs, and uniqueness constraints.
In order to reduce the burden on implementers, in particular implementers of streaming processors, only restricted subsets of XPath expressions are allowed in {selector} and {fields}. The details are given in Constraints on Identity-constraint Definition Schema Components (§3.11.6).
xsl:key
.See Annotations (§3.15) for information on the role of the {annotations} property.
The XML representation for an identity-constraint definition schema component is either a <key>, a <keyref> or a <unique> element information item. The correspondences between the properties of those information items and properties of the component they correspond to are as follows:
unique
Element Information
Item<unique
id = ID
name = NCName
ref = QName
xpathDefaultNamespace = (anyURI | (##defaultNamespace |
##targetNamespace | ##local))
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, (selector, field+))
</unique>
<key
id = ID
name = NCName
ref = QName
xpathDefaultNamespace = (anyURI | (##defaultNamespace |
##targetNamespace | ##local))
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, (selector, field+))
</key>
<keyref
id = ID
name = NCName
ref = QName
refer = QName
xpathDefaultNamespace = (anyURI | (##defaultNamespace |
##targetNamespace | ##local))
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, (selector, field+))
</keyref>
<selector
id = ID
xpath = a subset of XPath expression, see
below
{any attributes with non-schema namespace . .
.}>
Content: (annotation?)
</selector>
<field
id = ID
xpath = a subset of XPath expression, see
below
{any attributes with non-schema namespace . .
.}>
Content: (annotation?)
</field>
ref
[attribute] is absent, the
corresponding schema component is as follows:targetNamespace
[attribute] of the ↓parent↓↑ancestor↑ schema
element information item.xpath
[attribute] of the <selector> element information item among the
[children]xpath
as the designated expression [attribute].xpath
[attribute]s of the <field>
element information item [children], in order.xpath
as the designated expression [attribute].refer
[attribute], otherwise ·absent·.ref
[attribute] is present), the
corresponding schema component is the identity-constraint
definition ·resolved· to by the ·actual
value· of the
ref
[attribute].<xs:element name="vehicle"> <xs:complexType> . . . <xs:attribute name="plateNumber" type="xs:integer"/> <xs:attribute name="state" type="twoLetterCode"/> </xs:complexType> </xs:element> <xs:element name="state"> <xs:complexType> <xs:sequence> <xs:element name="code" type="twoLetterCode"/> <xs:element ref="vehicle" maxOccurs="unbounded"/> <xs:element ref="person" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:key name="reg"> <!-- vehicles are keyed by their plate within states --> <xs:selector xpath=".//vehicle"/> <xs:field xpath="@plateNumber"/> </xs:key> </xs:element> <xs:element name="root"> <xs:complexType> <xs:sequence> . . . <xs:element ref="state" maxOccurs="unbounded"/> . . . </xs:sequence> </xs:complexType> <xs:key name="state"> <!-- states are keyed by their code --> <xs:selector xpath=".//state"/> <xs:field xpath="code"/> </xs:key> <xs:keyref name="vehicleState" refer="state"> <!-- every vehicle refers to its state --> <xs:selector xpath=".//vehicle"/> <xs:field xpath="@state"/> </xs:keyref> <xs:key name="regKey"> <!-- vehicles are keyed by a pair of state and plate --> <xs:selector xpath=".//vehicle"/> <xs:field xpath="@state"/> <xs:field xpath="@plateNumber"/> </xs:key> <xs:keyref name="carRef" refer="regKey"> <!-- people's cars are a reference --> <xs:selector xpath=".//car"/> <xs:field xpath="@regState"/> <xs:field xpath="@regPlate"/> </xs:keyref> </xs:element> <xs:element name="person"> <xs:complexType> <xs:sequence> . . . <xs:element name="car"> <xs:complexType> <xs:attribute name="regState" type="twoLetterCode"/> <xs:attribute name="regPlate" type="xs:integer"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element>
state
element is
defined, which contains a code
child and some
vehicle
and person
children. A
vehicle
in turn has a plateNumber
attribute, which is an integer, and a state
attribute.
State's code
s are a key for them within the document.
Vehicle's plateNumber
s are a key for them within
states, and state
and plateNumber
is
asserted to be a key for vehicle
within
the document as a whole. Furthermore, a person
element
has an empty car
child, with regState
and
regPlate
attributes, which are then asserted together
to refer to vehicle
s via the carRef
constraint. The requirement that a vehicle
's
state
match its containing state
's
code
is not expressed here.ref
or
name
is present, but not both.ref
is present, then the
{identity-constraint category} of the
identity-constraint definition ·resolved· to by the ·actual
value· of the
ref
[attribute] matches the name of the
element information item.All identity-constraint definitions (see Identity-constraint Definitions (§3.11)) must satisfy the following constraint.
Selector XPath expressions | ||||||||||||||||
|
child
axis whose
abbreviated form is as given above.Lexical productions | ||||||||
|
Path in Field XPath expressions | ||||
|
child
and/or
attribute
axes whose abbreviated form is as given
above.Type Alternative components provide associations between boolean conditions (as XPath expressions) and Type Definitions. They are used in conditional type assignment.
The type alternative schema component has the following properties:
Type alternatives can be used by an Element Declaration to specify a condition ({test}) under which a particular type ({type definition}) is used as the ·governing type definition· for element information items governed by that Element Declaration. Each Element Declaration may have multiple Type Alternatives in its {type table}.
The XML representation for a type alternative schema componentType Alternative is an <alternative> element information item. The correspondences between the properties of that information item and properties of the component it corresponds to are as follows:
alternative
Element Information
Item<alternative
id = ID
test = an XPath expression
type = QName
xpathDefaultNamespace = (anyURI | (##defaultNamespace |
##targetNamespace | ##local))
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, (simpleType |
complexType)?)
</alternative>
test
[attribute] is not present, then
·absent·; otherwise an XPath Expression property record, as
described in section XML
Representation of Assertion Schema Components (§3.13.2),
with <alternative> as the "host element" and
test
as the designated expression [attribute].type
[attribute], if one is present,
otherwise the type definition corresponding to the
complexType
or simpleType
among the
[children] of the <alternative> element.type
attribute, or a complexType
child
element, or a simpleType
child element. No <alternative> element has more than one of these,
and each has at least one of these.true
and T is the {type
definition} of A. The {test} is evaluated in the
following way:
false
.
All type alternatives (see Type Alternatives (§3.12)) must satisfy the following constraints.
Comparator in Alternative XPath expressions | ||||
|
Assertion components constrain the existence and values of related elements and attributes.
<xs:assert test="@min le @max"/>↓
<xs:report test="@min gt @max"/>↓
min
attribute be less than or equal to
that of the max
attribute, and fails if that is not
the case. ↓The
<report> element shown here enforces much the same
condition, but expresses it differently; it detects an error if its
predicate is true, in this case if the value of the
min
attribute is greater than that of
max
.↓The assertion schema component has the following properties:
{category} controls how assertions impact ·assessment· of the element information item. A
{category}
with the value assert means the {test} must evaluate to true
. A {category} with the
value report means the {test} must
evaluate to false
.
↑The↑ {test} ↑property↑ specifies ↓a restricted↓↑an↑ XPath ([XPath 2.0]) expression↑. Conforming processors may implement all of [XPath 2.0] or may restrict themselves to the subset described below. Interoperability among all conforming implementations is best achieved by restricting XPath expressions to the subset. In the minimum subset↑:
↑To check
an assertion, an instance of the XPath 2.0 data model ([XDM]) is constructed, in which the
element information item being ·assessed·
is the root element, and elements and attributes are assigned types
and values according to XPath 2.0 data model construction rules,
with some exceptions. See Assertion Satisfied (§3.13.4) for details about how
the data model is constructed.↑ ↓As a
result↓↑When evaluated against
this data model instance↑, {test} evaluates to either
true
or false
(if any other value is
returned, it's converted to either true
or
false
as if by a call to the XPath fn:boolean function).
See Annotations (§3.15) for information on the role of the {annotations} property.
The XML representation for an assertion schema component is ↓either↓ an <assert> ↓or a <report>↓ element information item. The correspondences between the properties of ↓those information items↓ ↑that information item↑ and properties of the component ↓they correspond↓ ↑it corresponds↑ to are as follows:
assert
Element Information
Item<assert
id = ID
test = an XPath expression
xpathDefaultNamespace = (anyURI | (##defaultNamespace |
##targetNamespace | ##local))
{any attributes with non-schema namespace . .
.}>
Content: (annotation?)
</assert>
<report
id = ID
test = an XPath expression
{any attributes with non-schema namespace . .
.}>
Content: (annotation?)
</report>
test
as the designated expression [attribute].Assertions, like identity constraints and conditional type assignment, use [XPath 2.0] expressions. The expression itself is recorded, together with relevant parts of the context, in an XPath Expression property record. The mapping is as described below; in each case, the XPath expression itself is given in a designated attribute of the appropriate "host element".
xpathDefaultNamespace
[attribute], if present on the host
element, otherwise that of the
defaultXPathDefaultNamespace
[attribute] of the <schema>
ancestor. Then the value is the appropriate case among the
following:
##defaultNamespace
, then the appropriate
case among the following:
##targetNamespace
, then the appropriate
case among the following:
targetNamespace
[attribute] is present on the <schema>
ancestor, then its ·actual value·;##local
,
then ·absent·;<xs:complexType name="intRange"> <xs:attribute name="min" type="xs:int"/> <xs:attribute name="max" type="xs:int"/> <xs:assert test="@min le @max"/> </xs:complexType>
min
attribute must be less than or equal to that of the
max
attribute.<xs:complexType name="arrayType"> <xs:sequence> <xs:element name="entry" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="length" type="xs:int"/> <xs:assert test="@length eq fn:count(./entry)"/> </xs:complexType>
length
attribute must be the same as the number of occurrences of
entry
sub-elements.true
(see below) without raising any dynamic error or type error.↑
true
or
false
(see below) without raising any type error.true
or false
as if by a call
to the XPath fn:boolean function.false
.xsd:precisionDecimal
in the data model
instance and handled accordingly in XPath. If the XPath processor
does not support precisionDecimal, then any precisionDecimal values
in the ·post-schema-validation
infoset· should be mapped into decimal, unless the numericalValue is not a decimal number (for
example, it is positiveInfinity, negativeInfinity, or
notANumber), in which case they should be mapped to float. Whether this is done by altering the type
information in the partial ·post-schema-validation infoset·, or by altering the usual rules for
mapping from a ·post-schema-validation
infoset· to an [XDM] data model instance, or by
treating precisionDecimal as an unknown type which is coerced as
appropriate into decimal or float by the XPath processor, is
·implementation-defined· and out of scope for this
specification. As a consequence of the above variability, it is
possible that XPath expressions that perform various kinds of type
introspections will produce different results when different XPath
processors are used. If the schema author wishes to ensure
interoperable results, such introspections will need to be
avoided.All assertions (see Assertions (§3.13)) must satisfy the following constraints.
Test XPath expressions | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
child
and/or attribute
axes whose
abbreviated form is as given above.QName
in the BooleanFunction production↓ or the PBooleanFunction
production↓, then it identifies one of the
following functions defined in the [Functions and Operators] specification: fn:true, fn:false↓, op:boolean-equal↓ and fn:not.QName
in the ValueFunction production↓ or the PValueFunction↓ production,
then it identifies one of the following functions defined in the
[Functions and Operators]
specification: fn:data, fn:local-name, fn:namespace-uri, ↓op↓↑fn↑:count, fn:max and fn:min.QName
identifies a simple type definition.StringLiteral
is locally ·valid·
with respect to the simple type definition identified in the above
step, as per String Valid
(§3.16.4).Editorial Note: Priority Feedback Request
Earlier drafts of this specification defined a more restricted form of the non-terminal PredicateExpr (shown below). The XML Schema Working Group is not certain whether to retain the more comprehensive definition given above in the required minimum subset of XPath which all processors must implement, or to return to the earlier restricted form. The Working Group solicits input from implementors and users on this issue.
Alternate definition of Predicate Expressions | ||||||||||||||||||||||||||||||||||||||||
|
http://www.w3.org/2005/xpath-functions
.http://www.w3.org/2005/xpath-functions/collation/codepoint
)
defined by [Functions and
Operators].Notation declarations reconstruct XML NOTATION declarations.
<xs:notation name="jpeg" public="image/jpeg" system="viewer.exe">
The notation declaration schema component has the following properties:
As defined in ↓ Extensible Markup Language (XML) 1.1, Second Edition, Tim Bray et al., eds., W3C, 4 February 2004.↓ ↑[XML 1.1].↑
Notation declarations do not participate in ·validation· as such. They are referenced in the course of ·validating· strings as members of the NOTATION simple type. ↑An element or attribute information item with its ·governing· type definition or its ·actual member type definition· derived from the NOTATION simple type is ·valid· only if its value was among the enumerations of such simple type. As a consequence such a value is required to be the {name} of a notation declaration.↑
See Annotations (§3.15) for information on the role of the {annotations} property.
The XML representation for a notation declaration schema component is a <notation> element information item. The correspondences between the properties of that information item and properties of the component it corresponds to are as follows:
notation
Element Information
Item<notation
id = ID
name = NCName
public = token
system = anyURI
{any attributes with non-schema namespace . .
.}>
Content: (annotation?)
</notation>
targetNamespace
[attribute] of the parent
schema
element information item.<xs:notation name="jpeg" public="image/jpeg" system="viewer.exe" /> <xs:element name="picture"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:hexBinary"> <xs:attribute name="pictype"> <xs:simpleType> <xs:restriction base="xs:NOTATION"> <xs:enumeration value="jpeg"/> <xs:enumeration value="png"/> . . . </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <picture pictype="jpeg">...</picture>
All notation declarations (see Notation Declarations (§3.14)) must satisfy the following constraint.
Annotations provide for human- and machine-targeted annotations of schema components.
<xs:simpleType fn:note="special"> <xs:annotation> <xs:documentation>A type for experts only</xs:documentation> <xs:appinfo> <fn:specialHandling>checkForPrimes</fn:specialHandling> </xs:appinfo> </xs:annotation>
The annotation schema component has the following properties:
{user
information} is intended for human consumption, {application information} for automatic processing. In
both cases, provision is made for an optional URI reference to
supplement the local information, as the value of the
source
attribute of the respective element information
items. ·Validation· does not involve dereferencing
these URIs, when present. In the case of {user
information}, indication should be
given as to the identity of the (human) language used in the
contents, using the xml:lang
attribute.
{attributes} ensures that when schema authors take advantage of the provision for adding attributes from namespaces other than the ↓XML Schema↓↑XSDL↑ namespace to schema documents, they are available within the components corresponding to the element items where such attributes appear.
Annotations do not participate in ·validation· as such. Provided an annotation itself satisfies all relevant ·Schema Component Constraints· it cannot affect the ·validation· of element information items.
The name [Definition:] Annotated Component covers all the different kinds of component which may have annotations.
Annotation of schemas and schema components, with material for human or computer consumption, is provided for by allowing application information and human information at the beginning of most major schema elements, and anywhere at the top level of schemas. The XML representation for an annotation schema component is an <annotation> element information item. The correspondences between the properties of that information item and properties of the component it corresponds to are as follows:
annotation
Element Information
Item<annotation
id = ID
{any attributes with non-schema namespace . .
.}>
Content: (appinfo | documentation)*
</annotation>
<appinfo
source = anyURI
{any attributes with non-schema namespace . .
.}>
Content: ({any})*
</appinfo>
<documentation
source = anyURI
xml:lang = language
{any attributes with non-schema namespace . .
.}>
Content: ({any})*
</documentation>
The annotation component corresponding to the <annotation> element in the example above will have one element item in each of its {user information} and {application information} and one attribute item in its {attributes}.
Virtually every kind of schema component defined in this specification has an {annotations} property. When the component is described in a schema document, the mapping from the XML representation of the component to the Annotation components in the appropriate {annotations} property follows the rules described in the next paragraph.
None as such: the addition of annotations to the ·post-schema-validation infoset· is covered by the ·post-schema-validation infoset· contributions of the enclosing components.
All annotations (see Annotations (§3.15)) must satisfy the following constraint.
Simple type definitions provide for constraining character information item [children] of element and attribute information items.
<xs:simpleType name="↓fahrenheit↓↑celsius↑WaterTemp"> <xs:restriction base="xs:decimal"> <xs:fractionDigits value="2"/> <xs:minExclusive value="0.00"/> <xs:maxExclusive value="100.00"/> </xs:restriction> </xs:simpleType>
The simple type definition schema component has the following properties:
Either an Attribute Declaration, an Element Declaration, a Complex Type Definition or a Simple Type Definition.
With one exception, the {base type definition} of any
Simple Type
Definition is a Simple Type Definition. The exception is ·anySimpleType·, which has ↓·anyType·↓↑·xs:anyType
·↑, a Complex Type Definition, as its
{base type definition}.
↓Must not be empty if
{variety}
is union (unless the Simple Type Definition is that of
xsd:error
), otherwise must be ·absent·.↓ ↑Must be ·absent· if {variety} is not
union.↑
Simple types are identified by their {name} and {target
namespace}. Except for anonymous simple types (those with no
{name}), since
type definitions (i.e. both simple and complex type definitions
taken together) must be uniquely
identified within an ↓·XML Schema·↓↑·XSDL schema·↑, no simple type
definition can have the same name as another simple or complex type
definition. Simple type {name}s and {target namespace}s are provided for
reference from instances (see xsi:type (§2.6.1)), and for use in the XML
representation of schema components (specifically in <element>
and <attribute>). See References to schema
components across namespaces (<import>
)
(§4.2.4) for the use of component identifiers when
importing one schema into another.
A simple type definition with an empty specification for {final} can be used as the {base type definition} for other types derived by either of extension or restriction, or as the {item type definition} in the definition of a list, or in the {member type definitions} of a union; the explicit values extension, restriction, list and union prevent further derivations by extension (to yield a complex type) and restriction (to yield a simple type) and use in constructing lists and unions respectively.
{variety} determines whether the simple type corresponds to an atomic, list or union type as defined by [XML Schema: Datatypes].
As described in Type Definition Hierarchy (§2.2.1.1), every simple type definition is a ·restriction· of some other simple type (the {base type definition}), which is the ·simple ur-type definition· if and only if the type definition in question is ·anyAtomicType· or a list or union type definition which is not itself derived by restriction from a list or union respectively.A type definition has ·anyAtomicType· as its {base type definition} if and only if it is one of the built-in primitive datatypes. Each atomic type is ultimately a restriction of exactly one such built-in primitive datatype, which is its {primitive type definition}.
{facets} for each simple type definition are selected from those defined in [XML Schema: Datatypes]. For atomic definitions, these are restricted to those appropriate for the corresponding {primitive type definition}. Therefore, the value space and lexical space (i.e. what is ·validated· by any atomic simple type) is determined by the pair ({primitive type definition}, {facets}).
As specified in [XML Schema: Datatypes], list simple type definitions ·validate· space separated tokens, each of which conforms to a specified simple type definition, the {item type definition}. The item type specified must not itself be a list type, and must be one of the types identified in [XML Schema: Datatypes] as a suitable item type for a list simple type. In this case the {facets} apply to the list itself, and are restricted to those appropriate for lists.
A union simple type definition ·validates· strings which satisfy at least one of its {member type definitions}. As in the case of list, the {facets} apply to the union itself, and are restricted to those appropriate for unions.
The ·simple ur-type definition· or ·anyAtomicType· must not be named as the {base type definition} of any user-defined atomic simple type definitions: as they allow no constraining facets, this would be incoherent.
See Annotations (§3.15) for information on the role of the {annotations} property.
simpleType
Element Information
Item<simpleType
final = (#all | List of (list |
union | restriction |
extension))
id = ID
name = NCName
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, (restriction
| list |
union))
</simpleType>
<restriction
base = QName
id = ID
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, (simpleType?,
(minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | maxScale | minScale | length | minLength | maxLength | enumeration | whiteSpace | pattern)*))
</restriction>
<list
id = ID
itemType = QName
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, simpleType?)
</list>
<union
id = ID
memberTypes = List of QName
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, simpleType*)
</union>
name
[attribute] if present on the <simpleType> element, otherwise ·absent·.targetNamespace
[attribute] of the ↓parent↓↑ancestor↑ <schema> element information
item if present, otherwise ·absent·.base
[attribute] of <restriction>, if present, otherwise the type
definition corresponding to the <simpleType> among the
[children] of <restriction>.{
restriction, extension,
list, union}
, determined
as follows. [Definition:] Let FS be the
·actual value· of the final
[attribute], if present, otherwise the
·actual value· of the finalDefault
[attribute] of the ancestor
schema
element, if present, otherwise the empty
string. Then the property value is the appropriate
case among the following:
itemType
[attribute] of <list>, or (b), corresponding
to the <simpleType> among the [children] of <list>, whichever is present.
itemType
[attribute] or a <simpleType> [child], but not both.memberTypes
[attribute] of <union>, if any, and (b)
corresponding to the <simpleType>s among the [children] of <union>, if any, in order.
memberTypes
[attribute] or one or more <simpleType> [children], or both.Editorial Note: Priority Feedback Request
Note that the rule just given allows unions to be members of other unions. This is a change from version 1.0 of this specification, which prohibited unions in {member type definitions} and replaced any reference to a union M, in the XML declaration of a second union U, with the members of M. This had the unintended consequence that that if M had facets they were lost, and U erroneously accepted values not accepted by M. In order to correct this error, this version of this specification allows unions in {member type definitions} and removes the wording which replaced references to unions with their members. The XML Schema Working Group solicits input from implementors and users of this specification as to whether this change is an acceptable way of repairing the problem in version 1.0 of this specification, or whether it would be preferable to allow unions as members of other unions only if they have an empty {facets} property. If such a change would make this specification more (or less) attractive to users or implementors, please let us know.
base
[attribute] or a <simpleType> among its [children], but not both.itemType
[attribute] or a <simpleType> among its [children], but not both.memberTypes
[attribute] or it has at least one
simpleType
[child].memberTypes
[attribute] which ↓resolve↓↑·resolve·↑ to simple types
with {variety} union which include among their
transitive membership the component corresponding
to the <simpleType>.All simple type definitions must satisfy both the following constraints.
[Definition:] A simple type definition T is a valid restriction of its {base type definition} if and only if T satisfies constraint Derivation Valid (Restriction, Simple) (§3.16.6).
The following constraint defines relations appealed to elsewhere in this specification.
Editorial Note: Priority Feedback Request
The requirement that B and any unions intervening between B and D have no constraining facets is introduced in version 1.1 of this specification. Version 1.0 had no such restriction and thus allowed members of any union to be treated for some purposes as if derived from the union. The rules of 1.0 also did not ensure that values accepted by the member would also be datatype-valid with respect to the union, thus providing an unintended loophole which allowed values to be accepted which ought to have been invalid. The XML Schema Working Group solicits input from implementors and users of this specification as to whether the additional constraint introduced here is an acceptable way of achieving the goal of closing the loophole, or whether it is important that the loophole be closed without excluding facet-based restrictions of unions from the use of clause 2.2.4.
xsd:anySimpleType
The Simple Type Definition of anySimpleType is present in every schema. It has the following properties:
anySimpleType
'http://www.w3.org/2001/XMLSchema
'The definition of ·anySimpleType· is the root of the simple type
definition hierarchy, and as such mediates between the other simple
type definitions, which all eventually trace back to it via their
{base type definition} properties, and ↓·anyType·↓↑·xs:anyType
·↑, which is
its {base type definition}.
xsd:anyAtomicType
The Simple Type Definition of anyAtomicType is present in every schema. It has the following properties:
anyAtomicType
'http://www.w3.org/2001/XMLSchema
'xsd:error
A Simple Type
Definition for ·xsd:error
· is present in every schema by
definition. It has the following properties:
error
'http://www.w3.org/2001/XMLSchema
'xsd:error
has no valid instances (i.e. it has an empty
value space and an empty lexical space). This is a natural
consequence of its construction: a value is a value of a union type
if and only if it is a value of at least one member of the {member
type definitions} of the union. Since xsd:error
has no member type definitions, there can be no values which are
values of at least one of its member types. And since the value
space is empty, the lexical space is also empty.The type
xsd:error
is expected to be used mostly in conditional
type assignment. Whenever it serves as the ·governing· type definition for an attribute or
element information item, that item will be invalid.Simple type definitions corresponding to all the built-in primitive datatypes, namely string, boolean, float, double, decimal, precisionDecimal, dateTime, duration, time, date, gMonth, gMonthDay, gDay, gYear, gYearMonth, hexBinary, base64Binary, anyURI, QName and NOTATION (see the Primitive Datatypes section of [XML Schema: Datatypes]) are present by definition in every schema.as follows:
http://www.w3.org/2001/XMLSchema
'[as appropriate]
Similarly, simple type definitions corresponding to all the other built-in datatypes (see the Other Built-in Datatypes section of [XML Schema: Datatypes]) are present by definition in every schema, with properties as specified in [XML Schema: Datatypes] and as represented in XML in Illustrative XML representations for the built-in ordinary type definitions.
http://www.w3.org/2001/XMLSchema
'A schema consists of a set of schema components.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.com/example"> . . . </xs:schema>
At the abstract level, the schema itself is just a container for its components.
A schema is represented in XML by one or more ·schema documents·, that is, one or more <schema> element information items. A ·schema document· contains representations for a collection of schema components, e.g. type definitions and element declarations, which have a common {target namespace}. A ·schema document· which has one or more <import> element information items corresponds to a schema with components with more than one {target namespace}, see Import Constraints and Semantics (§4.2.4.2).
schema
Element Information
Item<schema
attributeFormDefault = (qualified |
unqualified) : unqualified
blockDefault = (#all | List of
(extension | restriction |
substitution)) : ''
defaultAttributes = QName
defaultXPathDefaultNamespace = (anyURI | (##defaultNamespace |
##targetNamespace | ##local))
: ##local
elementFormDefault = (qualified |
unqualified) : unqualified
finalDefault = (#all | List of
(extension | restriction | list |
union)) : ''
id = ID
targetNamespace = anyURI
version = token
xml:lang = language
{any attributes with non-schema namespace . .
.}>
Content: ((include | import | redefine |
annotation)*, (defaultOpenContent, annotation*)?, (((simpleType | complexType
| group |
attributeGroup) | element | attribute | notation),
annotation*)*)
</schema>
<defaultOpenContent
appliesToEmpty = boolean : false
id = ID
mode = (interleave |
suffix) : interleave
{any attributes with non-schema namespace . .
.}>
Content: (annotation?, any)
</defaultOpenContent>
<include>
)
(§4.2.2) and References to schema components across namespaces
(<import>
) (§4.2.4).<include>
)
(§4.2.2) and References to schema components across namespaces
(<import>
) (§4.2.4).<include>
)
(§4.2.2) and References to schema components across namespaces
(<import>
) (§4.2.4).<include>
)
(§4.2.2) and References to schema components across namespaces
(<import>
) (§4.2.4).<include>
)
(§4.2.2) and References to schema components across namespaces
(<import>
) (§4.2.4).<include>
)
(§4.2.2) and References to schema components across namespaces
(<import>
) (§4.2.4).<include>
) (§4.2.2) and References to schema
components across namespaces (<import>
)
(§4.2.4).Note that none of the attribute information items displayed
above correspond directly to properties of schemas. The
blockDefault
, finalDefault
,
attributeFormDefault
, elementFormDefault
and targetNamespace
attributes are appealed to in the
sub-sections above, as they provide global information applicable
to many representation/component correspondences. The other
attributes (id
and version
) are for user
convenience, and this specification defines no semantics for
them.
The definition of the schema abstract data model in ↓XML
Schema↓↑XSDL↑
Abstract Data Model (§2.2) makes clear that most
components have a {target namespace}.
Most components corresponding to representations within a given
<schema> element information item will have a
{target namespace} which corresponds
to the targetNamespace
attribute.
Since the empty string is not a legal namespace name, supplying
an empty string for targetNamespace
is incoherent, and
is not the same as not specifying it at all. The
appropriate form of schema document corresponding to a ·schema· whose components have no {target
namespace} is one which has no targetNamespace
attribute specified at all.
Although the example schema at the beginning of this section might be a complete XML document, <schema> need not be the document element, but can appear within other documents. Indeed there is no requirement that a schema correspond to a (text) document at all: it could correspond to an element information item constructed 'by hand', for instance via a DOM-conformant API.
Aside from <include> and <import>, which do not correspond directly to any schema component at all, each of the element information items which ↓may↓↑may↑ appear in the content of <schema> corresponds to a schema component, and all except <annotation> are named. The sections below present each such item in turn, setting out the components to which it ↓may↓ correspond↑s↑.
Reference to schema components from a schema document is managed
in a uniform way, whether the component corresponds to an element
information item from the same schema document or is imported
(References to
schema components across namespaces (<import>
)
(§4.2.4)) from an external schema (which ↓may↓↑may↑, but need not, correspond
to an actual schema document). The form of all such references is a
·QName·.
[Definition:] A QName is a name with an optional namespace qualification, as defined in [XML-Namespaces 1.1]. When used in connection with the XML representation of schema components or references to them, this refers to the simple type QName as defined in [XML Schema: Datatypes].
[Definition:] An NCName is a name with no colon, as defined in [XML-Namespaces 1.1]. When used in connection with the XML representation of schema components in this specification, this refers to the simple type NCName as defined in [XML Schema: Datatypes].
In each of the XML representation expositions in the following
sections, an attribute is shown as having type QName
if and only if it is interpreted as referencing a schema
component.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns="http://www.example.com" targetNamespace="http://www.example.com"> . . . <xs:element name="elem1" type="Address"/> <xs:element name="elem2" type="xhtml:blockquote"/> <xs:attribute name="attr1" type="xsl:quantity"/> . . . </xs:schema>
<import>
)
(§4.2.4) for a discussion of importing.The names of schema components such as type definitions and element declarations are not of type ID: they are not unique within a schema, just within a symbol space. This means that simple fragment identifiers will not always work to reference schema components from outside the context of schema documents.
There is currently no provision in the definition of the
interpretation of fragment identifiers for the
text/xml
MIME type, which is the MIME type for
schemas, for referencing schema components as such. However,
[XPointer] provides a
mechanism which maps well onto the notion of symbol spaces as it is
reflected in the XML representation of schema components. A
fragment identifier of the form
#xpointer(xs:schema/xs:element[@name="person"])
will
uniquely identify the representation of a top-level element
declaration with name person
, and similar fragment
identifiers can obviously be constructed for the other global
symbol spaces.
Short-form fragment identifiers ↓may↓↑may↑ also be used in some
cases, that is when a DTD or ↓XML
Schema↓↑XSDL
schema↑ is available for the schema in question,
and the provision of an id
attribute for the
representations of all primary and secondary schema components,
which is of type ID, has been exploited.
It is a matter for applications to specify whether they interpret document-level references of either of the above varieties as being to the relevant element information item (i.e. without special recognition of the relation of schema documents to schema components) or as being to the corresponding schema component.
defaultAttributes
[attribute] is present, its ·actual value· ·resolves·
to an Attribute Group
Definition.↓[Definition:] Whenever the word resolve in any form is used in this chapter in connection with a ·QName· in a schema document, the following definition QName resolution (Schema Document) (§3.17.3) must be understood↓↑[Definition:] A ·QName· in a schema document resolves to a component in a schema if and only if in the context of that schema the QName and the component together satisfy the rule QName resolution (Schema Document) (§3.17.3). A ·QName· in an input document, or a pair consisting of a local name and a namespace name, resolves to a component in a schema if and only if in the context of that schema the QName (or the name + namespace pair) and the component together satisfy the rule QName resolution (Instance) (§3.17.4)↑ ↓:↓↑.↑
targetNamespace
[attribute].namespace
[attribute].targetNamespace
[attribute] of the <schema>
element information item of the schema document containing the
·QName·.namespace
[attribute] of some <import>
element information item contained in the <schema> element information
item of that schema document.http://www.w3.org/2001/XMLSchema
.http://www.w3.org/2001/XMLSchema-instance
.As the discussion above at Schema Component Details (§3) makes clear, at the level of schema components and ·validation·, reference to components by name is normally not involved. In a few cases, however, qualified names appearing in information items being ·validated· must be resolved to schema components by such lookup. The following constraint is appealed to in these cases.
targetNamespace
matches the sibling [schema
namespace] property above (or whose
targetNamespace
was ·absent· but that contributed components to that
namespace by being <include>d by a schema document with that
targetNamespace
as per Assembling a schema for a single target namespace from
multiple schema definition documents (<include>
)
(§4.2.2)):
All schemas (see Schemas as a Whole (§3.17)) must satisfy the following constraint.
This chapter defines the mechanisms by which this specification establishes the necessary precondition for ·assessment·, namely access to one or more schemas. This chapter also sets out in detail the relationship between schemas and namespaces, as well as mechanisms for modularization of schemas, including provision for incorporating definitions and declarations from one schema in another, possibly with modifications.
Conformance (§2.4) describes three levels of conformance for schema processors, and Schemas and Schema-validity Assessment (§5) provides a formal definition of ·assessment·. This section sets out in detail the 3-layer architecture implied by the three conformance levels. The layers are:
Layer 1 specifies the manner in which a schema composed of schema components can be applied to in the ·assessment· of an instance element information item. Layer 2 specifies the use of <schema> elements in XML documents as the standard XML representation for schema information in a broad range of computer systems and execution environments. To support interoperation over the World Wide Web in particular, layer 3 provides a set of conventions for schema reference on the Web. Additional details on each of the three layers is provided in the sections below.
The fundamental purpose of the ·assessment· core is to define ·assessment· for a single element information item and its descendants with respect to a complex type definition. All processors are required to implement this core predicate in a manner which conforms exactly to this specification.
·↓a↓↑A↑ssessment· is defined with reference to an ↓·XML Schema·↓↑·XSDL schema·↑ (note not a ·schema document·) which consists of (at a minimum) the set of schema components (definitions and declarations) required for that ·assessment·. This is not a circular definition, but rather a post facto observation: no element information item can be fully assessed unless all the components required by any aspect of its (potentially recursive) ·assessment· are present in the schema.
As specified above, each schema component is associated directly or indirectly with a target namespace, or explicitly with no namespace. In the case of multi-namespace documents, components for more than one target namespace will co-exist in a schema.
Processors have the option to assemble (and perhaps to optimize or pre-compile) the entire schema prior to the start of an ·assessment· episode, or to gather the schema lazily as individual components are required. In all cases it is required that:
The obligation of a schema-aware processor as far as the ·assessment· core is concerned is to implement one or more of the options for ·assessment· given below in Assessing Schema-Validity (§5.2). Neither the choice of element information item for that ·assessment·, nor which of the means of initiating ·assessment· are used, is within the scope of this specification.
Although ·assessment· is defined recursively, it is also intended to be implementable in streaming processors. Such processors may choose to incrementally assemble the schema during processing in response, for example, to encountering new namespaces. The implication of the invariants expressed above is that such incremental assembly must result in an ·assessment· outcome that is the same as would be given if ·assessment· was undertaken again with the final, fully assembled schema.
The sub-sections of Schema Component Details (§3) define an XML representation for type definitions and element declarations and so on, specifying their target namespace and collecting them into schema documents. The two following sections relate to assembling a complete schema for ·assessment· from multiple sources. They should not be understood as a form of text substitution, but rather as providing mechanisms for distributed definition of schema components, with appropriate schema-specific semantics.
Whenever a conforming XSDL processor reads a ·schema document· in order to include the components defined in it in a schema, it first performs on the schema document the pre-processing described in this section.
Every element in the ·schema
document· is examined to see
whether the attributes vc:minVersion
or
vc:maxVersion
appear among its [attribute]s.
Where they appear, these attributes are treated as if declared
with type xsd:decimal
, and their ·actual values· are compared to a decimal value
representing the version of XSDL supported by the processor (here
represented as a variable V). For processors conforming
to this version of this specification, the value of V is
1.1.
If V is less than the value of
vc:minVersion
, or if V is greater than the
value of vc:maxVersion
, then the element on which the
attribute appears is to be ignored, along with all its attributes
and descendants.
The pre-processing of a schema document S1 results in
a second schema document S2, identical to S1
except that all elements and attributes in S1 which are
to be ignored are absent from S2. If the
<schema>
element information item in
S1 is to be ignored, then S2 is identical to
S1 except that any attributes other than
targetNamespace
, vc:minVersion
or
vc:maxVersion
are removed from its [attributes], and its [children] is the empty sequence. It is
S2, not S1, which is required to conform to
this specification.
Except where conditional-inclusion pre-processing is explicitly mentioned, references to ·schema documents· elsewhere in this specification invariably refer to the result of the pre-processing step described here, not to its input, which need not, and in the general case will not, always conform to the rules for schema documents laid out in this specification.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning"> <xsd:element name="e" vc:minVersion="3.2"> <!--* declaration suitable for 3.2 * and later processors *--> </xsd:element> <xsd:element name="e" vc:minVersion="1.1" vc:maxVersion="3.1"> <!--* declaration suitable for processors * supporting versions 1.1 through 3.1 *--> </xsd:element> ... </xsd:schema>
e
and
thus violates clause 2 of
constraint Schema
Properties Correct (§3.17.6), the pre-processing step
described in this section filters out the first element
declaration, making it possible for the resulting schema document
to be valid and to conform to this specification.vc:minVersion
or vc:maxVersion
appears on
an element information item in a ·schema
document·, its ·normalized value· must be
locally ·valid·
with respect to xsd:decimal
as per String Valid
(§3.16.4).<include>
)Schema components for a single target namespace can be assembled from several ·schema documents·, that is several <schema> element information items:
include
Element Information
Item<include
id = ID
schemaLocation = anyURI
{any attributes with non-schema namespace . .
.}>
Content: (annotation?)
</include>
A <schema> information item may contain any number of <include>
elements. Their schemaLocation
attributes, consisting
of a URI reference, identify other ·schema
documents·, that is <schema>
information items.
The ↓·XML Schema·↓↑·XSDL schema·↑ corresponding to
<schema> contains not only the components
corresponding to its definition and declaration [children], but also all the components
of all the ↓·XML Schemas·↓↑·XSDL schemas·↑ corresponding to
any <include>d schema documents. Such included schema
documents must either (a) have the
same targetNamespace
as the <include>ing schema document,
or (b) no targetNamespace
at all, in which case the
<include>d schema document is converted to the
<include>ing schema document's
targetNamespace
.
schemaLocation
[attribute] successfully resolves
one of the following must be
true:
application/xml
or
text/xml
with an XML declaration for preference, but
this is not required), which in turn corresponds to a <schema>
element information item in a well-formed information
set↓, which in
turn corresponds to a valid schema↓.targetNamespace
[attribute], and its ·actual value· is identical to the ·actual value· of the targetNamespace
[attribute] of ↓SII’↓↑D1↑ (which must have such an [attribute]).targetNamespace
[attribute] of SII’ is
used. In particular, it replaces ·absent· in the following
places:↓
targetNamespace
[attribute] whose value is the same as
the ·actual value· of the targetNamespace
[attribute] of D1;
D2′ corresponds to a valid schema (call it
S2).targetNamespace
[attribute], but neither B nor
C does, then the effect is as if A included B'
and B' included C', where B' and C' are
identical to B and C respectively, except that they
both have a targetNamespace
[attribute] the same as
A's.code
was
qualified) nested within definitions;##other
or ##local
in a wildcard, because
the result of the inclusion will not be the same as if the schema
document being included had a targetNamespace
[attribute] that is the same as that of
the including schema document.schemaLocation
[attribute] to fail to resolve
↓it
all↓↑at all↑, in which case no
corresponding inclusion is performed. It is an error for
it to resolve but the rest of clause 1 above to fail to be
satisfied. Failure to resolve ↓may
well↓↑is likely to↑ cause less than
complete ·assessment· outcomes, of course.As discussed in
Missing Sub-components
(§5.3), ·QName·s in XML representations ↓may↓↑will
sometimes↑ fail to ↓·resolve·↓↑·resolve·↑, rendering
components incomplete and unusable because of missing
subcomponents. During schema construction, implementations
must retain ·QName·
values for such references, in case an appropriately-named
component becomes available to discharge the reference by the time
it is actually needed. ·Absent· target ·namespace
name·s of such as-yet
unresolved reference ·QName·s in <include>d components must also be converted if clause 3.2 is satisfied.<redefine>
)In order to provide some support for evolution and versioning, it is possible to incorporate components corresponding to a schema document with modifications. The modifications have a pervasive impact, that is, only the redefined components are used, even when referenced from other incorporated components, whether redefined themselves or not.
redefine
Element Information
Item<redefine
id = ID
schemaLocation = anyURI
{any attributes with non-schema namespace . .
.}>
Content: (annotation | (simpleType |
complexType | group | attributeGroup))*
</redefine>
A <schema> information item may contain any number of <redefine> elements. Their
schemaLocation
attributes, consisting of a URI
reference, identify other ·schema
documents·, that is <schema>
information items.
The ↓·XML Schema·↓↑·XSDL schema·↑ corresponding to
<schema> contains not only the components
corresponding to its definition and declaration [children], but also all the components
of all the ↓·XML Schemas·↓↑·XSDL schemas·↑ corresponding to
any <redefine>d schema documents. Such schema
documents must either (a) have the
same targetNamespace
as the <redefine>ing schema document, or (b) no
targetNamespace
at all, in which case the <redefine>d schema document is converted to the
<redefine>ing schema document's
targetNamespace
.
This mechanism is intended to provide a declarative and modular approach to schema modification, with functionality no different except in scope from what would be achieved by wholesale text copying and redefinition by editing. In particular redefining a type is not guaranteed to be side-effect free: it ↓may↓↑can↑ have unexpected impacts on other type definitions which are based on the redefined one, even to the extent that some such definitions become ill-formed.
v1.xsd: <xs:complexType name="personName"> <xs:sequence> <xs:element name="title" minOccurs="0"/> <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:element name="addressee" type="personName"/> v2.xsd: <xs:redefine schemaLocation="v1.xsd"> <xs:complexType name="personName"> <xs:complexContent> <xs:extension base="personName"> <xs:sequence> <xs:element name="generation" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:redefine> <xs:element name="author" type="personName"/>
v2.xsd
has everything specified by
v1.xsd
, with the personName
type
redefined, as well as everything it specifies itself. According to
this schema, elements constrained by the personName
type ↓may↓↑may↑ end with a
generation
element. This includes not only the
author
element, but also the addressee
element.schemaLocation
[attribute] must successfully resolve.schemaLocation
[attribute] successfully resolves
one of the following must be
true:
targetNamespace
[attribute], and its ·actual value· is identical to the ·actual value· of the targetNamespace
[attribute] of ↓SII’↓↑D1↑ (which must have such an [attribute]).targetNamespace
[attribute] of SII’ is
used (see clause 3.2 in
Inclusion Constraints and
Semantics (§4.2.2) for details).↓
targetNamespace
[attribute] whose value is the same as
the ·actual value· of the targetNamespace
[attribute] of D1;
D2′ corresponds to a valid schema (call it
S2).restriction
or extension
among its
grand-[children] the ·actual value· of whose base
[attribute] must be the same as the ·actual
value· of its own
name
attribute plus target namespace;ref
[attribute] is the same as the ·actual value· of its own name
attribute
plus target namespace, then all of the following are
true:
minOccurs
and maxOccurs
[attribute] is 1
(or
·absent·).name
attribute plus target namespace successfully
↓·resolves·↓↑·resolves·↑ to a model group
definition in ↓I↓↑S2↑.ref
[attribute] is the same as the ·actual value· of its own name
attribute
plus target namespace, then it has exactly one such
group.name
attribute plus target namespace successfully
↓·resolves·↓↑·resolves·↑ to an attribute
group definition in ↓I↓↑S2↑.name
in the <redefine>d schema document, as defined in
Schema Component Details
(§3), except that its {name}
is ·absent· and its {context} is the redefining component, as defined
in clause 1.2 below;ref
[attribute] whose ·actual value· is the same as the item's
name
plus target namespace is ↓resolved↓↑·resolved·↑, a component which
corresponds to the top-level definition item of that name and the
appropriate kind in ↓I↓↑S2↑ is used.<import>
)As described in ↓XML
Schema↓↑XSDL↑
Abstract Data Model (§2.2), every top-level schema
component is associated with a target namespace (or, explicitly,
with none). Furthermore, each schema document carries on its
<schema> element at most one
targetNamespace
attribute associating that document
with a target namespace. This section sets out the syntax and
mechanisms by which references ↓may↓↑may↑ be made from within a
·schema document· to components not within that
document's target namespace. Also included within the same syntax
is an optional facility for suggesting the URI of a ·schema document· containing definitions and declarations
for components from the foreign target namespace.
schemaLocation
attribute. Although the function of
<import> is unchanged in ↓XML Schema Version
1.1↓↑this version↑, the presentation
below has been reorganized to clarify the two separate purposes
served by <import>.import
Element Information
Item<import
id = ID
namespace = anyURI
schemaLocation = anyURI
{any attributes with non-schema namespace . .
.}>
Content: (annotation?)
</import>
The <import> element information item identifies
namespaces used in external references, i.e. those whose ·QName·
identifies them as coming from a different namespace (or none) than
the enclosing schema document's targetNamespace
.
At least two conditions must be satisfied for a reference to be
made to a foreign component: there must be not only a means of
addressing such foreign components but also a signal to
schema-aware processors that a schema document contains such
references. Thus, the <import> element information item identifies
namespaces used in external component references, i.e.
those whose ·QName· identifies them as coming from a
namespace different from that of the enclosing schema document's
targetNamespace
. By contrast, a namespace used for
other purposes in a schema document need not be imported. There is
no need, for example, to import the namespace of a vocabulary such
as HTML for use in schema <documentation> elements, unless
that same namespace is also used as the target namespace for
component references.
The ·actual value· of the namespace
[attribute] indicates that the
containing schema document may contain
qualified references to schema components in that namespace (via
one or more prefixes declared with namespace declarations in the
normal way). If that attribute is absent, then the import allows
unqualified reference to components with no target namespace. Note
that components to be imported need not be in the form of a
·schema document· and need not in particular be declared
in the particular schema document identified by a
schemaLocation
attribute; the processor is free to
access or construct components using means of its own choosing,
whether or not a schemaLocation
hint is provided.
html:p
. If there were no component
reference, then the import would be unnecessary; no import is
needed for use of a namespace in a <documentation> or similar
schema document element or attribute name.<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:html="http://www.w3.org/1999/xhtml" targetNamespace="uri:mywork" xmlns:my="uri:mywork"> <import namespace="http://www.w3.org/1999/xhtml"/> <annotation> <documentation> <html:p>[Some documentation for my schema]</html:p> </documentation> </annotation> . . . <complexType name="myType"> <sequence> <element ref="html:p" minOccurs="0"/> </sequence> . . . </complexType> <element name="myElt" type="my:myType"/> </schema>
The ·actual value· of the
schemaLocation
attribute, if present on an <import>
element, gives a hint as to where a serialization of a ·schema document· with declarations and definitions for
the imported namespace (or none) ↓may↓↑can
possibly↑ be found. When no
schemaLocation
[attribute] is present, the schema
author is leaving the identification of that schema to the
instance, application or user, via the mechanisms described below
in Layer 3: Schema
Document Access and Web-interoperability (§4.3). When a
schemaLocation
attribute is present, it must contain a single URI reference which the
schema author warrants will resolve to a serialization of a
·schema document· containing component(s) in the <import>ed
namespace.
Conformance profiles may further restrict the use of the
schemaLocation
attribute. For example, one profile
might mandate that the hint be honored by the schema software,
perhaps calling for a processor-dependent error should the URI fail
to resolve, or mandating that the hint agree with some expected URI
value; another profile might mandate that the hint not be honored,
etc.
namespace
and schemaLocation
[attribute] are optional, a bare
<import/>
information item is allowed. This
simply allows unqualified reference to foreign components with no
target namespace without giving any hints as to where to find
them.namespace
[attribute] is present, then its
·actual value· does not match the ·actual value· of the enclosing <schema>'s
targetNamespace
[attribute].namespace
[attribute] is not present, then
the enclosing <schema> has a targetNamespace
[attribute]schemaLocation
and
namespace
[attributes] one of the
following must be true:
namespace
[attribute], then its ·actual value· is identical to the ·actual value· of the targetNamespace
[attribute] of ↓SII↓↑D2↑.schemaLocation
[attribute] is only a hint, it is open
to applications to ignore all but the first <import>
for a given namespace, regardless of the ·actual
value· of
schemaLocation
, but such a strategy risks missing
useful information when new schemaLocation
s are
offered.Layers 1 and 2 provide a framework for ·assessment· and XML definition of schemas in a broad variety of environments. Over time, it is possible that a range of standards and conventions ↓may well↓↑will↑ evolve to support interoperability of ↓XML Schema↓↑XSDL↑ implementations on the World Wide Web. Layer 3 defines the minimum level of function required of all conformant processors operating on the Web: it is intended that, over time, future standards (e.g. XML Packages) for interoperability on the Web and in other environments can be introduced without the need to republish this specification.
For interoperability, serialized ·schema documents·, like all other Web resources, should be identified by URI and retrieved using the standard mechanisms of the Web (e.g. http, https, etc.) Such documents on the Web must be part of XML documents (see clause 1.1), and are represented in the standard XML schema definition form described by layer 2 (that is as <schema> element information items).
Accept
header of application/xml, text/xml;
q=0.9, */*
is perhaps a reasonable starting point.As described in Layer 1: Summary of the Schema-validity Assessment Core (§4.1), processors are responsible for providing the schema components (definitions and declarations) needed for ·assessment·. This section introduces a set of normative conventions to facilitate interoperability for instance and schema documents retrieved and processed from the Web.
targetNamespace
is identical to the namespace
name, if any, of the element information item on which ·assessment· is undertaken.The composition of the complete schema for use in ·assessment· is discussed in Layer 2: Schema Documents, Namespaces and Composition (§4.2) above. The means used to locate appropriate schema document(s) are processor and application dependent, subject to the following requirements:
schemaLocation
and
noNamespaceSchemaLocation
[attributes] (in the ↓XML
Schema↓↑XSDL↑
instance namespace, that is,
http://www.w3.org/2001/XMLSchema-instance
) (hereafter
xsi:schemaLocation
and
xsi:noNamespaceSchemaLocation
) are provided. The first
records the author's warrant with pairs of URI references (one for
the namespace name, and one for a hint as to the location of a
schema document defining names for that namespace name). The second
similarly provides a URI reference as a hint as to the location of
a schema document with no targetNamespace
[attribute].Unless directed otherwise,
for example by the invoking application or by command line option,
processors should attempt to
dereference each schema document location URI in the ·actual value· of such xsi:schemaLocation
and xsi:noNamespaceSchemaLocation
[attributes], see details below.xsi:schemaLocation
and
xsi:noNamespaceSchemaLocation
[attributes] can occur on any element.
However, it is an error if such an attribute occurs after
the first appearance of an element or attribute information item
within an element information item initially ·validated· whose [namespace name] it
addresses.↓ According to the rules of Layer 1: Summary of the Schema-validity
Assessment Core (§4.1), the corresponding schema
may be lazily assembled, but is
otherwise stable throughout ·assessment·. Although schema location attributes
can occur on any element, and can be processed incrementally as
discovered, their effect is essentially global to the ·assessment·. Definitions and declarations remain in
effect beyond the scope of the element on which the binding is
declared.<stylesheet xmlns="http://www.w3.org/1999/XSL/Transform" xmlns:html="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/1999/XSL/Transform http://www.w3.org/1999/XSL/Transform.xsd http://www.w3.org/1999/xhtml http://www.w3.org/1999/xhtml.xsd">
schemaLocation
can, but need not be identical to those
actually qualifying the element within whose start tag it is found
or its other attributes. For example, as above, all schema location
information can be declared on the document element of a document,
if desired, regardless of where the namespaces are actually
used.Improved or alternative conventions for Web interoperability can be standardized in the future without reopening this specification. For example, the W3C is currently considering initiatives to standardize the packaging of resources relating to particular documents and/or namespaces: this would be an addition to the mechanisms described here for layer 3. This architecture also facilitates innovation at layer 2: for example, it would be possible in the future to define an additional standard for the representation of schema components which allowed e.g. type definitions to be specified piece by piece, rather than all at once.
The architecture of schema-aware processing allows for a rich characterization of XML documents: schema validity is not a binary predicate.
This specification distinguishes between errors in schema construction and structure, on the one hand, and schema validation outcomes, on the other.
Before ·assessment· can be attempted, a schema is required.
Special-purpose applications are free to determine a schema for use
in ·assessment· by whatever means are appropriate, but
general purpose processors should
implement and document a strategy for assembling a schema,
exploiting at least some if not all of the non-hard-coded methods
outlined in Terminology of
schema construction (§D.2), starting with the namespaces
declared in the document whose ·assessment· is being undertaken, and the ·actual value·s of the xsi:schemaLocation
and xsi:noNamespaceSchemaLocation
[attributes] thereof, if any, along
with any other information about schema identity or schema document
location provided by users in application-specific ways, if
any.
It is an error if a schema and all the components which are the value of any of its properties, recursively, fail to satisfy all the relevant Constraints on Schemas set out in the last section of each of the subsections of Schema Component Details (§3).
The three cases described above are the only types of error which this specification defines. With respect to the processes of the checking of schema structure and the construction of schemas corresponding to schema documents, this specification imposes no restrictions on processors ↓after an error is detected. However ·assessment· with respect to schema-like entities which do not satisfy all the above conditions is incoherent. Accordingly, conformant processors must not attempt to undertake ·assessment· using such non-schemas.↓↑ in the presence of errors. However, any operations performed in the presence of errors are outside the scope of this specification and are not ·schema-validity assessment· as that term is defined here.↑
xsi:type
), then ·strict
validation· is performed. If
they do not identify any declaration or definition, then ·lax validation· is performed.
xsi:type
), then ·strict· validation is performed; if they do not
identify any declaration or definition, then no schema-validity
assessment is performed.
[Definition:] The element or attribute information item at which ·assessment· begins is called the validation root.
The outcome of schema-validity assessment will be manifest in the [validation attempted] and [validity] properties on the ·validation root·, and if the ·validation root· is an element information item then also on its [attributes] and [children], recursively, as defined by Assessment Outcome (Element) (§3.3.5) and Assessment Outcome (Attribute) (§3.2.5). There is no requirement that input which is not schema-valid be rejected by an application. It is up to applications to decide what constitutes a successful outcome of validation.
Note that every element and attribute information item participating in the ·assessment· will also have a [validation context] property which refers back to the ·validation root·. .
At the beginning of Schema Component Details (§3), attention is drawn to the fact that most kinds of schema components have properties which are described therein as having other components, or sets of other components, as values, but that when components are constructed on the basis of their correspondence with element information items in schema documents, such properties usually correspond to QNames, and the ·resolution· of such QNames ↓may↓↑can↑ fail, resulting in one or more values of or containing ·absent· where a component is mandated.
Because of the value specification for [validation attempted] in Assessment Outcome (Element) (§3.3.5), if this situation ever arises, the document as a whole cannot show a [validation attempted] of full.
Schema-aware processors are responsible for processing XML documents, schemas and schema documents, as appropriate given the level of conformance (as defined in Conformance (§2.4)) they support, consistently with the conditions set out above.
The XML representation of the schema for schema documents is presented here as a normative part of the specification, and as an illustrative example of how the ↓XML Schema language↓↑XML Schema Definition Language↑ can define itself using its own constructs. The names of ↓XML Schema language↓↑XSDL↑ types, elements, attributes and groups defined here are evocative of their purpose, but are occasionally verbose.
There is some annotation in comments, but a fuller annotation will require the use of embedded documentation facilities or a hyperlinked external annotation for which tools are not yet readily available.
Like any other XML document, schema documents may carry XML and
document type declarations. An XML declaration and a document type
declaration are provided here for convenience. Since this schema
document describes the ↓XML Schema↓↑XSDL↑
language, the targetNamespace
attribute on the
schema
element refers to the ↓XML
Schema↓↑XSDL↑
namespace itself.
Schema documents conforming to this specification may be in XML 1.0 or XML 1.1. Conforming implementations may accept input in XML 1.0 or XML 1.1 or both. See Dependencies on Other Specifications (§1.4).
<!DOCTYPE xs:schema PUBLIC "-//W3C//DTD XMLSCHEMA 200102//EN" "XMLSchema.dtd" [ <!-- provide ID type information even for parsers which only read the internal subset --> <!ATTLIST xs:schema id ID #IMPLIED> <!ATTLIST xs:complexType id ID #IMPLIED> <!ATTLIST xs:complexContent id ID #IMPLIED> <!ATTLIST xs:simpleContent id ID #IMPLIED> <!ATTLIST xs:extension id ID #IMPLIED> <!ATTLIST xs:element id ID #IMPLIED> <!ATTLIST xs:group id ID #IMPLIED> <!ATTLIST xs:all id ID #IMPLIED> <!ATTLIST xs:choice id ID #IMPLIED> <!ATTLIST xs:sequence id ID #IMPLIED> <!ATTLIST xs:any id ID #IMPLIED> <!ATTLIST xs:anyAttribute id ID #IMPLIED> <!ATTLIST xs:attribute id ID #IMPLIED> <!ATTLIST xs:attributeGroup id ID #IMPLIED> <!ATTLIST xs:unique id ID #IMPLIED> <!ATTLIST xs:key id ID #IMPLIED> <!ATTLIST xs:keyref id ID #IMPLIED> <!ATTLIST xs:selector id ID #IMPLIED> <!ATTLIST xs:field id ID #IMPLIED> <!ATTLIST xs:assert id ID #IMPLIED> ↓<!ATTLIST xs:report id ID #IMPLIED>↓ <!ATTLIST xs:include id ID #IMPLIED> <!ATTLIST xs:import id ID #IMPLIED> <!ATTLIST xs:redefine id ID #IMPLIED> <!ATTLIST xs:notation id ID #IMPLIED> ]> <?xml version='1.0'?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" blockDefault="#all" elementFormDefault="qualified" xml:lang="EN" targetNamespace="http://www.w3.org/2001/XMLSchema" version="structures.xsd (wd-20070830)"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html"> The schema corresponding to this document is normative, with respect to the syntactic constraints it expresses in the ↓XML Schema language↓↑XML Schema Definition Language↑. The documentation (within <documentation> elements) below, is not normative, but rather highlights important aspects of the W3C Recommendation of which this is a part</xs:documentation> </xs:annotation> <xs:annotation> <xs:documentation> The simpleType element and all of its members are defined in datatypes.xsd</xs:documentation> </xs:annotation> <xs:include schemaLocation="datatypes.xsd"/> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"> <xs:annotation> <xs:documentation> Get access to the xml: attribute groups for xml:lang as declared on 'schema' and 'documentation' below </xs:documentation> </xs:annotation> </xs:import> <xs:complexType name="openAttrs"> <xs:annotation> <xs:documentation> This type is extended by almost all schema types to allow attributes from other namespaces to be added to user schemas. </xs:documentation> </xs:annotation> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="annotated"> <xs:annotation> <xs:documentation> This type is extended by all types which allow annotation other than <schema> itself </xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="xs:openAttrs"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="id" type="xs:ID"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:group name="schemaTop"> <xs:annotation> <xs:documentation> This group is for the elements which occur freely at the top level of schemas. All of their types are based on the "annotated" type by extension.</xs:documentation> </xs:annotation> <xs:choice> <xs:group ref="xs:redefinable"/> <xs:element ref="xs:element"/> <xs:element ref="xs:attribute"/> <xs:element ref="xs:notation"/> </xs:choice> </xs:group> <xs:group name="redefinable"> <xs:annotation> <xs:documentation> This group is for the elements which can self-redefine (see <redefine> below).</xs:documentation> </xs:annotation> <xs:choice> <xs:element ref="xs:simpleType"/> <xs:element ref="xs:complexType"/> <xs:element ref="xs:group"/> <xs:element ref="xs:attributeGroup"/> </xs:choice> </xs:group> <xs:simpleType name="formChoice"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="qualified"/> <xs:enumeration value="unqualified"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="reducedDerivationControl"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:derivationControl"> <xs:enumeration value="extension"/> <xs:enumeration value="restriction"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="derivationSet"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> <xs:documentation> #all or (possibly empty) subset of {extension, restriction}</xs:documentation> </xs:annotation> <xs:union> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#all"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:list itemType="xs:reducedDerivationControl"/> </xs:simpleType> </xs:union> </xs:simpleType> <xs:simpleType name="typeDerivationControl"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:derivationControl"> <xs:enumeration value="extension"/> <xs:enumeration value="restriction"/> <xs:enumeration value="list"/> <xs:enumeration value="union"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="fullDerivationSet"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> <xs:documentation> #all or (possibly empty) subset of {extension, restriction, list, union}</xs:documentation> </xs:annotation> <xs:union> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#all"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:list itemType="xs:typeDerivationControl"/> </xs:simpleType> </xs:union> </xs:simpleType> <xs:element name="schema" id="schema"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-schema"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:openAttrs"> <xs:sequence> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="xs:include"/> <xs:element ref="xs:import"/> <xs:element ref="xs:redefine"/> <xs:element ref="xs:annotation"/> </xs:choice> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:group ref="xs:schemaTop"/> <xs:element ref="xs:annotation" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:sequence> <xs:attribute name="targetNamespace" type="xs:anyURI"/> <xs:attribute name="version" type="xs:token"/> <xs:attribute name="finalDefault" type="xs:fullDerivationSet" default="" use="optional"/> <xs:attribute name="blockDefault" type="xs:blockSet" default="" use="optional"/> <xs:attribute name="attributeFormDefault" type="xs:formChoice" default="unqualified" use="optional"/> <xs:attribute name="elementFormDefault" type="xs:formChoice" default="unqualified" use="optional"/> ↑<xs:attribute name="defaultAttributes" type="xs:QName"/>↑ ↑<xs:attribute name="defaultXPathDefaultNamespace" type="xs:xpathDefaultNamespace" default="##local" use="optional"/>↑ <xs:attribute name="id" type="xs:ID"/> <xs:attribute ref="xml:lang"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:key name="element"> <xs:selector xpath="xs:element"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="attribute"> <xs:selector xpath="xs:attribute"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="type"> <xs:selector xpath="xs:complexType|xs:simpleType"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="group"> <xs:selector xpath="xs:group"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="attributeGroup"> <xs:selector xpath="xs:attributeGroup"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="notation"> <xs:selector xpath="xs:notation"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="identityConstraint"> <xs:selector xpath=".//xs:key|.//xs:unique|.//xs:keyref"/> <xs:field xpath="@name"/> </xs:key> </xs:element> <xs:simpleType name="allNNI"> <xs:annotation> <xs:documentation> for maxOccurs</xs:documentation> </xs:annotation> <xs:union memberTypes="xs:nonNegativeInteger"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="unbounded"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> <xs:attributeGroup name="occurs"> <xs:annotation> <xs:documentation> for all particles</xs:documentation> </xs:annotation> <xs:attribute name="minOccurs" type="xs:nonNegativeInteger" default="1" use="optional"/> <xs:attribute name="maxOccurs" type="xs:allNNI" default="1" use="optional"/> </xs:attributeGroup> <xs:attributeGroup name="defRef"> <xs:annotation> <xs:documentation> for element, group and attributeGroup, which both define and reference</xs:documentation> </xs:annotation> <xs:attribute name="name" type="xs:NCName"/> <xs:attribute name="ref" type="xs:QName"/> </xs:attributeGroup> <xs:group name="typeDefParticle"> <xs:annotation> <xs:documentation> 'complexType' uses this</xs:documentation> </xs:annotation> <xs:choice> <xs:element name="group" type="xs:groupRef"/> <xs:element ref="xs:all"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> </xs:choice> </xs:group> <xs:group name="nestedParticle"> <xs:choice> <xs:element name="element" type="xs:localElement"/> <xs:element name="group" type="xs:groupRef"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> <xs:element ref="xs:any"/> </xs:choice> </xs:group> <xs:group name="particle"> <xs:choice> <xs:element name="element" type="xs:localElement"/> <xs:element name="group" type="xs:groupRef"/> <xs:element ref="xs:all"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> <xs:element ref="xs:any"/> </xs:choice> </xs:group> <xs:complexType name="attribute"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:element name="simpleType" type="xs:localSimpleType" minOccurs="0"/> </xs:sequence> <xs:attributeGroup ref="xs:defRef"/> <xs:attribute name="type" type="xs:QName"/> <xs:attribute name="use" default="optional" use="optional"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="prohibited"/> <xs:enumeration value="optional"/> <xs:enumeration value="required"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="default" type="xs:string"/> <xs:attribute name="fixed" type="xs:string"/> <xs:attribute name="form" type="xs:formChoice"/> ↑<xs:attribute name="targetNamespace" type="xs:anyURI"/>↑ </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="topLevelAttribute"> <xs:complexContent> <xs:restriction base="xs:attribute"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:element name="simpleType" type="xs:localSimpleType" minOccurs="0"/> </xs:sequence> <xs:attribute name="ref" use="prohibited"/> <xs:attribute name="form" use="prohibited"/> <xs:attribute name="use" use="prohibited"/> ↑<xs:attribute name="targetNamespace" use="prohibited"/>↑ <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:group name="attrDecls"> <xs:sequence> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="attribute" type="xs:attribute"/> <xs:element name="attributeGroup" type="xs:attributeGroupRef"/> </xs:choice> <xs:element ref="xs:anyAttribute" minOccurs="0"/> </xs:sequence> </xs:group> <xs:element name="anyAttribute" type="xs:wildcard" id="anyAttribute"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-anyAttribute"/> </xs:annotation> </xs:element> <xs:group name="assertions"> <xs:sequence> ↓<xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="assert" type="xs:assertion"/> <xs:element name="report" type="xs:assertion"/> </xs:choice>↓ ↑<xs:element name="assert" type="xs:assertion" minOccurs="0" maxOccurs="unbounded"/>↑ </xs:sequence> </xs:group> <xs:complexType name="assertion"> <xs:complexContent> <xs:extension base="xs:annotated"> ↓<xs:attribute name="test"> <xs:simpleType> <xs:annotation> <xs:documentation>A subset of XPath expressions for use in assertion tests</xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> </xs:restriction> </xs:simpleType> </xs:attribute>↓ ↑<xs:attribute name="test" type="string"/>↑ ↑<xs:attribute name="xpathDefaultNamespace" type="xs:xpathDefaultNamespace"/>↑ </xs:extension> </xs:complexContent> </xs:complexType> <xs:group name="complexTypeModel"> <xs:choice> <xs:element ref="xs:simpleContent"/> <xs:element ref="xs:complexContent"/> <xs:sequence> <xs:annotation> <xs:documentation> This branch is short for <complexContent> <restriction base="xs:anyType"> ... </restriction> </complexContent></xs:documentation> </xs:annotation> ↑<xs:element ref="xs:openContent" minOccurs="0"/>↑ <xs:group ref="xs:typeDefParticle" minOccurs="0"/> <xs:group ref="xs:attrDecls"/> <xs:group ref="xs:assertions"/> </xs:sequence> </xs:choice> </xs:group> <xs:complexType name="complexType" abstract="true"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:group ref="xs:complexTypeModel"/> <xs:attribute name="name" type="xs:NCName"> <xs:annotation> <xs:documentation> Will be restricted to required or ↓forbidden↓↑prohibited↑</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="mixed" type="xs:boolean" default="false" use="optional"> <xs:annotation> <xs:documentation> Not allowed if simpleContent child is chosen. May be overridden by setting on complexContent child.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="abstract" type="xs:boolean" default="false" use="optional"/> <xs:attribute name="final" type="xs:derivationSet"/> <xs:attribute name="block" type="xs:derivationSet"/> ↑<xs:attribute name="defaultAttributesApply" type="xs:boolean" default="true" use="optional"/>↑ </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="topLevelComplexType"> <xs:complexContent> <xs:restriction base="xs:complexType"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:complexTypeModel"/> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="localComplexType"> <xs:complexContent> <xs:restriction base="xs:complexType"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:complexTypeModel"/> </xs:sequence> <xs:attribute name="name" use="prohibited"/> <xs:attribute name="abstract" use="prohibited"/> <xs:attribute name="final" use="prohibited"/> <xs:attribute name="block" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="restrictionType"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:choice minOccurs="0"> ↓<xs:group ref="xs:typeDefParticle"/>↓ ↑<xs:sequence> <xs:element ref="xs:openContent" minOccurs="0"/> <xs:group ref="xs:typeDefParticle"/> </xs:sequence>↑ <xs:group ref="xs:simpleRestrictionModel"/> </xs:choice> <xs:group ref="xs:attrDecls"/> <xs:group ref="xs:assertions"/> </xs:sequence> <xs:attribute name="base" type="xs:QName" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="complexRestrictionType"> <xs:complexContent> <xs:restriction base="xs:restrictionType"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0"> <xs:annotation> <xs:documentation>This choice is added simply to make this a valid restriction per the REC</xs:documentation> </xs:annotation> ↓<xs:group ref="xs:typeDefParticle"/>↓ ↑<xs:sequence> <xs:element ref="xs:openContent" minOccurs="0"/> <xs:group ref="xs:typeDefParticle"/> </xs:sequence>↑ </xs:choice> <xs:group ref="xs:attrDecls"/> <xs:group ref="xs:assertions"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="extensionType"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> ↑<xs:element ref="xs:openContent" minOccurs="0"/>↑ <xs:group ref="xs:typeDefParticle" minOccurs="0"/> <xs:group ref="xs:attrDecls"/> <xs:group ref="xs:assertions"/> </xs:sequence> <xs:attribute name="base" type="xs:QName" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="complexContent" id="complexContent"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-complexContent"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:choice> <xs:element name="restriction" type="xs:complexRestrictionType"/> <xs:element name="extension" type="xs:extensionType"/> </xs:choice> <xs:attribute name="mixed" type="xs:boolean"> <xs:annotation> <xs:documentation> Overrides any setting on complexType parent.</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> ↑<xs:element name="openContent" id="openContent"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-openContent"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:element name="any" minOccurs="0" type="xs:wildcard"/> </xs:sequence> <xs:attribute name="mode" default="interleave" use="optional"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="none"/> <xs:enumeration value="interleave"/> <xs:enumeration value="suffix"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="defaultOpenContent" id="defaultOpenContent"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-defaultOpenContent"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:element name="any" type="xs:wildcard"/> </xs:sequence> <xs:attribute name="appliesToEmpty" type="xs:boolean" default="false" use="optional"/> <xs:attribute name="mode" default="interleave" use="optional"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="interleave"/> <xs:enumeration value="suffix"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element>↑ <xs:complexType name="simpleRestrictionType"> <xs:complexContent> <xs:restriction base="xs:restrictionType"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0"> <xs:annotation> <xs:documentation>This choice is added simply to make this a valid restriction per the REC</xs:documentation> </xs:annotation> <xs:group ref="xs:simpleRestrictionModel"/> </xs:choice> <xs:group ref="xs:attrDecls"/> <xs:group ref="xs:assertions"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="simpleExtensionType"> <xs:complexContent> <xs:restriction base="xs:extensionType"> <xs:sequence> <xs:annotation> <xs:documentation> No typeDefParticle group reference</xs:documentation> </xs:annotation> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:attrDecls"/> <xs:group ref="xs:assertions"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="simpleContent" id="simpleContent"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-simpleContent"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:choice> <xs:element name="restriction" type="xs:simpleRestrictionType"/> <xs:element name="extension" type="xs:simpleExtensionType"/> </xs:choice> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="complexType" type="xs:topLevelComplexType" id="complexType"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-complexType"/> </xs:annotation> </xs:element> <xs:simpleType name="blockSet"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> <xs:documentation> #all or (possibly empty) subset of {substitution, extension, restriction}</xs:documentation> </xs:annotation> <xs:union> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#all"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:list> <xs:simpleType> <xs:restriction base="xs:derivationControl"> <xs:enumeration value="extension"/> <xs:enumeration value="restriction"/> <xs:enumeration value="substitution"/> </xs:restriction> </xs:simpleType> </xs:list> </xs:simpleType> </xs:union> </xs:simpleType> <xs:complexType name="element" abstract="true"> <xs:annotation> <xs:documentation> The element element can be used either at the top level to define an element-type binding globally, or within a content model to either reference a globally-defined element or type or declare an element-type binding locally. The ref form is not allowed at the top level.</xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:choice minOccurs="0"> <xs:element name="simpleType" type="xs:localSimpleType"/> <xs:element name="complexType" type="xs:localComplexType"/> </xs:choice>↑ <xs:element name="alternative" type="xs:altType" minOccurs="0" maxOccurs="unbounded"/>↑ <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attributeGroup ref="xs:defRef"/> <xs:attribute name="type" type="xs:QName"/> ↓<xs:attribute name="substitutionGroup" type="xs:QName"/>↓ ↑<xs:attribute name="substitutionGroup"> <xs:simpleType> <xs:list itemType="xs:QName"/> </xs:simpleType> </xs:attribute>↑ <xs:attributeGroup ref="xs:occurs"/> <xs:attribute name="default" type="xs:string"/> <xs:attribute name="fixed" type="xs:string"/> <xs:attribute name="nillable" type="xs:boolean" default="false" use="optional"/> <xs:attribute name="abstract" type="xs:boolean" default="false" use="optional"/> <xs:attribute name="final" type="xs:derivationSet"/> <xs:attribute name="block" type="xs:blockSet"/> <xs:attribute name="form" type="xs:formChoice"/> ↑<xs:attribute name="targetNamespace" type="xs:anyURI"/>↑ </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="topLevelElement"> <xs:complexContent> <xs:restriction base="xs:element"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0"> <xs:element name="simpleType" type="xs:localSimpleType"/> <xs:element name="complexType" type="xs:localComplexType"/> </xs:choice>↑ <xs:element name="alternative" type="xs:altType" minOccurs="0" maxOccurs="unbounded"/>↑ <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="ref" use="prohibited"/> <xs:attribute name="form" use="prohibited"/> ↑<xs:attribute name="targetNamespace" use="prohibited"/>↑ <xs:attribute name="minOccurs" use="prohibited"/> <xs:attribute name="maxOccurs" use="prohibited"/> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="localElement"> <xs:complexContent> <xs:restriction base="xs:element"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0"> <xs:element name="simpleType" type="xs:localSimpleType"/> <xs:element name="complexType" type="xs:localComplexType"/> </xs:choice>↑ <xs:element name="alternative" type="xs:altType" minOccurs="0" maxOccurs="unbounded"/>↑ <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="substitutionGroup" use="prohibited"/> <xs:attribute name="final" use="prohibited"/> <xs:attribute name="abstract" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="element" type="xs:topLevelElement" id="element"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-element"/> </xs:annotation> </xs:element>↑ <xs:complexType name="altType"> <xs:annotation> <xs:documentation> This type is used for 'alternative' elements. </xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:choice minOccurs="0"> <xs:element ref="xs:simpleType"/> <xs:element ref="xs:complexType"/> </xs:choice> <xs:attribute name="test" type="string" use="optional"/> <xs:attribute name="type" type="QName" use="optional"/> <xs:attribute name="xpathDefaultNamespace" type="xs:xpathDefaultNamespace"/> <xs:attribute name="id" type="xs:ID"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:simpleType name="restrictedXPathExpr"> <xs:annotation> <xs:documentation> This type is used for XPath expressions in assertions, identity constraints, and conditional type assignment. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>↑ <xs:complexType name="group" abstract="true"> <xs:annotation> <xs:documentation> group type for explicit groups, named top-level groups and group references</xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:group ref="xs:particle" minOccurs="0" maxOccurs="unbounded"/> <xs:attributeGroup ref="xs:defRef"/> <xs:attributeGroup ref="xs:occurs"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="realGroup"> <xs:complexContent> <xs:restriction base="xs:group"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0" maxOccurs="1"> <xs:element ref="xs:all"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> </xs:choice> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="namedGroup"> <xs:complexContent> <xs:restriction base="xs:realGroup"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="1" maxOccurs="1"> <xs:element name="all"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:all"> <xs:group ref="xs:allModel"/> <xs:attribute name="minOccurs" use="prohibited"/> <xs:attribute name="maxOccurs" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="choice" type="xs:simpleExplicitGroup"/> <xs:element name="sequence" type="xs:simpleExplicitGroup"/> </xs:choice> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:attribute name="ref" use="prohibited"/> <xs:attribute name="minOccurs" use="prohibited"/> <xs:attribute name="maxOccurs" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="groupRef"> <xs:complexContent> <xs:restriction base="xs:realGroup"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="ref" type="xs:QName" use="required"/> <xs:attribute name="name" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="explicitGroup"> <xs:annotation> <xs:documentation> group type for the three kinds of group</xs:documentation> </xs:annotation> <xs:complexContent> <xs:restriction base="xs:group"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:nestedParticle" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" ↓type="xs:NCName" ↓use="prohibited"/> <xs:attribute name="ref" ↓type="xs:QName" ↓use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="simpleExplicitGroup"> <xs:complexContent> <xs:restriction base="xs:explicitGroup"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:nestedParticle" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="minOccurs" use="prohibited"/> <xs:attribute name="maxOccurs" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:group name="allModel"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>This choice with min/max is here to avoid a pblm with the Elt:All/Choice/Seq Particle derivation constraint</xs:documentation> </xs:annotation> <xs:element name="element" type="xs:localElement"/> <xs:element ref="xs:any"/> </xs:choice> </xs:sequence> </xs:group> <xs:complexType name="all"> <xs:annotation> <xs:documentation> Only elements allowed inside</xs:documentation> </xs:annotation> <xs:complexContent> <xs:restriction base="xs:explicitGroup"> <xs:group ref="xs:allModel"/> <xs:attribute name="minOccurs" default="1" use="optional"> <xs:simpleType> <xs:restriction base="xs:nonNegativeInteger"> <xs:enumeration value="0"/> <xs:enumeration value="1"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="maxOccurs" default="1" use="optional"> <xs:simpleType> <xs:restriction base="xs:allNNI"> <xs:enumeration value="1"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="all" type="xs:all" id="all"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-all"/> </xs:annotation> </xs:element> <xs:element name="choice" type="xs:explicitGroup" id="choice"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-choice"/> </xs:annotation> </xs:element> <xs:element name="sequence" type="xs:explicitGroup" id="sequence"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-sequence"/> </xs:annotation> </xs:element> <xs:element name="group" type="xs:namedGroup" id="group"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-group"/> </xs:annotation> </xs:element> ↑<xs:attributeGroup name="anyAttrGroup"> <xs:attribute name="namespace" type="xs:namespaceList" use="optional"/> <xs:attribute name="notNamespace" type="xs:basicNamespaceList" use="optional"/> <xs:attribute name="notQName" type="xs:qnameList" use="optional"/> <xs:attribute name="processContents" default="strict" use="optional"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="skip"/> <xs:enumeration value="lax"/> <xs:enumeration value="strict"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:attributeGroup>↑ <xs:complexType name="wildcard"> <xs:complexContent> <xs:extension base="xs:annotated"> ↓<xs:attribute name="namespace" type="xs:namespaceList" use="optional"/> <xs:attribute name="notNamespace" type="xs:basicNamespaceList" use="optional"/> <xs:attribute name="notQName" use="optional"> <xs:simpleType> <xs:list itemType="xs:QName"/> </xs:simpleType> </xs:attribute> <xs:attribute name="processContents" default="strict" use="optional"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="skip"/> <xs:enumeration value="lax"/> <xs:enumeration value="strict"/> </xs:restriction> </xs:simpleType> </xs:attribute>↓ ↑<xs:attributeGroup ref="xs:anyAttrGroup"/>↑ </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="any" id="any"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-any"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:wildcard"> <xs:attributeGroup ref="xs:occurs"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:annotation> <xs:documentation> simple type for the value of the 'namespace' attr of 'any' and 'anyAttribute'</xs:documentation> </xs:annotation> <xs:annotation> <xs:documentation> Value is ##any - - any non-conflicting WFXML/attribute at all ##other - - any non-conflicting WFXML/attribute from namespace other than targetNS ##local - - any unqualified non-conflicting WFXML/attribute one or - - any non-conflicting WFXML/attribute from more URI the listed namespaces references (space separated) ##targetNamespace or ##local may appear in the above list, to refer to the targetNamespace of the enclosing schema or an absent targetNamespace respectively</xs:documentation> </xs:annotation> <xs:simpleType name="namespaceList"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> </xs:annotation> <xs:union memberTypes="xs:specialNamespaceList xs:basicNamespaceList" /> </xs:simpleType> <xs:simpleType name="basicNamespaceList"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> </xs:annotation> <xs:list> <xs:simpleType> <xs:union memberTypes="xs:anyURI"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="##targetNamespace"/> <xs:enumeration value="##local"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> </xs:list> </xs:simpleType> <xs:simpleType name="specialNamespaceList"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:enumeration value="##any"/> <xs:enumeration value="##other"/> </xs:restriction> </xs:simpleType> ↑<xs:simpleType name="qnameList"> <xs:annotation> <xs:documentation> A utility type, not for public use </xs:documentation> </xs:annotation> <xs:list> <xs:simpleType> <xs:union memberTypes="xs:QName"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="##defined"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> </xs:list> </xs:simpleType>↑ ↑<xs:simpleType name="xpathDefaultNamespace"> <xs:union memberTypes="xs:anyURI"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="##defaultNamespace"/> <xs:enumeration value="##targetNamespace"/> <xs:enumeration value="##local"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType>↑ <xs:element name="attribute" type="xs:topLevelAttribute" id="attribute"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-attribute"/> </xs:annotation> </xs:element> <xs:complexType name="attributeGroup" abstract="true"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:group ref="xs:attrDecls"/> <xs:attributeGroup ref="xs:defRef"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="namedAttributeGroup"> <xs:complexContent> <xs:restriction base="xs:attributeGroup"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:attrDecls"/> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:attribute name="ref" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="attributeGroupRef"> <xs:complexContent> <xs:restriction base="xs:attributeGroup"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="ref" type="xs:QName" use="required"/> <xs:attribute name="name" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="attributeGroup" type="xs:namedAttributeGroup" id="attributeGroup"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-attributeGroup"/> </xs:annotation> </xs:element> <xs:element name="include" id="include"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-include"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="redefine" id="redefine"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-redefine"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:openAttrs"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="xs:annotation"/> <xs:group ref="xs:redefinable"/> </xs:choice> <xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/> <xs:attribute name="id" type="xs:ID"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="import" id="import"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-import"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="namespace" type="xs:anyURI"/> <xs:attribute name="schemaLocation" type="xs:anyURI"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="selector" id="selector"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-selector"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="xpath" use="required"> <xs:simpleType> <xs:annotation> <xs:documentation>A subset of XPath expressions for use in selectors</xs:documentation> <xs:documentation>A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:token"↑/↑> ↓<xs:annotation> <xs:documentation>The following pattern is intended to allow XPath expressions per the following EBNF: Selector ::= Path ( '|' Path )* Path ::= ('.//')? Step ( '/' Step )* Step ::= '.' | NameTest NameTest ::= QName | '*' | NCName ':' '*' child:: is also allowed </xs:documentation> </xs:annotation> <xs:pattern value="(\.//)?(((child::)?((\i\c*:)?(\i\c*|\*)))|\.)(/(((child::)?((\i\c*:)?(\i\c*|\*)))|\.))*(\|(\.//)?(((child::)?((\i\c*:)?(\i\c*|\*)))|\.)(/(((child::)?((\i\c*:)?(\i\c*|\*)))|\.))*)*"/> </xs:restriction>↓ </xs:simpleType> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="field" id="field"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-field"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="xpath" use="required"> <xs:simpleType> <xs:annotation> <xs:documentation>A subset of XPath expressions for use in fields</xs:documentation> <xs:documentation>A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:token"↑/↑> ↓<xs:annotation> <xs:documentation>The following pattern is intended to allow XPath expressions per the same EBNF as for selector, with the following change: Path ::= ('.//')? ( Step '/' )* ( Step | '@' NameTest ) </xs:documentation> </xs:annotation> <xs:pattern value="(\.//)?((((child::)?((\i\c*:)?(\i\c*|\*)))|\.)/)*((((child::)?((\i\c*:)?(\i\c*|\*)))|\.)|((attribute::|@)((\i\c*:)?(\i\c*|\*))))(\|(\.//)?((((child::)?((\i\c*:)?(\i\c*|\*)))|\.)/)*((((child::)?((\i\c*:)?(\i\c*|\*)))|\.)|((attribute::|@)((\i\c*:)?(\i\c*|\*)))))*"/> </xs:restriction>↓ </xs:simpleType> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:complexType name="keybase"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:element ref="xs:selector"/> <xs:element ref="xs:field" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:NCName"↓ use="required"↓/> ↑<xs:attribute name="ref" type="xs:QName"/>↑ ↑<xs:attribute name="xpathDefaultNamespace" type="xs:xpathDefaultNamespace"/>↑ </xs:extension> </xs:complexContent> </xs:complexType> <xs:group name="identityConstraint"> <xs:annotation> <xs:documentation>The three kinds of identity constraints, all with type of or derived from 'keybase'. </xs:documentation> </xs:annotation> <xs:choice> <xs:element ref="xs:unique"/> <xs:element ref="xs:key"/> <xs:element ref="xs:keyref"/> </xs:choice> </xs:group> <xs:element name="unique" type="xs:keybase" id="unique"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-unique"/> </xs:annotation> </xs:element> <xs:element name="key" type="xs:keybase" id="key"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-key"/> </xs:annotation> </xs:element> <xs:element name="keyref" id="keyref"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-keyref"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:keybase"> <xs:attribute name="refer" type="xs:QName"↓ use="required"↓/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="notation" id="notation"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-notation"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:attribute name="public" type="xs:public"/> <xs:attribute name="system" type="xs:anyURI"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:simpleType name="public"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> <xs:documentation> A public identifier, per ISO 8879</xs:documentation> </xs:annotation> <xs:restriction base="xs:token"/> </xs:simpleType> <xs:element name="appinfo" id="appinfo"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-appinfo"/> </xs:annotation> <xs:complexType mixed="true"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:any processContents="lax"/> </xs:sequence> <xs:attribute name="source" type="xs:anyURI"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="documentation" id="documentation"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-documentation"/> </xs:annotation> <xs:complexType mixed="true"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:any processContents="lax"/> </xs:sequence> <xs:attribute name="source" type="xs:anyURI"/> <xs:attribute ref="xml:lang"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="annotation" id="annotation"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/structures.diff-wd.html#element-annotation"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:openAttrs"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="xs:appinfo"/> <xs:element ref="xs:documentation"/> </xs:choice> <xs:attribute name="id" type="xs:ID"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:annotation> <xs:documentation> notations for use within ↓XML Schema↓ schema↑ document↑s</xs:documentation> </xs:annotation> <xs:notation name="XMLSchemaStructures" public="structures" system="http://www.w3.org/2000/08/XMLSchema.xsd"/> <xs:notation name="XML" public="REC-xml-19980210" system="http://www.w3.org/TR/1998/REC-xml-19980210"/> <xs:complexType name="anyType" mixed="true"> <xs:annotation> <xs:documentation> Not the real urType, but as close an approximation as we can get in the XML representation</xs:documentation> </xs:annotation> <xs:sequence> <xs:any minOccurs="0" maxOccurs="unbounded" processContents="lax"/> </xs:sequence> <xs:anyAttribute processContents="lax"/> </xs:complexType> </xs:schema>
To facilitate consistent reporting of schema errors and ·validation· failures, this section tabulates and
provides unique names for all the constraints listed in this
document. Wherever such constraints have numbered parts, reports
must use the name given below plus the
part number, separated by a period ('.'). Thus for example
cos-ct-extends.1.2
must
be used to report a violation of the clause 1.2 of Derivation
Valid (Extension) (§3.4.6).
This section defines some terms for use in describing choices made by implementations in areas where the effect of ↓XML Schema language↓↑XSDL↑ features is explicitly ·implementation-defined·.
Future versions of this specification are expected to use the terminology defined here to specify conformance profiles. Conformance profiles may also be defined by other specifications without requiring any revision to this specification.
This specification defines a number of ways in which the information set taken as input is augmented in the course of schema-validity assessment. Conforming processors may provide access to some or all of this information; in the interests of simplifying discussion and documentation, this section defines names for several subsets of the PSVI, with the intention of simplifying short-hand descriptions of processors. These terms may be used to describe what parts of the PSVI a particular schema processor provides access to, or to specify requirements for processors, or for other purposes. A processor provides access to a particular subset of the PSVI if and only if it makes accessible some representation of the information in question, for information items to which it is applicable. (The properties labeled "if applicable" or "where applicable" below are simply the most obvious cases of properties which do not apply to every information item; the same qualification implicitly applies to all properties listed below.)
If other subsets of the PSVI prove important in practice it is expected that definitions of those subsets may be provided by other specifications or in later revisions of this one.
The definition in this section of a term denoting a particular subset of the PSVI does not constitute a requirement that conforming processors provide access to that subset.
Conforming processors may implement any combination of the following strategies for locating schema components, in any order. They may also implement other strategies.
The terminology offered here is intended to be useful in discussions of processor behavior, whether documenting existing behavior or describing required behavior.
General-purpose processors should support multiple methods for locating schema documents, and ↓to↓ provide user control over which methods are used and how to fall back in case of failure.
rddl:resource
elements with the
well-known property xlink:role
=
"http://www.w3.org/2001/XMLSchema
" and then attempt to
dereference the location(s) indicated on the
xlink:href
attribute of the link.import
element, the processor
attempts to dereference those locations.This specification requires as a precondition for ·assessment· an information set as defined in [XML-Infoset] which supports at least the following information items and properties:
In addition, infosets should support the [unparsedEntities] property of the Document Information Item. Failure to do so will mean all items of type ENTITY or ENTITIES will fail to ·validate·.
This specification does not require any destructive alterations to the input information set: all the information set contributions specified herein are additive.
This appendix is intended to satisfy the requirements for Conformance to the [XML-Infoset] specification.
[Definition:] An implementation-defined feature or behavior may vary among processors conforming to this specification; the precise behavior is not specified by this specification but must be specified by the implementor for each particular conforming implementation. (In the latter respect, ·implementation-defined· features differ from ·implementation-dependent· features.)
This appendix provides a summary of ↓XML Schema language↓↑XSDL↑ features whose effect is explicitly ·implementation-defined·. Any software which claims to conform to this specification must describe how these choices have been exercised, in documentation which accompanies any conformance claim.
In describing the choices made for a given processor, it is hoped that the terminology defined in Terminology for implementation-defined features (§D) will be found useful.
[Definition:] An implementation-dependent feature or behavior may vary among processors conforming to this specification; the precise behavior is not specified by this or any other W3C specification and is not required to be specified by the implementor for any particular implementation. (In the latter respect, ·implementation-dependent· features differ from ·implementation-defined· features.)
This appendix provides a summary of XSDL features whose effect is explicitly ·implementation-dependent·. Choices made by processors in these areas are not required to be documented.
The Unique Particle Attribution (§3.8.6) constraint has been relaxed. While competition between two ·element particles· is still forbidden, as is competition between two ·wildcard particles·, competition between an ·element particle· and a ·wildcard particle· is no longer forbidden. In the course of making this substantive change, some editorial changes have also been made, in order to make the exposition clearer. (Readers familiar with version 1.0 of this specification will find that the constraint works in almost exactly the same way as it did in 1.0, except that content models in which an input item matches either a ·wildcard particle· or an ·element particle· are now allowed.)
Support for XML 1.1 has been added. It is now implementation defined whether datatypes dependent on definitions in XML ([XML 1.1], [XML 1.0]) and Namespaces in XML ([XML-Namespaces 1.1], [XML-Namespaces 1.0]) use the definitions as found in version 1.1 or version 1.0 of those specifications.
Correction of an error in version 1.0 of this specification relating to the construction of union types from other union types. Unions may now appear as members of other unions, and all restrictions of unions are correctly enforced.
A {context} property has been defined for the definitions of complex and of simple types.
Since not all datatypes have a defined canonical representation for all of their values, appeals to the canonical forms of values have been eliminated.
Changes to ensure that the descriptions of the Simple Type Definition component and of ·anySimpleType· agree in all details with those of [XML Schema: Datatypes].
Addition of a note warning that the replace and collapse values for whitespace handling are not a reliable means of neutralizing the effects of word-wrapping and pretty-printing of natural-language data and should not be used for that purpose.
Support for negative wildcard has been expanded to handle multiple namespaces. Support has also been added to specify a set of explicitly enumerated expanded names that are not allowed by the wildcard.
Support for check clauses to implement some co-occurrence constraints has been added. Each complex type can carry a list of assertions, which are checked when the complex type is used to validate an element information item.
The underlying basis for the definition of all the different kinds of components has changed to make use of a regular and formal tabulation of their properties. This has been achieved by introducing property records wherever version 1.0 had complex property values. For example instead of describing the {scope} property as having "either global or a complex type definition" for its value, a Scope property record is called for, which in turn has its own simple properties and values. See e.g. The Element Declaration Schema Component (§3.3.1).
use-when
attribute or to the C
preprocessor #ifdef
construct. By means of the
vc:minVersion
and vc:maxVersion
attributes, a simple forward-processing mechanism is supplied, so
that conforming XSDL 1.1 processors can successfully ignore
constructs introduced in future versions (if any) of XSDL, and so
that schema authors can define schemas which use newer constructs
when available but can fall back on older constructs when the newer
constructs are not available.maxOccurs
may now be greater than 1
on particles in an all group. The elements which
match a particular particle need not be adjacent in the input.all
-groups
can now be extended; the result is an all
-group
(usually a larger one).report
element described in earlier drafts has
been removed. This involves no loss of functionality: the same
effect can be obtained by wrapping the test expression on an
<assert> element in a negation.xs:anyType
· (first a restriction step, then an
extension step, then a restriction step). A misleading note about
the purpose of this rule has been deleted.mixed
attribute.xs:ID
. Elements have always been able to have multiple
children of type xs:ID
, but XSDL 1.0 forbad multiple
attributes of this type for compabitility with XML DTDs. (Schemas
intended to be translatable into DTD form should still avoid the
practice.) This change should make it easier for XML vocabularies
to support both existing ID attributes and
xml:ID
.xs:IDREF
,
xs:ENTITY
, or xs:ENTITIES
are now
enforced on default values.xs:ID
may now have
default or fixed values. XSDL 1.0 had forbidden this, for
compatiblity with XML DTDs.anyAtomicType
has
been introduced into the type hierarchy between
anySimpleType
and all the atomic built-in
type definitions. See Built-in
Simple Type Definitions (§3.16.7).xsi:type
is used on an element to name a member of the
union.xsd:error
· for use in identifying conditionally
assigned types which violate restriction rulesxsi:type
and other attibutes in the namespace
http://www.w3.org/2001/XMLSchema-instance
, since they
will not be applied.defaultAttributes
attribute, which
identifies a named Attribute Group Definition; each complex type defined in
the schema document then automatically includes that attribute
group, unless this is overridden by the
defaultAttributesApply
attribute on the <complexType> element. Default attribute groups
make it easier to specify attributes which should be accepted by
every complex type in a schema (e.g. xml:id
and
xml:lang
).xsi:type
attribute appears on an element,
and has a QName as its value, but the QName does not resolve to a
known type definition, processors are now required to "fall back"
to lax validation, using the declared {type definition} of the ·governing element declaration· as the ·governing type
definition·.xsi:type
attribute, the ·actual
value· of that attribute must
·resolve· to a type definition, and that type
definition must be the ·governing
type definition· of the
element. (This affects only elements without a ·governing element declaration·; other cases were already
handled.)xsi:schemaLocation
attribute provides
information about a schema document location for a particular
namespace, it is no longer an error for it to be encountered after
the first occurrence of an element or attribute information item in
that namespace. Note, however, that if processing such an
xsi:schemaLocation
attribute causes new components to
be added to the schema, then the new components cannot change the
assessment outcome of any information items already seen before the
element bearing the xsi:schemaLocation
attribute.http://www.w3.org/2001/XMLSchema
or
http://www.w3.org/2001/XMLSchema-instance
. In XSDL
1.0, the examples showed no such imports, but there was no rule
making it legal to omit the <import>.xs:anyType
·) is now required; in earlier drafts of
this document, fallback to lax validation was optional.↓In addition to the changes already made, the Working Group has decided on a number of further changes which have not yet been reflected in this draft. These are indicated throughout the text as issues, including more or less detail on the intended resolution. The ones remaining in this draft are summarized below, linked to their occurrence in the text above, where more detail can be found, including links to the original requirement or other point of origin.↓↑it may be useful to mention Some points on which possible changes to the specification have been discussed, but on which no changes have, in the end, been made. In some cases, this resulted from the XML Schema Working Group's determination that no change was desirable; in other cases, there was no consensus on the desirability of change, or no consensus on what change should be made. ↑
ID
,
IDREF
, IDREFS
, and NOTATION
do not have the same effect on the base infoset as they do if
declared in a DTD. (An infoset-to-infoset transformation can be
used to migrate the appropriate information into the base
infoset.)xsd:ID
uniquely identify themselves,
instead of uniquely identifying their parent. This version of this
specification reaffirms the existing rule, which is that elements
and attributes of type xsd:ID
uniquely identify the
parent element of the ID attribute or element.The constraint Content type restricts (§3.4.6) requires that the set of element sequences accepted by one complex type (the restriction) be a subset of the set accepted by another complex type (the base type). Among the published algorithms for checking this subset relation are [Finite State Automata], [UPA and restriction] and [Brzozowski derivatives].
The listing below is for the benefit of readers of a printed version of this document: it collects together all the definitions which appear in the document above.
base
[attribute].xsi:type
, that is an
[attribute] whose [namespace name] is identical to
http://www.w3.org/2001/XMLSchema-instance
and whose
[local name] is
type
.xs:anyType
·↑ as per Element Locally Valid (Type)
(§3.3.4)↑ and assessing schema-validity of its [attributes] and [children] as per clause 3 and clause 4 above. If the element information item is ·skipped·, it must
not be laxly assessed↑xs:anyType
·↑, whose name is
anySimpleType in the XML Schema namespacetrue
and T
is the {type definition} of A.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 Hierarchyerror
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.The DTD for schema documents is given below. Note there is
no implication here that schema
must be the root element of a document.
Although this DTD is non-normative, any XML document which is not valid per this DTD, given redefinitions in its internal subset of the 'p' and 's' parameter entities below appropriate to its namespace declaration of the ↓XML Schema↓↑XSDL↑ namespace, is almost certainly not a valid schema document, with the exception of documents with multiple namespace prefixes for the ↓XML Schema↓↑XSDL↑ namespace itself. Accordingly authoring ↓XML Schema documents↓↑·schema documents·↑ using this DTD and DTD-based authoring tools, and specifying it as the DOCTYPE of documents intended to be ↓XML Schema documents↓↑·schema documents·↑ and validating them with a validating XML parser, are sensible development strategies which users are encouraged to adopt until ↓XML Schema↓↑XSDL↑-based authoring tools and validators are more widely available.
<!-- DTD for ↓XML Schemas: Part 1: Structures↓↑XML Schema Definition Language Part 1: Structures↑ Public Identifier: "-//W3C//DTD XMLSCHEMA 200102//EN" Official Location: http://www.w3.org/2001/XMLSchema.dtd --> <!-- Id: structures.dtd,v 1.1 2003/08/28 13:30:52 ht Exp --> <!-- With the exception of cases with multiple namespace prefixes for the ↓XML Schema↓↑XSDL↑ namespace, any XML document which is not valid per this DTD given redefinitions in its internal subset of the 'p' and 's' parameter entities below appropriate to its namespace declaration of the ↓XML Schema↓↑XSDL↑ namespace is almost certainly not a valid schema. --> <!-- The simpleType element and its constituent parts are defined in XML Schema↓:↓↑ Definition Language↑ Part 2: Datatypes --> <!ENTITY % xs-datatypes PUBLIC 'datatypes' 'datatypes.dtd' > <!ENTITY % p 'xs:'> <!-- can be overridden in the internal subset of a schema document to establish a different namespace prefix --> <!ENTITY % s ':xs'> <!-- if %p is defined (e.g. as foo:) then you must also define %s as the suffix for the appropriate namespace declaration (e.g. :foo) --> <!ENTITY % nds 'xmlns%s;'> <!-- Define all the element names, with optional prefix --> <!ENTITY % schema "%p;schema"> ↑<!ENTITY % defaultOpenContent "%p;defaultOpenContent">↑ <!ENTITY % complexType "%p;complexType"> <!ENTITY % complexContent "%p;complexContent"> ↑<!ENTITY % openContent "%p;openContent">↑ <!ENTITY % simpleContent "%p;simpleContent"> <!ENTITY % extension "%p;extension"> <!ENTITY % element "%p;element">↑ <!ENTITY % alternative "%p;alternative">↑ <!ENTITY % unique "%p;unique"> <!ENTITY % key "%p;key"> <!ENTITY % keyref "%p;keyref"> <!ENTITY % selector "%p;selector"> <!ENTITY % field "%p;field"> <!ENTITY % group "%p;group"> <!ENTITY % all "%p;all"> <!ENTITY % choice "%p;choice"> <!ENTITY % sequence "%p;sequence"> <!ENTITY % any "%p;any"> <!ENTITY % anyAttribute "%p;anyAttribute"> <!ENTITY % attribute "%p;attribute"> <!ENTITY % attributeGroup "%p;attributeGroup"> <!ENTITY % include "%p;include"> <!ENTITY % import "%p;import"> <!ENTITY % redefine "%p;redefine"> <!ENTITY % notation "%p;notation"> <!ENTITY % assert "%p;assert"> ↓<!ENTITY % report "%p;report">↓ <!-- annotation elements --> <!ENTITY % annotation "%p;annotation"> <!ENTITY % appinfo "%p;appinfo"> <!ENTITY % documentation "%p;documentation"> <!-- Customisation entities for the ATTLIST of each element type. Define one of these if your schema takes advantage of the anyAttribute='##other' in the↑ ↑ schema for schema↓s↓↑ documents↑ --> <!ENTITY % schemaAttrs ''> ↑<!ENTITY % defaultOpenContentAttrs ''>↑ <!ENTITY % complexTypeAttrs ''> <!ENTITY % complexContentAttrs ''> ↑<!ENTITY % openContentAttrs ''>↑ <!ENTITY % simpleContentAttrs ''> <!ENTITY % extensionAttrs ''> <!ENTITY % elementAttrs ''> <!ENTITY % groupAttrs ''> <!ENTITY % allAttrs ''> <!ENTITY % choiceAttrs ''> <!ENTITY % sequenceAttrs ''> <!ENTITY % anyAttrs ''> <!ENTITY % anyAttributeAttrs ''> <!ENTITY % attributeAttrs ''> <!ENTITY % attributeGroupAttrs ''> <!ENTITY % uniqueAttrs ''> <!ENTITY % keyAttrs ''> <!ENTITY % keyrefAttrs ''> <!ENTITY % selectorAttrs ''> <!ENTITY % fieldAttrs ''> <!ENTITY % assertAttrs ''> ↓<!ENTITY % reportAttrs ''>↓ <!ENTITY % includeAttrs ''> <!ENTITY % importAttrs ''> <!ENTITY % redefineAttrs ''> <!ENTITY % notationAttrs ''> <!ENTITY % annotationAttrs ''> <!ENTITY % appinfoAttrs ''> <!ENTITY % documentationAttrs ''> <!ENTITY % complexDerivationSet "CDATA"> <!-- #all or space-separated list drawn from derivationChoice --> <!ENTITY % blockSet "CDATA"> <!-- #all or space-separated list drawn from derivationChoice + 'substitution' --> <!ENTITY % mgs '%all; | %choice; | %sequence;'> <!ENTITY % cs '%choice; | %sequence;'> <!ENTITY % formValues '(qualified|unqualified)'> <!ENTITY % attrDecls '((%attribute;| %attributeGroup;)*,(%anyAttribute;)?)'> <!ENTITY % assertions '(%assert;↓| %report;↓)*'> <!ENTITY % particleAndAttrs '(↑%openContent;?, ↑(%mgs; | %group;)?, %attrDecls;, %assertions;)'> <!-- This is used in part2 --> <!ENTITY % restriction1 '((%mgs; | %group;)?)'> %xs-datatypes; <!-- the duplication below is to produce an unambiguous content model which allows annotation everywhere --> <!ELEMENT %schema; ((%include; | %import; | %redefine; | %annotation;)*, ↑(%defaultOpenContent;, (%annotation;)*)?,↑ ((%simpleType; | %complexType; | %element; | %attribute; | %attributeGroup; | %group; | %notation; ), (%annotation;)*)* )> <!ATTLIST %schema; targetNamespace %URIref; #IMPLIED version CDATA #IMPLIED %nds; %URIref; #FIXED 'http://www.w3.org/2001/XMLSchema' xmlns CDATA #IMPLIED finalDefault %complexDerivationSet; '' blockDefault %blockSet; '' id ID #IMPLIED elementFormDefault %formValues; 'unqualified' attributeFormDefault %formValues; 'unqualified'↑ defaultAttributes CDATA #IMPLIED↑↑ defaultXPathDefaultNamespace CDATA '##local'↑ xml:lang CDATA #IMPLIED %schemaAttrs;> <!-- Note the xmlns declaration is NOT in the↑ ↑ schema for schema↓s↓↑ documents↑, because at the Infoset level where schemas operate, xmlns(:prefix) is NOT an attribute! --> <!-- The declaration of xmlns is a convenience for schema authors --> <!-- The id attribute here and below is for use in external references from non-schemas using simple fragment identifiers. It is NOT used for schema-to-schema reference, internal or external. --> ↑<!ELEMENT %defaultOpenContent; ((%annotation;)?, %any;)> <!ATTLIST %defaultOpenContent; appliesToEmpty (true|false) 'false' mode (interleave|suffix) 'interleave' id ID #IMPLIED %defaultOpenContentAttrs;>↑ <!-- a type is a named content type specification which allows attribute declarations--> <!-- --> <!ELEMENT %complexType; ((%annotation;)?, (%simpleContent;|%complexContent;| %particleAndAttrs;))> <!ATTLIST %complexType; name %NCName; #IMPLIED id ID #IMPLIED abstract %boolean; #IMPLIED final %complexDerivationSet; #IMPLIED block %complexDerivationSet; #IMPLIED mixed (true|false) 'false' ↑defaultAttributesApply %boolean; 'true'↑ %complexTypeAttrs;> <!-- particleAndAttrs is shorthand for a root type --> <!-- mixed is disallowed if simpleContent, overridden if complexContent has one too. --> <!-- If anyAttribute appears in one or more referenced attributeGroups and/or explicitly, the intersection of the permissions is used --> <!ELEMENT %complexContent; ((%annotation;)?, (%restriction;|%extension;))> <!ATTLIST %complexContent; mixed (true|false) #IMPLIED id ID #IMPLIED %complexContentAttrs;> ↑<!ELEMENT %openContent; ((%annotation;)?, (%any;)?)> <!ATTLIST %openContent; mode (none|interleave|suffix) 'interleave' id ID #IMPLIED %openContentAttrs;>↑ <!-- restriction should use the branch defined above, not the simple one from part2; extension should use the full model --> <!ELEMENT %simpleContent; ((%annotation;)?, (%restriction;|%extension;))> <!ATTLIST %simpleContent; id ID #IMPLIED %simpleContentAttrs;> <!-- restriction should use the simple branch from part2, not the one defined above; extension should have no particle --> <!ELEMENT %extension; ((%annotation;)?, (%particleAndAttrs;))> <!ATTLIST %extension; base %QName; #REQUIRED id ID #IMPLIED %extensionAttrs;> <!-- an element is declared by either: a name and a type (either nested or referenced via the type attribute) or a ref to an existing element declaration --> <!ELEMENT %element; ((%annotation;)?, (%complexType;| %simpleType;)?,↑ (%alternative;)*,↑ (%unique; | %key; | %keyref;)*)> <!-- simpleType or complexType only if no type|ref attribute --> <!-- ref not allowed at top level --> <!ATTLIST %element; name %NCName; #IMPLIED id ID #IMPLIED ref %QName; #IMPLIED type %QName; #IMPLIED minOccurs %nonNegativeInteger; #IMPLIED maxOccurs CDATA #IMPLIED nillable %boolean; #IMPLIED substitutionGroup %QName; #IMPLIED abstract %boolean; #IMPLIED final %complexDerivationSet; #IMPLIED block %blockSet; #IMPLIED default CDATA #IMPLIED fixed CDATA #IMPLIED form %formValues; #IMPLIED ↑targetNamespace %URIref; #IMPLIED↑ %elementAttrs;> <!-- type and ref are mutually exclusive. name and ref are mutually exclusive, one is required --> <!-- In the absence of type AND ref, type defaults to type of substitutionGroup, if any, else the ur-type, i.e. unconstrained --> <!-- default and fixed are mutually exclusive -->↑ <!ELEMENT %alternative; ((%annotation;)?, (%simpleType; | %complexType;)? > <!ATTLIST %alternative; test CDATA #IMPLIED type %QName; #IMPLIED xpathDefaultNamespace CDATA #IMPLIED id ID #IMPLIED > ↑ <!ELEMENT %group; ((%annotation;)?,(%mgs;)?)> <!ATTLIST %group; name %NCName; #IMPLIED ref %QName; #IMPLIED minOccurs %nonNegativeInteger; #IMPLIED maxOccurs CDATA #IMPLIED id ID #IMPLIED %groupAttrs;> <!ELEMENT %all; ((%annotation;)?, (%element;)*)> <!ATTLIST %all; minOccurs (1) #IMPLIED maxOccurs (1) #IMPLIED id ID #IMPLIED %allAttrs;> <!ELEMENT %choice; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)> <!ATTLIST %choice; minOccurs %nonNegativeInteger; #IMPLIED maxOccurs CDATA #IMPLIED id ID #IMPLIED %choiceAttrs;> <!ELEMENT %sequence; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)> <!ATTLIST %sequence; minOccurs %nonNegativeInteger; #IMPLIED maxOccurs CDATA #IMPLIED id ID #IMPLIED %sequenceAttrs;> <!-- an anonymous grouping in a model, or a top-level named group definition, or a reference to same --> <!-- Note that if order is 'all', group is not allowed inside. If order is 'all' THIS group must be alone (or referenced alone) at the top level of a content model --> <!-- If order is 'all', minOccurs==maxOccurs==1 on element/any inside --> <!-- Should allow minOccurs=0 inside order='all' . . . --> <!ELEMENT %any; (%annotation;)?> <!ATTLIST %any; namespace CDATA #IMPLIED notNamespace CDATA #IMPLIED notQName CDATA '' processContents (skip|lax|strict) 'strict' minOccurs %nonNegativeInteger; '1' maxOccurs CDATA '1' id ID #IMPLIED %anyAttrs;> <!-- namespace is interpreted as follows: ##any - - any non-conflicting WFXML at all ##other - - any non-conflicting WFXML from namespace other than targetNamespace ##local - - any unqualified non-conflicting WFXML/attribute one or - - any non-conflicting WFXML from more URI the listed namespaces references ##targetNamespace ##local may appear in the above list, with the obvious meaning --> <!-- notNamespace is interpreted as follows: ##local - - any unqualified non-conflicting WFXML/attribute one or - - any non-conflicting WFXML from more URI the listed namespaces references ##targetNamespace ##local may appear in the above list, with the obvious meaning --> <!ELEMENT %anyAttribute; (%annotation;)?> <!ATTLIST %anyAttribute; namespace CDATA #IMPLIED notNamespace CDATA #IMPLIED notQName CDATA '' processContents (skip|lax|strict) 'strict' id ID #IMPLIED %anyAttributeAttrs;> <!-- namespace and notNamespace are interpreted as for 'any' above --> <!-- simpleType only if no type|ref attribute --> <!-- ref not allowed at top level, name iff at top level --> <!ELEMENT %attribute; ((%annotation;)?, (%simpleType;)?)> <!ATTLIST %attribute; name %NCName; #IMPLIED id ID #IMPLIED ref %QName; #IMPLIED type %QName; #IMPLIED use (prohibited|optional|required) #IMPLIED default CDATA #IMPLIED fixed CDATA #IMPLIED form %formValues; #IMPLIED ↑targetNamespace %URIref; #IMPLIED↑ %attributeAttrs;> <!-- type and ref are mutually exclusive. name and ref are mutually exclusive, one is required --> <!-- default for use is optional when nested, none otherwise --> <!-- default and fixed are mutually exclusive --> <!-- type attr and simpleType content are mutually exclusive --> <!-- an attributeGroup is a named collection of attribute decls, or a reference thereto --> <!ELEMENT %attributeGroup; ((%annotation;)?, (%attribute; | %attributeGroup;)*, (%anyAttribute;)?) > <!ATTLIST %attributeGroup; name %NCName; #IMPLIED id ID #IMPLIED ref %QName; #IMPLIED %attributeGroupAttrs;> <!-- ref iff no content, no name. ref iff not top level --> <!-- better reference mechanisms --> <!ELEMENT %unique; ((%annotation;)?, %selector;, (%field;)+)> <!ATTLIST %unique; name %NCName; ↓#REQUIRED↓↑#IMPLIED↑ ↑ref %QName; #IMPLIED↑ id ID #IMPLIED↑ xpathDefaultNamespace CDATA #IMPLIED↑ %uniqueAttrs;> <!ELEMENT %key; ((%annotation;)?, %selector;, (%field;)+)> <!ATTLIST %key; name %NCName; ↓#REQUIRED↓↑#IMPLIED↑ ↑ref %QName; #IMPLIED↑ id ID #IMPLIED↑ xpathDefaultNamespace CDATA #IMPLIED↑ %keyAttrs;> <!ELEMENT %keyref; ((%annotation;)?, %selector;, (%field;)+)> <!ATTLIST %keyref; name %NCName; ↓#REQUIRED↓↑#IMPLIED↑ ↑ref %QName; #IMPLIED↑ refer %QName; ↓#REQUIRED↓↑#IMPLIED↑ id ID #IMPLIED↑ xpathDefaultNamespace CDATA #IMPLIED↑ %keyrefAttrs;> <!ELEMENT %selector; ((%annotation;)?)> <!ATTLIST %selector; xpath %XPathExpr; #REQUIRED id ID #IMPLIED %selectorAttrs;> <!ELEMENT %field; ((%annotation;)?)> <!ATTLIST %field; xpath %XPathExpr; #REQUIRED id ID #IMPLIED %fieldAttrs;> <!-- co-constraint assertions --> <!ELEMENT %assert; ((%annotation;)?)> <!ATTLIST %assert; test %XPathExpr; #REQUIRED id ID #IMPLIED↑ xpathDefaultNamespace CDATA #IMPLIED↑ %assertAttrs;> ↓<!ELEMENT %report; ((%annotation;)?)> <!ATTLIST %report; test %XPathExpr; #REQUIRED id ID #IMPLIED %reportAttrs;>↓ <!-- Schema combination mechanisms --> <!ELEMENT %include; (%annotation;)?> <!ATTLIST %include; schemaLocation %URIref; #REQUIRED id ID #IMPLIED %includeAttrs;> <!ELEMENT %import; (%annotation;)?> <!ATTLIST %import; namespace %URIref; #IMPLIED schemaLocation %URIref; #IMPLIED id ID #IMPLIED %importAttrs;> <!ELEMENT %redefine; (%annotation; | %simpleType; | %complexType; | %attributeGroup; | %group;)*> <!ATTLIST %redefine; schemaLocation %URIref; #REQUIRED id ID #IMPLIED %redefineAttrs;> <!ELEMENT %notation; (%annotation;)?> <!ATTLIST %notation; name %NCName; #REQUIRED id ID #IMPLIED public CDATA #REQUIRED system %URIref; #IMPLIED %notationAttrs;> <!-- Annotation is either application information or documentation --> <!-- By having these here they are available for datatypes as well as all the structures elements --> <!ELEMENT %annotation; (%appinfo; | %documentation;)*> <!ATTLIST %annotation; %annotationAttrs;> <!-- User must define annotation elements in internal subset for this to work --> <!ELEMENT %appinfo; ANY> <!-- too restrictive --> <!ATTLIST %appinfo; source %URIref; #IMPLIED id ID #IMPLIED %appinfoAttrs;> <!ELEMENT %documentation; ANY> <!-- too restrictive --> <!ATTLIST %documentation; source %URIref; #IMPLIED id ID #IMPLIED xml:lang CDATA #IMPLIED %documentationAttrs;> <!NOTATION XMLSchemaStructures PUBLIC 'structures' 'http://www.w3.org/2001/XMLSchema.xsd' > <!NOTATION XML PUBLIC 'REC-xml-1998-0210' 'http://www.w3.org/TR/1998/REC-xml-19980210' >
A specification of the import of Unique Particle Attribution (§3.8.6) which does not appeal to a processing model is difficult. What follows is intended as guidance, without claiming to be complete.
Two particles may ·validate· adjacent information items if they are separated by at most epsilon transitions in the most obvious transcription of a content model into a finite-state automaton.
A precise formulation of this constraint can also be offered in terms of operations on finite-state automaton: transcribe the content model into an automaton in the usual way using epsilon transitions for optionality and unbounded maxOccurs, unfolding other numeric occurrence ranges and treating the heads of ↓substitution groups↓↑·substitution groups·↑ as if they were choices over all elements in the group, but using not element QNames as transition labels, but rather pairs of element QNames and positions in the model. Determinize this automaton, treating wildcard transitions as opaque. Now replace all QName+position transition labels with the element QNames alone. If the result has any states with two or more identical-QName-labeled transitions from it, or two wildcard transitions whose intentional intersection is non-empty, the model does not satisfy the Unique Attribution constraint.
http://www.w3.org/XML/XMLSchema
http://www.w3.org/XML/XMLSchema/v1.0
http://www.w3.org/XML/XMLSchema/v1.1
http://www.w3.org/XML/XMLSchema/v1.0/1e
http://www.w3.org/XML/XMLSchema/v1.0/2e
http://www.w3.org/XML/XMLSchema/v1.1/1e
http://www.w3.org/XML/XMLSchema/v1.0/1e/19990506
http://www.w3.org/XML/XMLSchema/v1.0/1e/19990924
http://www.w3.org/XML/XMLSchema/v1.0/1e/19991105
http://www.w3.org/XML/XMLSchema/v1.0/1e/19991217
http://www.w3.org/XML/XMLSchema/v1.0/1e/20000225
http://www.w3.org/XML/XMLSchema/v1.0/1e/20000407
http://www.w3.org/XML/XMLSchema/v1.0/1e/20000922
http://www.w3.org/XML/XMLSchema/v1.0/1e/20001024
http://www.w3.org/XML/XMLSchema/v1.0/1e/20010316
http://www.w3.org/XML/XMLSchema/v1.0/1e/20010330
http://www.w3.org/XML/XMLSchema/v1.0/1e/20010502
http://www.w3.org/XML/XMLSchema/v1.0/2e/20040318
http://www.w3.org/XML/XMLSchema/v1.0/2e/20041028
http://www.w3.org/XML/XMLSchema/v1.1/1e/20040716
http://www.w3.org/XML/XMLSchema/v1.1/1e/20050224
http://www.w3.org/XML/XMLSchema/v1.1/1e/20060116
http://www.w3.org/XML/XMLSchema/v1.1/1e/20060217
http://www.w3.org/XML/XMLSchema/v1.1/1e/20060330
http://www.w3.org/XML/XMLSchema/v1.1/1e/20060831
The following contributed material to version 1.0 of this specification:
David Fallside, IBM
Scott Lawrence, Agranat Systems
Andrew Layman, Microsoft
Eve L. Maler, Sun Microsystems
Asir S. Vedamuthu, webMethods, Inc
The Working Group thanks the members of other W3C Working Groups and industry experts in other forums who have contributed directly or indirectly to the creation of this document and its predecessor.
At the time this Working Draft is published, the members in good standing of the XML Schema Working Group are:
The XML Schema Working Group has benefited in its work from the participation and contributions of a number of people who are no longer members of the Working Group in good standing at the time of publication of this Working Draft. Their names are given below. In particular we note with sadness the accidental death of Mario Jeckle shortly before publication of the first Working Draft of ↓XML Schema↓↑XSDL↑ 1.1. Affiliations given were current at the time of their work with the WG.