This specification of the XML Schema language is a Candidate
Recommendation of the World Wide Web Consortium. This means that the XML
Schema Working Groupconsiders the specification to
be stable and encourages implementation and comment on the
specification during this period. The Candidate Recommendation review
period ends on 15 December 2000. Please send review comments before
the review period ends to www-xml-schema-comments@w3.org (public mailing list archive). Readers may find Description of changes (non-normative) (§J) helpful in identifying the major changes since the Last Call Public Working Draft.
During the Candidate Recommendation phase, although feedback based on
any aspect of implementation experience is welcome, there are certain aspects of the
design presented herein for which the Working Group is particularly
interested in feedback. These are designated priority feedback aspects
of the design, and identified as such in editorial notes throughout
this draft.
Should this specification prove very difficult or impossible to
implement, the Working Group will return the document to Working Draft
status and make necessary changes. Otherwise, the Working Group
anticipates asking the W3C Director to advance this document to
Proposed Recommendation.
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 an introduction
to the XML Schema abstract data model, along with
other terminology used throughout this document.
Chapter 3, Schema Component Details (§3), specifies the precise
semantics of each component of the abstract model.
Chapter 4, XML Representation of Schemas and Schema Components (§4), describes how to represent
schemas as one or more XML documents, with reference to a DTD and XML Schema
for an XML Schema document type, along with a detailed mapping between the elements and
attribute vocabulary of this representation and the components and properties
of the abstract model.
Chapter 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, inclusion and redefinition of declarations and definitions and
the foundations of schema-validity assessment.
Chapter 7 discusses Schemas and schema-validity assessment (§7), including the
overall approach to schema-validity assessment of documents, and responsibilities of schema-aware
processors.
The normative appendices include a Schema for Schemas (normative) (§A) for the XML representation of schemas and
References (normative) (§B).
The non-normative appendices include the DTD for Schemas (non-normative) (§F) and a Glossary (non-normative) (§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 normalization and defaulting of attribute
and element values. Schemas have
facilities for self-documentation. Thus, XML Schema: Structures can be used to define, describe and catalogue XML
vocabularies for classes of XML documents.
Any application that consumes well-formed XML can use the XML Schema: Structures
formalism to express syntactic, structural and value constraints applicable to
its document instances. The XML Schema: Structures formalism allows a useful level of
constraint checking to be described and implemented for a wide spectrum of XML
applications. However, the language defined by this specification does not attempt to provide
all the facilities that might be needed by any
application. Some applications may require constraint capabilities not
expressible in this language, and so may need to perform their own additional
validations.
1.2 Dependencies on Other Specifications
The definition of XML Schema: Structures depends on the following specifications:,
[XML-Infoset],
[XML-Namespaces],
[XPath], and
[XML Schemas: Datatypes]. Before this specification is finally completed, we will
need to account for any changes [XML Base] 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. See [XML Schemas: Datatypes] for the details of
the uriReference type and all uses of URI references in this specification.
See Required Information Set Items and Properties (normative) (§D) for a tabulation of the information items
and properties specified in [XML-Infoset] which this
specification requires as a precondition to schema-aware processing.
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.example.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 context,
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,
as are the illustrations of the XML representation element information items.
NOTE:
The illustrations are derived automatically from the Schema for Schemas (normative) (§A). In the case of apparent conflict, the Schema for Schemas (normative) (§A) takes precedence, as it, together with the Schema Representation Constraints provide the normative statement of
the form of XML representations.
XML Representation Summary:
example Element Information Item |
|
<example
count = integer
size = (small | medium | large) : medium>
Content: (all | any*)
</example>
|
|
|
The following highlighting is used for non-normative commentary in
this document:
Ed. Note: Priority Feedback Request
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 normalized and/or default values for
attributes and elements and
the types of element and attribute information items.
Schema-validity assessment has two aspects:
- determining local schema-validity, that is
whether an element or attribute information item satisfies the
constraints embodied in the relevant
components of an XML Schema;
- Synthesising an overall validation outcome for the item,
combining local schema-validity with the results of schema-validity
assessments of its descendants, if any, and
adding appropriate augmentations to the infoset to record this outcome.
Throughout this specification, [Definition:] the
word valid and its derivatives are used to refer to
item 1 above, the determination of local
schema-validity.
Throughout this specification, [Definition:] the work assessment is used to refer
to the whole rich process of
local validation, schema-validity assessment and infoset augmentation.
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 assessment 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 Schemas and schema-validity assessment (§7).
[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
assessment 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.
Validation, defined in detail in Schema Component Details (§3), is a
relation between information items and schema components. For example, an
attribute information item may validate respect to an attribute
declaration, a list of element information items may validate with
respect to a content model, and so on. The following sections briefly
introduce the kinds of components in the
schema abstract data model, other major features of the abstract
model, and how they contribute to validation.
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 of simple type definitions and the
validation semantics associated with them, 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 belongs to a particular simple
type or to contain a sequence of element information items which conforms to a particular model group, with or without character information items as well.
Each complex type definition 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
validation semantics 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 is described in a section below. Also included is a discussion
of element substitution groups, which is a feature provided in conjunction with
element declarations.
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 (possibly empty) 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 ellipses:
<!ELEMENT A . . .>
<!ATTLIST A . . .>
Element declarations contribute to
validation as part of model group validation, when their defaults and type components are checked against an element
information item with a matching name and namespace, and by triggering
identity-constraint definition validation.
See Element Declaration Details (§3.3) for the composition and
validation semantics 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.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
validation semantics 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
validation as part of complex type definition validation, when they allow anywhere
from zero to many element information items or sequences thereof, depending on
their contents and occurrence
constraints.
[Definition:] A particle can
be used in a complex type definition to constrain the validation
of the [children] of an element information item; such a particle is called
a content model.
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
validation semantics 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
An identity-constraint definition is an association between a name and one of
several varieties of
identity-constraint related to uniqueness and reference. All the
varieties use [XPath] expressions to pick out sets of
information items relative to particular target element
information items which are unique, or a key, or a valid reference, within
a specified scope. An element information item is only valid with
respect to an element declaration
with identity-constraint definitions if those definitions are all satisfied for all the descendants
of that element information item which they pick out.
See Identity-constraint Definition Details (§3.10) for the composition and
validation semantics 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 provided to enable
the re-use of pieces of complex type definitions: model group definitions
and attribute group definitions.
2.3 Constraints and Validation Rules
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 validation, that is
the constraints on information items which schema components supply. In fact
however this specification provides four different kinds of normative statements about schema
components, their representations in XML and their contribution to the
validation of information items:
-
Constraint on Schemas
-
[Definition:] 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).
-
Schema Representation Constraint
-
[Definition:] Constraints on the
representation of schema components in XML. Some but not all of these are expressed in DTD for Schemas (non-normative) (§F) and Schema for Schemas (normative) (§A). Largely to be
found in XML Representation of Schemas and Schema Components (§4).
-
Validation Rules
-
[Definition:] Contributions to validation associated with schema components. 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.
-
Schema Information Set
Contribution
-
[Definition:] Augmentations to post-schema-validation infosets
expressed by schema components, which follow
as a consequence of validation and/or assessment.
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 white space, and the semantics of
ID and IDREF.) By including schema
information set contributions, this specification makes explicit some features
that XML 1.0 left implicit.
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 Rules,
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 and assessment.
NOTE:
By separating the conformance requirements relating to the concrete syntax of XML schema
documents, this specification admits processors
which use schemas stored in optimized 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 specification 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 Validated
The XML representation of schema components uses a vocabulary
identified by the namespace URI http://www.w3.org/2000/10/XMLSchema. For brevity, the text and examples in this specification use the prefix
xs: to stand for this namespace; in practice,
any prefix can be used.
XML Schema: Structures also defines several attributes for direct use in any XML documents. These attributes are in a different namespace,
which has the namespace 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 assessment.
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.
[Definition:] Throughout this specification, the
term absent is used as a distinguished value denoting absence.
Any property not
identified as optional is required to be present, optional properties which are
not present are taken to have absent. 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.
The above definition means that comments and processing instructions,
even in the midst of text, are ignored for all validation purposes.
[Definition:] When we refer to the
normalized value of an element or
attribute information item, we mean an initial value whose white space, if any, has been
normalized according to the value of the whiteSpace facet of the
simple type definition used in its validation:
-
preserve
-
No normalization is done, the value is the normalized value
-
replace
-
All occurrences of
#x9 (tab), #xA (linefeed) and
#xD (carriage return) are replaced with #x20 (space).
-
collapse
-
Subsequent to the replacements specified above under replace,
contiguous sequences of
#x20s are collapsed to a single
#x20, and initial and/or final #x20s 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 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 takes place, as for instance when
character entity references in attribute values result in white space characters
other than spaces in their initial values.
Many properties are identified below as having
other schema components or sets of components as values. For the purposes of exposition, the definitions in
this section assume that (unless the property is explicitly identified as
optional) all such values are in fact present. When schema
components are constructed from XML representations involving reference by name
to other components, this assumption may be violated if one or more references
cannot be resolved. This specification addresses the matter of missing
components in a uniform manner, described in Missing Sub-components (§7.3): no mention of
handling missing components will be found in the individual component
descriptions below.
It is important to recognise that processors cannot be sure that names
will not resolve only on the basis of the schema document in which they occur.
By the time the component corresponding to the XML representation which
includes the name is actually needed for validation an appropriately-named component may have become available: see Schemas and schema-validity assessment (§7) for details.
As the above makes clear, at the level of schema components and validation, reference to components by name is normally not involved. In a
few cases, however, qualified names appearing in information items being
validated must be resolved to schema components by such lookup. The following
constraint is appealed to in these cases.
Validation Rule: 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
validation by appeal to the appropriate
property of the schema being used for the
assessment. Each such property indexes components by name. The table to use is determined by the kind of component specified, that is, the table which is the value of:
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
Schema components provide a wealth of information about the basis of
assessment, which may well be of relevance to
subsequent processing. Reflecting component structure into a form suitable for
inclusion in the post-schema-validation infoset is the way this specification provides for making this
information available.
Accordingly,
[Definition:] we refer below to an item isomorphic to a component, meaning an information item whose type is equivalent to the component's, 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.
In the post-schema-validation infoset a
[schema information] property is added
to the element information item at which
assessment began. Its value
is a set 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, and one for
absent if any schema
component in the schema had no
{target namespace}. Each
namespace schema information information item has the
following properties and values:
-
[schema namespace]
-
a namespace
URI or absent
-
[schema components]
-
a (possibly
empty) list of schema component information items, each one an item 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 [schema namespace] 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 the
components of the schema which was used during
assessment. Lightweight processors are free to leave it empty, but if it
is provided, it must contain at a minimum all the top-level (i.e. named) components which actually figured in the
assessment, either directly or (because an anonymous component which figured is contained within) indirectly.
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 absent in the case of declarations within attribute group definitions: their scope will be determined when they are used in the construction of complex type definitions.
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 {type definition}.
{value constraint} reproduces the functions of XML 1.0 default and #FIXED
attribute values. default specifies that the attribute is to appear unconditionally in
the post-schema-validation infoset, with the supplied value used
whenever the attribute is not actually present; fixed indicates that the attribute value if present must match the supplied
constraint string, and if absent receives the supplied value as for default.
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 {value constraint} is provided in
conjunction with other aspects of complex type validation (see Element Locally Valid (Complex Type) (§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 Rule: Attribute Locally Valid
An attribute information item is locally
valid with respect to an
attribute declaration if
Schema Information Set Contribution: Validation Failure (Attribute)
If the local
validity, as defined by
Attribute Locally Valid (§3.2)
above, of an attribute information item has been assessed,
in the post-schema-validation infoset the item has a
list-valued
[schema error code]
property. If the item is not
valid, applications wishing to provide
information as to the reason(s) for this are encouraged to record one or more
error codes (see
Outcome Tabulations (normative) (§C) therein.
Schema Information Set Contribution: Attribute Declaration
If an attribute information item is
valid with respect to an attribute
declaration as per
Attribute Locally Valid (§3.2) then in the post-schema-validation infoset the element
information item has, optionally
Schema Information Set Contribution: Attribute Validated by Type
Validation Rule: Schema-Validity Assessment (Attribute)
The schema-validity assessment of an attribute information item depends
on its
validation alone.
An attribute information item's schema-validity has been assessed if
| 1 |
[Definition:] If the above holds, the attribute information item has been strictly assessed.
|
Schema Information Set Contribution: Assessment Outcome (Attribute)
If the schema-validity of an element information item has been assessed
as per
Schema-Validity Assessment (Attribute) (§3.2), then in the post-schema-validation infoset it has properties as follows:
-
[validation context]
- the nearest ancestor element information item with a [schema
information] property.
-
[validity]
-
-
[validation attempted]
-
3.3 Element Declaration Details
Element declarations provide for:
- Establishing the local validity of element information items.
- Determining schema information set contributions, such as
normalized and/or 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 declarations within named model groups: their scope will be determined when they are used in the construction of complex type definitions.
A non-absent value of the {target namespace} property provides for validation of
namespace-qualified element information items. Absent values of
{target namespace} validate unqualified items.
An element information item is valid
if it satisfies the {type definition}. For such an
item, schema information set contributions appropriate to the {type definition} are added to the
corresponding element information item in the post-schema-validation infoset.
If {nullable} is true, then an element may
also be 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 Locally Valid (Element) (§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 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
substitution group headed by the declared element.
If {disallowed substitutions} is empty, then all derived types and substitution group members are allowed.
Element declarations for which {abstract} is true can appear in
content models only when substitution is allowed;
such declarations may not themselves ever be used to validate element content.
See 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 Rule: Element Locally Valid (Element)
Schema Information Set Contribution: Validation Failure (Element)
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 Locally Valid (Particle) (§3.8).
Schema Information Set Contribution: Element Declaration
Schema Information Set Contribution: Element Default Value
Validation Rule: Element Locally Valid (Type)
An element information item is locally
valid with respect to a type definition if
| 1.1 |
The type definition is non-absent;
|
| 1.2 |
If the type definition is a simple type
definition, then
| 1.2.1.1 | The element information item's [attributes] must be empty,
excepting those whose [namespace URI] is identical to http://www.w3.org/2000/10/XMLSchema-instance and whose [local name] is one of type, null, schemaLocation or noNamespaceSchemaLocation; |
| 1.2.1.2 |
The element information item must have no element information item [children];
|
| 1.2.1.3 |
the normalized value must be valid with respect to the type definition as defined by String Valid (§3.13)
|
otherwise (the type definition is a complex type definition)
|
Schema Information Set Contribution: Element Validated by Type
If an element information item is
valid with respect to a
type definition
as per
Element Locally Valid (Type) (§3.3), in the post-schema-validation infoset the item has
and either
or
| 1.3.1 |
four properties as follows:
-
[type definition type]
-
simple or complex, depending on the type definition
-
[type definition namespace]
-
the {target namespace} of the type definition
-
[type definition anonymous]
-
true if the {name} of the type definition is absent, otherwise false
-
[type definition name]
-
the {name} of the type definition, if it is not absent. If it is
absent, schema processors may, but need not,
provide a value unique to the definition.
|
| 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 normalized value 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 definition.
|
The first alternative above is provided for applications such as query
processors which need access to the full range of details about an item's
assessment, 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.
Note that if an element is
laxly assessed, the information described above under 1.2.1 or 1.3.1 above is provided with
respect to the
ur-type definition.
Validation Rule: Schema-Validity Assessment (Element)
The schema-validity assessment of an element information item depends
on its
validation and the
assessment of its element information item
children and associated attribute information items, if any.
During
validation, associations
between element and attribute information items among the
[children]
and
[attributes] on the one hand, and element and attribute
declarations on the other, are established as a side-effect.
[Definition:] We call such
declarations context-dependent declarations.
So an element information item's schema-validity has been assessed if
and
Schema Information Set Contribution: Assessment Outcome (Element)
If the schema-validity of an element information item has been assessed
as per
Schema-Validity Assessment (Element) (§3.3), then in the post-schema-validation infoset it has properties as follows:
-
[validation context]
- the nearest ancestor element information item with a [schema
information] property (or this element item itself if it has such a property).
-
[validity]
-
| 1 |
If it was strictly assessed, then if
then valid, otherwise invalid.
|
| 2 |
otherwise notKnown
|
-
[validation attempted]
-
| 1 |
If it was strictly assessed and neither its [children] nor its
[attributes] contains an information item (element or attribute
respectively) whose [validation attempted] is not
full, then full
|
| 2 |
If it was not strictly assessed and neither its [children] nor its
[attributes] contains an information item (element or attribute
respectively) whose [validation attempted] is not
none, then none
|
| 3 |
otherwise partial
|
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 infoset 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 infoset 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 use pairs} 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 validation of the
[attributes]
of element information items, where the boolean determines whether the
attribute is required or not. See Element Locally Valid (Complex Type) (§3.4)
and Attribute Locally 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 use pairs}.
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 Locally Valid (Complex Type) (§3.4) and Wildcard allows Namespace URI (§3.9) for formal
details of attribute wildcard validation.
{content type} determines the validation of [children] of element information items. Informally:
{prohibited substitutions} determine
whether an element declaration appearing in a
content model is prevented from additionally
validating element items with an xsi:type (§2.6.1) attribute that
identifies an extension or restriction, or element items in
a substitution group whose type definition is similarly derived:
If {prohibited substitutions} is empty,
then all such substitutions are allowed, otherwise, the derivation method(s) it
names are disallowed.
See Element Locally Valid (Complex Type) (§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 Rule: Element Locally Valid (Complex Type)
An element information item is locally
valid with respect to a complex type definition if:
| 1.1 |
{abstract} is false;
|
| 1.2 |
|
| 1.3 |
For each attribute information item in the element information
item's [attributes] excepting those whose [namespace URI] is identical to http://www.w3.org/2000/10/XMLSchema-instance and whose [local name] is one of type, null, schemaLocation or noNamespaceSchemaLocation,
either
or
|
| 1.4 |
The attribute declaration of each attribute use pair in the {attribute use pairs} whose
boolean is true matches one of the attribute information items in the element information item's [attributes] as per clause 3 above.
|
Schema Information Set Contribution: Attribute Default Value
Schema Information Set Contribution: Validation Failure (Complex Type)
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:
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 particles contained directly or indirectly in the {particles} of a model group have identical
element declarations as their
{term}, the type definitions of those declarations must be the
same. By 'indirectly' is meant particles within the {particles}
of a group which is itself the {term} of a directly contained
particle, and so on recursively.
See Annotation Details (§3.12) for the significance of the {annotation} property.
Validation Rule: 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
locally
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
valid
with respect to such a group whose
{compositor} is
choice, the empty sequence
is 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 Locally 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 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 Rule: Element Sequence Locally Valid (Particle)
A sequence (possibly empty) of element information items is
locally
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
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 assessment
of the information items allowed by wildcards, as follows:
-
strict
-
There must be a global declaration for the item available, or it
must have an
xsi:type, and it
must be valid as appropriate.
-
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 valid with respect to
that definition, that is, validate where you can, don't worry when you can't.
Validation Rule: Item Valid (Wildcard)
Validation Rule: Wildcard allows Namespace URI
A value which is either a namespace URI or
absent is
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.
|
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. 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:
-
Functioning as a part of an identity-constraint is in addition to, not instead of,
having a type;
- Not just attribute values, but also element content and combinations
of values and content can be declared to be unique;
- Identity-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 Rule: Identity-constraint Satisfied
An element information item is locally
valid with respect to an 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:
Although this specification defines a post-schema-validation infoset
contribution which would enable schema-aware processors to implement clause
2.2.4 above (Element Declaration (§3.3)), processors are not required to
provide it. This clause can be read as if in the absence of this infoset contribution, the
value of the relevant {nullable} property must be available.
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-4] 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 an
[identity-constraint table] property whose value has 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 identity-constraints, in the post-schema-validation infoset that element information item has an
[identity-constraint table] property, containing one
Identity-constraint Binding
information item for each
eligible identity-constraint, with
properties as follows
-
[definition]
-
the eligible identity-constraint
-
[node table]
-
a node table with one entry for every
key-sequence (call it k) and node (call it n) such that
| |
| 1 |
There is a entry in one of the node
tables associated with the [definition] in an
Identity-constraint Binding
information item in at least one of the [identity-constraint
tables] of the element information item [children] of the element
information item whose key-sequence is k and whose node is n;
|
or
|
provided no two entries have the same key-sequence but distinct nodes. Potential conflicts are resolved by not including any conflicting entries which would have owed their inclusion to clause 1.1 above. Note that if all the conflicting entries arose under clause 1.1 above, this means no entry at all will appear for the offending key-sequence.
NOTE:
The complexity of the above arises from the fact that
keyref identity-constraints may be defined on domains distinct from the
embedded domain of the identity-constraint they reference, or the domains may be the
same but self-embedding at some depth. In either case the node
table for the referenced identity-constraint needs to propagate upwards, with
conflict resolution.
The Identity-constraint Binding
information item, 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 them via
[identity-constraint table] properties 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 infoset items 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.11 Notation Declaration Details
The notation declaration schema component has the following
properties:
Notation declarations do not participate in validation as such.
They are referenced in the course of validating strings as members of
the NOTATION simple type, in
which case the following constraint applies.
Schema Information Set Contribution: Validated with Notation
Whenever an attribute information item is
valid with respect to a
NOTATION, in the post-schema-validation infoset its parent element information item has either
or
See XML Representation of Notation Declaration Schema Components (§4.3.9) for the XML representation of
notation declarations and Notation Declaration Constraints (§5.8) for constraints on
notation declaration 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 item type for a list simple type. In this case the {facets}
apply to the list itself, and are restricted to those appropriate for lists.
A union simple type definition validates strings which satisfy at
least one of its {member type definitions}. As in the case of
list, the {facets}
apply to the union itself, and are restricted to those appropriate for unions.
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
Schema for Schemas (normative) (§A).
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 Rule: 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.
4 XML Representation of Schemas and Schema Components
The principal purpose of XML Schema: Structures is to define a set of
schema components that constrain the contents of instances and augment the
information sets thereof. Although no external representation
of schemas is required for this purpose, such representations will
obviously be widely used. To provide for this in an appropriate and
interoperable way, we specify a normative XML representation for schemas which
makes provision for every kind of schema
component. [Definition:] A document in
this form (i.e. a schema element information item) is a schema document. For the schema document as a whole, and
its constituents, the sections below define correspondences between element
information items (with declarations in
Schema for Schemas (normative) (§A) and DTD for Schemas (non-normative) (§F)) and
schema components. All the element information items in the XML representation
of a schema are in the XML Schema namespace, that is their [namespace URI] is http://www.w3.org/2000/10/XMLSchema. Although a common way of creating schema documents will be using an XML parser, this is not required: any mechanism which constructs conformant infosets as defined in [XML-Infoset] is a possible starting point.
When we say below that a numeric-valued property of a schema component
corresponds to the normalized value of some attribute information item, the number in
question is understood to be the base 10 interpretation of that normalized value.
Two aspects of the type definitions for the elements presented in the
following sections are constant across them all:
-
All of them allow attributes qualified with namespace URIs other than
the XML Schema namespace itself: these correspond to nothing in corresponding
schema component;
-
All of them allow an annotation as their first child, for human-readable documentation and/or machine-targetted information.
4.1 XML Representations of Schemas
A schema is represented in XML by one or more schema documents. A schema document contains representations for a collection of schema components, e.g. type definitions and element declarations, which have a common {target namespace}. A schema document which has one or more import element information items corresponds to a schema with components with more than one {target namespace}, see Import Constraints and Semantics (§6.2.3).
XML Representation Summary:
schema Element Information Item |
|
<schema
attributeFormDefault = (qualified | unqualified) : unqualified
blockDefault =
(#all | List of (substitution | extension | restriction))
elementFormDefault = (qualified | unqualified) : unqualified
finalDefault =
(#all | List of (extension | restriction))
id = ID
targetNamespace = uriReference
version = string
{any attributes with non-schema namespace . . .}>
Content: ((include | import | redefine | annotation)* , ((attribute | attributeGroup | complexType | element | group | notation | simpleType) , annotation*)*)
</schema>
|
| Schema Schema Component |
| Property | Representation |
| {type definitions} | The simple and complex type definitions
corresponding to all the simpleType and complexType element information items in the
[children], if any, plus any included or imported definitions, see Assembling a schema for a single target namespace from multiple schema definition documents (§6.2.1) and References to schema components across namespaces (§6.2.3). |
| {attribute declarations} | The (global) attribute declarations
corresponding to all the attribute element information items in the
[children], if any, plus any included or imported declarations, see Assembling a schema for a single target namespace from multiple schema definition documents (§6.2.1) and References to schema components across namespaces (§6.2.3). |
| {element declarations} | The (global) element declarations
corresponding to all the element element information items in the
[children], if any, plus any included or imported declarations, see Assembling a schema for a single target namespace from multiple schema definition documents (§6.2.1) and References to schema components across namespaces (§6.2.3). |
| {attribute group definitions} | The attribute group definitions
corresponding to all the attributeGroup element information items in the
[children], if any, plus any included or imported definitions, see Assembling a schema for a single target namespace from multiple schema definition documents (§6.2.1) and References to schema components across namespaces (§6.2.3). |
| {model group definitions} | The model group definitions
corresponding to all the group element information items in the
[children], if any, plus any included or imported definitions, see Assembling a schema for a single target namespace from multiple schema definition documents (§6.2.1) and References to schema components across namespaces (§6.2.3). |
| {notation declarations} | The notation declarations
corresponding to all the notation element information items in the
[children], if any, plus any included or imported declarations, see Assembling a schema for a single target namespace from multiple schema definition documents (§6.2.1) and References to schema components across namespaces (§6.2.3). |
| {annotations} | The annotations
corresponding to all the annotation element information items in the
[children], if any. |
|
|
Note that none of the attribute information items displayed above
correspond directly to properties of schemas. The blockDefault,
finalDefault, attributeFormDefault, elementFormDefaultand targetNamespace attributes are appealed to in the sub-sections below, as they provide
global information applicable to many representation/component correspondences. The
other attributes (id and version) are for user
convenience, and this specification defines no semantics for them.
Ed. Note: Priority Feedback Request
A number of the attributes (listed above) on the <schema> element
provide defaults for attributes on subordinate elements. This allows setting
values for attributes we judge likely to have the same value across a whole
schema document in only one place. It does constitute a kind of minimisation,
and does not provide any new semantics. The Working Group solicits feedback
both on whether this aspect of the design is a good thing or not, and on the
particular values chosen as the defaults for these default-setting attributes
themselves.
The definition of the schema abstract data model in XML Schema Abstract Data Model (§2.2) makes clear that most components have a {target namespace}. Most components corresponding to representations within a given schema element information item will have a {target namespace} which corresponds to the targetNamespace attribute.
Since the empty string is a legal (relative) URI reference, supplying
an empty string for targetNamespace is not the same
as not specifying it at all. The appropriate form of schema document
corresponding to a schema whose components have no
{target namespace} is one which has no
targetNamespace attribute specified at all.
NOTE: The XML namespaces Recommendation discusses only instance document syntax for
elements and attributes; it therefore provides no direct framework for managing
the names of type definitions, attribute group definitions, and so on. Nevertheless, we apply the target namespace facility uniformly to all
schema components, i.e. not only declarations but also definitions have a {target namespace}.
| Example |
<xs:schema
xmlns:xs="http://www.w3.org/2000/10/XMLSchema"
targetNamespace="http://purl.org/metadata/dublin_core"
version="M.n">
...
</xs:schema>
|
|
| A modest beginning to a schema. |
|
Although the schema above might be a complete XML document, schema
need not be the document element, but can appear within other documents.
Indeed there is no requirement that a schema correspond to a (text) document
at all: it could correspond to an element information item constructed 'by
hand', for instance via a DOM-conformant API.
Aside from include and import, which do not correspond directly to any schema component at all, each of the element information
items which may appear in the content of schema corresponds to
a schema component, and all except annotation are named. The
sub-sections of XML Representation of Schema Components (§4.3)
present each such item in turn, setting out the
components to which it may correspond.
4.2 References to Schema Components
Reference to
schema components from a schema document is managed in a uniform way,
whether the component corresponds to an element information item from the same schema document or is imported
(References to schema components across namespaces (§6.2.3)) from an external schema (which may,
but need not, correspond to an actual schema document). The form
of all such references is a
QName.
[Definition:] A QName is a name
with an optional namespace qualification, as defined in [XML-Namespaces]. When used in connection with the XML
representation of schema components in this specification, this refers to the
simple type QName as defined in [XML Schemas: Datatypes].
[Definition:] An NCName is a name
with no colon, as defined in [XML-Namespaces]. When used in connection with the XML
representation of schema components in this specification, this refers to the
simple type NCName as defined in [XML Schemas: Datatypes].
In each of the XML
representation expositions in the following sections, an attribute is shown as
having type QName if and only if it is
interpreted as referencing a schema component.
| Example |
<xs:schema xmlns:xs="http://www.w3.org/2000/10/XMLSchema"
xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns="http://www.example.com"
targetNamespace="http://www.example.com">
. . .
<xs:element name="elem1" type="Address"/>
<xs:element name="elem2" type="xhtml:blockquote"/>
<xs:attribute name="attr1"
type="xsl:quantity"/>
. . .
</xs:schema>
|
|
| The first of these is most probably a local reference, i.e. a reference
to a type
definition corresponding to a complexType element information item
located elsewhere in the schema document, the other two refer to type
definitions from schemas for other namespaces and assume that their namespaces
have been declared for import. See References to schema components across namespaces (§6.2.3) for a discussion of importing. |
|
Schema Representation Constraint: QName Interpretation
Whenever the word "resolve" in any form is used in this
chapter in connection with a QName in a
schema document, the
following definition should be understood as obtaining:
Schema Representation Constraint: QName resolution (Schema Document)
A string known to be a
QName
resolves to a schema component of a specified kind if:
| 1.1 |
that component is a member of the value of the appropriate
property of the schema which corresponds to the schema
document within which the QName
appears, that is
|
| 1.2 |
its {local name} matches the local
name of the string;
|
| 1.3 |
its {target namespace} is identical to the namespace URI of the string;
|
| 1.4 |
its namespace URI is either the target
namespace of the schema document containing the QName or that schema document contains an import element information item the normalized value of whose namespace [attribute] is identical to that namespace URI.
|
4.2.1 References to Schema Components from Elsewhere
The names of schema components such as type definitions and element
declarations are not of type ID: they are not
unique within a schema, just within a symbol space. This means that simple
fragment identifiers will not always work to reference schema components from outside
the context of schema documents.
There is currently no provision in the definition of the interpretation
of fragment identifiers for the text/xml MIME type, which is the
MIME type for schemas, for referencing
schema components as such. However, we observe that
[XPointer] provides a mechanism which maps well onto our
notion of symbol spaces as it is reflected in the XML representation of schema components. A fragment identifier of the form
#xpointer(xs:schema/xs:element[@name="person"]) will uniquely identify
the representation of a global element declaration with name person, and similar fragment
identifiers can obviously be constructed for the other global symbol spaces.
Short-form fragment identifiers may also be used in some cases, that is
when a DTD or XML Schema is available for the schema in question, and the
provision of an id attribute for the representations of all primary and secondary schema
components, which is of type
ID, has been exploited.
It is a matter for applications to specify whether they interpret
document-level references of either of the above varieties as being to the relevant element information item (i.e. without
special recognition of the relation of schema documents to schema components) or as being to the
corresponding schema component.
4.3 XML Representation of Schema Components
For each kind of schema component there is a corresponding normative XML representation.
The sections below describe the correspondences between the properties of each kind of
schema component on the one hand and the properties of information items in
that XML representation on the other, together
with constraints on that representation above and beyond those implicit in the
Schema for Schemas (normative) (§A) and DTD for Schemas (non-normative) (§F).
The language used is as if the correspondences were mappings from XML representation to
schema component, but the mapping in the other direction, and therefore the
correspondence in the abstract, can always be
constructed therefrom.
4.3.1 XML Representation of Attribute Declaration Schema Components
The XML representation for an attribute declaration schema component is an
attribute element information item. It specifies a simple type
definition for an attribute either by reference or explicitly, and may provide default information. The correspondences between the
properties of the information item and
properties of the component are as follows:
XML Representation Summary:
attribute Element Information Item |
|
<attribute
form = (qualified | unqualified)
id = ID
name = NCName
ref = QName
type = QName
use = (prohibited | optional | required | default | fixed) : optional
value = string
{any attributes with non-schema namespace . . .}>
Content: (annotation? , (simpleType?))
</attribute>
|
|
If the attribute element information item has schema as its parent, the corresponding schema component is as follows:
|
| Attribute Declaration Schema Component |
| Property | Representation |
| {name} | The normalized value of the name [attribute] |
| {target namespace} | The normalized value of the
targetNamespace [attribute] of the parent schema
element information item, or absent if there is none. |
| {type definition} | The simple type definition
corresponding to the simpleType element information item in the
[children], if present, otherwise the simple type definition resolved to by
the normalized value of the type [attribute], if present, otherwise the
simple ur-type definition. |
| {scope} | global |
| {value constraint} | If there is no value
[attribute], then absent, otherwise a pair consisting of the normalized value (with respect to the
{type definition}) of that [attribute] and
fixed, if the normalized value of the use [attribute] is
fixed, otherwise default. |
| {annotation} | The annotation corresponding to the annotation element information item in the
[children], if present, otherwise absent. |
|
|
|
otherwise if the attribute element information item has
complexType or attributeGroup as an ancestor
and the ref [attribute] is absent, it corresponds to an
attribute use pair of a boolean and an attribute declaration (unless use='prohibited', in which case the item
corresponds to nothing at all).
|
|
The boolean is true if the use
[attribute] is present with normalized value required, otherwise
false. The attribute declaration is as follows:
|
| Attribute Declaration Schema Component |
| Property | Representation |
| {name} | The normalized value of the name [attribute] |
| {target namespace} | If form is present and its
normalized value is qualified, or if form is absent and the
normalized value of attributeFormDefault on the schema
ancestor is qualified, then the normalized value of the
targetNamespace [attribute] of the parent schema
element information item, or absent if there
is none, otherwise absent. |
| {type definition} | The simple type definition
corresponding to the simpleType element information item in the
[children], if present, otherwise the simple type definition resolved to by
the normalized value of the type [attribute], if present, otherwise the
simple ur-type definition. |
| {scope} | If the attribute element information item
has complexType as an ancestor, the complex definition
corresponding to that item, otherwise (the attribute element
information item is within a top-level attributeGroup definition), absent. |
| {value constraint} | If there is no value
[attribute], then absent, otherwise a pair consisting of the normalized value (with respect to the
{type definition}) of that [attribute] and
default, if the normalized value of the use [attribute] is
default, otherwise fixed. |
| {annotation} | The annotation corresponding to the annotation element information item in the
[children], if present, otherwise absent. |
|
|
|
otherwise (the attribute element information item has
complexType or attributeGroup as an ancestor and the
ref [attribute] is present), it corresponds to an attribute use pair of a boolean and an attribute declaration (unless use='prohibited', in which case the item
corresponds to nothing at all).
|
|
The boolean is true if the use
[attribute] is present with normalized value required, otherwise
false. The attribute declaration is the (global) attribute declaration resolved to by the
normalized value of the ref [attribute].
|
Attribute declarations can appear at the top level of a schema document, or within complex
type definitions, either as complete (local) declarations, or by reference to top-level
declarations, or within attribute group definitions. For complete declarations, top-level or local, the type attribute is used when the declaration can use a
built-in or pre-declared simple type definition. Otherwise an
anonymous simpleType is provided inline.
The default when no simple type definition is referenced or
provided is the simple ur-type definition, which imposes no constraints at all.
Attribute items validated by a global declaration must be qualified with a
namespace URI. Control over whether attribute items validated by a local declaration must be namespace-qualified or not
is provided by the form [attribute], whose default is provided
by the attributeFormDefault [attribute] on the enclosing schema, via its determination of {target namespace}.
The names for top-level attribute declarations are in their own
symbol space. The names of locally-scoped
attribute declarations with no {target namespace} reside in symbol spaces local to the type definition which contains
them.
| Example |
<xs:attribute name="myAttribute"/>
<xs:attribute name="yetAnotherAttribute" type="xs:integer" use="required"/>
<xs:attribute name="anotherAttribute" use="default" value="42">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minExclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="stillAnotherAttribute" type="xs:string" use="fixed" value="Hello world!"/>
|
|
Four attributes are declared: one with no explicit
constraints at all; two more each declared by reference to the
built-in simple datatype integer, one required to
be present in instances and one with a default and a subrange qualification; and a fourth with a fixed value. |
|
Schema Representation Constraint: Attribute Declaration Representation OK
In addition to the conditions imposed on
attribute element
information items by the DTD and schema for schemas, the following must also hold:
| 1.1 |
If the item's parent is schema, then
| 1.1.1 |
If value is present, use must be one of
default or fixed;
|
| 1.1.2 |
If value is absent, use must be absent
|
|
| 1.2 |
If the item's parent is not schema, then
| 1.2.1 |
One of ref or name must be present, but not both;
|
| 1.2.2 |
If ref is present, then all of
simpleType, form, type and value must be absent;
|
| 1.2.3 |
If value is present, use must be one of
default or fixed;
|
|
| 1.3 |
type and simpleType must not both be present;
|
| 1.4 |
The corresponding attribute declaration must satisfy the conditions set
out in Attribute Declaration Constraints (§5.1).
|
4.3.2 XML Representation of Element Declaration Schema Components
The XML representation for an element declaration schema component is an
element element information item. It specifies a type
definition for an element either by reference or explicitly, and may provide
occurrence and default information. The correspondences between the
properties of the information item and
properties of the component(s) it corresponds to are as follows:
XML Representation Summary:
element Element Information Item |
|
<element
abstract = boolean : false
block =
(#all | List of (substitution | extension | restriction))
default = string
final =
(#all | List of (extension | restriction))
fixed = string
form = (qualified | unqualified)
id = ID
maxOccurs =
(nonNegativeInteger | unbounded)
: 1
minOccurs = nonNegativeInteger : 1
name = NCName
nullable = boolean : false
ref = QName
substitutionGroup = QName
type = QName
{any attributes with non-schema namespace . . .}>
Content: (annotation? , ((simpleType | complexType)? , (key | keyref | unique)*))
</element>
|
|
If the element element information item has schema as its parent, the corresponding schema component is as follows:
|
| Element Declaration Schema Component |
| Property | Representation |
| {name} | The normalized value of the name [attribute] |
| {target namespace} | The normalized value of the
targetNamespace [attribute] of the parent schema
element information item, or absent if there is none. |
| {scope} | global |
| {type definition} | The type definition
corresponding to the simpleType or complexType element information item in the
[children], if either is present, otherwise the type definition resolved to by
the normalized value of the type [attribute], otherwise the {type definition} of the element declaration resolved to by the normalized value of the substitutionGroup [attribute], if present, otherwise the
ur-type definition. |
| {nullable} | The normalized value of the nullable
[attribute], if present, otherwise false. |
| {value constraint} | If there is a default or a fixed
[attribute], then a pair consisting of the normalized value (with respect to the
{type definition}, if it is a simple type definition, or the
{type definition}'s {content type}, if that is a
simple type definition, or else with respect to the simple ur type) of that [attribute] and
either default or fixed, as appropriate, otherwise absent. |
| {identity-constraint definitions} | A set consisting of the
identity-constraint-definitions corresponding to all the key, unique and keyref element information items in the
[children], if any, otherwise the empty set |
| {substitution group affiliation} | the element declaration resolved to by the
normalized value of the
substitutionGroup [attribute], if present, otherwise absent |
| {disallowed substitutions} | A set corresponding to the normalized normalized value of the
block [attribute], if present, otherwise on the normalized value of the
blockDefault [attribute] of the ancestor schema element
information item, if present, otherwise on the empty string, as follows:
-
the empty string
-
the empty set;
-
#all
-
{substitution, extension,
restriction};
-
otherwise
-
a set with members drawn from the set above, each being present or
absent depending on whether the string contains an equivalently named
space-delimited substring.
|
| {substitution group exclusions} | As for {disallowed substitutions} above, but using the
final [attribute] in place of the block
[attribute] and with the
relevant set being {extension, restriction} |
| {abstract} | The normalized value of the abstract
[attribute], if present, otherwise false |
| {annotation} | The annotation corresponding to the annotation element information item in the
[children], if present, otherwise absent |
|
|
|
otherwise if the element element information item has
complexType or group as an ancestor and the
ref [attribute] is absent, the corresponding schema components
are as follows (unless minOccurs=maxOccurs=0, in which case the item
corresponds to no component at all):
|
|
|
|
An element declaration as in the first case above, with the exception of its {target namespace} and {scope} properties, which are as below
|
|
|
|
otherwise (the element element information item has
complexType or group as an ancestor and the
ref [attribute] is present), the corresponding schema component is as
follows (unless minOccurs=maxOccurs=0, in which case the item
corresponds to no component at all):
|
|
|
element corresponds to an element declaration, and allows
the type definition of that declaration to be specified either by reference or
by explicit inclusion.
elements within schema produce
global element declarations; elements within group or complexType produce either particles which contain global element declarations (if there's a ref attribute) or local declarations (otherwise). For complete declarations, top-level or local, the type attribute is used when the declaration can use a
built-in or pre-declared type definition. Otherwise an
anonymous simpleType or complexType is provided inline.
Element items validated by a global declaration must be qualified with a
namespace URI. Control over whether element items validated by a local declaration must be namespace-qualified or not
is provided by the form [attribute], whose default is provided
by the elementFormDefault [attribute] on the enclosing schema, via its determination of {target namespace}.
Ed. Note: Priority Feedback Request
The provision of local element declarations is in part intended to
simplify mapping between programming language and database structures where
locally scoped name-type bindings are commonplace. It is a departure from XML
1.0 DTDs, in which the name-type binding for elements (but not for attributes)
is constant across a document. The Working Group solicits feedback
both on whether this aspect of the design is a good thing or not, and in
particular on whether it does in fact simplify mappings as intended.
As noted above the names for top-level element declarations are in a separate
symbol space from the symbol spaces for
the names of type definitions, so there can (but need
not be) a simple or complex type definition type with the same name as a
top-level element. As with attribute names, the names of locally-scoped
element declarations with no {target namespace} reside in symbol spaces local to the type definition which contains
them.
Note that the above allows for two levels of defaulting for unspecified
type definitions. An element with no referenced or included type definition will
correspond to an element declaration which has the same type definition as the
head of its substitution group if it identifies one, otherwise the ur-type definition. This has the important consequence that the minimum valid element declaration, that is, one with only a name attribute and no contents, is also the most general, validating any combination of text and element content and allowing any attributes.
See below at XML Representation of Identity-constraint Definition Schema Components (§4.3.8) for key, unique and keyref.
| Example |
&xs:element name="unconstrained"/>
<xs:element name="myelement" type="mySimpleType"/>
<xs:element name="et0" type="myComplexType"/>
<xs:element name="et1">
<xs:complexType>
<xs:sequence>
<xs:element ref="et0"/>
. . .
</xs:sequence>
<xs:attribute ...>. . .</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="et2">
<xs:complexType>
<xs:attribute ...>. . .</xs:attribute>
</xs:complexType>
</xs:element>
|
|
| The first example above declares an element whose type, by default, is the
ur-type definition. The next two examples declare elements by reference to a simple and a
complex type definition respectively. The last two use embedded anonymous complex
type definitions, the first of which in
turn refers to one of the top-level element declarations in its content model. |
<xs:element name="contextOne">
<xs:complexType>
<xs:sequence>
<xs:element name="myLocalelement" type="myFirstType"/>
<xs:element ref="globalelement"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="contextTwo">
<xs:complexType>
<xs:sequence>
<xs:element name="myLocalelement" type="mySecondType"/>
<xs:element ref="globalelement"/>
</xs:sequence>
</xs:complexType>
</xs:element>
|
|
Instances of myLocalelement within
contextOne will be constrained by myFirstType,
while those within contextTwo will be constrained by
mySecondType. |
|
NOTE:
The possibility that differing attribute declarations and/or content models
would apply to elements with the same name in different contexts is an
extension beyond the expressive power of a DTD in XML 1.0.
| Example |
<xs:complexType name="facet">
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:attribute name="value" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="facet" type="xs:facet" abstract="true"/>
<xs:element name="encoding" substitutionGroup="xs:facet">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:facet">
<xs:attribute name="value" type="xs:encodings"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="period" substitutionGroup="xs:facet">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:facet">
<xs:attribute name="value" type="xs:timeDuration"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="datatype">
<xs:sequence>
<xs:element ref="facet" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:NCName" use="optional"/>
. . .
</xs:complexType>
|
|
An example from the schema for datatypes from [XML Schemas: Datatypes]. The
facet type is defined
and the facet element is declared to use it. The facet element is abstract -- it's
only defined to stand as the head for a substitution group. Two further
elements are declared, each a member of the facet substitution group. Finally a type is defined which refers to facet, thereby
allowing either period or encoding (or
any other member of the group). |
|
Schema Representation Constraint: Element Declaration Representation OK
In addition to the conditions imposed on
element element
information items by the schema for schemas, the following must also hold:
| 1.1 |
default and fixed must not both be present;
|
| 1.2 |
minOccurs must be 0 if default
is present;
|
| 1.3 |
If the item's parent is not schema, then
| 1.3.1 |
One of ref or name must be present, but not both;
|
| 1.3.2 |
If ref is present, then all of complexType,
simpleType, key, keyref,
unique, nullable, default,
fixed, block and type must be absent,
i.e. only minOccurs, maxOccurs, id are
allowed in addition to ref, along with annotation;
|
|
| 1.4 |
type and either simpleType or complexType are mutually exclusive;
|
| 1.5 |
The corresponding particle and/or element declarations must satisfy the conditions set
out in Element Declaration Constraints (§5.2) and Particle Constraints (§5.10).
|
4.3.3 XML Representation of Complex Type Definition Schema Components
The XML representation for a complex type definition schema component is a
complexType element information item. It provides validation
information for the [attributes] and [children] of an element information
item in the form of attribute declarations and a content type.
The XML representation for complex type definitions with
a simple type definition {content type} is significantly different
from that of those with other {content type}s, and this
is reflected in the presentation below, which displays first the elements
involved in the first case, then those for the second. The property mapping is shown once for each case.
XML Representation Summary:
complexType Element Information Item |
|
<complexType
abstract = boolean : false
block =
(#all | List of (extension | restriction))
final =
(#all | List of (extension | restriction))
id = ID
mixed = boolean : false
name = NCName
{any attributes with non-schema namespace . . .}>
Content: (annotation? , (simpleContent | complexContent | ((group | all | choice | sequence)? , ((attribute | attributeGroup)* , anyAttribute?))))
</complexType>
|
|
Whichever alternative for the content of complexType is
chosen, the following property mappings obtain:
|
| Complex Type Definition Schema Component |
| Property | Representation |
| {name} | The normalized value of the name [attribute] if present, otherwise absent |
| {target namespace} | The normalized value of the
targetNamespace [attribute] of the schema ancestor
element information item if present, otherwise absent |
| {abstract} | The normalized value of the abstract
[attribute], if present, otherwise false |
| {prohibited substitutions} | A set corresponding to the normalized value of the
block [attribute], if present, otherwise on the normalized value of the
blockDefault [attribute] of the ancestor schema element
information item, if present, otherwise on the empty string, as follows:
-
the empty string
-
the empty set;
-
#all
-
{extension, restriction};
-
otherwise
-
a set with members drawn from the set above, each being present or
absent depending on whether the string contains an equivalently named
space-delimited substring.
NOTE:
Although the blockDefault [attribute] of schema may include the value substitution, this value is ignored in the determination of {prohibited substitutions} for type definitions (it is used in the determination of {disallowed substitutions} for element declarations)
|
| {final} | As for {prohibited substitutions} above, using the
final [attribute] in place of the block [attribute] |
| {annotations} | The annotations corresponding to the annotation element information item in the
[children], if present, in the simpleContent and
complexContent [children], if present, and in their restriction and extension [children], if present, otherwise absent |
|
|
|
When the simpleContent alternative is chosen, the following
elements are relevant, and the remaining property mappings are as below. Note that either
restriction or extension must be chosen as the
content of simpleContent.
|
|
<simpleContent
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation? , (restriction | extension))
</simpleContent>
|
|
<restriction
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation? , (simpleType? , (duration | encoding | enumeration | length | maxExclusive | maxInclusive | maxLength | minExclusive | minInclusive | minLength | pattern | period | precision | scale | whiteSpace)*)? , ((attribute | attributeGroup)* , anyAttribute?))
</restriction>
|
|
<extension
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation? , ((attribute | attributeGroup)* , anyAttribute?))
</extension>
|
|
<attributeGroup
id = ID
ref = QName
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</attributeGroup>
|
|
<anyAttribute
id = ID
namespace =
((##any | ##other) | List of
(uriReference | (##targetNamespace | ##local))
)
: ##any
processContents = (skip | lax | strict) : strict
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</anyAttribute>
|
|
|
|
When the complexContent alternative is chosen, the following
elements are relevant (as are the attributeGroup and anyAttribute elements, not repeated here), and the additional property mappings are as below. Note that either
restriction or extension must be chosen as the
content of complexContent, but their content models are
different in this case from the case above when they occur as children of
simpleContent.
|
|
The property mappings below are also used in the case where
the third alternative (neither simpleContent nor complexContent) is chosen. This case is understood as shorthand for complex content restricting the ur-type definition, and the details of the mappings should be modified as necessary.
|
|
<complexContent
id = ID
mixed = boolean
{any attributes with non-schema namespace . . .}>
Content: (annotation? , (restriction | extension))
</complexContent>
|
|
<restriction
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation? , (group | all | choice | sequence)? , ((attribute | attributeGroup)* , anyAttribute?))
</restriction>
|
|
<extension
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation? , ((group | all | choice | sequence)? , ((attribute | attributeGroup)* , anyAttribute?)))
</extension>
|
|
|
Schema Representation Constraint: Complex Type Definition Representation OK
In addition to the conditions imposed on
complexType element
information items by the schema for schemas, the following must also hold:
NOTE:
Aside from the simple coherence requirements enforced above, constraining
type definitions identified as restrictions to actually be
restrictions, that is, to validate a
subset of the items which are
validated by their base type definition, is enforced in Complex Type Definition Constraints (§5.11).
Careful consideration of the above concrete syntax reveals that
a type definition need consist of no more than a name, i.e. that
<complexType name="anyThing"/> is allowed. The result is
however not of much use, as it will have empty {content type} and no allowed attributes.
| Example |
<xs:complexType name="length1">
<xs:simpleContent>
<xs:extension base="xs:non-negative-integer">
<xs:attribute name="unit" type="xs:NMTOKEN"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="width" type="length1"/>
<width unit="cm">2.54</width>
<xs:complexType name="length2">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="size" type="xs:non-positive-integer"/>
<xs:element name="unit" type="xs:NMTOKEN"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="depth" type="length2"/>
<depth>
<size>2.54</size><unit>cm</unit>
</depth>
<xs:complexType name="length3">
<xs:sequence>
<xs:element name="size" type="xs:non-positive-integer"/>
<xs:element name="unit" type="xs:NMTOKEN"/>
</xs:sequence>
</xs:complexType>
|
|
Three approaches to defining a type for length: one with
character data content constrained by reference to
a built-in datatype, and one attribute, the other two using two
elements. length3 is the abbreviated alternative to
length2: they correspond to identical type definition components.
|
|
| Example |
<xs:complexType name="personName">
<xs:sequence>
<xs:element name="title" minOccurs="0"/>
<xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="surname"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="extendedName">
<xs:complexContent>
<xs:extension base="personName">
<xs:sequence>
<xs:element name="generation" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="addressee" type="extendedName"/>
<addressee>
<forename>Albert</forename>
<forename>Arnold</forename>
<surname>Gore</surname>
<generation>Jr</generation>
</addressee>
|
|
| A type definition for personal names, and a definition derived by
extension which adds a single element; an element declaration referencing the
derived definition, and a valid instance thereof. |
|
| Example |
<xs:complexType name="simpleName">
<xs:complexContent>
<xs:restriction base="personName">
<xs:sequence>
<xs:element name="title" maxOccurs="0"/>
<xs:element name="forename" minOccurs="1" maxOccurs="1"/>
<xs:element name="surname"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="who" type="simpleName"/>
<who>
<forename>Bill</forename>
<surname>Clinton</surname>
</who>
|
|
| A simplified type definition
derived from the base type from the previous example by restriction, eliminating one optional daughter and
fixing another to occur exactly once; an element declared by reference to it,
and a valid instance thereof. |
|
| Example |
<xs:complexType name="paraType" mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="emph"/>
<xs:element ref="strong"/>
</xs:choice>
<xs:attribute name="version" type="xs:decimal"/>
</xs:complexType>
|
|
A further illustration of the abbreviated form, with the
mixed attribute appearing on complexType itself. |
|
Ed. Note: Priority Feedback Request
The Working Group solicits feedback on whether the fixed order of
content model, then attribute declarations within restriction and extension is acceptable.
4.3.4 XML Representation of Attribute Group Definition Schema Components
The XML representation for an attribute group definition schema component is an
attributeGroup element information item. It provides for
naming a group of attribute declarations and an attribute wildcard for use by reference in the XML representation of
complex type definitions and other attribute group definitions. The correspondences between the
properties of the information item and
properties of the component it corresponds to are as follows:
| Example |
<xs:attributeGroup name="myAttrGroup">
<xs:attribute . . ./>
. . .
</xs:attributeGroup>
<xs:complexType name="myelement">
. . .
<xs:attributeGroup ref="myAttrGroup"/>
</xs:complexType>
|
|
| Define and refer to an attribute group. The effect is as if the attribute
declarations in the group were present in the type definition. |
|
The example above illustrates a pattern which
recurs in the XML representation of schemas: The same element, in this case attributeGroup, serves both to
define and to incorporate by reference. In the first case the
name attribute is required, in the second the ref
attribute is required, and the element must be empty. These two are mutually exclusive, and also conditioned
by context: the defining form, with a name, must occur at the top
level of a schema, whereas the referring form, with a ref, must
occur within a complex type definition or an attribute group definition.
Schema Representation Constraint: Attribute Group Definition Representation OK
In addition to the conditions imposed on
attributeGroup element
information items by the schema for schemas, the following must also hold:
| 1.1 |
The corresponding attribute group definition, if any, must satisfy the conditions set
out in Attribute Group Definition Constraints (§5.4).
|
| 1.2 |
If clause 2 in the correspondence specification in XML Representation of Complex Type Definition Schema Components (§4.3.3) for {attribute wildcard}, as referenced above, obtains, the intensional intersection must be expressible, as defined in Attribute Wildcard Intersection (§5.4).
|
| 1.3 |
Circular group reference is disallowed outside redefine. That is, unless this element information item's parent is redefine, then among the
[children], if any, there may not be at any depth a attributeGroup with ref [attribute] which resolves to the component corresponding to this attributeGroup, or to any other attribute group definition component which contains this component at any depth.
|
4.3.5 XML Representation of Model Group Definition Schema Components
The XML representation for a model group definition schema component is a
group element information item. It provides for
naming a model group for use by reference in the XML representation of
complex type definitions and model groups. The correspondences between the
properties of the information item and
properties of the component it corresponds to are as follows:
XML Representation Summary:
group Element Information Item |
|
<group
id = ID
maxOccurs =
(nonNegativeInteger | unbounded)
: 1
minOccurs = nonNegativeInteger : 1
name = NCName
ref = QName
{any attributes with non-schema namespace . . .}>
Content: (annotation? , (all | choice | sequence)?)
</group>
|
|
If there is a name [attribute] (in which case the
item will have schema or redefine as parent), then the item corresponds to
a model group definition component with properties as follows:
|
|
|
|
Otherwise, the item will have a ref [attribute],
in which case it corresponds to a particle component with properties as follows (unless minOccurs=maxOccurs=0, in which case the item
corresponds to no component at all):
|
|
|
Given the constraints on its appearance in content models, an all should only occur as the only item in the [children]: see Model Group Constraints (§5.7).
| Example |
<xs:group name="myModelGroup">
<xs:sequence>
<xs:element ref="someThing"/>
</xs:sequence>
</xs:group>
<xs:complexType name="trivial">
<xs:sequence>
<xs:group ref="myModelGroup"/>
</xs:sequence>
<xs:attribute .../>
</xs:complexType>
<xs:complexType name="moreSo">
<xs:choice>
<xs:element ref="anotherThing"/>
<xs:group ref="myModelGroup"/>
</xs:choice>
<xs:attribute .../>
</xs:complexType>
|
|
| A minimal model group is defined and used by reference, first as the whole
content model, then as one alternative in a choice. |
|
Schema Representation Constraint: Model Group Definition Representation OK
In addition to the conditions imposed on
group element
information items by the schema for schemas, the following must also hold:
| 1.1 |
The corresponding model group definition, if any, must satisfy the conditions set
out in Model Group Constraints (§5.7).
|
| 1.2 |
Circular group reference is disallowed outside redefine. That is, unless this element information item's parent is redefine, then within the all, choice and sequence among the [children], if any, there may not be at any depth a group with ref [attribute] which resolves to the component corresponding to this group, or to any other group definition component which contains this component at any depth.
|
4.3.6 XML Representation of Model Group Schema Components
The XML representation for a model group schema component is
either an
all, a choice or a sequence
element information item. The correspondences between the
properties of those information items and
properties of the component they correspond to are as follows:
Schema Representation Constraint: Model Group Representation OK
In addition to the conditions imposed on
all,
choice and
sequence element
information items by the schema for schemas, the following must also hold:
4.3.7 XML Representation of Wildcard Schema Components
The XML representation for a wildcard schema component is an
any or anyAttribute element information item. The correspondences between the
properties of an any information item and
properties of the components it corresponds to are as follows (see complexType and attributeGroup for the correspondences for anyAttribute):
XML Representation Summary:
any Element Information Item |
|
<any
id = ID
maxOccurs =
(nonNegativeInteger | unbounded)
: 1
minOccurs = nonNegativeInteger : 1
namespace =
((##any | ##other) | List of
(uriReference | (##targetNamespace | ##local))
)
: ##any
processContents = (skip | lax | strict) : strict
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</any>
|
|
A particle containing a wildcard, with properties as follows (unless minOccurs=maxOccurs=0, in which case the item
corresponds to no component at all):
|
|
|
| Wildcard Schema Component |
| Property | Representation |
| {namespace constraint} | Dependent on the normalized value of the
namespace [attribute]: if absent, then any, otherwise as follows:
-
##any
-
any
-
##other
-
a pair of not and the normalized value of the
targetNamespace [attribute] of the schema ancestor
element information item if present, otherwise absent
-
otherwise
-
a set whose members are namespace URIs corresponding to the
space-delimited substrings of the string, except
| 1 |
if one such
substring is ##targetNamespace, the corresponding member is the normalized value of the targetNamespace [attribute] of the schema ancestor
element information item if present, otherwise absent
|
| 2 |
if one such
substring is ##local, the corresponding member is absent
|
|
| {process contents} | One of lax, skip,
strict, corresponding to the normalized value of the
processContents [attribute], if present, otherwise strict |
| {annotation} | The annotation corresponding to the annotation element information item in the
[children], if present, otherwise absent |
|
|
Wildcards are subject to the same ambiguity constraints
(Unique Particle Attribution (§5.7)) as other
content model particles: If an instance element could match either an explicit
particle and a wildcard, or one of two wildcards, within the content model of a
type, that model is in error.
| Example |
<xs:any processContents="skip"/>
<xs:any namespace="##other" processContents="lax"/>
<xs:any namespace="http://www.w3.org/1999/XSL/Transform"/>
<xs:any namespace="##targetNamespace"/>
<xs:anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/>
|
|
| Concrete examples of the four basic types of wildcard, plus one attribute wildcard. |
|
Schema Representation Constraint: Wildcard Representation OK
In addition to the conditions imposed on
any element
information items by the schema for schemas, the following must also hold:
4.3.8 XML Representation of Identity-constraint Definition Schema Components
The XML representation for an identity-constraint definition schema component is
either a
key, a keyref or a unique
element information item. The correspondences between the
properties of those information items and
properties of the component they correspond to are as follows:
The XPathExprApprox simple type referenced above
is defined in Schema for Schemas (normative) (§A). It is a
permissive approximation to the syntax of XPath expressions as defined
in [XPath], and is not an accurate
reconstruction of that syntax. Its use by reference from other schema
documents is deprecated: In due course a schema for XPath
will be published which includes a simple type definition appropriate
for widespread use.
| Example |
<xs:element name="state">
<xs:complexType>
<xs:sequence>
<xs:element name="stateCode" type="twoLetterCode"/>
<xs:element name="vehicle">
<xs:complexType>
. . .
<xs:attribute name="regNo" type="xs:integer"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="root">
. . .
<xs:key name="regKey">
<xs:selector xpath=".//vehicle[@regNo]"/>
<xs:field xpath="@regNo"/>
<xs:field xpath="ancestor::state/stateCode"/>
<!-- scope needs to be involved -->
</xs:key>
</xs:element>
<xs:element name="person">
<xs:complexType>
<xs:sequence>
. . .
<xs:element name="car">
<xs:complexType>
. . .
<xs:attribute name="regRef" type="xs:integer"/>
<xs:attribute name="regState" type="twoLetterCode"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:keyref name="carRef" refer="regKey">
<xs:selector xpath=".//car[@regRef]"/>
<xs:field xpath="@regRef"/>
<xs:field xpath="@regState"/>
</xs:keyref>
</xs:element>
|
|
A state element is defined, which inter alia
contains a stateCode descendant and some vehicle
descendants. A vehicle in turn has a regNo attribute,
which is an integer. The combination of stateCode and
regNo is asserted to be a key for
vehicle within state. Furthermore, a person element has
inter-alia an empty car element, with regRef and
regState attributes, which are then asserted together to refer to
vehicles via the regKey constraint. |
|
Schema Representation Constraint: Identity-constraint Definition Representation OK
In addition to the conditions imposed on
key,
keyref and
unique element
information items by the schema for schemas, the following must also hold:
4.3.9 XML Representation of Notation Declaration Schema Components
The XML representation for a notation declaration schema component is
a
notation
element information item. The correspondences between the
properties of that information item and
properties of the component it corresponds to are as follows:
XML Representation Summary:
notation Element Information Item |
|
<notation
id = ID
name = NCName
public =
A public identifier, per ISO 8879
system = uriReference
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</notation>
|
|
|
| Example |
<xs:notation name="jpeg"
public="image/jpeg" system="viewer.exe" />
<xs:element name="picture">
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:binary">
<xs:attribute name="pictype" type="xs:NOTATION"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<picture pictype="jpeg">...</picture>
|
|
|
Schema Representation Constraint: Notation Definition Representation OK
In addition to the conditions imposed on
notation element
information items by the schema for schemas, the following must also hold:
4.3.10 XML Representation of Annotation Schema Components
Annotation of schemas and schema components, with material for human or
computer consumption, is provided for by allowing application information and
human information at the beginning of most major schema elements, and anywhere
at the top level of schemas. The XML representation for an annotation schema component is
an
annotation
element information item. The correspondences between the
properties of that information item and
properties of the component it corresponds to are as follows:
Schema Representation Constraint: Annotation Definition Representation OK
In addition to the conditions imposed on
annotation element
information items by the schema for schemas, the following must also hold:
4.3.11 (non-normative) XML Representation of Simple Type Definition Schema Components
NOTE:
This section reproduces a version of material from [XML Schemas: Datatypes], for local cross-reference purposes.
XML Representation Summary:
simpleType Element Information Item |
|
<simpleType
id = ID
name = NCName
{any attributes with non-schema namespace . . .}>
Content: (annotation? , ((list | restriction | union)))
</simpleType>
|
|
<restriction
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation? , (simpleType? , (duration | encoding | enumeration | length | maxExclusive | maxInclusive | maxLength | minExclusive | minInclusive | minLength | pattern | period | precision | scale | whiteSpace)*))
</restriction>
|
|
<list
id = ID
itemType = QName
{any attributes with non-schema namespace . . .}>
Content: (annotation? , (simpleType?))
</list>
|
|
<union
id = ID
memberTypes = List of QName
{any attributes with non-schema namespace . . .}>
Content: (annotation? , (simpleType*))
</union>
|
| Simple Type Definition Schema Component |
| Property | Representation |
| {name} | The normalized value of the name [attribute] if present, otherwise absent |
| {target namespace} | The normalized value of the
targetNamespace [attribute] of the schema ancestor
element information item if present, otherwise absent |
| {base type definition} | The type definition resolved to by the
normalized value of the base [attribute], if present, otherwise the
type definition corresponding to the simpleType among
the [children] of restriction, if present, otherwise (the
restriction alternative is not chosen), the simple ur-type definition. |
| {variety} | If there is a list among the
[children], then list, otherwise if there is a union among the
[children], then union, otherwise (there is a restriction among the
[children]), then the {variety} of the {base type definition} |
|
|
|
If the {variety} is atomic, the following
additional property mappings also apply:
|
|
|
|
If the {variety} is list, the following
additional property mappings also apply:
|
|
|
|
If the {variety} is union, the following
additional property mappings also apply:
|
|
|
Schema Representation Constraint: Simple Type Restriction (Facets)
A simple type definition (call it
R) restricts another simple type
definition (call it
B) with a
set of facets (call this
S) if:
[Definition:] If
clause 1.2 above holds, we say that the {facets} of R constitute a
constitute a restriction of the {facets} of
B with respect to S.
A Schema for Schemas (normative)
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" [
<!--
keep this schema XML1.0 DTD valid
-->
<!ATTLIST element xmlns:x CDATA #IMPLIED>
<!-- provide ID type information even for parsers which only read the
internal subset -->
<!ATTLIST schema id ID #IMPLIED>
<!ATTLIST complexType id ID #IMPLIED>
<!ATTLIST complexContent id ID #IMPLIED>
<!ATTLIST simpleContent id ID #IMPLIED>
<!ATTLIST extension id ID #IMPLIED>
<!ATTLIST element id ID #IMPLIED>
<!ATTLIST group id ID #IMPLIED>
<!ATTLIST all id ID #IMPLIED>
<!ATTLIST choice id ID #IMPLIED>
<!ATTLIST sequence id ID #IMPLIED>
<!ATTLIST any id ID #IMPLIED>
<!ATTLIST anyAttribute id ID #IMPLIED>
<!ATTLIST attribute id ID #IMPLIED>
<!ATTLIST attributeGroup id ID #IMPLIED>
<!ATTLIST unique id ID #IMPLIED>
<!ATTLIST key id ID #IMPLIED>
<!ATTLIST keyref id ID #IMPLIED>
<!ATTLIST selector id ID #IMPLIED>
<!ATTLIST field id ID #IMPLIED>
<!ATTLIST include id ID #IMPLIED>
<!ATTLIST import id ID #IMPLIED>
<!ATTLIST redefine id ID #IMPLIED>
<!ATTLIST notation id ID #IMPLIED>
]>
<schema targetNamespace="http://www.w3.org/2000/10/XMLSchema" blockDefault="#all" elementFormDefault="qualified" version="Id: XMLSchema.xsd,v 1.26 2000/10/23 08:58:09 ht Exp " xmlns="http://www.w3.org/2000/10/XMLSchema">
<annotation>
<documentation xml:lang="en" source="http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/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 xml:lang="en">
The simpleType element and all of its members are defined
in datatypes.xsd</documentation>
</annotation>
<include schemaLocation="datatypes.xsd"/>
<import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2000/10/xml.xsd">
<annotation>
<documentation xml:lang="en">
Get access to the xml: attribute groups for xml:lang
as declared on 'documentation' below
</documentation>
</annotation>
</import>
<complexType name="openAttrs">
<annotation>
<documentation xml:lang="en">
This type is extended by almost all schema types
to allow attributes from other namespaces to be
added to user schemas.
</documentation>
</annotation>
<complexContent>
<restriction base="anyType">
<anyAttribute namespace="##other" processContents="lax"/>
</restriction>
</complexContent>
</complexType>
<complexType name="annotated">
<annotation>
<documentation xml:lang="en">
This type is extended by all types which allow annotation
other than <schema> itself
</documentation>
</annotation>
<complexContent>
<extension base="openAttrs">
<sequence>
<element ref="annotation" minOccurs="0"/>
</sequence>
<attribute name="id" type="ID"/>
</extension>
</complexContent>
</complexType>
<element name="schemaTop" abstract="true" type="annotated">
<annotation>
<documentation xml:lang="en">
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 xml:lang="en">
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 xml:lang="en">
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 xml:lang="en" 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="token"/>
<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 xml:lang="en">
for maxOccurs</documentation></annotation>
<union memberTypes="nonNegativeInteger">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="unbounded"/>
</restriction>
</simpleType>
</union>
</simpleType>
<attributeGroup name="occurs">
<annotation><documentation xml:lang="en">
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 xml:lang="en">
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 xml:lang="en">
'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 xml:lang="en">
'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 xml:lang="en" 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 xml:lang="en">
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 xml:lang="en">
Will be restricted to required or forbidden</documentation>
</annotation>
</attribute>
<attribute name="mixed" type="boolean" use="default" value="false">
<annotation>
<documentation xml:lang="en">
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 xml:lang="en" 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 xml:lang="en">
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 xml:lang="en">
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 xml:lang="en" 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 xml:lang="en" source="http://www.w3.org/TR/xmlschema-1/#element-complexType"/>
</annotation>
</element>
<simpleType name="derivationControl">
<annotation>
<documentation xml:lang="en">
A utility type, not for public use</documentation>
</annotation>
<restriction base="NMTOKEN">
<enumeration value="substitution"/>
<enumeration value="extension"/>
<enumeration value="restriction"/>
</restriction>
</simpleType>
<simpleType name="reducedDerivationControl">
<annotation>
<documentation xml:lang="en">
A utility type, not for public use</documentation>
</annotation>
<restriction base="derivationControl">
<enumeration value="extension"/>
<enumeration value="restriction"/>
</restriction>
</simpleType>
<simpleType name="blockSet">
<annotation>
<documentation xml:lang="en">
#all or (possibly empty) subset of {substitution, extension,
restriction}</documentation>
<documentation xml:lang="en">
A utility type, not for public use</documentation>
</annotation>
<union>
<simpleType>
<restriction base="token">
<enumeration value="#all"/>
</restriction>
</simpleType>
<simpleType>
<list itemType="derivationControl"/>
</simpleType>
</union>
</simpleType>
<simpleType name="derivationSet">
<annotation>
<documentation xml:lang="en">
#all or (possibly empty) subset of {extension, restriction}</documentation>
<documentation xml:lang="en">
A utility type, not for public use</documentation>
</annotation>
<union>
<simpleType>
<restriction base="token">
<enumeration value="#all"/>
</restriction>
</simpleType>
<simpleType>
<list itemType="reducedDerivationControl"/>
</simpleType>
</union>
</simpleType>
<complexType name="element" abstract="true">
<annotation>
<documentation xml:lang="en">
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 xml:lang="en" source="http://www.w3.org/TR/xmlschema-1/#element-element"/>
</annotation>
</element>
<complexType name="group" abstract="true">
<annotation>
<documentation xml:lang="en">
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 xml:lang="en">
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 xml:lang="en" source="http://www.w3.org/TR/xmlschema-1/#element-all"/>
</annotation>
<complexType>
<annotation>
<documentation xml:lang="en">
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 xml:lang="en">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>
<attribute name="minOccurs" use="default" value="1">
<simpleType>
<restriction base="nonNegativeInteger">
<enumeration value="1"/>
</restriction>
</simpleType>
</attribute>
<attribute name="maxOccurs" use="default" value="1">
<simpleType>
<restriction base="allNNI">
<enumeration value="1"/>
</restriction>
</simpleType>
</attribute>
</restriction>
</complexContent>
</complexType>
</element>
<element name="choice" type="explicitGroup" id="choice">
<annotation>
<documentation xml:lang="en" source="http://www.w3.org/TR/xmlschema-1/#element-choice"/>
</annotation>
</element>
<element name="sequence" type="explicitGroup" id="sequence">
<annotation>
<documentation xml:lang="en" source="http://www.w3.org/TR/xmlschema-1/#element-sequence"/>
</annotation>
</element>
<element name="group" substitutionGroup="redefinable" type="namedGroup" id="group">
<annotation>
<documentation xml:lang="en" 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 xml:lang="en" 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 xml:lang="en">
simple type for the value of the 'namespace' attr of
'any' and 'anyAttribute'</documentation>
</annotation>
<annotation>
<documentation xml:lang="en">
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 xml:lang="en">
A utility type, not for public use</documentation>
</annotation>
<union>
<simpleType>
<restriction base="token">
<enumeration value="##any"/>
<enumeration value="##other"/>
</restriction>
</simpleType>
<simpleType>
<list>
<simpleType>
<union memberTypes="uriReference">
<simpleType>
<restriction base="token">
<enumeration value="##targetNamespace"/>
<enumeration value="##local"/>
</restriction>
</simpleType>
</union>
</simpleType>
</list>
</simpleType>
</union>
</simpleType>
<element name="attribute" substitutionGroup="schemaTop" type="topLevelAttribute" id="attribute">
<annotation>
<documentation xml:lang="en" 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 xml:lang="en" source="http://www.w3.org/TR/xmlschema-1/#element-attributeGroup"/>
</annotation>
</element>
<element name="include" id="include">
<annotation>
<documentation xml:lang="en" 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 xml:lang="en" 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 xml:lang="en" 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 xml:lang="en">
An XPath expression</documentation>
<documentation xml:lang="en">
A utility type, not for public use</documentation>
</annotation>
<restriction base="string">
<pattern value="(/|//|\.|\.\.|:|::|\||(\c-[.:/|])+)+">
<annotation>
<documentation xml:lang="en">
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 xml:lang="en" source="http://www.w3.org/TR/xmlschema-1/#element-selector"/>
</annotation>
</element>
<element name="field" id="field" type="XPathSpec">
<annotation>
<documentation xml:lang="en" 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 xml:lang="en" source="http://www.w3.org/TR/xmlschema-1/#element-identityConstraint"/>
</annotation>
</element>
<element name="unique" substitutionGroup="identityConstraint" id="unique">
<annotation>
<documentation xml:lang="en" source="http://www.w3.org/TR/xmlschema-1/#element-unique"/>
</annotation>
</element>
<element name="key" substitutionGroup="identityConstraint" id="key">
<annotation>
<documentation xml:lang="en" source="http://www.w3.org/TR/xmlschema-1/#element-key"/>
</annotation>
</element>
<element name="keyref" substitutionGroup="identityConstraint" id="keyref">
<annotation>
<documentation xml:lang="en" 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 xml:lang="en" 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 xml:lang="en">
A public identifier, per ISO 8879</documentation>
<documentation xml:lang="en">
A utility type, not for public use</documentation>
</annotation>
<restriction base="token"/>
</simpleType>
<element name="appinfo" id="appinfo">
<annotation>
<documentation xml:lang="en" source="http://www.w3.org/TR/xmlschema-1/#element-appinfo"/>
</annotation>
<complexType mixed="true">
<sequence minOccurs="0" maxOccurs="unbounded">
<any processContents="lax"/>
</sequence>
<attribute name="source" type="uriReference"/>
</complexType>
</element>
<element name="documentation" xmlns:x="http://www.w3.org/XML/1998/namespace" id="documentation">
<annotation>
<documentation xml:lang="en" source="http://www.w3.org/TR/xmlschema-1/#element-documentation"/>
</annotation>
<complexType mixed="true">
<sequence minOccurs="0" maxOccurs="unbounded">
<any processContents="lax"/>
</sequence>
<attribute name="source" type="uriReference"/>
<attribute ref="x:lang"/>
</complexType>
</element>
<element name="annotation" id="annotation">
<annotation>
<documentation xml:lang="en" source="http://www.w3.org/TR/xmlschema-1/#element-annotation"/>
</annotation>
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="appinfo"/>
<element ref="documentation"/>
</choice>
</complexType>
</element>
<annotation>
<documentation xml:lang="en">
notations for use within XML Schema schemas</documentation>
</annotation>
<notation name="XMLSchemaStructures" public="structures" system="http://www.w3.org/2000/08/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 xml:lang="en">
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.
B References (normative)
-
XML Schemas: Datatypes
-
XML Schema Part 2: Datatypes, Paul V. Biron and Ashok
Malhotra, eds. See http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/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
-
XML
- Extensible
Markup Language (XML) 1.0, Tim Bray, et al., eds., W3C, 10 February 1998. See
http://www.w3.org/TR/REC-xml
-
XML Base
-
XML Base, Jonathan Marsh,
ed., W3C, 8 September 2000. See http://www.w3.org/TR/xmlbase/
-
XML-Infoset
- XML Information Set (public WD),
John Cowan, ed., W3C, July 2000. 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
D Required Information Set Items and Properties (normative)
This specification requires as a precondition for assessment an information set as defined in [XML-Infoset] which supports at least the following information items and properties:
-
Attribute Information Item
-
[local name], [namespace URI],
[normalized value]
-
Character Information Item
-
[character code]
-
Element Information Item
-
[local name], [namespace URI],
[children], [attributes], [in-scope namespaces] or
[declared namespaces]
-
Namespace Declaration Information Item
-
[prefix], [children]
E Glossary (non-normative)
The listing below is for the benefit of readers of a printed version of this
document: it collects together all the definitions which appear in the
document above.
-
absent
- Throughout this specification, the
term absent is used as a distinguished value denoting absence.
-
actual member type definition
- that
member of the {member type definitions} which actually
validated the element item's normalized value the
actual member type definition
-
actual type definition
- We refer below to the
actual type definition. If the above three clauses obtain, this
should be understood as referring to the local type
definition, otherwise to the {type definition}.
-
assessment
- the work assessment is used to refer
to the whole rich process of
local validation, schema-validity assessment and infoset augmentation.
-
attribute use pair
-
attribute use pairs:
each is a pair of a boolean
and an individual Attribute Declaration (§2.2.2.3)
to be used for validation of the
[attributes]
of element information items, where the boolean determines whether the
attribute is required or not
-
base type definition
- A type definition used as the
basis for an extension or
restriction is known as
the base type definition of that definition.
-
component name
- Declarations and
definitions may have and be identified by names, which are NCNames as defined by [XML-Namespaces]
-
conformance to the XML Representation of Schemas
- 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.
-
constitute a restriction
- If
clause 1.2 above holds, we say that the {facets} of R constitute a
constitute a restriction of the {facets} of
B with respect to S.
-
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).
-
content model
- A particle can
be used in a complex type definition to constrain the validation
of the [children] of an element information item; such a particle is called
a content model
-
context-dependent declaration
- We call such
declarations context-dependent declarations.
-
declaration
-
declaration components are associated by
(qualified) name to information items being validated
-
definition
-
definition components define
internal schema components that can be used in other schema components.
-
element substitution group
- Through
the new mechanism of element substitution groups, XML Schemas provides a more powerful model supporting substitution of one named element for another.
-
eligible identity-constraint
- An eligible
identity-constraint of an element information item is one such that clauses 2.1.[1-2] or 2.2.[1-4] 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 an
[identity-constraint table] property whose value has an entry for that constraint
-
emptiable
- A particle is
emptiable if
-
explicit content
- let the explicit
content be empty if any of the sub-clauses of clause 1.1 above
applies, otherwise the particle corresponding to
the all, choice, group or
sequence among the [children].
-
explicit members
- Define the explicit members as follows:
-
extension
- 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.
-
final
-
final: no
further derivations are possible.
-
fully conforming
- 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).
-
head declaration
- call this declaration the substituting declaration
-
implicitly contains
- We say that a list
of particles implicitly contains an element declaration if a
member of the list contains that
element declaration in its substitution group
-
initial value
- 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
-
item isomorphic to a component
- we refer below to an item isomorphic to a component, meaning an information item whose type is equivalent to the component's, 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.
-
item type definition
- call this type definition the local type definition
-
key-sequence
- Call the sequence of the values (as defined in [XML Schemas: Datatypes]) of those node-sets in order the key-sequence of the node
-
laxly assessed
- an element information item's
schema validity may be laxly assessed if its context-dependent declaration is not skip by validating with respect to the ur-type definition as per Element Locally Valid (Type) (§3.3)
-
local name
-
local name consisting of the character information items after the colon, if any, otherwise all the character information items, in the normalized value
-
local type definition
- call this type definition the local type definition
-
minimally conforming
-
Minimally conforming processors must completely and
correctly implement the Constraints on
Schemas, Validity Rules,
and Schema Information
Set Contributions contained in this specification.
-
namespace URI
-
namespace URI, derived from its normalized value and the containing element information item's [in-scope namespaces] as follows:
-
NCName
- An NCName is a name
with no colon, as defined in [XML-Namespaces]. When used in connection with the XML
representation of schema components in this specification, this refers to the
simple type NCName as defined in [XML Schemas: Datatypes].
-
node table
- A node table is a set
of pairs each consisting of
a key-sequence and an element node
-
normalized value
- When we refer to the
normalized value of an element or
attribute information item, we mean an initial value whose white space, if any, has been
normalized according to the value of the whiteSpace facet of the
simple type definition used in its validation:
-
order-preserving
- A complete functional mapping is
order-preserving if each particle r in the domain R maps to a
particle b in the range B which follows (not necessarily
immediately) the particle in the range
B mapped to by the predecessor of r, if any, where
"predecessor" and "follows" are defined with respect
to the order of the lists which constitute R and B.
-
overlap
- We say that two non-group
particles overlap if
-
partition
- 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.
-
QName
- A QName is a name
with an optional namespace qualification, as defined in [XML-Namespaces]. When used in connection with the XML
representation of schema components in this specification, this refers to the
simple type QName as defined in [XML Schemas: Datatypes].
-
qualified node set
- 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
-
restriction
- 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.
-
schema component
- Schema component is the generic term for the building blocks that comprise the abstract data model of the schema.
-
schema document
- A document in
this form (i.e. a schema element information item) is a schema document
-
Schema Information Set Contribution
- Augmentations to post-schema-validation infosets
expressed by schema components, which follow
as a consequence of validation and/or assessment.
Largely to be
found in Schema Component Details (§3).
-
Schema Representation Constraint
- Constraints on the
representation of schema components in XML. Some but not all of these are expressed in DTD for Schemas (non-normative) (§F) and Schema for Schemas (normative) (§A). Largely to be
found in XML Representation of Schemas and Schema Components (§4).
-
strictly assessed
- If the above holds, the attribute information item has been strictly assessed.
-
strictly assessed
- If either of the above cases hold, the element information item has been strictly assessed.
-
substitution group
- Every element declaration
in the {element declarations} of a schema defines a
substitution group, a subset of those {element declarations}, as follows:
-
symbol space
-
symbol space to denote a
collection of names, each of which is unique with respect to the others.
-
target namespace
- Several kinds
of component have a target namespace, which is either
absent or a namespace URI, also as
defined by [XML-Namespaces]
-
target node set
- Call this the target node set
-
term
- A term is
something we use a lot
-
type definition
- This specification uses
the phrase type definition in cases where no distinction
need be made between simple and complex types.
-
Type Definition Hierarchy
- 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.
-
ur-type definition
- A distinguished ur-type
definition is present in each XML Schema, serving as the root of the type
definition hierarchy for that schema.
-
valid
- the
word valid and its derivatives are used to refer to
item 1 above, the determination of local
schema-validity.
-
valid extension
- A particle
(call it E, for extension) is a valid extension of
another particle (call it B, for base) if
-
valid extension
- If this
constraint holds of a complex type definition, we say it is a valid
extension of its {base type definition}.
-
Validition Rules
- Contributions to validation associated with schema components. Largely to be
found in Schema Component Details (§3).
-
valid restriction
- A particle
(call it R, for restriction) is a valid restriction of
another particle (call it B, for base) if
-
valid restriction
- If this
constraint holds of a complex type definition, we say it is a valid
restriction of its {base type definition}.
-
valid restriction
- If this
constraint holds of a simple type definition, we say it is a valid
restriction of its base type definition.
-
XML Schema
-
An XML Schema is a
set of schema components.
F DTD for Schemas (non-normative)
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.20 2000/10/23 08:58:08 ht Exp -->
<!-- With the exception of cases with multiple namespace
prefixes for the XML Schema namespace, any XML document which is
not valid per this DTD given redefinitions in its internal subset of the
'p' and 's' parameter entities below appropriate to its namespace
declaration of the XML Schema namespace is almost certainly not
a valid schema. -->
<!-- The simpleType element and its constituent parts
are defined in XML Schema: Part 2: Datatypes -->
<!ENTITY % xs-datatypes PUBLIC 'datatypes' 'datatypes.dtd' >
<!ENTITY % p ''> <!-- 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">
<!-- annotation elements -->
<!ENTITY % annotation "%p;annotation">
<!ENTITY % appinfo "%p;appinfo">
<!ENTITY % documentation "%p;documentation">
<!-- Customisation entities for the ATTLIST of each element type.
Define one of these if your schema takes advantage of the
anyAttribute='##other' in the schema for schemas -->
<!ENTITY % schemaAttrs ''>
<!ENTITY % complexTypeAttrs ''>
<!ENTITY % complexContentAttrs ''>
<!ENTITY % simpleContentAttrs ''>
<!ENTITY % extensionAttrs ''>
<!ENTITY % elementAttrs ''>
<!ENTITY % groupAttrs ''>
<!ENTITY % allAttrs ''>
<!ENTITY % choiceAttrs ''>
<!ENTITY % sequenceAttrs ''>
<!ENTITY % anyAttrs ''>
<!ENTITY % anyAttributeAttrs ''>
<!ENTITY % attributeAttrs ''>
<!ENTITY % attributeGroupAttrs ''>
<!ENTITY % uniqueAttrs ''>
<!ENTITY % keyAttrs ''>
<!ENTITY % keyrefAttrs ''>
<!ENTITY % selectorAttrs ''>
<!ENTITY % fieldAttrs ''>
<!ENTITY % includeAttrs ''>
<!ENTITY % importAttrs ''>
<!ENTITY % redefineAttrs ''>
<!ENTITY % notationAttrs ''>
<!ENTITY % 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
id ID #IMPLIED
%complexContentAttrs;>
<!-- restriction should use the branch defined above, not the simple
one from part2; extension should use the full model -->
<!ELEMENT %simpleContent; (%restriction;|%extension;)>
<!ATTLIST %simpleContent;
id ID #IMPLIED
%simpleContentAttrs;>
<!-- restriction should use the simple branch from part2, not the
one defined above; extension should have no particle -->
<!ELEMENT %extension; (%particleAndAttrs;)>
<!ATTLIST %extension;
base %QName; #REQUIRED
id ID #IMPLIED
%extensionAttrs;>
<!-- an element is declared by either:
a name and a type (either nested or referenced via the type attribute)
or a ref to an existing element declaration -->
<!ELEMENT %element; ((%annotation;)?, (%complexType;| %simpleType;)?,
(%unique; | %key; | %keyref;)*)>
<!-- simpleType or complexType only if no type|ref attribute -->
<!-- ref not allowed at top level -->
<!ATTLIST %element;
name %NCName; #IMPLIED
id ID #IMPLIED
ref %QName; #IMPLIED
type %QName; #IMPLIED
minOccurs %nonNegativeInteger; #IMPLIED
maxOccurs CDATA #IMPLIED
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 exclusive, one is required -->
<!-- In the absence of type AND ref, type defaults to type of
substitutionGroup, if any, else the ur-type, i.e. unconstrained -->
<!-- default and fixed are mutually exclusive -->
<!ELEMENT %group; ((%annotation;)?,(%mgs;)?)>
<!ATTLIST %group;
name %NCName; #IMPLIED
ref %QName; #IMPLIED
minOccurs %nonNegativeInteger; #IMPLIED
maxOccurs CDATA #IMPLIED
id ID #IMPLIED
%groupAttrs;>
<!ELEMENT %all; ((%annotation;)?, (%element;)*)>
<!ATTLIST %all;
minOccurs (1) #FIXED '1'
maxOccurs (1) #FIXED '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'
id ID #IMPLIED
%anyAttrs;>
<!-- namespace is interpreted as follows:
##any - - any non-conflicting WFXML at all
##other - - any non-conflicting WFXML from namespace other
than targetNamespace
##local - - any unqualified non-conflicting WFXML/attribute
one or - - any non-conflicting WFXML from
more URI the listed namespaces
references
##targetNamespace ##local may appear in the above list,
with the obvious meaning -->
<!ELEMENT %anyAttribute; (%annotation;)?>
<!ATTLIST %anyAttribute;
namespace CDATA '##any'
processContents (skip|lax|strict) 'strict'
id ID #IMPLIED
%anyAttributeAttrs;>
<!-- namespace is interpreted as for 'any' above -->
<!-- simpleType only if no type|ref attribute -->
<!-- ref not allowed at top level, name iff at top level -->
<!ELEMENT %attribute; ((%annotation;)?, (%simpleType;)?)>
<!ATTLIST %attribute;
name %NCName; #IMPLIED
id ID #IMPLIED
ref %QName; #IMPLIED
type %QName; #IMPLIED
use (prohibited|optional|required|fixed|default) #IMPLIED
value CDATA #IMPLIED
form %formValues; #IMPLIED
%attributeAttrs;>
<!-- type and ref are mutually exclusive.
name and ref are mutually exclusive, 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
refer %QName; #REQUIRED
id ID #IMPLIED
%keyrefAttrs;>
<!ELEMENT %selector; ((%annotation;)?)>
<!ATTLIST %selector;
xpath %XPathExpr; #REQUIRED
id ID #IMPLIED
%selectorAttrs;>
<!ELEMENT %field; ((%annotation;)?)>
<!ATTLIST %field;
xpath %XPathExpr; #REQUIRED
id ID #IMPLIED
%fieldAttrs;>
<!-- Schema combination mechanisms -->
<!ELEMENT %include; (%annotation;)?>
<!ATTLIST %include;
schemaLocation %URIref; #REQUIRED
id ID #IMPLIED
%includeAttrs;>
<!ELEMENT %import; (%annotation;)?>
<!ATTLIST %import;
namespace %URIref; #IMPLIED
schemaLocation %URIref; #IMPLIED
id ID #IMPLIED
%importAttrs;>
<!ELEMENT %redefine; (%annotation; | %simpleType; | %complexType; |
%attributeGroup; | %group;)*>
<!ATTLIST %redefine;
schemaLocation %URIref; #REQUIRED
id ID #IMPLIED
%redefineAttrs;>
<!ELEMENT %notation; (%annotation;)?>
<!ATTLIST %notation;
name %NCName; #REQUIRED
id ID #IMPLIED
public CDATA #REQUIRED
system %URIref; #IMPLIED
%notationAttrs;>
<!-- Annotation is either application information or documentation -->
<!-- By having these here they are available for datatypes as well
as all the structures elements -->
<!ELEMENT %annotation; (%appinfo; | %documentation;)*>
<!-- User must define annotation elements in internal subset for this
to work -->
<!ELEMENT %appinfo; ANY> <!-- too restrictive -->
<!ATTLIST %appinfo;
source %URIref; #IMPLIED
id ID #IMPLIED
%appinfoAttrs;>
<!ELEMENT %documentation; ANY> <!-- too restrictive -->
<!ATTLIST %documentation;
source %URIref; #IMPLIED
id ID #IMPLIED
xml:lang CDATA #IMPLIED
%documentationAttrs;>
<!NOTATION XMLSchemaStructures PUBLIC
'structures' 'http://www.w3.org/2000/10/XMLSchema.xsd' >
<!NOTATION XML PUBLIC
'REC-xml-1998-0210' 'http://www.w3.org/TR/1998/REC-xml-19980210' >
G Analysis of the Unique Particle Attribution constraint (non-normative)
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.
H References (non-normative)
-
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/CR-xmlschema-0-20001024/primer.html
-
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
???
-
XDR
- XML-Data
Reduced, Frankston, Charles, and Henry S. Thompson, ed. See
http://www.ltg.ed.ac.uk/~ht/XMLData-Reduced.htm
-
XML-Data
-
XML-Data, Andrew Layman, et al. W3C, 05 January 1998. See
http://www.w3.org/TR/1998/NOTE-XML-data-0105/
-
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
I 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, TIBCO Extensibility; Charles E. Campbell, Informix; Wayne Carr, Intel; Peter Chen, Bootstrap Alliance and LSU; David Cleary, Progress Software; Mike Cokus, MITRE; Dan Connolly, W3C (staff contact); Roger L. Costello, MITRE; Ugo Corda, Xerox; Haavard Danielson, 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, Contivo (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; Ashok Malhotra, IBM; Murray Maloney, Muzmo Communication, acting for Commerce One; John McCarthy, Lawrence Berkeley National Laboratory; Noah Mendelsohn, Lotus Development Corporation; Don Mullen, TIBCO Extensibility; Alex Milowski, Lexica LLC; Frank Olken, Lawrence Berkeley National Laboratory; Dave Peterson, Graphic Communications Association; 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.; Mark Tucker, Health Level Seven; Asir S. Vedamuthu, webMethods, Inc; Priscilla Walmsley, XMLSolutions; Norm Walsh, Sun Microsystems; 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; Andrew Eisenberg, Progress Software; 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; Eve Maler, Sun Microsystems; Chris Olds, Wall Data; Shriram Revankar, Xerox; Mark Reinhold, Sun Microsystems; John C. Schneider, MITRE; William Shea, Merrill Lynch; Ralph Swick, W3C; Tony Stewart, Rivcom; Steph Tryphonas, Microstar
J 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.
J.1 Equivalence classes renamed
Equivalence classes have been renamed substitution groups, to reflect the
fact that their semantics is not symmetrical.
J.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.
J.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.
J.5 Simple value normalization
All values governed by simple type definitions are now subject to
normalization, as in XML 1.0 attribute value normalization.
J.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.
J.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.
J.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.
J.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.
J.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.
J.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.
J.12 DTD non-normative
To avoid potential confusion the DTD for schemas is no longer normative,
but its use is still encouraged.
J.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.
J.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.
J.15 Validation outcomes
The determination of the values of the post-schema-validation infoset
properties relating to validation has been reworked.
J.16 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.
J.17 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.
J.18 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.
J.19 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.