This working draft incorporates all Working Group decisions through
2000-04-06. It has been reviewed by the XML Schema Working Group, and
the Working Group has agreed to its publication as a Last Call draft.
The Last Call period is expected to end 12 May 2000. Following this
Last Call for Review, the Working Group intends to submit this specification
for publication as a Candidate Recommendation.
This schedule may vary, depending on the comments of the public and of
other W3C working groups on this draft. Such comments are instrumental
in the WG's deliberations, and we encourage readers to review the draft
and to send comments to
www-xml-schema-comments@w3.org.
An archive
of the comments received is available.
Although the Working Group does not anticipate further
changes to the functionality described here, this is still a working
draft, subject to change. The present version should
be implemented only by those interested in providing a check on
its design or by those preparing for an implementation of the
Candidate Recommendation. The Schema WG will
not allow early implementation to constrain its ability to make changes to this
specification prior to final release.
1 Introduction
This document sets out the structural part (XML Schema: Structures) of the XML Schema definition language.
Chapter 2 presents a Conceptual Framework (§2) for XML Schemas, including
an introduction to the nature of XML Schemas and a formal specification
of the XML Schema abstract data model, along with
other terminology used throughout this document.
Chapter 3, Schema Component Details (§3), specifies the precise
semantics of each component of the abstract model.
Chapter 4, XML Representation of Schemas and Schema Components (§4), presents the XML representation
that maps to the abstract model, in the form
of a DTD and XML Schema for an XML Schema document type, along with rules and
conventions for identifying the components needed for any particular
validation.
Chapter 5 presents Schema Component Validity Constraints (§5), which provide
detailed constraints on the internal structure of each component of the
abstract model.
Chapter 6 presents Schema Access and Composition (§6), including the
connection between documents and schemas, the import and inclusion of declarations and definitions and
the foundations of schema-validity.
Chapter 7 discusses Validation Processing of schemas and documents (§7), including the
overall approach to schema-validation of documents, and responsibilities of schema-aware
processors.
The normative appendices include a (normative) DTD for Schemas (§B)
and a (normative) Schema for Schemas (§A) for the transfer syntax, a Glossary (normative) * (§C) [not yet written] and
References (normative) * (§D).
1.1 Purpose
The purpose of XML Schema: Structures is to define the nature of XML schemas
and their component parts,
provide an inventory of XML markup
constructs with which to represent schemas, and define the
application of schemas to XML documents.
The purpose of an XML Schema: Structures schema is to define and describe a class of
XML documents by using schema components to constrain and document the meaning,
usage and relationships of their constituent parts: datatypes, elements and
their content and attributes and their values. Schemas may also provide for the specification of additional
document information, such as default values for attributes
and elements. Schemas have
facilities for self-documentation. Thus, XML Schema: Structures can be used to define, describe and catalogue XML
vocabularies for classes of XML documents.
Any application that consumes well-formed XML can use the XML Schema: Structures
formalism to express syntactic, structural and value constraints applicable to
its document instances. The XML Schema: Structures formalism allows a useful level of
constraint checking to be described and validated for a wide spectrum of XML
applications. However, the language defined by this specification does not attempt to provide
all the facilities that might be needed by any
application. Some applications may require constraint capabilities not
expressible in this language, and so may need to perform their own additional
validations.
1.2 Dependencies on Other Specifications
The definition of XML Schema: Structures depends on the following specifications:
[URI],
[XML-Infoset],
[XML-Namespaces],
[XPath], and
[XML Schemas: Datatypes]. If the XML Base proposal is adopted before we go to REC, we will
need to account for any changes it makes to the Infoset in the areas of
QName interpretation and value space and
the interpretation of all aspects of schemas involving values identified as
being of type uriReference, including in particular
xsi:schemaLocation, xsi:noNamespaceSchemaLocation and targetNamespace.
1.3 Documentation Conventions and Terminology
The following highlighting and typography is used to present technical material in
this document:
Special terms are defined at their point of
introduction in the text; hyperlinks connect other uses of the
term to the definition. For example, a definition of
term might read: [Definition:] A term is
something we use a lot. The definition is labeled as such and the term is highlighted
typographically. The end of the definition is not specially marked
in the displayed or printed text.
Non-normative examples are set off
typographically and accompanied by a brief
explanation:
| Example |
<schema
targetNamespace="http://www.muzmo.com/XMLSchema/1.0/mySchema" >
|
|
| And an explanation of the example. |
|
References to properties of information items as defined in [XML-Infoset] are notated as links to the relevant section thereof, set off with square brackets, for example [children].
The definition of each kind of schema component consists of a list of
its properties and their contents, followed by descriptions of the
semantics of the properties:
References to properties of schema components are notated as links to
the relevant definition as exemplified above, set off with curly braces, for instance {example property}.
The correspondence between an element information item which is part
of the XML representation of a schema and one or more schema components is presented in a tableau
which illustrates the element information item(s) involved,
followed by a tabulation of the correspondence between properties of the component
and properties of the information item. Where context may determine which of
several different components may arise, several tabulations, one per component,
are given. In the XML representation, bold-face
attribute names (e.g. count below) indicate a required
attribute information item, and the rest are
optional. Where an attribute information item has an enumerated type
definition, the values are shown separated by vertical bars, as for
size below; if there is a default value, it is shown
following a colon. The allowed content of the information item is
shown as a grammar fragment, using the Kleene operators ?,
* and +. The property correspondences are normative, but
the illustration of the XML representation element information items is not.
XML Representation Summary:
example Element Information Item |
|
<example
count = integer
size = large | medium | small : medium>
Content: (child1 | child2*)
</example>
|
|
|
The following highlighting is used for non-normative commentary in
this document:
Issue (dummy):
A recorded issue.
Ed. Note:
Notes from the editors to themselves or the Working Group.
NOTE:
General comments directed to all readers.
2 Conceptual Framework
This chapter gives an overview of XML Schema: Structures at the level of its abstract data model. (Schema Component Details (§3) provides details on this model, and subsequent
chapters define
a normative representation in XML for the components of the model.)
Readers interested primarily in learning to write schema documents may wish to first read [XML Schema: Primer] and then consult XML Representation of Schemas and Schema Components (§4), using the sections below as a guide to the underlying formal structure of the schema language.
2.1 Overview of XML Schema
An XML Schema
consists of components such as type definitions
and element declarations. These can be used to assess the validity of well-formed element information items (as defined
in [XML-Infoset]), and furthermore
may specify augmentations to those items and their descendants. This augmentation makes explicit information which may have
been implicit in the original document, such as default values for
attributes and elements and
the types of element and attribute information items.
The process of schema validation consists of determining
whether an element information item satisfies the constraints embodied in the
components of an XML Schema, and if so of
adding any appropriate augmentations.
2.2 XML Schema Abstract Data Model
This specification builds on [XML] and
[XML-Namespaces]. The concepts and definitions used
herein regarding XML are framed at the abstract level of information
items as defined in [XML-Infoset]. By
definition, this use of the infoset provides a priori guarantees of well-formedness
(as defined in [XML]) and namespace
conformance (as defined in [XML-Namespaces]) for
all candidates for schema-validity and for all schema documents.
Just as [XML] and
[XML-Namespaces] can be described in terms of
information items, XML Schemas can be described in terms of an
abstract data model. In defining XML Schemas in terms of an abstract
data model, this specification rigorously specifies the information which
must be available to a conforming XML Schema processor. The abstract
model for schemas is conceptual only, and does not mandate any
particular implementation or representation of this information. To
facilitate interoperation and sharing of schema information, a
normative interchange format for schemas is described in XML Representation of Schemas and Schema Components (§4)
NOTE:
We have not so far seen any need to reconstruct the XML 1.0 notion of
root. For the connection from document instances to schemas, see
Layer 3: Web-interoperability (§6.3) and Errors in Schema Construction and Structure (§7.1).
[Definition:] Schema component is the generic term for the building blocks that comprise the abstract data model of the schema.
[Definition:]
An XML Schema is a
set of schema components. There are 12 kinds of
component in all, falling into three groups. The primary components
are as follows. They may have names, and (except for some element
declarations) may be independently accessed:
- Simple type definitions
- Complex type definitions
- Attribute declarations
- Element declarations
The secondary components are as follows. Like the primary
components, they may have names and be independently accessed:
- Attribute group definitions
- Identity-constraint definitions
- Model group definitions
- Notation declarations
Finally, the "helper" components provide small parts of
other components; they are not independent of their context and
cannot be independently accessed:
- Annotations
- Model groups
- Particles
- Wildcards
During validation, [Definition:] declaration components are associated by
(qualified) name to information items being validated.
On the other hand, [Definition:] definition components define
internal schema components that can be used in other schema components.
[Definition:] Declarations and
definitions may have and be identified by names, which are NCNames as defined by [XML-Namespaces].
[Definition:] Several kinds
of component have a target namespace, which is either
absent or a namespace URI, also as
defined by [XML-Namespaces]. The target
namespace serves to identify the namespace within which the
association between the component and its name exists. In the case of
declarations, this in turn determines the namespace URI of, for example, the element
information items it may validate.
NOTE:
At the abstract level, there is
no requirement that the components of a schema share a
target namespace. Any schema for use in
schema-validation of documents containing names from more than one namespace
will of necessity include components with different target namespaces. This contrasts with
the situation at the level of the XML Representation of Schemas and Schema Components (§4), in which each schema document contributes
definitions and declarations to a single target namespace.
Schema-validity, defined in detail in Validation Processing of schemas and documents (§7), is a
relation between information items and schema components. For example, an
attribute information item may be schema-valid with respect to an attribute
declaration, a list of element information items may be schema-valid with
respect to a content model, and so on. The following sections briefly
introduce the kinds of components in the
schema abstract data model, other major features of the abstract model, and how they contribute to the overall definition of
schema-validity.
2.2.1 Type Definition Components
The abstract model provides two kinds of type definition component: simple
and complex.
[Definition:] This specification uses
the phrase type definition in cases where no distinction
need be made between simple and complex types.
Type definitions form a hierarchy with a single root. First we describe characteristics of that
hierarchy, then provide an introduction to simple and complex type definitions themselves.
2.2.1.1 Type Definition Hierarchy
[Definition:] Except for a distinguished ur-type definition, every type definition is, by construction, either a
restriction or an extension of some other type definition. The graph of these relationships forms a tree known as the Type Definition Hierarchy.
[Definition:] A type
definition whose
declarations or facets are in a one-to-one relation with those of another
specified type
definition, with each in turn restricting the possibilities of the one it
corresponds to, is said to be a restriction.
The specific restrictions might include narrowed ranges or reduced
alternatives.
Members of a type, A, whose definition is a restriction of the definition of another type, B, are always members of type B as well.
[Definition:] A complex type definition
which allows element or attribute content in addition to that allowed by
another specified type
definition is said to be an extension.
[Definition:] A distinguished ur-type
definition is present in each XML Schema, serving as the root of the type
definition hierarchy for that schema. The ur-type definition 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.3 Complex Type Definition
A complex type definition is a set of attribute declarations and a content type, applicable to the [attributes] and
[children] of an element information item respectively. The content type may
require the [children] to contain neither element nor character information
items, to be a string which is schema-valid with respect to particular simple
type or to contain a sequence of element information items which is schema-valid with respect to a particular model group, with or without character information items as well.
Each complex type definition is either
or
or
A
complex type which extends another does so by having additional content model
particles at the end of the other definition's content model,
or by having additional attribute declarations, or both.
NOTE:
This specification allows only appending, and not other kinds of
extensions. This decision
simplifies application processing required to cast instances from derived to
base type. Future versions may allow more kinds of extension, requiring more
complex transformations to effect casting.
See Complex Type Definition Details (§3.4) for the composition and
schema-validation contributions of complex type definition schema components, XML Representation of Complex Type Definition Schema Components (§4.3.3) for the XML representation of
complex type definitions and Complex Type Definition Constraints (§5.11) for constraints on complex
type definition components as such.
2.2.2 Declaration Components
There are three kinds of declaration component: element, attribute, and
notation. Each described in a section below. Also included is a discussion of element equivalence
classes, which is a feature provided in conjunction with element declarations.
2.2.2.1 Element Declaration
An element declaration is an association of a name with a type definition, either simple or
complex, an (optional) default value and a set of identity-constraint
definitions. The association is either global or scoped to a containing complex type definition. A
global element declaration with name 'A' is broadly comparable to a pair of
DTD declarations as follows, where the associated type definition
fills in the ellipsis:
<!ELEMENT A . . .>
<!ATTLIST A . . .>
Element declarations contribute to
schema-validity as part of model group validation, when their defaults and type components are checked against an element
information item with a matching name and namespace, and by triggering
identity-constraint definition validation.
See Element Declaration Details (§3.3) for the composition and
schema-validation contributions of element declaration schema components, XML Representation of Element Declaration Schema Components (§4.3.2) for the XML representation of
element declarations and Element Declaration Constraints (§5.2) for constraints on
element declaration components as such.
2.2.2.2 Element Equivalence Class
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 equivalence classes, 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
exemplar, for an element equivalence class. Other global element declarations, regardless of target namespace, can be designated as members of the class defined by the exemplar. In a suitably enabled content model, a reference to the exemplar validates not just the exemplar itself, but elements corresponding to any member of the equivalence class as well.
All such members must have type definitions which are either the same as the
exemplar'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 equivalence class are defined, the
content of member elements is strictly limited according to the type
definition of the equivalence class exemplar.
Note that element equivalence classes are not represented as separate components. They are
specified in the property values for element declarations (see Element Declaration (§2.2.2.1)).
2.2.2.3 Attribute Declaration
An attribute declaration is an association between a name and a simple type definition, together
with occurrence information and (optionally) a default value. The
association is either global, or local to its containing complex type definition. Attribute declarations contribute to
schema-validity as part of complex type definition validation, when their
occurrence, defaults and type components are checked against an attribute
information item with a matching name and namespace.
See Attribute Declaration Details (§3.2) for the composition and
schema validation contributions of attribute declaration schema components, XML Representation of Attribute Declaration Schema Components (§4.3.1) for the XML representation of
attribute declarations and Attribute Declaration Constraints (§5.1) for constraints on
attribute declaration components as such.
2.2.3 Model Group Components
The model group, particle, and wildcard components contribute to
the portion of a complex type definition that controls an element
information item's content type.
2.2.3.1 Model Group
A model group is a constraint in the form of a grammar fragment that applies to
lists of element information items. It consists of a list of particles, i.e.
element declarations, wildcards and model groups. There are three varieties of
model group:
- Sequence (the element information items
match the particles in sequential order)
- Conjunction (the element information items match the
particles, in any order)
- Disjunction (the element information items match
one of the particles)
See Model Group Details (§3.7) for the composition and
schema-validation contributions of model group schema components, Complex Type Definition Details (§3.4) for the use of model groups as content models, XML Representation of Model Group Schema Components (§4.3.6) for the XML representation of
model groups and Model Group Constraints (§5.7) for constraints
on model group components as such.
2.2.3.2 Particle
A particle is a term in the grammar for element content, consisting of either an element
declaration, a wildcard or a model group, together with
occurrence constraints. Particles contribute to
schema-validity as part of complex type validation, when they allow anywhere
from zero to many element information items or sequences thereof, depending on
their contents and occurrence
constraints.
[Definition:] A particle can
be used in a complex type definition to express a validity
constraint on the [children] of an element information item; such a particle is called
a content model.
NOTE:
XML Schema: Structures content models are similar to but more expressive than
[XML] content models; unlike [XML], XML Schema: Structures applies content models to the validation of both mixed and element-only content.
See Particle Details (§3.8) for the composition and
schema-validation contributions of particle schema components, XML Representation of Model Group Schema Components (§4.3.6) for the XML representation of
particles and Particle Constraints (§5.10) for constraints
on particle components as such.
2.2.4 Identity-constraint Definition Components
A identity-constraint definition is an association between a name and one of
several varieties of
identity-constraint related to uniqueness and reference. All the
varieties use [XPath] expressions to pick out sets of
information items relative to particular target element
information items which are unique, or a key, or a valid reference, within
a specified scope. An element information item is only schema-valid with
respect to an element declaration
with identity-constraint definitions if those definitions are all satisfied for all the descendants
of that element information item which they pick out.
See Identity-constraint Definition Details (§3.10) for the composition and
schema-validation contributions of identity-constraint definition schema components, XML Representation of Identity-constraint Definition Schema Components (§4.3.8) for the XML representation of
identity-constraint definitions and Identity-constraint Definition Constraints (§5.3) for constraints
on identity-constraint definition components as such.
2.2.5 Group Definition Components
There are two kinds of convenience definitions available for use
in reusing pieces of complex type definitions: model group definitions
and attribute group definitions.
2.3 Constraints and Contributions
The [XML] specification describes two kinds of
constraints on XML documents: well-formedness and
validity constraints. Informally, the well-formedness constraints
are those imposed by the definition of XML itself (such as the rules for the
use of the < and > characters and the rules for proper nesting of
elements), while validity constraints are the further constraints on document
structure provided by a particular DTD.
The preceding section focussed on schema-validity, that is
the constraints on information items which schema components supply. In fact
however this specification provides four different kinds of normative statements about schema
components, their representations in XML and their contribution to the
schema-validation of information items:
-
[Definition:] Constraint on Schemas
-
Constraints on the schema components themselves, i.e.
conditions components must satisfy to be components at all. Largely to be
found in Schema Component Validity Constraints (§5).
-
[Definition:] Schema Representation Constraint
-
Constraints on the
representation of schema components in XML. Some but not all of these are expressed in (normative) DTD for Schemas (§B) and (normative) Schema for Schemas (§A). Largely to be
found in XML Representation of Schemas and Schema Components (§4).
-
[Definition:] Validity Contribution
-
Constraints expressed by schema components which information
items must satisfy to
be schema-valid. Largely to be
found in Schema Component Details (§3).
The definition of the above constraints sometimes involves many
clauses, some as alternatives, some as joint requirements. The presentations
below number all clauses: clauses at the same level are either clearly
identified as alternatives with words such as either and
or, or should be understood as joint.
-
[Definition:] Schema Information Set
Contribution
-
Augmentations to post-schema-validation information sets
expressed by schema components, which follow
as a consequence of schema-validation.
Largely to be
found in Schema Component Details (§3).
Schema information set
contributions are not new. XML 1.0
validation augments the XML 1.0 information set in similar ways,
for example by
providing values for attributes not present in instances, and by implicitly
exploiting type information for normalisation or access.
(As an example of the latter case, consider the
effect of NMTOKENS on attribute whitespace, and the semantics of
ID and IDREF.) By including schema
information set contributions, this specification makes explicit some features
that XML 1.0 left implicit.
2.4 Conformance
This specification describes three levels of conformance for schema aware processors. The first is
required of all processors. Support for the other two will depend on the application environments
for which the processor is intended.
[Definition:] Minimally conforming processors must completely and
correctly implement the Constraints on
Schemas, Validity Contributions,
and Schema Information
Set Contributions contained in this specification.
[Definition:] Processors which accept
schemas in the form of XML documents as described in XML Representation of Schemas and Schema Components (§4) are
additionally said to provide conformance to the XML Representation of Schemas.
Such processors must, when processing schema documents, completely and
correctly implement all Schema Representation
Constraints in this specification, and must adhere exactly to the
specifications in XML Representation of Schemas and Schema Components (§4) for mapping the contents of such documents to schema components for use in validation.
NOTE:
By separating the conformance requirements relating to the concrete syntax of XML schema
documents, this specification admits processors
which validate using schemas stored in optimised binary
representations, dynamically created schemas represented as programming language data structures, or implementations in which particular schemas are compiled into executable code
such as C or Java. Such processors can be said to be minimally conforming but not necessarily in conformance to the XML Representation of Schemas.
[Definition:] Fully conforming
processors are network-enabled processors which support both levels of conformance described
above, and which must additionally be capable of accessing
schema documents from the World Wide Web according to Representation of Schemas on the World Wide Web (§2.7) and How schema definitions are located on the Web (§6.3.2).
.
NOTE: Although this specification provides just these three standard levels of conformance, it is
anticipated that other conventions can be established in the future. For example, the World Wide
Web Consortium is considering conventions for packaging on the Web a variety of
resources relating to individual documents and namespaces. Should such
developments lead to new conventions for representing schemas, or for accessing them on the Web,
new levels of conformance can be established and named at that time. There is no need to modify
or republish this recommendation to define such additional levels of conformance.
See Schema Access and Composition (§6) for a more detailed explanation of the
mechanisms supporting these levels of conformance.
2.5 Names and Symbol Spaces
As discussed in XML Schema Abstract Data Model (§2.2), most schema
components (may) have names.
If all such names were assigned from the same "pool", then
it would be impossible to have, for example, a simple type definition and an element
declaration both with the name
"title" in a given target namespace.
This specification
therefore introduces the term
[Definition:] symbol space to denote a
collection of names, each of which is unique with respect to the others. A symbol space is similar to the non-normative concept of namespace partition introduced in [XML-Namespaces].
There is a single distinct symbol space within a given target
namespace for each kind of definition and declaration component
identified in XML Schema Abstract Data Model (§2.2), except that within a target namespace, simple
type definitions and complex type definitions share a symbol space.
Within a given symbol space, names are unique, but the same name may appear in more than one symbol space without conflict. For example, the same name can appear in both a type definition and an element declaration, without conflict or necessary relation between the two.
Locally scoped attribute and element
declarations are special with regard to symbol spaces.
Every complex type definition defines its own local attribute and element declaration symbol
spaces, where these symbol spaces are distinct from each other and from any of the other
symbol spaces. So, for example, two complex type definitions having
the same target namespace can contain
a local attribute declaration for the unqualified name "priority", or contain a local element declaration
for the name "address", without conflict or necessary relation between
the two.
2.6 Schema-Related Markup in
Documents Being Schema-Validated
The XML representation of schema components uses a vocabulary
identified by the namespace URI http://www.w3.org/1999/XMLSchema.
XML Schema: Structures also defines several attributes for direct use in XML documents. These attributes are in a different namespace,
which has the namespace URI http://www.w3.org/1999/XMLSchema-instance.
For brevity, the text and examples in this specification use the prefix
xsi: to stand for this latter namespace; in practice,
any prefix can be used.
2.6.2 xsi:null
XML Schema: Structures introduces a mechanism for signalling that an element's content is
missing, or "null" in the terminology of databases. An
element has null content if it has the attribute xsi:null with
the value true. An element so labelled must be empty, but can
carry attributes if permitted by the corresponding complex type.
2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation
The xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes can be used in a document to provide
hints as to the physical location of schema documents which may be used for validation.
See How schema definitions are located on the Web (§6.3.2) for details on the use of these attributes.
3 Schema Component Details
The following sections provide full details on the properties and
significance of the schema itself and each kind of schema component. For each property, its range,
that is the kinds of values it may have, is defined. This can be understood as
defining a schema as a labelled directed graph, where the root is a schema, and
every other vertex is a schema
component or a literal (string, boolean, number) and every labelled edge a
property. The graph is not acyclic: multiple copies of
components with the same name in the same symbol space may not exist, so in some cases re-entrant chains
of properties must exist. Equality of components for the purposes of this
specification is always addressed at the level of names (including target
namespaces) within symbol spaces. Any property not
identified as optional is required to be present, optional properties which are absent are taken to have absent as their value. Any
property identified as a having a set, subset or list value may have an empty value unless this is explicitly
ruled out: this is not the same as absent. Any property value identified as superset or subset of some set may be equal to that set, unless a proper superset or subset is explicitly called for.
By 'string' in Part 1 of this specification is meant a
sequence of ISO 10646 character codes identified as legal XML character codes
in [XML].
NOTE:
Readers whose primary interest is in the XML representation of schemas
may wish to skip this chapter on the first reading, concentrating on XML Representation of Schemas and Schema Components (§4) and [XML Schema: Primer].
Throughout the following sections, when we refer to the lexical [value] of some
attribute information item, we mean by this a string composed of, in order, the
[character code] of each character information item in the [children] of that
attribute information item.
Many properties are identified below as having (sets of)
other schema components as values. For the purposes of exposition, the definitions in
this section assume that (unless the property is explicitly identified as
optional) all such values are in fact present. When schema
components are constructed from XML representations involving reference by name
to other components, this assumption may be violated if one or more references
cannot be resolved. This specification addresses the matter of missing
components in a uniform manner, described in Missing Sub-components (§7.3): no mention of
handling missing components will be found in the individual component
descriptions below.
As the above makes clear, at the level of schema components and schema
validation, reference to components by name is normally not involved. In a
few cases, however, qualified names appearing in information items being
validated must be resolved to schema components by such lookup. The following
constraint is appealed to in these cases.
Schema Representation Constraint: QName resolution (Instance)
A pair of a local name and a namespace URI (or
absent)
resolve to a schema component of a specified kind in the context of schema
validation if the component is that member of the value of the appropriate
property of the schema being used for the validation, that is:
whose
{local name} matches the local name and whose
{target namespace} is identical to the namespace URI of the pair.
NOTE:
A schema and its components as defined in this chapter are an idealisation of the information a schema-aware
processor requires: implementations are not constrained in how they provide
it. In particular, no implications about literal embedding versus indirection
follow from the use above of language such as "properties . . . having . . .
components as values".
3.1 Schema details
At the abstract level, the schema itself is just a container for its components.
See XML Representations of Schemas (§4.1) for the XML representation of
schemas and Schema Constraints (§5.13) for constraints on schemas as such.
Schema Information Set Contribution: Schema Information
In the post-schema
validation infoset a
[schema information] property is added
to the element information item at which validity assessment began. Its value
is a list of tuples, one for each namespace URI which appears as the
{target namespace} of any schema component in the schema used for that
assessment. Each tuple consists of such a namespace URI followed by 0 or
more pairs. Each pair is composed of a URI reference, if available, and a
[document
information item], if available, for a schema document which
contributed components to the schema, whose
targetNamespace matches the namespace URI (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)).
3.2 Attribute Declaration Details
Attribute declarations provide for:
- Requiring/preventing the appearance of attribute information items;
- 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 {min occurs} of 1 specifies that the corresponding attribute must
be present; a value of 0 allows for optional attributes.
Similarly, a {max occurs} of 0 indicates an attribute that must
not be present; a value of 1 (the normal case) allows the attribute to occur
explicitly. The XML representation does not require two attributes to specify
these properties, but rather uses a single use [attribute] with
values such as optional and required: see XML Representation of Attribute Declaration Schema Components (§4.3.1) for details.
A {scope} of global identifies attribute declarations
available for use in complex type definitions throughout the schema. Locally scoped declarations are available for use only within the
complex type definition identified by the {scope} property. This property is also absent in the case of non-global declarations within attribute group definitions: their scope will be determined when they are used in the construction of complex type definitions.
A non-absent value of the {target namespace} property provides for validation of
namespace-qualified attribute information items (which must be explicitly
prefixed in the character-level form of XML documents). absent values of
{target namespace} validate unqualified (unprefixed) items.
The value of the attribute must conform to the supplied {simple type definition}.
{value constraint} reproduces the functions of XML 1.0 default and #FIXED
attribute values. fixed indicates that the attribute value must match the supplied
constraint string; default specifies that the attribute is to appear unconditionally in
the post-schema-validation information set, with the supplied value used
whenever the attribute is not actually present. As for {min occurs} and {max occurs} the XML representation reflects this information indirectly: see XML Representation of Attribute Declaration Schema Components (§4.3.1).
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},
{min occurs}, {max occurs} and
default {value constraint} is provided in
conjunction with other aspects of complex type validation (see Element Children and Attributes Valid (§3.4).)
[XML-Infoset] distinguishes namespace declarations such as xmlns or xmlns:xsl from
attributes. Accordingly, it is unnecessary and in fact not possible for
schemas to contain attribute declarations corresponding to such
namespace declarations, see xmlns Not Allowed (§5.1). No means is provided in
this specification to supply a
default value for a namespace declaration.
See XML Representation of Attribute Declaration Schema Components (§4.3.1) for the XML representation of
attribute declarations and Attribute Declaration Constraints (§5.1) for constraints on attribute
declaration components as such.
Validation Contribution: Attribute Valid
For an attribute information item to be schema-valid with respect to an
attribute declaration, its lexical
[value] must
Validation Contribution: Attribute Valid (Lax)
An attribute information item is laxly schema-valid if either
or
Schema Information Set Contribution: Attribute Validated by Type
Schema Information Set Contribution: Validation Outcome (Attribute)
If an attribute information item's schema-validity as defined by
Attribute Valid (§3.2) has been assessed, whether successfully or not, then in the
post-schema validation infoset the item has a
[validation attempted] property with the value
full.
If an attribute information item's schema-validity as defined by
Attribute Valid (§3.2) has not been assessed, but its lax schema-validity as
defined by
Attribute Valid (Lax) (§3.2) has been assessed, in the post-schema
validation infoset the item has a
[validation attempted] property with the value
partial.
3.3 Element Declaration Details
Element declarations provide for:
- Establishing the validity of element information items.
- Determining schema information set contributions, such as default values.
- Establishing uniquenesses and reference constraint relationships among the values of related elements and
attributes.
- Controlling the substitutability of elements through the
mechanism of element equivalence classes.
The element declaration schema component has the following
properties:
The {name} property must match the local part of the names
of element information items being validated.
A {scope} of global identifies element declarations available for use in content
models throughout the schema. Locally scoped declarations are available for use only within the
complex type identified by the {scope} property. This property is absent in the case of non-global declarations within named model groups: their scope will be determined when they are used in the construction of complex type definitions.
A non-absent value of the {target namespace} property provides for validation of
namespace-qualified element information items. absent values of
{target namespace} validate unqualified items.
An element information item is schema-valid
if it obeys the schema validity constraints of the {type definition}. For such an
item, the schema information set contributions from the {type definition} are applied to the
corresponding element information item in the post-schema-validation information set. {type definition} must not be an
abstract type definition.
If {nullable} is true, then an element is also
schema-valid if it
carries the namespace qualified attribute with [local name] null from namespace http://www.w3.org/1999/XMLSchema-instance and value true (see xsi:null (§2.6.2)) even if it has
no text or element content despite a {content type} which would
otherwise require content. Formal details of element validation are described in Element Valid (Explicit) (§3.3).
{value constraint} establishes a default or fixed value for an element. If default is specified, and if the element
being validated is empty, then the supplied
constraint string becomes [character]
[children] 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 equivalence class, if any, identified
by {equivalence class affiliation}. Membership is transitive but not symmetric; an element
declaration is implicitly a member of any class of which its {equivalence class affiliation} is a member.
An empty {equivalence class exclusions} allows a declaration to be nominated as
the {equivalence class affiliation} of other element declarations having the same {type definition} or
types derived therefrom. The explicit
values of {equivalence class 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
{equivalence class affiliation} of any other declaration.
The supplied values for {disallowed substitutions} determine
whether an element declaration appearing in a content model will be prevented from additionally
validating elements (a) with an xsi:type (§2.6.1) that identifies an
extension or restriction of the type of the declared element, and/or (b) from validating elements which are in the same
equivalence class as the declared element.
If {disallowed substitutions} is empty, then all derived types and equivalence class members are valid.
Element declarations for which {abstract} is true can appear in
content models only when equivalence class substitution is allowed;
such declarations may not themselves ever be used to validate element content.
See XML Representation of Element Declaration Schema Components (§4.3.2) for the XML representation of
element declarations and Element Declaration Constraints (§5.2) for constraints on element
declaration components as such.
Validation Contribution: Element Valid (Explicit)
NOTE: The {name} and {target namespace} properties are not
mentioned above because they are checked during particle validation, as per
Element Sequence Valid (Particle) (§3.8).
Validation Contribution: Element Valid (Lax)
An element information item is laxly schema-valid if either
or
Schema Information Set Contribution: Element Default Value
Schema Information Set Contribution: Element Validated by Type
If an element information item is schema-valid with respect to an element
declaration, in the post-schema
validation infoset the element information item has four properties as follows:
-
[type definition type]
-
simple or complex, depending on the actual type definition
-
[type definition namespace]
-
the {target namespace} of the actual type definition
-
[type definition anonymous]
-
true if the {name} of the actual type definition is absent, otherwise false
-
[type definition name]
-
the {name} of the actual type definition, if it is not absent. If it is
absent, schema processors may, but need not,
provide a value unique to the {type definition} of the
declaration.
Also, if the declaration has a
{value constraint}, the item's
[default] is set to a list of character information items, one per character
in that
{value constraint}'s string.
Schema Information Set Contribution: Element Null
If an element information item is schema-valid with respect to an element
declaration then in the post-schema
validation infoset the element
information item has a
[null] property with the value
true if clause 1.2 of
Element Valid (Explicit) (§3.3) above obtains,
otherwise
false.
Schema Information Set Contribution: Validation Outcome (Element)
If
| 1.1 |
an element information item's schema-validity as defined by
Element Valid (Explicit) (§3.3) has been assessed, whether successfully or not;
|
| 1.2 |
all its element information item children have the value full for
their [validation attempted] property,
|
then in the
post-schema validation infoset the item has a
[validation attempted] property with the value
full.
If an element information item's schema-validity as defined by
Element Valid (Explicit) (§3.3) has not been assessed, or has been but the above
clause is not satisfied, but its lax schema-validity as
defined by
Element Valid (Lax) (§3.3) has been assessed, in the post-schema
validation infoset the item has a
[validation attempted] property with the value
partial.
3.4 Complex Type Definition Details
Complex Type Definitions provide for:
- Constraining element information items by providing Attribute Declaration (§2.2.2.3)s governing the appearance and content of
[attributes]
- Constraining element information item [children] to be empty, or to conform to a specified element-only or mixed content model.
- Using the mechanisms of Type Definition Hierarchy (§2.2.1.1) to derive a complex type from another simple or complex type.
-
Specifying contributions to the post-schema-validation information set for elements.
- Limiting the ability to derive additional types from a given complex type.
- Controlling the permission to substitute, in an instance, elements of a derived
type for elements declared in a content model to be of a given complex type.
- Determining post-schema-validation
information set contributions.
A complex type definition schema component has the following
properties:
Complex types definitions are identified by their {name} and {target namespace}. Except
for anonymous complex type definitions (those with no {name}), since
type definitions (i.e. both simple and complex type definitions taken together) must be uniquely identified within an XML
Schema, no complex type definition can have the same name as another
simple or complex type definition. Complex type {name}s and {target namespace}s
are provided for reference from
instances (see xsi:type (§2.6.1)), and for use in the XML Representation of Schemas and Schema Components (§4)
(specifically in element and attribute). See References to schema components across namespaces (§6.2.2) for the use of component
identifiers when importing one schema into another.
NOTE:
The {name} of a complex type is not ipso
facto the [(local) name] of the
element information items validated by that definition. The connection between a
name and a type definition is described in Element Declaration Details (§3.3).
As described in Type Definition Hierarchy (§2.2.1.1), each complex type is derived from a
{base type definition} which is itself either a Simple Type Definition (§2.2.1.2) or a Complex Type Definition (§2.2.1.3). {derivation method} specifies the means of derivation as either extension or restriction (see Type Definition Hierarchy (§2.2.1.1)).
A complex type with an empty specification for {final} can be used as a
{base type definition} for other types derived by either of
extension or restriction; the explicit values extension, and restriction prevent further
derivations by extension and restriction respectively. If all values are specified, then the complex type is said to be
[Definition:] final: no
further derivations are possible.
A complex type for which {abstract} is true must not appear as the
{type definition} of an Element Declaration (§2.2.2.1), and must not be referenced from an
xsi:type (§2.6.1) attribute in an instance document; such abstract complex types can be
used as {base type definition}s, but they are never used directly to validate
element content.
{attribute declarations} are a set of individual Attribute Declaration (§2.2.2.3)s
to be used for schema-validating the
[attributes]
of element information items. See Element Children and Attributes Valid (§3.4)
and Attribute Valid (§3.2) for details of attribute validation.
{attribute wildcard}s provide a more flexible specification for validation of
attributes not explicitly included in {attribute declarations}.
Informally, the specific values
of {attribute wildcard} are interpreted as follows:
-
any: [attributes] can include attributes with any qualified or unqualified name.
-
a set whose
members are either namespace URIs or absent: [attributes] can
include any attribute(s) from the specified namespace(s). If absent is included in the set, then any unqualified attributes are (also) allowed.
-
'not' and a namespace URI: [attributes] cannot include attributes from the specified namespace.
-
'not' and absent: [attributes] cannot include
unqualified attributes.
See Element Children and Attributes Valid (§3.4) and Wildcard allows Namespace URI (§3.9) for formal
details of attribute wildcard validation.
{content type} determines the schema-validation of [children] of element information items. Informally:
{prohibited-substitutions} determine
whether an element declaration appearing in a
content model is prevented from additionally
validating element items with an xsi:type (§2.6.1) attribute that
identifies an extension or restriction, or element items in
an equivalence class whose type definition is similarly derived (if {prohibited-substitutions} contains one of those).
If {prohibited-substitutions} is empty,
then all such substitutions are valid.
See Element Children and Attributes Valid (§3.4)
for a formal specification of element content validation.
See XML Representation of Complex Type Definition Schema Components (§4.3.3) for the XML representation of
complex type definitions and Complex Type Definition Constraints (§5.11) for constraints on
complex type definition components as such.
Validation Contribution: Element Children and Attributes Valid
An element information item is schema-valid with respect to a complex type definition if:
Schema Information Set Contribution: Attribute Default Value
Schema Information Set Contribution: Validation Outcome (Complex Type)
If the schema-validity, as defined by
Element Children and Attributes Valid (§3.4)
above, of an element information item has been assessed,
in the post-schema validation infoset the item has a
[validity]
property, whose value is
complete if the item is schema-valid,
partial if it is not schema-valid but some or all of its element
information item
[children] and/or its
[attributes] are either schema-valid
or laxly schema-valid, otherwise
not.
There is a complex type definition equivalent to the ur-type definition present in every
schema by definition. It has the following properties:
| Complex Type Definition of the Ur-Type |
|
|
The mixed content specification together with the
unconstrained wildcard content model and attribute specification produce the defining property for the
ur-type definition, namely that every complex type
definition is (eventually) a restriction
of the ur-type definition: its permissions and requirements are
the least restrictive possible.
3.7 Model Group Details
When the [children] of element information items are not constrained
to be empty or by reference to a simple type definition
((non-normative) Simple Type Definition Details (§3.13)), the sequence of element
information item [children] content may be specified in
more detail with a model group. Because the {term} property of a particle can be a
model group, and model groups contain particles, model groups can indirectly contain other model groups; the grammar for content models
is therefore recursive.
The model group schema component has the following
properties:
{compositor}determines whether the element
information item [children] validated by the model group must:
- (sequence) correspond, in order, to the specified {particles};
- (choice) corresponded to exactly one of the specified {particles};
- (all, (in which case {particles} is restricted to contain local and global element
declarations, with {min occurs}
=0 or
1, {max occurs}=1) contain exactly zero or one of each element specified in {particles}. The elements can occur in any order.
When two or more element declarations with the same identity occur at
any level within a model group, their type definitions must be the same.
{annotation}Description to be supplied in a future draft.
Validation Contribution: Element Sequence Valid
[Definition:] We define a
partition of a sequence as a sequence of sub-sequences, some or
all of which may be empty, such that concatenating all the sub-sequences yields
the original sequence.
A sequence (possibly empty) of element information items is schema-valid with respect to
a model group if
or
or
Nothing in the above should be understood as ruling out groups whose
{particles} is empty: although no sequence can be schema-valid
with respect to such a group whose
{compositor} is
choice, the empty sequence
is schema-valid with respect
to empty groups whose
{compositor} is
sequence or
all.
NOTE:
The above definition is implicitly non-deterministic, and should not be
taken as a recipé for implementations. Note in particular that when
{compositor} is all, particles is restricted to a list
of local and global element declarations (see Model Group Constraints (§5.7)). A much simpler implementation is possible than would arise from a literal interpretation of the definition above; informally, the content is valid when each declared element occurs exactly once (or at most once, if {min occurs} is 0), and each is valid with respect to its corresponding declaration. The elements can occur in arbitrary order.
See XML Representation of Model Group Schema Components (§4.3.6) for the XML representation of
model groups and Model Group Constraints (§5.7) for constraints
on model group components as such.
3.8 Particle Details
As described in Model Group Details (§3.7), particles contribute to the definition
of content models. The particle schema component has the following properties:
The following is an informal overview of the properties of a particle. Formal interpretation of
these properties is found in Element Sequence Valid (Particle) (§3.8).
In general, multiple element
information item [children], possibly with intervening character [children] if the content type
is mixed, can be validated with respect to a single particle. {min occurs} determines the minimum number of such element [children] that can validly occur. The number of such children must be greater than or equal to {min occurs}. If {min occurs} is 0, then occurrence of such children is optional.
The number of such element [children] must be less than or equal to any numeric specification of
{max occurs}; if {max occurs} is unbounded, then there is no
upper bound on the number of such children.
Validation Contribution: Element Sequence Valid (Particle)
A sequence (possibly empty) of element information items is schema-valid
with respect to a particle if either
| 1.1.1 |
The length of the sequence is greater than or equal to the {min occurs};
|
| 1.1.2 |
If {max occurs} is a number, the length of the sequence is less than or equal to the {max occurs};
|
| 1.1.3 |
Either
| 1.1.3.1 |
the {term} is a wildcard and each element
information item in the sequence is schema-valid with respect to the wildcard as defined by Item Valid (Wildcard) (§3.9)
|
or
| 1.1.3.2.1 |
the {term} is an element declaration;
|
| 1.1.3.2.2 |
for each element
information item in the sequence either
or
or
|
|
or
See XML Representation of Model Group Schema Components (§4.3.6) for the XML representation of
particles and Particle Constraints (§5.10) for constraints
on particle components as such.
3.9 Wildcard Details
In order to exploit the full potential for extensibility offered by XML
plus namespaces, more provision is needed than DTDs allow for targeted flexibility in content
models and attribute declarations. A wildcard provides for validation of
attribute and element information items dependent on their namespace
URI, but independently
of their local name. The wildcard schema component has the following properties:
{namespace constraint} provides for validation of elements that:
-
(any) have any namespace or are not namespace qualified;
-
(not and a namespace URI) have any namespace other than the specified namespace URI, or
are not namespace qualified;
-
(not and absent) are namespace qualified;
-
(a set whose
members are either namespace URIs or absent) have any of the
specified namespaces and/or, if absent is included in the set, are unqualified.
{process contents} controls the impact on schema-validity
of the information items allowed by wildcards, as follows:
-
strict
-
There must be a global declaration for the item available, and it
must be schema-valid with respect to that definition.
-
skip
-
No constraints at all: the item must simply be well-formed XML.
-
lax
-
If the item, or any items among its [children] if it's an element
information item, has a uniquely
determined declaration available, it must be laxly schema-valid with respect to
that definition, that is, schema-validate where you can, don't worry when you can't.
Validation Contribution: Item Valid (Wildcard)
An element or attribute information item is schema-valid with respect to a wildcard
constraint if
Validation Contribution: Wildcard allows Namespace URI
A value which is either a namespace URI or
absent is schema-valid with respect to a wildcard constraint (the
value of a
{namespace constraint}) if
| 1.1 |
the constraint is any;
|
or
| 1.2 |
the constraint is a pair of not and a namespace URI, and
the value is not identical to the namespace URI;
|
or
| 1.3 |
the constraint is a set, and the value is identical to one of the members of the set.
|
Schema Information Set Contribution: Validation Outcome (skipped)
If clause 1.2.1 of
Item Valid (Wildcard) (§3.9) above obtains with
respect to an information item, in the post-schema
validation infoset the item has a
[validation attempted] property with the value
none.
See XML Representation of Wildcard Schema Components (§4.3.7) for the XML representation of
wildcards and Wildcard Constraints (§5.5) for constraints
on wildcard components as such.
3.10 Identity-constraint Definition Details
Identity-constraint definition components provide for uniqueness and reference constraints with respect
to the contents of multiple elements and attributes. The identity-constraint definition schema component has the following
properties:
Identity-constraint definitions are identified by their {name} and {target namespace}; Identity-constraint definition identities must be unique within an XML Schema. See References to schema components across namespaces (§6.2.2) 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(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(s), with those of the {referenced key}.
These constraints are specified independently of the types of the
attributes and elements involved, i.e. something declared as of type integer
may also serve as a key, unlike ID and
IDREF. Each constraint declaration has a name, which exists in a
single symbol space for constraints. The equality and inequality conditions
appealed to in checking these constraints applies to the value of
the fields selected, so that for example 3.0 and 3
would be conflicting keys if they were both decimal, but non-conflicting if
they were both strings, or one was a string and one a decimal.
Overall the augmentations to XML's ID/IDREF mechanism are:
- Not just attribute values, but also element content and combinations
of values and content can be declared to be unique;
- Constraints are specified to hold within the scope of particular elements;
- (Combinations of) attribute values and/or element content can be
declared to be keys, that is, not only unique, but always present and non-nullable;
-
The comparison between keyref {fields} and
key or unique {fields} is by value equality,
not by string equality.
{selector} specifies an XPath expression [XPath] relative to
instances of the element being declared. This must identify a node set of subelements (i.e. elements contained within the declared element) to which the constraint applies.
{fields} specifies XPath expressions relative to each
element selected by a {selector}. This must identify
a single node (element or attribute, not necessarily within the selected element) whose content or value, which must be
of a simple type, is used in the constraint. It is possible to specify an
ordered list of {fields}s, to cater to multi-field keys,
keyrefs, and uniqueness constraints.
NOTE:
Provision for multi-field keys etc. goes beyond what is supported by xsl:key.
NOTE:
If reference to a key or unique defined in a scoping element which may
occur more than once is envisaged (which reference may be from outside any of
the scoping elements), then the scoping elements themselves must
have keys (typically unique across the entire document), and the scoped keys must include the
key of their scoping element among their fields.
A formal description of Identity-constraint definition validation is given below in Identity-constraint Satisfied (§3.10)
Validation Contribution: Identity-constraint Satisfied
An element information item is schema-valid with respect to a identity-constraint if
| 1.1 |
The {selector}, with the element information item as the
context node, evaluates to a node-set (as defined in
[XPath]). [Definition:] Call this the target node set;
|
| 1.2 |
Each node in the target node set is an
element node among the descendants of the context node;
|
| 1.3 |
For each node in the target node set all of the {fields}, with that node as the context
node, evaluate to either an empty node-set or a node-set with exactly one
member. [Definition:] Call the sequence of the values (as defined in [XML Schemas: Datatypes]) of those node-sets in order the key-sequence of the node;
|
[Definition:] Call the subset of the target node set for
which all the {fields} evaluate to a node-set with exactly one
member which is an element or attribute node the qualified node set;
or
or
NOTE:
This specification does not define a post-schema validation infoset
contribution which would enable schema-aware processors to implement clause
2.2.4 above. This clause can be read as if there were such a contribution,
which recorded for example either the element declaration appealed to in
Element Valid (Explicit) (§3.3), or the value of its {nullable} property.
Schema Information Set Contribution: Identity-constraint Table
[Definition:] An eligible
identity-constraint of an element information item is one such that clauses 2.1.[1-2] or 2.2.[1-3] of Identity-constraint Satisfied (§3.10) obtains
with respect to that item and that constraint,
or such that any of the element information item [children] of that item have a
[identity-constraint table] with an entry for that constraint.
[Definition:] A node table is a set of pairs each consisting of
a key-sequence and an element node.
Whenever an element information item has one or more
eligible constraints, a new
[identity-constraint table] is added to the post-schema-validation
infoset for that element information item, consisting of pairs of identity-constraints
and
node tables, one for each of the item's
eligible constraints, with the
node table in each pair defined as follows: There is a member in the
node table
associated with an
eligible constraint of an
element information item consisting of a
key-sequence (call it
k) and a node (call it
n) if and only if
NOTE: This information set contribution, unlike others in this
specification, is essentially an internal bookkeeping mechanism. It is introduced to
support the definition of Identity-constraint Satisfied (§3.10) above.
Accordingly, conformant processors may, but are not required, to expose
[identity-constraint table]s in the post-schema-validation infoset.
In other words, the above constraints may be read as saying validation of
identity-constraints proceeds as if such an infoset property existed.
See XML Representation of Identity-constraint Definition Schema Components (§4.3.8) for the XML representation of
identity-constraint definitions and Identity-constraint Definition Constraints (§5.3) for constraints
on identity-constraint definition components as such.
3.12 Annotation Details
The annotation schema component has the following
properties:
{user information} is intended for human consumption, {application information} for automatic processing. In both cases, provision is made for an optional URI reference to supplement the local information. Schema validation does not involve dereferencing these URIs, when present. In the case of {user information}, indication may be given as to the identity of the (human) language used in the contents, using the xml:lang attribute.
Annotations do not participate in schema-validation as such. Provided
an annotation itself satisfies all relevant Constraints of Schemas it cannot affect the schema-validity of element information items.
See XML Representation of Annotation Schema Components (§4.3.10) for the XML representation of
annotations and Annotation Constraints (§5.9) for constraints
on annotation components as such.
3.13 (non-normative) Simple Type Definition Details
NOTE:
This section reproduces a version of material from [XML Schemas: Datatypes], for local cross-reference purposes.
Simple type definitions provide for constraining character information item [children] of element and attribute
information items.
The simple type definition schema component has the following properties:
Simple types are identified by their {name} and {target namespace}. Except
for anonymous simple types (those with no {name}), since
type definitions (i.e. both simple and complex type definitions taken together) must be uniquely identified within an XML
Schema, no simple type definition can have the same name as another
simple or complex type definition. Simple type {name}s and {target namespace}s
are provided for reference from
instances (see xsi:type (§2.6.1)), and for use in the XML Representation of Schemas and Schema Components (§4)
(specifically in element and attribute). See References to schema components across namespaces (§6.2.2) 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 or list type as defined by [XML Schemas: Datatypes].
As described in Type Definition Hierarchy (§2.2.1.1), every atomic simple type definition is
a restriction of some other simple
{base type definition}, which is itself either a simple type
definition or the ur-type definition. Each
atomic type is ultimately a restriction of exactly one built-in simple {primitive type definition}.
{facets} for each atomic simple type definition are selected from those defined in
[XML Schemas: Datatypes] 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 types validate whitespace separated tokens, each of
which conforms to the specified {base type definition}. The base type specified
must not itself be a list type, and must be one of the types identified in [XML Schemas: Datatypes] as a
suitable base for a list simple type.
NOTE:
Careful readers will observe that the above specification of list types conflicts
with the claim in
Type Definition Hierarchy (§2.2.1.1) that all simple types are restrictions of
other simple types. This anomaly has no effect on the validation of content.
Simple type definitions for all the built-in primitive datatypes, namely string, boolean, float,
double, decimal, timeInstant, timeDuration,
recurringInstant, binary, uri (see the Primitive
Datatypes section of [XML Schemas: Datatypes]), as well as for the
ur-type definition (as previously described), are present by definition in every schema. All
are in the XML Schema {target namespace} (namespace
URI http://www.w3.org/1999/XMLSchema), have an atomic {variety} with an empty
{facets} and the ur-type definition as
their {base type definition} and themselves as {primitive type definition}.
Similarly, simple type definitions for all the built-in derived
datatypes (see the Derived
Datatypes section of [XML Schemas: Datatypes]) are present by definition in every schema, with
properties as specified in [XML Schemas: Datatypes] and as represented in XML in
(normative) Schema for Schemas (§A).
therein.
There is no separate ur-Type for simple types. As discussed in
Type Definition Hierarchy (§2.2.1.1), the ur-type definition functions as a simple type when used as the base type definition for a simple type.
Validation Contribution: String Valid
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
(normative) Schema for Schemas (§A) and (normative) DTD for Schemas (§B)) 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/1999/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.
Throughout the following sections, when we specify that a particular
property
of a schema component corresponds to the lexical [value] of some attribute information item or the [children] of some element information item,
the value in question is understood to be based on a string consisting of the list, in order, of the
[character code] of each character information item in the [children] of that
attribute information item or in the [children] of that element information
item respectively, that string then being interpreted as appropriate to the
defined type of the property in question.
When we say that a numeric-valued property of a schema component
corresponds to the lexical [value] of some attribute information item, the number in
question is understood to be the base 10 interpretation of the string described above.
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.2).
XML Representation Summary:
schema Element Information Item |
|
<schema
attributeFormDefault = qualified | unqualified : unqualified
blockDefault = #all or (possibly empty) subset of {equivClass,
extension, restriction} : ''
elementFormDefault = qualified | unqualified : unqualified
finalDefault = #all or (possibly empty) subset of {extension,
restriction} : ''
id = ID
targetNamespace = uriReference
version = string>
Content: ((include | import | annotation)* , ((simpleType | complexType | element | group | attribute | attributeGroup | notation) , 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.2). |
| {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.2). |
| {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.2). |
| {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.2). |
| {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.2). |
| {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.2). |
| {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.
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/1999/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.2)) from an external schema (which may,
but need not, correspond to an actual schema document). The form
of all such references is a
QName. 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/1999/XMLSchema"
xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns="http://www.foo.com"
targetNamespace="http://www.foo.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.2) for a discussion of importing. |
|
Schema Representation Constraint: QName Interpretation
Where the type of an attribute information item in a document involved in
schema validation is
identified as
QName, its value is uniformly
interpreted as consisting of a
[Definition:] local name consisting of the character information items after the colon, if any, otherwise all the character information items, in the lexical [value], and of a
[Definition:] namespace URI, derived from its lexical [value] and the containing element information item's [in-scope namespaces] as follows:
In the absence of the non-core properties
[in-scope namespaces] and/or
[namespace URI] from the infoset for the schema document in question, processors must reconstruct equivalent information as necessary, using the
[declared namespaces] of the containing element information item and its ancestors in the first case and using the namespace declaration in question's
[children] in the second.
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 lexical [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
(normative) Schema for Schemas (§A) and (normative) DTD for Schemas (§B).
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
occurrence and 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 = default | fixed | optional | prohibited | required : optional
value = string>
Content: (annotation? , simpleType?)
</attribute>
|
|
If the attribute element information item has schema as its parent, the corresponding schema component is as follows:
|
|
|
|
otherwise if the attribute element information item has
complexType or attributeGroup as an ancestor
and the ref [attribute] is absent the corresponding schema
component is an attribute declaration as follows (unless use='prohibited', in which case the item
corresponds to no component at all)
|
| Attribute Declaration Schema Component |
| Property | Representation |
| {name} | The lexical [value] of the name [attribute] |
| {target namespace} | If form is present and its
lexical [value] is qualified, or if form is absent and the
lexical [value] of attributeFormDefault on the schema
ancestor is qualified, then the lexical [value] of the
targetNamespace [attribute] of the parent schema
element information item, or absent if there
is none, otherwise absent. |
| {simple 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 lexical [value] of the type [attribute], if present, otherwise the
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. |
| {min occurs} | Depending on the lexical [value] of the use
[attribute], as follows:
| 1 |
If it is required, then 1
|
| 2 |
Otherwise (it is absent, optional, default or
fixed or prohibited), then 0
|
. |
| {max occurs} | Depending on the lexical [value] of the use
[attribute], as follows:
| 1 |
If it is prohibited, then 0
|
| 2 |
Otherwise (it is absent, optional, default,
fixed or required), then 1
|
. |
| {value constraint} | If there is no value
[attribute], then absent, otherwise a pair consisting of the lexical [value] of that [attribute] and
default, if the lexical [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), the corresponding schema component is as
follows (unless use='prohibited', in which case the item
corresponds to no component at all), where G means the (global) attribute declaration resolved to by the
lexical [value] of the ref [attribute]: |
| Attribute Declaration Schema Component |
| Property | Representation |
| {name} | The {name} of G |
| {target namespace} | The {target namespace} of G |
| {scope} | global |
| {simple type definition} | The {simple type definition} of G |
| {min occurs} | Depending on the lexical [value] of the use
[attribute], as described above |
| {max occurs} | Depending on the lexical [value] of the use
[attribute], as described above |
| {value constraint} | If there is no value
[attribute] and G has no {value constraint}, then
absent, otherwise a pair consisting of the
lexical [value] of that [attribute] if present, otherwise the {value constraint} of G, and
default, if the lexical [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. |
|
|
Attribute declarations can appear at the top level of a schema document, or within complex
types, either as complete (local) declarations, or by reference to top-level
declarations. 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 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="dt:integer" use="required"/>
<xs:attribute name="anotherAttribute" use="default" value="42">
<xs:simpleType base="dt:integer">
<xs:minExclusive value="0"/>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="stillAnotherAttribute" type="dt: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 not schema, then
| 1.1.1 |
One of ref or name must be present, but not both;
|
| 1.1.2 |
If ref is present, then both of
simpleType and type must be absent;
|
|
| 1.2 |
type and simpleType must not both be present;
|
| 1.3 |
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 or (possibly empty) subset of {equivClass,
extension, restriction} : ''
default = string
equivClass = QName
final = #all or (possibly empty) subset of {extension,
restriction} : ''
fixed = string
form = qualified | unqualified
id = ID
maxOccurs = string
minOccurs = nonNegativeInteger : 1
name = NCName
nullable = boolean : false
ref = QName
type = QName>
Content: (annotation? , (simpleType | complexType)? , (unique | key | keyref)*)
</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 lexical [value] of the name [attribute] |
| {target namespace} | The lexical [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 lexical [value] of the type [attribute], otherwise the {type definition} of the element declaration resolved to by the lexical [value] of the equivClass [attribute], if present, otherwise the
ur-type definition. |
| {nullable} | The lexical [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 lexical [value] 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 |
| {equivalence class affiliation} | the element declaration resolved to by the
value of the
equivClass [attribute], if present, otherwise absent |
| {disallowed substitutions} | A set corresponding to the normalised lexical [value] of the
block [attribute], if present, otherwise on the lexical [value] of the
blockDefault [attribute] of the parent schema element
information item, if present, otherwise on the empty string, as follows:
-
the empty string
-
the empty set;
-
#all
-
{equivClass, 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
whitespace-delimited substring.
|
| {equivalence class 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 lexical [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):
|
|
|
|
Let G be the global element declaration resolved to by the
value of the ref [attribute]
|
| Element Declaration Schema Component |
| Property | Representation |
| {name} | The {name} of G |
| {target namespace} | The {target namespace} of G |
| {scope} | global |
| {type definition} | The {type definition} of G |
| {nullable} | The lexical [value] of the nullable
[attribute], if present, otherwise the {nullable} of G |
| {value constraint} | If there is a default or a fixed
[attribute], then a pair consisting of the lexical [value] of that [attribute] and
either default or fixed, as appropriate, otherwise the {value constraint} of G |
| {identity-constraint definitions} | If there are any key, among the [children], then a set of identity-constraint definitions as in the first case above, otherwise the {identity-constraint definitions} of G |
| {equivalence class affiliation} | absent (not used) |
| {equivalence class exclusions} | false (not used) |
| {disallowed substitutions} | If the block [attribute] is present,
then a value as for {disallowed substitutions} above, otherwise the {disallowed substitutions} of G |
| {abstract} | The {abstract} of G |
| {annotation} | The annotation corresponding to the annotation element information item in the
[children], if present, otherwise absent |
|
|
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}.
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 exemplar of its equivalence class if it
identifies one, otherwise the ur-type definition.
See below at XML Representation of Identity-constraint Definition Schema Components (§4.3.8) for key, unique and keyref.
| Example |
<xs:element name="myelement" type="mySimpleType"/>
<xs:element name="et0" type="myComplexType"/>
<xs:element name="et1">
<xs:complexType>
<xs:element ref="et0"/>
. . .
<xs:attribute ...>. . .</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="et2">
<xs:complexType content="empty">
<xs:attribute ...>. . .</xs:attribute>
</xs:complexType>
</xs:element>
|
|
| The first two examples above declare elements by reference to a simple and a
complex type definition respectively. The third and fourth 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:element name="myLocalelement" type="myFirstType"/>
<xs:element ref="globalelement"/>
</xs:complexType>
</xs:element>
<xs:element name="contextTwo">
<xs:complexType>
<xs:element name="myLocalelement" type="mySecondType"/>
<xs:element ref="globalelement"/>
</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 |
<complexType name="facet" base="annotated" derivedBy="extension">
<attribute name="value" minOccurs="1"/>
</complexType>
<element name="facet" type="facet" abstract="true"/>
<element name="encoding" equivClass="facet">
<complexType base="facet" derivedBy="restriction">
<attribute name="value" type="encodings"/>
</complexType>
</element>
<element name="period" equivClass="facet">
<complexType base="facet" derivedBy="restriction">
<attribute name="value" type="timeDuration"/>
</complexType>
</element>
<complexType name="datatype">
<element ref="facet" minOccurs="0" maxOccurs="unbounded"/>
<attribute name="name" type="NCName" minOccurs="0">
. . .
</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 exemplar for a class. Two further
elements are declared, each a member of the facet equivalence
class. Finally a type is defined which refers to facet, thereby
allowing either period or encoding (or
any other member of the class). |
|
Schema Representation Constraint: Element Declaration Representation OK
In addition to the conditions imposed on
element element
information items by the DTD and schema for schemas, the following must also hold:
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 correspondences between the
properties of the information item and
properties of the component(s) it corresponds to are as follows:
XML Representation Summary:
complexType Element Information Item |
|
<complexType
abstract = boolean : false
base = QName
block = #all or (possibly empty) subset of {extension,
restriction}
content = elementOnly | empty | mixed | textOnly
derivedBy = extension | restriction
final = #all or (possibly empty) subset of {extension,
restriction}
id = ID
name = NCName>
Content: (annotation? , (((minExclusive | minInclusive | maxExclusive | maxInclusive | precision | scale | length | minLength | maxLength | encoding | period | duration | enumeration | pattern)* | (element | group | all | choice | sequence | any)*) , ((attribute | attributeGroup)* , anyAttribute?)))
</complexType>
|
|
<attributeGroup
id = ID
ref = QName>
Content: (annotation?)
</attributeGroup>
|
|
<anyAttribute
id = ID
namespace = ##any | ##other | ##local | list of {uri, ##targetNamespace} : ##any>
Content: (annotation?)
</anyAttribute>
|
| Complex Type Definition Schema Component |
| Property | Representation |
| {name} | The lexical [value] of the name [attribute] if present, otherwise absent |
| {target namespace} | The lexical [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
value of the base [attribute], if present, otherwise the simple
ur-type definition if the
content [attribute] is textOnly, otherwise the complex ur-type definition |
| {derivation method} | If the derivedBy [attribute]
is present, the member of the set {extension, restriction} corresponding to its value, otherwise restriction |
| {abstract} | The lexical [value] of the abstract
[attribute], if present, otherwise false |
| {attribute declarations} | The union of the set of attribute
declarations corresponding to
|
| {attribute wildcard} |
|
| {content type} |
| 1 | If the content [attribute] is empty,
then empty; |
| 2 | otherwise if the base [attribute] is present, the type definition resolved to by the
value of the base [attribute] is a complex type definition whose own {content type} is a
simple type definition and the derivedBy [attribute] is restriction, then
a simple type definition which restricts that simple type definition with the
facets corresponding to the minExclusive, minInclusive, maxExclusive, maxInclusive, precision, scale, length, minLength, maxLength, encoding, period, enumeration and pattern [children], if any, as
defined in Simple Type Restriction (Facets) (§4.3.11); |
| 3 |
otherwise if the base [attribute] is present, the type definition resolved to by the
value of the base [attribute] is a simple type definition and
the derivedBy [attribute] is extension, then
that simple type definition;
|
| 4 |
otherwise if the content [attribute] is
elementOnly or mixed, a pair of that value and a particle
as follows:
[Definition:] Let the explicit particle be as follows:
otherwise
otherwise
The actual value then depends on the derivedBy
[attribute] as follows:
|
| 5 | otherwise (the content [attribute] is
textonly but there is no base [attribute]) the simple
ur-type definition |
|
| {prohibited-substitutions} | A set corresponding to the normalised value of the
block [attribute], if present, otherwise on the lexical [value] of the
blockDefault [attribute] of the parent 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
whitespace-delimited substring.
NOTE:
Although the blockDefault [attribute] of schema may include the value equivClass, 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] |
| {annotation} | The annotation corresponding to the annotation element information item in the
[children], if present, otherwise absent |
|
|
Given the constraints on its appearance in content models, if an all occurs in the [children], it must make up the entire {content type}: see Model Group Constraints (§5.7).
Schema Representation Constraint: Complex Type Definition Representation OK
In addition to the conditions imposed on
complexType element
information items by the DTD and schema for schemas, the following must also hold:
| 1.1 |
derivedBy is required if base is present;
|
| 1.2 |
Element information items corresponding to particles (element, any, group, all, choice, sequence) are only allowed in the [children] if the base attribute is either absent or its value resolves to a complex type definition whose {content type} is not a simple type definition;
|
| 1.3 |
Element information items corresponding to facets (minExclusive, minInclusive, maxExclusive, maxInclusive, precision, scale, length, minLength, maxLength, encoding, period, enumeration, pattern) are only allowed in the [children] if the derivedBy [attribute] is restriction and the lexical [value] of the base [attribute] resolves to a complex type definition whose {content type} is a simple type definition;
|
| 1.4 |
Element information items corresponding to attribute declarations or
attribute wildcards (attribute, attributeGroup,
anyAttribute) are only allowed in the [children] if either
or
| 1.4.2 |
the
derivedBy [attribute] is restriction and the base attribute is either absent or its value resolves to a complex type definition whose {content type} is not a simple type definition;
|
|
| 1.5 |
The corresponding complex type definition component must satisfy the conditions set
out in Complex Type Definition Constraints (§5.11).
|
| 1.6 |
If clause 2 in the correspondence specification above for {attribute wildcard} obtains, the intensional intersection must be expressible, as defined in Attribute Wildcard Intersection (§5.4).
|
NOTE:
Aside from the simple coherence requirements enforced above, constraining
type definitions identified as restrictions to actually be
restrictions, that is, to schema-validate a subset of the what is
schema-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 need consist of no more than a name, i.e. that
<complexType name="anything"/> is allowed. In this case the type
definition constructed is taken to be derived by restriction from the ur-type definition.
| Example |
<xs:complexType name="length1" base="dt:non-negative-integer" derivedBy="extension"/>
<xs:attribute name="unit" type="dt:NMTOKEN"/>
</xs:complexType>
<xs:element name="width" type="length1"/>
<width unit="cm">2.54</width>
<xs:complexType name="length2">
<xs:element name="size" type="dt:non-positive-integer"/>
<xs:element name="unit" type="dt:NMTOKEN"/>
</xs:complexType>
<xs:element name="depth" type="length2"/>
<depth>
<size>2.54</size><unit>cm</unit>
</depth>
|
|
|
Two 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 using two
elements.
|
|
| Example |
<xs:complexType name="personName">
<xs:element name="title" minOccurs="0"/>
<xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>
</xs:complexType>
<xs:complexType name="extendedName" base="personName" derivedBy="extension">
<xs:element name="generation" minOccurs="0"/>
</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" base="personName" derivedBy="restriction">
<xs:element name="title" maxOccurs="0"/>
<xs:element name="forename" minOccurs="1" maxOccurs="1"/>
<xs:element name="surname"/>
</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. |
|
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:
XML Representation Summary:
attributeGroup Element Information Item |
|
<attributeGroup
id = ID
name = NCName
ref = QName>
Content: (annotation? , (attribute | attributeGroup)* , anyAttribute?)
</attributeGroup>
|
|
When an attributeGroup appears as a daughter of
schema, it corresponds to an attribute group definition as
below. When it appears as a daughter of complexType or attributeGroup, it does not correspond to any component as such.
|
| Attribute Group Definition Schema Component |
| Property | Representation |
| {name} | The lexical [value] of the name [attribute] |
| {target namespace} | The lexical [value] of the
targetNamespace [attribute] of the parent schema
element information item. |
| {attribute declarations} | The union of the set of attribute
declarations corresponding to the attribute [children] of the
item, if any, with the {attribute declarations} of the
attribute groups resolved to by the lexical [value]s of the ref
[attribute] of the attributeGroup [children], if any. In
the latter case, if the {target namespace} of any referenced
group is not identical to the {target namespace} of this
group definition, the attribute declarations are not the attribute declarations
from the corresponding {attribute declarations} as such, but
distinct attribute declarations sharing all properties with them except for
{target namespace}, which has the value of {target namespace} from their original containing group. |
| {attribute wildcard} | As for {attribute wildcard} as described in XML Representation of Complex Type Definition Schema Components (§4.3.3), except that clause 1.2 is irrelevant and cannot obtain |
| {annotation} | The annotation corresponding to the annotation element information item in the
[children], if present, otherwise absent |
|
|
| Example |
<xs:attributeGroup name="myAttrGroup">
<xs:attribute .../>
...
</xs:attributeGroup>
<xs:complexType name="myelement" content="empty">
<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 DTD and schema for schemas, the following must also hold:
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 = string
minOccurs = nonNegativeInteger : 1
name = NCName
ref = QName>
Content: (annotation? , (element | group | all | choice | sequence | any)*)
</group>
|
|
If there is a name [attribute] (in which case the
item will have schema as parent), then the item corresponds to
a model group definition component with properties as follows:
|
| Model Group Definition Schema Component |
| Property | Representation |
| {name} | The lexical [value] of the
name [attribute] |
| {target namespace} | The lexical [value] of the
targetNamespace [attribute] of the parent schema
element information item. |
| {model group} | A model group, as follows:
| 1 |
If there is exactly one all, choice, group or
sequence among the [children], that item has
{min occurs}={max occurs}=1 and there are no any or
element [children], then the {term} of a
particle corresponding to that all, choice, group or
sequence;
|
| 2 |
otherwise a model group whose {compositor} is
sequence and whose {particles} is the sequence of particles
corresponding to all the choice,
sequence, any,
group or element items among the [children],
in order.
|
|
| {annotation} | The annotation corresponding to the annotation element information item in the
[children], if present, otherwise absent |
|
|
|
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:group ref="myModelGroup"/>
<xs:attribute .../>
</xs:complexType>
<xs:complexType name="moreSo">
<xs:choice>
<xs:element ref="anotherThing"/>
<xs:group ref="myModelGroup"/>
</xs:choice>
<xs:attribute .../>
</xs:complexType>
|
|
| 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 DTD and schema for schemas, the following must also hold:
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 DTD and 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 = string
minOccurs = nonNegativeInteger : 1
namespace = ##any | ##other | ##local | list of {uri, ##targetNamespace} : ##any
processContents = lax | skip | strict : strict>
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 lexical [value] of the
namespace [attribute]: if absent, then any, otherwise as follows:
-
##any
-
any
-
##other
-
a pair of not and the lexical [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
whitespace-delimited substrings of the string, except
| 1 |
if one such
substring is ##targetNamespace, the corresponding member is the lexical [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 lexical [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 DTD and 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 (normative) Schema for Schemas (§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:element name="stateCode" type="twoLetterCode"/>
<xs:element name="vehicle">
<xs:complexType>
. . .
<xs:attribute name="regNo" type="dt:integer"/>
</xs:complexType>
</xs:element>
. . .
</xs:complexType>
</xs:element>
<xs:element name="root"
. . .
<xs:key name="regKey">
<xs:selector>.//vehicle[@regNo]</xs:selector>
<xs:field>@regNo</xs:field>
<xs:field>ancestor::state/stateCode</xs:field>
<!-- scope needs to be involved -->
</xs:key>
</xs:element>
<xs:element name="person">
<xs:complexType>
. . .
<xs:element name="car">
<xs:complexType model="empty">
. . .
<xs:attribute name="regRef" type="dt:integer"/>
<xs:attribute name="regState" type="twoLetterCode"/>
</xs:complexType>
</xs:element>
</xs:complexType>
<xs:keyref name="carRef" refer="regKey">
<xs:selector>.//car[@regRef]</xs:selector>
<xs:field>@regRef</xs:field>
<xs:field>@regState</xs:field>
</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 DTD and 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:
| Example |
<xs:notation name="jpeg"
public="image/jpeg" system="viewer.exe" />
<xs:element name="picture">
<xs:complexType base="dt:binary" derivedBy="extension">
<xs:attribute name="pictype" type="dt:NOTATION"/>
</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 DTD and 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 DTD and 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.
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:
| 1.1 |
The {base type definition} of R is the same
as that of B;
|
| 1.2 |
The {variety} of R is the same as that of R;
|
| 1.3 |
For each facet in the {facets} of B, there is a
a facet of the same kind in R, which is the facet of the same kind in S, if
there is one, otherwise a facet of the same kind whose {value} is the
{value} of the facet of the same kind in the {facets} of
B and whose {annotation} is absent.
|
6 Schema Access and Composition
This chapter defines the mechanisms by which we establish the necessary precondition for establishing schema-validity, namely access to one or more schemas. This chapter also describes in detail related mechanisms for using in
one schema, definitions and declarations from another.
Conformance (§2.4) describes three levels of conformance for schema
processors, and Validation Processing of schemas and documents (§7) provides a formal definition of schema-validation. Here we set out
in detail the 3-layer architecture implied by the three conformance levels.
The layers
are:
- The schema-validation core, relating schema components and instance
information items;
- Schema representation: the connections between XML
representations and schema components, including the
relationships between namespaces and schema components;
- XML Schema web-interoperability guidelines: instance->schema and
schema->schema connections for the WWW.
Layer 1 specifies the manner in which a schema composed of schema components
can be applied to validate an instance element information item. Layer 2, which is
primarily defined in XML Representation of Schemas and Schema Components (§4), specifies the use of schema
elements in XML documents as the standard XML representation for
schema information in a broad range of computer systems and execution
environments. To support interoperation over the World Wide Web in particular,
layer 3 provides a set of conventions for schema reference on the
Web. Additional details on each of the three layers is provided in the sections below.
6.1 Layer 1: Summary of the schema-validation core
The fundamental purpose of the schema-validation core is to define schema-validatity for a single
element information item and its descendants with respect to a
complex type
definition. All processors are required to implement this core predicate in a
manner which conforms exactly to this specification.
Schema-validity is defined with reference to an XML Schema (note not a
schema document) which consists of (at a minimum) the set of schema
components (definitions and declarations) required for that
validation. This is not a circular definition, but rather a
post facto observation: no element information item can
be fully schema-valid unless all the components required by any aspect of
its (potentially recursive) validation are present in the schema.
As specified above, each schema component is associated directly or
indirectly with a target namespace, or explicitly with no namespace. In the case of multi-namespace documents,
components for more than one target namespace will co-exist in a schema.
Processors have the option to assemble (and perhaps to optimise or pre-compile) the entire schema prior to the start of a validation episode, or to
gather the schema lazily as individual components are required. In all
cases it is required that:
- The processor succeed in locating the schema components
transitively required to complete a validation (note that components derived
from schema documents can be integrated
with components obtained through other means);
- no definition or declaration changes once it has been established;
- if the processor chooses to acquire declarations and definitions
dynamically, that there be no side effects of such dynamic acquisition that
would cause the results of validation to differ from that which would have
been obtained from the same schema components acquired in bulk.
NOTE: the validation core is defined in terms of schema components at the
abstract level, and no mention is made of the schema definition
syntax (i.e. schema). Although many processors will acquire
schemas in this format, others may operate on compiled representations, on a
programmatic representation as exposed in some programming language, etc.
The obligation of a schema-aware processor as far as the schema-validation
core is concerned is to implement the definitions of schema-valid given below in Schema Validation of Documents (§7.2). Neither the
choice of element information item to be schema-validated, nor which of three
means of initiating validation are used, is within the scope of this specification.
Although assessing schema-validity is defined recursively, it is also intended to be
implementable in streaming
processors. Such processors may choose to incrementally assemble the schema during
processing in response, for example, to encountering new namespaces.
The implication of the
invariants expressed above is that such incremental assembly must result in a validation
outcome that is the
same as would
be given if schema-validity was re-assessed
with the final, fully assembled schema.
6.2 Layer 2: Schema definitions in XML
XML Representation of Schemas and Schema Components (§4) defines an
XML representation for type definitions and element declarations and so on,
specifying their target namespace and collecting them into schema documents.
The two following sections relate to assembling a complete schema for validation from multiple sources. They should not be understood as a form of text substitution, but rather as providing mechanisms for distributed definition of schema components, with appropriate schema-specific semantics.
NOTE: The core validation architecture requires that a complete schema with
all the necessary declarations and definitions be
available. This may involve resolving both
instance->schema and schema->schema references. As observed earlier in Conformance (§2.4),
we anticipate
that the precise mechanisms for resolving such references will evolve over time.
In support of such evolution, we have attempted to observe the design principle that references from
one schema document to another schema use mechanisms that directly parallel those used to
reference a schema from an instance document.
NOTE: In the sections below, "schemaLocation" really belongs at layer 3.
For convenience, we document it with the layer 2 mechanisms of import and
include, with which it is closely associated.
6.2.1 Assembling a schema for a single target namespace from multiple schema definition documents
Schema components for a single target namespace can be assembled from
several schema documents, that is several schema element
information items:
A schema information item may contain any number of include elements. Their schemaLocation attributes, consisting of a URI reference, identify other schema documents, that is schema information items.
The XML Schema corresponding
to schema then
consists of all the components its [children] correspond to and
all the components of all the XML Schemas corresponding to those included schema documents.
Such included components must either (a) have the same
targetNamespace as the includeing schema document, or
(b) no targetNamespace at all, in which case all the top-level
included components are converted to the includeing schema document's targetNamespace.
Schema Representation Constraint: Inclusion Constraints and Semantics
In addition to the conditions imposed on
include element
information items by the DTD and schema for schemas, the following must also hold:
| 1.1 |
If the lexical [value] of the schemaLocation [attribute]
successfully resolves, it resolves either
| 1.1.1 |
to (a fragment of) a resource of type
text/xml, which in turn corresponds to a schema
element information item in a well-formed information set, which in turn
corresponds to a valid schema
|
or
| 1.1.2 |
to a schema
element information item in a well-formed information set, which in turn
corresponds to a valid schema.
|
In either case call the schema item SII and the valid schema I.
|
| 1.2 |
The targetNamespace of SII is either
or
| 1.2.2 |
identical to the targetNamespace of the include
item's parent schema.
|
|
It is
not an error for the lexical
[value] of the
schemaLocation [attribute] to fail to resolve it all, in which case no
corresponding inclusion is performed. It
is an error for it to resolve but the rest of clause 1.1 above to
fail to obtain. Failure to resolve may well cause less than complete
schema-validation outcomes, of course.
The
schema components (that is
{type definitions} {attribute declarations},
{element declarations},
{attribute group definitions},
{model group definitions},
{notation declarations}) of a schema corresponding to a
schema element information item with one or more
include element information items must include not only definitions or declarations corresponding to the appropriate members of its
[children], but also, for each of those
include element information items for which clause 1.1 above obtains successfully, a set of components identical to all the
schema components of
I (if clause 1.2.2 above obtains), or identical in all respects except their
{target namespace}, which is that of the
includeing
schema (if clause 1.2.1 above obtains).
NOTE: The above is carefully worded so that multiple includeing of the same schema document will not constitute a violation of
clause 2 of Schema Properties Correct (§5.13), but applications are
allowed, indeed encouraged, to avoid includeing the same schema document more than once to forestall the necessity of establishing identity
component by component.
6.2.2 References to schema components across namespaces
As described in XML Schema Abstract Data Model (§2.2), every global schema component is associated with
a target namespace (or, explicitly, with none). In this section we set out
the exact mechanism and syntax in the XML form of
schema definition by which a reference to a foreign component is made, that is, a component with a different target namespace from that of the referring component.
We require not only a means
of addressing such foreign components but also a signal to schema-aware processors that a
schema document contains such references:
The import element information item identifies namespaces
used in external references, i.e. those whose
QName identifies them as coming from a
different namespace (or none) than the enclosing schema document's
targetNamespace. The lexical [value] of its namespace
[attribute] indicates that the containing schema document may contain
qualified references to schema components in that namespace (via one or more
prefixes declared with namespace declarations in the normal way). If that
attribute is absent, then the import allows unqualified reference to components
with no target namespace.
Note that components to be imported need not be in the form of a
schema document; the processor
is free to access or construct components using means of its own
choosing.
The
lexical [value] of the schemaLocation, if present, gives a
hint as to where a schema document with declarations and definitions for that
namespace (or none) may be found. When no
schemaLocation [attribute] is present, the schema author is leaving the
identification of that schema to the instance, application or user, via the mechanisms described
below in Layer 3: Web-interoperability (§6.3). When a schemaLocation is present, it
must contain a single URI reference which the schema author
warrants will resolve to a schema document containing the component(s) in the
imported namespace referred to elsewhere in the containing
schema document.
NOTE:
Since both the namespace and schemaLocation
[attribute] are optional, a bare <import/> information item
is schema-valid. This simply allows unqualified reference to foreign
components without giving any hints as to where to find them.
| Example |
| We may use the same namespace both for real work, and in the course of
defining schema components in terms of foreign components: |
<schema xmlns="http://www.w3.org/1999/XMLSchema"
xmlns:html="http://www.w3.org/1999/xhtml"
targetNamespace="uri:mywork" xmlns:my="uri:mywork">
<import namespace="http://www.w3.org/1999/xhtml"/>
<annotation>
<documentation
<html:p>[Some documentation for my schema]</html:p>
</documentation>
<annotation>
. . .
<complexType name="myType">
<element ref="html:p" minOccurs="0"/>
. . .
</complexType>
<element name="myElt" type="my:myType"/>
</schema>
|
|
| The treatment of references as QNames implies that since (with the exception of
the schema for schemas) the target namespace and the XML Schema namespace
differ, without massive redeclaration of the default namespace
either internal references to the names being defined in a schema document
or the schema declaration and definition elements themselves must
be explicitly qualified. This example takes the first option -- most other
examples in this specification have taken the second. |
|
Schema Representation Constraint: Import Constraints and Semantics
In addition to the conditions imposed on
import element
information items by the DTD and schema for schemas, the following must also hold:
| 1.1 |
If the application schema reference strategy using the lexical [value]s of
the schemaLocation and namespace [attributes],
provides a referent, as defined by Schema Document Location Strategy (§6.3.2), it is
either
| 1.1.1 |
(a fragment of) a resource of type
text/xml, which in turn corresponds to a schema
element information item in a well-formed information set, which in turn
corresponds to a valid schema
|
or
| 1.1.2 |
a schema
element information item in a well-formed information set, which in turn
corresponds to a valid schema.
|
In either case call the schema item SII and the valid schema I.
|
| 1.2 |
The targetNamespace of SII is identical to the lexical [value] of the
namespace [attribute]
|
It is
not an error for the application schema reference
strategy to fail. It
is an error for it to resolve but the rest of clause 1.1 above to
fail to obtain. Failure to find a referent may well cause less than complete
schema-validation outcomes, of course.
The
schema components (that is
{type definitions} {attribute declarations},
{element declarations},
{attribute group definitions},
{model group definitions},
{notation declarations}) of a schema corresponding to a
schema element information item with one or more
import element information items must include not only definitions or declarations corresponding to the appropriate members of its
[children], but also, for each of those
import element information items for which clause 1.1 above obtains successfully, a set of
schema components identical to all the
schema components of
I.
NOTE: The above is carefully worded so that multiple importing of the same schema document will not constitute a violation of
clause 2 of Schema Properties Correct (§5.13), but applications are
allowed, indeed encouraged, to avoid importing the same schema document more than once to forestall the necessity of establishing identity
component by component.
6.3 Layer 3: Web-interoperability
Layers 1 and 2 provide a framework for validation and XML definition of schemas in a broad variety of environments. Over time, we expect that a range
of standards and conventions will evolve to support interoperability of XML
Schema implementations on the World Wide Web. Layer 3 defines the minimum level
of function required of all conformant processors operating on the Web:
it is intended that, over time, future standards (e.g. XML Packages) for interoperability on the
Web and in other environments can be introduced without the need to republish
this specification.
6.3.1 Standards for representation of schemas and retrieval of schema documents on the Web
For interoperability, schema documents like all other Web resources may be identified by
URI and retrieved using the standard mechanisms of the Web (e.g. http, https,
etc.) Schema documents on the Web must be part of documents with the mime type text/xml, and are represented in the
standard XML schema definition form described by layer 2 (that is as schema
element information items).
NOTE: there will often be times when a schema document will be a
complete XML 1.0 document whose document element is schema. There will be
other occasions in which schema items will be contained in other
documents, perhaps referenced using fragment and/or Xpointer notation.
6.3.2 How schema definitions are located on the Web
As described in Layer 1: Summary of the schema-validation core (§6.1), processors are responsible for providing the
schema components (definitions and declarations) needed for validation. This
section introduces a set of normative conventions to facilitate interoperability
for instance and schema documents retrieved and validated from the Web.
NOTE: As discussed above in Layer 2: Schema definitions in XML (§6.2), other non-Web mechanisms for delivering schemas for validation may exist, but are outside the scope of this recommendation.
Processors on the Web are free to assess schema-validity against arbitrary
schemas in any of the ways set out in Schema Validation of Documents (§7.2). However, it
is useful to have a common convention for determining the schema to use. For
this purpose, we require that for general-purpose schema-aware processors (i.e. those not
specialised to one or a fixed set of pre-determined schemas) validating a document on the web:
-
unless directed otherwise by the user, validation is performed on the document
element information item of the specified document;
-
unless directed otherwise by a user, the
processor is required to construct a schema corresponding to a schema document
whose
targetNamespace is
identical to the
namespace URI, if any, of the element information item to be
validated.
The composition of the complete
schema for use in assessing schema-validity is discussed in Layer 2: Schema definitions in XML (§6.2) above.
The means used to locate appropriate schema document(s) are processor and
application dependent, subject to the following requirements:
- Schemas are represented on the Web in the form specified above in Standards for representation of schemas and retrieval of schema documents on the Web (§6.3.1);
- The author of a document uses namespace declarations to indicate the intended
interpretation of names appearing therein; there may or may not be a schema
retrievable via the namespace URI. Accordingly whether a processor's default
behaviour is or is not to attempt such dereferencing, it must always provide
for user-directed overriding of that default.
NOTE: Experience suggests that it is not in all cases safe or desirable from
a performance point of view to dereference NS URIs as a matter of course. User community and/or
consumer/provider agreements may establish circumstances in which such dereference is a sensible
default strategy: this recommendation allows but does not require particular communities to
establish and implement such conventions. Users are always free to supply namespace URIs as schema location information when dereferencing is desired: see below.
-
On the other hand, in case a document author (human or not) created a
document with a particular schema in view, and warrants that some or
all of the document is schema-valid per that schema, we provide the
schemaLocation and noNamespaceSchemaLocation [attributes] (in the XML Schema instance namespace,
that is, http://www.w3.org/1999/XMLSchema-instance) (hereafter
xsi:schemaLocation and
xsi:noNamespaceSchemaLocation). The first records
the author's warrant with pairs of URI references (one for the namespace URI, and
one for a hint as to the location of a schema document defining names for that
namespace URI). The second similarly provides a URI reference as a hint as to
the location of a schema document with no targetNamespace [attribute].
Unless directed otherwise, for example by the invoking application
or by command line option, processors
should attempt to dereference each schema document location URI in the
lexical [value] of such
xsi:schemaLocation and xsi:noNamespaceSchemaLocation [attributes], see details below.
-
xsi:schemaLocation and xsi:noNamespaceSchemaLocation [attributes] can occur on any element,
and all such [attributes] must be processed as if they had occurred on the
element information item initially assessed for schema-validity. According to the rules of
Layer 1: Summary of the schema-validation core (§6.1), the corresponding schema may be lazily assembled, but is otherwise
stable throughout a validation. Although schema location attributes can occur
on any element, and can be processed incrementally as discovered, their effect
is essentially global to the validation. Definitions and declarations remain
in effect beyond the scope of the element on which the binding is declared.
| Example |
| Multiple schema bindings can be declared using a single
attribute. For example consider a stylesheet: |
<stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
xmlns:html="http://www.w3.org/1999/xhtml"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/1999/XSL/Transform
http://www.w3.org/1999/XSL/Transform.xsd
http://www.w3.org/1999/xhtml
http://www.w3.org/1999/xhtml.xsd">
|
|
The namespace URIs used in schemaLocation can, but need not
be identical to those actually qualifying the element within whose start tag
it is found or its other attributes. For example, as above, all
schema location information can be declared on the document element
of a document, if desired,
regardless of where the namespaces are actually used. |
|
Schema Representation Constraint: Schema Document Location Strategy
Given a namespace URI (or none) and (optionally) a URI reference from
xsi:schemaLocation or
xsi:noNamespaceSchemaLocation,
schema-aware processors may implement any combination of the following
strategies, in any order:
| 1.1 |
Do nothing, for instance because a schema containing components for the
given namespace URI is already known to be available, or because it
is known in advance that no efforts to locate schema documents will be successful
(for
example in embedded systems);
|
| 1.2 |
Based on the location URI,
identify an existing schema document,
either as a text/xml resource or a schema element
information item, in some local schema repository;
|
| 1.3 |
Based on the namespace URI, identify an existing schema document,
either as a text/xml resource or a schema element
information item, in some local schema repository;
|
| 1.4 |
Attempt to resolve the location URI,
to locate a
resource on the web which is or contains or references a schema element;
|
| 1.5 |
Attempt to resolve the namespace URI to locate such a resource.
|
Whenever possible configuration and/or invocation options for selecting and/or ordering
the implemented strategies should be provided.
We note that improved or alternative conventions for Web interoperability can
be standardised in the future without reopening this recommendation. For
example, the W3C is currently considering initiatives to standardise the
packaging of resources relating to particular documents and/or namespaces: this
would be an addition to the mechanisms described here for layer 3. This
architecture also facilitates innovation at layer 2: for example, it would be
possible in the future to define an additional standard for the representation of
schema components which allowed e.g. type definitions to be specified piece by
piece, rather than all at once.
7 Validation Processing of schemas and documents
The architecture of schema
validation allows for a rich characterisation of XML documents: schema validity is not a binary predicate.
We distinguish between errors in schema construction and structure, on the
one hand, and schema validation outcomes, on the other.
7.1 Errors in Schema Construction and Structure
Before schema validation can be attempted, a schema is required.
Special-purpose applications are free to determine a schema for use in validation by whatever
means are appropriate, but general purpose processors should implement the
strategy set out in Schema Document Location Strategy (§6.3.2), starting with the
namespaces declared in the document to be validated, and the lexical [value]s of the
xsi:schemaLocation and xsi:noNamespaceSchemaLocation
[attributes] thereof, if any.
It is an
error if a
schema and all the components which are the value of any of its properties,
recursively, fail to satisfy all the relevant Constraints on Schemas set out in
Schema Component Validity Constraints (§5).
If a schema is derived from one or more schema documents (that is, one or
more schema element information items) based on the
correspondence rules set out in XML Representation of Schemas and Schema Components (§4) and Schema Access and Composition (§6), two additional
conditions hold:
The three cases described above are the only types of error which this
specification defines. With respect to the processes of the checking of schema structure
and the construction of schemas corresponding to schema documents, this
specification imposes no restrictions on processors after an error is detected.
However schema-validity with respect to schema-like entities which do not
satisfy all the above conditions is incoherent. Accordingly, conformant
processors must not attempt to schema-validate using such non-schemas.
7.3 Missing Sub-components
At the beginning of Schema Component Details (§3), attention is drawn to the
fact that most kinds of schema components have properties which are described therein
as having other components, or sets of other components, as values, but that
when components are constructed on the basis of their correspondence with
element information items in schema documents, such properties usually
correspond to QNames, and the
resolution of such QNames may fail, resulting in one or more values of or containing absent where a component is mandated.
If at any time during schema-validation, schema-validity of an
information item is being assessed with respect to a component of any kind any of whose
properties has or contains such an absent value,
the schema-validation effort is modified, as following:
-
In the post-schema validation infoset, the [validation attempted] of the item has the value partial;
-
Schema-validation resumes attempting to satisfy clause 1.2.2 of
Element Valid (Lax) (§3.3), if the item is an element, or as if clause 1.2 of
Attribute Valid (Lax) (§3.2) obtained, it the item is an attribute.
Because of clause 1.2 of Validation Outcome (Element) (§3.3), if this situation ever arises, the
document as a whole will not show a [validation attempted]
of full, unless the problem arises within an area of lax validation
(see clause 1.2.3 of Item Valid (Wildcard) (§3.9)).
7.4 Responsibilities of Schema-aware processors
Schema-aware processors are responsible for processing XML documents,
schemas and schema documents, as appropriate given the level of conformance
(as defined in Conformance (§2.4)) they support,
consistently with the conditions set out above.
A (normative) Schema for Schemas
The XML Schema definition for XML Schema: Structures itself is presented here as normative
part of the specification, and as an illustrative example of the XML Schema in
defining itself with the very constructs that it defines. The names of XML
Schema language types, elements, attributes and groups defined here
are evocative of their purpose, but are occasionally verbose.
There is some annotation in comments, but a fuller annotation will require
the use of embedded documentation facilities or a hyperlinked external
annotation for which tools are not yet readily available.
Since an XML Schema: Structures is an XML document, it has optional XML and doctype
declarations that are provided here for completeness. The root
schema element defines a new schema. Since this is a schema for
XML Schema: Structures, the targetNamespace references the XML Schema namespace itself.
<?xml version='1.0'?>
<!-- XML Schema schema for XML Schemas: Part 1: Structures -->
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSCHEMA 19991216//EN" "XMLSchema.dtd" >
<schema xmlns="http://www.w3.org/1999/XMLSchema" targetNamespace="http://www.w3.org/1999/XMLSchema" blockDefault="#all" elementFormDefault="qualified" version="Id: XMLSchema.xsd,v 1.1 2000/04/06 13:51:05 aqw Exp">
<!-- The simpleType element and all of its members are defined
in XML Schema: Part 2: Datatypes -->
<include schemaLocation="part2.xsd"/>
<element name="schemaTop" abstract="true" type="annotated">
<annotation>
<documentation>This abstract element defines an equivalence class over the
elements which occur freely at the top level of schemas.
These are: datatype, type, element, attributeGroup, group, notation
All of their types are based on the "annotated" type
by extension.</documentation>
</annotation>
</element>
<!-- schema element -->
<simpleType name="formChoice" base="NMTOKEN">
<annotation>
<documentation>A utility type, not for public use</documentation>
</annotation>
<enumeration value="qualified"/>
<enumeration value="unqualified"/>
</simpleType>
<element name="schema">
<complexType base="openAttrs" derivedBy="extension" content="elementOnly">
<sequence>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="include"/>
<element ref="import"/>
<element ref="annotation"/>
</choice>
<sequence minOccurs="1" maxOccurs="unbounded">
<element ref="schemaTop"/>
<element ref="annotation" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</sequence>
<attribute name="targetNamespace" type="uriReference"/>
<attribute name="version" type="string"/>
<attribute name="finalDefault" type="derivationSet" use="default" value=""/>
<attribute name="blockDefault" type="blockSet" use="default" value=""/>
<attribute name="attributeFormDefault" type="formChoice" use="default" value="unqualified"/>
<attribute name="elementFormDefault" type="formChoice" use="default" value="unqualified"/>
<attribute name="id" type="ID"/>
</complexType>
<key name="element">
<selector>element</selector>
<field>@name</field>
</key>
<key name="attribute">
<selector>attribute</selector>
<field>@name</field>
</key>
<key name="type">
<selector>complexType|simpleType</selector>
<field>@name</field>
</key>
<key name="group">
<selector>group</selector>
<field>@name</field>
</key>
<key name="attributeGroup">
<selector>attributeGroup</selector>
<field>@name</field>
</key>
<key name="notation">
<selector>notation</selector>
<field>@name</field>
</key>
<key name="identityConstraint">
<selector>.//key|.//unique|.//keyref</selector>
<field>@name</field>
</key>
</element>
<!-- for all particles -->
<attributeGroup name="occurs">
<attribute name="minOccurs" type="nonNegativeInteger" use="default" value="1"/>
<attribute name="maxOccurs" type="string">
<annotation>
<documentation>allows 'unbounded', so integer won't do</documentation>
</annotation>
</attribute>
</attributeGroup>
<!-- for element, group and attributeGroup,
which both define and reference -->
<attributeGroup name="defRef">
<attribute name="name" type="NCName"/>
<attribute name="ref" type="QName"/>
</attributeGroup>
<!-- 'complexType' and 'group' use this -->
<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>
<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>
<complexType base="annotated" derivedBy="extension" name="attribute" abstract="true">
<element name="simpleType" minOccurs="0" type="localSimpleType"/>
<attributeGroup ref="defRef"/>
<attribute name="type" type="QName"/>
<attribute name="use" use="default" value="optional">
<simpleType base="NMTOKEN">
<enumeration value="prohibited"/>
<enumeration value="optional"/>
<enumeration value="required"/>
<enumeration value="default"/>
<enumeration value="fixed"/>
</simpleType>
</attribute>
<attribute name="value" use="optional" type="string"/>
<attribute name="form" type="formChoice"/>
</complexType>
<complexType name="topLevelAttribute" base="attribute" derivedBy="restriction">
<element ref="annotation" minOccurs="0"/>
<element name="simpleType" minOccurs="0" type="localSimpleType"/>
<attribute name="ref" use="prohibited"/>
<attribute name="form" use="prohibited"/>
<attribute name="use" use="prohibited"/>
<attribute name="name" use="required" type="NCName"/>
</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">
<complexType base="annotated" derivedBy="extension">
<attribute name="namespace" type="namespaceList" use="default" value="##any"/>
</complexType>
</element>
<!-- types for type -->
<complexType name="complexType" base="annotated" derivedBy="extension" abstract="true">
<sequence>
<choice>
<element ref="facet" minOccurs="0" maxOccurs="unbounded"/>
<!-- max 1, min 0, for each facet except pattern, period-->
<group ref="particle" minOccurs="0" maxOccurs="unbounded"/>
</choice>
<group ref="attrDecls"/>
</sequence>
<attribute name="name" type="NCName">
<annotation>
<documentation>Will be restricted to required or forbidden</documentation>
</annotation>
</attribute>
<attribute name="content">
<simpleType base="NMTOKEN">
<enumeration value="elementOnly"/>
<enumeration value="textOnly"/>
<enumeration value="mixed"/>
<enumeration value="empty"/>
</simpleType>
</attribute>
<attribute name="base" type="QName"/>
<attribute name="derivedBy" type="derivationChoice"/>
<attribute name="abstract" type="boolean" use="default" value="false"/>
<attribute name="final" type="derivationSet"/>
<attribute name="block" type="derivationSet"/>
</complexType>
<complexType name="topLevelComplexType" base="complexType" derivedBy="restriction">
<sequence>
<element ref="annotation" minOccurs="0"/>
<choice>
<element ref="facet" minOccurs="0" maxOccurs="unbounded"/>
<!-- max 1, min 0, for each facet except pattern, period-->
<group ref="particle" minOccurs="0" maxOccurs="unbounded"/>
</choice>
<group ref="attrDecls"/>
</sequence>
<attribute name="name" type="NCName" use="required"/>
</complexType>
<complexType name="localComplexType" base="complexType" derivedBy="restriction">
<sequence>
<element ref="annotation" minOccurs="0"/>
<choice>
<element ref="facet" minOccurs="0" maxOccurs="unbounded"/>
<!-- max 1, min 0, for each facet except pattern, period-->
<group ref="particle" minOccurs="0" maxOccurs="unbounded"/>
</choice>
<group ref="attrDecls"/>
</sequence>
<attribute name="name" use="prohibited"/>
</complexType>
<!-- Top level type element, daughter of schema -->
<element name="complexType" equivClass="schemaTop" type="topLevelComplexType"/>
<simpleType name="derivationControls" base="string">
<enumeration value="#all"/>
<enumeration value="equivClass"/>
<enumeration value="extension"/>
<enumeration value="restriction"/>
</simpleType>
<simpleType name="derivationChoiceOrAll" base="derivationControls">
<annotation>
<documentation>A utility type, not for public use</documentation>
</annotation>
<enumeration value="#all"/>
<enumeration value="extension"/>
<enumeration value="restriction"/>
</simpleType>
<simpleType name="derivationChoice" base="derivationChoiceOrAll">
<annotation>
<documentation>A utility type, not for public use</documentation>
</annotation>
<enumeration value="extension"/>
<enumeration value="restriction"/>
</simpleType>
<simpleType name="blockSet" base="derivationControls" derivedBy="list">
<annotation>
<documentation>#all or (possibly empty) subset of {equivClass,
extension, restriction}</documentation>
<documentation>A utility type, not for public use</documentation>
</annotation>
</simpleType>
<simpleType name="derivationSet" base="derivationChoiceOrAll" derivedBy="list">
<annotation>
<documentation>#all or (possibly empty) subset of {extension,
restriction}</documentation>
<documentation>A utility type, not for public use</documentation>
</annotation>
</simpleType>
<!-- 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 -->
<complexType name="element" base="annotated" derivedBy="extension" abstract="true">
<choice minOccurs="0">
<element name="simpleType" type="localSimpleType"/>
<element name="complexType" type="localComplexType"/>
</choice>
<element ref="identityConstraint" minOccurs="0" maxOccurs="unbounded"/>
<attributeGroup ref="defRef"/>
<attribute name="type" type="QName"/>
<attribute name="equivClass" 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"/>
</complexType>
<complexType name="topLevelElement" base="element" derivedBy="restriction">
<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"/>
<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"/>
</complexType>
<complexType name="localElement" base="element" derivedBy="restriction">
<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"/>
<attribute name="equivClass" use="prohibited"/>
<attribute name="final" use="prohibited"/>
</complexType>
<element name="element" type="topLevelElement" equivClass="schemaTop"/>
<!-- group type for named top-level groups and group references -->
<complexType name="group" base="annotated" derivedBy="extension" abstract="true">
<group ref="particle" minOccurs="0" maxOccurs="unbounded"/>
<attributeGroup ref="defRef"/>
<attributeGroup ref="occurs"/>
</complexType>
<complexType name="namedGroup" base="group" derivedBy="restriction">
<element ref="annotation" minOccurs="0"/>
<group ref="particle" minOccurs="0" maxOccurs="unbounded"/>
<attribute name="name" use="required" type="NCName"/>
<attribute name="ref" use="prohibited"/>
<attribute name="minOccurs" use="prohibited"/>
<attribute name="maxOccurs" use="prohibited"/>
</complexType>
<complexType name="groupRef" base="group" derivedBy="restriction">
<element ref="annotation" minOccurs="0"/>
<attribute name="ref" use="required" type="QName"/>
<attribute name="name" use="prohibited"/>
</complexType>
<!-- group type for the three kinds of group -->
<complexType name="explicitGroup" base="group" derivedBy="restriction">
<element ref="annotation" minOccurs="0"/>
<group ref="nestedParticle" minOccurs="0" maxOccurs="unbounded"/>
<attribute name="name" type="NCName" use="prohibited"/>
<attribute name="ref" type="QName" use="prohibited"/>
</complexType>
<element name="all" type="explicitGroup"/>
<element name="choice" type="explicitGroup"/>
<element name="sequence" type="explicitGroup"/>
<element name="group" equivClass="schemaTop" type="namedGroup"/>
<!-- The wildcard specifier in content models -->
<element name="any">
<complexType base="annotated" derivedBy="extension">
<attribute name="namespace" type="namespaceList" use="default" value="##any"/>
<attribute name="processContents" use="default" value="strict">
<simpleType base="NMTOKEN">
<enumeration value="skip"/>
<enumeration value="lax"/>
<enumeration value="strict"/>
</simpleType>
</attribute>
<attributeGroup ref="occurs"/>
</complexType>
</element>
<!-- simple type for the value of the 'namespace' attr of 'any' and
'anyAttribute' -->
<!-- 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 may appear in the above list, to refer to the
targetNamespace of the enclosing schema -->
<simpleType name="namespaceList" base="string">
<annotation>
<documentation>##any | ##other | ##local | list of {uri, ##targetNamespace}</documentation>
<documentation>A utility type, not for public use</documentation>
</annotation>
</simpleType>
<!-- the attribute element declares attributes -->
<element name="attribute" equivClass="schemaTop" type="topLevelAttribute"/>
<!-- attributeGroup element -->
<complexType name="attributeGroup" base="annotated" derivedBy="extension" abstract="true">
<choice minOccurs="0" maxOccurs="unbounded">
<element name="attribute" type="attribute"/>
<element name="attributeGroup" type="attributeGroupRef"/>
</choice>
<element ref="anyAttribute" minOccurs="0"/>
<attributeGroup ref="defRef"/>
</complexType>
<complexType name="namedAttributeGroup" base="attributeGroup" derivedBy="restriction">
<element ref="annotation" minOccurs="0"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="attribute" type="attribute"/>
<element name="attributeGroup" type="attributeGroupRef"/>
</choice>
<attribute name="name" use="required" type="NCName"/>
<attribute name="ref" use="prohibited"/>
</complexType>
<complexType name="attributeGroupRef" base="attributeGroup" derivedBy="restriction">
<element ref="annotation" minOccurs="0"/>
<attribute name="ref" use="required" type="QName"/>
<attribute name="name" use="prohibited"/>
</complexType>
<element name="attributeGroup" type="namedAttributeGroup" equivClass="schemaTop"/>
<element name="include">
<complexType base="annotated" derivedBy="extension">
<attribute name="schemaLocation" type="uriReference" use="required"/>
</complexType>
</element>
<element name="import">
<complexType base="annotated" derivedBy="extension">
<attribute name="namespace" type="uriReference"/>
<attribute name="schemaLocation" type="uriReference"/>
</complexType>
</element>
<!-- Better reference mechanisms -->
<simpleType name="XPathExprApprox" base="string">
<annotation>
<documentation>An XPath expression</documentation>
<documentation>A utility type, not for public use</documentation>
</annotation>
<pattern value="(/|//|\.|\.\.|:|::|\||(\c-[.:/|])+)+">
<annotation>
<documentation>A VERY permissive definition,
probably not even right
</documentation>
</annotation>
</pattern>
</simpleType>
<element name="selector" type="XPathExprApprox"/>
<element name="field" type="XPathExprApprox"/>
<complexType name="keybase" base="annotated" derivedBy="extension">
<sequence>
<element ref="selector"/>
<element ref="field" minOccurs="1" maxOccurs="unbounded"/>
</sequence>
<attribute name="name" type="NCName" use="required"/>
</complexType>
<element name="identityConstraint" type="keybase" abstract="true"/>
<element name="unique" equivClass="identityConstraint"/>
<element name="key" equivClass="identityConstraint"/>
<element name="keyref" equivClass="identityConstraint">
<complexType base="keybase" derivedBy="extension">
<attribute name="refer" type="QName" use="required"/>
</complexType>
</element>
<!-- notation element type -->
<element name="notation" equivClass="schemaTop">
<complexType base="annotated" derivedBy="extension">
<attribute name="name" type="NCName" use="required"/>
<attribute name="public" type="public" use="required"/>
<attribute name="system" type="uriReference"/>
</complexType>
</element>
<simpleType name="public" base="string">
<annotation>
<documentation>A public identifier, per ISO 8879</documentation>
<documentation>A utility type, not for public use</documentation>
</annotation>
</simpleType>
<!-- notations for use within XML Schema schemas -->
<notation name="XMLSchemaStructures" public="structures" system="http://www.w3.org/1999/XMLSchema.xsd"/>
<notation name="XML" public="REC-xml-19980210" system="http://www.w3.org/TR/1998/REC-xml-19980210"/>
</schema>
NOTE:
And that is the end of the schema for XML Schema: Structures.
B (normative) DTD for Schemas
The DTD for XML Schema: Structures is given below. Note there is no
implication here the schema must be the root element of a document.
<!-- DTD for XML Schemas: Part 1: Structures -->
<!-- Id: XMLSchema.dtd,v 1.1 2000/04/06 13:50:43 aqw Exp -->
<!-- The the datatype element and its components
are defined in XML Schema: Part 2: Datatypes -->
<!-- Note %p is defined in part2.dtd -->
<!ENTITY % xs-datatypes PUBLIC 'datatypes' 'part2.dtd' >
%xs-datatypes;
<!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 % 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 % notation "%p;notation">
<!-- Customisation entities for the ATTLIST of each element type.
Define one of these if your schema takes advantage of the
anyAttribute='##other' in the schema for schemas -->
<!ENTITY % schemaAttrs ''>
<!ENTITY % complexTypeAttrs ''>
<!ENTITY % elementAttrs ''>
<!ENTITY % groupAttrs ''>
<!ENTITY % allAttrs ''>
<!ENTITY % choiceAttrs ''>
<!ENTITY % sequenceAttrs ''>
<!ENTITY % anyAttrs ''>
<!ENTITY % anyAttributeAttrs ''>
<!ENTITY % attributeAttrs ''>
<!ENTITY % attributeGroupAttrs ''>
<!ENTITY % uniqueAttrs ''>
<!ENTITY % keyAttrs ''>
<!ENTITY % keyrefAttrs ''>
<!ENTITY % includeAttrs ''>
<!ENTITY % importAttrs ''>
<!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 + 'equivClass' -->
<!ENTITY % mgs '%all; | %choice; | %sequence;'>
<!ENTITY % cs '%choice; | %sequence;'>
<!ENTITY % formValues '(qualified|unqualified)'>
<!-- the duplication below is to produce an unambiguous content model
which allows annotation everywhere -->
<!ELEMENT %schema; ((%include; | %import; | %annotation;)*,
(%simpleType; | %complexType;
| %element; | %attribute;
| %attributeGroup; | %group;
| %notation; ),
(%annotation;
| %simpleType; | %complexType;
| %element; | %attribute;
| %attributeGroup; | %group;
| %notation; )* )>
<!ATTLIST %schema;
targetNamespace %URIref; #IMPLIED
version CDATA #IMPLIED
%nds; %URIref; #FIXED 'http://www.w3.org/1999/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;)?,
((%facet;)*|
((%element;| %mgs; | %group; | %any;)*,
(%attribute;| %attributeGroup;)*,
(%anyAttribute;)?)))>
<!ATTLIST %complexType;
name %NCName; #IMPLIED
id ID #IMPLIED
content (textOnly|mixed|elementOnly|empty) #IMPLIED
abstract %boolean; 'false'
final %complexDerivationSet; ''
block %complexDerivationSet; ''
derivedBy %complexDerivationChoice; #IMPLIED
base %QName; #IMPLIED
%complexTypeAttrs;>
<!-- facets only if derivedBy='restriction' -->
<!-- (element|group|any) only if content=mixed or =elementOnly
and no base at all, i.e. a root type, or base is a complex type -->
<!-- content defaults to base's if there is a complex base,
textonly if there's a simple base,
'mixed' if no base (because that's the urType's content)
and no content daughters,
'elementOnly' otherwise -->
<!-- should we replace content='empty' with content='elementOnly'
final='#all' plus no content? -->
<!-- If one top-level group, that IS the content model, otherwise
an implicit group obtains.
This is
<sequence minOccurs='1' maxOccurs='1'>
unless content='mixed', in which case it's
<choice minOccurs='0' maxOccurs='unbounded'> -->
<!-- If anyAttribute appears in one or more referenced attributeGroups
and/or explicitly, the intersection of the permissions is used -->
<!-- A text-only type with no attributes differs from a datatype with
the same base qualified the same way in regard to the impact on
attributes of anyAttribute -->
<!-- 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; '1'
maxOccurs CDATA #IMPLIED
nullable %boolean; 'false'
equivClass %QName; #IMPLIED
abstract %boolean; 'false'
final %complexDerivationSet; ''
block %blockSet; ''
default CDATA #IMPLIED
fixed CDATA #IMPLIED
form %formValues; #IMPLIED
%elementAttrs;>
<!-- type and ref are mutually exclusive.
name and ref are mutually exculsive, one is required -->
<!-- In the absence of type AND ref, type defaults to type of
equivClass, if any, else the ur-type, i.e. unconstrained -->
<!-- maxOccurs defaults to 1 or minOccurs, whichever is greater -->
<!-- default and fixed are mutually exclusive -->
<!ELEMENT %group; (%mgs;)?>
<!ATTLIST %group;
name %NCName; #IMPLIED
ref %QName; #IMPLIED
minOccurs %nonNegativeInteger; '1'
maxOccurs CDATA #IMPLIED
id ID #IMPLIED
%groupAttrs;>
<!ELEMENT %all; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)>
<!ATTLIST %all;
minOccurs %nonNegativeInteger; '1'
maxOccurs CDATA #IMPLIED
id ID #IMPLIED
%allAttrs;>
<!ELEMENT %choice; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)>
<!ATTLIST %choice;
minOccurs %nonNegativeInteger; '1'
maxOccurs CDATA #IMPLIED
id ID #IMPLIED
%choiceAttrs;>
<!ELEMENT %sequence; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)>
<!ATTLIST %sequence;
minOccurs %nonNegativeInteger; '1'
maxOccurs CDATA #IMPLIED
id ID #IMPLIED
%sequenceAttrs;>
<!-- an anonymous grouping in a model, or
a top-level named group definition, or a reference to same -->
<!-- Note that if order is 'all', group is not allowed inside.
If order is 'all' THIS group must be alone (or referenced alone) at
the top level of a content model -->
<!-- If order is 'all', minOccurs==maxOccurs==1 on element/any inside -->
<!-- Should allow minOccurs=0 inside order='all' . . . -->
<!ELEMENT %any; (%annotation;)?>
<!ATTLIST %any;
namespace CDATA '##any'
processContents (skip|lax|strict) 'strict'
minOccurs %nonNegativeInteger; '1'
maxOccurs CDATA #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 may appear in the above list, with the
obvious meaning -->
<!ELEMENT %anyAttribute; (%annotation;)?>
<!ATTLIST %anyAttribute;
namespace CDATA '##any'
%anyAttributeAttrs;>
<!-- namespace is interpreted as for 'any' above -->
<!-- simpleType only if no type|ref attribute -->
<!-- ref not allowed at top level, name iff at top level -->
<!ELEMENT %attribute; ((%annotation;)?, (%simpleType;)?)>
<!ATTLIST %attribute;
name %NCName; #IMPLIED
id ID #IMPLIED
ref %QName; #IMPLIED
type %QName; #IMPLIED
use (prohibited|optional|required|fixed|default) #IMPLIED
value CDATA #IMPLIED
form %formValues; #IMPLIED
%attributeAttrs;>
<!-- type and ref are mutually exclusive.
name and ref are mutually exculsive, one is required -->
<!-- value only if use is fixed, required or default, or name -->
<!-- name and use are mutually exclusive -->
<!-- default for use is optional when nested, none otherwise -->
<!-- type attr and simpleType content are mutually exclusive -->
<!-- an attributeGroup is a named collection of attribute decls, or a
reference thereto -->
<!ELEMENT %attributeGroup; ((%annotation;)?,
(%attribute; | %attributeGroup;)*,
(%anyAttribute;)?) >
<!ATTLIST %attributeGroup;
name %NCName; #IMPLIED
id ID #IMPLIED
ref %QName; #IMPLIED
%attributeGroupAttrs;>
<!-- ref iff no content, no name. ref iff not top level -->
<!-- better reference mechanisms -->
<!ELEMENT %unique; ((%annotation;)?, %selector;, (%field;)+)>
<!ATTLIST %unique; name %NCName; #REQUIRED
id ID #IMPLIED
%uniqueAttrs;>
<!ELEMENT %key; ((%annotation;)?, %selector;, (%field;)+)>
<!ATTLIST %key; name %NCName; #REQUIRED
id ID #IMPLIED
%keyAttrs;>
<!ELEMENT %keyref; ((%annotation;)?, %selector;, (%field;)+)>
<!ATTLIST %keyref;
name %NCName; #REQUIRED
id ID #IMPLIED
refer %QName; #REQUIRED
%keyrefAttrs;>
<!ELEMENT %selector; (#PCDATA)>
<!ELEMENT %field; (#PCDATA)>
<!-- Schema combination mechanisms -->
<!ELEMENT %include; (%annotation;)?>
<!ATTLIST %include; schemaLocation %URIref; #REQUIRED
%includeAttrs;>
<!ELEMENT %import; (%annotation;)?>
<!ATTLIST %import; namespace %URIref; #IMPLIED
schemaLocation %URIref; #IMPLIED
%importAttrs;>
<!ELEMENT %notation; (%annotation;)?>
<!ATTLIST %notation;
name %NCName; #REQUIRED
id ID #IMPLIED
public CDATA #REQUIRED
system %URIref; #IMPLIED
%notationAttrs;>
<!NOTATION XMLSchemaStructures PUBLIC 'structures'
'http://www.w3.org/1999/XMLSchema.xsd' >
<!NOTATION XML PUBLIC 'REC-xml-1998-0210'
'http://www.w3.org/TR/1998/REC-xml-19980210' >
D References (normative) *
-
Cambridge Communiqué
-
The
Cambridge Communiqué, Ralph Swick
and Henry S. Thompson, editors, 7 October 1999. See http://www.w3.org/TR/schema-arch
-
DCD
- Document
Content Description for XML (DCD), Tim Bray et al. W3C, 10 August 1998.
See http://www.w3.org/TR/NOTE-dcd
-
DDML
- Document
Definition Markup Language. See
http://www.w3.org/TR/NOTE-ddml
-
XML Schema: Primer
-
XML Schema:
Primer, David C. Fallside, ed. See http://www.w3.org/TR/2000/WD-xmlschema-0-20000407/primer.html
-
HTML-4
- HTML 4.0
Specification, Dave Raggett et al. W3C, 1998. See
http://www.w3.org/TR/REC-html40/
-
ISO-11404
- ISO
11404 -- Information Technology -- Programming Languages, their environments
and system software interfaces -- Language-independent datatypes,
ISO/IEC 11404:1996(E).
-
RFC-1808
- RFC
1808,Relative Uniform Resource Locators. Internet Engineering Task
Force. See http://www.ietf.org/rfc/rfc1808.txt
-
SOX
- Schema for
Object-oriented XML, Matt Fuchs, et al. W3C, 1998. See
http://www.w3.org/Submission/1998/15/
-
SOX-1.1
- Schema
for Object-oriented XML, Version 1.1, Matt Fuchs, et al. W3C, 1999. See
???
-
URI
- Uniform
Resource Identifiers (URI): Generic Syntax and Semantics. See
http://www.ics.uci.edu/~fielding/url/draft-fielding-uri-syntax-01.txt
-
URL
- RFC
1738,Uniform Resource Locators (URL). Internet Engineering Task
Force. See http://www.ietf.org/rfc/rfc1738.txt
-
URN
- RFC 2141,URN
Syntax. Internet Engineering Task Force. See
http://www.ietf.org/rfc/rfc2141.txt
-
WAI-PAGEAUTH
-
WAI Accessibility Guidelines: Page Authoring, Gregg Vanderheiden
et al. W3C, 14-Apr-1998. See http://www.w3.org/TR/WAI-WEBCONTENT/
-
WEBARCH-EXTLANG
- Web Architecture: Extensible Languages, Tim
Berners-Lee and Dan Connolly. W3C, 10 Feb 1998. See
http://www.w3.org/TR/NOTE-webarch-extlang
-
WEBSGML
-
Proposed TC for WebSGML Adaptations for SGML, C. F. Goldfarb, ed.,
14 June 1997. See http://www.sgmlsource.com/8879rev/n1929.htm
-
XML Schemas: Datatypes
-
XML Schema Part 2: Datatypes, Paul V. Biron and Ashok
Malhotra, eds. See http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/datatypes.html
-
XML Schema Requirements
-
XML Schema Requirements , Ashok Malhotra and Murray Maloney, ed.,
W3C, 15 February 1999. See http://www.w3.org/TR/NOTE-xml-schema-req
-
XDR
- XML-Data
Reduced, Frankston, Charles, and Henry S. Thompson, ed. See
http://www.ltg.ed.ac.uk/~ht/XMLData-Reduced.htm
-
XLink
- XML Linking
Language (XLink), Eve Maler and Steve DeRose, W3C, 3 March 1998. See
http://www.w3.org/TR/WD-xlink
-
XML
- Extensible
Markup Language (XML) 1.0, Tim Bray, et al. W3C, 10 February 1998. See
http://www.w3.org/TR/REC-xml
-
XSLT
- Extensible
Stylesheet Language Transformations, James Clark, W3C, 21 April 1999.
See http://www.w3.org/TR/1999/WD-xslt-19990421
-
XML-Data
-
XML-Data, Andrew Layman, et al. W3C, 05 January 1998. See
http://www.w3.org/TR/1998/NOTE-XML-data-0105/
-
XML-Infoset
- XML Information Set (public WD),
David Megginson et al., W3C, 1999. See
http://www.w3.org/TR/xml-infoset
-
XML-Namespaces
-
Namespaces in XML, Tim Bray et al., W3C, 1998. See
http://www.w3.org/TR/WD-xml-names/
-
XPointer
- XML
Pointer Language (XPointer), Eve Maler and Steve DeRose, W3C, 3 March
1998. See http://www.w3.org/TR/xptr
-
XPath
-
XML Path Language, James Clark
and Steve DeRose, editors, 16 November 1999. See http://www.w3.org/TR/xpath
-
XSchema
- XSchema
Specification, Simon St. Laurent, Ronald Bourret, John Cowan, et al.,
Version 1.0, Draft, 18 October 1998. See
http://www.simonstl.com/xschema/spec/xscspecv4.htm
For more general information, consult
http://purl.oclc.org/NET/xschema
E (non-normative) Analysis of the Unique Particle Attribution constraint
A specification of the import of Unique Particle Attribution (§5.7) which does
not appeal to a processing model is difficult. What follows is intended as
guidance, without claiming to be complete.
[Definition:] We say that two non-group
particles overlap if
or
-
They are both element declaration particles one of which is in the other's equivalence class
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.
F Acknowledgements (non-normative)
The following have contributed material to this draft:
- David Fallside, IBM
- Scott Lawrence, Agranat Systems
- Andrew Layman, Microsoft
- Eve L. Maler, Sun Microsystems
The editors acknowledge the members of the XML Schema Working Group, the members of other W3C Working Groups, and industry experts in other
forums who have contributed directly or indirectly to the process or content of
creating this document. The Working Group is particularly grateful to Lotus
Development Corp. and IBM for providing teleconferencing facilities.
The current members of the XML Schema Working Group are:
Jim Barnette, Defense Information Systems Agency (DISA); David Beech, Oracle Corp.; Paul V. Biron, Health Level Seven; Don Box, DevelopMentor; Allen Brown, Microsoft; Lee Buck, Extensibility; Charles E. Campbell, Informix; Peter Chen, Bootstrap Alliance and LSU; David Cleary, Progress Software; Dan Connolly, W3C (staff contact); Roger L. Costello, MITRE; Ugo Corda, Xerox; Andrew Eisenberg, Progress Software; David Ezell, Hewlett Packard Company; David Fallside, IBM; Matthew Fuchs, Commerce One; Andrew Goodchild, Distributed Systems Technology Centre (DSTC Pty Ltd); Paul Grosso, ArborText, Inc; Martin Gudgin, DevelopMentor; Dave Hollander, CommerceNet (co-chair); Mary Holstege, Calico Commerce; Jane Hunter, Distributed Systems Technology Centre (DSTC Pty Ltd); Rick Jelliffe, Academia Sinica; Andrew Layman, Microsoft; Dmitry Lenkov, Hewlett Packard Company; Eve Maler, Sun Microsystems; Ashok Malhotra, IBM; Murray Maloney, Commerce One; John McCarthy, Lawrence Berkeley National Laboratory; Noah Mendelsohn, Lotus Development Corporation; Don Mullen, Extensibility; Frank Olken, Lawrence Berkeley National Laboratory; Dave Peterson, Graphic Communications Association; Mark Reinhold, Sun Microsystems; Jonathan Robie, Software AG; John C. Schneider, MITRE; Lew Shannon, NCR; C. M. Sperberg-McQueen, W3C (co-chair); Bob Streich, Calico Commerce; Henry S. Thompson, University of Edinburgh; Matt Timmermans, Microstar; Jim Trezzo, Oracle Corp.; Steph Tryphonas, Microstar; Mark Tucker, Health Level Seven; Asir S. Vedamuthu, webMethods, Inc; Priscilla Walmsley, XMLSolutions; Norm Walsh, ArborText, Inc; Aki Yoshida, SAP AG
The XML Schema Working Group has benefited in its work from the
participation and contributions of a number of people not currently
members of the Working Group, including
in particular those named below. Affiliations given are those current at
the time of their work with the WG.
Paula Angerstein, Vignette Corporation; Gabe Beged-Dov, Rogue Wave Software; Greg Bumgardner, Rogue Wave Software; Dean Burson, Lotus Development Corporation; Rob Ellman, Calico Commerce; George Feinberg, Object Design; Charles Frankston, Microsoft; Ernesto Guerrieri, Inso; Michael Hyman, Microsoft; Renato Iannella, Distributed Systems Technology Centre (DSTC Pty Ltd); Dianne Kennedy, Graphic Communications Association; Janet Koenig, Sun Microsystems; Setrag Khoshafian, Technology Deployment International (TDI); Ara Kullukian, Technology Deployment International (TDI); Murata Makoto, Xerox; Chris Olds, Wall Data; Shriram Revankar, Xerox; William Shea, Merrill Lynch; Ralph Swick, W3C; Tony Stewart, Rivcom
G Tabulation of changes
$Log: structures.xml,v $
Revision 1.82.2.11 2000/04/07 21:55:09 ht
balance parens
Revision 1.82.2.10 2000/04/07 21:44:33 ht
entity typo
Revision 1.82.2.9 2000/04/07 21:33:28 ht
xspecref->xtermref, fix mailto
Revision 1.82.2.8 2000/04/07 16:53:35 ht
arghh, typo in fix
Revision 1.82.2.7 2000/04/07 16:52:23 ht
more quoted links
Revision 1.82.2.6 2000/04/07 16:11:31 ht
typo
Revision 1.82.2.5 2000/04/07 16:03:52 ht
quoted link cleanup, hugo comments handled, status para fixed.
Revision 1.82.2.4 2000/04/07 14:51:18 ht
two link bugs
Revision 1.82.2.3 2000/04/07 14:39:24 ht
spelling corrections
Revision 1.82.2.2 2000/04/07 13:45:58 ht
new ,txt files
Revision 1.82.2.1 2000/04/07 10:43:20 ht
start towards public version for last call, merge last publication work branch
Revision 1.82 2000/04/06 16:35:44 aqw
wg version for last call,
implement nullable decision, 224 decision
Revision 1.81 2000/04/06 14:08:54 aqw
last lap for last call, noah comments done
Revision 1.80 2000/04/02 22:54:40 aqw
last call version
Revision 1.78 2000/03/31 18:47:46 aqw
preliminary 208
Revision 1.77 2000/03/31 13:41:12 aqw
working on 208, attr attrs
Revision 1.76 2000/03/30 18:44:24 aqw
lots of edits: Michael, David B, Noah
Revision 1.75 2000/03/18 23:29:02 ht
typos, minor fixes
Revision 1.74 2000/03/18 22:20:19 aqw
finished Chapter 6
Revision 1.71 2000/03/18 15:43:05 aqw
top-level attr decls in,
particles simplified to have copy of global rather than copy of bits
Revision 1.70 2000/03/18 11:08:25 aqw
working on top-level attr decl
Revision 1.69 2000/03/17 14:50:52 aqw
starting on top-level attr decls
Revision 1.68 2000/03/17 12:10:55 aqw
typo in id constraints,
better handling of anyAttr in extension, restriction,
copy down attributes when deriving at XML repr level
Revision 1.67 2000/03/16 15:09:32 aqw
Basic error and outcome work now in place
Revision 1.66 2000/03/16 10:42:47 aqw
Finished Chapter 5
Revision 1.65 2000/03/16 08:52:19 bu
change equiv-class-ancestor to equiv-class
Revision 1.64 2000/03/15 18:42:29 aqw
Chapter 5 now clean through 5.12, most of 5.13
Revision 1.61 2000/03/15 12:46:46 aqw
working through (new) Chapter 5 cleaning up
Revision 1.60 2000/03/15 11:04:47 aqw
extract and reorder coss to be new chapter 5
Revision 1.59 2000/03/14 14:55:59 ht
change locus of exponent in RecurseAsIfGroup restriction test case
Revision 1.58 2000/03/14 14:48:26 aqw
completed minimum pass on sections for model groups, wildcards, notations, annotations and identity constraints in Chapter 4, which is now minimally complete;
brought simple type definition component def closer in line with Pauls version
Revision 1.57 2000/03/13 17:58:37 aqw
srcs for attributeGroup, group
Revision 1.56 2000/03/11 22:08:32 bu
first pass at adding abstract schema itself
Revision 1.55 2000/03/11 16:00:22 aqw
start compdef for schema itself
Revision 1.54 2000/03/11 12:23:10 aqw
reproduction in, 4.3.1 cleaned
Revision 1.53 2000/03/11 11:26:23 aqw
update * to unbounded for maxOccurs, allow min=0 on <all>
Revision 1.52 2000/03/08 15:14:11 aqw
complete XML Repr of Complex Types, more work on coss-ct
Revision 1.51 2000/03/08 11:52:03 aqw
covered required attributes in complex restriction
Revision 1.50 2000/03/08 11:39:37 aqw
finished by-cases definition of valid particle restriction
Revision 1.49 2000/03/07 17:46:03 aqw
continue by-cases definition of valid particle restricton
Revision 1.48 2000/03/07 12:29:51 aqw
begin by-cases definition of valid particle restricton
Revision 1.47 2000/03/03 00:16:59 ht
return from restructure branch to main line post-pwd5
Revision 1.46.1.49 2000/03/03 00:10:22 ht
fold back in substantive aspects of pwd5 branch,
work on wildcard validation,
fix bug in particle validation of groups
Revision 1.46.1.48 2000/02/24 23:03:55 ht
fixed examples brutally
spell check
rushed through stubs for all propmaps
Revision 1.46.1.47 2000/02/24 21:42:27 ht
exact->value, work on groups
Revision 1.46.1.46 2000/02/24 12:28:05 ht
noah's most recent additions
work on attributes, make content type a particle, not a group (oops)
Revision 1.46.1.45 2000/02/23 18:08:54 ht
ur-type consistency
more on complex type in c6
stubs for all props in c6
derivationChoice/Set/exactSet fussing
Revision 1.46.1.44 2000/02/23 10:06:31 ht
integrate work from Noah on ur-type cleanup, ed note removal
Revision 1.46.1.43 2000/02/22 23:10:27 ht
try identity-c for reference-c
Revision 1.46.1.42 2000/02/22 17:51:30 ht
Handle some ednotes, remove some stale in-doc issues
turn the rhetoric for chapter 4 around, so elements in repr are on
top, elaborate the reprdef content model accordingly
Finish off (?) <element> and associated src and cos
Revision 1.46.1.41 2000/02/21 17:45:45 ht
add latest from Noah,
more structure in <reprdef> to allow one elt->many components
Revision 1.46.1.40 2000/02/18 19:05:17 ht
minor cleanup for Plenary notice,
start on <element> element,
rename source to base
Revision 1.46.1.39 2000/02/18 12:27:22 ht
work on XML repr of attributes, QName stuff
incorporate Eve's and Noah's edits of yesterday
Revision 1.46.1.38 2000/02/17 10:10:07 ht
integrated changes from eve,
added names to annotations property (oops)
Revision 1.46.1.37 2000/02/16 22:10:45 ht
add annotations to every component,
start seriously on Chapter 4
Revision 1.46.1.36 2000/02/16 13:24:53 ht
integrate (with minor mods) updates from eve,
full (but complex) spec. for keyref validation
Revision 1.46.1.35 2000/02/15 14:12:02 ht
merged in edits to c.1 from eve
Revision 1.46.1.34 2000/02/14 17:59:37 ht
some ref-constr work, cleaned up some ednotes
Revision 1.46.1.33.2.1 2000/02/15 13:44:11 ht
noah's contributions of 14 Feb
Revision 1.46.1.33 2000/02/14 14:51:12 ht
working on particles vs. equiv classes
Revision 1.46.1.32 2000/02/14 12:07:05 bu
cvcs for model group, particle and wildcard
Revision 1.46.1.31 2000/02/14 08:46:52 ht
more from Noah
Revision 1.46.1.30 2000/02/12 18:10:47 ht
noahs next edits integrated, responded to
Revision 1.46.1.29 2000/02/12 16:53:52 ht
got defaults sorted out for element decls
Revision 1.46.1.28 2000/02/11 12:56:00 aqw
Integrate from Noah, add comments, value constraint for complex types, clarify language about LDG
Revision 1.46.1.27 2000/02/11 11:03:06 ht
Noah working on element decl
Revision 1.46.1.26 2000/02/10 15:00:50 aqw
another pass over 3.2, finished I think
Revision 1.46.1.25 2000/02/10 11:11:47 ht
appropriate noah's additions
Revision 1.46.1.23 2000/02/09 16:32:06 aqw
update terminology per some f2f votes, begin working through chapter 3, add null processing to element decl
Revision 1.46.1.22 2000/02/08 23:20:24 ht
fix bogus eg embedding
Revision 1.46.1.21 2000/01/27 19:09:32 aqw
a bit more cleanup of composition chapter, everybody has at least stub
properties, got field and selectors in barely, lots more <stale>
wrapping.
Revision 1.46.1.20 2000/01/27 16:00:13 aqw
began to mark non-restructured sections, some cleanup of composition
Revision 1.46.1.19 2000/01/27 10:57:14 aqw
Michael's and Noah's general editorial suggestions
Try reference-constraint for key, unique, keyref
Revision 1.46.1.18 2000/01/26 23:18:30 aqw
example reprdef, full set of reprdef stubs
Revision 1.46.1.17 2000/01/26 13:12:16 aqw
Another minor reordering in chapter 2
Brief expositions added to each subsection in chapter 2
QName reference validation stuff
Revision 1.46.1.16 2000/01/25 22:29:38 bu
final cross-references added to Chapter 3 stubs, some sics
Revision 1.46.1.15 2000/01/25 17:45:11 aqw
some work on references/QNames
Revision 1.46.1.14 2000/01/25 16:13:50 aqw
restructuring for parallelism, with lots of stubs, now complete?
Revision 1.46.1.13 2000/01/24 18:06:22 aqw
more re-ordering of chapter 3, preliminary cvcs for attr and elt decls
Revision 1.46.1.12 2000/01/22 11:11:06 aqw
detail work on complex type def details
Revision 1.46.1.11 2000/01/20 17:40:01 aqw
working seriously on complex type defn details
Revision 1.46.1.10 2000/01/20 11:25:29 aqw
move simple type to end of each section
start work on complex type defn for real in Chap. 3
introduce <eltref>.
Revision 1.46.1.9 2000/01/19 17:10:18 aqw
remove all remaining scraps == abstract syntax
cosmetic changes in chap.1
begin adding more details in chap.3
Revision 1.46.1.8 2000/01/19 15:52:07 aqw
restructure compdef and reprdef for better control
Revision 1.46.1.7 2000/01/18 17:59:00 aqw
moving towards auto-generated paradigms
Revision 1.46.1.6 2000/01/15 18:13:20 aqw
revised approach to reprdef
Revision 1.46.1.5 2000/01/15 12:56:03 aqw
new chaps 2 and 3 complete in outline
Starting on 4.[attr grp defn] as prototype for XML repr spec
Revision 1.46.1.4 2000/01/12 23:02:17 ht
Moved component type details from Chap 2 to Chap 3
Revision 1.46.1.3 2000/01/12 21:18:22 ht
replaced [prop] with <propdef>, <propref> and <xpropref>
Revision 1.46.1.2 2000/01/12 18:04:37 aqw
Finished drastic pruning and rewrite of Chapter 2
Now propose to move all the formal definitions to the new Chapter 3:
Schema Components, with sections called e.g. Attribute Declarations:
details or some such
Revision 1.46.1.1 2000/01/12 12:44:56 aqw
begin major reorg: component exposition started
Revision 1.46 2000/01/10 11:57:56 aqw
Fold in non-publ-related changes in 19991217 publication version (1.45.1.6)
Experiment with moving major examples out-of-line
Revision 1.45.1.6 1999/12/17 16:14:53 ht
one more link
Revision 1.45.1.5 1999/12/17 15:35:47 ht
reorder prevloc
Revision 1.45.1.4 1999/12/17 14:50:25 ht
link fixes
Revision 1.45.1.3 1999/12/17 14:46:51 ht
additional status prose
Revision 1.45.1.2 1999/12/17 13:33:11 ht
PWD status prose and link fixes
Revision 1.45.1.1 1999/12/17 12:26:37 ht
towards PWD
Revision 1.45 1999/12/17 12:06:05 ht
eacute
Revision 1.44 1999/12/17 11:51:45 ht
make all example quotes double
some changes merged from pre-Nov-publ branch (1.15.1...)
Revision 1.43 1999/12/17 10:59:16 ht
minor fix in schema wrt keys
Revision 1.42 1999/12/16 15:48:08 ht
fix some refs, incorporate up-to-date schema and DTD
Revision 1.41 1999/12/16 15:40:05 aqw
describe exact, final and abstract on elements
Revision 1.40 1999/12/16 09:44:11 aqw
minor editorial
Revision 1.39 1999/12/14 16:22:46 aqw
various QName fixes
Revision 1.38 1999/12/10 18:01:42 ht
remove * where status has changed
Revision 1.37 1999/12/10 16:14:10 aqw
renaming attrGroup, elemOnly, integrate DTD and schema
Revision 1.36 1999/12/10 16:08:05 aqw
more on BRM, add an wildcard ambiguity issue
Revision 1.35 1999/12/10 10:07:35 ht
merge in new-design branch
Revision 1.34 1999/12/10 09:38:42 ht
minor orphan changes
Revision 1.33 1999/12/08 20:06:52 aqw
added prose for BRM
Revision 1.32 1999/12/03 15:49:25 ht
fix status text
Revision 1.31 1999/12/03 14:54:16 aqw
ht version confusion
Revision 1.30 1999/12/03 14:48:41 aqw
Outline inclusion of BRM proposal
Implemented QName aspect of composition decision
Revision 1.29.1.6 1999/12/08 20:04:26 aqw
describe impact of exact for equiv classes, remove substitutabiliity section
Revision 1.29.1.5 1999/12/06 23:15:09 ht
add stars, no standalone
Revision 1.29.1.4 1999/12/06 22:50:02 aqw
add equiv classes, up-to-date DTD and schema
Revision 1.29.1.3 1999/12/03 19:37:27 ht
Fill in 3.6.3, controlling derivation, including mod agreed with Allen
wrt type tolerance.
Revision 1.29.1.2 1999/12/03 15:55:38 aqw
cleanup new proposal stuff for preliminary release
Revision 1.29.1.1 1999/12/02 22:55:36 aqw
begin serious work on integrating new type derivation proposal
Revision 1.29 1999/12/02 19:05:00 aqw
resolve ! issue in <any namespace='...'> in favour of ##
remove private exploratory hierarchy rewrite
Revision 1.28 1999/12/02 11:36:27 aqw
merge in DTD and schema for internal point release
Revision 1.27 1999/12/02 11:09:36 aqw
composition tf integrates, validates nearly ok
Revision 1.26 1999/12/01 15:43:23 aqw
integrating composition tf . . .
Revision 1.25 1999/11/22 14:14:59 aqw
integrate tentative type construction compromise
Revision 1.24 1999/11/12 17:00:41 ht
Incorporate minimal null support
Revision 1.23 1999/11/11 11:19:11 ht
add issues per 1999-11-04 telcon vote
Revision 1.22 1999/11/11 11:11:51 ht
include dtd and schema
Revision 1.21.1.1 1999/11/22 14:03:55 aqw
try out type construction compromise
Revision 1.21 1999/11/05 00:48:14 aqw
note about status vis a vis forthcoming issues from minutes
Revision 1.20 1999/11/04 23:46:57 aqw
remove element classes per WG vote
Revision 1.19 1999/11/03 21:39:47 aqw
fix editors list and acks
typoes spotted by DBeech
Revision 1.18 1999/11/03 15:49:26 aqw
Implement chair's instructions wrt WG poll closed 1999-10-30:
* re-integrate named model groups
* change details of implicit openness
* remove entities, not notations
Revision 1.17 1999/11/02 23:37:35 aqw
merge refinement proposal into mainline preparatory to implementing poll results
Revision 1.16 1999/11/02 21:32:25 aqw
remove entity definitions and related material (e.g. notations)
Revision 1.15 1999/10/27 13:28:58 ht
Fix some (all?) syntax paradigms, examples
Include bug-fixed .xsd and .dtd
Revision 1.14 1999/10/27 10:48:01 ht
Incorporate up-to-date schema and DTD, completing concrete syntax changes
Parameterise paths/dates to facilitate release process
Revision 1.13.1.15 1999/10/26 16:23:30 ht
a bit more on validity
Revision 1.13.1.14 1999/10/25 14:37:31 ht
Begin to try to fill in validity section on basis of
schema-valid(EII,type,schemaSet) minimalist approach
Revision 1.13.1.13 1999/10/19 18:42:13 ht
added xsd:type to text, changed status
Revision 1.13.1.12 1999/10/18 19:46:12 aqw
Added concrete syntax, prose and examples to 3.6, new section on the
hierarchy and restrictions
Revision 1.13.1.11 1999/10/18 15:28:16 aqw
Included lots in 3.5 and 3.6, editting it in to shape
Revision 1.13.1.10 1999/10/18 13:55:23 aqw
correct and corresponding DTD and Schema included
text from new design included in 3.5 and 3.6 for editting
Revision 1.13.1.9 1999/10/18 11:39:01 aqw
light pass over section 2, cleaning up 'type' terminology
minor fixups in 3.4
Revision 1.13.1.8 1999/10/17 22:05:19 aqw
first pass through 3.4 complete
Revision 1.13.1.7 1999/10/16 22:12:03 aqw
element classes
Revision 1.13.1.6 1999/10/16 19:02:51 aqw
attribute finished, also attrGroup
Revision 1.13.1.5 1999/10/16 17:53:28 aqw
finished (?) with complex types, on to attributes
Revision 1.13.1.4 1999/10/16 11:52:07 aqw
still working on complex type
Revision 1.13.1.3 1999/10/15 16:38:31 aqw
more work on 'type'
Revision 1.13.1.1 1999/10/15 11:46:18 ht
on the way to matching new refinement proposal
Revision 1.13 1999/10/09 10:49:40 ht
correct headline date
Revision 1.12 1999/10/05 09:56:19 ht
Preliminary implementation of A3 and A7 (ampConnector and richerMixed)
votes. Moving towards a parallel syntax for elementDecl/Ref and
groupDefn/Ref.
Concrete syntax paradigms, examples, DTD and Schema NOT up-to-date
Revision 1.11 1999/09/27 16:31:07 ht
merge simple back to main branch
Revision 1.10.2.38 1999/09/27 16:29:02 ht
return to xmlschema-current as base
Revision 1.10.2.37 1999/09/24 16:40:22 ht
add comments archive pointer
Revision 1.10.2.36 1999/09/24 16:38:23 ht
link housekeeping, move TF reports bibliography to separate appendix
Revision 1.10.2.35 1999/09/24 13:44:27 ht
final (?) housekeeping before publication
Revision 1.10.2.34 1999/09/23 18:48:51 ht
changes to front matter in preparation for public WD
ponter to Simple TF included
Revision 1.10.2.33 1999/09/23 13:32:15 ht
up-to-date pointer to refinement TF report
Revision 1.10.2.32 1999/09/23 13:00:22 ht
typo in db entity
Revision 1.10.2.31 1999/09/23 12:59:04 ht
per suggestions from Ashok, some rewording of summary of Composition
TF, added issue regarding priority of instance->schema alternatives
Revision 1.10.2.30 1999/09/22 14:02:35 ht
typo in correction to 4.1
Revision 1.10.2.29 1999/09/22 13:58:39 ht
edits implementing Noah's comments
Revision 1.10.2.28 1999/09/22 08:07:07 ht
add verbatim change log at end
----------------------------
revision 1.10.2.27
date: 1999/09/21 16:26:11; author: ht; state: Exp; lines: +4 -4
added Id: to title for now
----------------------------
revision 1.10.2.26
date: 1999/09/21 16:06:08; author: ht; state: Exp; lines: +42 -244
replaced composition tf report with a summary and a pointer
----------------------------
revision 1.10.2.25
date: 1999/09/21 14:11:50; author: aqw; state: Exp; lines: +495 -111
some dates, up-to-date DTD and Schema for schemas
----------------------------
revision 1.10.2.24
date: 1999/09/21 10:50:37; author: ht; state: Exp; lines: +18 -3
supply missing content model for 'attribute' in concrete syntax
paradigm
----------------------------
revision 1.10.2.23
date: 1999/09/21 10:37:51; author: aqw; state: Exp; lines: +21 -20
define/declare consistency pass
----------------------------
revision 1.10.2.22
date: 1999/09/20 13:08:36; author: aqw; state: Exp; lines: +47 -49
track datatype content model changes,
minor wording
----------------------------
revision 1.10.2.21
date: 1999/09/16 14:55:17; author: ht; state: Exp; lines: +136 -14
header disclaimer, graveyards rescued to discharge references
----------------------------
revision 1.10.2.20
date: 1999/09/16 14:25:01; author: aqw; state: Exp; lines: +274 -1541
rip out all of 3.5, all of 4, install 'Draft Proposal' in 4
----------------------------
revision 1.10.2.19
date: 1999/09/16 12:08:59; author: aqw; state: Exp; lines: +107 -143
Clean up import/include/export, references in particular
Add archetypeRef to content models, minimally
New example of datatype+attr
----------------------------
revision 1.10.2.18
date: 1999/09/15 22:06:29; author: aqw; state: Exp; lines: +26 -3
Two clarifications following discussion with Andrew
1) what it would take to remove the two symbol spaces problem
2) How <archetype> allows either datatypeRef or contentType
----------------------------
revision 1.10.2.17
date: 1999/09/15 20:30:49; author: aqw; state: Exp; lines: +114 -105
change date, incorporate edited dtd
----------------------------
revision 1.10.2.16
date: 1999/09/15 19:52:39; author: aqw; state: Exp; lines: +90 -76
Encorporate/respond to Eve Maler's suggested edits
----------------------------
revision 1.10.2.15
date: 1999/09/13 16:14:12; author: aqw; state: Exp; lines: +306 -335
Finish consistency pass through 3.4
Brutal 'element type' -> element
----------------------------
revision 1.10.2.14
date: 1999/09/09 14:22:29; author: aqw; state: Exp; lines: +53 -56
cleanup pass, down to 3.3
----------------------------
revision 1.10.2.13
date: 1999/09/08 18:23:47; author: ht; state: Exp; lines: +41 -41
more type back to archetype
----------------------------
revision 1.10.2.12
date: 1999/09/08 18:03:06; author: aqw; state: Exp; lines: +214 -216
put archetype back in, imperfectly, I expect
----------------------------
revision 1.10.2.11
date: 1999/09/07 21:50:36; author: bu; state: Exp; lines: +124 -63
fix paradigm contexts, extend example, consolidate example in appendix
----------------------------
revision 1.10.2.10
date: 1999/09/07 16:54:39; author: aqw; state: Exp; lines: +514 -521
syntax paradigms now properly distributed, I think
----------------------------
revision 1.10.2.9
date: 1999/09/07 15:53:06; author: ht; state: Exp; lines: +5 -8
fixed minor validity errors
----------------------------
revision 1.10.2.8
date: 1999/09/07 15:31:58; author: aqw; state: Exp; lines: +288 -285
working on integrating syntax paradigms
----------------------------
revision 1.10.2.7
date: 1999/09/07 09:44:57; author: aqw; state: Exp; lines: +630 -33
added ALL concrete syntax boxes at once
----------------------------
revision 1.10.2.6
date: 1999/09/06 14:55:04; author: ht; state: Exp; lines: +35 -2
added one e: syntax exposition
----------------------------
revision 1.10.2.5
date: 1999/09/02 15:28:27; author: ht; state: Exp; lines: +6 -6
fix URLs for self, a bit
----------------------------
revision 1.10.2.4
date: 1999/09/02 12:53:34; author: aqw; state: Exp; lines: +108 -95
Added not-status-quo marks, changed e.g. String to string
----------------------------
revision 1.10.2.3
date: 1999/09/01 17:02:14; author: aqw; state: Exp; lines: +587 -977
integration of 2.3 from simple
more renaming
----------------------------
revision 1.10.2.2
date: 1999/08/23 15:32:16; author: aqw; state: Exp; lines: +730 -248
Modified simple integration to give preliminary consistency
----------------------------
revision 1.10.2.1
date: 1999/08/22 17:44:40; author: aqw; state: Exp; lines: +317 -260
Textual integration of Simple update of 1999-08-13
----------------------------
revision 1.10
date: 1999/07/20 19:47:27; author: ht; state: Exp; lines: +5 -5
branches: 1.10.2;
fixed dates, dangling reference
----------------------------
revision 1.9
date: 1999/07/19 09:31:26; author: ht; state: Exp; lines: +34 -38
David Beech: updated definition of "Schema" following WG and IG email
discussion. Changed "Schemata" to "Schemas" except where directly
quoted from Requirements doc. Clarified in 2.5 that elements and
attributes have separate symbol spaces (public comment). Fixed
assorted typos.
----------------------------
revision 1.8
date: 1999/06/23 10:00:31; author: aqw; state: Exp; lines: +1 -1
fix Id:
----------------------------
revision 1.7
date: 1999/06/23 09:51:15; author: aqw; state: Exp; lines: +28 -28
Restrict content model of 'all' in schema and dtd, change entities for
point releases
----------------------------
revision 1.6
date: 1999/06/23 09:10:01; author: aqw; state: Exp; lines: +147 -187
pushed & down to lowest level, fixed incoherent validity
definition in 6.2.3.7 to agree with the note which follows. Wrapped
validation text from 3.4 in appropriately named div4's
----------------------------
revision 1.5
date: 1999/06/21 16:31:59; author: aqw; state: Exp; lines: +569 -551
Really moved validity-oriented definitions to 6.3 (previous revision
was just housekeeping)
----------------------------
revision 1.4
date: 1999/06/21 16:25:21; author: aqw; state: Exp; lines: +45 -36
moved validity-oriented definitions to 6.3
----------------------------
revision 1.3
date: 1999/06/21 12:25:21; author: aqw; state: Exp; lines: +3540 -3650
Low-level: Normalise line ends, quotes
Editorial: Move all constraintnotes to new separate section
----------------------------
revision 1.2
date: 1999/05/27 14:13:54; author: aqw; state: Exp; lines: +2 -2
fix stylesheet and dtd urls to local versions
----------------------------
revision 1.1
date: 1999/05/23 16:51:11; author: ht; state: Exp;
branches: 1.1.1;
Initial revision
H Open Issues
A tabulation of open issues flagged above follows: