This is a public working draft of XML Schema 1.0 for review by the
public and by members of the World Wide Web Consortium.
Following a period of review and polishing, it is the WG's intent
to issue a Last Call for Review by other W3C working groups sometime
during March, 2000, and to submit this specification thereafter 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 send comments to
www-xml-schema-comments@w3.org
This working draft has been substantially restructured since the previous public
release. This structural reorganisation is not yet complete.
In this
draft, unrestructured material is distinguished as follows:
The restructuring of Chapters 1 through 3 is largely completed:
Attributes and Attribute groups give the clearest picture of how Chapters 5 and
6 will eventually look.
The lengthy introductory example material from the old Chapter 2 has
been moved out of line into a non-normative companion document ([XML Schema: Exposition] and expanded
considerably. Pointers to this will in due course be added to this document.
Although the Working Group does not anticipate further substantial
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 Access and Composition (§5), including the
connection between documents and schemas, the import and inclusion of declarations and definitions and
the foundations of schema-validity.
Chapter 6 discusses Conformance * (§6), including the rules
by which documents are validated, 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.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.
The following terms are used in building
definitions and describing the actions of XML Schema: Structures processors:
-
[Definition:] may
-
Conforming documents and processors are permitted to but need
not behave as described.
[Unrestructured material elided]
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. |
|
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:
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: Exposition] 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
defines a set of schema-valid XML documents. At a minimum, it consists of type definitions
and element declarations. It
identifies a set 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 is a member of the set defined by 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.
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)
Ed. Note:
The datatype spec's use of the word "component" makes things somewhat confusing
next to this specification's use of the same word. Perhaps the terminology in the datatype spec should be revised?
[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
- 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
- Attribute declarations
- 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
null 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 Conformance * (§6), 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, an extension of some other type definition. Collectively, 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 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 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.
Ed. Note: Should use this as a target for other references
throughout the text.
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 be empty, to be a string which is schema-valid with respect to particular simple type or to contain element information items which is schema-valid with respect to a particular model group, with or without character information items as well.
Each is complex type definition is either a:
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.3) for the composition and
schema-validation contributions of complex type definition schema components, XML Representation of Complex Type Definition Schema Components (§4.4.3) for the XML representation of
complex type definitions and Complex Type Definition Constraints (§6.3.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.2) for the composition and
schema-validation contributions of element declaration schema components, XML Representation of Element Declaration Schema Components (§4.4.2) for the XML representation of
element declarations and Element Declaration Constraints (§6.3.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 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.1) for the composition and
schema validation contributions of attribute declaration schema components, XML Representation of Attribute Declaration Schema Components (§4.4.1) for the XML representation of
attribute declarations and Attribute Declaration Constraints (§6.3.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.6) for the composition and
schema-validation contributions of model group schema components, Complex Type Definition Details (§3.3) for the use of model groups as content models, XML Representation of Model Group Schema Components (§4.4.6) for the XML representation of
model groups and Model Group Constraints (§6.3.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.7) for the composition and
schema-validation contributions of particle schema components, XML Representation of Model Group Schema Components (§4.4.6) for the XML representation of
particles and Particle Constraints (§6.3.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.9) for the composition and
schema-validation contributions of identity-constraint definition schema components, XML Representation of Identity-constraint Definition Schema Components (§4.4.8) for the XML representation of
identity-constraint definitions and Identity-constraint Definition Constraints (§6.3.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 Conformance * (§6).
-
[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).
-
[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 XXX.
.
Ed. Note:
A a reference to the rules for handling
schema location, dereference of namespace Uris, etc.
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.
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 represent 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.
Attribute declarations and locally scoped element
declarations are special with regard to symbol spaces.
Every complex type definition defines its own attribute declaration
symbol space and local element declaration symbol
space, where these symbol spaces are distinct from each other and from any of the other
symbol spaces. So, for example, several complex type definitions having
the same target namespace can contain
an 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 distinguished null value for XML document elements. An
element has the null value if it has no [children] and carries the attribute xsi:null.
Ed. Note:
Are other attributes allowed? Must sync with validation rules.
2.6.3 xsi:schemaLocation
The xsi:schemaLocation attribute can be used in a document to provide
hints as to the physical location of schema documents to be used for validation.
3 Schema Component Details
The following sections provide full details on the properties and
significance of 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 every vertex is a schema
component or a literal (string, boolean, number) and every labelled edge a property. Any property not
identified as optional is required to be present, optional properties which are absent are taken to have null 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 null. Any property value identified as subset of some set may be equal to that set, unless a proper subset is explicitly called for.
By 'string' here and below is meant a
sequence of ISO 10646 character codes identified as legal XML character codes
in [XML].
Ed. Note:
Or the UNICODE 3 addendum, where/when?
Throughout the following sections, when we refer to the [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 of schema components are identified below as having
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 discharged. This specification addresses the matter of missing
components in a uniform manner, described in Missing Sub-components (§6.2): no mention of
handling missing components will be found in the individual component
descriptions below.
NOTE:
Schema components 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".
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: Exposition].
Ed. Note:
Due to time constraints in preparing this draft, the {annotation} properties are not explicitly described for the
components below. In all cases, the property is an annotation
(see "Annotation Details" below).
3.1 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 "qualified" attribute name is one that appears with a namespace prefix which is itself declared with a
value other than the empty string. A non-null value of the {target namespace} property provides for validation of
such attributes qualified with an identical namespace URI. Null values of {target namespace} provide for validation of local
(unprefixed) attributes. Each complex type definition provides its own symbol space for the
names of its associated local attribute declarations. (E.g. an attribute
named title within one type definition need not have the same
simple type definition as one declared within another complex
type; neither of these need agree with the declaration for a similarly named qualified attribute.)
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 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.
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.3).)
[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 (§6.3.1). No means is provided to supply a
default value for a namespace declaration.
See XML Representation of Attribute Declaration Schema Components (§4.4.1) for the XML representation of
attribute declarations and Attribute Declaration Constraints (§6.3.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
[value] must
Schema Information Set Contribution: Attribute Type
In the post-schema
validation infoset a
[schema type] property is added to the attribute information item with the
{simple type definition} as its value.
3.2 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 elements being validated.
A {scope} of global declares elements available for use in content
models throughout the schema. Locally scoped elements are available for use only within the
complex type identified by the {scope} property. For globally scoped element declarations, a non-null value of the {target namespace} property provides for validation of
namespace qualified elements. Null values of
{target namespace} validate unqualified elements, including
locally scoped elements. This property is also null 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.
An element is schema-valid
if it obeys the schema validity constraints of the {type definition}. For such an
element, 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 the element is also schema valid if it has
no text or element content, and
carries the namespace qualified attribute with [local name] null from namespace http://www.w3.org/1999/XMLSchema/instance (see xsi:null (§2.6.2)). Formal details of element validation are described in Element Valid (Explicit) (§3.2).
{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.9).
Element declarations are members of the equivalence class, if any, identified
by {equivalence class affiliation}. Membership is transitive; an element
declaration is implicitly a member of any class of which its {equivalence class affiliation} is a member.
An empty {equivalence class exclusions} creates an equivalence
class admitting other element declarations having the same {type definition} or
types derived therefrom. The explicit
values of {equivalence class exclusions} exclude from the equivalence class elements having types which
are extensions, lists, restrictions or reproductions respectively of {type definition}. If all values are specified, then no equivalence class is possible based on this element 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, list, restriction and/or reproduction of the type of the declared element, and/or (b) from validating elements which are in the same
equivalence class (equivClass) 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.4.2) for the XML representation of
element declarations and Element Declaration Constraints (§6.3.2) for constraints on element
declaration components as such.
Validation Contribution: Element Valid (Explicit)
An element information item is schema-valid with respect to an
element declaration if
| 1.1 |
If {nullable} is false there is no attribute information item among the element
information item's [attributes] whose [namespace URI] is identical to http://www.w3.org/1999/XMLSchema/instance and whose [local name] is null;
|
| 1.2 |
If {nullable} is true and there is such an attribute
information item and its [value] is true, then
| 1.2.1 |
the element information item must have no character or element information item
[children];
|
| 1.2.2 |
there is no fixed {value constraint}.
|
|
If there is an attribute information item among the element
information item's
[attributes] whose
[namespace URI] is identical to
http://www.w3.org/1999/XMLSchema/instance and whose
[local name] is
type, then
[Definition:] We refer below to the
actual type definition. If the above three clauses obtain, this
should be understood as referring to the local type
definition, otherwise to the {type definition}.
If the declaration has a
{value constraint}, then
provided clause 1.2 has not obtained
Otherwise (the element information item has character information item
[children] or there is no
{value constraint}) if the
actual type definition is a simple type
definition, then
otherwise (the
actual type definition is a complex type
definition)
Issue (nullRequiresEmpty):
Is it a precondition for being nullable that the element's contentType
allow no content? If not, then more needs to be said in Chapter 6, if so, this needs
to be spelled out.
Ed. Note: The above also allows null elements to have
attributes, i.e. it's their CONTENT which is null. Was that the
designers' intention? See related ednote under xsi:null in chapter 2.
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.7).
Schema Information Set Contribution: Element Default Value
If the
{value constraint} is present and the element
information item has no character or element information item
[children], the post-schema
validation infoset has a list of character information items, one per character
in the
{value constraint} string, appended to its
[children].
Ed. Note:
Should we add a property to indicate THAT the value was supplied by default?
Schema Information Set Contribution: Element Type
In the post-schema
validation infoset a
[schema type] property is added to the element information item with the
actual type definition as its value.
Schema Information Set Contribution: Element Null
If clause 1.2 of
Element Valid (Explicit) (§3.2) above obtains, in the post-schema
validation infoset a
[null] property is added to the element
information item with the value true.
3.3 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 are identified by their {name} and {target namespace}. Except
for anonymous complex types (those with no {name}), complex
type definitions must be uniquely identified within an XML
Schema. 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 (§5.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.2).
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 any of
extension, restriction or reproduction; the explicit values extension,
restriction and reproduction prevent further
derivations by extension, restriction and reproduction 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.3)
and Attribute Valid (§3.1) 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 null: [attributes] can
include any attribute(s) from the specified namespace(s). If null 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 null: [attributes] cannot include
unqualified attributes.
See Element Children and Attributes Valid (§3.3) and Wildcard allows Namespace URI (§3.8) 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 elements with an xsi:type (§2.6.1) attribute that
identifies an extension, restriction or reproduction of the type of the declared element.
If {prohibited-substitutions} is empty,
then all such substitutions are valid.
See Element Children and Attributes Valid (§3.3)
for a formal specification of element content validation.
See XML Representation of Complex Type Definition Schema Components (§4.4.3) for the XML representation of
complex type definitions and Complex Type Definition Constraints (§6.3.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
There is a complex type definition version of the ur-type definition present in every
schema by definition. It has the following properties:
| Complex Type Definition of the Ur-Type |
|
|
Ed. Note:
This should be handled with a generic tableau markup
The mixed content specification together with the
unconstrained wildcard content model and attribute specification produce the defining property for the
complex ur-type definition, namely that every complex type definition is
either an extension of a simple type definition or (eventually) a restriction
of the complex ur-type definition: its permissions and requirements are
the least restrictive possible.
3.6 Model Group Details
When the [children] of element information items are not constrained
to be empty or by reference to a simple type definition
(Simple Type Definition Details (§3.12)), 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 minOccurs=maxOccurs=1) contain exactly one of each element specified in {particles}. The elements can occur in any order.
{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 (§6.3.7)). A much simpler implementation is possible for than would arise from a literal interpretation of the definition above; informally, the content is valid when each declared element occurs exactly once, and each is valid with respect to its corresponding declaration. The elements can occur in arbitrary order.
<