This working draft incorporates most Working Group decisions through
2000-09-19. It has been reviewed by the XML Schema Working Group, and
the Working Group has agreed to its publication as a working draft, which includes our proposed resolution of most issues raised during Last Call.
The Working Group intends to submit this specification
for publication as a Candidate Recommendation very soon, but is issuing this interim public draft as it sets out a number of changes to the XML Representation of XML Schemas, and we wished to make these available as quickly as possible. Readers may find Description of changes (non-normative) (§H) helpful in identifying the major changes since the last Public Working Draft.
Note that this revision incorporates several backwards-incompatible changes to the XML representation of schemas. Accordingly, the XML Schema namespace URI has changed, to http://www.w3.org/2000/10/XMLSchema.
Although comments from the public and
other W3C working groups are always welcome, and we encourage readers to review the draft
and to send comments to
www-xml-schema-comments@w3.org, comments on changes other than those to the concrete syntax may be premature, as there are still some changes pending to the prose of the specifications.
An archive
of the comments received is available.
Although the Working Group does not anticipate further
changes to the functionality described here, this is still a working
draft, subject to change. The present version should
be implemented only by those interested in providing a check on
its design or by those preparing for an implementation of the
Candidate Recommendation. The Schema WG will
not allow early implementation to constrain its ability to make changes to this
specification prior to final release.
During the Candidate Recommendation phase, although feedback based on
implementation experience is welcome, there are certain aspects of the design
presented herein where the Working Group is
particularly interested in feedback. These are designated priority
feedback aspects of the design, and identified as such in editorial
notes throughout this draft.
1 Introduction
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 a formal specification
of 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.
Chapter 4, XML Representation of Schemas and Schema Components (§4), presents the XML representation
that maps to the abstract model, in the form
of a DTD and XML Schema for an XML Schema document type, along with rules and
conventions for identifying the components needed for any particular
validation.
Chapter 5 presents Schema Component Validity Constraints (§5), which provide
detailed constraints on the internal structure of each component of the
abstract model.
Chapter 6 presents Schema Access and Composition (§6), including the
connection between documents and schemas, the import and inclusion of declarations and definitions and
the foundations of schema-validity.
Chapter 7 discusses Validation Processing of schemas and documents (§7), including the
overall approach to schema-validation of documents, and responsibilities of schema-aware
processors.
The normative appendices include a (normative) Schema for Schemas (§A) for the transfer syntax, a Glossary (normative) * (§B) [not yet written] and
References (normative) * (§C).
The non-normative appendices include the (non-normative) DTD for Schemas (§E)
This document is primarily intended as a language definition reference.
As such, although it contains a few examples, it is not designed
primarily to serve as a motivating introduction to the design and its features,
but rather as 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.
1.1 Purpose
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 default values for attributes
and elements. 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 validated 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.
1.2 Dependencies on Other Specifications
The definition of XML Schema: Structures depends on the following specifications:
[URI],
[XML-Infoset],
[XML-Namespaces],
[XPath], and
[XML Schemas: Datatypes]. If the XML Base proposal is adopted before we go to REC, we will
need to account for any changes it makes to the Infoset in the areas of
QName interpretation and value space and
the interpretation of all aspects of schemas involving values identified as
being of type uriReference, including in particular
xsi:schemaLocation, xsi:noNamespaceSchemaLocation and targetNamespace.
1.3 Documentation Conventions and Terminology
The following highlighting and typography is used to present technical material in
this document:
Special terms are defined at their point of
introduction in the text; hyperlinks connect other uses of the
term to the definition. For example, a definition of
term might read: [Definition:] A term is
something we use a lot. The definition is labeled as such and the term is highlighted
typographically. The end of the definition is not specially marked
in the displayed or printed text.
Non-normative examples are set off
typographically and accompanied by a brief
explanation:
| Example |
<schema
targetNamespace="http://www.muzmo.com/XMLSchema/1.0/mySchema" >
|
|
| And an explanation of the 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].
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 notated as 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,
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 component,
are given. 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. The allowed content of the information item is
shown as a grammar fragment, using the Kleene operators ?,
* and +. The property correspondences are normative, but
the illustration of the XML representation element information items is not.
XML Representation Summary:
example Element Information Item |
|
|
|
The following highlighting is used for non-normative commentary in
this document:
Issue (dummy):
A recorded issue.
Ed. Note:
Notes from the editors to themselves or the Working Group, or
identification of priority feedback aspects of this draft.
NOTE:
General comments directed to all readers.
2 Conceptual Framework
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, and subsequent
chapters define
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] and then consult XML Representation of Schemas and Schema Components (§4), using the sections below as a guide to the underlying formal structure of the schema language.
2.1 Overview of XML Schema
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 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 default values for
attributes and elements and
the types of element and attribute information items.
The process of schema validation consists of determining
whether an element information item satisfies the constraints embodied in the
components of an XML Schema, and if so of
adding any appropriate augmentations.
2.2 XML Schema Abstract Data Model
This specification builds on [XML] 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]) and namespace
conformance (as defined in [XML-Namespaces]) for
all candidates for schema-validity and for all schema documents.
Just as [XML] 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 interchange format for schemas is described in XML Representation of Schemas and Schema Components (§4)
NOTE:
We have not so far seen any need to reconstruct the XML 1.0 notion of
root. For the connection from document instances to schemas, see
Layer 3: Web-interoperability (§6.3) and Errors in Schema Construction and Structure (§7.1).
[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 12 kinds of
component in all, falling into three groups. The primary components
are as follows. They may have names, and (except for some element
declarations) may be independently accessed:
- Simple type definitions
- Complex type definitions
- Attribute declarations
- Element declarations
The secondary components are as follows. Like the primary
components, they may have names and be independently accessed:
- Attribute group definitions
- Identity-constraint definitions
- Model group definitions
- Notation declarations
Finally, the "helper" components provide small parts of
other components; they are not independent of their context and
cannot be independently accessed:
- Annotations
- Model groups
- Particles
- Wildcards
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 URI, 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 URI of, for example, the element
information items it may validate.
NOTE:
At the abstract level, there is
no requirement that the components of a schema share a
target namespace. Any schema for use in
schema-validation of documents containing names from more than one namespace
will of necessity include components with different target namespaces. This contrasts with
the situation at the level of the XML Representation of Schemas and Schema Components (§4), in which each schema document contributes
definitions and declarations to a single target namespace.
Schema-validity, defined in detail in Validation Processing of schemas and documents (§7), is a
relation between information items and schema components. For example, an
attribute information item may be schema-valid with respect to an attribute
declaration, a list of element information items may be schema-valid 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 the overall definition of
schema-validity.
2.2.1 Type Definition Components
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. First we describe characteristics of that
hierarchy, then provide an introduction to simple and complex type definitions themselves.
2.2.1.1 Type Definition Hierarchy
[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 ur-type
definition is present in each XML Schema, serving as the root of the type
definition hierarchy for that schema. The ur-type definition, whose
name is anyType, has
the unique characteristic that it can function as a complex or a
simple type definition, according to context.
Specifically, restrictions of the ur-type definition can
themselves be either simple or complex type definitions.
[Definition:] A type definition used as the
basis for an extension or
restriction is known as
the base type definition of that definition.
2.2.1.2 Simple Type 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 attribute values and 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 types, this is the simple
version of the ur-type
definition, whose name is anySimpleType, which
is in turn understood to be a restriction of the ur-type definition. 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. List and union simple type definitions are also understood as
restrictions of the simple ur-type
definition.
For details on the composition and
schema-validation contributions of simple type definitions, see (non-normative) Simple Type Definition Details (§3.13) and [XML Schemas: Datatypes]. The latter also defines an extensive inventory of
pre-defined simple types. See (non-normative) XML Representation of Simple Type Definition Schema Components (§4.3.11) for the XML representation of
simple type definitions, and Simple Type Definition Constraints (§5.12) for constraints on simple
type definition components as such.
2.2.1.3 Complex Type Definition
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, to be a string which is schema-valid with respect to particular simple
type or to contain a sequence of element information items which is schema-valid with respect to a particular model group, with or without character information items as well.
Each complex type definition is either
or
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.
NOTE:
This specification allows only appending, and not other kinds of
extensions. This decision
simplifies application processing required to cast instances from derived to
base type. Future versions may allow more kinds of extension, requiring more
complex transformations to effect casting.
See Complex Type Definition Details (§3.4) for the composition and
schema-validation contributions of complex type definition schema components, XML Representation of Complex Type Definition Schema Components (§4.3.3) for the XML representation of
complex type definitions and Complex Type Definition Constraints (§5.11) for constraints on complex
type definition components as such.
2.2.2 Declaration Components
There are three kinds of declaration component: element, attribute, and
notation. Each described in a section below. Also included is a discussion of
element substitution groups, which is a feature provided in conjunction with element declarations.
2.2.2.1 Element Declaration
An element declaration is an association of a name with a type definition, either simple or
complex, an (optional) default value and a set of identity-constraint
definitions. The association is either global or scoped to a containing complex type definition. A
global element declaration with name 'A' is broadly comparable to a pair of
DTD declarations as follows, where the associated type definition
fills in the ellipsis:
<!ELEMENT A . . .>
<!ATTLIST A . . .>
Element declarations contribute to
schema-validity 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.
See Element Declaration Details (§3.3) for the composition and
schema-validation contributions of element declaration schema components, XML Representation of Element Declaration Schema Components (§4.3.2) for the XML representation of
element declarations and Element Declaration Constraints (§5.2) for constraints on
element declaration components as such.
2.2.2.2 Element Substitution Group
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 global element declaration can serve as the defining element, or
head, for an element substitution group. Other global 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 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 Declaration (§2.2.2.1)).
2.2.2.3 Attribute Declaration
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
schema-validity 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.
See Attribute Declaration Details (§3.2) for the composition and
schema validation contributions of attribute declaration schema components, XML Representation of Attribute Declaration Schema Components (§4.3.1) for the XML representation of
attribute declarations and Attribute Declaration Constraints (§5.1) for constraints on
attribute declaration components as such.
2.2.3 Model Group Components
The model group, particle, and wildcard components contribute to
the portion of a complex type definition that controls an element
information item's content type.
2.2.3.1 Model Group
A model group is a constraint in the form of a grammar fragment that applies to
lists of element information items. It consists of a list of particles, i.e.
element declarations, wildcards and model groups. There are three varieties of
model group:
- Sequence (the element information items
match the particles in sequential order)
- Conjunction (the element information items match the
particles, in any order)
- Disjunction (the element information items match
one of the particles)
See Model Group Details (§3.7) for the composition and
schema-validation contributions of model group schema components, Complex Type Definition Details (§3.4) for the use of model groups as content models, XML Representation of Model Group Schema Components (§4.3.6) for the XML representation of
model groups and Model Group Constraints (§5.7) for constraints
on model group components as such.
2.2.3.2 Particle
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
schema-validity as part of complex type 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 express a validity
constraint on the [children] of an element information item; such a particle is called
a content model.
NOTE:
XML Schema: Structures content models are similar to but more expressive than
[XML] content models; unlike [XML], XML Schema: Structures applies content models to the validation of both mixed and element-only content.
See Particle Details (§3.8) for the composition and
schema-validation contributions of particle schema components, XML Representation of Model Group Schema Components (§4.3.6) for the XML representation of
particles and Particle Constraints (§5.10) for constraints
on particle components as such.
2.2.4 Identity-constraint Definition Components
A 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 schema-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.
See Identity-constraint Definition Details (§3.10) for the composition and
schema-validation contributions of identity-constraint definition schema components, XML Representation of Identity-constraint Definition Schema Components (§4.3.8) for the XML representation of
identity-constraint definitions and Identity-constraint Definition Constraints (§5.3) for constraints
on identity-constraint definition components as such.
2.2.5 Group Definition Components
There are two kinds of convenience definitions available for use
in reusing pieces of complex type definitions: model group definitions
and attribute group definitions.
2.3 Constraints and Contributions
The [XML] 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 focussed on schema-validity, 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
schema-validation of information items:
-
[Definition:] Constraint on Schemas
-
Constraints on the schema components themselves, i.e.
conditions components must satisfy to be components at all. Largely to be
found in Schema Component Validity Constraints (§5).
-
[Definition:] Schema Representation Constraint
-
Constraints on the
representation of schema components in XML. Some but not all of these are expressed in (non-normative) DTD for Schemas (§E) and (normative) Schema for Schemas (§A). Largely to be
found in XML Representation of Schemas and Schema Components (§4).
-
[Definition:] Validity Contribution
-
Constraints expressed by schema components which information
items must satisfy to
be schema-valid. Largely to be
found in Schema Component Details (§3).
The definition of the above constraints sometimes involves many
clauses, some as alternatives, some as joint requirements. The presentations
below number all clauses: clauses at the same level are either clearly
identified as alternatives with words such as either and
or, or should be understood as joint.
-
[Definition:] Schema Information Set
Contribution
-
Augmentations to post-schema-validation information sets
expressed by schema components, which follow
as a consequence of schema-validation.
Largely to be
found in Schema Component Details (§3).
Schema information set
contributions are not new. 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 whitespace, 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.
2.4 Conformance
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 Constraints on
Schemas, Validity Contributions,
and Schema Information
Set Contributions contained in this specification.
[Definition:] Processors which accept
schemas in the form of XML documents as described in XML Representation of Schemas and Schema Components (§4) 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 XML Representation of Schemas and Schema Components (§4) for mapping the contents of such documents to schema components for use in validation.
NOTE:
By separating the conformance requirements relating to the concrete syntax of XML schema
documents, this specification admits processors
which validate using schemas stored in optimised binary
representations, dynamically created schemas represented as programming language data structures, or implementations in which particular schemas are compiled into executable code
such as C or Java. Such processors can be said to be minimally conforming but not necessarily in conformance to the XML Representation of Schemas.
[Definition:] Fully conforming
processors are network-enabled processors which support both levels of conformance described
above, and which must additionally 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 (§6.3.2).
.
NOTE: Although this specification provides just these three standard levels of conformance, it is
anticipated that other conventions can be established in the future. For example, the World Wide
Web Consortium is considering conventions for packaging on the Web a variety of
resources relating to individual documents and namespaces. Should such
developments lead to new conventions for representing schemas, or for accessing them on the Web,
new levels of conformance can be established and named at that time. There is no need to modify
or republish this recommendation to define such additional levels of conformance.
See Schema Access and Composition (§6) for a more detailed explanation of the
mechanisms supporting these levels of conformance.
2.5 Names and Symbol Spaces
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.
This specification
therefore introduces the term
[Definition:] 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.
2.6 Schema-Related Markup in
Documents Being Schema-Validated
The XML representation of schema components uses a vocabulary
identified by the namespace URI http://www.w3.org/2000/10/XMLSchema.
XML Schema: Structures also defines several attributes for direct use in XML documents. These attributes are in a different namespace,
which has the namespace URI http://www.w3.org/2000/10/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.
2.6.2 xsi:null
XML Schema: Structures introduces a mechanism for signalling that an element's content is
missing, or "null" in the terminology of databases. An
element has null content if it has the attribute xsi:null with
the value true. An element so labelled must be empty, but can
carry attributes if permitted by the corresponding complex type.
2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation
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 validation.
See How schema definitions are located on the Web (§6.3.2) for details on the use of these attributes.
3 Schema Component Details
The following sections provide full details on the properties and
significance of the schema itself and each kind of schema component. For each property, its range,
that is the kinds of values it may have, is defined. This can be understood as
defining a schema as a labelled directed graph, where the root is a schema, and
every other vertex is a schema
component or a literal (string, boolean, number) and every labelled edge 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 addressed at the level of names (including target
namespaces) within symbol spaces. Any property not
identified as optional is required to be present, optional properties which are absent 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 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 character codes identified as legal XML character codes
in [XML].
NOTE:
Readers whose primary interest is in the XML representation of schemas
may wish to skip this chapter on the first reading, concentrating on XML Representation of Schemas and Schema Components (§4) and [XML Schema: Primer].
Throughout this specification, [Definition:] when we refer to the
initial value of some
attribute information item, we mean by this the value of the
normalized
value property of that item. Similarly, when
we refer to the initial value of an element information item, we mean the string composed of, in order, the
[character code] of each character information item in the [children] of that
element information item.
[Definition:] When we refer to the
normalized value of an element or
attribute information item, we mean an initial value whose whitespace, if any, has been
normalized according to the value of the whitespace facet of the simple type definition by which its validity is assessed:
-
preserve
-
No normalization is done, the value is the normalized value
-
replace
-
All occurrences of
	 (tab), 
 (linefeed) and

 (carriage return) are replaced with   (space).
-
collapse
-
Subsequent to the replacements specified above under replace,
contiguous sequences of
 s are collapsed to a single
 , and initial and/or final &x20;s are deleted.
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] for the precedent for replace and collapse for attributes. Extending this processing to element content is necessary to ensure a consistent schema 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.
NOTE:
Even when DTD-based information has been appealed to, and
Attribute Value
Normalization has taken place, the above definition of normalized value may
mean further normalization may take place, as for instance when
character entity references in attribute values result in whitespace characters
other than spaces in their initial values.
Many properties are identified below as having (sets of)
other schema 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 (§7.3): no mention of
handling missing components will be found in the individual component
descriptions below.
As the above makes clear, at the level of schema components and schema
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.
Validation Contribution: QName resolution (Instance)
A pair of a local name and a namespace URI (or
absent)
resolve to a schema component of a specified kind in the context of schema
validation if the component is that member of the value of the appropriate
property of the schema being used for the validation, that is:
whose
{local name} matches the local name and whose
{target namespace} is identical to the namespace URI of the pair.
NOTE:
A schema and its components as defined in this chapter are an idealisation of the information a schema-aware
processor requires: implementations are not constrained in how they provide
it. In particular, no implications about literal embedding versus indirection
follow from the use above of language such as "properties . . . having . . .
components as values".
3.1 Schema details
At the abstract level, the schema itself is just a container for its components.
See XML Representations of Schemas (§4.1) for the XML representation of
schemas and Schema Constraints (§5.13) for constraints on schemas as such.
Schema Information Set Contribution: Schema Information
In the post-schema
validation infoset a
[schema information] property is added
to the element information item at which validity assessment began. Its value
is a list of
namespace schema information information items, one for each namespace URI which appears as the
{target namespace} of any schema component in the schema used for that
assessment. Each
namespace schema information information item has the
following properties and values:
-
[schema namespace]
-
a namespace
URI
-
[schema components]
-
a (possibly
empty) list of schema component information items, each one isomorphic
to a component whose {target
namespace} is the sibling [schema namespace]
property above, drawn from the schema used for assessment.
-
[schema documents]
-
a
(possibly empty) list of schema document information items, with
properties and values as follows:
-
[document
location]
-
either a URI reference, if available, otherwise
absent
-
[document]
-
a document
information item, if available, otherwise absent
for a schema document which
contributed components to the schema, and whose
targetNamespace matches the sibling [namespace
URI] property above (or was absent
but contributed components to that namespace by being included
by a schema document with that targetNamespace as per Assembling a schema for a single target namespace from multiple schema definition documents (§6.2.1)).
The
[schema components] property is provided for
processors which wish to provide a single access point to some or all of the
components of the schema used during validation. Lightweight processors are free to leave it empty.
3.2 Attribute Declaration Details
Attribute declarations provide for:
- Constraining attribute information item values by a simple type definition;
- Providing default or fixed values for an attribute information item.
The attribute declaration schema component has the following
properties:
The {name} property must match the local part of the names of attributes being validated.
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 also absent in the case of non-global declarations within attribute group definitions: their scope will be determined when they are used in the construction of complex type definitions.
A non-absent value of the {target namespace} property provides for validation of
namespace-qualified 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.
The value of the attribute must conform to the supplied {simple type definition}.
{value constraint} reproduces the functions of XML 1.0 default and #FIXED
attribute values. fixed indicates that the attribute value must match the supplied
constraint string; default specifies that the attribute is to appear unconditionally in
the post-schema-validation information set, with the supplied value used
whenever the attribute is not actually present.
See Annotation Details (§3.12) for the significance of the
{annotation} property.
NOTE: A more complete and formal presentation of the semantics of {name}, {target namespace} and
default {value constraint} is provided in
conjunction with other aspects of complex type validation (see Element Children and Attributes Valid (§3.4).)
[XML-Infoset] distinguishes namespace declarations such as xmlns or xmlns:xsl from
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 (§5.1). No means is provided in
this specification to supply a
default value for a namespace declaration.
See XML Representation of Attribute Declaration Schema Components (§4.3.1) for the XML representation of
attribute declarations and Attribute Declaration Constraints (§5.1) for constraints on attribute
declaration components as such.
Validation Contribution: Attribute Valid
For an attribute information item to be schema-valid with respect to an
attribute declaration, its
normalized value must
Validation Contribution: Attribute Valid (Lax)
An attribute information item is laxly schema-valid if either
or
Schema Information Set Contribution: Attribute Validated by Type
If an attribute information item is schema-valid with respect to an attribute
declaration, in the post-schema
validation infoset the attribute information item has
| 1.1 |
a [schema normalized value] property, whose value is
the normalized value of the item as validated;
|
and either
| 1.2.1 | a single [type definition] property,
containing an information item isomorphic to the attribute declaration's {simple type definition} component itself, that is, a Simple Type Definition information item with one property per property of the component, with the same name, and value either the same atomic value, or an information item corresponding in the same way to its component value, recursively, as necessary. |
| 1.2.2 |
if the [type definition] has {variety} union, then additionally there
is a [member type definition] property, containing an
information item isomorphic to that member of the {member type definitions} which actually validated the attribute item's [normalized value].
|
or
See below under
Element Validated by Type (§3.3) for a discussion of the
alternatives given above.
Also, if the declaration has a
{value constraint}, the item's
[schema default] is set to the declaration's
{value constraint} string.
Finally, if an attribute is laxly but not strictly valid, that is
Attribute Valid (§3.2) does not hold but
Attribute Valid (Lax) (§3.2)
does, the information described above under 1.2.1 or 1.3.1 above is provided with
respect to the
simple ur-type definition.
Schema Information Set Contribution: Validation Outcome (Attribute)
If an attribute information item's schema-validity as defined by
Attribute Valid (§3.2) has been assessed, whether successfully or not, then in the
post-schema validation infoset the item has a
[validation
attempted] property with the value
full.
If an attribute information item's schema-validity as defined by
Attribute Valid (§3.2) has not been assessed, but its lax schema-validity as
defined by
Attribute Valid (Lax) (§3.2) has been assessed, in the post-schema
validation infoset the item has a
[validation attempted] property with the value
partial.
If an attribute information item's schema-validity, as defined by either
Attribute Valid (§3.2) or
Attribute Valid (Lax) (§3.2), has been assessed, whether successfully or not, then in the
post-schema validation infoset the item has a
[validation context] property whose value is the lowest
containing element information item with a
[schema
information] property.
3.3 Element Declaration Details
Element declarations provide for:
- Establishing the validity of element information items.
- Determining schema information set contributions, such as default values.
- Establishing uniquenesses and reference constraint relationships among the values of related elements and
attributes.
- Controlling the substitutability of elements through the
mechanism of element substitution groups.
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 non-global declarations within named model groups: their scope will be determined when they are used in the construction of complex type definitions.
A non-absent value of the {target namespace} property provides for validation of
namespace-qualified element information items. absent values of
{target namespace} validate unqualified items.
An element information item is schema-valid
if it obeys the schema validity constraints of the {type definition}. For such an
item, the schema information set contributions from the {type definition} are applied to the
corresponding element information item in the post-schema-validation information set.
If {nullable} is true, then an element is also
schema-valid if it
carries the namespace qualified attribute with [local name] null from namespace http://www.w3.org/2000/10/XMLSchema-instance and value true (see xsi:null (§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 Valid (Explicit) (§3.3).
{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 supplied
constraint string 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 it must match the supplied constraint string.
{identity-constraint definitions} express constraints establishing uniquenesses and reference relationships among the values of related elements and
attributes. See Identity-constraint Definition Details (§3.10).
Element declarations are members of the substitution group, if any, identified
by {substitution group affiliation}. Membership is transitive but not symmetric; an element
declaration is implicitly a member of any group of which its {substitution group affiliation} is a member.
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 same
substitution group as the declared element.
If {disallowed substitutions} is empty, then all derived types and substitution group members are valid.
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 XML Representation of Element Declaration Schema Components (§4.3.2) for the XML representation of
element declarations and Element Declaration Constraints (§5.2) for constraints on element
declaration components as such.
Validation Contribution: Element Valid (Explicit)
Ed. Note: Priority Feedback Request
The Working Group solicits feedback from implementors and users
on the extent to which the xsi:null feature provides useful functionality and
satisfactorily addresses requirements in the area of data interchange.
NOTE: The {name} and {target namespace} properties are not
mentioned above because they are checked during particle validation, as per
Element Sequence Valid (Particle) (§3.8).
Validation Contribution: Element Valid (Strict)
An element information item is strictly schema-valid if
Validation Contribution: Element Valid (Lax)
An element information item is laxly schema-valid if either
or
Schema Information Set Contribution: Element Default Value
Schema Information Set Contribution: Element Validated by Type
If an element information item is schema-valid with respect to a
type definition
declaration, in the post-schema
validation infoset the item has
and either
| 1.2.1 |
a single [type definition] property,
containing an information item isomorphic to the type definition component itself, that is, a Complex Type Definition information item with one property per property of the component, with the same name, and value either the same atomic value, or an information item corresponding in the same way to its component value, recursively, as necessary. |
| 1.2.2 |
if the type definition has a
simple type definition {content type}, and that type
definition has {variety} union, then additionally there
is a [member type definition] property, containing an
information item isomorphic to that member of the {member type definitions} which actually validated the element item's character information item content.
|
or
| 1.3.1 |
four properties as follows:
-
[type definition type]
-
simple or complex, depending on the actual type definition
-
[type definition namespace]
-
the {target namespace} of the actual type definition
-
[type definition anonymous]
-
true if the {name} of the actual type definition is absent, otherwise false
-
[type definition name]
-
the {name} of the actual type definition, if it is not absent. If it is
absent, schema processors may, but need not,
provide a value unique to the {type definition} of the
declaration.
|
| 1.3.2 |
if the type definition has a
simple type definition {content type}, and that type
definition has {variety} union, then calling
[Definition:] that
member of the {member type definitions} which actually
validated the element item's character information item content the
actual member type definition, there are three additional properties:
-
[member type definition namespace]
-
the {target namespace} of the actual
member type definition
-
[member type definition anonymous]
-
true if the {name} of the actual member type definition is absent, otherwise false
-
[member type definition name]
-
the {name} of the actual member type definition, if it is not absent. If it is
absent, schema processors may, but need not,
provide a value unique to the {type definition} of the
declaration.
|
The first alternative above is provided for applications such as query
processors which need access to the full range of details about how an item was
validated, for example the type hierarchy; the second, for lighter-weight
processors for whom representing the significant parts of the type hierarchy as
information items might be a significant burden.
Also, if the declaration has a
{value constraint}, the item's
[schema default] property is set to that
{value constraint}'s string.
Finally, if an element is laxly but not strictly valid, that is
Element Valid (Explicit) (§3.3) and/or
Element Valid (Strict) (§3.3) do not hold but
Element Valid (Lax) (§3.3)
does, the information described above under 1.2.1 or 1.3.1 above is provided with
respect to the
ur-type definition.
Schema Information Set Contribution: Element Declaration
If an element information item is schema-valid with respect to an element
declaration then in the post-schema
validation infoset the element
information item has a either
| 1 |
a single [element declaration] property,
containing an information item isomorphic to the declaration component itself,
that is, an Element Declaration item with one property per property of the component, with the same name, and value either the same atomic value, or an information item corresponding in the same way to its component value, recursively, as necessary.
|
| 2 |
a [null] property, with value true if clause 1.2 of Element Valid (Explicit) (§3.3) above obtains,
otherwise false.
|
Schema Information Set Contribution: Validation Outcome (Element)
If
| 1.1 |
an element information item's schema-validity as defined by
Element Valid (Explicit) (§3.3) has been assessed, whether successfully or not;
|
| 1.2 |
all its element information item children have the value full for
their [validation attempted] property,
|
then in the
post-schema validation infoset the item has a
[validation attempted] property with the value
full.
If an element information item's schema-validity as defined by
Element Valid (Explicit) (§3.3) has not been assessed, or has been but the above
clause is not satisfied, but its lax schema-validity as
defined by
Element Valid (Lax) (§3.3) has been assessed, in the post-schema
validation infoset the item has a
[validation attempted] property with the value
partial.
If an element information item's schema-validity, as defined by either
Element Valid (Explicit) (§3.3) or
Element Valid (Explicit) (§3.3), has been assessed, whether successfully or not, then in the
post-schema validation infoset the item has a
[validation context] property whose value is the lowest
containing element information item with a
[schema
information] property.
3.4 Complex Type Definition Details
Complex Type Definitions provide for:
- Constraining element information items by providing Attribute Declaration (§2.2.2.3)s governing the appearance and content of
[attributes]
- Constraining element information item [children] to be empty, or to conform to a specified element-only or mixed content model.
- Using the mechanisms of Type Definition Hierarchy (§2.2.1.1) to derive a complex type from another simple or complex type.
-
Specifying contributions to the post-schema-validation information set for elements.
- Limiting the ability to derive additional types from a given complex type.
- Controlling the permission to substitute, in an instance, elements of a derived
type for elements declared in a content model to be of a given complex type.
- Determining post-schema-validation
information set contributions.
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 Schemas and Schema Components (§4)
(specifically in element). See References to schema components across namespaces (§6.2.3) for the use of component
identifiers when importing one schema into another.
NOTE:
The {name} of a complex type is not ipso
facto the [(local) name] of the
element information items validated by that definition. The connection between a
name and a type definition is described in Element Declaration Details (§3.3).
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 the complex type is said to be
[Definition:] final: no
further derivations are possible.
A complex type for which {abstract} is true must not appear as the
{type definition} of an Element Declaration (§2.2.2.1), and must not be referenced from an
xsi:type (§2.6.1) attribute in an instance document; such abstract complex types can be
used as {base type definition}s, but they are never used directly to validate
element content.
{attribute declarations} are a set of [Definition:] attribute use pairs:
each is a pair of a boolean
and an individual Attribute Declaration (§2.2.2.3)
to be used for schema-validating the
[attributes]
of element information items, where the boolean determines whether the
attribute is required or not. See Element Children and Attributes Valid (§3.4)
and Attribute Valid (§3.2) for details of attribute validation.
{attribute wildcard}s provide a more flexible specification for validation of
attributes not explicitly included in {attribute declarations}.
Informally, the specific values
of {attribute wildcard} are interpreted as follows:
-
any: [attributes] can include attributes with any qualified or unqualified name.
-
a set whose
members are either namespace URIs or absent: [attributes] can
include any attribute(s) from the specified namespace(s). If absent is included in the set, then any unqualified attributes are (also) allowed.
-
'not' and a namespace URI: [attributes] cannot include attributes from the specified namespace.
-
'not' and absent: [attributes] cannot include
unqualified attributes.
See Element Children and Attributes Valid (§3.4) and Wildcard allows Namespace URI (§3.9) for formal
details of attribute wildcard validation.
{content type} determines the schema-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 an extension or restriction, or element items in
a substitution group whose type definition is similarly derived (if {prohibited-substitutions} contains one of those).
If {prohibited-substitutions} is empty,
then all such substitutions are valid.
See Element Children and Attributes Valid (§3.4)
for a formal specification of element content validation.
See XML Representation of Complex Type Definition Schema Components (§4.3.3) for the XML representation of
complex type definitions and Complex Type Definition Constraints (§5.11) for constraints on
complex type definition components as such.
Validation Contribution: Element Children and Attributes Valid
An element information item is schema-valid with respect to a complex type definition if:
Schema Information Set Contribution: Attribute Default Value
Schema Information Set Contribution: Validation Outcome (Complex Type)
If the schema-validity, as defined by
Element Children and Attributes Valid (§3.4)
above, of an element information item has been assessed,
in the post-schema validation infoset the item has a
[validity]
property, whose value is
complete if the item is schema-valid,
partial if it is not schema-valid but some or all of its element
information item
[children] and/or its
[attributes] are either schema-valid
or laxly schema-valid, otherwise
not.
Schema Information Set Contribution: Validation Failure (Complex Type)
If the schema-validity, as defined by
Element Children and Attributes Valid (§3.4)
above, of an element information item has been assessed,
in the post-schema validation infoset the item has a
list-valued
[error code]
property. If the item is not schema-valid, applications wishing to provide
information as to the reason(s) for this are encouraged to record one or more
error codes (see
Validity Contributions (§D.2) therein.
There is a complex type definition nearly equivalent to the ur-type definition present in every
schema by definition. It has the following properties:
The mixed content specification together with the
unconstrained wildcard content model and attribute specification produce the defining property for the
ur-type definition, namely that every complex type
definition is (eventually) a restriction
of the ur-type definition: its permissions and requirements are
the least restrictive possible.
3.7 Model Group Details
When the [children] of element information items are not constrained
to be empty or by reference to a simple type definition
((non-normative) Simple Type Definition Details (§3.13)), 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.
The model group schema component has the following
properties:
{compositor}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:
- (sequence) correspond, in order, to the specified {particles};
- (choice) corresponded to exactly one of the specified {particles};
- (all, (in which case {particles} is restricted to contain local and global element
declarations, with {min occurs}
=0 or
1, {max occurs}=1) contain exactly zero or one of each element specified in {particles}. The elements can occur in any order.
When two or more element declarations with the same identity occur at
any level within a model group, their type definitions must be the same.
{annotation}Description to be supplied in a future draft.
Validation Contribution: Element Sequence Valid
[Definition:] We define a
partition of a sequence as a sequence of sub-sequences, some or
all of which may be empty, such that concatenating all the sub-sequences yields
the original sequence.
A sequence (possibly empty) of element information items is schema-valid with respect to
a model group if
or
or
Nothing in the above should be understood as ruling out groups whose
{particles} is empty: although no sequence can be schema-valid
with respect to such a group whose
{compositor} is
choice, the empty sequence
is schema-valid with respect
to empty groups whose
{compositor} is
sequence or
all.
NOTE:
The above definition is implicitly non-deterministic, and should not be
taken as a recipé for implementations. Note in particular that when
{compositor} is all, particles is restricted to a list
of local and global element declarations (see Model Group Constraints (§5.7)). A much simpler implementation is possible than would arise from a literal interpretation of the definition above; informally, the content is valid when each declared element occurs exactly once (or at most once, if {min occurs} is 0), and each is valid with respect to its corresponding declaration. The elements can occur in arbitrary order.
See XML Representation of Model Group Schema Components (§4.3.6) for the XML representation of
model groups and Model Group Constraints (§5.7) for constraints
on model group components as such.
3.8 Particle Details
As described in Model Group Details (§3.7), particles contribute to the definition
of content models. The particle schema component has the following properties:
The following is an informal overview of the properties of a particle. Formal interpretation of
these properties is found in Element Sequence Valid (Particle) (§3.8).
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. {min occurs} determines the minimum number of such element [children] that can validly 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.
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.
Validation Contribution: Element Sequence Valid (Particle)
A sequence (possibly empty) of element information items is schema-valid
with respect to a particle if either
| 1.1.1 |
The length of the sequence is greater than or equal to the {min occurs};
|
| 1.1.2 |
If {max occurs} is a number, the length of the sequence is less than or equal to the {max occurs};
|
| 1.1.3 |
Either
| 1.1.3.1 |
the {term} is a wildcard and each element
information item in the sequence is schema-valid with respect to the wildcard as defined by Item Valid (Wildcard) (§3.9)
|
or
| 1.1.3.2.1 |
the {term} is an element declaration;
|
| 1.1.3.2.2 |
for each element
information item in the sequence either
or
or
|
|
or
See XML Representation of Model Group Schema Components (§4.3.6) for the XML representation of
particles and Particle Constraints (§5.10) for constraints
on particle components as such.
3.9 Wildcard Details
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
URI, but independently
of their local name. The wildcard schema component has the following properties:
{namespace constraint} provides for validation of elements that:
-
(any) have any namespace or are not namespace qualified;
-
(not and a namespace URI) have any namespace other than the specified namespace URI, or
are not namespace qualified;
-
(not and absent) are namespace qualified;
-
(a set whose
members are either namespace URIs or absent) have any of the
specified namespaces and/or, if absent is included in the set, are unqualified.
{process contents} controls the impact on schema-validity
of the information items allowed by wildcards, as follows:
-
strict
-
There must be a global declaration for the item available, and it
must be schema-valid with respect to that definition.
-
skip
-
No constraints at all: the item must simply be well-formed XML.
-
lax
-
If the item, or any items among its [children] if it's an element
information item, has a uniquely
determined declaration available, it must be laxly schema-valid with respect to
that definition, that is, schema-validate where you can, don't worry when you can't.
Validation Contribution: Item Valid (Wildcard)
An element or attribute information item is schema-valid with respect to a wildcard
constraint if
Validation Contribution: Wildcard allows Namespace URI
A value which is either a namespace URI or
absent is schema-valid with respect to a wildcard constraint (the
value of a
{namespace constraint}) if
| 1.1 |
the constraint is any;
|
or
| 1.2 |
the constraint is a pair of not and a namespace URI, and
the value is not identical to the namespace URI;
|
or
| 1.3 |
the constraint is a set, and the value is identical to one of the members of the set.
|
Schema Information Set Contribution: Validation Outcome (skipped)
If clause 1.2.1 of
Item Valid (Wildcard) (§3.9) above obtains with
respect to an information item, in the post-schema
validation infoset the item has a
[validation attempted] property with the value
none.
See XML Representation of Wildcard Schema Components (§4.3.7) for the XML representation of
wildcards and Wildcard Constraints (§5.5) for constraints
on wildcard components as such.
3.10 Identity-constraint Definition Details
Identity-constraint definition components provide for uniqueness and reference constraints with respect
to the contents of multiple elements and attributes. 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 (§6.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:
- (unique) the Identity-constraint definition asserts uniqueness, with respect to the content
identified by {selector}, of the tuples resulting from
evaluation of the {fields} XPath expression(s).
-
(key) the Identity-constraint definition asserts uniqueness as for
unique. key further asserts that all selected content
actually has such tuples.
- (keyref) the Identity-constraint definition asserts a correspondence, with respect to the content
identified by {selector}, of the tuples resulting from
evaluation of the {fields} XPath expression(s), with those of the {referenced key}.
These constraints are specified independently of the types of the
attributes and elements involved, i.e. something declared as of type integer
may also serve as a key, unlike ID and
IDREF. 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 applies to the value of
the fields selected, so that for example 3.0 and 3
would be conflicting keys if they were both decimal, but non-conflicting if
they were both strings, or one was a string and one a decimal.
Overall the augmentations to XML's ID/IDREF mechanism are:
- Not just attribute values, but also element content and combinations
of values and content can be declared to be unique;
- Constraints are specified to hold within the scope of particular elements;
- (Combinations of) attribute values and/or element content can be
declared to be keys, that is, not only unique, but always present and non-nullable;
-
The comparison between keyref {fields} and
key or unique {fields} is by value equality,
not by string equality.
{selector} specifies an XPath expression [XPath] relative to
instances of the element being declared. This must identify a node set of subelements (i.e. elements 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, not necessarily within the selected element) 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.
NOTE:
Provision for multi-field keys etc. goes beyond what is supported by xsl:key.
NOTE:
If reference to a key or unique defined in a scoping element which may
occur more than once is envisaged (which reference may be from outside any of
the scoping elements), then the scoping elements themselves must
have keys (typically unique across the entire document), and the scoped keys must include the
key of their scoping element among their fields.
A formal description of Identity-constraint definition validation is given below in Identity-constraint Satisfied (§3.10)
Validation Contribution: Identity-constraint Satisfied
An element information item is schema-valid with respect to a identity-constraint if
| 1.1 |
The {selector}, with the element information item as the
context node, evaluates to a node-set (as defined in
[XPath]). [Definition:] Call this the target node set;
|
| 1.2 |
Each node in the target node set is an
element node among the descendants of the context node;
|
| 1.3 |
For each node in the target node set all of the {fields}, with that node as the context
node, evaluate to either an empty node-set or a node-set with exactly one
member. [Definition:] Call the sequence of the values (as defined in [XML Schemas: Datatypes]) of those node-sets in order the key-sequence of the node;
|
[Definition:] Call the subset of the target node set for
which all the {fields} evaluate to a node-set with exactly one
member which is an element or attribute node the qualified node set;
or
or
NOTE:
This specification does not define a post-schema validation infoset
contribution which would enable schema-aware processors to implement clause
2.2.4 above. This clause can be read as if there were such a contribution,
which recorded for example either the element declaration appealed to in
Element Valid (Explicit) (§3.3), or the value of its {nullable} property.
Schema Information Set Contribution: Identity-constraint Table
[Definition:] An eligible
identity-constraint of an element information item is one such that clauses 2.1.[1-2] or 2.2.[1-3] of Identity-constraint Satisfied (§3.10) obtains
with respect to that item and that constraint,
or such that any of the element information item [children] of that item have a
[identity-constraint table] with an entry for that constraint.
[Definition:] A node table is a set of pairs each consisting of
a key-sequence and an element node.
Whenever an element information item has one or more
eligible constraints, a new
[identity-constraint table] is added to the post-schema-validation
infoset for that element information item, consisting of pairs of identity-constraints
and
node tables, one for each of the item's
eligible constraints, with the
node table in each pair defined as follows: There is a member in the
node table
associated with an
eligible constraint of an
element information item consisting of a
key-sequence (call it
k) and a node (call it
n) if and only if
NOTE: This information set contribution, unlike others in this
specification, is essentially an internal bookkeeping mechanism. It is introduced to
support the definition of Identity-constraint Satisfied (§3.10) above.
Accordingly, conformant processors may, but are not required, to expose
[identity-constraint table]s in the post-schema-validation infoset.
In other words, the above constraints may be read as saying validation of
identity-constraints proceeds as if such an infoset property existed.
See XML Representation of Identity-constraint Definition Schema Components (§4.3.8) for the XML representation of
identity-constraint definitions and Identity-constraint Definition Constraints (§5.3) for constraints
on identity-constraint definition components as such.
3.12 Annotation Details
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. Schema validation does not involve dereferencing these URIs, when present. In the case of {user information}, indication may be given as to the identity of the (human) language used in the contents, using the xml:lang attribute.
Annotations do not participate in schema-validation as such. Provided
an annotation itself satisfies all relevant Constraints of Schemas it cannot affect the schema-validity of element information items.
See XML Representation of Annotation Schema Components (§4.3.10) for the XML representation of
annotations and Annotation Constraints (§5.9) for constraints
on annotation components as such.
3.13 (non-normative) Simple Type Definition Details
NOTE:
This section reproduces a version of material from [XML Schemas: Datatypes], for local cross-reference purposes.
Simple type definitions provide for constraining character information item [children] of element and attribute
information items.
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 Schemas and Schema Components (§4)
(specifically in element and attribute). See References to schema components across namespaces (§6.2.3) for the use of component
identifiers when importing one schema into another.
NOTE:
The {name} of a simple type is not ipso
facto the [(local) name] of the
element or attribute information items validated by that definition. The connection between a
name and a type definition is described in Element Declaration Details (§3.3) and Attribute Declaration Details (§3.2).
{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. Each
atomic type is ultimately a restriction of exactly one such built-in simple {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. the content 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 base 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.
Simple type definitions for all the built-in primitive datatypes, namely string, boolean, float,
double, decimal, timeInstant, timeDuration,
recurringInstant, binary, uriReference (see the Primitive
Datatypes section of [XML Schemas: Datatypes]), as well as for the
simple and complex ur-type definitions (as previously described), are present by definition in every schema. All
are in the XML Schema {target namespace} (namespace
URI http://www.w3.org/2000/10/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
(normative) Schema for Schemas (§A).
therein.
There is a separate ur-Type for simple types. As discussed in
Type Definition Hierarchy (§2.2.1.1), the ur-type
definition functions as a simple type when used as the base type definition for the built-in primitive datatypes and for list and union type definitions. It 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 simple ur-type
definition must not be named as the base type definition of any user-defined simple types: as it has no constraining facets, this would be incoherent.
Validation Contribution: String Valid
There is a simple type definition nearly equivalent to the ur-type definition present in every
schema by definition. It has the following properties:
See (non-normative) XML Representation of Simple Type Definition Schema Components (§4.3.11) for the XML representation of
simple type definitions and Simple Type Definition Constraints (§5.12) for constraints on simple
type definition components as such.
A (normative) Schema for Schemas
The XML Schema definition for XML Schema: Structures itself is presented here as normative
part of the specification, and as an illustrative example of the XML Schema in
defining itself with the very constructs that it defines. 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 an XML Schema: Structures 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.
<?xml version='1.0' encoding='UTF-8'?>
<!-- XML Schema schema for XML Schemas: Part 1: Structures -->
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSCHEMA 200010//EN" "XMLSchema.dtd" >
<schema targetNamespace="http://www.w3.org/2000/10/XMLSchema" blockDefault="#all" elementFormDefault="qualified" version="Id: XMLSchema.xsd,v 1.21 2000/09/22 13:12:32 ht Exp " xmlns="http://www.w3.org/2000/10/XMLSchema">
<annotation>
<documentation source="http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/structures.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</documentation>
</annotation>
<annotation>
<documentation>The simpleType element and all of its members are defined
in datatypes.xsd</documentation>
</annotation>
<include schemaLocation="datatypes.xsd"/>
<element name="schemaTop" abstract="true" type="annotated">
<annotation>
<documentation>This abstract element defines an substitution group over the
elements which occur freely at the top level of schemas. These are:
simpleType, complexType, element, attribute, attributeGroup, group, notation
All of their types are based on the "annotated" type by extension.</documentation>
</annotation>
</element>
<element name="redefinable" abstract="true" substitutionGroup="schemaTop">
<annotation>
<documentation>This abstract element defines a substitution group for the
elements which can self-redefine (see <redefine> below).</documentation>
</annotation>
</element>
<simpleType name="formChoice">
<annotation>
<documentation>A utility type, not for public use</documentation>
</annotation>
<restriction base="NMTOKEN">
<enumeration value="qualified"/>
<enumeration value="unqualified"/>
</restriction>
</simpleType>
<element name="schema" id="schema">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-schema"/>
</annotation>
<complexType>
<complexContent>
<extension base="openAttrs">
<sequence>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="include"/>
<element ref="import"/>
<element ref="redefine"/>
<element ref="annotation"/>
</choice>
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="schemaTop"/>
<element ref="annotation" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</sequence>
<attribute name="targetNamespace" type="uriReference"/>
<attribute name="version" type="string"/>
<attribute name="finalDefault" type="derivationSet" use="default" value=""/>
<attribute name="blockDefault" type="blockSet" use="default" value=""/>
<attribute name="attributeFormDefault" type="formChoice" use="default" value="unqualified"/>
<attribute name="elementFormDefault" type="formChoice" use="default" value="unqualified"/>
<attribute name="id" type="ID"/>
</extension>
</complexContent>
</complexType>
<key name="element">
<selector xpath="element"/>
<field xpath="@name"/>
</key>
<key name="attribute">
<selector xpath="attribute"/>
<field xpath="@name"/>
</key>
<key name="type">
<selector xpath="complexType|simpleType"/>
<field xpath="@name"/>
</key>
<key name="group">
<selector xpath="group"/>
<field xpath="@name"/>
</key>
<key name="attributeGroup">
<selector xpath="attributeGroup"/>
<field xpath="@name"/>
</key>
<key name="notation">
<selector xpath="notation"/>
<field xpath="@name"/>
</key>
<key name="identityConstraint">
<selector xpath=".//key|.//unique|.//keyref"/>
<field xpath="@name"/>
</key>
</element>
<simpleType name="allNNI">
<annotation><documentation>for maxOccurs</documentation></annotation>
<union memberTypes="nonNegativeInteger">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="unbounded"/>
</restriction>
</simpleType>
</union>
</simpleType>
<attributeGroup name="occurs">
<annotation><documentation>for all particles</documentation></annotation>
<attribute name="minOccurs" type="nonNegativeInteger" use="default" value="1"/>
<attribute name="maxOccurs" type="allNNI" use="default" value="1"/>
</attributeGroup>
<attributeGroup name="defRef">
<annotation><documentation>for element, group and attributeGroup,
which both define and reference</documentation></annotation>
<attribute name="name" type="NCName"/>
<attribute name="ref" type="QName"/>
</attributeGroup>
<group name="typeDefParticle">
<annotation>
<documentation>'complexType' uses this</documentation></annotation>
<choice>
<element name="group" type="groupRef"/>
<element ref="all"/>
<element ref="choice"/>
<element ref="sequence"/>
</choice>
</group>
<group name="groupDefParticle">
<annotation>
<documentation>'topLevelGroup' uses this</documentation></annotation>
<choice>
<element ref="all"/>
<element ref="choice"/>
<element ref="sequence"/>
</choice>
</group>
<group name="nestedParticle">
<choice>
<element name="element" type="localElement"/>
<element name="group" type="groupRef"/>
<element ref="choice"/>
<element ref="sequence"/>
<element ref="any"/>
</choice>
</group>
<group name="particle">
<choice>
<element name="element" type="localElement"/>
<element name="group" type="groupRef"/>
<element ref="all"/>
<element ref="choice"/>
<element ref="sequence"/>
<element ref="any"/>
</choice>
</group>
<complexType name="attribute">
<complexContent>
<extension base="annotated">
<sequence>
<element name="simpleType" minOccurs="0" type="localSimpleType"/>
</sequence>
<attributeGroup ref="defRef"/>
<attribute name="type" type="QName"/>
<attribute name="use" use="default" value="optional">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="prohibited"/>
<enumeration value="optional"/>
<enumeration value="required"/>
<enumeration value="default"/>
<enumeration value="fixed"/>
</restriction>
</simpleType>
</attribute>
<attribute name="value" use="optional" type="string"/>
<attribute name="form" type="formChoice"/>
</extension>
</complexContent>
</complexType>
<complexType name="topLevelAttribute">
<complexContent>
<restriction base="attribute">
<sequence>
<element ref="annotation" minOccurs="0"/>
<element name="simpleType" minOccurs="0" type="localSimpleType"/>
</sequence>
<attribute name="ref" use="prohibited"/>
<attribute name="form" use="prohibited"/>
<attribute name="use" use="prohibited"/>
<attribute name="name" use="required" type="NCName"/>
</restriction>
</complexContent>
</complexType>
<group name="attrDecls">
<sequence>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="attribute" type="attribute"/>
<element name="attributeGroup" type="attributeGroupRef"/>
</choice>
<element ref="anyAttribute" minOccurs="0"/>
</sequence>
</group>
<element name="anyAttribute" type="wildcard" id="anyAttribute">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-anyAttribute"/>
</annotation>
</element>
<group name="complexTypeModel">
<choice>
<element ref="simpleContent"/>
<element ref="complexContent"/>
<sequence>
<annotation>
<documentation>This branch is short for
<complexContent>
<restriction base="anyType">
...
</restriction>
</complexContent></documentation>
</annotation>
<group ref="typeDefParticle" minOccurs="0"/>
<group ref="attrDecls"/>
</sequence>
</choice>
</group>
<complexType name="complexType" abstract="true">
<complexContent>
<extension base="annotated">
<group ref="complexTypeModel"/>
<attribute name="name" type="NCName">
<annotation>
<documentation>Will be restricted to required or
forbidden</documentation>
</annotation>
</attribute>
<attribute name="mixed" type="boolean" use="default" value="false">
<annotation>
<documentation>Not allowed if simpleContent child is chosen.
May be overriden by setting on complexContent child.
</documentation>
</annotation>
</attribute>
<attribute name="abstract" type="boolean" use="default" value="false"/>
<attribute name="final" type="derivationSet"/>
<attribute name="block" type="derivationSet" use="default" value=""/>
</extension>
</complexContent>
</complexType>
<complexType name="topLevelComplexType">
<complexContent>
<restriction base="complexType">
<sequence>
<element ref="annotation" minOccurs="0"/>
<group ref="complexTypeModel"/>
</sequence>
<attribute name="name" type="NCName" use="required"/>
</restriction>
</complexContent>
</complexType>
<complexType name="localComplexType">
<complexContent>
<restriction base="complexType">
<sequence>
<element ref="annotation" minOccurs="0"/>
<group ref="complexTypeModel"/>
</sequence>
<attribute name="name" use="prohibited"/>
</restriction>
</complexContent>
</complexType>
<complexType name="restrictionType">
<complexContent>
<extension base="annotated">
<sequence>
<choice>
<group ref="typeDefParticle" minOccurs="0"/>
<group ref="simpleRestrictionModel" minOccurs="0"/>
</choice>
<group ref="attrDecls"/>
</sequence>
<attribute name="base" type="QName" use="required"/>
</extension>
</complexContent>
</complexType>
<complexType name="complexRestrictionType">
<complexContent>
<restriction base="restrictionType">
<sequence>
<element ref="annotation" minOccurs="0"/>
<group ref="typeDefParticle" minOccurs="0"/>
<group ref="attrDecls"/>
</sequence>
</restriction>
</complexContent>
</complexType>
<complexType name="extensionType">
<complexContent>
<extension base="annotated">
<sequence>
<group ref="typeDefParticle" minOccurs="0"/>
<group ref="attrDecls"/>
</sequence>
<attribute name="base" type="QName" use="required"/>
</extension>
</complexContent>
</complexType>
<element name="complexContent" id="complexContent">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-complexContent"/>
</annotation>
<complexType>
<complexContent>
<extension base="annotated">
<choice>
<element name="restriction" type="complexRestrictionType"/>
<element name="extension" type="extensionType"/>
</choice>
<attribute name="mixed" type="boolean">
<annotation>
<documentation>Overrides any setting on complexType parent.
</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
</element>
<complexType name="simpleRestrictionType">
<complexContent>
<restriction base="restrictionType">
<sequence>
<element ref="annotation" minOccurs="0"/>
<group ref="simpleRestrictionModel" minOccurs="0"/>
<group ref="attrDecls"/>
</sequence>
</restriction>
</complexContent>
</complexType>
<complexType name="simpleExtensionType">
<complexContent>
<restriction base="extensionType">
<sequence>
<annotation>
<documentation>No typeDefParticle group reference</documentation>
</annotation>
<element ref="annotation" minOccurs="0"/>
<group ref="attrDecls"/>
</sequence>
</restriction>
</complexContent>
</complexType>
<element name="simpleContent" id="simpleContent">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-simpleContent"/>
</annotation>
<complexType>
<complexContent>
<extension base="annotated">
<choice>
<element name="restriction" type="simpleRestrictionType"/>
<element name="extension" type="simpleExtensionType"/>
</choice>
</extension>
</complexContent>
</complexType>
</element>
<element name="complexType" substitutionGroup="redefinable" type="topLevelComplexType" id="complexType">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-complexType"/>
</annotation>
</element>
<simpleType name="derivationControls">
<restriction base="string">
<enumeration value="#all"/>
<enumeration value="substitution"/>
<enumeration value="extension"/>
<enumeration value="restriction"/>
</restriction>
</simpleType>
<simpleType name="derivationChoiceOrAll">
<annotation>
<documentation>A utility type, not for public use</documentation>
</annotation>
<restriction base="derivationControls">
<enumeration value="#all"/>
<enumeration value="extension"/>
<enumeration value="restriction"/>
</restriction>
</simpleType>
<simpleType name="derivationChoice">
<annotation>
<documentation>A utility type, not for public use</documentation>
</annotation>
<restriction base="derivationChoiceOrAll">
<enumeration value="extension"/>
<enumeration value="restriction"/>
</restriction>
</simpleType>
<simpleType name="blockSet">
<annotation>
<documentation>#all or (possibly empty) subset of {substitution, extension,
restriction}</documentation>
<documentation>A utility type, not for public use</documentation>
</annotation>
<list itemType="derivationControls"/>
</simpleType>
<simpleType name="derivationSet">
<annotation>
<documentation>#all or (possibly empty) subset of {extension,
restriction}</documentation>
<documentation>A utility type, not for public use</documentation>
</annotation>
<list itemType="derivationChoiceOrAll"/>
</simpleType>
<complexType name="element" abstract="true">
<annotation>
<documentation>The element element can be used either
at the toplevel 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.</documentation>
</annotation>
<complexContent>
<extension base="annotated">
<sequence>
<choice minOccurs="0">
<element name="simpleType" type="localSimpleType"/>
<element name="complexType" type="localComplexType"/>
</choice>
<element ref="identityConstraint" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attributeGroup ref="defRef"/>
<attribute name="type" type="QName"/>
<attribute name="substitutionGroup" type="QName"/>
<attributeGroup ref="occurs"/>
<attribute name="default" type="string"/>
<attribute name="fixed" type="string"/>
<attribute name="nullable" type="boolean" use="default" value="false"/>
<attribute name="abstract" type="boolean" use="default" value="false"/>
<attribute name="final" type="derivationSet" use="default" value=""/>
<attribute name="block" type="blockSet" use="default" value=""/>
<attribute name="form" type="formChoice"/>
</extension>
</complexContent>
</complexType>
<complexType name="topLevelElement">
<complexContent>
<restriction base="element">
<sequence>
<element ref="annotation" minOccurs="0"/>
<choice minOccurs="0">
<element name="simpleType" type="localSimpleType"/>
<element name="complexType" type="localComplexType"/>
</choice>
<element ref="identityConstraint" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="ref" use="prohibited"/>
<attribute name="form" use="prohibited"/>
<attribute name="minOccurs" use="prohibited"/>
<attribute name="maxOccurs" use="prohibited"/>
<attribute name="name" use="required" type="NCName"/>
</restriction>
</complexContent>
</complexType>
<complexType name="localElement">
<complexContent>
<restriction base="element">
<sequence>
<element ref="annotation" minOccurs="0"/>
<choice minOccurs="0">
<element name="simpleType" type="localSimpleType"/>
<element name="complexType" type="localComplexType"/>
</choice>
<element ref="identityConstraint" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="substitutionGroup" use="prohibited"/>
<attribute name="final" use="prohibited"/>
</restriction>
</complexContent>
</complexType>
<element name="element" type="topLevelElement" substitutionGroup="schemaTop" id="element">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-element"/>
</annotation>
</element>
<complexType name="group" abstract="true">
<annotation>
<documentation>group type for explicit groups, named top-level groups and
group references</documentation>
</annotation>
<complexContent>
<extension base="annotated">
<group ref="particle" minOccurs="0" maxOccurs="unbounded"/>
<attributeGroup ref="defRef"/>
<attributeGroup ref="occurs"/>
</extension>
</complexContent>
</complexType>
<complexType name="realGroup">
<complexContent>
<restriction base="group">
<sequence>
<element ref="annotation" minOccurs="0"/>
<group ref="groupDefParticle" minOccurs="0" maxOccurs="1"/>
</sequence>
</restriction>
</complexContent>
</complexType>
<complexType name="namedGroup">
<complexContent>
<restriction base="realGroup">
<sequence>
<element ref="annotation" minOccurs="0"/>
<group ref="groupDefParticle" minOccurs="1" maxOccurs="1"/>
</sequence>
<attribute name="name" use="required" type="NCName"/>
<attribute name="ref" use="prohibited"/>
<attribute name="minOccurs" use="prohibited"/>
<attribute name="maxOccurs" use="prohibited"/>
</restriction>
</complexContent>
</complexType>
<complexType name="groupRef">
<complexContent>
<restriction base="realGroup">
<sequence>
<element ref="annotation" minOccurs="0"/>
</sequence>
<attribute name="ref" use="required" type="QName"/>
<attribute name="name" use="prohibited"/>
</restriction>
</complexContent>
</complexType>
<complexType name="explicitGroup">
<annotation>
<documentation>group type for the three kinds of group</documentation>
</annotation>
<complexContent>
<restriction base="group">
<sequence>
<element ref="annotation" minOccurs="0"/>
<group ref="nestedParticle" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="name" type="NCName" use="prohibited"/>
<attribute name="ref" type="QName" use="prohibited"/>
</restriction>
</complexContent>
</complexType>
<element name="all" id="all">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-all"/>
</annotation>
<complexType>
<annotation>
<documentation>Only elements allowed inside</documentation>
</annotation>
<complexContent>
<restriction base="explicitGroup">
<sequence>
<element ref="annotation" minOccurs="0"/>
<element name="element" minOccurs="0" maxOccurs="unbounded">
<complexType>
<annotation>
<documentation>restricted max/min</documentation>
</annotation>
<complexContent>
<restriction base="localElement">
<sequence>
<element ref="annotation" minOccurs="0"/>
<choice minOccurs="0">
<element name="simpleType" type="localSimpleType"/>
<element name="complexType" type="localComplexType"/>
</choice>
<element ref="identityConstraint" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="minOccurs" use="default" value="1">
<simpleType>
<restriction base="nonNegativeInteger">
<enumeration value="0"/>
<enumeration value="1"/>
</restriction>
</simpleType>
</attribute>
<attribute name="maxOccurs" use="default" value="1">
<simpleType>
<restriction base="allNNI">
<enumeration value="0"/>
<enumeration value="1"/>
</restriction>
</simpleType>
</attribute>
</restriction>
</complexContent>
</complexType>
</element>
</sequence>
</restriction>
</complexContent>
</complexType>
</element>
<element name="choice" type="explicitGroup" id="choice">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-choice"/>
</annotation>
</element>
<element name="sequence" type="explicitGroup" id="sequence">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-sequence"/>
</annotation>
</element>
<element name="group" substitutionGroup="redefinable" type="namedGroup" id="group">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-group"/>
</annotation>
</element>
<complexType name="wildcard">
<complexContent>
<extension base="annotated">
<attribute name="namespace" type="namespaceList" use="default" value="##any"/>
<attribute name="processContents" use="default" value="strict">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="skip"/>
<enumeration value="lax"/>
<enumeration value="strict"/>
</restriction>
</simpleType>
</attribute>
</extension>
</complexContent>
</complexType>
<element name="any" id="any">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-any"/>
</annotation>
<complexType>
<complexContent>
<extension base="wildcard">
<attributeGroup ref="occurs"/>
</extension>
</complexContent>
</complexType>
</element>
<annotation>
<documentation> simple type for the value of the 'namespace' attr of
'any' and 'anyAttribute'</documentation>
</annotation>
<annotation>
<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</documentation>
</annotation>
<simpleType name="namespaceList">
<annotation>
<documentation>##any | ##other | list of {uri, ##targetNamespace,
##local}</documentation>
<documentation>A utility type, not for public use</documentation>
</annotation>
<restriction base="string"/>
</simpleType>
<element name="attribute" substitutionGroup="schemaTop" type="topLevelAttribute" id="attribute">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-attribute"/>
</annotation>
</element>
<complexType name="attributeGroup" abstract="true">
<complexContent>
<extension base="annotated">
<group ref="attrDecls"/>
<attributeGroup ref="defRef"/>
</extension>
</complexContent>
</complexType>
<complexType name="namedAttributeGroup">
<complexContent>
<restriction base="attributeGroup">
<sequence>
<element ref="annotation" minOccurs="0"/>
<group ref="attrDecls"/>
</sequence>
<attribute name="name" use="required" type="NCName"/>
<attribute name="ref" use="prohibited"/>
</restriction>
</complexContent>
</complexType>
<complexType name="attributeGroupRef">
<complexContent>
<restriction base="attributeGroup">
<sequence>
<element ref="annotation" minOccurs="0"/>
</sequence>
<attribute name="ref" use="required" type="QName"/>
<attribute name="name" use="prohibited"/>
</restriction>
</complexContent>
</complexType>
<element name="attributeGroup" type="namedAttributeGroup" substitutionGroup="redefinable" id="attributeGroup">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-attributeGroup"/>
</annotation>
</element>
<element name="include" id="include">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-include"/>
</annotation>
<complexType>
<complexContent>
<extension base="annotated">
<attribute name="schemaLocation" type="uriReference" use="required"/>
</extension>
</complexContent>
</complexType>
</element>
<element name="redefine" id="redefine">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-redefine"/>
</annotation>
<complexType>
<complexContent>
<extension base="openAttrs">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="annotation"/>
<element ref="redefinable"/>
</choice>
<attribute name="schemaLocation" type="uriReference" use="required"/>
</extension>
</complexContent>
</complexType>
</element>
<element name="import" id="import">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-import"/>
</annotation>
<complexType>
<complexContent>
<extension base="annotated">
<attribute name="namespace" type="uriReference"/>
<attribute name="schemaLocation" type="uriReference"/>
</extension>
</complexContent>
</complexType>
</element>
<simpleType name="XPathExprApprox">
<annotation>
<documentation>An XPath expression</documentation>
<documentation>A utility type, not for public use</documentation>
</annotation>
<restriction base="string">
<pattern value="(/|//|\.|\.\.|:|::|\||(\c-[.:/|])+)+">
<annotation>
<documentation>A VERY permissive definition, probably not even
right</documentation>
</annotation>
</pattern>
</restriction>
</simpleType>
<complexType name="XPathSpec">
<complexContent>
<extension base="annotated">
<attribute name="xpath" type="XPathExprApprox"/>
</extension>
</complexContent>
</complexType>
<element name="selector" type="XPathSpec" id="selector">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-selector"/>
</annotation>
</element>
<element name="field" id="field" type="XPathSpec">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-field"/>
</annotation>
</element>
<complexType name="keybase">
<complexContent>
<extension base="annotated">
<sequence>
<element ref="selector"/>
<element ref="field" minOccurs="1" maxOccurs="unbounded"/>
</sequence>
<attribute name="name" type="NCName" use="required"/>
</extension>
</complexContent>
</complexType>
<element name="identityConstraint" type="keybase" abstract="true" id="identityConstraint">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-identityConstraint"/>
</annotation>
</element>
<element name="unique" substitutionGroup="identityConstraint" id="unique">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-unique"/>
</annotation>
</element>
<element name="key" substitutionGroup="identityConstraint" id="key">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-key"/>
</annotation>
</element>
<element name="keyref" substitutionGroup="identityConstraint" id="keyref">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-keyref"/>
</annotation>
<complexType>
<complexContent>
<extension base="keybase">
<attribute name="refer" type="QName" use="required"/>
</extension>
</complexContent>
</complexType>
</element>
<element name="notation" substitutionGroup="schemaTop" id="notation">
<annotation>
<documentation
source="http://www.w3.org/TR/xmlschema-1/#element-notation"/>
</annotation>
<complexType>
<complexContent>
<extension base="annotated">
<attribute name="name" type="NCName" use="required"/>
<attribute name="public" type="public" use="required"/>
<attribute name="system" type="uriReference"/>
</extension>
</complexContent>
</complexType>
</element>
<simpleType name="public">
<annotation>
<documentation>A public identifier, per ISO 8879</documentation>
<documentation>A utility type, not for public use</documentation>
</annotation>
<restriction base="string"/>
</simpleType>
<annotation>
<documentation>notations for use within XML Schema schemas</documentation>
</annotation>
<notation name="XMLSchemaStructures" public="structures" system="http://www.w3.org/2000/10/XMLSchema.xsd"/>
<notation name="XML" public="REC-xml-19980210" system="http://www.w3.org/TR/1998/REC-xml-19980210"/>
<complexType name="anyType" mixed="true">
<annotation>
<documentation>Not the real urType, but as close an approximation as we can
get in the XML representation</documentation>
</annotation>
<sequence>
<any minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<anyAttribute/>
</complexType>
</schema>
NOTE:
And that is the end of the schema for XML Schema: Structures.
C References (normative) *
-
Cambridge Communiqué
-
The
Cambridge Communiqué, Ralph Swick
and Henry S. Thompson, editors, 7 October 1999. See http://www.w3.org/TR/schema-arch
-
DCD
- Document
Content Description for XML (DCD), Tim Bray et al. W3C, 10 August 1998.
See http://www.w3.org/TR/NOTE-dcd
-
DDML
- Document
Definition Markup Language. See
http://www.w3.org/TR/NOTE-ddml
-
XML Schema: Primer
-
XML Schema:
Primer, David C. Fallside, ed. See http://www.w3.org/TR/2000/WD-xmlschema-0-20000922/primer.html
-
HTML-4
- HTML 4.0
Specification, Dave Raggett et al. W3C, 1998. See
http://www.w3.org/TR/REC-html40/
-
ISO-11404
- ISO
11404 -- Information Technology -- Programming Languages, their environments
and system software interfaces -- Language-independent datatypes,
ISO/IEC 11404:1996(E).
-
RFC-1808
- RFC
1808,Relative Uniform Resource Locators. Internet Engineering Task
Force. See http://www.ietf.org/rfc/rfc1808.txt
-
SOX
- Schema for
Object-oriented XML, Matt Fuchs, et al. W3C, 1998. See
http://www.w3.org/Submission/1998/15/
-
SOX-1.1
- Schema
for Object-oriented XML, Version 1.1, Matt Fuchs, et al. W3C, 1999. See
???
-
URI
- Uniform
Resource Identifiers (URI): Generic Syntax and Semantics. See
http://www.ics.uci.edu/~fielding/url/draft-fielding-uri-syntax-01.txt
-
URL
- RFC
1738,Uniform Resource Locators (URL). Internet Engineering Task
Force. See http://www.ietf.org/rfc/rfc1738.txt
-
URN
- RFC 2141,URN
Syntax. Internet Engineering Task Force. See
http://www.ietf.org/rfc/rfc2141.txt
-
WAI-PAGEAUTH
-
WAI Accessibility Guidelines: Page Authoring, Gregg Vanderheiden
et al. W3C, 14-Apr-1998. See http://www.w3.org/TR/WAI-WEBCONTENT/
-
WEBARCH-EXTLANG
- Web Architecture: Extensible Languages, Tim
Berners-Lee and Dan Connolly. W3C, 10 Feb 1998. See
http://www.w3.org/TR/NOTE-webarch-extlang
-
WEBSGML
-
Proposed TC for WebSGML Adaptations for SGML, C. F. Goldfarb, ed.,
14 June 1997. See http://www.sgmlsource.com/8879rev/n1929.htm
-
XML Schemas: Datatypes
-
XML Schema Part 2: Datatypes, Paul V. Biron and Ashok
Malhotra, eds. See http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/datatypes.html
-
XML Schema Requirements
-
XML Schema Requirements , Ashok Malhotra and Murray Maloney, ed.,
W3C, 15 February 1999. See http://www.w3.org/TR/NOTE-xml-schema-req
-
XDR
- XML-Data
Reduced, Frankston, Charles, and Henry S. Thompson, ed. See
http://www.ltg.ed.ac.uk/~ht/XMLData-Reduced.htm
-
XLink
- XML Linking
Language (XLink), Eve Maler and Steve DeRose, W3C, 3 March 1998. See
http://www.w3.org/TR/WD-xlink
-
XML
- Extensible
Markup Language (XML) 1.0, Tim Bray, et al. W3C, 10 February 1998. See
http://www.w3.org/TR/REC-xml
-
XSLT
- Extensible
Stylesheet Language Transformations, James Clark, W3C, 21 April 1999.
See http://www.w3.org/TR/1999/WD-xslt-19990421
-
XML-Data
-
XML-Data, Andrew Layman, et al. W3C, 05 January 1998. See
http://www.w3.org/TR/1998/NOTE-XML-data-0105/
-
XML-Infoset
- XML Information Set (public WD),
David Megginson et al., W3C, 1999. See
http://www.w3.org/TR/xml-infoset
-
XML-Namespaces
-
Namespaces in XML, Tim Bray et al., W3C, 1998. See
http://www.w3.org/TR/WD-xml-names/
-
XPointer
- XML
Pointer Language (XPointer), Eve Maler and Steve DeRose, W3C, 3 March
1998. See http://www.w3.org/TR/xptr
-
XPath
-
XML Path Language, James Clark
and Steve DeRose, editors, 16 November 1999. See http://www.w3.org/TR/xpath
-
XSchema
- XSchema
Specification, Simon St. Laurent, Ronald Bourret, John Cowan, et al.,
Version 1.0, Draft, 18 October 1998. See
http://www.simonstl.com/xschema/spec/xscspecv4.htm
For more general information, consult
http://purl.oclc.org/NET/xschema
E (non-normative) DTD for Schemas
The DTD for XML Schema: Structures is given below. Note there is no
implication here the 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 200010//EN"
Official Location: http://www.w3.org/2000/10/XMLSchema.dtd -->
<!-- Id: XMLSchema.dtd,v 1.15 2000/09/22 13:04:59 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 the datatype element and its components
are defined in XML Schema: Part 2: Datatypes -->
<!ENTITY % xs-datatypes PUBLIC 'datatypes' 'datatypes.dtd' >
<!ENTITY % p ''> <!-- can be overriden in the internal subset of a
schema document to establish a namespace prefix -->
<!ENTITY % s ''> <!-- 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">
<!-- 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 % complexDerivationChoice "(extension|restriction)">
<!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/2000/10/XMLSchema'
finalDefault %complexDerivationSet; ''
blockDefault %blockSet; ''
id ID #IMPLIED
elementFormDefault %formValues; 'unqualified'
attributeFormDefault %formValues; 'unqualified'
%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 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; 'false'
final %complexDerivationSet; #IMPLIED
block %complexDerivationSet; ''
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; (%restriction;|%extension;)>
<!ATTLIST %complexContent;
mixed (true|false) #IMPLIED
%complexContentAttrs;>
<!-- restriction should use the branch defined above, not the simple
one from part2; extension should use the full model -->
<!ELEMENT %simpleContent; (%restriction;|%extension;)>
<!ATTLIST %simpleContent; %simpleContentAttrs;>
<!-- restriction should use the simple branch from part2, not the
one defined above; extension should have no particle -->
<!ELEMENT %extension; (%particleAndAttrs;)>
<!ATTLIST extension
base %QName; #REQUIRED
%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
nullable %boolean; 'false'
substitutionGroup %QName; #IMPLIED
abstract %boolean; 'false'
final %complexDerivationSet; #IMPLIED
block %blockSet; ''
default CDATA #IMPLIED
fixed CDATA #IMPLIED
form %formValues; #IMPLIED
%elementAttrs;>
<!-- type and ref are mutually exclusive.
name and ref are mutually exculsive, 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 (0|1) '1'
maxOccurs (0|1) '1'
id ID #IMPLIED
%allAttrs;>
<!ELEMENT %choice; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)>
<!ATTLIST %choice;
minOccurs %nonNegativeInteger; '1'
maxOccurs CDATA '1'
id ID #IMPLIED
%choiceAttrs;>
<!ELEMENT %sequence; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)>
<!ATTLIST %sequence;
minOccurs %nonNegativeInteger; '1'
maxOccurs CDATA '1'
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'
%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'
%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|fixed|default) #IMPLIED
value CDATA #IMPLIED
form %formValues; #IMPLIED
%attributeAttrs;>
<!-- type and ref are mutually exclusive.
name and ref are mutually exculsive, one is required -->
<!-- value only if use is fixed, required or default, or name -->
<!-- name and use are mutually exclusive -->
<!-- default for use is optional when nested, none otherwise -->
<!-- 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
id ID #IMPLIED
refer %QName; #REQUIRED
%keyrefAttrs;>
<!ELEMENT %selector; ((%annotation;)?)>
<!ATTLIST %selector;
xpath %XPathExpr; #REQUIRED
%selectorAttrs;>
<!ELEMENT %field; ((%annotation;)?)>
<!ATTLIST %field;
xpath %XPathExpr; #REQUIRED
%fieldAttrs;>
<!-- Schema combination mechanisms -->
<!ELEMENT %include; (%annotation;)?>
<!ATTLIST %include; schemaLocation %URIref; #REQUIRED
%includeAttrs;>
<!ELEMENT %import; (%annotation;)?>
<!ATTLIST %import; namespace %URIref; #IMPLIED
schemaLocation %URIref; #IMPLIED
%importAttrs;>
<!ELEMENT %redefine; (%annotation; | %simpleType; | %complexType; |
%attributeGroup; | %group;)*>
<!ATTLIST %redefine; schemaLocation %URIref; #REQUIRED
%redefineAttrs;>
<!ELEMENT %notation; (%annotation;)?>
<!ATTLIST %notation;
name %NCName; #REQUIRED
id ID #IMPLIED
public CDATA #REQUIRED
system %URIref; #IMPLIED
%notationAttrs;>
<!NOTATION XMLSchemaStructures PUBLIC 'structures'
'http://www.w3.org/2000/10/XMLSchema.xsd' >
<!NOTATION XML PUBLIC 'REC-xml-1998-0210'
'http://www.w3.org/TR/1998/REC-xml-19980210' >
F (non-normative) Analysis of the Unique Particle Attribution constraint
A specification of the import of Unique Particle Attribution (§5.7) which does
not appeal to a processing model is difficult. What follows is intended as
guidance, without claiming to be complete.
[Definition:] We say that two non-group
particles overlap if
or
-
They are both element declaration particles one of which is in the
other's substitution group
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. Determinise 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-labelled transitions from it, or a
QName-labelled 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.
G Acknowledgements (non-normative)
The following have contributed material to this draft:
- David Fallside, IBM
- Scott Lawrence, Agranat Systems
- Andrew Layman, Microsoft
- Eve L. Maler, Sun Microsystems
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.
The current members of the XML Schema Working Group are:
Jim Barnette, Defense Information Systems Agency (DISA); David Beech, Oracle Corp.; Paul V. Biron, Health Level Seven; Don Box, DevelopMentor; Allen Brown, Microsoft; Lee Buck, Extensibility; Charles E. Campbell, Informix; Peter Chen, Bootstrap Alliance and LSU; David Cleary, Progress Software; Dan Connolly, W3C (staff contact); Roger L. Costello, MITRE; Ugo Corda, Xerox; Andrew Eisenberg, Progress Software; David Ezell, Hewlett Packard Company; David Fallside, IBM; Matthew Fuchs, Commerce One; Andrew Goodchild, Distributed Systems Technology Centre (DSTC Pty Ltd); Paul Grosso, ArborText, Inc; Martin Gudgin, DevelopMentor; Dave Hollander, CommerceNet (co-chair); Mary Holstege, Calico Commerce; Jane Hunter, Distributed Systems Technology Centre (DSTC Pty Ltd); Rick Jelliffe, Academia Sinica; Andrew Layman, Microsoft; Dmitry Lenkov, Hewlett Packard Company; Eve Maler, Sun Microsystems; Ashok Malhotra, IBM; Murray Maloney, Commerce One; John McCarthy, Lawrence Berkeley National Laboratory; Noah Mendelsohn, Lotus Development Corporation; Don Mullen, Extensibility; Frank Olken, Lawrence Berkeley National Laboratory; Dave Peterson, Graphic Communications Association; Mark Reinhold, Sun Microsystems; Jonathan Robie, Software AG; Lew Shannon, NCR; C. M. Sperberg-McQueen, W3C (co-chair); Bob Streich, Calico Commerce; Henry S. Thompson, University of Edinburgh; Matt Timmermans, Microstar; Jim Trezzo, Oracle Corp.; Steph Tryphonas, Microstar; Mark Tucker, Health Level Seven; Asir S. Vedamuthu, webMethods, Inc; Priscilla Walmsley, XMLSolutions; Norm Walsh, ArborText, Inc; Aki Yoshida, SAP AG
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.
Paula Angerstein, Vignette Corporation; Gabe Beged-Dov, Rogue Wave Software; Greg Bumgardner, Rogue Wave Software; Dean Burson, Lotus Development Corporation; Rob Ellman, Calico Commerce; George Feinberg, Object Design; Charles Frankston, Microsoft; Ernesto Guerrieri, Inso; Michael Hyman, Microsoft; Renato Iannella, Distributed Systems Technology Centre (DSTC Pty Ltd); Dianne Kennedy, Graphic Communications Association; Janet Koenig, Sun Microsystems; Setrag Khoshafian, Technology Deployment International (TDI); Ara Kullukian, Technology Deployment International (TDI); Murata Makoto, Xerox; Chris Olds, Wall Data; Shriram Revankar, Xerox; John C. Schneider, MITRE; William Shea, Merrill Lynch; Ralph Swick, W3C; Tony Stewart, Rivcom
H Description of changes (non-normative)
This section gives brief summaries of the substantive changes to this
specification since the public working draft of 7 April 2000.
H.1 Equivalence classes renamed
Equivalence classes have been renamed substitution groups, to reflect the
fact that their semantics is not symmetrical.
H.2 Content model of complexType element changed
The content model of the complexType element has been
significantly changed, allowing for tighter content models and a better fit
between the abstract component and its XML Representation. The side conditions
on well-formed representations not captured in the schema for schemas have
accordingly been downsized. No changes to the abstract complex type definition
component were involved.
H.4 Simple type definitions changed
Both the abstract component and the XML representation for simple type
definitions have been changed, the former to handle list type
definitions more cleanly and to support union type definitions, the latter to
give tighter content models and a better fit
between the abstract component and its XML Representation.
H.5 Simple value normalization
All values governed by simple type definitions are now subject to
normalization, as in XML 1.0 attribute value normalization.
H.6 Schema component redefinition
A new form of schema composition operation, similar to that provided by
include but allowing constrained
redefinition of the included components has been added, using a redefine element.
H.7 Element and attribute reference restricted
The ability to override properties of global element declarations when
referencing them from complex type definitions has been removed. As a
consequence of this attribute declarations no longer have max- and minOccurs properties.
H.8 Default values for minOccurs and maxOccurs
attributes
The defaulting for these attributes of element has been simplified: it is now
1 in both cases, with no interdependencies.
H.9 Content model for Model Group definition
The content model for the group element when it occurs at
the top level has been tightened, to allow only a single all,
choice, group or sequence child.
H.10 XML Schema namespace URI
In recognition of the above changes, the namespace URI for XML Schema ahs
been changed to http://www.w3.org/2000/10/XMLSchema. There has been no change to the
XML Schema instance namespace URI, which remains http://www.w3.org/2000/10/XMLSchema-instance.
H.11 Error codes
A standard format for identifying validation failures and schema form
errors is now provided, and a post-schema-validation infoset property specified
which processors may, but need not, use to record validation failure codes.
H.12 DTD non-normative
To avoid potential confusion the DTD for schemas is no longer normative,
but its use is still encouraged.
H.13 Abstract types in element declarations
These had inadvertently been disallowed: they are now allowed, since
the use of either substitution groups or xsi:type may derive a
non-abstract type in all actual occurrences.
H.14 Schema components as info items (optional)
Processors may, but need not, provide detailed information in the
form of
post-schema-validation infoset contributions of information items
corresponding to element declaration and type definition components. They may
also do the same for schema components in general.
H.15 Ur-types
The structure and nature of the ur-type has been clarified, with names
provided for both its complex and simple forms. Approximations to definitions
at both the component and XML representation layer are now provided. The
status of lists and unions wrt the type hierarchy has been regularised.
H.16 Type-related validation properties
In the post-schema-validation infoset, element and attribute items now
always have type information, even when validation is lax. In this case the type
information given is the simple or complex ur-type, as appropriate.
H.17 Facilitate online schema validation
The first xsi:schemaLocation for a namespace must not be preceded by any
names from that namespace; otherwise it is an error.
H.18 Complex type definitions by extension
Complex type definitions which extended other complex type definitions whose base type
definition is simple had inadvertently been disallowed: this is now allowed.