Please refer to the errata for this document, which may include some normative corrections.
This document is also available in these non-normative formats: XML, XHTML with visible change markup, Independent copy of the schema for schema documents, and Independent copy of the DTD for schema documents. See also translations.
Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
XML Schema: Structures specifies the XML Schema definition language, which offers facilities for describing the structure and constraining the contents of XML 1.0 documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in XML 1.0 and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML 1.0 document type definitions (DTDs). This specification depends on XML Schema 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 W3C Recommendation, which forms part of the Second Edition of XML Schema. This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
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 are discussed in the XML Schema Requirements 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 under the 24 January 2002 Current Patent Practice (CPP) as amended by the W3C Patent Policy Transition Procedure. The Working Group maintains a public list of patent disclosures relevant to this document; 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) with respect to this specification should 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/2001/05/xmlschema-translations.
This second edition is not a new version, it merely incorporates the changes dictated by the corrections to errors found in the first edition as agreed by the XML Schema Working Group, as a convenience to readers. A separate list of all such corrections is available at http://www.w3.org/2001/05/xmlschema-errata.
The errata list for this second edition is available at http://www.w3.org/2004/03/xmlschema-errata.
Please report errors in this document to www-xml-schema-comments@w3.org (archive).
1 Introduction
1.1 Purpose
1.2 Dependencies on Other Specifications
1.3 Documentation Conventions and Terminology
2 Conceptual Framework
2.1 Overview of XML Schema
2.2 XML Schema Abstract Data Model
2.3 Constraints and Validation Rules
2.4 Conformance
2.5 Names and Symbol Spaces
2.6 Schema-Related Markup in
Documents Being Validated
2.7 Representation of Schemas on the World Wide Web
3 Schema Component Details
3.1 Introduction
3.2 Attribute Declarations
3.3 Element Declarations
3.4 Complex Type Definitions
3.5 AttributeUses
3.6 Attribute Group Definitions
3.7 Model Group Definitions
3.8 Model Groups
3.9 Particles
3.10 Wildcards
3.11 Identity-constraint Definitions
3.12 Notation Declarations
3.13 Annotations
3.14 Simple Type Definitions
3.15 Schemas as a Whole
4 Schemas and Namespaces: Access and Composition
4.1 Layer 1: Summary of the Schema-validity Assessment Core
4.2 Layer 2: Schema Documents, Namespaces and Composition
4.3 Layer 3: Schema Document Access and Web-interoperability
5 Schemas and Schema-validity Assessment
5.1 Errors in Schema Construction and Structure
5.2 Assessing Schema-Validity
5.3 Missing Sub-components
5.4 Responsibilities of Schema-aware Processors
A Schema for Schemas (normative)
B References (normative)
C Outcome Tabulations (normative)
C.1 Validation Rules
C.2 Contributions to the post-schema-validation infoset
C.3 Schema Representation Constraints
C.4 Schema Component Constraints
D Required Information Set Items and Properties (normative)
E Schema Components Diagram (non-normative)
F Glossary (non-normative)
G DTD for Schemas (non-normative)
H Analysis of the Unique Particle Attribution Constraint (non-normative)
I References (non-normative)
J Acknowledgements (non-normative)
This document sets out the structural part (XML Schema: Structures) of the XML Schema definition language.
Chapter 2 presents a Conceptual Framework (§2) for XML Schemas, including an introduction to the nature of XML Schemas and an introduction to the XML Schema 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 XML Schema for an XML Schema document type, along with a detailed mapping between the elements and attribute vocabulary of this representation and the components and properties of the abstract model.
Chapter 4 presents Schemas and Namespaces: Access and Composition (§4), including the connection between documents and schemas, the import, inclusion and redefinition of declarations and definitions and the foundations of schema-validity assessment.
Chapter 5 discusses Schemas and Schema-validity Assessment (§5), including the overall approach to schema-validity assessment of documents, and responsibilities of schema-aware processors.
The normative appendices include a Schema for Schemas (normative) (§A) for the XML representation of schemas and References (normative) (§B).
The non-normative appendices include the DTD for Schemas (non-normative) (§G) and a Glossary (non-normative) (§F).
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 purpose of XML Schema: Structures is to define the nature of XML schemas and their component parts, provide an inventory of XML markup constructs with which to represent schemas, and define the application of schemas to XML documents.
The purpose of an XML Schema: Structures 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 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: 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 to express syntactic, structural and value constraints applicable to its document instances. The XML Schema: Structures 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. Some applications may require constraint capabilities not expressible in this language, and so may need to perform their own additional validations.
The definition of XML Schema: Structures depends on the following specifications: [XML-Infoset], [XML-Namespaces], [XPath], and [XML Schemas: Datatypes].
See Required Information Set Items and Properties (normative) (§D) for a tabulation of the information items and properties specified in [XML-Infoset] which this specification requires as a precondition to schema-aware processing.
The section introduces the highlighting and typography as used in this document to present technical material.
Special terms are defined at their point of introduction in the text. For example [Definition:] a term is something used with a special meaning. The definition is labeled as such and the term it defines is displayed in boldface. The end of the definition is not specially marked in the displayed or printed text. Uses of defined terms are links to their definitions, set off with middle dots, for instance ·term·.
Non-normative examples are set off in boxes and accompanied by a brief explanation:
<schema targetNamespace="http://www.example.com/XMLSchema/1.0/mySchema">
The definition of each kind of schema component consists of a list of its properties and their contents, followed by descriptions of the semantics of the properties:
References to properties of schema components are links to the relevant definition as exemplified above, set off with curly braces, for instance {example property}.
The correspondence between an element information item which is part of the XML representation of a schema and one or more schema components is presented in a tableau which illustrates the element information item(s) involved. This is followed by a tabulation of the correspondence between properties of the component and properties of the information item. Where context may determine which of several different components may arise, 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 Schemas: 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 Item<example
count = integer
size = (large | medium | small) : medium>
Content: (all | any*)
</example>
Example Schema Component | ||||
---|---|---|---|---|
|
References to elements in the text are links to the relevant illustration as exemplified above, set off with angle brackets, for instance <example>.
References to properties of information items as defined in [XML-Infoset] are notated as links to the relevant section thereof, set off with square brackets, for example [children].
Properties which this specification defines for information items are introduced as follows:
References to properties of information items defined in this specification are notated as links to their introduction as exemplified above, set off with square brackets, for example [new property].
The following highlighting is used for non-normative commentary in this document:
Following [XML 1.0 (Second Edition)], within normative prose in this specification, the words may and must are defined as follows:
Note however that this specification provides a definition of error and of conformant processors' responsibilities with respect to errors (see Schemas and Schema-validity Assessment (§5)) which is considerably more complex than that of [XML 1.0 (Second Edition)].
This chapter gives an overview of XML Schema: 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 read [XML Schema: Primer] for a tutorial introduction, and only then consult the sub-sections of Schema Component Details (§3) named XML Representation of ... for the details.
An XML Schema consists 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 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. [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.
Schema-validity assessment has two aspects:
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.0 (Second Edition)] and [XML-Namespaces]. 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.0 (Second Edition)]) and namespace conformance (as defined in [XML-Namespaces]) for all candidates for ·assessment· and for all ·schema documents·.
Just as [XML 1.0 (Second Edition)] and [XML-Namespaces] can be described in terms of information items, XML Schemas can be described in terms of an abstract data model. In defining XML Schemas in terms of an abstract data model, this specification rigorously specifies the information which must be available to a conforming XML Schema 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 the abstract data model of the schema. [Definition:] An XML Schema is a set of ·schema components·. There are 13 kinds of component in all, falling into three groups. The primary components, which may (type definitions) or must (element and attribute declarations) have names are as follows:
The secondary components, which must have names, are as follows:
Finally, the "helper" components provide small parts of other components; they are not independent of their context:
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 have and be identified by names, which are NCNames as defined by [XML-Namespaces].
[Definition:] Several kinds of component have a target namespace, which is either ·absent· or a namespace name, also as defined by [XML-Namespaces]. 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 ·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· 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·, every ·type definition· is, by construction, either a ·restriction· or an ·extension· of some other type definition. The graph of these relationships forms a tree known as the Type Definition Hierarchy.
[Definition:] A type definition whose declarations or facets are in a one-to-one relation with those of another specified type definition, with each in turn restricting the possibilities of the one it corresponds to, is said to be a restriction. The specific restrictions 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 members of 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 type definition used as the basis for an ·extension· or ·restriction· is known as the base type definition of that definition.
A simple type definition is a set of constraints on strings and information about the values they encode, applicable to the ·normalized value· of an attribute information item or of an element information item with no element children. Informally, it applies to the values of attributes and the text-only content of elements.
Each simple type definition, whether built-in (that is, defined in [XML Schemas: Datatypes]) or user-defined, is a ·restriction· of some particular simple ·base type definition·. For the built-in primitive type definitions, this is [Definition:] the simple ur-type definition, a special restriction of the ·ur-type definition·, whose name is anySimpleType in the XML Schema namespace. 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 mapping from lexical space to value space is unspecified for items whose type definition is the ·simple ur-type definition·. Accordingly this specification does not constrain processors' behaviour in areas where this mapping is implicated, for example checking such items against enumerations, constructing default attributes or elements whose declared type definition is the ·simple ur-type definition·, checking identity constraints involving such items.
Simple types may also be defined 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.14) and [XML Schemas: Datatypes]. The latter also defines an extensive inventory of pre-defined simple types.
A complex type definition is a set of attribute declarations and a content type, applicable to the [attributes] and [children] of an element information item respectively. The content type may require the [children] to contain neither element nor character information items (that is, to be empty), 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.
Each complex type definition other than the ·ur-type definition· is either
or
A complex type which extends another does so by having additional content model particles at the end of the other definition's content model, or by having additional attribute declarations, or both.
For detailed information on complex type definitions, see Complex Type Definitions (§3.4).
There are three kinds of declaration component: element, attribute, and notation. Each is described in a section below. Also included is a discussion of element substitution groups, which is a feature provided in conjunction with element declarations.
An element declaration is an association of a name with a type definition, either simple or complex, an (optional) default value and a (possibly empty) set of identity-constraint definitions. The association is either global or scoped to a containing complex type definition. A top-level element declaration with name 'A' is broadly comparable to a pair of DTD declarations as follows, where the associated type definition fills in the ellipses:
<!ELEMENT A . . .> <!ATTLIST A . . .>
Element declarations contribute to ·validation· as part of model group ·validation·, when their defaults and type components are checked against an element information item with a matching name and namespace, and by triggering identity-constraint definition ·validation·.
For detailed information on element declarations, see Element Declarations (§3.3).
In XML 1.0, the name and content of an element must correspond exactly to the element type referenced in the corresponding content model.
[Definition:] Through the new mechanism of element substitution groups, XML Schemas 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. Other top-level element declarations, regardless of target namespace, can be designated as members of the substitution group headed by this element. In a suitably enabled content model, a reference to the head ·validates· not just the head itself, but elements corresponding to any other member of the substitution group as well.
All such members must have type definitions which are either the same as the head's type definition or restrictions or extensions of it. Therefore, although the names of elements can vary widely as new namespaces and members of the substitution group are defined, the content of member elements is strictly limited according to the type definition of the substitution group head.
Note that element substitution groups are not represented as separate components. They are specified in the property values for element declarations (see Element Declarations (§3.3)).
An attribute declaration is an association between a name and a simple type definition, together with occurrence information and (optionally) a default value. The association is either global, or local to its containing complex type definition. Attribute declarations contribute to ·validation· as part of complex type definition ·validation·, when their occurrence, defaults and type components are checked against an attribute information item with a matching name and namespace.
For detailed information on attribute declarations, see Attribute Declarations (§3.2).
A notation declaration is an association between a name and an identifier for a
notation. For an attribute 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.12).
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:
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.
[Definition:] A particle can be used in a complex type definition to constrain the ·validation· of the [children] of an element information item; such a particle is called a content model.
For detailed information on particles, see Particles (§3.9).
An attribute use plays a role similar to that of a particle, but for attribute declarations: an attribute declaration within a complex type definition is embedded within an attribute use, which specifies whether the declaration requires or merely allows its attribute, and whether it has a default or fixed value.
A wildcard is a special kind of particle which matches element and attribute information items dependent on their namespace name, independently of 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] 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).
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.13).
The [XML 1.0 (Second Edition)] 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 1.0
validation augments the XML 1.0 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 1.0 left implicit.
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 provide conformance to the XML Representation of Schemas. Such processors must, when processing schema documents, completely and correctly implement 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:] Fully conforming processors are network-enabled processors which are not only both ·minimally conforming· and ·in conformance to the XML Representation of Schemas·, but which additionally must be capable of accessing schema documents from the World Wide Web according to 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 Abstract Data Model (§2.2), most schema components (may) have ·names·. If all such names were assigned from the same "pool", then it would be impossible to have, for example, a simple type definition and an element declaration both with the name "title" in a given ·target namespace·.
Therefore [Definition:] this specification introduces the term symbol space to denote a collection of names, each of which is unique with respect to the others. A symbol space is similar to the non-normative concept of namespace partition introduced in [XML-Namespaces]. There is a single distinct symbol space within a given ·target namespace· for each kind of definition and declaration component identified in XML Schema 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: 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. 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).
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.15.3) for
the means by which the ·QName· is
associated with a type definition.
XML Schema: Structures introduces a mechanism for signaling that an element should
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
·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 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.1)), 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).
The following sections provide full details on the composition of all schema components, together with their XML representations and their contributions to ·assessment·. Each section is devoted to a single component, with separate subsections for
The sub-sections immediately below introduce conventions and terminology used throughout the component sections.
Components are defined in terms of their properties, and each property in turn is defined by giving its range, that is the values it may have. This can be understood as defining a schema as a labeled directed graph, where the root is a schema, every other vertex is a schema component or a literal (string, boolean, number) 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· may not exist, so in some cases re-entrant chains of properties must exist. Equality of components for the purposes of this specification is always defined as equality of names (including target namespaces) within symbol spaces.
[Definition:] Throughout this specification, the term absent is used as a distinguished property value denoting absence.
Any property not identified as optional is required to be 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.0 (Second Edition)].
The principal purpose of XML Schema: 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 Schemas (normative) (§A) and DTD for Schemas (non-normative) (§G)) and
schema components. All the element information items in the XML representation
of a schema must be in the XML Schema namespace, that is their [namespace name] must be 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.
Two aspects of the XML representations of components presented in the following sections are constant across them all:
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 Schemas (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 Schemas (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 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 be violated if one or more references cannot be resolved. This specification addresses the matter of missing components in a uniform manner, described in Missing Sub-components (§5.3): no mention of handling missing components will be found in the individual component descriptions below.
Forward reference to named definitions and declarations is allowed, both within and between ·schema documents·. By the time the component corresponding to an XML representation which contains a forward reference is actually needed for ·validation· an appropriately-named component may 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.
[Definition:] The normalized value of an element or attribute information item is an ·initial value· whose white space, if any, has been normalized according to the value of the whiteSpace facet of the simple type definition used in its ·validation·:
#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·, the ·normalized value· must be determined as in the preserve case above.
There are three alternative validation rules which may 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 2.2).
These three levels of normalization correspond to the processing mandated in XML 1.0 for element content, CDATA attribute content and tokenized attributed content, respectively. See Attribute Value Normalization in [XML 1.0 (Second Edition)] 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} of 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 identified by the {scope} 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 1.0 default and #FIXED
attribute values. default specifies that the attribute is to appear unconditionally in
the ·post-schema-validation infoset·, with the supplied value used
whenever the attribute is not actually present; fixed indicates that the attribute value if present must equal the supplied
constraint value, and if absent receives the supplied value as for
default. Note that it is values that are supplied and/or
checked, not strings.
See Annotations (§3.13) for information on the role of the {annotation} 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 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
type = QName
use = (optional | prohibited | required) : optional
{any attributes with non-schema namespace . . .}>
Content: (annotation?, simpleType?)
</attribute>
Attribute Declaration Schema Component | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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):Attribute Use Schema Component | ||||||||
---|---|---|---|---|---|---|---|---|
|
Attribute Declaration Schema Component | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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):Attribute Use Schema Component | ||||||||
---|---|---|---|---|---|---|---|---|
|
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 this 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
must be present, but not both.type
and <simpleType>
must not both be present.All attribute declarations (see Attribute Declarations (§3.2)) must satisfy the following constraints.
http://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.There are four attribute declarations present in every schema by definition:
Attribute Declaration for the 'type' attribute | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Attribute Declaration for the 'nil' attribute | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Attribute Declaration for the 'schemaLocation' attribute | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Attribute Declaration for the 'noNamespaceSchemaLocation' attribute | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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} of 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 identified by the {scope} property. This property is ·absent· in the case of declarations within named model groups: their scope is 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· if it satisfies 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·.
If {nillable} is true, then an element may
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 default is specified, and if the element being ·validated· is empty, then the canonical form of the supplied constraint value becomes the [schema normalized value] of the ·validated· element in the ·post-schema-validation infoset·. If fixed is specified, then the element's content must either be empty, in which case fixed behaves as default, or its value must match the supplied constraint value.
{identity-constraint definitions} express constraints establishing uniquenesses and reference relationships among the values of related elements and attributes. See Identity-constraint Definitions (§3.11).
Element declarations are potential members of the substitution group, if any, identified by {substitution group affiliation}. Potential membership is transitive but not symmetric; an element declaration is a potential member of any group of which its {substitution group affiliation} is a potential member. Actual membership may be blocked by the effects of {substitution group exclusions} or {disallowed substitutions}, see below.
An empty {substitution group exclusions} allows a declaration to be nominated as the {substitution group affiliation} of other element declarations having the same {type definition} or types 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 may 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 headed by the declared element. If {disallowed substitutions} is empty, then all derived types and substitution group members are allowed.
Element declarations for which {abstract} is true can appear in content models only when substitution is allowed; such declarations may not themselves ever be used to ·validate· element content.
See Annotations (§3.13) for information on the role of the {annotation} property.
The XML representation for an element declaration schema component is an <element> element information item. It specifies a type definition for an element either by reference or explicitly, and may provide occurrence and default information. The correspondences between the properties of the information item 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 = QName
type = QName
{any attributes with non-schema namespace . . .}>
Content: (annotation?, ((simpleType | complexType)?, (unique | key | keyref)*))
</element>
Element Declaration Schema Component | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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):Particle Schema Component | ||||||||
---|---|---|---|---|---|---|---|---|
|
Element Declaration Schema Component | ||||||
---|---|---|---|---|---|---|
|
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):Particle Schema Component | ||||||||
---|---|---|---|---|---|---|---|---|
|
<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 this 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, otherwise the ·ur-type definition·. 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>
myLocalElement
within
contextOne
will be constrained by myFirstType
,
while those within contextTwo
will be constrained by
mySecondType
. <xs:complexType name="facet"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="value" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="facet" type="xs:facet" abstract="true"/> <xs:element name="encoding" substitutionGroup="xs:facet"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:facet"> <xs:sequence> <xs:element ref="annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="value" type="xs:encodings"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="period" substitutionGroup="xs:facet"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:facet"> <xs:sequence> <xs:element ref="annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="value" type="xs:duration"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <xs:complexType name="datatype"> <xs:sequence> <xs:element ref="facet" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="optional"/> . . . </xs:complexType>
facet
type is defined
and the facet
element is declared to use it. The facet
element is abstract -- it's
only defined to stand as the head for a substitution group. Two further
elements are declared, each a member of the facet
substitution group. Finally a type is defined which refers to facet
, thereby
allowing either period
or encoding
(or
any other member of the group).default
and fixed
must not both be present.ref
or name
must be present, but not both.ref
is present, then all of <complexType>,
<simpleType>, <key>, <keyref>,
<unique>, nillable
, default
,
fixed
, form
, block
and type
must be absent,
i.e. only minOccurs
, maxOccurs
, id
are
allowed in addition to ref
, along with <annotation>.http://www.w3.org/2001/XMLSchema-instance
and whose [local name] is nil
.true
, then
all of the following must be true:http://www.w3.org/2001/XMLSchema-instance
and whose [local name] is type
, then
all of the following must be true:http://www.w3.org/2001/XMLSchema-instance
and whose [local name] is one of type
, nil
, schemaLocation
or noNamespaceSchemaLocation
.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
.xsi:type
[attribute] is involved, however, clause 1.2 takes precedence,
as is made clear in Element Locally Valid (Element) (§3.3.4).All element declarations (see Element Declarations (§3.3)) must satisfy the following constraint.
The following constraints define relations appealed to elsewhere in this specification.
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:
Complex types 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·, 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 (§4.2.3) 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.
Complex types for which {abstract} is true must not be used as the {type definition} for the ·validation· of element information items. It follows that they 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 {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.
{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}. Informally, the specific values of {attribute wildcard} are interpreted as follows:
See Element Locally Valid (Complex Type) (§3.4.4) and Wildcard allows Namespace Name (§3.10.4) for formal details of attribute wildcard ·validation·.
{content type} determines the ·validation· of [children] of element information items. Informally:
{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 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.
See Annotations (§3.13) 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 simple type definition {content type} 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
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (simpleContent | complexContent | ((group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?))))
</complexType>
Complex Type Definition Schema Component | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
<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 | length | minLength | maxLength | enumeration | whiteSpace | pattern)*)?, ((attribute | attributeGroup)*, anyAttribute?))
</restriction>
<extension
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation?, ((attribute | attributeGroup)*, anyAttribute?))
</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))
)
: ##any
processContents = (lax | skip | strict) : strict
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</anyAttribute>
Complex Type Definition with simple content Schema Component | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
<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?, (group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?))
</restriction>
<extension
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation?, ((group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?)))
</extension>
Complex Type Definition with complex content Schema Component | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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:number"/> </xs:complexType>
mixed
attribute appearing on complexType
itself.base
[attribute] must be a complex type definition;base
[attribute] must be
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.http://www.w3.org/2001/XMLSchema-instance
and whose [local name] is one of type
, nil
, schemaLocation
or noNamespaceSchemaLocation
,
the appropriate case among the following
must be true:All complex type definitions (see Complex Type Definitions (§3.4)) must satisfy the following constraints.
The following constraint defines a relation appealed to elsewhere in this specification.
xsi:type
or
substitution groups), that the type used is actually derived from the expected
type, and that that derivation does not involve a form of derivation which was
ruled out by the expected type.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· present in every schema by definition. It has the following properties:
Complex Type Definition of the Ur-Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The mixed
content specification together with the
lax wildcard and attribute specification produce the defining property for the
·ur-type definition·, namely that every type
definition is (eventually) a restriction
of the ·ur-type definition·: its permissions and requirements are
(nearly) the least restrictive possible.
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:number" 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.
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).
All attribute uses (see AttributeUses (§3.5)) must satisfy the following constraints.
A schema can name a group of attribute declarations so that they may be incorporated as a group into complex type definitions.
Attribute group definitions do not participate in ·validation· as such, but the {attribute uses} and {attribute wildcard} of one or more complex type definitions may be constructed in whole or part by reference to an attribute group. Thus, attribute group definitions provide a replacement for some uses of XML's parameter entity facility. Attribute group definitions are provided primarily for reference from the XML representation of schema components (see <complexType> and <attributeGroup>).
<xs:attributeGroup name="myAttrGroup"> <xs:attribute . . ./> . . . </xs:attributeGroup> <xs:complexType name="myelement"> . . . <xs:attributeGroup ref="myAttrGroup"/> </xs:complexType>
The 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·. See References to schema components across namespaces (§4.2.3) 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.13) for information on the role of the {annotation} 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>
Attribute Group Definition Schema Component | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 to the component corresponding to this <attributeGroup>. Indirect circularity is also ruled out. That is, when QName resolution (Schema Document) (§3.15.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 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 (§2.2.3.1). 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·. See References to schema components across namespaces (§4.2.3) for the use of component identifiers when importing one schema into another.
Model group definitions per se do not participate in ·validation·, but the {term} of a particle may correspond in whole or in part to a model group from a model group definition.
{model group} is the Model Group (§2.2.3.1) for which the model group definition provides a name.
See Annotations (§3.13) for information on the role of the {annotation} 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:Model Group Definition Schema Component | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
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):Particle Schema Component | ||||||||
---|---|---|---|---|---|---|---|---|
|
The name of this section is slightly misleading, in that the second, un-named,
case above (with a
ref
and no name
) is not really a named model
group at all, but a reference to one. Also note that in the first (named)
case above no reference is made to minOccurs
or
maxOccurs
: this is because the schema for schemas does not allow
them on the child of <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> should 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.14)), the sequence of element information item [children] content may be specified in more detail with a model group. Because the {term} property of a particle can be a model group, and model groups contain particles, model groups can indirectly contain other model groups; the grammar for content models is therefore recursive.
<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:
specifies a sequential (sequence), disjunctive (choice) or conjunctive (all) interpretation of the {particles}. This in turn determines whether the element information item [children] ·validated· by the model group must:
=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.13) for information on the role of the {annotation} 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*)
</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):Particle Schema Component | ||||||||
---|---|---|---|---|---|---|---|---|
|
Model Group Schema Component | ||||||||
---|---|---|---|---|---|---|---|---|
|
n
sub-sequences where n
is the length of {particles} such that each of the sub-sequences in order is ·valid·
with respect to the corresponding particle in the {particles} as defined in Element Sequence Locally Valid (Particle) (§3.9.4).n
sub-sequences where n
is the length of {particles} such that there is a one-to-one mapping between the sub-sequences and the {particles} where each sub-sequence is ·valid· with respect to the corresponding particle as defined in Element Sequence Locally Valid (Particle) (§3.9.4).0
), and each is ·valid· with respect to its corresponding declaration. The elements can occur in arbitrary order.All model groups (see Model Groups (§3.8)) must satisfy the following constraints.
=1
which is part of a pair which constitutes the {content type} of a
complex type definition.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.
<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}.
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.
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.The approach to defining a type by restricting another type definition set out here is designed to ensure that types defined in this way are guaranteed to be a subset of the type they restrict. This is accomplished by requiring a clear mapping between the components of the base type definition and the restricting type definition. Permissible mappings are set out below via a set of recursive definitions, bottoming out in the obvious cases, e.g. where an (restricted) element declaration corresponds to another (base) element declaration with the same name and type but the same or wider range of occurrence.
1
for each of the declarations in its ·substitution group·.0
.Base Particle | |||||||
---|---|---|---|---|---|---|---|
elt | any | all | choice | sequence | |||
Derived Particle | elt | NameAnd- TypeOK | NSCompat | Recurse- AsIfGroup | Recurse- AsIfGroup | RecurseAs- IfGroup | |
any | Forbidden | NSSubset | Forbidden | Forbidden | Forbidden | ||
all | Forbidden | NSRecurse- CheckCardinality | Recurse | Forbidden | Forbidden | ||
choice | Forbidden | NSRecurse- CheckCardinality | Forbidden | RecurseLax | Forbidden | ||
seq- uence | Forbidden | NSRecurse- CheckCardinality | Recurse- Unordered | MapAndSum | Recurse |
1
and with {particles} consisting of a single particle
the same as the element declaration must be a ·valid restriction· of the group as defined by Particle Derivation OK (All:All,Sequence:Sequence -- Recurse) (§3.9.6), Particle Derivation OK (Choice:Choice -- RecurseLax) (§3.9.6) or Particle Derivation OK (All:All,Sequence:Sequence -- Recurse) (§3.9.6), depending on whether the group is all, choice or sequence.Note:
The exception to the third clause above for derivations from the ·ur-type definition· is necessary as its wildcards have a {process contents} of lax, so without this exception, no use of wildcards with {process contents} of skip would be possible.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 name, but independently of their local name.
<xs:any processContents="skip"/> <xs:any namespace="##other" processContents="lax"/> <xs:any namespace="http://www.w3.org/1999/XSL/Transform"/> <xs:any namespace="##targetNamespace"/> <xs:anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/>
The wildcard schema component has the following properties:
{namespace constraint} provides for ·validation· of attribute and element items that:
{process contents} controls the impact on ·assessment· of the information items allowed by wildcards, as follows:
xsi:type
, and the item
must be ·valid· as appropriate.
See Annotations (§3.13) for information on the role of the {annotation} property.
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))
)
: ##any
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):Particle Schema Component | ||||||||
---|---|---|---|---|---|---|---|---|
|
Wildcard Schema Component | ||||||||
---|---|---|---|---|---|---|---|---|
|
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 either an explicit particle and a wildcard, or one of two wildcards, within the content model of a type, that model is in error.
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:
Identity-constraint definitions are identified by their {name} and {target namespace}; Identity-constraint definition identities must be unique within an ·XML Schema·. See References to schema components across namespaces (§4.2.3) for the use of component identifiers when importing one schema into another.
Informally, {identity-constraint category} identifies the Identity-constraint definition as playing one of three roles:
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 also serve as a key. Each constraint declaration has a name, which exists in a
single symbol space for constraints. The equality and inequality conditions
appealed to in checking these constraints apply to the value of
the fields selected, so that for example 3.0
and 3
would be conflicting keys if they were both number, but non-conflicting if
they were both strings, or one was a string and one a number. Values of
differing type can only be equal if one type is derived from the other, and the
value is in the value space of both.
Overall the augmentations to XML's ID/IDREF
mechanism are:
{selector} specifies a restricted XPath ([XPath]) expression relative to instances of the element being declared. This must identify a node set of subordinate elements (i.e. 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.13) for information on the role of the {annotation} 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
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (selector, field+))
</unique>
<key
id = ID
name = NCName
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (selector, field+))
</key>
<keyref
id = ID
name = NCName
refer = QName
{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>
Identity-constraint Definition Schema Component | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
<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.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.Notation declarations reconstruct XML 1.0 NOTATION declarations.
<xs:notation name="jpeg" public="image/jpeg" system="viewer.exe">
The notation declaration schema component has the following properties:
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.
See Annotations (§3.13) for information on the role of the {annotation} 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>
Notation Declaration Schema Component | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
<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.12)) 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 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.
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>
Annotation Schema Component | ||||||||
---|---|---|---|---|---|---|---|---|
|
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}.
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.13)) must satisfy the following constraint.
Simple type definitions provide for constraining character information item [children] of element and attribute information items.
<xs:simpleType name="fahrenheitWaterTemp"> <xs:restriction base="xs:number"> <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:
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·, 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 (§4.2.3) 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 Schemas: 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 one of the built-in primitive datatypes, or a list or union type definition which is not itself derived by restriction from a list or union respectively. 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 Schemas: 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 Schemas: 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 Schemas: 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· must not be named as the ·base type definition· of any user-defined atomic simple type definitions: as it has no constraining facets, this would be incoherent.
See Annotations (§3.13) for information on the role of the {annotation} property.
simpleType
Element Information Item<simpleType
final =
(#all | List of (list | union | restriction))
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 | 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>
Simple Type Definition Schema Component | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Atomic Simple Type Definition Schema Component | ||||||
---|---|---|---|---|---|---|
|
List Simple Type Definition Schema Component | ||||||
---|---|---|---|---|---|---|
|
Union Simple Type Definition Schema Component | ||||||
---|---|---|---|---|---|---|
|
base
[attribute] or a <simpleType>
among its [children], but not both.itemType
[attribute] or a <simpleType>
among its [children], but not both.memberTypes
[attribute] at any depth which resolve to the component corresponding to the <simpleType>.All simple type definitions other than the ·simple ur-type definition· and the built-in primitive datatype definitions (see Simple Type Definitions (§3.14)) must satisfy both the following constraints.
The following constraint defines relations appealed to elsewhere in this specification.
There is a simple type definition nearly equivalent to the ·simple ur-type definition· present in every schema by definition. It has the following properties:
Simple Type Definition of the Ur-Type | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The ·simple ur-type definition· 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 the ·ur-type definition·, which is its {base type definition}. This is why the ·simple ur-type definition· is exempted from the first clause of Simple Type Definition Properties Correct (§3.14.6), which would otherwise bar it because of its derivation from a complex type definition and absence of {variety}.
Simple type definitions for all the built-in primitive datatypes, namely string, boolean, float,
double, number, dateTime, duration,
time, date, gMonth, gMonthDay, gDay, gYear, gYearMonth, hexBinary, base64Binary, anyURI (see the Primitive
Datatypes section of [XML Schemas: Datatypes]) are present by definition in every schema. All
are in the XML Schema {target namespace} (namespace
name http://www.w3.org/2001/XMLSchema
), have an atomic {variety} with an empty
{facets} and the ·simple ur-type definition· as
their ·base type definition· and themselves as {primitive type definition}.
Similarly, simple type definitions for all the built-in derived datatypes (see the Derived Datatypes section of [XML Schemas: Datatypes]) are present by definition in every schema, with properties as specified in [XML Schemas: Datatypes] and as represented in XML in Schema for Schemas (normative) (§A).
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.3).
schema
Element Information Item<schema
attributeFormDefault = (qualified | unqualified) : unqualified
blockDefault =
(#all | List of (extension | restriction | substitution))
: ''
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)*, (((simpleType | complexType | group | attributeGroup) | element | attribute | notation), annotation*)*)
</schema>
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 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 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.
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 (§4.2.3)) from an external schema (which 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]. 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 Schemas: Datatypes].
[Definition:] An NCName is a name with no colon, as defined in [XML-Namespaces]. 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 Schemas: 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>
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 also be used in some cases, that is
when a DTD or XML 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.
[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.15.3) should be understood:
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.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 (§4.2.1)):
All schemas (see Schemas as a Whole (§3.15)) 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.
·assessment· is defined with reference to an ·XML 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.
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· 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· 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’ (which must have such an [attribute]).targetNamespace
[attribute] of SII’ is used. In
particular, it replaces ·absent· in the following places:
code
was qualified) nested within definitions;schemaLocation
[attribute] to fail to resolve it 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 cause less than complete
·assessment· outcomes, of course.As discussed in Missing Sub-components (§5.3), ·QName·s in XML representations may fail to
·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.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· 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· 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
.
The definitions within the <redefine> element itself are restricted to be redefinitions of components from the <redefine>d schema document, in terms of themselves. That is,
Not all the components of the <redefine>d schema document need be redefined.
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 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 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’ (which must have such an [attribute]).targetNamespace
[attribute] of SII’ is
used (see clause 3.2 in Inclusion Constraints and Semantics (§4.2.1) for details).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 must be true:minOccurs
and
maxOccurs
[attribute] must be 1
(or ·absent·).name
attribute plus target
namespace must successfully ·resolve· to a
model group definition in I.ref
[attribute] is the same as the ·actual value· of its own
name
attribute plus target namespace, then it must have exactly one such group.name
attribute plus target
namespace must successfully ·resolve· to an
attribute group definition in I.name
in
the <redefine>d schema document, as defined in Schema Component Details (§3), except that its {name} is ·absent·;ref
[attribute] whose ·actual value· is the same as the item's name
plus target namespace is resolved, a component which corresponds to the top-level definition item of that name and the appropriate kind in
I is used.As described in XML Schema Abstract Data Model (§2.2), every top-level schema component is associated with a target namespace (or, explicitly, with none). This section sets out the exact mechanism and syntax in the XML form of schema definition by which a reference to a foreign component is made, that is, a component with a different target namespace from that of the referring component.
Two things are required: not only a means of addressing such foreign components but also a signal to schema-aware processors that a schema document contains such references:
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
. The ·actual value· of its 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·; the processor
is free to access or construct components using means of its own
choosing.
The
·actual value· of the schemaLocation
, if present, gives a
hint as to where a serialization of a ·schema document· with declarations and definitions for that
namespace (or none) may 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
is present, it
must contain a single URI reference which the schema author
warrants will resolve to a serialization of a ·schema document· containing the component(s) in the
<import>ed namespace referred to elsewhere in the containing
schema document.
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.<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>
namespace
[attribute] is present, then its ·actual value· must not match the ·actual value· of the
enclosing <schema>'s targetNamespace
[attribute].namespace
[attribute] is not present, then the enclosing <schema> must have a targetNamespace
[attribute]schemaLocation
and namespace
[attributes],
provides a referent, as defined by Schema Document Location Strategy (§4.3.2),
one of the following must be true:namespace
[attribute], then its ·actual value· must be identical to the ·actual value· of the targetNamespace
[attribute] of SII.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, a range of standards and conventions may well evolve to support interoperability of XML Schema 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, may 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.
Processors on the Web are free to undertake ·assessment· against arbitrary schemas in any of the ways set out in Assessing Schema-Validity (§5.2). However, it is useful to have a common convention for determining the schema to use. Accordingly, general-purpose schema-aware processors (i.e. those not specialized to one or a fixed set of pre-determined schemas) undertaking ·assessment· of a document on the web must behave as follows:
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 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. xsi:schemaLocation
or xsi:noNamespaceSchemaLocation
,
schema-aware processors may implement any combination of the following
strategies, in any order:
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 the
strategy set out in Schema Document Location Strategy (§4.3.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).
If a schema is derived from one or more schema documents (that is, one or more <schema> element information items) based on the correspondence rules set out in Schema Component Details (§3) and Schemas and Namespaces: Access and Composition (§4), two additional conditions hold:
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.
With a schema which satisfies the conditions expressed in Errors in Schema Construction and Structure (§5.1) above, the schema-validity of an element information item can be assessed. Three primary approaches to this are possible:
xsi:type
) or not.
The outcome of this effort, in any case, will be manifest in the [validation attempted] and [validity] properties on the element information item and its [attributes] and [children], recursively, as defined by Assessment Outcome (Element) (§3.3.5) and Assessment Outcome (Attribute) (§3.2.5). It is up to applications to decide what constitutes a successful outcome.
Note that every element and attribute information item participating in the ·assessment· will also have a [validation context] property which refers back to the element information item at which ·assessment· began. [Definition:] This item, that is the element information item at which ·assessment· began, is called 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 fail, resulting in one or more values of or containing ·absent· where a component is mandated.
If at any time during ·assessment·, an element or attribute information item is being ·validated· with respect to a component of any kind any of whose properties has or contains such an ·absent· value, the ·validation· is modified, as following:
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 can define itself using its own constructs. The names of XML Schema language 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.
Since a schema document is an XML document, it has optional XML and doctype
declarations that are provided here for completeness. The root
schema
element defines a new schema. Since this is a schema for
XML Schema: Structures, the targetNamespace
references the XML Schema namespace itself.
<!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: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="Id: structures.xsd,v 1.2 2004/01/15 11:34:25 ht Exp "> <xs:annotation> <xs:documentation source="../structures/structures-with-errata.html.html"> The schema corresponding to this document is normative, with respect to the syntactic constraints it expresses in the XML Schema 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/xmlschema-1/#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="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: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="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/xmlschema-1/#element-anyAttribute"/> </xs:annotation> </xs:element> <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:group ref="xs:typeDefParticle" minOccurs="0"/> <xs:group ref="xs:attrDecls"/> </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</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 overriden 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: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:group ref="xs:simpleRestrictionModel"/> </xs:choice> <xs:group ref="xs:attrDecls"/> </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:choice> <xs:group ref="xs:attrDecls"/> </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:group ref="xs:typeDefParticle" minOccurs="0"/> <xs:group ref="xs:attrDecls"/> </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/xmlschema-1/#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: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: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: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/xmlschema-1/#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/xmlschema-1/#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: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: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: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: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="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: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/xmlschema-1/#element-element"/> </xs:annotation> </xs:element> <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:narrowMaxMin"/> </xs:choice> </xs:sequence> </xs:group> <xs:complexType name="narrowMaxMin"> <xs:annotation> <xs:documentation>restricted max/min</xs:documentation> </xs:annotation> <xs:complexContent> <xs:restriction base="xs:localElement"> <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:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <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="0"/> <xs:enumeration value="1"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <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/xmlschema-1/#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/xmlschema-1/#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/xmlschema-1/#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/xmlschema-1/#element-group"/> </xs:annotation> </xs:element> <xs:complexType name="wildcard"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="namespace" type="xs:namespaceList" default="##any" 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:extension> </xs:complexContent> </xs:complexType> <xs:element name="any" id="any"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#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> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="##any"/> <xs:enumeration value="##other"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <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:union> </xs:simpleType> <xs:element name="attribute" type="xs:topLevelAttribute" id="attribute"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#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/xmlschema-1/#element-attributeGroup"/> </xs:annotation> </xs:element> <xs:element name="include" id="include"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#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/xmlschema-1/#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/xmlschema-1/#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/xmlschema-1/#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/xmlschema-1/#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: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/xmlschema-1/#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/xmlschema-1/#element-key"/> </xs:annotation> </xs:element> <xs:element name="keyref" id="keyref"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#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/xmlschema-1/#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/xmlschema-1/#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/xmlschema-1/#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/xmlschema-1/#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 schemas</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 should use the name given below plus the part number, separated
by a period ('.'). Thus for example cos-ct-extends.1.2
should be
used to report a violation of the clause 1.2 of
Derivation Valid (Extension) (§3.4.6).
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.
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.
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 namespace, is almost certainly not a valid schema document, with the exception of documents with multiple namespace prefixes for the XML Schema namespace itself. Accordingly authoring XML Schema documents using this DTD and DTD-based authoring tools, and specifying it as the DOCTYPE of documents intended to be XML Schema documents and validating them with a validating XML parser, are sensible development strategies which users are encouraged to adopt until XML Schema-based authoring tools and validators are more widely available.
<!-- DTD for XML Schemas: 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 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 namespace is almost certainly not a valid schema. --> <!-- The simpleType element and its constituent parts are defined in XML Schema: Part 2: Datatypes --> <!ENTITY % xs-datatypes PUBLIC 'datatypes' 'datatypes.dtd' > <!ENTITY % p 'xs:'> <!-- can be overriden 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 % complexType "%p;complexType"> <!ENTITY % complexContent "%p;complexContent"> <!ENTITY % simpleContent "%p;simpleContent"> <!ENTITY % extension "%p;extension"> <!ENTITY % element "%p;element"> <!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"> <!-- 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 schemas --> <!ENTITY % schemaAttrs ''> <!ENTITY % complexTypeAttrs ''> <!ENTITY % complexContentAttrs ''> <!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 % 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 % particleAndAttrs '((%mgs; | %group;)?, %attrDecls;)'> <!-- 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;)*, ((%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' xml:lang CDATA #IMPLIED %schemaAttrs;> <!-- Note the xmlns declaration is NOT in the Schema for Schemas, 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. --> <!-- 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' %complexTypeAttrs;> <!-- particleAndAttrs is shorthand for a root type --> <!-- mixed is disallowed if simpleContent, overriden 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;> <!-- 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;)?, (%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 %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 %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 '##any' 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 --> <!ELEMENT %anyAttribute; (%annotation;)?> <!ATTLIST %anyAttribute; namespace CDATA '##any' processContents (skip|lax|strict) 'strict' id ID #IMPLIED %anyAttributeAttrs;> <!-- namespace is 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 %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 id ID #IMPLIED %uniqueAttrs;> <!ELEMENT %key; ((%annotation;)?, %selector;, (%field;)+)> <!ATTLIST %key; name %NCName; #REQUIRED id ID #IMPLIED %keyAttrs;> <!ELEMENT %keyref; ((%annotation;)?, %selector;, (%field;)+)> <!ATTLIST %keyref; name %NCName; #REQUIRED refer %QName; #REQUIRED id ID #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;> <!-- 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.
[Definition:] Two non-group particles overlap if
or
or
or
A content model will violate the unique attribution constraint if it contains two particles which ·overlap· and which either
or
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 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 a QName-labeled transition and a wildcard transition which subsumes it, or two wildcard transitions whose intentional intersection is non-empty, the model does not satisfy the Unique Attribution constraint.
The following contributed material to the first edition of this specification:
David Fallside, IBM
Scott Lawrence, Agranat Systems
Andrew Layman, Microsoft
Eve L. Maler, Sun Microsystems
Asir S. Vedamuthu, webMethods, Inc
The editors acknowledge the members of the XML Schema Working Group, the members of other W3C Working Groups, and industry experts in other forums who have contributed directly or indirectly to the process or content of creating this document. The Working Group is particularly grateful to Lotus Development Corp. and IBM for providing teleconferencing facilities.
At the time the first edition of this specification was published, the members of the XML Schema Working Group were:
The XML Schema Working Group has benefited in its work from the participation and contributions of a number of people not currently members of the Working Group, including in particular those named below. Affiliations given are those current at the time of their work with the WG.
The lists given above pertain to the first edition. At the time work on this second edition was completed, the membership of the Working Group was:
We note with sadness the accidental death of Mario Jeckle shortly after the completion of work on this document. In addition to those named above, several people served on the Working Group during the development of this second edition: