<notice role="publoc"><ednote><edtext>The following SHOULD be in the publoc, but
the DTD doesn't currently allow it: the stylesheet fakes it.</edtext></ednote>
<p>(in <loc href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/structures.xml">XML</loc> (with its own <loc href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/xmlspec-19990429.dtd">DTD</loc>, <loc href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/xmlschema.xsl">XSL
stylesheet</loc>) and <loc href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/structures.html">HTML</loc>), with separate provision of the <loc href="http://www.w3.org/2001/XMLSchema.xsd">schema</loc> and <loc href="http://www.w3.org/2001/XMLSchema.dtd">DTD</loc> for schemas described herein.</p>
<p><emph>This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. The latest status of this document series is maintained at
the W3C.</emph></p>
<p>This document has been reviewed by W3C Members and other interested
parties and has been endorsed by the Director as a W3C
Recommendation. It is a stable document and may be used as reference
material or cited as a normative reference from another
document. W3C's role in making the Recommendation is to draw attention
to the specification and to promote its widespread deployment. This
enhances the functionality and interoperability of the Web.</p>
<p>This document has been produced by the <loc href="http://www.w3.org/XML/Schema">W3C XML Schema Working Group</loc>
as part of the W3C <loc href="http://www.w3.org/XML/">XML
Activity</loc>. The goals of the XML Schema language are discussed in
the <loc href="http://www.w3.org/TR/NOTE-xml-schema-req">XML Schema
Requirements</loc> document. The authors of this document are the XML
Schema WG members. Different parts of this specification have
different editors.</p>
<p>
This version of this document incorporates some editorial changes
from earlier versions.
</p>
<p>
Please report errors in this document to <loc href="mailto:www-xml-schema-comments@w3.org">www-xml-schema-comments@w3.org</loc> (<loc href="http://lists.w3.org/Archives/Public/www-xml-schema-comments/">archive</loc>). The list of known errors in this specification is available at <loc href="http://www.w3.org/2001/05/xmlschema-errata">http://www.w3.org/2001/05/xmlschema-errata</loc>.
</p>
<p>The English version of this specification is the only normative
version. Information about translations of this document is available
at <loc href="http://www.w3.org/2001/05/xmlschema-translations">http://www.w3.org/2001/05/xmlschema-translations</loc>.</p>
<p>A list of current W3C Recommendations and other technical documents can be found at
<p>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:</p>
<compdef name="Example" ref="intro-terminology">
<proplist>
<propdef id="xmpl-prop" name="example property">
Definition of the property.
</propdef>
</proplist>
</compdef>
<p>References to properties of schema components are links to
the relevant definition as exemplified above, set off with curly braces, for instance <propref ref="xmpl-prop"/>.</p>
<p>The correspondence between an element information item which is part
of the XML representation of a schema and one or more schema components is presented in a tableau
which illustrates the element information item(s) involved.
This is followed by a tabulation of the correspondence between properties of the component
and properties of the information item. Where context may determine which of
several different components may arise, several tabulations, one per context,
are given. The property correspondences are normative,
as are the illustrations of the XML representation element information items.
</p>
<p>In the XML representation, bold-face
attribute names (e.g. <term>count</term> 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
<code>size</code> below; if there is a default value, it is shown
following a colon. Where an attribute information item has a built-in simple
type definition defined in <bibref ref="ref-xsp2"/>, a hyperlink to its
definition therein is given.</p>
<p>The allowed content of the information item is
shown as a grammar fragment, using the Kleene operators <code>?</code>,
<code>*</code> and <code>+</code>. Each element name therein is a hyperlink to
its own illustration.</p>
<note>
<p>The illustrations are derived automatically from the <specref ref="normative-schemaSchema"/>. In the case of apparent conflict, the <specref ref="normative-schemaSchema"/> takes precedence, as it, together with the <termref def="gloss-src">Schema Representation Constraints</termref>, provide the normative statement of
<propmap name="xmpl-prop">Description of what the property corresponds to, e.g. the value of the <code>size</code>
&i-attribute;
</propmap>
</reprcomp>
</reprdef>
<p>References to elements in the text are links to
the relevant illustration as exemplified above, set off with angle brackets, for instance <eltref ref="example"/>.</p>
<p>References to properties of information items as defined in <bibref ref="ref-xmlinfo"/> are notated as links to the relevant section thereof, set off with square brackets, for example &i-children;.</p>
<p>Properties which this specification defines for information items are
introduced as follows:</p>
<proplist item="example" role="psvi">
<propdef id="ex-foo" name="new property">The value the property gets.</propdef>
</proplist>
<p>References to properties of information items defined in this specification
are notated as links to their introduction as exemplified above, set off with square brackets, for example <propref role="psvi" ref="ex-foo"/>.</p>
<p>The following highlighting is used for non-normative commentary in
this document:</p>
<note>
<p>General comments directed to all readers. </p>
</note>
<p>Following <bibref ref="ref-xml"/>, within normative prose in this specification, the words
<emph>may</emph> and <emph>must</emph> are defined as follows:</p>
<glist>
<gitem>
<label>may</label>
<def>
<p>Conforming documents and XML Schema-aware processors are permitted to but need not behave as described.</p>
</def>
</gitem>
<gitem>
<label>must</label>
<def>
<p>Conforming documents and XML Schema-aware processors are required to behave as described; otherwise they are in error.</p>
</def>
</gitem>
</glist>
<p>Note however that this specification provides a definition of error and of conformant processors'
responsibilities with respect to errors (see <specref ref="conformance"/>) which is considerably
more complex than that of <bibref ref="ref-xml"/>.</p>
</div2>
</div1>
<div1 id="concepts">
<head>Conceptual Framework</head>
<p>This chapter gives an overview of &XSP1; at the level of its abstract data model. <specref ref="components"/> provides details on this model, including
a normative representation in XML for the components of the model.
Readers interested primarily in learning to write schema documents may wish to
first read <bibref ref="bib-expo"/> for a tutorial introduction, and only then consult the sub-sections of
<specref ref="components"/> named <emph>XML Representation of ...</emph> for
the details.</p>
<div2>
<head>Overview of XML Schema</head>
<p>An XML Schema
consists of components such as type definitions
and element declarations. These can be used to assess the validity of
well-formed element and attribute information items (as defined
in <bibref ref="ref-xmlinfo"/>), and furthermore
may specify augmentations to those items and their descendants. This augmentation makes explicit information which may have
been implicit in the original document, such as normalized and/or default values for
attributes and elements and
the types of element and attribute information items.</p>
<p>Schema-validity assessment has two aspects:
<olist><item id="c-lsv"><p>determining local schema-validity, that is
whether an element or attribute information item satisfies the
constraints embodied in the relevant
components of an XML Schema;</p></item>
<item><p>Synthesizing an overall validation outcome for the item,
combining local schema-validity with the results of schema-validity
assessments of its descendants, if any, and
adding appropriate augmentations to the infoset to record this outcome.</p></item></olist></p>
<p>Throughout this specification, <termdef id="key-vn" term="valid">the
word <term>valid</term> and its derivatives are used to refer to
<clauseref ref="c-lsv"/> above, the determination of local
schema-validity</termdef>.</p>
<p>Throughout this specification, <termdef id="key-va" term="assessment"> the word <term>assessment</term> is used to refer
to the overall process of
local validation, schema-validity assessment and infoset augmentation</termdef>.</p>
</div2>
<div2 id="concepts-data-model">
<head>XML Schema Abstract Data Model</head>
<p>This specification builds on <bibref ref="ref-xml"/> and
<bibref ref="ref-xml-namespaces"/>. The concepts and definitions used
herein regarding XML are framed at the abstract level of <xtermref href="http://www.w3.org/TR/xml-infoset/#infoitem">information
items</xtermref> as defined in <bibref ref="ref-xmlinfo"/>. By
definition, this use of the infoset provides <emph>a priori</emph> guarantees of <xtermref href="http://www.w3.org/TR/REC-xml#sec-well-formed">well-formedness</xtermref>
(as defined in <bibref ref="ref-xml"/>) and <xtermref href="http://www.w3.org/TR/REC-xml-names/#Conformance">namespace
conformance</xtermref> (as defined in <bibref ref="ref-xml-namespaces"/>) for
all candidates for <termref def="key-va">assessment</termref> and for all <termref def="key-schemaDoc">schema documents</termref>.</p>
<p>Just as <bibref ref="ref-xml"/> and
<bibref ref="ref-xml-namespaces"/> can be described in terms of
information items, XML Schemas can be described in terms of an
abstract data model. In defining XML Schemas in terms of an abstract
data model, this specification rigorously specifies the information which
must be available to a conforming XML Schema processor. The abstract
model for schemas is conceptual only, and does not mandate any
particular implementation or representation of this information. To
facilitate interoperation and sharing of schema information, a
normative XML interchange format for schemas is provided.</p>
<p><termdef id="key-component" term="schema component"> <term>Schema component</term> is the generic term for the building blocks that comprise the abstract data model of the schema.
</termdef>
<termdef id="key-schema" term="XML Schema">
An <term>XML Schema</term> is a
set of <termref def="key-component">schema components</termref></termdef>. There are 13 kinds of
component in all, falling into three groups. The primary components, which may
(type definitions) or must (element and attribute declarations) have names
are as follows:</p>
<ulist>
<item><p>Simple type definitions
</p></item>
<item><p>Complex type definitions</p></item>
<item><p>Attribute declarations</p></item>
<item><p>Element declarations</p></item>
</ulist><p>The secondary components, which must have names, are as follows:</p>
<ulist>
<item><p>Attribute group definitions</p></item>
<item><p>&Constraint; definitions</p></item>
<item><p>Model group definitions</p></item>
<item><p>Notation declarations</p></item>
</ulist>
<p>Finally, the <quote>helper</quote> components provide small parts of
other components; they are not independent of their context:</p>
<ulist>
<item><p>Annotations</p></item>
<item><p>Model groups</p></item>
<item><p>Particles</p></item>
<item><p>Wildcards</p></item>
<item><p>Attribute Uses</p></item>
</ulist>
<p>During <termref def="key-vn">validation</termref>, <termdef id="key-declaration" term="declaration"><term>declaration</term> components are associated by
(qualified) name to information items being <termref def="key-vn">validated</termref></termdef>.</p>
<p>On the other hand, <termdef id="key-definition" term="definition"><term>definition</term> components define
internal schema components that can be used in other schema components</termdef>.
</p>
<p>
<termdef id="key-compName" term="component name">Declarations and
definitions may have and be identified by <term>name</term>s, which are NCNames as defined by <bibref ref="ref-xml-namespaces"/></termdef>.</p>
Hierarchy">Except for a distinguished <termref def="key-urType">ur-type definition</termref>, every <termref def="key-typeDefn">type definition</termref> is, by construction, either a
<termref def="key-typeRestriction">restriction</termref> or an <termref def="key-typeExtension">extension</termref> of some other type definition. The graph of these relationships forms a tree known as the <term>Type Definition Hierarchy</term></termdef>.
</p>
<p><termdef id="key-typeRestriction" term="restriction">A type
definition whose
declarations or facets are in a one-to-one relation with those of another
specified type
definition, with each in turn restricting the possibilities of the one it
corresponds to, is said to be a <term>restriction</term></termdef>.
The specific restrictions might include narrowed ranges or reduced
alternatives.
Members of a type, A, whose definition is a <termref def="key-typeRestriction">restriction</termref> of the definition of another type, B, are always members of type B as well.</p>
<p><termdef id="key-typeExtension" term="extension">A complex type definition
which allows element or attribute content in addition to that allowed by
another specified type
definition is said to be an <term>extension</term></termdef>.</p>
definition</term> is present in each <termref def="key-schema">XML Schema</termref>, serving as the root of the type
definition hierarchy for that schema</termdef>. The ur-type definition, whose
name is <local>anyType</local>, has
the unique characteristic that it can function as a complex or a
simple type definition, according to context.
Specifically, <termref def="key-typeRestriction">restrictions</termref> of the ur-type definition can
themselves be either simple or complex type definitions.
</p>
<p><termdef id="key-baseTypeDefinition" term="base type definition">A type definition used as the
basis for an <termref def="key-typeExtension">extension</termref> or
<termref def="key-typeRestriction">restriction</termref> is known as
the <term>base type definition</term> of that definition</termdef>.
</p>
</div4><div4 id="Simple_Type_Definition">
<head>Simple Type Definition</head>
<p>A simple type definition is a set of constraints on strings and information about the values they encode, applicable to the &i-value; of an attribute
information item or of an element information item with no element children.
Informally, it applies to the values of attributes and the text-only content of elements.
</p>
<p>Each simple type definition, whether built-in (that is, defined in &XSP2;) or
user-defined, is a <termref def="key-typeRestriction">restriction</termref> of some particular
simple <termref def="key-baseTypeDefinition">base type
definition</termref>. For the built-in primitive types, this is the simple
version of the <termref def="key-urType">ur-type
definition</termref>, whose name is <local>anySimpleType</local>. This
is in turn understood to be a restriction of the <termref def="key-urType">ur-type
definition</termref>. Simple types may
also be defined whose members are lists of items
themselves constrained by some other simple type definition, or whose
membership is the union of the memberships of some other simple type
definitions. List and union simple type definitions are also understood as
restrictions of the simple <termref def="key-urType">ur-type
definition</termref>.</p>
<p>For detailed information on simple type definitions, see <specref ref="Simple_Type_Definitions"/> and &XSP2;. The latter also defines an extensive inventory of
pre-defined simple types.</p>
</div4>
<div4 id="Complex_Type_Definition">
<head>Complex Type Definition</head>
<p>A complex type definition is a set of attribute declarations and a content type, applicable to the &i-attributes; and
&i-children; of an element information item respectively. The content type may
require the &i-children; to contain neither element nor character information
items (that is, to be empty), to be a string which belongs to a particular simple
type or to contain a sequence of element information items which conforms to a particular model group, with or without character information items as well.</p>
<p>Each complex type definition is either
<ulist>
<item>
<p>a restriction of a complex <termref def="key-baseTypeDefinition">base
type definition</termref></p>
</item>
</ulist>
or
<ulist><item>
<p>an <termref def="key-typeExtension">extension</termref> of a simple or complex <termref def="key-baseTypeDefinition">base
type definition</termref></p>
</item>
</ulist>
or
<ulist>
<item>
<p>a <termref def="key-typeRestriction">restriction</termref> of the
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>
<p>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.</p>
</note></p>
<p>
For detailed information on complex type definitions, see <specref ref="Complex_Type_Definitions"/>.</p>
</div4>
</div3>
<div3 id="Declarations_Summary">
<head>Declaration Components</head>
<p>There are three kinds of declaration component: element, attribute, and
notation. Each is described in a section below. Also included is a discussion
of element substitution groups, which is a feature provided in conjunction with
element declarations.</p>
<div4 id="Element_Declaration">
<head>Element Declaration</head>
<p>An element declaration is an association of a name with a type definition, either simple or
complex, an (optional) default value and a (possibly empty) set of &constraint;
definitions. The association is either global or scoped to a containing complex type definition. A
top-level element declaration with name 'A' is broadly comparable to a pair of
DTD declarations as follows, where the associated type definition
fills in the ellipses:</p>
<eg><!ELEMENT A . . .>
<!ATTLIST A . . .>
</eg>
<p>Element declarations contribute to
<termref def="key-vn">validation</termref> as part of model group <termref def="key-vn">validation</termref>, when their defaults and type components are checked against an element
information item with a matching name and namespace, and by triggering
the new mechanism of <term>element substitution groups</term>, XML Schemas provides a more powerful model supporting substitution of one named element for another</termdef>.
Any top-level element declaration can serve as the defining element, or
head, for an element substitution group. Other top-level element declarations,
regardless of target namespace, can be designated as members of the
substitution group headed by this element. In a suitably enabled content
model, a reference to the head <termref def="key-vn">validates</termref> not just the head itself, but elements
corresponding to any member of the substitution group as well.
</p>
<p>All such members must have type definitions which are either the same as the
head's type definition or
restrictions or extensions of it.
Therefore, although the names of elements can vary widely as new
namespaces and members of the substitution group are defined, the
content of member elements is strictly limited according to the type
definition of the substitution group head.</p>
<p>Note that element substitution groups are not represented as separate components. They are
specified in the property values for element declarations (see <specref ref="cElement_Declarations"/>).</p>
</div4>
<div4 id="Attribute_Declaration">
<head>Attribute Declaration</head>
<p>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
<termref def="key-vn">validation</termref> as part of complex type definition <termref def="key-vn">validation</termref>, when their
occurrence, defaults and type components are checked against an attribute
information item with a matching name and namespace.</p>
<p>
For detailed information on attribute declarations, see <specref ref="cAttribute_Declarations"/>.</p>
</div4>
<div4 id="Notation_Declaration">
<head>Notation Declaration</head>
<p>A notation declaration is an association between a name and an identifier for a
notation. For an attribute information item to be <termref def="key-vn">valid</termref> with respect to a
<code>NOTATION</code> simple type definition, its value must have been declared
with a notation declaration.</p>
<p>
For detailed information on notation declarations, see <specref ref="cNotation_Declarations"/>.</p>
</div4>
</div3>
<div3 id="Model_Group_Summary">
<head>Model Group Components</head>
<p>The model group, particle, and wildcard components contribute to
the portion of a complex type definition that controls an element
information item's content.</p>
<div4 id="Model_Group">
<head>Model Group</head>
<p>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:</p>
<ulist>
<item><p>Sequence (the element information items
match the particles in sequential order);</p></item>
<item><p>Conjunction (the element information items match the
particles, in any order);</p></item>
<item><p>Disjunction (the element information items match
one of the particles).</p></item>
</ulist>
<p>
For detailed information on model groups, see <specref ref="Model_Groups"/>.</p>
</div4>
<div4 id="Particle">
<head>Particle</head>
<p>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
<termref def="key-vn">validation</termref> as part of complex type definition <termref def="key-vn">validation</termref>, when they allow anywhere
from zero to many element information items or sequences thereof, depending on
their contents and occurrence
constraints.</p>
<p><termdef id="key-contentModel" term="content model">A particle can
be used in a complex type definition to constrain the <termref def="key-vn">validation</termref>
of the &i-children; of an element information item; such a particle is called
a <term>content model</term></termdef>.
<note>
<p>&XSP1; <termref def="key-contentModel">content models</termref> are similar to but more expressive than
<bibref ref="ref-xml"/> content models; unlike <bibref ref="ref-xml"/>, &XSP1; applies <termref def="key-contentModel">content models</termref> to the <termref def="key-vn">validation</termref> of both mixed and element-only content. </p>
</note></p>
<p>
For detailed information on particles, see <specref ref="cParticles"/>.</p>
</div4>
<div4 id="Attribute_Use">
<head>Attribute Use</head>
<p>An attribute use plays a role similar to that of a particle, but for
attribute declarations: an attribute declaration within a complex type definition
is embedded within an attribute use, which specifies whether the declaration
requires or merely allows its attribute, and whether it has a default or fixed value.</p>
</div4>
<div4 id="Wildcard">
<head>Wildcard</head>
<p>A wildcard is a special kind of particle which matches element and attribute information items dependent on their namespace name, independently
of their local names.</p>
<p>
For detailed information on wildcards, see <specref ref="Wildcards"/>.</p>
</div4>
</div3>
<div3 id="&Constraint;_Definition">
<head>&Constraint; Definition Components</head>
<p>An &constraint; definition is an association between a name and one of
several varieties of
&constraint; related to uniqueness and reference. All the
varieties use <bibref ref="bib-xpath"/> expressions to pick out sets of
information items relative to particular target element
information items which are unique, or a key, or a <termref def="key-vn">valid</termref> reference, within
a specified scope. An element information item is only <termref def="key-vn">valid</termref> with
respect to an element declaration
with &constraint; definitions if those definitions are all satisfied for all the descendants
of that element information item which they pick out.</p>
<p>
For detailed information on &constraint; definitions, see <specref ref="c&Constraint;_Definitions"/>.</p>
</div3>
<div3 id="Group_Definitions">
<head>Group Definition Components</head>
<p>There are two kinds of convenience definitions provided to enable
the re-use of pieces of complex type definitions: model group definitions
and attribute group definitions.</p>
<div4 id="Model_Group_Definition">
<head>Model Group Definition</head>
<p>A model group definition is an association between a name and a model group,
enabling re-use of the same model group in several complex type
definitions.</p>
<p>
For detailed information on model group definitions, see <specref ref="cModel_Group_Definitions"/>.</p>
</div4>
<div4 id="Attribute_Group_Definition">
<head>Attribute Group Definition</head>
<p>An attribute group definition is an association between a name and a set of attribute declarations,
enabling re-use of the same set in several complex type
definitions.</p>
<p>
For detailed information on attribute group definitions, see <specref ref="cAttribute_Group_Definitions"/>.</p>
</div4>
</div3>
<div3 id="Annotation">
<head>Annotation Components</head>
<p>An annotation is information for human and/or mechanical
consumers. The interpretation of such information is
not defined in this specification.</p>
<p>
For detailed information on annotations, see <specref ref="cAnnotations"/>.</p>
</div3>
</div2>
<div2 id="concepts-schemaConstraints">
<head>Constraints and Validation Rules</head>
<p>The <bibref ref="ref-xml"/> specification describes two kinds of
constraints on XML documents: <emph>well-formedness</emph> and
<emph>validity</emph> 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. </p>
<p>The preceding section focused on <termref def="key-vn">validation</termref>, 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
<termref def="key-vn">validation</termref> of information items:</p>
<glist>
<gitem>
<label>Schema Component Constraint</label>
<def>
<p><termdef id="gloss-cos" term="Schema Component Constraint">Constraints on the schema components themselves, i.e.
conditions components must satisfy to be components at all. Located in the
sixth sub-section of the per-component sections of <specref ref="components"/>
and tabulated in <specref ref="outcome-cos"/></termdef>.</p>
</def>
</gitem>
<gitem>
<label>Schema Representation Constraint</label>
<def>
<p><termdef id="gloss-src" term="Schema Representation Constraint">Constraints on the
representation of schema components in XML beyond those which are expressed
in <specref ref="normative-schemaSchema"/>. Located in the
third sub-section of the per-component sections of <specref ref="components"/>
and tabulated in <specref ref="outcome-src"/></termdef>.</p>
</def>
</gitem>
<gitem>
<label>Validation Rules</label>
<def>
<p><termdef id="gloss-cvc" term="Validation
Rules">Contributions to <termref def="key-vn">validation</termref> associated
with schema components. Located in the
fourth sub-section of the per-component sections of <specref ref="components"/>
and tabulated in <specref ref="validation_failures"/></termdef>.</p>
</def>
</gitem>
<gitem>
<label>Schema Information Set
Contribution</label>
<def>
<p><termdef id="gloss-sic" term="Schema Information Set Contribution">Augmentations to &PSVI;s
expressed by schema components, which follow
as a consequence of <termref def="key-vn">validation</termref> and/or <termref def="key-va">assessment</termref>.
Located in the
fifth sub-section of the per-component sections of <specref ref="components"/>
and tabulated in <specref ref="PSVI_contributions"/></termdef>.</p>
</def>
</gitem>
</glist>
<p>The last of these, schema information set
contributions, are not as new as they might at first seem. XML 1.0
validation augments the XML 1.0 information set in similar ways,
for example by
providing values for attributes not present in instances, and by implicitly
exploiting type information for normalization or access.
(As an example of the latter case, consider the
effect of <code>NMTOKENS</code> on attribute white space, and the semantics of
<code>ID</code> and <code>IDREF</code>.) By including schema
information set contributions, this specification makes explicit some features
that XML 1.0 left implicit.</p>
</div2>
<div2 id="concepts-conformance">
<head>Conformance</head>
<p>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.</p>
<p><termdef id="key-minimallyConforming" term="minimally conforming"><term>Minimally conforming</term> processors must completely and
correctly implement the <termref def="gloss-cos">Schema Component
Set Contributions</termref> contained in this specification</termdef>.</p>
<p><termdef id="key-interchange" term="conformance to the XML Representation of Schemas"><termref def="key-minimallyConforming">Minimally conforming</termref> processors which accept
schemas represented in the form of XML documents as described in <specref ref="layer2"/> are
additionally said to provide <term>conformance to the XML Representation of Schemas</term>.
</termdef>
Such processors must, when processing schema documents, completely and
correctly implement all <termref def="gloss-src">Schema Representation
Constraints</termref> in this specification, and must adhere exactly to the
specifications in <specref ref="components"/> for mapping the contents of
such documents to <termref def="key-component">schema
components</termref> for use in <termref def="key-vn">validation</termref> and <termref def="key-va">assessment</termref>.</p>
<note>
<p>By separating the conformance requirements relating to the concrete syntax of XML schema
documents, this specification admits processors
which use schemas stored in optimized binary
representations, dynamically created schemas represented as programming language data structures, or implementations in which particular schemas are compiled into executable code
such as C or Java. Such processors can be said to be <termref def="key-minimallyConforming">minimally conforming</termref> but not necessarily in <termref def="key-interchange">conformance to the XML Representation of Schemas</termref>.</p>
processors are network-enabled processors which are not only both <termref def="key-minimallyConforming">minimally conforming</termref> and <termref def="key-interchange">in conformance to the XML Representation of Schemas</termref>, but which additionally must be capable of accessing
schema documents from the World Wide Web according to <specref ref="web-representation"/> and <specref ref="schema-loc"/>.
</termdef>.
</p>
<note><p>Although this specification provides just these three standard levels of conformance, it is
anticipated that other conventions can be established in the future. For example, the World Wide
Web Consortium is considering conventions for packaging on the Web a variety of
resources relating to individual documents and namespaces. Should such
developments lead to new conventions for representing schemas, or for accessing them on the Web,
new levels of conformance can be established and named at that time. There is no need to modify
or republish this specification to define such additional levels of conformance.</p></note>
<p>See <specref ref="composition"/> for a more detailed explanation of the
mechanisms supporting these levels of conformance.</p>
</div2>
<div2 id="concepts-nameSymbolSpaces">
<head>Names and Symbol Spaces</head>
<p>As discussed in <specref ref="concepts-data-model"/>, most schema
components (may) have <termref def="key-compName">names</termref>.
If all such names were assigned from the same <quote>pool</quote>, then
it would be impossible to have, for example, a simple type definition and an element
declaration both with the name
<quote>title</quote> in a given <termref def="key-targetNS">target namespace</termref>.</p>
<p>
Therefore <termdef id="key-symbolSpace" term="symbol space">this specification introduces the term
<term>symbol space</term> to denote a
collection of names, each of which is unique with respect to the others</termdef>. A symbol space is similar to the non-normative concept of <xtermref href="http://www.w3.org/TR/REC-xml-names/#ns-breakdown">namespace partition</xtermref> introduced in <bibref ref="ref-xml-namespaces"/>.
There is a single distinct symbol space within a given <termref def="key-targetNS">target
namespace</termref> for each kind of definition and declaration component
identified in <specref ref="concepts-data-model"/>, 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.
</p>
<p>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 <quote>priority</quote>, or contain a local element declaration
for the name <quote>address</quote>, without conflict or necessary relation between
the two.</p>
</div2>
<div2 id="Instance_Document_Constructions"> <head>Schema-Related Markup in
Documents Being Validated</head>
<p>The XML representation of schema components uses a vocabulary
identified by the namespace name <code>http://www.w3.org/2001/XMLSchema</code>. For brevity, the text and examples in this specification use the prefix
<code>xs:</code> to stand for this namespace; in practice,
any prefix can be used.</p>
<p>&XSP1; also defines several attributes for direct use in any XML documents. These attributes are in a different namespace,
which has the namespace name <code>http://www.w3.org/2001/XMLSchema-instance</code>.
For brevity, the text and examples in this specification use the prefix
<code>xsi:</code> to stand for this latter namespace; in practice,
any prefix can be used. All schema processors have appropriate attribute
declarations for these attributes built in, see <specref ref="xsi.type"/>,
<specref ref="xsi.nil"/>, <specref ref="xsi.schemaLocation"/> and <specref ref="xsi.noNamespaceSchemaLocation"/>.</p>
<div3 id="xsi_type">
<head>xsi:type</head>
<p>The <specref ref="Simple_Type_Definition"/> or <specref ref="Complex_Type_Definition"/> used in <termref def="key-vn">validation</termref> of an element is usually
determined by reference to the appropriate schema components.
An element information item in an instance may, however,
explicitly assert its type using the attribute <code>xsi:type</code>.
The value of this attribute is a <termref def="gloss-QName">QName</termref>; see <specref ref="src-qname"/> for
the means by which the <termref def="gloss-QName">QName</termref> is
associated with a type definition.
</p>
</div3>
<div3 id="xsi_nil">
<head>xsi:nil</head>
<p>&XSP1; introduces a mechanism for signaling that an element should
be accepted as <termref def="key-vn">valid</termref> when it has no
content despite a content type which does not require or even necessarily allow empty content. An
element may be
<termref def="key-vn">valid</termref> without content if it has the attribute <code>xsi:nil</code> with
the value <code>true</code>. An element so labeled must be empty, but can
carry attributes if permitted by the corresponding complex type.</p>
<p>The <code>xsi:schemaLocation</code> and <code>xsi:noNamespaceSchemaLocation</code> attributes can be used in a document to provide
hints as to the physical location of schema documents which may be used for <termref def="key-va">assessment</termref>.
See <specref ref="schema-loc"/> for details on the use of these attributes.</p>
</div3>
</div2>
<div2 id="web-representation">
<head>Representation of Schemas on the World Wide Web</head>
<p>On the World Wide Web, schemas are conventionally represented as XML
documents (preferably of MIME type
<code>application/xml</code> or <code>text/xml</code>, but see <clauseref ref="c-vxd"/> of <specref ref="src-include"/>), conforming to the specifications in <specref ref="layer2"/>. For more information on
the representation and use of schema documents on the World Wide Web see <specref ref="schema-repr"/> and
<specref ref="schema-loc"/>. </p>
</div2>
</div1>
<div1 id="components">
<head>Schema Component Details</head>
<div2 id="scIntro">
<head>Introduction</head>
<p>The following sections provide full details on the composition of all schema components, together
with their XML representations and their contributions to <termref def="key-va">assessment</termref>. Each section is devoted to a single component, with separate subsections for
<olist>
<item>
<p>properties: their values and significance</p>
</item>
<item>
<p>XML representation and the mapping to properties</p>
</item>
<item>
<p>constraints on representation</p>
</item>
<item>
<p>validation rules</p>
</item>
<item>
<p>&PSVI; contributions</p>
</item>
<item>
<p>constraints on the components themselves</p>
</item>
</olist>
The sub-sections immediately below introduce conventions and terminology used throughout the component sections.</p>
<div3>
<head>Components and Properties</head>
<p>Components are defined in terms of their
properties, and each property in turn is defined by giving its range,
that is the values it may have. This can be understood as
defining a schema as a labeled directed graph, where the root is a schema,
every other vertex is a schema
component or a literal (string, boolean, number) and every labeled edge is a
property. The graph is <emph>not</emph> acyclic: multiple copies of
components with the same name in the same <termref def="key-symbolSpace">symbol space</termref> may not exist, so in some cases re-entrant chains
of properties must exist. Equality of components for the purposes of this
specification is always defined as equality of names (including target
namespaces) within symbol spaces.</p>
<note>
<p>A schema and its components as defined in this chapter are an idealization 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 below of language such as "properties . . . having . . .
components as values".</p>
</note>
<p><termdef id="key-null" term="absent">Throughout this specification, the
term <term>absent</term> is used as a distinguished property value denoting absence</termdef>.</p>
<p>Any property not
identified as optional is required to be present; optional properties which are
not present are taken to have <termref def="key-null">absent</termref> 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 <emph>not</emph> the same as <termref def="key-null">absent</termref>. Any property value identified as a superset or subset of some set may be equal to that set, unless a proper superset or subset is explicitly called for.
By 'string' in Part 1 of this specification is meant a
sequence of ISO 10646 characters identified as <xtermref href="http://www.w3.org/TR/REC-xml#charsets">legal XML characters</xtermref>
in <bibref ref="ref-xml"/>.</p></div3>
<div3>
<head>XML Representations of Components</head>
<p>The principal purpose of &XSP1; is to define a set of
schema components that constrain the contents of instances and augment the
information sets thereof. Although no external representation
of schemas is required for this purpose, such representations will
obviously be widely used. To provide for this in an appropriate and
interoperable way, this specification provides a normative XML representation for schemas which
makes provision for every kind of schema
component. <termdef id="key-schemaDoc" term="schema document">A document in
this form (i.e. a <eltref ref="schema"/> element information item) is a <term>schema document</term></termdef>. For the schema document as a whole, and
its constituents, the sections below define correspondences between element
information items (with declarations in
<specref ref="normative-schemaSchema"/> and <specref ref="nonnormative-schemaDTD"/>) and
schema components. All the element information items in the XML representation
of a schema must be in the XML Schema namespace, that is their <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">namespace name</xpropref> must be <code>http://www.w3.org/2001/XMLSchema</code>. Although a common way of creating the XML Infosets which are or contain <termref def="key-schemaDoc">schema documents</termref> will be using an XML parser, this is not required: any mechanism which constructs conformant infosets as defined in <bibref ref="ref-xmlinfo"/> is a possible starting point.</p>
<p>Two aspects of the XML representations of components presented in the
following sections are constant across them all:
<olist>
<item>
<p>All of them allow attributes qualified with namespace names other than
the XML Schema namespace itself: these appear as annotations in the
corresponding schema component;</p>
</item>
<item>
<p>All of them allow an <eltref ref="annotation"/> as their first child, for human-readable documentation and/or machine-targeted information.</p>
</item>
</olist>
</p>
</div3>
<div3>
<head>The Mapping between XML Representations and Components</head>
<p>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
<specref ref="normative-schemaSchema"/>.</p>
<p>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.</p>
<p>In discussing the mapping from XML representations to schema
components below, the value of a component property is often determined by the
value of an attribute information item, one of the &i-attributes; of an element
information item. Since schema documents are constrained by the
<specref ref="normative-schemaSchema"/>, there is always a simple type
definition associated with any such attribute information item. <termdef id="key-vv" term="actual value">The
phrase <term>actual value</term> is used to refer to the member of the value space of the
simple type definition associated with an attribute information item which corresponds to
its &i-value;</termdef>. This will often be a string, but may also be an
integer, a boolean, a URI reference, etc. This term is also occasionally used with respect to element or attribute information items in a document being <termref def="key-va">validated</termref>.</p>
<p>Many properties are identified below as having
other schema components or sets of components as values. For the purposes of exposition, the definitions in
this section assume that (unless the property is explicitly identified as
optional) all such values are in fact present. When schema
components are constructed from XML representations involving reference by name
to other components, this assumption may be violated if one or more references
cannot be resolved. This specification addresses the matter of missing
components in a uniform manner, described in <specref ref="conformance-missing"/>: no mention of
handling missing components will be found in the individual component
descriptions below.</p>
<p>Forward reference to named definitions and declarations <emph>is</emph>
allowed, both within and between <termref def="key-schemaDoc">schema documents</termref>.
By the time the component corresponding to an XML representation which
contains a forward reference is actually needed for <termref def="key-vn">validation</termref> an appropriately-named component may have become available to discharge the reference: see <specref ref="composition"/> for details.</p>
</div3>
<div3>
<head>White Space Normalization during Validation</head>
<p>Throughout this specification, <termdef id="key-iv" term="initial value">the
value</xpropref> property of that item. Similarly, the <term>initial value</term> of an element information item is the string composed of, in order, the
&i-ccode; of each character information item in the &i-children; of that
element information item</termdef>.</p>
<p>The above definition means that comments and processing instructions,
even in the midst of text, are ignored for all <termref def="key-vn">validation</termref> purposes.</p>
attribute information item is an &r-value; whose white space, if any, has been
normalized according to the value of the <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes.html#rf-whiteSpace">whiteSpace facet</xtermref> of the
simple type definition used in its <termref def="key-vn">validation</termref>:
</termdef>
<glist>
<gitem>
<label>preserve</label>
<def>
<p>No normalization is done, the value is the &i-value;</p>
</def>
</gitem>
<gitem>
<label>replace</label>
<def>
<p>All occurrences of <code>#x9</code> (tab), <code>#xA</code> (line feed) and
<code>#xD</code> (carriage return) are replaced with <code>#x20</code> (space).</p>
</def>
</gitem>
<gitem>
<label>collapse</label>
<def>
<p>Subsequent to the replacements specified above under <local>replace</local>,
contiguous sequences of <code>#x20</code>s are collapsed to a single
<code>#x20</code>, and initial and/or final <code>#x20</code>s are deleted.</p>
</def>
</gitem>
</glist>
</p>
<p>There are three alternative validation rules which may supply the
necessary background for the above: <specref ref="cvc-attribute"/> (<clauseref ref="c-sva"/>), <specref ref="cvc-type"/> (<clauseref ref="c-sv1"/>) or <specref ref="cvc-complex-type"/> (<clauseref ref="c-sv2"/>).</p>
<p>These three levels of normalization correspond to the processing mandated
in XML 1.0 for element content, CDATA attribute content and tokenized
attributed content, respectively. See <xspecref href="http://www.w3.org/TR/REC-xml#AVNormalize">Attribute Value Normalization</xspecref> in <bibref ref="ref-xml"/> for the precedent for <local>replace</local> and <local>collapse</local> for attributes. Extending this processing to element content is necessary to ensure a consistent <termref def="key-vn">validation</termref> semantics for simple types, regardless of whether they are applied to attributes or elements. Performing it twice in the case of attributes whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">normalized
value</xpropref> has already been subject to replacement or collapse on the basis of
information in a DTD is necessary to ensure consistent treatment of attributes
regardless of the extent to which DTD-based information has been made use of
during infoset construction.</p>
<note>
<p>Even when DTD-based information <emph>has</emph> been appealed to, and
<xspecref href="http://www.w3.org/TR/REC-xml#AVNormalize">Attribute Value
Normalization</xspecref> has taken place, the above definition of &i-value; may
mean <emph>further</emph> normalization takes place, as for instance when
character entity references in attribute values result in white space characters
other than spaces in their &r-value;s.</p>
</note>
</div3>
</div2>
<div2 id="cAttribute_Declarations">
<head>Attribute Declarations</head>
<p>Attribute declarations provide for:</p>
<ulist>
<item><p>Local <termref def="key-vn">validation</termref> of attribute information item values using a simple type definition;</p></item>
<item><p>Specifying default or fixed values for attribute information items.</p></item>
<propdef id="a-scope" name="scope">Optional. Either <pt>global</pt> or a complex type
definition.</propdef>
<propdef id="a-value_constraint" name="value constraint">Optional. A pair
consisting of a value and one of <pt>default</pt>, <pt>fixed</pt>.</propdef>
<propdef id="a-annotation" name="annotation">Optional. An annotation.</propdef>
</proplist>
</compdef>
<p>The <propref ref="a-name"/> property must match the local part of the names of attributes being <termref def="key-vn">validated</termref>.</p>
<p>The value of the attribute must conform to the supplied <propref ref="a-simple_type_definition"/>.</p>
<p>A non-<termref def="key-null">absent</termref> value of the <propref ref="a-target_namespace"/> property provides for <termref def="key-vn">validation</termref> of
namespace-qualified attribute information items (which must be explicitly
prefixed in the character-level form of XML documents). <termref def="key-null">Absent</termref> values of
<p>A <propref ref="a-scope"/> of <pt>global</pt> 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 <propref ref="a-scope"/> property. This property is <termref def="key-null">absent</termref> in the case of declarations within attribute group definitions: their scope will be determined when they are used in the construction of complex type definitions.
</p>
<p><propref ref="a-value_constraint"/> reproduces the functions of XML 1.0 default and <code>#FIXED</code>
attribute values. <pt>default</pt> specifies that the attribute is to appear unconditionally in
the &PSVI;, with the supplied value used
whenever the attribute is not actually present; <pt>fixed</pt> indicates that the attribute value if present must equal the supplied
constraint value, and if absent receives the supplied value as for
<pt>default</pt>. Note that it is <emph>values</emph> that are supplied and/or
checked, not strings.</p>
<p>See <specref ref="cAnnotations"/> for information on the role of the
<propref ref="a-annotation"/> property.</p>
<note><p>A more complete and formal presentation of the semantics of <propref ref="a-name"/>, <propref ref="a-target_namespace"/> and <propref ref="a-value_constraint"/> is provided in
conjunction with other aspects of complex type <termref def="key-vn">validation</termref> (see <specref ref="cvc-complex-type"/>.)</p></note>
<p><bibref ref="ref-xmlinfo"/> distinguishes attributes with names such as <code>xmlns</code> or <code>xmlns:xsl</code> from
ordinary attributes, identifying them as <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">namespace attributes</xpropref>. Accordingly, it is unnecessary and in fact not possible for
schemas to contain attribute declarations corresponding to such
namespace declarations, see <specref ref="no-xmlns"/>. No means is provided in
this specification to supply a
default value for a namespace declaration.</p>
</div3>
<div3 id="declare-attribute">
<head>XML Representation of Attribute Declaration Schema Components</head>
<p>The XML representation for an attribute declaration schema component is an
<eltref ref="attribute"/> element information item. It specifies a simple type
definition for an attribute either by reference or explicitly, and may provide default information. The correspondences between the
properties of the information item and
properties of the component are as follows:</p>
<reprdef>
<reprelt eltname="attribute" type="attribute"/>
<p>If the <eltref ref="attribute"/> element information item has <eltref ref="schema"/> as its parent, the corresponding schema component is as follows:</p>
<propmap name="required"><pt>true</pt> if the <code>use</code>
&i-attribute; is present with &v-value; <code>required</code>, otherwise
<pt>false</pt>.</propmap>
<propmap name="attribute">The (top-level) attribute declaration <termref def="src-resolve">resolved</termref> to by the
&v-value; of the <code>ref</code> &i-attribute;</propmap>
<propmap name="au-value_constraint">If there is a <code>default</code> or a <code>fixed</code>
&i-attribute;, then a pair consisting of the &v-value; (with respect to the
<propref ref="a-simple_type_definition"/> of the <propref ref="attribute"/>) of that &i-attribute; and
either <pt>default</pt> or <pt>fixed</pt>, as appropriate, otherwise <termref def="key-null">absent</termref>.</propmap>
</reprcomp>
</reprdef>
<p>Attribute declarations can appear at the top level of a schema document, or within complex
type definitions, either as complete (local) declarations, or by reference to top-level
declarations, or within attribute group definitions. For complete declarations, top-level or local, the <code>type</code> attribute is used when the declaration can use a
built-in or pre-declared simple type definition. Otherwise an
anonymous <eltref ref="simpleType"/> is provided inline.</p>
<p>The default when no simple type definition is referenced or
provided is the simple <termref def="key-urType">ur-type definition</termref>, which imposes no constraints at all.</p>
<p>Attribute information items <termref def="key-vn">validated</termref> by a top-level declaration must be qualified with the
<propref ref="a-target_namespace"/> of that declaration (if this is <termref def="key-null">absent</termref>, the item must be unqualified). Control over whether attribute information items
<termref def="key-vn">validated</termref> by a local declaration must be similarly qualified or not
is provided by the <code>form</code> &i-attribute;, whose default is provided
by the <code>attributeFormDefault</code> &i-attribute; on the enclosing <eltref ref="schema"/>, via its determination of <propref ref="a-target_namespace"/>.</p>
<p>The names for top-level attribute declarations are in their own
<termref def="key-symbolSpace">symbol space</termref>. The names of locally-scoped
attribute declarations reside in symbol spaces local to the type definition which contains
them.</p>
</div3>
<div3>
<head>Constraints on XML Representations of Attribute Declarations</head>
<p>For an attribute information item to be locally <termref def="key-vn">valid</termref> with respect to an
attribute declaration
<olist role="and">
<item id="c-a1">
<p>The declaration must not be <termref def="key-null">absent</termref> (see <specref ref="conformance-missing"/> for
how this can fail to be the case).</p>
</item>
<item id="c-a2">
<p>Its <propref ref="a-simple_type_definition"/> must not be absent.</p>
</item>
<item id="c-sva">
<p>The item's &i-value; must be locally <termref def="key-vn">valid</termref> with respect to that <propref ref="a-simple_type_definition"/> as per <specref ref="cvc-simple-type"/>.</p>
</item>
<item>
<p>The item's &v-value; must match the value of the <propref ref="a-value_constraint"/>, if it is
<p>A declaration which has been established as its <termref def="key-dd">context-determined declaration</termref>;</p>
</item>
<item id="c-adbyr">
<p>A declaration resolved to by its <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">local name</xpropref> and <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">namespace name</xpropref> as defined by <specref ref="cvc-resolve-instance"/>, provided its <termref def="key-dd">context-determined declaration</termref> is
not <pt>skip</pt>.</p>
</item>
</olist>
</p>
</item>
<item>
<p>Its <termref def="key-vn">validity</termref> with respect to that
declaration must have been evaluated as per <specref ref="cvc-attribute"/>.</p>
</item>
<item>
<p>Both <clauseref ref="c-a1"/> and <clauseref ref="c-a2"/> of <specref ref="cvc-attribute"/> must be satisfied.</p>
</item>
</olist>
</p>
<p><termdef id="key-svaa" term="strictly assessed" role="local">For attributes, there is no
difference between assessment and strict assessment, so if the above holds, the attribute information item has been <term>strictly assessed</term></termdef>.</p>
</constraintnote>
</div3>
<div3>
<head>Attribute Declaration Information Set Contributions</head>
<constraintnote id="sic-a-outcome" type="sic">
<head>Assessment Outcome (Attribute)</head>
<p>If the schema-validity of an attribute information item has been assessed
as per <specref ref="cvc-assess-attr"/>, then in the &PSVI; it has properties as follows:</p>
<proplist role="psvi" item="attribute">
<propdef name="validation context" id="a-validation_context">The nearest ancestor element information
item with a <propref role="psvi" ref="e-schema_information"/> property.</propdef>
<propdef name="validity" id="a-validity">
<olist role="Caseval">
<item>
<p role="if">it was <termref def="key-svaa">strictly assessed</termref></p>
<p role="then">
<olist role="caseval">
<item>
<p role="if">it was
<termref def="key-vn">valid</termref> as defined by <specref ref="cvc-attribute"/></p>
<p role="if">it was <termref def="key-svaa">strictly assessed</termref></p>
<p role="then"><pt>full</pt>;</p>
</item>
<item>
<p role="otherwise"><pt>none</pt>.</p>
</item>
</olist></propdef>
<propdef name="schema specified" id="a-schema_specified"><pt>infoset</pt>. See <specref ref="sic-attrDefault"/> for the other possible value.</propdef>
<propdef name="member type definition" id="a-member_type_definition">If
and only if that type definition has <propref ref="variety"/> <pt>union</pt>, then an
<termref def="key-iso">item isomorphic</termref> to that member of its <propref ref="st-member_type_definitions"/> which actually <termref def="key-vn">validated</termref> the attribute item's <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">normalized value</xpropref>.</propdef>
<propdef id="a-type_definition_namespace" name="type definition namespace">The <propref ref="st-target_namespace"/> of the <termref def="key-typeDefn">type definition</termref>.</propdef>
<propdef name="type definition anonymous" id="a-type_definition_anonymous"><pt>true</pt> if the <propref ref="st-name"/> of the <termref def="key-typeDefn">type definition</termref> is <termref def="key-null">absent</termref>, otherwise <pt>false</pt>.</propdef>
<propdef name="type definition name" id="a-type_definition_name">The <propref ref="st-name"/> of the <termref def="key-typeDefn">type definition</termref>, if it is not <termref def="key-null">absent</termref>. If it is
<termref def="key-null">absent</termref>, schema processors may, but need not,
provide a value unique to the definition.</propdef>
</proplist>
<p>If the <termref def="key-typeDefn">type definition</termref> has <propref ref="variety"/> <pt>union</pt>, then calling
<termdef id="a-key-amt" term="actual member type definition" role="local"> that
member of the <propref ref="st-member_type_definitions"/> which actually
<termref def="key-vn">validated</termref> the attribute item's &i-value; the
<term>actual member type definition</term></termdef>, there are three additional properties:</p>
<proplist role="psvi" item="attribute">
<propdef name="member type definition namespace" id="a-member_type_definition_namespace">The <propref ref="st-target_namespace"/> of the <termref def="a-key-amt">actual
member type definition</termref>.</propdef>
<propdef name="member type definition anonymous" id="a-member_type_definition_anonymous"><pt>true</pt> if the <propref ref="st-name"/> of the <termref def="a-key-amt">actual member type definition</termref> is <termref def="key-null">absent</termref>, otherwise <pt>false</pt>.</propdef>
<propdef name="member type definition name" id="a-member_type_definition_name">The <propref ref="st-name"/> of the <termref def="a-key-amt">actual member type definition</termref>, if it is not <termref def="key-null">absent</termref>. If it is
<termref def="key-null">absent</termref>, schema processors may, but need not,
provide a value unique to the definition.</propdef>
</proplist>
<p>The first (<termref def="key-iso">item isomorphic</termref>) alternative above is provided for applications such as query
processors which need access to the full range of details about an item's
<termref def="key-va">assessment</termref>, for example the type hierarchy; the second, for lighter-weight
processors for whom representing the significant parts of the type hierarchy as
information items might be a significant burden.</p>
<p>Also, if the declaration has a <propref ref="a-value_constraint"/>, the
The <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-canonical-representation">canonical lexical representation</xtermref> of
the declaration's <propref ref="a-value_constraint"/> value.
</propdef>
</proplist>
<p>If the attribute information item was not <termref def="key-svaa">strictly assessed</termref>, then instead of the values specified above,
<p>The values of the properties of an attribute declaration must be as described in
the property tableau in
<specref ref="Attribute_Declaration_details"/>, modulo the impact of <specref ref="conformance-missing"/>.</p>
</item>
<item>
<p>if there is a <propref ref="a-value_constraint"/>, the <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-canonical-representation">canonical lexical representation</xtermref> of its value must be
<termref def="key-vn">valid</termref> with respect to the <propref ref="a-simple_type_definition"/> as
defined in <specref ref="cvc-simple-type"/>.
</p>
</item>
<item>
<p>If the <propref ref="a-simple_type_definition"/> is or is derived from <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#ID">ID</xtermref> then there must not be a <propref ref="a-value_constraint"/>.</p>
</item>
</olist>
</constraintnote>
<constraintnote type="cos" id="no-xmlns">
<head><code>xmlns</code> Not Allowed</head>
<p>The <propref ref="a-name"/> of an attribute declaration must not match <code>xmlns</code>.</p>
<note>
<p>The <propref ref="a-name"/> of an attribute is an <termref def="gloss-NCName">NCName</termref>, which implicitly
prohibits attribute declarations of the form <code>xmlns:*</code>.</p>
</note>
</constraintnote>
<constraintnote type="cos" id="no-xsi">
<head><code>xsi:</code> Not Allowed</head>
<p>The <propref ref="a-target_namespace"/> of an attribute declaration,
whether local or top-level, must not match <code>http://www.w3.org/2001/XMLSchema-instance</code>
(unless it is one of the four built-in declarations given in the next section).</p>
<note>
<p>This reinforces the special status of these attributes, so that they not
only <emph>need</emph> not be declared to be allowed in instances, but
<emph>must</emph> not be declared. It also removes any temptation to experiment with supplying global or fixed values
for e.g. <code>xsi:type</code> or <code>xsi:nil</code>, which would be
seriously misleading, as they would have no effect.</p>
</note>
</constraintnote>
</div3>
<div3>
<head>Built-in Attribute Declarations</head>
<p>There are four attribute declarations present in every
schema by definition:</p>
<schemaComp id="xsi.type">
<head>Attribute Declaration for the 'type' attribute</head>
<propdef id="e-annotation" name="annotation">Optional. An annotation.</propdef>
</proplist>
</compdef>
<p>The <propref ref="e-name"/> property must match the local part of the names
of element information items being <termref def="key-vn">validated</termref>.</p>
<p>A <propref ref="e-scope"/> of <pt>global</pt> 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 <propref ref="e-scope"/> property. This property is <termref def="key-null">absent</termref> in the case of declarations within named model groups: their scope is determined when they are used in the construction of complex type definitions.</p>
<p>A non-<termref def="key-null">absent</termref> value of the <propref ref="e-target_namespace"/> property provides for <termref def="key-vn">validation</termref> of
namespace-qualified element information items. <termref def="key-null">Absent</termref> values of
<p>An element information item is <termref def="key-vn">valid</termref>
if it satisfies the <propref ref="type_definition"/>. For such an
item, schema information set contributions appropriate to the <propref ref="type_definition"/> are added to the
corresponding element information item in the &PSVI;.
</p>
<p>If <propref ref="nillable"/> is <pt>true</pt>, then an element may
also be <termref def="key-vn">valid</termref> if it
carries the namespace qualified attribute with <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">local name</xpropref> <code>nil</code> from namespace <code>http://www.w3.org/2001/XMLSchema-instance</code> and value <code>true</code> (see <specref ref="xsi_nil"/>) even if it has
no text or element content despite a <propref ref="content_type"/> which would
otherwise require content. Formal details of element <termref def="key-vn">validation</termref> are described in <specref ref="cvc-elt"/>.</p>
<p><propref ref="e-value_constraint"/> establishes a default or fixed value for an element. If <pt>default</pt> is specified, and if the element
being <termref def="key-vn">validated</termref> is empty, then the
canonical form of the supplied
constraint value becomes the <propref role="psvi" ref="e-schema_normalized_value"/> of the <termref def="key-vn">validated</termref> element in the &PSVI;. If <pt>fixed</pt> is specified, then the element's content
must either be empty, in which case <pt>fixed</pt> behaves as <pt>default</pt>,
or its value must match the supplied constraint value.</p>
<note>
<p>The provision of defaults for elements goes beyond what is possible in
XML 1.0 DTDs, and does not exactly correspond to defaults for attributes. In
particular, an element with a non-empty <propref ref="e-value_constraint"/> whose simple
type definition includes the empty string in its lexical space will
nonetheless never receive that value, because the <propref ref="e-value_constraint"/> will override it.</p>
</note>
<p><propref ref="&constraint;_definitions"/> express constraints establishing uniquenesses and reference relationships among the values of related elements and
attributes. See <specref ref="c&Constraint;_Definitions"/>.</p>
<p>Element declarations are members of the substitution group, if any, identified
by <propref ref="class_exemplar"/>. Membership is transitive but not symmetric; an element
declaration is a member of any group of which its <propref ref="class_exemplar"/> is a member.</p>
<p>An empty <propref ref="e-final"/> allows a declaration to be nominated as
the <propref ref="class_exemplar"/> of other element declarations having the same <propref ref="type_definition"/> or
types derived therefrom. The explicit
values of <propref ref="e-final"/> rule out element declarations having types which
are <pt>extension</pt>s or <pt>restriction</pt>s respectively of <propref ref="type_definition"/>. If
both values are specified, then the declaration may not be nominated as the
<propref ref="class_exemplar"/> of any other declaration.</p>
<p>The supplied values for <propref ref="e-exact"/> determine
whether an element declaration appearing in a <termref def="key-contentModel">content model</termref> will be prevented from additionally
<termref def="key-vn">validating</termref> elements (a) with an <specref ref="xsi_type"/> that identifies an
<pt>extension</pt> or <pt>restriction</pt> of the type of the declared element, and/or (b) from <termref def="key-vn">validating</termref> elements which are in the
substitution group headed by the declared element.
If <propref ref="e-exact"/> is empty, then all derived types and substitution group members are allowed.</p>
<p>Element declarations for which <propref ref="e-abstract"/> is <pt>true</pt> can appear in
content models only when substitution is allowed;
such declarations may not themselves ever be used to <termref def="key-vn">validate</termref> element content.</p>
<p>See <specref ref="cAnnotations"/> for information on the role of the
<propref ref="e-annotation"/> property.</p>
</div3>
<div3 id="declare-element">
<head>XML Representation of Element Declaration Schema Components</head>
<p>The XML representation for an element declaration schema component is an
<eltref ref="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:</p>
<reprdef>
<reprelt eltname="element" type="element"/>
<p>If the <eltref ref="element"/> element information item has <eltref ref="schema"/> as its parent, the corresponding schema component is as follows:</p>
<propmap name="type_definition">The type definition
corresponding to the <eltref ref="simpleType"/> or <eltref ref="complexType"/> element information item in the
&i-children;, if either is present, otherwise the type definition <termref def="src-resolve">resolved</termref> to by
the &v-value; of the <code>type</code> &i-attribute;, otherwise the <propref ref="type_definition"/> of the element declaration <termref def="src-resolve">resolved</termref> to by the &v-value; of the <code>substitutionGroup</code> &i-attribute;, if present, otherwise the
<propmap name="nillable">The &v-value; of the <code>nillable</code>
&i-attribute;, if present, otherwise <pt>false</pt>.</propmap>
<propmap name="e-value_constraint">If there is a <code>default</code> or a <code>fixed</code>
&i-attribute;, then a pair consisting of the &v-value; (with respect to the
<propref ref="type_definition"/>, if it is a simple type definition, or the
<propref ref="type_definition"/>'s <propref ref="content_type"/>, if that is a
simple type definition, or else with respect to the built-in <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#string">string</xtermref> simple type definition) of that &i-attribute; and
either <pt>default</pt> or <pt>fixed</pt>, as appropriate, otherwise <termref def="key-null">absent</termref>.</propmap>
<propmap name="&constraint;_definitions">A set consisting of the
&constraint;-definitions corresponding to all the <eltref ref="key"/>, <eltref ref="unique"/> and <eltref ref="keyref"/> element information items in the
&i-children;, if any, otherwise the empty set.</propmap>
<propmap name="class_exemplar">The element declaration <termref def="src-resolve">resolved</termref> to by the
&v-value; of the
<code>substitutionGroup</code> &i-attribute;, if present, otherwise <termref def="key-null">absent</termref>.</propmap>
<propmap name="e-exact">A set depending on the &v-value; of the
<code>block</code> &i-attribute;, if present, otherwise on the &v-value; of the
<code>blockDefault</code> &i-attribute; of the ancestor <eltref ref="schema"/> element
information item, if present, otherwise on the empty string. Call this the <local>EBV</local> (for effective block value). Then the value of this property is
<olist role="caseval">
<item>
<p role="if">the <local>EBV</local> is the empty string</p>
<p role="then">the empty set;</p>
</item>
<item>
<p role="if">the <local>EBV</local> is <code>#all</code></p>
<p role="otherwise">a set with members drawn from the set above, each being present or
absent depending on whether the &v-value; (which is a list) contains an
equivalently named item.
<note>
<p>Although the <code>blockDefault</code> &i-attribute; of <eltref ref="schema"/> may include values other than <pt>extension</pt>, <pt>restriction</pt> or <pt>substitution</pt>, those values are ignored in the determination of <propref ref="e-exact"/> for element declarations (they <emph>are</emph> used elsewhere).</p>
</note>
</p>
</item>
</olist>
</propmap>
<propmap name="e-final">As for <propref ref="e-exact"/> above, but using the
<code>final</code> and <code>finalDefault</code> &i-attributes; in place of the
<code>block</code> and <code>blockDefault</code>
&i-attributes; and with the
relevant set being <code>{</code><pt>extension</pt>, <pt>restriction</pt><code>}</code>.</propmap>
<propmap name="e-abstract">The &v-value; of the <code>abstract</code>
&i-attribute;, if present, otherwise <pt>false</pt>.</propmap>
<propmap name="e-annotation">The annotation corresponding to the <eltref ref="annotation"/> element information item in the
&i-children;, if present, otherwise <termref def="key-null">absent</termref>.</propmap>
</reprcomp>
<p>otherwise if the <eltref ref="element"/> element information item has
<eltref ref="complexType"/> or <eltref ref="group"/> as an ancestor and the
<code>ref</code> &i-attribute; is absent, the corresponding schema components
are as follows (unless <code>minOccurs=maxOccurs=0</code>, in which case the item
<propmap name="p-min_occurs">The &v-value; of the <code>minOccurs</code>
&i-attribute;, if present, otherwise <code>1</code>.</propmap>
<propmap name="p-max_occurs"><pt>unbounded</pt>, if the <code>maxOccurs</code>
&i-attribute; equals <pt>unbounded</pt>, otherwise the &v-value; of the <code>maxOccurs</code>
&i-attribute;, if present, otherwise <code>1</code>.</propmap>
<propmap name="term">A (local) element declaration as given below.</propmap>
</reprcomp>
<p>
An element declaration as in the first case above, with the exception of its <propref ref="e-target_namespace"/> and <propref ref="e-scope"/> properties, which are as below:</p>
<propmap name="p-min_occurs">The &v-value; of the <code>minOccurs</code>
&i-attribute;, if present, otherwise <code>1</code>.</propmap>
<propmap name="p-max_occurs"><pt>unbounded</pt>, if the <code>maxOccurs</code>
&i-attribute; equals <pt>unbounded</pt>, otherwise the &v-value; of the <code>maxOccurs</code>
&i-attribute;, if present, otherwise <code>1</code>.</propmap>
<propmap name="term">The (top-level) element declaration <termref def="src-resolve">resolved</termref> to by the
&v-value; of the <code>ref</code> &i-attribute;.</propmap>
</reprcomp>
</reprdef>
<p><eltref ref="element"/> corresponds to an element declaration, and allows
the type definition of that declaration to be specified either by reference or
by explicit inclusion.</p>
<p><eltref ref="element"/>s within <eltref ref="schema"/> produce
<pt>global</pt> element declarations; <eltref ref="element"/>s within <eltref ref="group"/> or <eltref ref="complexType"/> produce either particles which contain <pt>global</pt> element declarations (if there's a <code>ref</code> attribute) or local declarations (otherwise). For complete declarations, top-level or local, the <code>type</code> attribute is used when the declaration can use a
built-in or pre-declared type definition. Otherwise an
anonymous <eltref ref="simpleType"/> or <eltref ref="complexType"/> is provided inline.</p>
<p>Element information items <termref def="key-vn">validated</termref> by a top-level declaration must be qualified with the
<propref ref="e-target_namespace"/> of that declaration (if this is <termref def="key-null">absent</termref>, the item must be unqualified). Control over whether element information items <termref def="key-vn">validated</termref> by a local declaration must be similarly qualified or not
is provided by the <code>form</code> &i-attribute;, whose default is provided
by the <code>elementFormDefault</code> &i-attribute; on the enclosing <eltref ref="schema"/>, via its determination of <propref ref="e-target_namespace"/>.</p>
<p>As noted above the names for top-level element declarations are in a separate
<termref def="key-symbolSpace">symbol space</termref> from the symbol spaces for
the names of type definitions, so there can (but need
not be) a simple or complex type definition with the same name as a
top-level element. As with attribute names, the names of locally-scoped
element declarations with no <propref ref="e-target_namespace"/> reside in symbol spaces local to the type definition which contains
them.</p>
<p>Note that the above allows for two levels of defaulting for unspecified
type definitions. An <eltref ref="element"/> with no referenced or included type definition will
correspond to an element declaration which has the same type definition as the
head of its substitution group if it identifies one, otherwise the <termref def="key-urType">ur-type definition</termref>. This has the important consequence that the minimum valid element declaration, that is, one with only a <code>name</code> attribute and no contents, is also the most general, validating any combination of text and element content and allowing any attributes.</p>
<p>See below at <specref ref="declare-key"/> for <eltref ref="key"/>, <eltref ref="unique"/> and <eltref ref="keyref"/>.</p>
<p>An example from a previous version of the schema for datatypes. The
<code>facet</code> type is defined
and the <code>facet</code> element is declared to use it. The <code>facet</code> element is abstract -- it's
<emph>only</emph> defined to stand as the head for a substitution group. Two further
elements are declared, each a member of the <code>facet</code> substitution group. Finally a type is defined which refers to <code>facet</code>, thereby
allowing <emph>either</emph> <code>period</code> or <code>encoding</code> (or
any other member of the group).</p>
</note>
</div3>
<div3>
<head>Constraints on XML Representations of Element Declarations</head>
<code>fixed</code>, <code>form</code>, <code>block</code> and <code>type</code> must be absent,
i.e. only <code>minOccurs</code>, <code>maxOccurs</code>, <code>id</code> are
allowed in addition to <code>ref</code>, along with <eltref ref="annotation"/>.</p>
</item>
</olist>
</p>
</item>
<item>
<p><code>type</code> and either <eltref ref="simpleType"/> or <eltref ref="complexType"/> are mutually exclusive.</p>
</item>
<item>
<p>The corresponding particle and/or element declarations must satisfy the conditions set
out in <specref ref="coss-element"/> and <specref ref="coss-particle"/>.</p>
</item>
</olist>
</p>
</constraintnote>
</div3>
<div3>
<head>Element Declaration Validation Rules</head>
<constraintnote type="cvc" id="cvc-elt">
<head>Element Locally Valid (Element)</head>
<p>For an element information item to be locally <termref def="key-vn">valid</termref> with respect to an
element declaration
<olist role="and">
<item id="c-ea">
<p>The declaration must not be <termref def="key-null">absent</termref>.</p>
</item>
<item>
<p>Its
<propref ref="e-abstract"/> must be <pt>false</pt>.</p>
</item>
<item>
<olist role="Case">
<item>
<p role="if"><propref ref="nillable"/> is <pt>false</pt></p>
<p role="then">there must be no attribute information item among the element
information item's &i-attributes; whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">namespace name</xpropref> is identical to <code>http://www.w3.org/2001/XMLSchema-instance</code> and whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">local name</xpropref> is <code>nil</code>.</p>
</item>
<item id="c-nl">
<p role="if"><propref ref="nillable"/> is <pt>true</pt> and there is such an attribute
information item and its &v-value; is <code>true</code>
</p>
<p role="then">
<olist role="and">
<item>
<p>The element information item must have no character or element information item
&i-children;.</p>
</item>
<item>
<p>There must be no <pt>fixed</pt> <propref ref="e-value_constraint"/>.</p>
</item>
</olist></p>
</item>
</olist>
</item>
<item>
<p>If there is an attribute information item among the element
information item's &i-attributes; whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">namespace name</xpropref> is identical to <code>http://www.w3.org/2001/XMLSchema-instance</code> and whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">local name</xpropref> is <code>type</code>, then
<olist role="and">
<item>
<p>The &i-value; of that attribute information item must be
<termref def="key-vn">valid</termref> with respect to the built-in <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#QName">QName</xtermref> simple type, as defined by <specref ref="cvc-simple-type"/>;</p>
</item>
<item>
<p>The <termref def="q-local">local name</termref> and <termref def="q-uri">namespace name</termref> (as defined in <specref ref="src-qname"/>), of the &v-value; of that attribute information item must resolve to a type definition, as defined in <specref ref="cvc-resolve-instance"/> -- <termdef id="key-ltd" term="local type definition" role="local">call this type definition the <term>local type definition</term></termdef>;</p></item>
<item>
<p>The <termref def="key-ltd">local type definition</termref> must be
validly derived from the <propref ref="type_definition"/> given the
union of the <propref ref="e-exact"/> and the <propref ref="type_definition"/>'s <propref ref="ct-exact"/>, as defined in <specref ref="cos-ct-derived-ok"/> (if it is a complex type definition), or given <propref ref="e-exact"/> as defined in <specref ref="cos-st-derived-ok"/> (if it is a simple type definition).</p>
</item>
</olist>
<termdef id="key-atd" term="actual type definition" role="local">The phrase
<term>actual type definition</term> occurs below. If the above three clauses are satisfied, this
should be understood as referring to the <termref def="key-ltd">local type
definition</termref>, otherwise to the <propref ref="type_definition"/></termdef>.
</p>
</item>
<item>
<olist role="Case">
<item>
<p role="if">the declaration has a <propref ref="e-value_constraint"/>, the item has neither element nor character &i-children; and <clauseref ref="c-nl"/> has not applied</p>
<p role="then">
<olist role="and">
<item>
<p>If the <termref def="key-atd">actual type definition</termref> is a <termref def="key-ltd">local type
definition</termref> then the <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-canonical-representation">canonical lexical representation</xtermref> of the <propref ref="e-value_constraint"/> value must
be a valid default for the <termref def="key-atd">actual
type definition</termref> as defined in <specref ref="cos-valid-default"/>.
</p>
</item>
<item>
<p>The element information item with the <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-canonical-representation">canonical lexical representation</xtermref> of the <propref ref="e-value_constraint"/> value used as its &i-value;
must be <termref def="key-vn">valid</termref> with respect to the <termref def="key-atd">actual type definition</termref> as defined by <specref ref="cvc-type"/>.</p>
</item>
</olist>
</p>
</item>
<item>
<p role="if">the declaration has no <propref ref="e-value_constraint"/> or the item has either element or character &i-children; or <clauseref ref="c-nl"/> has applied</p>
<p role="then"><olist role="and">
<item>
<p>The element information item
must be <termref def="key-vn">valid</termref> with respect to the <termref def="key-atd">actual type definition</termref> as defined by <specref ref="cvc-type"/>.</p>
</item>
<item>
<p>If there is a <pt>fixed</pt> <propref ref="e-value_constraint"/> and
<clauseref ref="c-nl"/> has not applied,
<olist role="and">
<item>
<p>The element information item must have no element information
item &i-children;.</p>
</item>
<item>
<olist role="Case">
<item>
<p role="if">the <propref ref="content_type"/> of the <termref def="key-atd">actual type definition</termref> is <pt>mixed</pt></p>
of the item must match the <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-canonical-representation">canonical lexical representation</xtermref> of the <propref ref="e-value_constraint"/> value.</p>
</item>
<item>
<p role="if">the <propref ref="content_type"/> of the <termref def="key-atd">actual type definition</termref> is a simple type definition</p>
<p role="then">the &v-value; of the item must match the <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-canonical-representation">canonical lexical representation</xtermref> of the <propref ref="e-value_constraint"/> value.</p>
</item>
</olist>
</item>
</olist>
</p>
</item>
</olist></p>
</item>
</olist>
</item>
<item>
<p>The element information item must be <termref def="key-vn">valid</termref> with respect to
each of the <propref ref="&constraint;_definitions"/> as per <specref ref="cvc-&constraint;"/>.</p>
</item>
<item>
<p>If the element information item is the <termref def="key-vr">validation root</termref>, it must be <termref def="key-vn">valid</termref> per <specref ref="cvc-id"/>.</p>
</item>
</olist>
</p>
</constraintnote>
<constraintnote type="cvc" id="cvc-type">
<head>Element Locally Valid (Type)</head>
<p>For an element information item to be locally <termref def="key-vn">valid</termref> with respect to a type definition
<olist role="and">
<item id="c-ct">
<p>The type definition must not be <termref def="key-null">absent</termref>;</p>
</item>
<item>
<p>Its
<propref ref="ct-abstract"/> must be <pt>false</pt>.</p>
</item>
<item>
<olist role="Case">
<item>
<p role="if">the type definition is a simple type
definition</p>
<p role="then">
<olist role="and">
<item><p>The element information item's &i-attributes; must be empty,
excepting those whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">namespace name</xpropref> is identical to <code>http://www.w3.org/2001/XMLSchema-instance</code> and whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">local name</xpropref> is one of <code>type</code>, <code>nil</code>, <code>schemaLocation</code> or <code>noNamespaceSchemaLocation</code>.</p>
</item>
<item>
<p>The element information item must have no element information item &i-children;.</p>
</item>
<item id="c-sv1">
<p>If <clauseref ref="c-nl"/> of <specref ref="cvc-elt"/> did not apply, then the &i-value; must be <termref def="key-vn">valid</termref> with respect to the type definition as defined by <specref ref="cvc-simple-type"/>.</p>
</item>
</olist>
</p>
</item>
<item>
<p role="if">the type definition is a complex type definition</p>
<p role="then">the element information item must be <termref def="key-vn">valid</termref> with respect to the type definition as per <specref ref="cvc-complex-type"/>;</p>
</item>
</olist>
</item>
</olist>
</p>
</constraintnote>
<constraintnote type="cvc" id="cvc-id">
<head>Validation Root Valid (ID/IDREF)</head>
<p>For an element information item which is the <termref def="key-vr">validation root</termref> to be <termref def="key-vn">valid</termref>
<olist role="and">
<item>
<p>There must be no <local>ID/IDREF binding</local> in the item's
<propref ref="e-ii_table" role="psvi"/> whose <propref role="psvi" ref="iib-binding"/> is the
empty set.</p>
</item>
<item id="c-uba">
<p>There must be no <local>ID/IDREF binding</local> in the item's <propref ref="e-ii_table" role="psvi"/> whose <propref role="psvi" ref="iib-binding"/> has more
than one member.</p>
</item>
</olist>
</p>
<p>See <specref ref="sic-id"/> for the definition of <local>ID/IDREF binding</local>.</p>
<note>
<p>The first clause above applies when there is a reference to an
undefined ID. The second applies when there is a multiply-defined ID. They
are separated out to ensure that distinct error codes (see <specref ref="outcomes"/>) are associated with these two cases.</p>
</note>
<note>
<p>Although this rule applies at the <termref def="key-vr">validation
root</termref>, in practice processors, particularly streaming processors, may
wish to detect and signal the <clauseref ref="c-uba"/> case as it arises.</p>
</note>
<note>
<p>This reconstruction of <bibref ref="ref-xml"/>'s <code>ID/IDREF</code>
functionality is imperfect in that if the <termref def="key-vr">validation
root</termref> is not the document element of an XML document, the results will
not necessarily be the same as those a validating parser would give were the
document to have a DTD with equivalent declarations.</p>
</note>
</constraintnote>
<constraintnote id="cvc-assess-elt" type="cvc">
<head>Schema-Validity Assessment (Element)</head>
<p>The schema-validity assessment of an element information item depends
on its <termref def="key-vn">validation</termref> and the <termref def="key-va">assessment</termref> of its element information item
children and associated attribute information items, if any.</p>
<p>So for an element information item's schema-validity to be assessed
<olist role="and">
<item id="c-xd">
<p><olist role="Or">
<item id="c-ed">
<olist role="And">
<item>
<p>A non-<termref def="key-null">absent</termref> element declaration
must be known for it, because</p>
<olist role="ortest">
<item>
<p>A declaration was stipulated by the processor (see <specref ref="validation_outcome"/>).</p>
</item>
<item>
<p>A declaration has been established as its <termref def="key-dd">context-determined declaration</termref>.</p>
</item>
<item>
<olist role="And">
<item>
<p>Its <termref def="key-dd">context-determined declaration</termref> is
not <pt>skip</pt>.</p>
</item>
<item>
<p>Its <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">local name</xpropref> and <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">namespace name</xpropref> resolve to an element declaration as defined by <specref ref="cvc-resolve-instance"/>.</p>
</item>
</olist>
</item>
</olist>
</item>
<item>
<p>Its <termref def="key-vn">validity</termref> with respect to that
declaration must have been evaluated as per <specref ref="cvc-elt"/>.</p>
</item>
<item>
<p>If that evaluation involved the evaluation of <specref ref="cvc-type"/>, <clauseref ref="c-ct"/> thereof must be satisfied.</p>
</item>
</olist>
</item>
<item id="c-td">
<olist role="And">
<item>
<p>A non-<termref def="key-null">absent</termref> type definition is known for
it because
<olist role="ortest">
<item>
<p>A type definition was stipulated by the processor
(see <specref ref="validation_outcome"/>).</p>
</item>
<item>
<olist role="And">
<item>
<p>There is an attribute information item among the element
information item's &i-attributes; whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">namespace name</xpropref> is identical to <code>http://www.w3.org/2001/XMLSchema-instance</code> and whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">local name</xpropref> is <code>type</code>.</p>
</item>
<item>
<p>The &i-value; of that attribute information item is
<termref def="key-vn">valid</termref> with respect to the built-in <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#QName">QName</xtermref> simple type, as defined by <specref ref="cvc-simple-type"/>.</p>
</item>
<item>
<p>The <termref def="q-local">local name</termref> and <termref def="q-uri">namespace name</termref> (as defined in <specref ref="src-qname"/>), of the &v-value; of that attribute information item resolve to a type definition, as defined in <specref ref="cvc-resolve-instance"/> -- <termdef id="key-ltd1" term="item type definition" role="local">call this type definition the <term>local type definition</term></termdef>.</p></item>
<item>
<p>If there is also a processor-stipulated type definition, the <termref def="key-ltd1">local type definition</termref> must be
validly derived from that type definition given its <propref ref="ct-exact"/>,
as defined in <specref ref="cos-ct-derived-ok"/> (if it is a complex type
definition), or given the empty set, as defined in <specref ref="cos-st-derived-ok"/> (if it is a simple type definition).</p>
</item>
</olist>
</item>
</olist>
</p>
</item>
<item>
<p>The element information item's <termref def="key-vn">validity</termref> with respect to the <termref def="key-ltd1">local type definition</termref> (if present and validly derived)
or the processor-stipulated type definition (if no <termref def="key-ltd1">local
type definition</termref> is present) has been evaluated as per <specref ref="cvc-type"/>.</p>
</item>
</olist>
</item>
</olist>
</p>
</item>
<item>
<p>The schema-validity of all the element information items among its
&i-children; has been assessed as per <specref ref="cvc-assess-elt"/>, and the
schema-validity of all the attribute information items among its
&i-attributes; has been assessed as per <specref ref="cvc-assess-attr"/>.</p>
</item>
</olist>
</p>
<p><termdef id="key-sva" term="strictly assessed" role="local">If either case of
<clauseref ref="c-xd"/> above holds, the element information item has been <term>strictly assessed</term></termdef>.</p>
<p>If the item cannot be <termref def="key-sva">strictly
assessed</termref>, because neither <clauseref ref="c-ed"/> nor <clauseref ref="c-td"/> above are satisfied,
<termdef id="key-lva" term="laxly assessed">an element information item's
schema validity may be <term>laxly assessed</term> if its <termref def="key-dd">context-determined declaration</termref> is not <pt>skip</pt> by <termref def="key-vn">validating</termref> with respect to the <termref def="ur-type-itself">ur-type definition</termref> as per <specref ref="cvc-type"/></termdef>.</p>
<note>
<p>In general if <clauseref ref="c-ed"/> above holds
<clauseref ref="c-td"/> does not, and vice versa. When an
<code>xsi:type</code> &i-attribute; is involved, however, <clauseref ref="c-td"/> takes precedence,
as is made clear in <specref ref="cvc-elt"/>.</p>
</note>
</constraintnote>
<note><p>The <propref ref="e-name"/> and <propref ref="e-target_namespace"/> properties are not
mentioned above because they are checked during particle <termref def="key-vn">validation</termref>, as per
<specref ref="cvc-particle"/>.</p></note>
</div3>
<div3>
<head>Element Declaration Information Set Contributions</head>
<constraintnote id="sic-e-outcome" type="sic">
<head>Assessment Outcome (Element)</head>
<p>If the schema-validity of an element information item has been assessed
as per <specref ref="cvc-assess-elt"/>, then in the &PSVI; it has properties as follows:</p>
<proplist role="psvi" item="element">
<propdef name="validation context" id="e-validation_context">The nearest ancestor element information
item with a <propref role="psvi" ref="e-schema_information"/> property (or this element item itself if it has such a property).</propdef>
<propdef name="validity" id="e-validity">
<olist role="Caseval">
<item>
<p role="if">it was <termref def="key-sva">strictly
assessed</termref></p>
<p role="then">
<olist role="caseval">
<item>
<p role="if">
<olist role="andtest">
<item>
<olist role="Ortest">
<item>
<p><clauseref ref="c-ed"/> of <specref ref="cvc-assess-elt"/>
applied and the item was
<termref def="key-vn">valid</termref> as defined by <specref ref="cvc-elt"/>;</p>
</item>
<item>
<p><clauseref ref="c-td"/> of <specref ref="cvc-assess-elt"/>
applied and the item was
<termref def="key-vn">valid</termref> as defined by <specref ref="cvc-type"/>.</p>
</item>
</olist>
</item>
<item>
<p>Neither its &i-children; nor its
&i-attributes; contains an information item (element or attribute respectively) whose <xpropref role="psviAnon">validity</xpropref> is <pt>invalid</pt>.</p>
</item>
<item>
<p>Neither its &i-children; nor its
&i-attributes; contains an information item (element or attribute respectively) with a <termref def="key-dd">context-determined declaration</termref> of
<pt>mustFind</pt> whose <xpropref role="psviAnon">validity</xpropref> is <pt>unknown</pt>.</p>
<item><p role="if"><clauseref ref="c-nl"/> of <specref ref="cvc-elt"/> and <specref ref="sic-eltDefault"/> above have
<emph>not</emph> applied and either the <termref def="key-typeDefn">type definition</termref> is a simple type definition or its <propref ref="content_type"/> is a simple type definition</p>
<p role="then">
the &i-value; of the item as <termref def="key-vn">validated</termref>.</p>
namespace">The <xpropref role="anon">target namespace</xpropref> of the <termref def="key-typeDefn">type definition</termref>.</propdef>
<propdef name="type definition anonymous" id="e-type_definition_anonymous"><pt>true</pt> if the <xpropref role="anon">name</xpropref> of the <termref def="key-typeDefn">type definition</termref> is <termref def="key-null">absent</termref>, otherwise <pt>false</pt>.</propdef>
<propdef name="type definition name" id="e-type_definition_name">The <xpropref role="anon">name</xpropref> of the <termref def="key-typeDefn">type definition</termref>, if it is not <termref def="key-null">absent</termref>. If it is
<termref def="key-null">absent</termref>, schema processors may, but need not,
provide a value unique to the definition.</propdef>
</proplist>
<p>If the <termref def="key-typeDefn">type definition</termref> is a
simple type definition or its <propref ref="content_type"/> is a
simple type definition, and that type
definition has <propref ref="variety"/> <pt>union</pt>, then calling
<termdef id="key-amt" term="actual member type definition" role="local"> that
member of the <propref ref="st-member_type_definitions"/> which actually
<termref def="key-vn">validated</termref> the element item's &i-value; the
<term>actual member type definition</term></termdef>, there are three additional properties:</p>
<proplist role="psvi" item="element">
<propdef name="member type definition namespace" id="e-member_type_definition_namespace">The <propref ref="st-target_namespace"/> of the <termref def="key-amt">actual
member type definition</termref>.</propdef>
<propdef name="member type definition anonymous" id="e-member_type_definition_anonymous"><pt>true</pt> if the <propref ref="st-name"/> of the <termref def="key-amt">actual member type definition</termref> is <termref def="key-null">absent</termref>, otherwise <pt>false</pt>.</propdef>
<propdef name="member type definition name" id="e-member_type_definition_name">The <propref ref="st-name"/> of the <termref def="key-amt">actual member type definition</termref>, if it is not <termref def="key-null">absent</termref>. If it is
<termref def="key-null">absent</termref>, schema processors may, but need not,
provide a value unique to the definition.</propdef>
</proplist>
<p>The first (<termref def="key-iso">item isomorphic</termref>) alternative above is provided for applications such as query
processors which need access to the full range of details about an item's
<termref def="key-va">assessment</termref>, for example the type hierarchy; the second, for lighter-weight
processors for whom representing the significant parts of the type hierarchy as
information items might be a significant burden.</p>
<p>Also, if the declaration has a <propref ref="e-value_constraint"/>, the item has a property:</p>
The <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-canonical-representation">canonical lexical representation</xtermref> of
the declaration's <propref ref="e-value_constraint"/> value.</propdef>
</proplist>
<p>Note that if an element is <termref def="key-lva">laxly assessed</termref>, then the <propref ref="e-type_definition" role="psvi"/> and
<propref ref="e-member_type_definition" role="psvi"/> properties, or their
alternatives, are based on the <termref def="ur-type-itself">ur-type definition</termref>.</p>
</constraintnote>
<constraintnote type="sic" id="sic-eltDefault">
<head>Element Default Value</head>
<p>If the local <termref def="key-vn">validity</termref>, as defined by <specref ref="cvc-elt"/>
above, of an element information item has been assessed,
<p role="if">the item is <termref def="key-vn">valid</termref> with respect to an element
declaration as per <specref ref="cvc-elt"/> and the <propref ref="e-value_constraint"/> is present, but <clauseref ref="c-nl"/>
of <specref ref="cvc-elt"/> above is not satisfied and the item has no element or character information item &i-children;</p>
<p role="then">
<pt>schema</pt>. Furthermore, the
&PSVI; has the <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-canonical-representation">canonical lexical representation</xtermref> of the <propref ref="e-value_constraint"/> value as the
<p>The values of the properties of an element declaration must be as described in
the property tableau in
<specref ref="Element_Declaration_details"/>, modulo the impact of <specref ref="conformance-missing"/>.</p>
</item>
<item>
<p>If there is a <propref ref="e-value_constraint"/>, the <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-canonical-representation">canonical lexical representation</xtermref> of its value must be
<termref def="key-vn">valid</termref> with respect to the <propref ref="type_definition"/> as defined in <specref ref="cos-valid-default"/>.</p>
</item>
<item>
<p>If there is an <propref ref="class_exemplar"/>, the <propref ref="type_definition"/> of the element declaration must
be validly derived from the <propref ref="type_definition"/> of the <propref ref="class_exemplar"/>, given the value of the <propref ref="e-final"/> of the <propref ref="class_exemplar"/>, as defined in <specref ref="cos-ct-derived-ok"/> (if the <propref ref="type_definition"/> is complex) or as defined in <specref ref="cos-st-derived-ok"/> (if the <propref ref="type_definition"/> is simple).
</p>
</item>
<item>
<p>If the <propref ref="type_definition"/> or <propref ref="type_definition"/>'s <propref ref="content_type"/> is or is derived from <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#ID">ID</xtermref> then there must not be a <propref ref="e-value_constraint"/>.</p>
<note>
<p>The use of <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#ID">ID</xtermref> as a type
definition for elements goes beyond XML 1.0, and should be avoided if backwards
compatibility is desired.</p>
</note>
</item>
</olist>
</constraintnote>
<p>The following constraints define relations appealed to elsewhere in this specification.</p>
<p>For a string to be a valid default with respect to a type definition
<olist role="case">
<item>
<p role="if">the type definition is a simple type definition</p>
<p role="then">the string must be
<termref def="key-vn">valid</termref> with respect to that definition as defined by <specref ref="cvc-simple-type"/>.</p>
</item>
<item>
<p role="if">the type definition is a complex type definition</p>
<p role="then">
<olist role="and">
<item>
<p>its <propref ref="content_type"/> must be a simple type definition
or <pt>mixed</pt>.</p>
</item>
<item>
<olist role="Case">
<item>
<p role="if">the <propref ref="content_type"/> is a simple type definition</p>
<p role="then">the string must be
<termref def="key-vn">valid</termref> with respect to that simple type definition as defined by <specref ref="cvc-simple-type"/>.</p>
</item>
<item>
<p role="if">the <propref ref="content_type"/> is <pt>mixed</pt></p>
<p role="then">the <propref ref="content_type"/>'s particle must be <termref def="cd-emptiable">emptiable</termref> as defined by <specref ref="cos-group-emptiable"/>.</p>
<propdef id="content_type" name="content type">One of <pt>empty</pt>, a simple type definition or a pair
consisting of a <termref def="key-contentModel">content model</termref> (I.e. a <specref ref="Particle"/>) and one of <pt>mixed</pt>, <pt>element-only</pt>.
A subset of {<pt>extension</pt>, <pt>restriction</pt>}.
</propdef>
<propdef id="ct-annotations" name="annotations">A set of annotations.</propdef>
</proplist>
</compdef>
<p>Complex types definitions are identified by their <propref ref="ct-name"/> and <propref ref="ct-target_namespace"/>. Except
for anonymous complex type definitions (those with no <propref ref="ct-name"/>), since
type definitions (i.e. both simple and complex type definitions taken together) must be uniquely identified within an <termref def="key-schema">XML
Schema</termref>, no complex type definition can have the same name as another
simple or complex type definition. Complex type <propref ref="ct-name"/>s and <propref ref="ct-target_namespace"/>s
are provided for reference from
instances (see <specref ref="xsi_type"/>), and for use in the XML
representation of schema components
(specifically in <eltref ref="element"/>). See <specref ref="composition-schemaImport"/> for the use of component
identifiers when importing one schema into another.</p>
<note>
<p>The <propref ref="ct-name"/> of a complex type is not <emph>ipso
facto</emph> the <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">(local) name</xpropref> of the
element information items <termref def="key-vn">validated</termref> by that definition. The connection between a
name and a type definition is described in <specref ref="cElement_Declarations"/>. </p>
</note>
<p>As described in <specref ref="Type_Derivation"/>, each complex type is derived from a
<propref ref="ct-base_type_definition"/> which is itself either a <specref ref="Simple_Type_Definition"/> or a <specref ref="Complex_Type_Definition"/>. <propref ref="derivation_method"/> specifies the means of derivation as either <pt>extension</pt> or <pt>restriction</pt> (see <specref ref="Type_Derivation"/>).</p>
<p>A complex type with an empty specification for <propref ref="ct-final"/> can be used as a
<propref ref="ct-base_type_definition"/> for other types derived by either of
extension or restriction; the explicit values <pt>extension</pt>, and <pt>restriction</pt> prevent further
derivations by extension and restriction respectively. If all values are specified, then <termdef id="key-ct-final" term="final">the complex type is said to be
<term>final</term>, because no
further derivations are possible</termdef>. Finality is <emph>not</emph>
inherited, that is, a type definition derived by restriction from a type
definition which is final for extension is not itself, in the absence of any
explicit <code>final</code> attribute of its own, final for anything.</p>
<p>Complex types for which <propref ref="ct-abstract"/> is <pt>true</pt> must
not be used as the
<propref ref="type_definition"/> for the <termref def="key-vn">validation</termref> of element information items. It follows that they must not be referenced from an
<specref ref="xsi_type"/> attribute in an instance document. Abstract complex types can be
used as <propref ref="ct-base_type_definition"/>s, or even as the <propref ref="type_definition"/>s of element declarations, provided in every case a concrete derived type definition is used for <termref def="key-vn">validation</termref>, either via <specref ref="xsi_type"/> or the operation of a substitution group.</p>
<p><propref ref="ct-attribute_declarations"/> are a set of attribute uses. See <specref ref="cvc-complex-type"/>
and <specref ref="cvc-attribute"/> for details of attribute <termref def="key-vn">validation</termref>.</p>
<p><propref ref="ct-attribute_wildcard"/>s provide a more flexible specification for <termref def="key-vn">validation</termref> of
attributes not explicitly included in <propref ref="ct-attribute_declarations"/>.
Informally, the specific values
of <propref ref="ct-attribute_wildcard"/> are interpreted as follows:
<ulist><item>
<p><pt>any</pt>: &i-attributes; can include attributes with any qualified or unqualified name.</p>
</item>
<item>
<p>a set whose
members are either namespace names or <termref def="key-null">absent</termref>: &i-attributes; can
include any attribute(s) from the specified namespace(s). If <termref def="key-null">absent</termref> is included in the set, then any unqualified attributes are (also) allowed.</p>
</item>
<item>
<p><pt>'not'</pt> and a namespace name: &i-attributes; cannot include attributes from the specified namespace.</p>
</item>
<item>
<p><pt>'not'</pt> and <termref def="key-null">absent</termref>: &i-attributes; cannot include
unqualified attributes.</p>
</item></ulist>
See <specref ref="cvc-complex-type"/> and <specref ref="cvc-wildcard-namespace"/> for formal
details of attribute wildcard <termref def="key-vn">validation</termref>. </p>
<p><propref ref="content_type"/> determines the <termref def="key-vn">validation</termref> of &i-children; of element information items. Informally:
<ulist>
<item>
<p>A <propref ref="content_type"/> with the distinguished value <pt>empty</pt> <termref def="key-vn">validates</termref> elements
with no character or element information item &i-children;.</p>
</item>
<item>
<p>A <propref ref="content_type"/> which is a <specref ref="Simple_Type_Definition"/> <termref def="key-vn">validates</termref>
elements with character-only &i-children;.</p>
</item>
<item>
<p>An <pt>element-only</pt> <propref ref="content_type"/> <termref def="key-vn">validates</termref> elements with &i-children; that
conform to the supplied <termref def="key-contentModel">content model</termref>.</p>
</item>
<item>
<p>A <pt>mixed</pt> <propref ref="content_type"/> <termref def="key-vn">validates</termref> elements whose element &i-children; (i.e. specifically ignoring other &i-children; such as character information items)
conform to the supplied <termref def="key-contentModel">content model</termref>.</p>
</item></ulist>
</p>
<p><propref ref="ct-exact"/> determine
whether an element declaration appearing in a <termref def="key-contentModel">
content model</termref> is prevented from additionally
<termref def="key-vn">validating</termref> element items with an <specref ref="xsi_type"/> attribute that
identifies a complex type definition derived by <pt>extension</pt> or
<pt>restriction</pt> from this definition, or element items in
a substitution group whose type definition is similarly derived:
If <propref ref="ct-exact"/> is empty,
then all such substitutions are allowed, otherwise, the derivation method(s) it
names are disallowed.
</p>
<p>See <specref ref="cAnnotations"/> for information on the role of the
<propref ref="ct-annotations"/> property.</p>
</div3>
<div3 id="declare-type">
<head>XML Representation of Complex Type Definitions</head>
<p>The XML representation for a complex type definition schema component is a
<eltref ref="complexType"/> element information item.</p>
<p>The XML representation for complex type definitions with
a simple type definition <propref ref="content_type"/> is significantly different
from that of those with other <propref ref="content_type"/>s, and this
is reflected in the presentation below, which displays first the elements
involved in the first case, then those for the second. The property mapping is shown once for each case.</p>
<p>Whichever alternative for the content of <eltref ref="complexType"/> is
chosen, the following property mappings apply:</p>
<reprcomp abstract="Complex Type Definition" ref="Complex_Type_Definition_details">
<propmap name="ct-name">The &v-value; of the <code>name</code> &i-attribute; if present, otherwise <termref def="key-null">absent</termref>.</propmap>
<propmap name="ct-target_namespace">The &v-value; of the
<code>targetNamespace</code> &i-attribute; of the <eltref ref="schema"/> ancestor
element information item if present, otherwise <termref def="key-null">absent</termref>.</propmap>
<propmap name="ct-abstract">The &v-value; of the <code>abstract</code>
&i-attribute;, if present, otherwise <pt>false</pt>.</propmap>
<propmap name="ct-exact">A set corresponding to the &v-value; of the
<code>block</code> &i-attribute;, if present, otherwise on the &v-value; of the
<code>blockDefault</code> &i-attribute; of the ancestor <eltref ref="schema"/> element
information item, if present, otherwise on the empty string. Call this the <local>EBV</local> (for effective block value). Then the value of this property is
<olist role="caseval">
<item>
<p role="if">the <local>EBV</local> is the empty string</p>
<p role="then">the empty set;</p>
</item>
<item>
<p role="if">the <local>EBV</local> is <code>#all</code></p>
<p role="otherwise">a set with members drawn from the set above, each being present or
absent depending on whether the &v-value; (which is a list) contains an
equivalently named item.
<note>
<p>Although the <code>blockDefault</code> &i-attribute; of <eltref ref="schema"/> may include values other than <pt>restriction</pt> or<pt>extension</pt>, those values are ignored in the determination of <propref ref="ct-exact"/> for complex type definitions (they <emph>are</emph> used elsewhere).</p>
</note>
</p>
</item>
</olist>
</propmap>
<propmap name="ct-final">As for <propref ref="ct-exact"/> above, but using the
<code>final</code> and <code>finalDefault</code> &i-attributes; in place of the
<code>block</code> and <code>blockDefault</code>
&i-attributes;.</propmap>
<propmap name="ct-annotations">The annotations corresponding to the <eltref ref="annotation"/> element information item in the
&i-children;, if present, in the <eltref ref="simpleContent"/> and
<eltref ref="complexContent"/> &i-children;, if present, and in their <eltref ref="restriction" inside="simpleContent"/> and <eltref ref="extension" inside="simpleContent"/> &i-children;, if present, otherwise <termref def="key-null">absent</termref>.</propmap>
</reprcomp>
<p>When the <eltref ref="simpleContent"/> alternative is chosen, the following
elements are relevant, and the remaining property mappings are as below. Note that either
<eltref ref="restriction" inside="simpleContent"/> or <eltref ref="extension" inside="simpleContent"/> must be chosen as the
<reprcomp abstract="Complex Type Definition with simple content" ref="Complex_Type_Definition_details">
<propmap name="ct-base_type_definition">The type definition <termref def="src-resolve">resolved</termref> to by the
&v-value; of the <code>base</code> &i-attribute;</propmap>
<propmap name="derivation_method">If the <eltref ref="restriction" inside="simpleContent"/> alternative
is chosen, then <pt>restriction</pt>, otherwise (the <eltref ref="extension" inside="simpleContent"/> alternative
is chosen) <pt>extension</pt>.</propmap>
<propmap name="ct-attribute_declarations">A union of sets of attribute uses as follows
<olist>
<item id="c-add1">
<p>The set of attribute uses corresponding to the <eltref ref="attribute"/> &i-children;, if any.</p>
</item>
<item id="c-add2">
<p>The <propref ref="ag-attribute_declarations"/> of the
attribute groups <termref def="src-resolve">resolved</termref> to by the &v-value;s of the <code>ref</code>
&i-attribute; of the <eltref ref="attributeGroup" inside="simpleContent"/> &i-children;, if any.</p>
</item>
<item>
<p>if the type definition <termref def="src-resolve">resolved</termref> to by the
&v-value; of the <code>base</code> &i-attribute; is a complex type definition, the
<propref ref="ct-attribute_declarations"/> of that type definition, unless
the <eltref ref="restriction" inside="simpleContent"/> alternative is chosen, in which case some members of
that type definition's <propref ref="ct-attribute_declarations"/> may not be
included, namely those whose
<propref ref="attribute"/>'s
<propref ref="a-name"/> and <propref ref="a-target_namespace"/> are the same as
<olist role="orval">
<item>
<p>the <propref ref="a-name"/> and <propref ref="a-target_namespace"/> of the <propref ref="attribute"/> of an attribute use in the set per <clauseref ref="c-add1"/> or <clauseref ref="c-add2"/> above;</p>
</item>
<item>
<p>what would have been the <propref ref="a-name"/> and <propref ref="a-target_namespace"/> of the <propref ref="attribute"/> of an attribute use in the set per <clauseref ref="c-add1"/> above but for the &v-value; of the <code>use</code> &i-attribute; of the relevant <eltref ref="attribute"/> among the
&i-children; of <eltref ref="restriction" inside="simpleContent"/> being <pt>prohibited</pt>.</p>
</item>
</olist></p>
</item>
</olist>
</propmap>
<propmap name="ct-attribute_wildcard"><termdef id="key-law" term="local wildcard" role="local">Let the <term>local wildcard</term> be defined as</termdef>
<olist role="caseval">
<item>
<p role="if">there is an <eltref ref="anyAttribute"/> present</p>
<p role="then">a wildcard based
on the &v-value;s of the <code>namespace</code> and
<code>processContents</code> &i-attributes; and the <eltref ref="annotation"/> &i-children;, exactly as for the wildcard
corresponding to an <eltref ref="any"/> element as set out in <specref ref="declare-openness"/>;</p>
<p role="if">there are one or more <eltref ref="attributeGroup" inside="simpleContent"/> &i-children; corresponding
to attribute groups with non-<termref def="key-null">absent</termref> <propref ref="ag-attribute_wildcard"/>s</p>
<p role="then">
<olist role="caseval">
<item id="c-awi1">
<p role="if">there is an <eltref ref="anyAttribute"/> present</p>
<p role="then">a wildcard whose <propref ref="process_contents"/> and
<propref ref="w-annotation"/> are those of the <termref def="key-law">local
wildcard</termref>, and whose <propref ref="namespace_constraint"/> is the intensional intersection of the <propref ref="namespace_constraint"/> of the <termref def="key-law">local wildcard</termref>
and of the <propref ref="namespace_constraint"/>s of all the non-<termref def="key-null">absent</termref> <propref ref="ag-attribute_wildcard"/>s of the attribute groups corresponding to the <eltref ref="attributeGroup" inside="simpleContent"/> &i-children;, as defined in <specref ref="cos-aw-intersect"/>.</p>
</item>
<item id="c-awi2">
<p role="if">there is no <eltref ref="anyAttribute"/> present</p>
<p role="then">a wildcard whose properties are as follows:
<glist>
<gitem>
<label><propref ref="process_contents"/></label>
<def>
<p>The <propref ref="process_contents"/> of the first non-<termref def="key-null">absent</termref> <propref ref="ag-attribute_wildcard"/> of an attribute group among the
attribute groups corresponding to the <eltref ref="attributeGroup" inside="simpleContent"/> &i-children;.</p>
<p>The intensional intersection of the <propref ref="namespace_constraint"/>s of all the non-<termref def="key-null">absent</termref> <propref ref="ag-attribute_wildcard"/>s of the attribute groups corresponding to the <eltref ref="attributeGroup" inside="simpleContent"/> &i-children;, as defined in <specref ref="cos-aw-intersect"/>.</p>
<p role="otherwise">a wildcard whose <propref ref="process_contents"/> and
<propref ref="w-annotation"/> are those of the <termref def="key-eaw">complete
wildcard</termref>, and whose <propref ref="namespace_constraint"/> is the intensional union of the <propref ref="namespace_constraint"/> of the <termref def="key-eaw">effective wildcard</termref>
and of the <termref def="key-baw">base wildcard</termref>, as defined in <specref ref="cos-aw-union"/>.</p>
</item>
</olist>
</p>
</item>
</olist>
</p>
</item>
</olist>
</propmap>
<propmap name="content_type">
<olist>
<item><p>if the type definition <termref def="src-resolve">resolved</termref> to by the
&v-value; of the <code>base</code> &i-attribute; is a complex type definition
(whose own <propref ref="content_type"/> must be a
simple type definition, see below) and the <eltref ref="restriction" inside="simpleContent"/> alternative is chosen, then starting from either
<olist>
<item>
<p>the simple type definition corresponding to the <eltref ref="simpleType"/> among
the &i-children; of <eltref ref="restriction" inside="simpleContent"/> if there
is one;</p>
</item>
<item>
<p>otherwise (<eltref ref="restriction" inside="simpleContent"/> has no <eltref ref="simpleType"/> among its
&i-children;), the simple type definition which is the <propref ref="content_type"/> of the type definition <termref def="src-resolve">resolved</termref> to by the
&v-value; of the <code>base</code> &i-attribute;</p>
</item>
</olist>
a simple type definition which restricts that simple type definition with a
set of facet components corresponding to the appropriate element information
items among the <eltref ref="restriction" inside="simpleContent"/>'s
&i-children; (i.e. those which specify facets, if any), as
defined in <specref ref="st-restrict-facets"/>;</p></item>
<item><p>otherwise if the type definition <termref def="src-resolve">resolved</termref> to by the
&v-value; of the <code>base</code> &i-attribute; is a complex type definition
(whose own <propref ref="content_type"/> must be a
simple type definition, see below) and the <eltref ref="extension" inside="simpleContent"/> alternative is chosen, then
the <propref ref="content_type"/> of that complex type definition;</p></item>
<item>
<p>otherwise (the type definition <termref def="src-resolve">resolved</termref> to by the
&v-value; of the <code>base</code> &i-attribute; is a simple type definition and
the <eltref ref="extension" inside="simpleContent"/> alternative is chosen), then
that simple type definition.</p>
</item>
</olist>
</propmap>
</reprcomp>
<p>When the <eltref ref="complexContent"/> alternative is chosen, the following
elements are relevant (as are the <eltref ref="attributeGroup" inside="simpleContent"/> and <eltref ref="anyAttribute"/> elements, not repeated here), and the additional property mappings are as below. Note that either
<eltref ref="restriction" inside="complexContent"/> or <eltref ref="extension" inside="complexContent"/> must be chosen as the
content of <eltref ref="complexContent"/>, but their content models are
different in this case from the case above when they occur as children of
<eltref ref="simpleContent"/>.</p>
<p>The property mappings below are <emph>also</emph> used in the case where
the third alternative (neither <eltref ref="simpleContent"/> nor <eltref ref="complexContent"/>) is chosen. This case is understood as shorthand for complex content restricting the <termref def="key-urType">ur-type definition</termref>, and the details of the mappings should be modified as necessary.</p>
<reprcomp abstract="Complex Type Definition with complex content" ref="Complex_Type_Definition_details">
<propmap name="ct-base_type_definition">The type definition <termref def="src-resolve">resolved</termref> to by the
&v-value; of the <code>base</code> &i-attribute;</propmap>
<propmap name="derivation_method">If the <eltref ref="restriction" inside="complexContent"/> alternative
is chosen, then <pt>restriction</pt>, otherwise (the <eltref ref="extension" inside="complexContent"/> alternative
is chosen) <pt>extension</pt>.</propmap>
<propmap name="ct-attribute_declarations">A union of sets of attribute uses as follows:
<olist>
<item id="c-ad1">
<p>The set of attribute uses corresponding to the <eltref ref="attribute"/> &i-children;, if any.</p>
</item>
<item id="c-ad2">
<p>The <propref ref="ag-attribute_declarations"/> of the
attribute groups <termref def="src-resolve">resolved</termref> to by the &v-value;s of the <code>ref</code>
&i-attribute; of the <eltref ref="attributeGroup" inside="simpleContent"/> &i-children;, if any.</p>
</item>
<item>
<p>The
<propref ref="ct-attribute_declarations"/> of the type definition <termref def="src-resolve">resolved</termref> to by the
&v-value; of the <code>base</code> &i-attribute;, unless
the <eltref ref="restriction" inside="complexContent"/> alternative
is chosen, in which case some members of
that type definition's <propref ref="ct-attribute_declarations"/> may not be
included, namely those whose
<propref ref="attribute"/>'s
<propref ref="a-name"/> and <propref ref="a-target_namespace"/> are the same as
<olist role="orval">
<item>
<p>The <propref ref="a-name"/> and <propref ref="a-target_namespace"/> of the <propref ref="attribute"/> of an attribute use in the set per <clauseref ref="c-ad1"/> or <clauseref ref="c-ad2"/> above;</p>
</item>
<item>
<p>what would have been the <propref ref="a-name"/> and <propref ref="a-target_namespace"/> of the <propref ref="attribute"/> of an attribute use in the set per <clauseref ref="c-ad1"/> above but for the &v-value; of the <code>use</code> &i-attribute; of the relevant <eltref ref="attribute"/> among the
&i-children; of <eltref ref="restriction" inside="complexContent"/> being <pt>prohibited</pt>.</p>
</item>
</olist></p>
</item>
</olist>
</propmap>
<propmap name="ct-attribute_wildcard">As above for the <eltref ref="simpleContent"/> alternative.</propmap>
<propmap name="content_type">
<olist role="Caseval">
<item><p role="if">the <eltref ref="restriction" inside="complexContent"/> alternative is chosen</p>
<p role="then"><olist role="caseval">
<item id="c-cme"><p role="if">
<olist role="ortest">
<item>
<p>There is no <eltref ref="group"/>, <eltref ref="all"/>, <eltref ref="choice"/> or <eltref ref="sequence"/> among the &i-children;;</p>
</item>
<item>
<p>There is an <eltref ref="all"/> or <eltref ref="sequence"/> among
the &i-children; with no &i-children; of its own excluding <eltref ref="annotation"/>;</p>
</item>
<item>
<p>There is a <eltref ref="choice"/> among
the &i-children; with no &i-children; of its own excluding <eltref ref="annotation"/> whose <code>minOccurs</code> &i-attribute; has the &v-value; <code>0</code>;</p>
</item>
</olist>
</p>
<p role="then"><pt>empty</pt>;</p>
</item>
<item>
<p role="otherwise">a pair consisting of
<olist>
<item id="c-mve">
<olist role="caseval">
<item>
<p role="if">the <code>mixed</code> &i-attribute; is present on <eltref ref="complexContent"/></p>
<p role="then"><pt>mixed</pt> if its &v-value; is <code>true</code>, otherwise <pt>elementOnly</pt>;</p>
</item>
<item>
<p role="if">the <code>mixed</code> &i-attribute; is present on
<eltref ref="complexType"/> and its &v-value; is <code>true</code></p>
<p role="then"><pt>mixed</pt>;</p>
</item>
<item>
<p role="otherwise"><pt>elementOnly</pt>.</p>
</item>
</olist>
</item>
<item>
<p>The particle corresponding to
the <eltref ref="all"/>, <eltref ref="choice"/>, <eltref ref="group"/> or
<eltref ref="sequence"/> among the &i-children;.</p>
</item>
</olist>
</p>
</item>
</olist></p>
</item>
<item><p role="if">the <eltref ref="extension" inside="complexContent"/> alternative is chosen</p>
<p role="then"><termdef id="key-exg" term="explicit content" role="local">let the <term>explicit
content</term> be <pt>empty</pt> if any of the sub-clauses of <clauseref ref="c-cme"/> above
applies, otherwise the particle corresponding to
the <eltref ref="all"/>, <eltref ref="choice"/>, <eltref ref="group"/> or
<eltref ref="sequence"/> among the &i-children;</termdef>, and then take
<olist role="caseval">
<item>
<p role="if">the <termref def="key-exg">explicit
content</termref> is <pt>empty</pt></p>
<p role="then">the
<propref ref="content_type"/> of the type definition <termref def="src-resolve">resolved</termref> to
by the &v-value; of the <code>base</code> &i-attribute;</p>
</item>
<item>
<p role="if">the type definition <termref def="src-resolve">resolved</termref> to
by the &v-value; of the <code>base</code> &i-attribute; has a <propref ref="content_type"/> of <pt>empty</pt></p>
<p role="then">a pair of <pt>mixed</pt> or <pt>elementOnly</pt> (determined as per <clauseref ref="c-mve"/> above) and the <termref def="key-exg">explicit content</termref> itself;</p>
</item>
<item>
<p role="otherwise">a pair of <pt>mixed</pt> or <pt>elementOnly</pt> (determined as per
<clauseref ref="c-mve"/> above) and a particle whose properties are as follows:
<glist>
<gitem>
<label><propref ref="p-min_occurs"/></label>
<def>
<p><code>1</code></p>
</def>
</gitem>
<gitem>
<label><propref ref="p-max_occurs"/></label>
<def>
<p><code>1</code></p>
</def>
</gitem>
<gitem>
<label><propref ref="term"/></label>
<def>
<p>A model group whose <propref ref="compositor"/> is
<pt>sequence</pt> and whose <propref ref="particles"/> are the particle of
the <propref ref="content_type"/> of the type definition <termref def="src-resolve">resolved</termref> to
by the &v-value; of the <code>base</code> &i-attribute; followed by the
<p>Aside from the simple coherence requirements enforced above, constraining
type definitions identified as restrictions to actually <emph>be</emph>
restrictions, that is, to <termref def="key-vn">validate</termref> a
subset of the items which are
<termref def="key-vn">validated</termref> by their base type definition, is enforced in <specref ref="coss-ct"/>.</p>
</note>
<note>
<p>The <emph>only</emph> substantive function of the value <pt>prohibited</pt> for the
<code>use</code> attribute of an <eltref ref="attribute"/> is in establishing
the correspondence between a complex type defined by restriction and its XML
representation. It serves to prevent
inheritance of an identically named attribute use from the <propref ref="ct-base_type_definition"/>. Such an <eltref ref="attribute"/> does not correspond to any component, and hence there is no interaction with either explicit or inherited wildcards in the operation of <specref ref="formal-complex-type"/> or <specref ref="coss-ct"/>.</p>
</note>
<p>Careful consideration of the above concrete syntax reveals that
a type definition need consist of no more than a name, i.e. that
<code><complexType name="anyThing"/></code> is allowed.</p>
<p>A further illustration of the abbreviated form, with the
<code>mixed</code> attribute appearing on <code>complexType</code> itself.</p>
</note>
</div3>
<div3>
<head>Constraints on XML Representations of Complex Type Definitions</head>
<constraintnote id="src-ct" type="src">
<head>Complex Type Definition Representation OK</head>
<p>In addition to the conditions imposed on <eltref ref="complexType"/> element
information items by the schema for schemas,
<olist role="and">
<item>
<p>If the <eltref ref="complexContent"/> alternative is chosen, the type definition <termref def="src-resolve">resolved</termref> to
by the &v-value; of the <code>base</code> &i-attribute; must be a complex type definition;</p>
</item>
<item>
<p>If the <eltref ref="simpleContent"/> alternative is chosen, the type definition <termref def="src-resolve">resolved</termref> to
by the &v-value; of the <code>base</code> &i-attribute; must be either a complex type
definition whose <propref ref="content_type"/> is a simple type definition or, only if the
<eltref ref="extension" inside="simpleContent"/> alternative is also chosen, a simple type definition;</p>
</item>
<item>
<p>The corresponding complex type definition component must satisfy the conditions set
out in <specref ref="coss-ct"/>;</p>
</item>
<item>
<p>If <clauseref ref="c-awi1"/> or <clauseref ref="c-awi2"/> in the correspondence specification above for <propref ref="ct-attribute_wildcard"/> is satisfied, the intensional intersection must be expressible, as defined in <specref ref="cos-aw-intersect"/>.</p>
</item>
</olist>
</p>
</constraintnote>
</div3>
<div3 id="formal-complex-type">
<head>Complex Type Definition Validation Rules</head>
<constraintnote type="cvc" id="cvc-complex-type">
<head>Element Locally Valid (Complex Type)</head>
<p>For an element information item to be locally <termref def="key-vn">valid</termref> with respect to a complex type definition
<olist role="and">
<item>
<p><propref ref="ct-abstract"/> is <pt>false</pt>.</p>
</item>
<item>
<p>If <clauseref ref="c-nl"/> of <specref ref="cvc-elt"/> did not
apply, then <olist role="case">
<item>
<p role="if">the <propref ref="content_type"/> is <pt>empty</pt></p>
<p role="then">the element
information item has no character or element information item &i-children;.</p>
</item>
<item id="c-sv2">
<p role="if">the <propref ref="content_type"/> is a simple
type definition</p>
<p role="then">the element information item has no element
information item &i-children;, and the &i-value; of the element information item is <termref def="key-vn">valid</termref> with respect to that simple type definition as defined by <specref ref="cvc-simple-type"/>.</p>
</item>
<item>
<p role="if">the <propref ref="content_type"/> is <pt>element-only</pt></p>
<p role="then">the
element information item has no character information item &i-children; other
than those whose &i-ccode; is defined as a <xtermref href="http://www.w3.org/TR/REC-xml#NT-S">white space</xtermref>
in <bibref ref="ref-xml"/>.</p>
</item>
<item>
<p role="if">the <propref ref="content_type"/> is <pt>element-only</pt> or
<pt>mixed</pt></p>
<p role="then">the sequence of the element information item's element
information item &i-children;, if any, taken in order, is <termref def="key-vn">valid</termref> with
respect to the <propref ref="content_type"/>'s particle, as defined in <specref ref="cvc-particle"/>.</p>
</item>
</olist></p>
</item>
<item id="c-aam">
<p>For each attribute information item in the element information
item's &i-attributes; excepting those whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">namespace name</xpropref> is identical to <code>http://www.w3.org/2001/XMLSchema-instance</code> and whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">local name</xpropref> is one of <code>type</code>, <code>nil</code>, <code>schemaLocation</code> or <code>noNamespaceSchemaLocation</code>,
<olist role="case">
<item id="c-ctma">
<p role="if">there is among the <propref ref="ct-attribute_declarations"/> an
attribute use with an <propref ref="attribute"/> whose
<propref ref="a-name"/> matches the attribute information item's <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">local name</xpropref> and whose <propref ref="a-target_namespace"/> is identical to the attribute information item's <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">namespace name</xpropref> (where an <termref def="key-null">absent</termref> <propref ref="a-target_namespace"/> is taken to be identical to a <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">namespace name</xpropref> with no value)</p>
<p role="then">the attribute information must be <termref def="key-vn">valid</termref> with respect to that attribute use as per <specref ref="cvc-au"/>. In this case the <propref ref="attribute"/> of that attribute use is the <termref def="key-dd">context-determined declaration</termref> for the attribute information item with respect to <specref ref="cvc-assess-attr"/> and <specref ref="sic-a-outcome"/>.</p>
</item>
<item id="c-avaw">
<p role="otherwise">
<olist role="and">
<item>
<p>There must be an <propref ref="ct-attribute_wildcard"/>.</p>
</item>
<item>
<p>The
attribute information item must be <termref def="key-vn">valid</termref> with respect to it as defined in <specref ref="cvc-wildcard"/>.</p>
</item>
</olist>
</p>
</item>
</olist>
</p>
</item>
<item>
<p>The <propref ref="attribute"/> of each attribute use in the <propref ref="ct-attribute_declarations"/> whose
<propref ref="required"/> is <pt>true</pt> matches one of the attribute information items in the element information item's &i-attributes; as per <clauseref ref="c-ctma"/> above.</p>
attribute information item to which <clauseref ref="c-avaw"/> applied and whose <termref def="key-vn">validation</termref> resulted in
a <termref def="key-dd">context-determined declaration</termref> of
<pt>mustFind</pt> or no <termref def="key-dd">context-determined
declaration</termref> at all, and whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">local name</xpropref> and <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">namespace name</xpropref> resolve (as defined by <specref ref="cvc-resolve-instance"/>) to an attribute declaration whose <propref ref="a-simple_type_definition"/> is or is derived from <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#ID">ID</xtermref></termdef>. Then
<olist role="and">
<item>
<p>There must be no more than one item in <termref def="key-ida">wild IDs</termref>.</p>
</item>
<item>
<p>If <termref def="key-ida">wild IDs</termref> is non-empty, there must not be any attribute uses among the <propref ref="ct-attribute_declarations"/> whose <propref ref="attribute"/>'s <propref ref="a-simple_type_definition"/> is or is derived from <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#ID">ID</xtermref>.</p>
</item>
</olist>
<note>
<p>This clause serves to ensure that even via attribute
wildcards no element has more than one attribute of type ID, and that even when
an element legitimately lacks a declared attribute of type ID, a
wildcard-validated attribute must not supply it. That is, if an element has a
type whose attribute declarations include one of type ID, it either has that
attribute or no attribute of type ID.</p>
</note>
</p>
</item>
</olist>
</p>
<note>
<p>When an <propref ref="ct-attribute_wildcard"/> is present, this does
<emph>not</emph> introduce any ambiguity with respect to how attribute
information items for
which an attribute use is present amongst the <propref ref="ct-attribute_declarations"/> whose name and target namespace match are <termref def="key-va">assessed</termref>. In such cases the attribute use <emph>always</emph> takes precedence, and the <termref def="key-va">assessment</termref> of such items stands or falls entirely on the basis of the attribute use and its <propref ref="attribute"/>. This follows from the details of <clauseref ref="c-aam"/>.</p>
</note>
</constraintnote>
</div3>
<div3>
<head>Complex Type Definition Information Set Contributions</head>
<constraintnote type="sic" id="sic-attrDefault">
<head>Attribute Default Value</head>
<p>For each attribute use in the <propref ref="ct-attribute_declarations"/> whose
<propref ref="required"/> is <pt>false</pt> and whose <propref ref="au-value_constraint"/> is not <termref def="key-null">absent</termref> but whose <propref ref="attribute"/> does not match one of the attribute information items in the element information item's &i-attributes; as per <clauseref ref="c-ctma"/> of <specref ref="cvc-complex-type"/> above, the &PSVI; has an attribute information item whose properties are as below added to the
&i-attributes; of the element information item.</p>
<p>The <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-canonical-representation">canonical lexical representation</xtermref> of the <propref ref="au-value_constraint"/> value.</p>
<p>The <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-canonical-representation">canonical lexical representation</xtermref> of the <propref ref="au-value_constraint"/> value.</p>
<p>The added items should also either have <propref role="psvi" ref="a-type_definition"/> (and <propref role="psvi" ref="a-member_type_definition"/> if appropriate) properties, or their lighter-weight alternatives, as specified in <specref ref="sic-attrType"/>.</p>
</constraintnote>
</div3>
<div3 id="coss-ct">
<head>Constraints on Complex Type Definition Schema Components</head>
<p>All complex type definitions (see <specref ref="Complex_Type_Definitions"/>) must satisfy the following constraints.</p>
<constraintnote type="cos" id="ct-props-correct">
<head>Complex Type Definition Properties Correct</head>
<olist role="And">
<item>
<p>The values of the properties of a complex type definition must be as described in
the property tableau in
<specref ref="Complex_Type_Definition_details"/>, modulo the impact of <specref ref="conformance-missing"/>.</p>
</item>
<item>
<p>If the <propref ref="ct-base_type_definition"/> is a simple type
definition, the <propref ref="derivation_method"/> must be <pt>extension</pt>.</p>
</item>
<item><p>Circular definitions are disallowed, except for the <termref def="ur-type-itself">ur-type definition</termref>. That is, it must be possible to reach the <termref def="ur-type-itself">ur-type definition</termref> by repeatedly following the <propref ref="ct-base_type_definition"/>.</p></item>
<item>
<p>Two distinct attribute declarations in the <propref ref="ct-attribute_declarations"/> must not have identical <propref ref="a-name"/>s and <propref ref="a-target_namespace"/>s.</p>
</item>
<item>
<p>Two distinct attribute declarations in the <propref ref="ct-attribute_declarations"/>
must not have <propref ref="a-simple_type_definition"/>s which are or are derived from <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#ID">ID</xtermref>.</p>
</item>
</olist>
</constraintnote>
<constraintnote type="cos" id="cos-ct-extends">
<head>Derivation Valid (Extension)</head>
<p>If the <propref ref="derivation_method"/> is <pt>extension</pt>,
<olist role="case">
<item>
<p role="if">the <propref ref="ct-base_type_definition"/> is a complex type
definition</p>
<p role="then">
<olist role="and">
<item>
<p>The <propref ref="ct-final"/> of the <propref ref="ct-base_type_definition"/> must not contain <pt>extension</pt>.</p>
</item>
<item id="c-cte">
<p>Its <propref ref="ct-attribute_declarations"/> must be a subset
of the <propref ref="ct-attribute_declarations"/> of the complex type
definition itself, that is, for every attribute use in the
<propref ref="ct-attribute_declarations"/> of the
<propref ref="ct-base_type_definition"/>, there must be an attribute use in the <propref ref="ct-attribute_declarations"/> of the complex
type definition itself whose <propref ref="attribute"/> has the same <propref ref="a-name"/>,
<propref ref="a-target_namespace"/> and
<propref ref="a-simple_type_definition"/> as its attribute declaration.</p>
</item>
<item>
<p>If it has an <propref ref="ct-attribute_wildcard"/>, the complex
type definition must also have one, and the base type definition's <propref ref="ct-attribute_wildcard"/>'s <propref ref="namespace_constraint"/> must be a subset of the complex type definition's <propref ref="ct-attribute_wildcard"/>'s <propref ref="namespace_constraint"/>, as defined by <specref ref="cos-ns-subset"/>.</p>
</item>
<item>
<p>
<olist role="Or">
<item>
<p>The <propref ref="content_type"/> of
the <propref ref="ct-base_type_definition"/> and the
<propref ref="content_type"/> of the complex type definition itself must be the
same simple type definition.</p>
</item>
<item>
<olist role="And">
<item>
<p>The
<propref ref="content_type"/> of the complex type definition itself must
specify a particle.</p>
</item>
<item>
<olist role="Or">
<item>
<p>The
<propref ref="content_type"/> of the <propref ref="ct-base_type_definition"/>
must be <pt>empty</pt>.</p>
</item>
<item>
<p>
<olist role="And">
<item>
<p>Both
<propref ref="content_type"/>s must be <pt>mixed</pt> or both must be
<pt>element-only</pt>.</p>
</item>
<item>
<p>The particle of the complex type
definition must be a <termref def="cd-model-extension">valid
extension</termref> of the <propref ref="ct-base_type_definition"/>'s particle,
as defined in <specref ref="cos-particle-extend"/>.</p>
</item>
</olist>
</p>
</item>
</olist>
</item>
</olist>
</item>
</olist>
</p>
</item>
<item>
<p>It must in principle be possible to derive the complex type
definition in two steps, the first an extension and the
second a restriction (possibly vacuous), from that type definition among its
ancestors whose <propref ref="ct-base_type_definition"/> is the <termref def="ur-type-itself">ur-type definition</termref>.</p>
<note>
<p>This requirement ensures that nothing removed by a restriction
is subsequently added back by an extension. It is trivial to check if the
extension in question is the only extension in its derivation, or if there are
no restrictions bar the first from the <termref def="ur-type-itself">ur-type definition</termref>.</p>
<p>Constructing the intermediate type definition to check this
constraint is straightforward: simply re-order the derivation to put all the
extension steps first, then collapse them into a single extension. If the
resulting definition can be the basis for a valid restriction to the desired
definition, the constraint is satisfied.</p>
</note>
</item>
</olist>
</p>
</item>
<item>
<p role="if">the <propref ref="ct-base_type_definition"/> is a simple type
definition</p>
<p role="then">
<olist role="and">
<item>
<p>The <propref ref="content_type"/> must be the same simple type
definition.</p>
</item>
<item>
<p>The <propref ref="st-final"/> of the <propref ref="ct-base_type_definition"/> must not contain <pt>extension</pt>.</p>
</item>
</olist>
</p>
</item>
</olist>
<termdef id="cd-ct-extension" term="valid extension">If this
constraint <specref ref="cos-ct-extends"/> holds of a complex type definition, it is a <term>valid
extension</term> of its <propref ref="ct-base_type_definition"/></termdef>.
<p>If the <propref ref="derivation_method"/> is <pt>restriction</pt>
<olist role="and">
<item>
<p>The <propref ref="ct-base_type_definition"/> must be a complex type
definition whose <propref ref="ct-final"/> does not contain <pt>restriction</pt>.</p>
</item>
<item id="c-rad">
<p>For each attribute use (call this <local>R</local>) in the <propref ref="ct-attribute_declarations"/>
<olist role="case">
<item>
<p role="if">there is an attribute use in the
<propref ref="ct-attribute_declarations"/> of the <propref ref="ct-base_type_definition"/> (call this <local>B</local>) whose <propref ref="attribute"/> has the same <propref ref="a-name"/> and <propref ref="a-target_namespace"/></p>
<p role="then">
<olist role="and">
<item>
<p><olist role="or">
<item>
<p><local>B</local>'s <propref ref="required"/> is <pt>false</pt>.</p>
</item>
<item>
<p><local>R</local>'s <propref ref="required"/> is <pt>true</pt>.</p>
</item>
</olist></p>
</item>
<item>
<p><local>R</local>'s <propref ref="attribute"/>'s <propref ref="a-simple_type_definition"/> must be validly derived from <local>B</local>'s <propref ref="a-simple_type_definition"/> given the
empty set as defined in
<specref ref="cos-st-derived-ok"/>.</p>
</item>
<item>
<p><termdef id="key-evc" term="effective base value constraint" role="local">Let the
<term>effective value constraint</term> of an attribute use be
its <propref ref="au-value_constraint"/>, if present, otherwise
its <propref ref="attribute"/>'s <propref ref="a-value_constraint"/>
</termdef>. Then <olist role="or">
<item>
<p><local>B</local>'s <termref def="key-evc">effective value
constraint</termref> is <termref def="key-null">absent</termref> or <pt>default</pt>.</p>
</item>
<item>
<p><local>R</local>'s <termref def="key-evc">effective value
constraint</termref> is
<pt>fixed</pt> with the same string as <local>B</local>'s.</p>
</item>
</olist>
</p>
</item>
</olist>
</p>
</item>
<item>
<p role="otherwise">the <propref ref="ct-base_type_definition"/> must
have an <propref ref="ct-attribute_wildcard"/> and the <propref ref="a-target_namespace"/> of the <local>R</local>'s <propref ref="attribute"/> must be <termref def="key-vn">valid</termref> with respect to that wildcard, as defined in <specref ref="cvc-wildcard-namespace"/>.</p>
</item>
</olist>
</p>
</item>
<item id="c-rad2">
<p>For each attribute use in the <propref ref="ct-attribute_declarations"/> of
the <propref ref="ct-base_type_definition"/> whose <propref ref="required"/> is
<pt>true</pt>, there must be an attribute use with an <propref ref="attribute"/> with the same <propref ref="a-name"/> and <propref ref="a-target_namespace"/> as its <propref ref="attribute"/> in the
<propref ref="ct-attribute_declarations"/> of the complex type definition
itself whose <propref ref="required"/> is
<pt>true</pt>.</p>
</item>
<item id="c-raw">
<p>If there is an <propref ref="ct-attribute_wildcard"/>,
<olist role="and">
<item>
<p>The
<propref ref="ct-base_type_definition"/> must also have one.</p>
</item>
<item>
<p>The complex
type definition's <propref ref="ct-attribute_wildcard"/>'s <propref ref="namespace_constraint"/> must be a subset of the <propref ref="ct-base_type_definition"/>'s <propref ref="ct-attribute_wildcard"/>'s <propref ref="namespace_constraint"/>, as defined by <specref ref="cos-ns-subset"/>.</p>
</item>
</olist>
</p>
</item>
<item>
<p>
<olist role="Case">
<item>
<p role="if">the <propref ref="content_type"/> of the complex type definition
is a simple type definition</p>
<p role="then">
<olist role="or">
<item>
<p>The <propref ref="content_type"/> of the <propref ref="ct-base_type_definition"/> must be a simple type
definition of which the <propref ref="content_type"/> is a <termref def="cd-st-restriction">valid restriction</termref> as defined in
<specref ref="cos-st-restricts"/>.</p>
</item>
<item>
<p>The <propref ref="ct-base_type_definition"/> must be <pt>mixed</pt>
and have a particle which is <termref def="cd-emptiable">emptiable</termref> as defined in <specref ref="cos-group-emptiable"/>.</p>
</item>
</olist>
</p>
</item>
<item>
<p role="if">the <propref ref="content_type"/> of the complex type itself
is <pt>empty</pt>
</p>
<p role="then">
<olist role="or">
<item>
<p>The <propref ref="content_type"/> of the <propref ref="ct-base_type_definition"/> must also be <pt>empty</pt>.</p>
</item>
<item>
<p>The <propref ref="content_type"/> of the <propref ref="ct-base_type_definition"/> must be <pt>elementOnly</pt> or <pt>mixed</pt> and have a particle which is <termref def="cd-emptiable">emptiable</termref> as defined in <specref ref="cos-group-emptiable"/>.</p>
</item>
</olist>
</p>
</item>
<item>
<p role="if">the <propref ref="content_type"/> of the <propref ref="ct-base_type_definition"/> is <pt>mixed</pt> or the <propref ref="content_type"/> of the complex type definition itself is <pt>element-only</pt></p>
<p role="then">the particle of the complex type definition itself
must be a <termref def="cd-model-restriction">valid restriction</termref> of the particle of the <propref ref="content_type"/> of the <propref ref="ct-base_type_definition"/> as defined in <specref ref="cos-particle-restrict"/>.</p>
</item>
</olist>
</p>
</item>
</olist>
<termdef id="cd-ct-restriction" term="valid restriction">If this
constraint <specref ref="derivation-ok-restriction"/> holds of a complex type definition, it is a <term>valid
restriction</term> of its <propref ref="ct-base_type_definition"/></termdef>.
</p>
</constraintnote>
<note>
<p>To restrict a complex type definition with a simple base type definition
to <pt>empty</pt>, use a simple type definition with a <pt>fixed</pt> value of
the empty string: this preserves the type information.</p>
</note>
<p>The following constraint defines a relation appealed to elsewhere in this specification.</p>
<propref ref="namespace_constraint"/> is <pt>any</pt></pvpair>
<pvpair ref="ct-final">The empty set</pvpair>
<pvpair ref="ct-exact">The empty set</pvpair>
<pvpair ref="ct-abstract"><pt>false</pt></pvpair>
</pvlist>
</schemaComp>
<p>The <code>mixed</code> content specification together with the
unconstrained wildcard content model and attribute specification produce the defining property for the
<termref def="key-urType">ur-type definition</termref>, namely that <emph>every</emph> complex type
definition is (eventually) a restriction
of the <termref def="key-urType">ur-type definition</termref>: its permissions and requirements are
the least restrictive possible.</p>
<note><p>This specification does not provide an inventory of built-in complex
type definitions for use in user schemas. A preliminary library of complex type
definitions is available which includes both mathematical (e.g.
<code>rational</code>) and utility (e.g. <code>array</code>) type definitions.
In particular, there is a <code>text</code> type definition which is recommended for use
as the type definition in element declarations intended for general text
content, as it makes sensible provision for various aspects of
internationalization. For more details, see the schema document for the type
library at its namespace name: <loc href="http://www.w3.org/2001/03/XMLSchema/TypeLibrary.xsd">http://www.w3.org/2001/03/XMLSchema/TypeLibrary.xsd</loc>.</p></note>
</div3>
</div2>
<div2 id="cAttributeUse">
<head>AttributeUses</head>
<p>An attribute use is a utility component which controls the occurrence and
defaulting behavior of attribute declarations. It plays the same role for
attribute declarations in complex types that particles play for element declarations.</p>
<propdef id="au-value_constraint" name="value constraint">Optional. A pair
consisting of a value and one of <pt>default</pt>, <pt>fixed</pt>.</propdef> </proplist>
</compdef>
<p><propref ref="required"/> determines whether this use of an attribute
declaration requires an appropriate attribute information item to be present, or
merely allows it.</p>
<p><propref ref="attribute"/> provides the attribute declaration itself,
which will in turn determine the simple type definition used.</p>
<p><propref ref="au-value_constraint"/> allows for local specification of a
default or fixed value. This must be consistent with that of the <propref ref="attribute"/>, in that if the <propref ref="attribute"/> specifies a fixed value, the only allowed <propref ref="au-value_constraint"/> is the same fixed value.</p>
</div3>
<div3>
<head>XML Representation of Attribute Use Components</head>
<p>Attribute uses correspond to all uses of <eltref ref="attribute"/> which
allow a <code>use</code> attribute. These in turn correspond to
<emph>two</emph> components in each case, an attribute use and its <propref ref="attribute"/> (although note the latter is not new when the attribute use is a reference to a top-level attribute declaration). The appropriate mapping is described in <specref ref="declare-attribute"/>.</p>
</div3>
<div3>
<head>Constraints on XML Representations of Attribute Uses</head>
<p>None as such.</p>
</div3>
<div3>
<head>Attribute Use Validation Rules</head>
<constraintnote type="cvc" id="cvc-au">
<head>Attribute Locally Valid (Use)</head>
<p>For an attribute information item to be<termref def="key-vn">valid</termref> with respect to an attribute use its &i-value; must match the <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-canonical-representation">canonical lexical representation</xtermref> of the attribute use's <propref ref="au-value_constraint"/> value, if it is present and
<pt>fixed</pt>.</p>
</constraintnote>
</div3>
<div3>
<head>Attribute Use Information Set Contributions</head>
<p>None as such.</p>
</div3>
<div3 id="coss-attruse">
<head>Constraints on Attribute Use Schema Components</head>
<p>All attribute uses (see <specref ref="cAttributeUse"/>) must satisfy the following constraints.</p>
<constraintnote type="cos" id="au-props-correct">
<head>Attribute Use Correct</head>
<olist role="And">
<item>
<p>The values of the properties of an attribute use must be as described in
the property tableau in
<specref ref="AU_details"/>, modulo the impact of <specref ref="conformance-missing"/>.</p>
</item>
<item>
<p>If the <propref ref="attribute"/> has a <pt>fixed</pt> <propref ref="a-value_constraint"/>, then if the attribute use itself has a <propref ref="au-value_constraint"/>, it must also be <pt>fixed</pt> and its value must match that of the <propref ref="attribute"/>'s <propref ref="a-value_constraint"/>.</p>
</item>
</olist>
</constraintnote>
</div3>
</div2>
<div2 id="cAttribute_Group_Definitions">
<head>Attribute Group Definitions</head>
<p>A schema can name a group of attribute declarations so that they may be incorporated as a
group into complex type definitions.</p>
<p>
Attribute group definitions do not participate in <termref def="key-vn">validation</termref> as such, but the
<propref ref="ct-attribute_declarations"/> and <propref ref="ct-attribute_wildcard"/> of one or
more complex type definitions may be constructed in whole or part by reference
to an attribute group. Thus, attribute group definitions provide a
<propdef id="ag-annotation" name="annotation">Optional. An annotation.</propdef>
</proplist>
</compdef>
<p>Attribute groups are identified by their <propref ref="ag-name"/> and <propref ref="ag-target_namespace"/>; attribute group identities must be unique within an <termref def="key-schema">XML Schema</termref>. See <specref ref="composition-schemaImport"/> for the use of component
identifiers when importing one schema into another.</p>
<p><propref ref="ag-attribute_declarations"/> is a set attribute uses, allowing
for local specification of occurrence and default or fixed values.</p>
<p><propref ref="ag-attribute_wildcard"/> provides for an attribute wildcard to be included in an
attribute group.
See above under <specref ref="Complex_Type_Definitions"/> for the
interpretation of
attribute wildcards during <termref def="key-vn">validation</termref>.</p>
<p>See <specref ref="cAnnotations"/> for information on the role of the
<propref ref="ag-annotation"/> property.</p>
</div3>
<div3 id="declare-attributeGroup">
<head>XML Representation of Attribute Group Definition Schema Components</head>
<p>The XML representation for an attribute group definition schema component is an
<eltref ref="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:</p>
<p>When an <eltref ref="attributeGroup"/> appears as a daughter of
<eltref ref="schema"/> or <eltref ref="redefine"/>, it corresponds to an attribute group definition as
below. When it appears as a daughter of <eltref ref="complexType"/> or <eltref ref="attributeGroup"/>, it does not correspond to any component as such.</p>
<reprcomp abstract="Attribute Group Definition" ref="Attribute_Group_Definition_details">
<propmap name="ag-name">The &v-value; of the <code>name</code> &i-attribute;</propmap>
<propmap name="ag-target_namespace">The &v-value; of the
<code>targetNamespace</code> &i-attribute; of the parent <code>schema</code>
element information item.</propmap>
<propmap name="ag-attribute_declarations">The union of the set of attribute uses corresponding to the <eltref ref="attribute"/> &i-children;, if any, with the <propref ref="ag-attribute_declarations"/> of the
attribute groups <termref def="src-resolve">resolved</termref> to by the &v-value;s of the <code>ref</code>
&i-attribute; of the <eltref ref="attributeGroup" inside="simpleContent"/> &i-children;, if any.</propmap>
<propmap name="ag-attribute_wildcard">As for the <termref def="key-eaw">complete wildcard</termref> as described in <specref ref="declare-type"/>.</propmap>
<propmap name="ag-annotation">The annotation corresponding to the <eltref ref="annotation"/> element information item in the
&i-children;, if present, otherwise <termref def="key-null">absent</termref>.</propmap>
</reprcomp></reprdef>
<p>The example above illustrates a pattern which
recurs in the XML representation of schemas: The same element, in this case <code>attributeGroup</code>, serves both to
define and to incorporate by reference. In the first case the
<code>name</code> attribute is required, in the second the <code>ref</code>
attribute is required, and the element must be empty. These two are mutually exclusive, and also conditioned
by context: the defining form, with a <code>name</code>, must occur at the top
level of a schema, whereas the referring form, with a <code>ref</code>, must
occur within a complex type definition or an attribute group definition.</p>
</div3>
<div3>
<head>Constraints on XML Representations of Attribute Group Definitions</head>
<head>Attribute Group Definition Representation OK</head>
<p>In addition to the conditions imposed on <eltref ref="attributeGroup"/> element
information items by the schema for schemas,
<olist role="and">
<item>
<p>The corresponding attribute group definition, if any, must satisfy the conditions set
out in <specref ref="coss-attrGroup"/>.</p>
</item>
<item>
<p>If <clauseref ref="c-awi1"/> or <clauseref ref="c-awi2"/> in the correspondence specification in <specref ref="declare-type"/> for <propref ref="ct-attribute_wildcard"/>, as referenced above, is satisfied, the intensional intersection must be expressible, as defined in <specref ref="cos-aw-intersect"/>.</p>
</item>
<item>
<p>Circular group reference is disallowed outside <eltref ref="redefine"/>. That is, unless this element information item's parent is <eltref ref="redefine"/>, then among the
&i-children;, if any, there must not be an <eltref ref="attributeGroup" inside="simpleContent"/> with <code>ref</code> &i-attribute; which resolves to the component corresponding to this <eltref ref="attributeGroup"/>.</p>
</item>
</olist>
</p>
</constraintnote>
</div3>
<div3>
<head>Attribute Group Definition Validation Rules</head>
<p>None as such.</p>
</div3>
<div3>
<head>Attribute Group Definition Information Set
Contributions</head>
<p>None as such.</p>
</div3>
<div3 id="coss-attrGroup">
<head>Constraints on Attribute Group Definition Schema Components</head>
<p>All attribute group definitions (see <specref ref="cAttribute_Group_Definitions"/>) must satisfy the following constraint.</p>
<constraintnote type="cos" id="ag-props-correct">
<head>Attribute Group Definition Properties Correct</head>
<olist role="And">
<item>
<p>The values of the properties of an attribute group definition must be as described in
the property tableau in
<specref ref="Attribute_Group_Definition_details"/>, modulo the impact of <specref ref="conformance-missing"/>;</p>
</item>
<item>
<p>Two distinct members of the <propref ref="ag-attribute_declarations"/>
must not have <propref ref="attribute"/>s both of whose <propref ref="a-name"/>s
match and whose <propref ref="a-target_namespace"/>s are identical.</p>
</item>
<item>
<p>Two distinct members of the <propref ref="ag-attribute_declarations"/>
must not have <propref ref="attribute"/>s both of whose <propref ref="a-simple_type_definition"/>s are or are derived from <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#ID">ID</xtermref>.</p>
</item>
</olist>
</constraintnote>
</div3>
</div2>
<div2 id="cModel_Group_Definitions">
<head>Model Group Definitions</head>
<p>A model group definition associates a name and optional annotations with a <specref ref="Model_Group"/>.
By reference to the name, the entire model group can be incorporated by reference into a <propref ref="term"/>.</p>
<p>
Model group definitions are provided
primarily for reference from the <specref ref="declare-type"/> (see <eltref ref="complexType"/>
and <eltref ref="group"/>). Thus, model group definitions provide a
Either <termref def="key-null">absent</termref> or a namespace name, as defined in <bibref ref="ref-xml-namespaces"/>.
</propdef>
<propdef id="model_group" name="model group">
A model group.
</propdef>
<propdef id="mg-annotation" name="annotation">Optional. An annotation.</propdef>
</proplist>
</compdef>
<p>Model group definitions are identified by their <propref ref="mg-name"/> and <propref ref="mg-target_namespace"/>; model group identities must be unique within an <termref def="key-schema">XML Schema</termref>. See <specref ref="composition-schemaImport"/> for the use of component
identifiers when importing one schema into another.</p>
<p>Model group definitions <emph>per se</emph> do not participate in <termref def="key-vn">validation</termref>, but the <propref ref="term"/> of
a particle may correspond in whole or in part
to a model group from a model group definition.</p>
<p><propref ref="model_group"/> is the <specref ref="Model_Group"/> for which the model group definition provides a name.</p>
<p>See <specref ref="cAnnotations"/> for information on the role of the
<propref ref="mg-annotation"/> property.</p>
</div3>
<div3 id="declare-namedModelGroup">
<head>XML Representation of Model Group Definition Schema Components</head>
<p>The XML representation for a model group definition schema component is a
<eltref ref="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:</p>
<reprdef>
<reprelt eltname="group" type="namedGroup"/>
<p>If there is a <code>name</code> &i-attribute; (in which case the
item will have <eltref ref="schema"/> or <eltref ref="redefine"/> as parent), then the item corresponds to
a model group definition component with properties as follows:</p>
<reprcomp abstract="Model Group Definition" ref="Model_Group_Definition_details">
<propmap name="mg-name">The &v-value; of the
<code>name</code> &i-attribute;</propmap>
<propmap name="mg-target_namespace">The &v-value; of the
<code>targetNamespace</code> &i-attribute; of the parent <code>schema</code>
element information item.</propmap>
<propmap name="model_group">A model group which is the <propref ref="term"/> of a
particle corresponding to the <eltref ref="all"/>, <eltref ref="choice"/> or
<eltref ref="sequence"/> among the &i-children; (there must be one).</propmap>
<propmap name="mg-annotation">The annotation corresponding to the <eltref ref="annotation"/> element information item in the
&i-children;, if present, otherwise <termref def="key-null">absent</termref>.</propmap>
</reprcomp>
<p>Otherwise, the item will have a <code>ref</code> &i-attribute;,
in which case it corresponds to a particle component with properties as follows (unless <code>minOccurs=maxOccurs=0</code>, in which case the item
corresponds to no component at all):</p>
<reprcomp abstract="Particle" ref="Particle">
<propmap name="p-min_occurs">The &v-value; of the <code>minOccurs</code>
&i-attribute;, if present, otherwise <code>1</code>.</propmap>
<propmap name="p-max_occurs"><pt>unbounded</pt>, if the <code>maxOccurs</code>
&i-attribute; equals <pt>unbounded</pt>, otherwise the &v-value; of the <code>maxOccurs</code>
&i-attribute;, if present, otherwise <code>1</code>.</propmap>
<propmap name="term">The <propref ref="model_group"/> of the
model group definition <termref def="src-resolve">resolved</termref> to by the &v-value; of the <code>ref</code> &i-attribute;</propmap>
</reprcomp>
</reprdef>
<p>The name of this section is slightly misleading, in that the second, un-named,
case above (with a
<code>ref</code> and no <code>name</code>) is not really a named model
group at all, but a reference to one. Also note that in the first (named)
case above no reference is made to <code>minOccurs</code> or
<code>maxOccurs</code>: this is because the schema for schemas does not allow
them on the child of <eltref ref="group"/> when it is named. This in turn is
because the <propref ref="p-min_occurs"/> and <propref ref="p-max_occurs"/> of
the particles which <emph>refer</emph> to the definition are what count.</p>
<p>Given the constraints on its appearance in content models, an
<eltref ref="all"/> should only occur as the only item in the
&i-children; of a named model group definition or a content model: see <specref ref="coss-modelGroup"/>.</p>
</div3>
<div3>
<head>Constraints on XML Representations of Model Group Definitions</head>
<propmap name="compositor">One of <pt>all</pt>, <pt>choice</pt>,
<pt>sequence</pt> depending on the element information item.</propmap>
<propmap name="particles">A sequence of particles
corresponding to all the <eltref ref="all"/>, <eltref ref="choice"/>,
<eltref ref="sequence"/>, <eltref ref="any"/>,
<eltref ref="group"/> or <eltref ref="element"/> items among the &i-children;,
in order.</propmap>
<propmap name="amg-annotation">The annotation corresponding to the <eltref ref="annotation"/> element information item in the
&i-children;, if present, otherwise <termref def="key-null">absent</termref>.</propmap>
</reprcomp>
</reprdef>
</div3>
<div3>
<head>Constraints on XML Representations of Model Groups</head>
<constraintnote type="src" id="src-model_group">
<head>Model Group Representation OK</head>
<p>In addition to the conditions imposed on <eltref ref="all"/>, <eltref ref="choice"/> and <eltref ref="sequence"/> element
information items by the schema for schemas, the corresponding particle and model group must satisfy the conditions set
out in <specref ref="coss-modelGroup"/> and <specref ref="coss-particle"/>.
</p>
</constraintnote>
</div3>
<div3>
<head>Model Group Validation Rules</head>
<constraintnote type="cvc" id="cvc-model-group">
<head>Element Sequence Valid</head>
<p><termdef id="key-partition" term="partition">Define a
<term>partition</term> 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</termdef>.</p>
<p>For a sequence (possibly empty) of element information items to be
locally <termref def="key-vn">valid</termref> with respect to
a model group
<olist role="case">
<item>
<p role="if">the <propref ref="compositor"/> is <pt>sequence</pt></p>
<p role="then">there must be a
<termref def="key-partition">partition</termref> of the sequence into <code>n</code> sub-sequences where <code>n</code> is the length of <propref ref="particles"/> such that each of the sub-sequences in order is <termref def="key-vn">valid</termref>
with respect to the corresponding particle in the <propref ref="particles"/> as defined in <specref ref="cvc-particle"/>.</p>
</item>
<item>
<p role="if">the <propref ref="compositor"/> is <pt>choice</pt></p>
<p role="then">there must be a
particle among the <propref ref="particles"/> such that the sequence is
<termref def="key-vn">valid</termref> with respect to that particle as defined in <specref ref="cvc-particle"/>.</p>
</item>
<item>
<p role="if">the <propref ref="compositor"/> is <pt>all</pt></p>
<p role="then">there must be a
<termref def="key-partition">partition</termref> of the sequence into <code>n</code> sub-sequences where <code>n</code> is the length of <propref ref="particles"/> such that there is a one-to-one mapping between the sub-sequences and the <propref ref="particles"/> where each sub-sequence is <termref def="key-vn">valid</termref> with respect to the corresponding particle as defined in <specref ref="cvc-particle"/>.</p>
</item>
</olist>
</p>
<p>Nothing in the above should be understood as ruling out groups whose
<propref ref="particles"/> is empty: although no sequence can be <termref def="key-vn">valid</termref>
with respect to such a group whose <propref ref="compositor"/> is
<pt>choice</pt>, the empty sequence <emph>is</emph> <termref def="key-vn">valid</termref> with respect
to empty groups whose <propref ref="compositor"/> is <pt>sequence</pt> or <pt>all</pt>.</p>
</constraintnote>
<note>
<p>The above definition is implicitly non-deterministic, and should not be
taken as a recipé for implementations. Note in particular that when
<propref ref="compositor"/> is <pt>all</pt>, particles is restricted to a list
of local and top-level element declarations (see <specref ref="coss-modelGroup"/>). A much simpler implementation is possible than would arise from a literal interpretation of the definition above; informally, the content is <termref def="key-vn">valid</termref> when each declared element occurs exactly once (or at most once, if <propref ref="p-min_occurs"/> is <code>0</code>), and each is <termref def="key-vn">valid</termref> with respect to its corresponding declaration. The elements can occur in arbitrary order.</p>
</note>
</div3>
<div3>
<head>Model Group Information Set Contributions</head>
<p>None as such.</p>
</div3>
<div3 id="coss-modelGroup">
<head>Constraints on Model Group Schema Components</head>
<p>All model groups (see <specref ref="Model_Groups"/>) must satisfy the following constraints.</p>
<constraintnote type="cos" id="mg-props-correct">
<head>Model Group Correct</head>
<olist role="And">
<item><p>The values of the properties of a model group must be as described in
the property tableau in
<specref ref="Model_Group_details"/>, modulo the impact of <specref ref="conformance-missing"/>.</p></item>
<item><p>Circular groups are disallowed. That is, within the <propref ref="particles"/> of a group there must not be at any
depth a particle whose <propref ref="term"/> is the
group itself.</p></item>
</olist>
</constraintnote>
<constraintnote type="cos" id="cos-all-limited">
<head>All Group Limited</head>
<p>When a model group has <propref ref="compositor"/> <pt>all</pt>
<olist role="and">
<item><olist role="or">
<item>
<p>It appears as the model group of a model group definition.</p>
</item>
<item>
<p>It appears in a particle with <propref ref="p-min_occurs"/>=<propref ref="p-max_occurs"/><code>=1</code>, and that particle
must be part of a pair which constitutes the <propref ref="content_type"/> of a
complex type definition.</p>
</item>
</olist>
</item>
<item>
<p>The <propref ref="p-max_occurs"/> of all the particles in the
<propref ref="particles"/> of the group must be <code>0</code> or <code>1</code>.</p>
<p>If the <propref ref="particles"/> contains, either directly, indirectly
(that is, within the <propref ref="particles"/> of a contained model group,
recursively) or <termref def="key-impl-cont">implicitly</termref> two or more
element declaration particles with the same <propref ref="e-name"/> and
<propref ref="e-target_namespace"/>, then all their type definitions must be
the same top-level definition, that is,
<olist role="and">
<item>
<p>all their
<propref ref="type_definition"/>s must have a non-<termref def="key-null">absent</termref> name.</p>
</item>
<item>
<p>all their
<propref ref="type_definition"/>s must have the same name.</p>
</item>
<item>
<p>all their
<propref ref="type_definition"/>s must have the same target namespace.</p>
</item>
</olist>
</p>
<p><termdef id="key-impl-cont" term="implicitly contains">A list
of particles <term>implicitly contains</term> an element declaration if a
member of the list contains that
element declaration in its <termref def="key-eq">substitution group</termref></termdef>.</p>
</constraintnote>
<constraintnote type="cos" id="cos-nonambig">
<head>Unique Particle Attribution</head>
<p>A content model must be formed such that
during <termref def="key-vn">validation</termref> of an element information item sequence, the particle
contained directly, indirectly or <termref def="key-impl-cont">implicitly</termref> therein with which to attempt to <termref def="key-vn">validate</termref> each item in the sequence in turn can be uniquely determined without examining the content or attributes of that item, and without any information about the items in the remainder of the sequence.</p>
<note>
<p>This constraint reconstructs for XML Schema the equivalent constraints of
<bibref ref="ref-xml"/> and SGML. Given the presence of element substitution groups and wildcards, the concise expression of this constraint is difficult,
see <specref ref="non-ambig"/> for further discussion.</p>
</note>
</constraintnote>
<note>
<p>Because locally-scoped element declarations may or may not have a
<propref ref="e-target_namespace"/>, the scope of declarations is
<emph>not</emph> relevant to enforcing either of the two preceding constraints.</p>
</note>
<p>The following constraints define relations appealed to elsewhere in this specification.</p>
<constraintnote type="cos" id="cos-seq-range">
<head>Effective Total Range (<pt>all</pt> and <pt>sequence</pt>)</head>
<p>The effective total range of a particle whose <propref ref="term"/> is a group whose <propref ref="compositor"/> is
<pt>all</pt> or <pt>sequence</pt> is a pair of minimum and maximum, as follows: </p>
<glist>
<gitem>
<label>minimum</label>
<def>
<p>The product of the particle's <propref ref="p-min_occurs"/> and the
sum of the <propref ref="p-min_occurs"/> of every wildcard or element
declaration particle in the group's <propref ref="particles"/> and the minimum
part of the effective total range of each of the group particles in the group's <propref ref="particles"/> (or <code>0</code> if there are no <propref ref="particles"/>).</p>
</def>
</gitem>
<gitem>
<label>maximum</label>
<def>
<p><pt>unbounded</pt> if the <propref ref="p-max_occurs"/> of any wildcard or element
declaration particle in the group's <propref ref="particles"/> or the maximum
part of the effective total range of any of the group particles in the group's
<propref ref="particles"/> is <pt>unbounded</pt>, or if any of those is non-zero
and the <propref ref="p-max_occurs"/> of the particle itself is <pt>unbounded</pt>,
otherwise the product of the particle's <propref ref="p-max_occurs"/> and the
sum of the <propref ref="p-max_occurs"/> of every wildcard or element
declaration particle in the group's <propref ref="particles"/> and the maximum
part of the effective total range of each of the group particles in the group's <propref ref="particles"/> (or <code>0</code> if there are no <propref ref="particles"/>).</p>
</def>
</gitem>
</glist>
</constraintnote>
<constraintnote type="cos" id="cos-choice-range">
<head>Effective Total Range (<pt>choice</pt>)</head>
<p>The effective total range of a particle whose <propref ref="term"/> is a group whose <propref ref="compositor"/> is
<pt>choice</pt> is a pair of minimum and maximum, as follows:</p>
<glist>
<gitem>
<label>minimum</label>
<def>
<p>The product of the particle's <propref ref="p-min_occurs"/> and the
minimum of the <propref ref="p-min_occurs"/> of every wildcard or element
declaration particle in the group's <propref ref="particles"/> and the minimum
part of the effective total range of each of the group particles in the group's <propref ref="particles"/> (or <code>0</code> if there are no <propref ref="particles"/>).</p>
</def>
</gitem>
<gitem>
<label>maximum</label>
<def>
<p><pt>unbounded</pt> if the <propref ref="p-max_occurs"/> of any wildcard or element
declaration particle in the group's <propref ref="particles"/> or the maximum
part of the effective total range of any of the group particles in the group's
<propref ref="particles"/> is <pt>unbounded</pt>, or if any of those is non-zero
and the <propref ref="p-max_occurs"/> of the particle itself is <pt>unbounded</pt>,
otherwise the product of the particle's <propref ref="p-max_occurs"/> and the
maximum of the <propref ref="p-max_occurs"/> of every wildcard or element
declaration particle in the group's <propref ref="particles"/> and the maximum
part of the effective total range of each of the group particles in the group's <propref ref="particles"/> (or <code>0</code> if there are no <propref ref="particles"/>).</p>
</def>
</gitem>
</glist>
</constraintnote>
</div3>
</div2>
<div2 id="cParticles">
<head>Particles</head>
<p>As described in <specref ref="Model_Groups"/>, particles contribute to the definition
<propdef id="p-max_occurs" name="max occurs">Either a non-negative integer
or <pt>unbounded</pt>.</propdef>
<propdef id="term" name="term">One of a model group, a wildcard, or an element declaration.</propdef>
</proplist>
</compdef>
<p>In general, multiple element
information item &i-children;, possibly with intervening character &i-children; if the content type
is <pt>mixed</pt>, can be <termref def="key-vn">validated</termref> with
respect to a single particle. When the <propref ref="term"/> is an element
declaration or wildcard, <propref ref="p-min_occurs"/> determines the minimum number of such element &i-children; that can occur. The number of such children must be greater than or equal to <propref ref="p-min_occurs"/>. If <propref ref="p-min_occurs"/> is <pt>0</pt>, then occurrence of such children is optional.</p>
<p>Again, when the <propref ref="term"/> is an element
declaration or wildcard, the number of such element &i-children; must be less than or equal to any numeric specification of
<propref ref="p-max_occurs"/>; if <propref ref="p-max_occurs"/> is <pt>unbounded</pt>, then there is no
upper bound on the number of such children.</p>
<p>When the <propref ref="term"/> is a model group, the permitted
occurrence range is determined by a combination of <propref ref="p-min_occurs"/> and <propref ref="p-max_occurs"/> and the occurrence ranges of the <propref ref="term"/>'s <propref ref="particles"/>.</p>
</div3>
<div3>
<head>XML Representation of Particle Components</head>
<p>Particles correspond to all three elements (<eltref ref="element" inside="complexType"/> not immediately within <eltref ref="schema"/>, <eltref ref="group" inside="complexType"/> not immediately within <eltref ref="schema"/> and <eltref ref="any"/>) which allow <code>minOccurs</code> and <code>maxOccurs</code> attributes. These in turn correspond to
<emph>two</emph> components in each case, a particle and its <propref ref="term"/>. The appropriate mapping is described in <specref ref="declare-element"/>, <specref ref="declare-contentModel"/> and <specref ref="declare-openness"/> respectively.</p>
</div3>
<div3>
<head>Constraints on XML Representations of Particles</head>
<p>For a sequence (possibly empty) of element information items to be
locally <termref def="key-vn">valid</termref>
with respect to a particle
<olist role="case">
<item id="c-pw">
<p role="if">the <propref ref="term"/> is a wildcard</p>
<p role="then">
<olist role="and">
<item>
<p>The length of the sequence must be greater than or equal to the <propref ref="p-min_occurs"/>.</p>
</item>
<item>
<p>If <propref ref="p-max_occurs"/> is a number, the length of the sequence must be less than or equal to the <propref ref="p-max_occurs"/>.</p>
</item>
<item>
<p>Each element
information item in the sequence must be <termref def="key-vn">valid</termref> with respect to the wildcard as defined by <specref ref="cvc-wildcard"/>.</p>
</item>
</olist>
</p>
</item>
<item id="c-cdde">
<p role="if">the <propref ref="term"/> is an element declaration</p>
<p role="then">
<olist role="and">
<item>
<p>The length of the sequence must be greater than or equal to the <propref ref="p-min_occurs"/>.</p>
</item>
<item>
<p>If <propref ref="p-max_occurs"/> is a number, the length of the sequence must be less than or equal to the <propref ref="p-max_occurs"/>.</p>
</item>
<item>
<p>For each element
information item in the sequence
<olist role="or">
<item>
<p>The element declaration is local (i.e. its
<propref ref="e-scope"/> must not be <pt>global</pt>), its <propref ref="e-abstract"/> is <pt>false</pt>, the element information
item's <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">namespace name</xpropref> is identical to the element declaration's <propref ref="e-target_namespace"/> (where an <termref def="key-null">absent</termref> <propref ref="e-target_namespace"/> is taken to be identical to a <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">namespace name</xpropref> with no value) and the element information
name</xpropref> matches the element declaration's <propref ref="e-name"/>.</p>
<p>In this case the element declaration is the <termref def="key-dd">context-determined declaration</termref> for the element information item with respect to <specref ref="cvc-assess-elt"/> and <specref ref="sic-e-outcome"/>.</p>
</item>
<item>
<p>The element declaration is top-level (i.e. its
<propref ref="e-scope"/> is <pt>global</pt>), <propref ref="e-abstract"/> is <pt>false</pt>, the element information
item's <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">namespace name</xpropref> is identical to the element declaration's <propref ref="e-target_namespace"/> (where an <termref def="key-null">absent</termref> <propref ref="e-target_namespace"/> is taken to be identical to a <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">namespace name</xpropref> with no value) and the element information
name</xpropref> matches the element declaration's <propref ref="e-name"/>.</p>
<p>In this case the element declaration is the <termref def="key-dd">context-determined declaration</termref> for the element information item with respect to <specref ref="cvc-assess-elt"/> and <specref ref="sic-e-outcome"/>.</p>
</item>
<item id="c-psg">
<p>The element declaration is top-level (i.e. its
<propref ref="e-scope"/> is <pt>global</pt>), its <propref ref="e-exact"/> does not contain <pt>substitution</pt>,
the <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">local
</xpropref> and <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">namespace name</xpropref> of the element information item resolve to an element declaration, as
defined in <specref ref="cvc-resolve-instance"/> -- <termdef id="key-eqd" term="head declaration" role="local">call this declaration the <term>substituting declaration</term></termdef> and the <termref def="key-eqd">substituting declaration</termref> together with the particle's element declaration's <propref ref="e-exact"/> is validly substitutable for the particle's element declaration as defined in <specref ref="cos-equiv-derived-ok-rec"/>.</p>
<p>In this case the <termref def="key-eqd">substituting declaration</termref> is the <termref def="key-dd">context-determined declaration</termref> for the element information item with respect to <specref ref="cvc-assess-elt"/> and <specref ref="sic-e-outcome"/>.</p>
</item>
</olist></p>
</item>
</olist>
</p>
</item>
<item>
<p role="if">the <propref ref="term"/> is a model group</p>
<p role="then">
<olist role="and">
<item><p>There is a <termref def="key-partition">partition</termref> of the sequence into <code>n</code> sub-sequences such that <code>n</code> is greater than or equal to <propref ref="p-min_occurs"/>.</p></item>
<item><p>If <propref ref="p-max_occurs"/> is a number, <code>n</code>
must be less than or equal to <propref ref="p-max_occurs"/>.</p></item>
<item><p>Each sub-sequence in the <termref def="key-partition">partition</termref> is <termref def="key-vn">valid</termref> with respect to that model group as defined in <specref ref="cvc-model-group"/>.</p></item>
</olist>
</p>
</item>
</olist>
</p>
<note>
<p>Clauses <clauseref ref="c-pw"/> and <clauseref ref="c-psg"/> do not
interact: an element information item validatable by a declaration with a substitution group head in a
different namespace is <emph>not</emph> validatable by a wildcard which accepts
the head's namespace but not its own.</p>
</note>
</constraintnote>
</div3>
<div3>
<head>Particle Information Set Contributions</head>
<p>None as such.</p>
</div3>
<div3 id="coss-particle">
<head>Constraints on Particle Schema Components</head>
<p>All particles (see <specref ref="cParticles"/>) must satisfy the following constraints.</p>
<constraintnote type="cos" id="p-props-correct">
<head>Particle Correct</head>
<olist role="And">
<item>
<p>The values of the properties of a particle must be as described in
the property tableau in
<specref ref="Particle_details"/>, modulo the impact of <specref ref="conformance-missing"/>.</p>
</item>
<item>
<p>If <propref ref="p-max_occurs"/> is not <pt>unbounded</pt>, that is, it has a
numeric value, then
<olist role="and">
<item>
<p><propref ref="p-min_occurs"/> must not be greater than <propref ref="p-max_occurs"/>.</p>
</item>
<item>
<p><propref ref="p-max_occurs"/> must be greater than or equal to 1.</p>
</item>
</olist>
</p>
</item>
</olist>
</constraintnote>
<p>The following constraints define relations appealed to elsewhere in this specification.</p>
<p><termdef id="cd-model-extension" term="valid extension" role="local">For a particle
(call it <local>E</local>, for extension) to be a <term>valid extension</term> of
another particle (call it <local>B</local>, for base)</termdef>
<olist role="or">
<item>
<p>They are the same particle.</p>
</item>
<item>
<p><local>E</local>'s <propref ref="p-min_occurs"/>=<propref ref="p-max_occurs"/><code>=1</code> and its <propref ref="term"/> is a <pt>sequence</pt> group whose <propref ref="particles"/>' first member is a particle all of whose properties, recursively, are identical to those of <local>B</local>, with the exception of <xpropref role="anon">annotation</xpropref> properties.</p>
</item>
</olist>
</p>
</constraintnote>
<p>The approach to defining a type by restricting another type definition
set out here is designed to ensure that types defined in this way are
guaranteed to be a subset of the type they restrict. This is accomplished by
requiring a clear mapping between the components of the base type definition and the
restricting type definition. Permissible mappings are set out below via a set
of recursive definitions, bottoming out in the obvious cases, e.g. where an
(restricted) element declaration corresponds to another (base) element
declaration with the same name and type but the same or wider range of occurrence.</p>
<note role="pf">
<p>The structural correspondence approach to guaranteeing the subset
relation set out here is necessarily verbose, but has the advantage of being
checkable in a straightforward way. The working group solicits feedback on how
difficult this is in practice, and on whether other approaches are found to be viable.</p>
<p><termdef id="cd-model-restriction" term="valid restriction" role="local">For a particle (call it <local>R</local>, for restriction) to be a <term>valid restriction</term> of
another particle (call it <local>B</local>, for base)</termdef>
<olist role="or">
<item>
<p>They are the same particle.</p>
</item>
<item>
<p>depending on the kind of particle, per the table below, with the
qualifications that
<olist role="and">
<item>
<p>Any top-level element declaration particle (in <local>R</local> or
<local>B</local>) which is the
<propref ref="class_exemplar"/> of one or more other element declarations is
treated as if it were a <pt>choice</pt> group whose <propref ref="p-min_occurs"/> and <propref ref="p-max_occurs"/> are those of the particle, and whose <propref ref="particles"/> consists of
one particle with <propref ref="p-min_occurs"/> and <propref ref="p-max_occurs"/> of <code>1</code> for the top-level element declaration and for each of the declarations in its <termref def="key-eq">substitution group</termref>.</p>
</item>
<item>
<p>Any pointless occurrences of <eltref ref="sequence"/>, <eltref ref="choice"/> or <eltref ref="all"/> are ignored, where pointlessness is understood as follows:
<glist>
<gitem>
<label><eltref ref="sequence"/></label>
<def>
<olist role="Or">
<item>
<p><propref ref="particles"/> is empty.</p>
</item>
<item>
<olist role="And">
<item><p>The particle within which this <eltref ref="sequence"/>
appears has <propref ref="p-max_occurs"/> and <propref ref="p-min_occurs"/> of
<head>Particle Derivation OK (Elt:All/Choice/Sequence -- RecurseAsIfGroup)</head>
<p>For an element declaration particle to be a <termref def="cd-model-restriction">valid restriction</termref> of a group particle (<pt>all</pt>, <pt>choice</pt> or <pt>sequence</pt>)
a group particle of the variety corresponding to <local>B</local>'s, with
<propref ref="p-min_occurs"/> and <propref ref="p-max_occurs"/> of <code>1</code> and with <propref ref="particles"/> consisting of a single particle
the same as the element declaration must be a <termref def="cd-model-restriction">valid restriction</termref> of the group as defined by <specref ref="rcase-Recurse"/>, <specref ref="rcase-RecurseLax"/> or <specref ref="rcase-Recurse"/>, depending on whether the group is <pt>all</pt>, <pt>choice</pt> or <pt>sequence</pt>.</p>
</constraintnote>
<constraintnote type="cos" id="rcase-NSSubset">
<head>Particle Derivation OK (Any:Any -- NSSubset)</head>
<p>For a wildcard particle to be a <termref def="cd-model-restriction">valid restriction</termref> of another wildcard particle
<olist role="and">
<item>
<p><local>R</local>'s occurrence range must be a valid
restriction of <local>B</local>'s occurrence range as defined by <specref ref="range-ok"/>.</p>
</item>
<item>
<p><local>R</local>'s <propref ref="namespace_constraint"/> must be an intensional
subset of <local>B</local>'s <propref ref="namespace_constraint"/> as defined by <specref ref="cos-ns-subset"/>.</p>
<head>Particle Derivation OK (All/Choice/Sequence:Any -- NSRecurseCheckCardinality)</head>
<p>For a group particle to be a <termref def="cd-model-restriction">valid restriction</termref> of a wildcard particle
<olist role="and">
<item>
<p>Every member of the <propref ref="particles"/> of the group is a
<termref def="cd-model-restriction">valid restriction</termref> of the wildcard
as defined by <specref ref="cos-particle-restrict"/>.</p>
</item>
<item>
<p>The effective total range of the group, as defined by <specref ref="cos-seq-range"/> (if
the group is <pt>all</pt> or <pt>sequence</pt>) or
<specref ref="cos-choice-range"/> (if it is <pt>choice</pt>) is a valid
restriction of <local>B</local>'s occurrence range as defined by <specref ref="range-ok"/>.</p>
</item>
</olist>
</p>
</constraintnote>
<constraintnote type="cos" id="rcase-Recurse">
<head>Particle Derivation OK (All:All,Sequence:Sequence -- Recurse)</head>
<p>For an <pt>all</pt> or <pt>sequence</pt> group particle to be a <termref def="cd-model-restriction">valid restriction</termref> of another group particle with the same <propref ref="compositor"/>
<olist role="and">
<item>
<p><local>R</local>'s occurrence range is a valid
restriction of <local>B</local>'s occurrence range as defined by <specref ref="range-ok"/>.</p>
</item>
<item>
<p>There is a complete <termref def="key-op">order-preserving</termref> functional mapping from the particles in the
<propref ref="particles"/> of <local>R</local> to the particles in the <propref ref="particles"/> of <local>B</local> such that
<olist role="and">
<item>
<p>Each particle in the <propref ref="particles"/> of <local>R</local> is a
<termref def="cd-model-restriction">valid restriction</termref> of the
particle in the <propref ref="particles"/> of <local>B</local> it maps to as defined
by <specref ref="cos-particle-restrict"/>.</p>
</item>
<item>
<p>All particles in the <propref ref="particles"/> of <local>B</local> which
are not mapped to by any particle in the <propref ref="particles"/> of <local>R</local>
are <termref def="cd-emptiable">emptiable</termref> as defined by <specref ref="cos-group-emptiable"/>.</p>
</item>
</olist></p>
</item>
</olist>
</p>
<note>
<p>Although the <termref def="key-vn">validation</termref> semantics of an <pt>all</pt> group does not
depend on the order of its particles, derived <pt>all</pt> groups are required to
match the order of their base in order to simplify checking that the derivation is OK.</p>
</note>
<p><termdef id="key-op" term="order-preserving" role="local">A complete functional mapping is
<term>order-preserving</term> if each particle <local>r</local> in the domain <local>R</local> maps to a
particle <local>b</local> in the range <local>B</local> which follows (not necessarily
immediately) the particle in the range
<local>B</local> mapped to by the predecessor of <local>r</local>, if any, where
<quote>predecessor</quote> and <quote>follows</quote> are defined with respect
to the order of the lists which constitute <local>R</local> and <local>B</local></termdef>.</p>
</constraintnote>
<constraintnote type="cos" id="rcase-RecurseLax">
<head>Particle Derivation OK (Choice:Choice -- RecurseLax)</head>
<p>For a <pt>choice</pt> group particle to be a <termref def="cd-model-restriction">valid restriction</termref> of another <pt>choice</pt> group particle
<olist role="and">
<item>
<p><local>R</local>'s occurrence range is a valid
restriction of <local>B</local>'s occurrence range as defined by <specref ref="range-ok"/>;</p>
</item>
<item>
<p>There is a complete <termref def="key-op">order-preserving</termref> functional mapping from the particles in the
<propref ref="particles"/> of <local>R</local> to the particles in the <propref ref="particles"/> of <local>B</local> such that each particle in the <propref ref="particles"/> of <local>R</local> is a
<termref def="cd-model-restriction">valid restriction</termref> of the
particle in the <propref ref="particles"/> of <local>B</local> it maps to as defined
by <specref ref="cos-particle-restrict"/>.</p>
</item>
</olist>
</p>
<note>
<p>Although the <termref def="key-vn">validation</termref> semantics of a <pt>choice</pt> group does not
depend on the order of its particles, derived <pt>choice</pt> groups are
required to
match the order of their base in order to simplify checking that the derivation is OK.</p>
<head>Particle Derivation OK (Sequence:All -- RecurseUnordered)</head>
<p>For a <pt>sequence</pt> group particle to be a <termref def="cd-model-restriction">valid restriction</termref> of an <pt>all</pt> group particle
<olist role="and">
<item>
<p><local>R</local>'s occurrence range is a valid
restriction of <local>B</local>'s occurrence range as defined by <specref ref="range-ok"/>.</p>
</item>
<item>
<p>There is a complete functional mapping from the particles in the
<propref ref="particles"/> of <local>R</local> to the particles in the <propref ref="particles"/> of <local>B</local> such that
<olist role="and">
<item>
<p>No particle in the <propref ref="particles"/> of <local>B</local> is mapped
to by more than one of the particles in the
<propref ref="particles"/> of <local>R</local>;</p>
</item>
<item>
<p>Each particle in the <propref ref="particles"/> of <local>R</local> is a
<termref def="cd-model-restriction">valid restriction</termref> of the
particle in the <propref ref="particles"/> of <local>B</local> it maps to as defined
by <specref ref="cos-particle-restrict"/>;</p>
</item>
<item>
<p>All particles in the <propref ref="particles"/> of <local>B</local> which
are not mapped to by any particle in the <propref ref="particles"/> of <local>R</local>
are <termref def="cd-emptiable">emptiable</termref> as defined by <specref ref="cos-group-emptiable"/>.</p>
</item>
</olist>
</p>
</item>
</olist>
</p>
<note>
<p>Although this clause allows reordering, because of the limits on the
contents of <pt>all</pt> groups the checking process can still be deterministic.</p>
</note>
</constraintnote>
<constraintnote type="cos" id="rcase-MapAndSum">
<head>Particle Derivation OK (Sequence:Choice -- MapAndSum)</head>
<p>For a <pt>sequence</pt> group particle to be a <termref def="cd-model-restriction">valid restriction</termref> of a <pt>choice</pt> group particle
<olist role="and">
<item>
<p>There is a complete functional mapping from the particles in the
<propref ref="particles"/> of <local>R</local> to the particles in the <propref ref="particles"/> of <local>B</local> such that each particle in the <propref ref="particles"/> of <local>R</local> is a
<termref def="cd-model-restriction">valid restriction</termref> of the
particle in the <propref ref="particles"/> of <local>B</local> it maps to as defined
by <specref ref="cos-particle-restrict"/>.</p>
</item>
<item>
<p>The pair consisting of the product of the <propref ref="p-min_occurs"/> of <local>R</local> and the length of its <propref ref="particles"/> and <pt>unbounded</pt> if <propref ref="p-max_occurs"/> is <pt>unbounded</pt> otherwise the product of the <propref ref="p-max_occurs"/> of <local>R</local> and the length of its <propref ref="particles"/> is a valid
restriction of <local>B</local>'s occurrence range as defined by <specref ref="range-ok"/>.</p>
<note>
<p>This clause is in principle more restrictive than absolutely
necessary, but in practice will cover all the likely cases, and is much easier
to specify than the fully general version.</p>
</note>
</item>
</olist>
</p>
<note>
<p>This case allows the <quote>unfolding</quote> of iterated disjunctions
into sequences. It may be particularly useful when the disjunction is an
implicit one arising from the use of substitution groups.</p>
One of <pt>any</pt>; a pair of <pt>not</pt> and a namespace name
or <termref def="key-null">absent</termref>; or a set whose
members are either namespace names or <termref def="key-null">absent</termref>.
</propdef>
<propdef name="process contents" id="process_contents">One of <pt>skip</pt>, <pt>lax</pt> or <pt>strict</pt>.</propdef>
<propdef id="w-annotation" name="annotation">Optional. An annotation.</propdef>
</proplist>
</compdef>
<p><propref ref="namespace_constraint"/> provides for <termref def="key-vn">validation</termref> of attribute and element items that:
<olist>
<item>
<p>(<pt>any</pt>) have any namespace or are not namespace qualified;</p>
</item>
<item>
<p>(<pt>not</pt> and a namespace name) have any namespace other than the specified namespace name, or
are not namespace qualified;</p>
</item>
<item>
<p>(<pt>not</pt> and <termref def="key-null">absent</termref>) are namespace qualified;</p>
</item>
<item>
<p>(a set whose
members are either namespace names or <termref def="key-null">absent</termref>) have any of the
specified namespaces and/or, if <termref def="key-null">absent</termref> is included in the set, are unqualified.</p>
</item>
</olist></p>
<p><propref ref="process_contents"/> controls the impact on <termref def="key-va">assessment</termref>
of the information items allowed by wildcards, as follows:
<glist>
<gitem>
<label>strict</label>
<def>
<p>There must be a top-level declaration for the item available, or the item
must have an <code>xsi:type</code>, and the item
must be <termref def="key-vn">valid</termref> as appropriate.</p>
</def>
</gitem>
<gitem>
<label>skip</label>
<def>
<p>No constraints at all: the item must simply be well-formed XML.</p>
</def>
</gitem>
<gitem>
<label>lax</label>
<def>
<p>If the item, or any items among its &i-children; if it's an element
information item, has a uniquely
determined declaration available, it must be <termref def="key-vn">valid</termref> with respect to
that definition, that is, <termref def="key-vn">validate</termref> where you can, don't worry when you can't.</p>
</def>
</gitem>
</glist>
</p>
<p>See <specref ref="cAnnotations"/> for information on the role of the
<propref ref="w-annotation"/> property.</p>
</div3>
<div3 id="declare-openness">
<head>XML Representation of Wildcard Schema Components</head>
<p>The XML representation for a wildcard schema component is an
<eltref ref="any"/> or <eltref ref="anyAttribute"/> element information item. The correspondences between the
properties of an <eltref ref="any"/> information item and
properties of the components it corresponds to are as follows (see <eltref ref="complexType"/> and <eltref ref="attributeGroup"/> for the correspondences for <eltref ref="anyAttribute"/>):</p>
<reprdef>
<reprelt eltname="any"/>
<p>A particle containing a wildcard, with properties as follows (unless <code>minOccurs=maxOccurs=0</code>, in which case the item
<propmap name="namespace_constraint">Dependent on the &v-value; of the
<code>namespace</code> &i-attribute;: if absent, then <pt>any</pt>, otherwise as follows:<glist>
<gitem>
<label>##any</label>
<def>
<p><pt>any</pt></p>
</def>
</gitem>
<gitem>
<label>##other</label>
<def>
<p>a pair of <pt>not</pt> and the &v-value; of the <code>targetNamespace</code> &i-attribute; of the <eltref ref="schema"/> ancestor
element information item if present, otherwise <termref def="key-null">absent</termref>.</p>
</def>
</gitem>
<gitem>
<label><emph>otherwise</emph></label>
<def>
<p>a set whose members are namespace names corresponding to the
space-delimited substrings of the string, except
<olist>
<item>
<p>if one such
substring is <code>##targetNamespace</code>, the corresponding member is the &v-value; of the <code>targetNamespace</code> &i-attribute; of the <eltref ref="schema"/> ancestor
element information item if present, otherwise <termref def="key-null">absent</termref>.</p>
</item>
<item>
<p>if one such
substring is <code>##local</code>, the corresponding member is <termref def="key-null">absent</termref>.</p>
</item>
</olist>
</p>
</def>
</gitem>
</glist>
</propmap>
<propmap name="process_contents">The &v-value; of the
<code>processContents</code> &i-attribute;, if present, otherwise <pt>strict</pt>.</propmap>
<propmap name="w-annotation">The annotation corresponding to the <eltref ref="annotation"/> element information item in the
&i-children;, if present, otherwise <termref def="key-null">absent</termref>.</propmap>
</reprcomp></reprdef>
<p>Wildcards are subject to the same ambiguity constraints
(<specref ref="cos-nonambig"/>) 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.</p>
</div3>
<div3>
<head>Constraints on XML Representations of Wildcards</head>
<constraintnote type="src" id="src-wildcard">
<head>Wildcard Representation OK</head>
<p>In addition to the conditions imposed on <eltref ref="any"/> element
information items by the schema for schemas, the corresponding particle and model group must satisfy the conditions set
out in <specref ref="coss-modelGroup"/> and <specref ref="coss-particle"/>.</p>
</constraintnote>
</div3>
<div3>
<head>Wildcard Validation Rules</head>
<constraintnote type="cvc" id="cvc-wildcard">
<head>Item Valid (Wildcard)</head>
<p>For an element or attribute information item to be locally <termref def="key-vn">valid</termref> with respect to a wildcard
constraint
its <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">namespace name</xpropref> must be <termref def="key-vn">valid</termref> with respect to the wildcard constraint, as defined in <specref ref="cvc-wildcard-namespace"/>.</p>
<p>When this constraint applies
<olist role="case">
<item>
<p role="if"><propref ref="process_contents"/> is <pt>lax</pt></p>
<p role="then">the item has no <termref def="key-dd">context-determined declaration</termref> with respect to <specref ref="sic-e-outcome"/>, <specref ref="cvc-assess-elt"/> and <specref ref="cvc-assess-attr"/>.</p>
</item>
<item>
<p role="if"><propref ref="process_contents"/> is <pt>strict</pt></p>
<p role="then">the item's <termref def="key-dd">context-determined declaration</termref> is <pt>mustFind</pt>.</p>
</item>
<item>
<p role="if"><propref ref="process_contents"/> is <pt>skip</pt></p>
<p role="then">the item's <termref def="key-dd">context-determined declaration</termref> is <pt>skip</pt>.</p>
<p>For a value which is either a namespace name or <termref def="key-null">absent</termref> to be <termref def="key-vn">valid</termref> with respect to a wildcard constraint (the
value of a <propref ref="namespace_constraint"/>)
<olist role="or">
<item>
<p>The constraint must be <pt>any</pt>.</p>
</item>
<item>
<olist role="And">
<item>
<p>The constraint is a pair of <pt>not</pt> and a namespace name or
<termref def="key-null">absent</termref> (<termdef id="key-nst" term="namespace test" role="local">call this the <term>namespace test</term>)</termdef>.</p>
</item>
<item>
<p>The value must not be identical to the <termref def="key-nst">namespace test</termref>.</p>
</item>
<item>
<p>The value must not be <termref def="key-null">absent</termref>.</p>
</item>
</olist>
</item>
<item>
<p>The constraint is a set, and the value is identical to one of the members of the set.</p>
</item>
</olist>
</p>
</constraintnote>
</div3>
<div3>
<head>Wildcard Information Set Contributions</head>
<p>None as such.</p>
</div3>
<div3 id="coss-wildcard">
<head>Constraints on Wildcard Schema Components</head>
<p>All wildcards (see <specref ref="Wildcards"/>) must satisfy the following constraint.</p>
<constraintnote type="cos" id="w-props-correct">
<head>Wildcard Properties Correct</head>
<p>The values of the properties of a wildcard must be as described in
the property tableau in
<specref ref="Wildcard_details"/>, modulo the impact of <specref ref="conformance-missing"/>.</p>
</constraintnote>
<p>The following constraints define a relation appealed to elsewhere in this specification.</p>
<constraintnote type="cos" id="cos-ns-subset">
<head>Wildcard Subset</head>
<p>For a namespace constraint (call it <local>sub</local>) to be an intensional subset of
another namespace constraint (call it <local>super</local>)
<olist role="or">
<item>
<p><local>super</local> must be <pt>any</pt>.</p>
</item>
<item>
<olist role="And">
<item><p><local>sub</local> must be a pair of <pt>not</pt> and a namespace name or
Required if <propref ref="&constraint;_name"/> is <pt>keyref</pt>, forbidden
otherwise. An &constraint; definition with <propref ref="&constraint;_name"/>
equal to <pt>key</pt> or <pt>unique</pt>.
</propdef>
<propdef id="rc-annotation" name="annotation">Optional. An annotation.</propdef>
</proplist>
</compdef>
<p>&Constraint; definitions are identified by their <propref ref="c-name"/> and <propref ref="c-target_namespace"/>; &Constraint; definition identities must be unique within an <termref def="key-schema">XML Schema</termref>. See <specref ref="composition-schemaImport"/> for the use of component
identifiers when importing one schema into another.</p>
<p>Informally, <propref ref="&constraint;_name"/> identifies the &Constraint; definition as playing one of
three roles:
<ulist>
<item><p>(<pt>unique</pt>) the &Constraint; definition asserts uniqueness, with respect to the content
identified by <propref ref="selector"/>, of the tuples resulting from
evaluation of the <propref ref="fields"/> XPath expression(s). </p></item>
<item>
<p>(<pt>key</pt>) the &Constraint; definition asserts uniqueness as for
<pt>unique</pt>. <pt>key</pt> further asserts that all selected content
actually has such tuples.</p>
</item>
<item><p>(<pt>keyref</pt>) the &Constraint; definition asserts a correspondence, with respect to the content
identified by <propref ref="selector"/>, of the tuples resulting from
evaluation of the <propref ref="fields"/> XPath expression(s), with those of the <propref ref="referenced_key"/>. </p></item>
</ulist> </p>
<p>These constraints are specified along side the specification of types for the
attributes and elements involved, i.e. something declared as of type integer
may also serve as a key. Each constraint declaration has a name, which exists in a
single symbol space for constraints. The equality and inequality conditions
appealed to in checking these constraints apply to the <emph>value</emph> of
the fields selected, so that for example <code>3.0</code> and <code>3</code>
would be conflicting keys if they were both number, but non-conflicting if
they were both strings, or one was a string and one a number. Values of
differing type can only be equal if one type is derived from the other, and the
value is in the value space of both.</p>
<p>Overall the augmentations to XML's <code>ID/IDREF</code> mechanism are:</p>
<ulist>
<item>
<p>Functioning as a part of an &constraint; is in addition to, not instead of,
having a type;</p>
</item>
<item><p>Not just attribute values, but also element content and combinations
of values and content can be declared to be unique;</p></item>
<item><p>&Constraint;s are specified to hold within the scope of particular elements;</p></item>
<item><p>(Combinations of) attribute values and/or element content can be
declared to be keys, that is, not only unique, but always present and non-nillable;</p></item>
<item>
<p>The comparison between <pt>keyref</pt> <propref ref="fields"/> and
<pt>key</pt> or <pt>unique</pt> <propref ref="fields"/> is by value equality,
not by string equality.</p>
</item>
</ulist>
<p><propref ref="selector"/> specifies a restricted XPath (<bibref ref="bib-xpath"/>) expression relative to
instances of the element being declared. This must identify a node set of
subordinate elements (i.e. contained within the declared element) to which the constraint applies.</p>
<p><propref ref="fields"/> specifies XPath expressions relative to each
element selected by a <propref ref="selector"/>. This must identify
a single node (element or attribute) whose content or value, which must be
of a simple type, is used in the constraint. It is possible to specify an
ordered list of <propref ref="fields"/>s, to cater to multi-field keys,
keyrefs, and uniqueness constraints.
</p>
<p>In order to reduce the burden on implementers, in particular
implementers of streaming processors, only restricted subsets of XPath
expressions are allowed in <propref ref="selector"/> and <propref ref="fields"/>. The details are given in <specref ref="coss-&constraint;"/>.</p>
<note>
<p>Provision for multi-field keys etc. goes beyond what is supported by <code>xsl:key</code>.</p>
</note>
<p>See <specref ref="cAnnotations"/> for information on the role of the
<propref ref="rc-annotation"/> property.</p>
</div3>
<div3 id="declare-key">
<head>XML Representation of &Constraint; Definition Schema Components</head>
<p>The XML representation for an &constraint; definition schema component is
either a
<eltref ref="key"/>, a <eltref ref="keyref"/> or a <eltref ref="unique"/>
element information item. The correspondences between the
properties of those information items and
properties of the component they correspond to are as follows:</p>
<reprdef>
<reprelt eltname="unique"/>
<reprelt eltname="key"/>
<reprelt eltname="keyref"/>
<reprelt eltname="selector"/>
<reprelt eltname="field"/>
<reprcomp abstract="&Constraint; Definition" ref="&Constraint;_Definition_details"><propmap name="c-name">The &v-value; of the <code>name</code> &i-attribute;</propmap>
<propmap name="c-target_namespace">The &v-value; of the
<code>targetNamespace</code> &i-attribute; of the parent <code>schema</code>
element information item.</propmap>
<propmap name="&constraint;_name">One of <pt>key</pt>, <pt>keyref</pt> or
<pt>unique</pt>, depending on the item.</propmap>
<propmap name="selector">A restricted XPath expression corresponding to the &v-value; of
the <code>xpath</code> &i-attribute; of the <eltref ref="selector"/> element information item among the &i-children;</propmap>
<propmap name="fields">A sequence of XPath expressions, corresponding to the
&v-value;s of the <code>xpath</code> &i-attribute;s of the <eltref ref="field"/> element information item &i-children;, in order.</propmap>
<propmap name="referenced_key">If the item is a <eltref ref="keyref"/>, the
&constraint; definition <termref def="src-resolve">resolved</termref> to by the
&v-value; of the <code>refer</code> &i-attribute;, otherwise <termref def="key-null">absent</termref>.</propmap>
<propmap name="rc-annotation">The annotation corresponding to the <eltref ref="annotation"/> element information item in the
&i-children;, if present, otherwise <termref def="key-null">absent</termref>.</propmap>
<p>For an element information item to be locally <termref def="key-vn">valid</termref> with respect to an &constraint;
<olist role="and">
<item>
<p>The <propref ref="selector"/>, with the element information item as the
context node, evaluates to a node-set (as defined in
<bibref ref="bib-xpath"/>). <termdef id="key-tns" term="target node set" role="local">Call this the <term>target node set</term></termdef>.</p>
</item>
<item>
<p>Each node in the <termref def="key-tns">target node set</termref> is an
element node among the descendants of the context node.</p>
</item>
<item>
<p>For each node in the <termref def="key-tns">target node set</termref> all of the <propref ref="fields"/>, with that node as the context
node, evaluate to either an empty node-set or a node-set with exactly one
member, which must have a simple type. <termdef id="key-ks" term="key-sequence" role="local">Call the sequence of the
type-determined values (as defined in <bibref ref="ref-xsp2"/>) of the
<xpropref role="psviAnon">schema normalized value</xpropref> of the element and/or attribute information items in those node-sets in order the <term>key-sequence</term> of the node</termdef>.</p>
</item>
<item>
<p>
<termdef id="key-qns" term="qualified node set" role="local">Call the subset of the <termref def="key-tns">target node set</termref> for
which all the <propref ref="fields"/> evaluate to a node-set with exactly one
member which is an element or attribute node with a simple type the <term>qualified node set</term></termdef>.
<olist role="Case">
<item id="c-u">
<p role="if">the <propref ref="&constraint;_name"/> is <pt>unique</pt></p>
<p role="then">no two members of the <termref def="key-qns">qualified node
set</termref> have <termref def="key-ks">key-sequences</termref> whose members
are pairwise equal, as defined by <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#equal">Equal</xtermref> in <bibref ref="ref-xsp2"/>.</p>
</item>
<item id="c-k">
<p role="if">the <propref ref="&constraint;_name"/> is <pt>key</pt></p>
<p role="then">
<olist role="and">
<item>
<p>The <termref def="key-tns">target node set</termref> and the <termref def="key-qns">qualified node
set</termref> are equal, that is, every member of the <termref def="key-tns">target node set</termref> is also a member of the <termref def="key-qns">qualified node
set</termref> and <emph>vice versa</emph>.</p>
</item>
<item>
<p>No two members of the <termref def="key-qns">qualified node
set</termref> have <termref def="key-ks">key-sequences</termref> whose members
are pairwise equal, as defined by <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#equal">Equal</xtermref> in <bibref ref="ref-xsp2"/>.</p>
</item>
<item id="c-nlbl">
<p>No element member of the <termref def="key-ks">key-sequence</termref> of any
member of the <termref def="key-qns">qualified node
set</termref> was assessed as <termref def="key-vn">valid</termref> by reference to an element
declaration whose <propref ref="nillable"/> is <pt>true</pt>.</p>
</item>
</olist>
</p>
</item>
<item>
<p role="if">the <propref ref="&constraint;_name"/> is <pt>keyref</pt></p>
<p role="then">for each member of the <termref def="key-qns">qualified node
set</termref> (call this the <local>keyref member</local>), there must be a <termref def="key-nt">node table</termref> associated with the
<propref ref="referenced_key"/> in the <propref role="psvi" ref="e-id_constraint_table"/>
of the element information item (see <specref ref="sic-key"/>, which must be
understood as logically prior to this clause of this constraint, below) and
there must be an entry in that table whose
<termref def="key-ks">key-sequence</termref> is equal to the
<local>keyref member's</local> <termref def="key-ks">key-sequence</termref> member for
member, as defined by <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#equal">Equal</xtermref> in <bibref ref="ref-xsp2"/>.</p>
</item>
</olist>
</p>
</item>
</olist>
</p>
<note>
<p>The use of <xpropref role="psviAnon">schema normalized value</xpropref> in the definition
of <termref def="key-ks">key sequence</termref> above means that
<pt>default</pt> or <pt>fixed</pt> value constraints may play a part in <termref def="key-ks">key sequence</termref>s.</p>
</note>
</constraintnote>
<note>
<p>Although this specification defines a &PSVI;
contribution which would enable schema-aware processors to implement <clauseref ref="c-nlbl"/> above (<specref ref="sic-elt-decl"/>), processors are not required to
provide it. This clause can be read as if in the absence of this infoset contribution, the
value of the relevant <propref ref="nillable"/> property must be available.</p>
</note>
</div3>
<div3>
<head>&Constraint; Definition Information Set Contributions</head>
&constraint;</term> of an element information item is one such that <clauseref ref="c-u"/> or <clauseref ref="c-k"/> of <specref ref="cvc-&constraint;"/> is satisfied
with respect to that item and that constraint,
or such that any of the element information item &i-children; of that item have an
<propref role="psvi" ref="e-id_constraint_table"/> property whose value has an entry for that constraint</termdef>.</p>
<p><termdef id="key-nt" term="node table" role="local">A <term>node table</term> is a set
of pairs each consisting of
a <termref def="key-ks">key-sequence</termref> and an element node</termdef>.</p>
<p>Whenever an element information item has one or more <termref def="key-ec">eligible &constraint;s</termref>, in the &PSVI; that element information item has a property as follows:</p>
<propdef id="cb-node_table" name="node table">A <termref def="key-nt">node table</termref> with one entry for every
<termref def="key-ks">key-sequence</termref> (call it <local>k</local>) and node (call it <local>n</local>) such that
<olist role="or">
<item id="c-kc">
<p>There is an entry in one of the <termref def="key-nt">node
tables</termref> associated with the <propref role="psvi" ref="cb-definition"/> in an
<local>&Constraint; Binding</local>
information item in at least one of the <propref role="psvi" ref="e-id_constraint_table"/>s of the element information item &i-children; of the element
information item whose <termref def="key-ks">key-sequence</termref> is <local>k</local> and whose node is <local>n</local>;</p>
</item>
<item>
<p><local>n</local> appears with
<termref def="key-ks">key-sequence</termref> <local>k</local> in the <termref def="key-qns">qualified node
set</termref> for the <propref role="psvi" ref="cb-definition"/>.</p>
</item>
</olist>
provided no two entries have the same <termref def="key-ks">key-sequence</termref> but distinct nodes. Potential conflicts are resolved by not including any conflicting entries which would have owed their inclusion to <clauseref ref="c-kc"/> above. Note that if all the conflicting entries arose under <clauseref ref="c-kc"/> above, this means no entry at all will appear for the offending <termref def="key-ks">key-sequence</termref>.</propdef>
</proplist>
</propdef>
</proplist>
<note>
<p>The complexity of the above arises from the fact that
<pt>keyref</pt> &constraint;s may be defined on domains distinct from the
embedded domain of the &constraint; they reference, or the domains may be the
same but self-embedding at some depth. In either case the <termref def="key-nt">node
table</termref> for the referenced &constraint; needs to propagate upwards, with
conflict resolution.</p>
<p>The <local>&Constraint; Binding</local>
information item, unlike others in this
specification, is essentially an internal bookkeeping mechanism. It is introduced to
support the definition of <specref ref="cvc-identity-constraint"/> above.
Accordingly, conformant processors may, but are <emph>not</emph> required to,
expose them via
<propref role="psvi" ref="e-id_constraint_table"/> properties in the &PSVI;.
In other words, the above constraints may be read as saying <termref def="key-vn">validation</termref> of
&constraint;s proceeds <emph>as if</emph> such infoset items existed.
</p></note>
</constraintnote>
</div3>
<div3 id="coss-&constraint;">
<head>Constraints on &Constraint; Definition Schema Components</head>
<p>All &constraint; definitions (see <specref ref="c&Constraint;_Definitions"/>) must satisfy the following constraint.</p>
<p>Whenever an attribute information item is <termref def="key-vn">valid</termref> with respect to a <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#NOTATION">NOTATION</xtermref>, in the &PSVI; its parent element information item either has a property as follows:</p>
<proplist item="element" role="psvi">
<propdef id="e-notation" name="notation">An
<termref def="key-iso">item isomorphic</termref> to the notation declaration whose <propref ref="n-name"/> and <propref ref="n-target_namespace"/> match the <termref def="q-local">local name</termref> and <termref def="q-uri">namespace name</termref> (as defined in <specref ref="src-qname"/>) of the attribute item's &v-value;</propdef>
</proplist>
<p>or has a pair of properties as follows:</p>
<proplist item="element" role="psvi">
<propdef id="e-notation_system" name="notation system">The value of the <propref ref="system_identifier"/> of that notation declaration.</propdef>
<propdef id="e-notation_public" name="notation public">The value of the <propref ref="public_identifier"/> of that notation declaration.</propdef>
</proplist>
<note>
<p>For compatibility, only one such attribute should appear on any given
element. If more than one such attribute <emph>does</emph> appear, which one
supplies the infoset property or properties above is not defined.</p>
</note>
</constraintnote>
</div3>
<div3 id="coss-notation">
<head>Constraints on Notation Declaration Schema Components</head>
<p>All notation declarations (see <specref ref="cNotation_Declarations"/>) must satisfy the following constraint.</p>
<constraintnote type="cos" id="n-props-correct">
<head>Notation Declaration Correct</head>
<p>The values of the properties of a notation declaration must be as described in
the property tableau in
<specref ref="Notation_Declaration_details"/>, modulo the impact of <specref ref="conformance-missing"/>.</p>
</constraintnote>
</div3>
</div2>
<div2 id="cAnnotations">
<head>Annotations</head>
<p>Annotations provide for human- and machine-targeted annotations of
<propdef id="attributes" name="attributes">A sequence of attribute
information items.</propdef>
</proplist>
</compdef>
<p><propref ref="user_information"/> is intended for human consumption,
<propref ref="application_information"/> for automatic processing. In both
cases, provision is made for an optional URI reference to supplement the local
information, as the value of the <code>source</code> attribute of the
respective element information items. <termref def="key-vn">Validation</termref> does <emph>not</emph> involve dereferencing these URIs, when present. In the case of <propref ref="user_information"/>, indication should be given as to the identity of the (human) language used in the contents, using the <code>xml:lang</code> attribute.</p>
<p><propref ref="attributes"/> ensures that when schema authors take
advantage of the provision for adding attributes from namespaces other than the
XML Schema namespace to schema documents, they are available within the components
corresponding to the element items where such attributes appear.</p>
<p>Annotations do not participate in <termref def="key-vn">validation</termref> as such. Provided
an annotation itself satisfies all relevant <termref def="gloss-cos">Schema
Component Constraints</termref> it <emph>cannot</emph> affect the <termref def="key-vn">validation</termref> of element information items.</p>
</div3>
<div3 id="declare-annotation">
<head>XML Representation of Annotation Schema Components</head>
<p>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
<eltref ref="annotation"/>
element information item. The correspondences between the
properties of that information item and
properties of the component it corresponds to are as follows:</p>
<propmap name="application_information">A sequence of the <eltref ref="appinfo"/> element
information items from among the &i-children;, in order, if any, otherwise the
empty sequence.</propmap>
<propmap name="user_information">A sequence of the <eltref ref="documentation"/> element
information items from among the &i-children;, in order, if any, otherwise the
empty sequence.</propmap>
<propmap name="attributes">A sequence of attribute information items, namely
those allowed by the attribute wildcard in the type definition for the <eltref ref="annotation"/> item itself or for the enclosing items which correspond to the component within which the annotation component is located.</propmap>
</reprcomp></reprdef>
<p>The annotation component corresponding to the <eltref ref="annotation"/>
element in the example above will have one element item in each of its <propref ref="user_information"/> and <propref ref="application_information"/> and one attribute item in its <propref ref="attributes"/>.</p></div3>
<div3>
<head>Constraints on XML Representations of Annotations</head>
<p>As specified in &XSP2;, <pt>list</pt> simple type definitions <termref def="key-vn">validate</termref> space separated tokens, each of
which conforms to a specified simple type definition, the <propref ref="st-item_type_definition"/>. The item type specified
must not itself be a <pt>list</pt> type, and must be one of the types identified in &XSP2; as a
suitable item type for a list simple type. In this case the <propref ref="facets"/>
apply to the list itself, and are restricted to those appropriate for lists.</p>
<p>A <pt>union</pt> simple type definition <termref def="key-vn">validates</termref> strings which satisfy at
least one of its <propref ref="st-member_type_definitions"/>. As in the case of
<pt>list</pt>, the <propref ref="facets"/>
apply to the union itself, and are restricted to those appropriate for unions.</p>
<p>As discussed in
<specref ref="Type_Derivation"/>, the <termref def="key-urType">ur-type
definition</termref> functions as a simple type when used as the <termref def="st-base_type_definition">base type definition</termref> for the built-in primitive datatypes and for list and union type definitions. It is considered to have an unconstrained lexical space, and a value space consisting of the union of the value spaces of all the built-in primitive datatypes and the set of all lists of all members of the value spaces of all the built-in primitive datatypes.</p>
<p>The simple <termref def="key-urType">ur-type
definition</termref> must <emph>not</emph> be named as the <termref def="st-base_type_definition">base type definition</termref> of any user-defined simple types: as it has no constraining facets, this would be incoherent.</p>
<p>See <specref ref="cAnnotations"/> for information on the role of the
<propref ref="st-annotation"/> property.</p>
</div3>
<div3 id="declare-datatype">
<head>(non-normative) XML Representation of Simple Type Definition Schema Components</head>
<note>
<p>This section reproduces a version of material from <bibref ref="ref-xsp2"/>, for local cross-reference purposes.</p>
</note>
<reprdef>
<reprelt eltname="simpleType" type="simpleType"/>
<reprelt eltname="restriction"/>
<reprelt eltname="list"/>
<reprelt eltname="union"/>
<reprcomp abstract="Simple Type Definition" ref="Simple_Type_Definition_details">
<propmap name="st-name">The &v-value; of the <code>name</code> &i-attribute; if present, otherwise <termref def="key-null">absent</termref>.</propmap>
<propmap name="st-target_namespace">The &v-value; of the
<code>targetNamespace</code> &i-attribute; of the <eltref ref="schema"/> ancestor
element information item if present, otherwise <termref def="key-null">absent</termref>.</propmap>
<propmap name="st-base_type_definition">
<olist role="Caseval">
<item>
<p role="if">the <eltref ref="restriction"/> alternative is chosen</p>
<p role="then">the type definition <termref def="src-resolve">resolved</termref> to by the
&v-value; of the <code>base</code> &i-attribute; of <eltref ref="restriction"/>, if present, otherwise the
type definition corresponding to the <eltref ref="simpleType"/> among
the &i-children; of <eltref ref="restriction"/>.</p>
</item>
<item>
<p role="if">the <eltref ref="list"/> or <eltref ref="union"/> alternative is chosen</p>
<p role="if">the <eltref ref="union"/> alternative is chosen</p>
<p role="then"><termdef id="key-exm" term="explicit members" role="local">define the
<term>explicit members</term> as</termdef> the type definitions <termref def="src-resolve">resolved</termref> to by the
items in the &v-value; of the <code>memberTypes</code>
&i-attribute;, if any, followed by the
type definitions corresponding to the <eltref ref="simpleType"/>s among the
&i-children; of <eltref ref="union"/>, if any. The actual value is then formed by replacing any union type definition
in the <termref def="key-exm">explicit members</termref> with the members of
their <propref ref="st-member_type_definitions"/>, in order.</p>
</item>
<item>
<p role="if">the <eltref ref="restriction"/> option is chosen</p>
<p role="then">the <propref ref="st-member_type_definitions"/> of the <propref ref="st-base_type_definition"/>.</p>
</item>
</olist>
</propmap>
<propmap name="facets">If the <eltref ref="restriction"/> alternative is
chosen, a set of facet components <termref def="key-facets-restriction">constituting a restriction</termref>
of the <propref ref="facets"/> of the
<propref ref="st-base_type_definition"/> with respect to a
set of facet components corresponding to the appropriate element information items among the
&i-children; of <eltref ref="restriction"/> (i.e. those which specify facets, if any), as
defined in <specref ref="st-restrict-facets"/>, otherwise the empty set.</propmap>
</reprcomp>
</reprdef>
</div3>
<div3>
<head>(non-normative) Constraints on XML Representations of Simple Type Definitions</head>
<constraintnote type="src" id="src-simple-type">
<head>Simple Type Definition Representation OK</head>
<p>In addition to the conditions imposed on <eltref ref="simpleType"/> element
information items by the schema for schemas,
<olist role="and">
<item>
<p>The corresponding simple type definition, if any, must satisfy the conditions set
out in <specref ref="coss-st"/>.</p>
</item>
<item><p>If the <eltref ref="restriction"/> alternative is chosen, either
it must have a <code>base</code> &i-attribute; or a <eltref ref="simpleType"/>
among its &i-children;, but not both.</p>
</item>
<item><p>If the <eltref ref="list"/> alternative is chosen, either
it must have an <code>itemType</code> &i-attribute; or a <eltref ref="simpleType"/>
among its &i-children;, but not both.</p>
</item>
<item>
<p>Circular union type definition is disallowed. That is, if the <eltref ref="union"/> alternative is chosen, there must not be any entries in the <code>memberTypes</code> &i-attribute; at any depth which resolve to the component corresponding to the <eltref ref="simpleType"/>.</p>
<p>For a simple type definition (call it <local>R</local>) to restrict another simple type
definition (call it <local>B</local>) with a
set of facets (call this <local>S</local>)
<olist role="and">
<item>
<p>The <propref ref="variety"/> and <propref ref="st-primitive_type_definition"/> of <local>R</local> are the same as those of <local>B</local>.</p>
</item>
<item id="c-fr">
<p>The <propref ref="facets"/> of <local>R</local> are the union of <local>S</local> and
the <propref ref="facets"/> of <local>B</local>, eliminating duplicates. To eliminate
duplicates, when a facet of the same kind occurs in both <local>S</local> and
the <propref ref="facets"/> of <local>B</local>, the one in the <propref ref="facets"/>
of <local>B</local> is not included, with the exception of <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-enumeration">enumeration</xtermref> and <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dt-pattern">pattern</xtermref> facets, for which multiple occurrences with distinct values are allowed.</p>
</item>
</olist>
</p>
<p><termdef id="key-facets-restriction" term="constitute a restriction" role="local">If
<clauseref ref="c-fr"/> above holds, the <propref ref="facets"/> of <local>R</local>
<term>constitute a restriction</term> of the <propref ref="facets"/> of
<local>B</local> with respect to <local>S</local></termdef>.</p>
</constraintnote>
</div3>
<div3>
<head>Simple Type Definition Validation Rules</head>
<constraintnote type="cvc" id="cvc-simple-type">
<head>String Valid</head>
<p>A string is locally <termref def="key-vn">valid</termref> with respect to a simple type definition if
it is schema-valid with respect to that definition as defined by
<xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes.html#cvc-datatype-valid">Datatype Valid</xtermref> in <bibref ref="ref-xsp2"/>.
</p>
</constraintnote>
</div3>
<div3>
<head>Simple Type Definition Information Set
Contributions</head>
<p>None as such.</p>
</div3>
<div3 id="coss-st">
<head>Constraints on Simple Type Definition
Schema Components</head>
<p>All simple type definitions (see <specref ref="Simple_Type_Definitions"/>) must satisfy the following constraints.</p>
<constraintnote type="cos" id="st-props-correct">
<head>Simple Type Definition Properties Correct</head>
<olist role="And">
<item><p>The values of the properties of a simple type definition must be as described in
the property tableau in
<xspecref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#dc-defn">Datatype definition</xspecref>, modulo the impact of <specref ref="conformance-missing"/>.</p></item>
<item><p>Circular definitions are disallowed. That is, it must be possible to reach a built-in
primitive datatype or the <termref def="simple-ur-type-itself">simple ur-type definition</termref> by repeatedly following the <propref ref="st-base_type_definition"/>.</p></item>
<item>
<p>The <propref ref="st-final"/> of the <propref ref="st-base_type_definition"/> must not contain <pt>restriction</pt>.</p>
</item>
<item>
<p>If the <propref ref="st-base_type_definition"/> is not the <termref def="simple-ur-type-itself">simple ur-type definition</termref>,
<olist role="and">
<item>
<p>The definition must be a <termref def="cd-st-restriction">valid restriction</termref> as defined in
<specref ref="cos-st-restricts"/>.</p>
</item>
<item>
<p>If <propref ref="variety"/> is not <pt>atomic</pt>, then
<olist role="case">
<item>
<p role="if">the <propref ref="variety"/> is <pt>list</pt></p>
<p role="then">the <propref ref="st-final"/> of the <propref ref="st-base_type_definition"/> must not contain <pt>list</pt>.</p>
</item>
<item>
<p role="if">the <propref ref="variety"/> is <pt>union</pt></p>
<p role="then">the <propref ref="st-final"/> of the <propref ref="st-base_type_definition"/> must not contain <pt>union</pt>.</p>
<p role="if">the <propref ref="variety"/> is <pt>atomic</pt></p>
<p role="then">
<olist role="and">
<item>
<p>The <propref ref="st-base_type_definition"/> must be an atomic simple type
definition or a built-in
primitive datatype.</p>
</item>
<item>
<p>The <propref ref="st-final"/> of the <propref ref="st-base_type_definition"/> must not contain <pt>restriction</pt>.</p>
</item>
<item>
<p>For each facet in the <propref ref="facets"/> there must be a facet of the same kind in the
<propref ref="facets"/> of the <propref ref="st-base_type_definition"/> of
whose <xpropref role="anon">value</xpropref> the facet in question's <xpropref role="anon">value</xpropref> must be a valid restriction as
defined in <bibref ref="ref-xsp2"/>.</p>
</item>
</olist></p>
</item>
<item>
<p role="if">the <propref ref="variety"/> is <pt>list</pt></p>
<p role="then">
<olist role="and">
<item>
<p>The <propref ref="st-item_type_definition"/> must have a <propref ref="variety"/> of <pt>atomic</pt> or <pt>union</pt> (in which case all the <propref ref="st-member_type_definitions"/> must be <pt>atomic</pt>).</p>
<pt>time</pt>, <pt>date</pt>, <pt>gMonth</pt>, <pt>gMonthDay</pt>, <pt>gDay</pt>, <pt>gYear</pt>, <pt>gYearMonth</pt>, <pt>hexBinary</pt>, <pt>base64Binary</pt>, <pt>anyURI</pt> (see the <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#built-in-primitive-datatypes">Primitive
Datatypes</xtermref> section of &XSP2;), as well as for the
simple and complex <termref def="key-urType">ur-type definitions</termref> (as previously described), are present by definition in every schema. All
are in the XML Schema <propref ref="st-target_namespace"/> (namespace
name <code>http://www.w3.org/2001/XMLSchema</code>), have an <pt>atomic</pt> <propref ref="variety"/> with an empty
<propref ref="facets"/> and the simple <termref def="key-urType">ur-type definition</termref> as
their <termref def="st-base_type_definition">base type definition</termref> and themselves as <propref ref="st-primitive_type_definition"/>.</p>
<p>Similarly, simple type definitions for all the built-in derived
datatypes (see the <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#built-in-derived">Derived
Datatypes</xtermref> section of &XSP2;) are present by definition in every schema, with
properties as specified in &XSP2; and as represented in XML in
<specref ref="normative-schemaSchema"/>.</p>
</div3>
</div2>
<div2 id="Schemas">
<head>Schemas as a Whole</head>
<p>A schema consists of a set of schema components.</p>
<note role="example">
<eg xml:space="preserve"><xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.com/example">
. . .
</xs:schema></eg>
<p>The XML representation of the skeleton of a schema.</p>
</note>
<div3 id="Schema_details">
<head>The Schema Itself</head>
<p>At the abstract level, the schema itself is just a container for its components.</p>
<compdef name="Schema" ref="key-schema">
<proplist>
<propdef id="type_definitions" name="type definitions">A set of
named simple and complex type definitions.</propdef>
<propdef id="attribute_declarations" name="attribute declarations">A set of
named (top-level) attribute declarations.</propdef>
<propdef id="element_declarations" name="element declarations">A set of
named (top-level) element declarations.</propdef>
<propdef id="attribute_group_definitions" name="attribute group definitions">A set of named
attribute group definitions.</propdef>
<propdef id="model_group_definitions" name="model group definitions">A set of named
model group definitions.</propdef>
<propdef id="notation_declarations" name="notation declarations">A set of
notation declarations.</propdef>
<propdef id="annotations" name="annotations">A set of annotations.</propdef>
</proplist>
</compdef>
</div3>
<div3 id="declare-schema">
<head>XML Representations of Schemas</head>
<p>A schema is represented in XML by one or more <termref def="key-schemaDoc">schema documents</termref>, that is, one or more <eltref ref="schema"/> element information items. A <termref def="key-schemaDoc">schema document</termref> contains representations for a collection of schema components, e.g. type definitions and element declarations, which have a common <xpropref role="anon">target namespace</xpropref>. A <termref def="key-schemaDoc">schema document</termref> which has one or more <eltref ref="import"/> element information items corresponds to a schema with components with more than one <xpropref role="anon">target namespace</xpropref>, see <specref ref="src-import"/>.</p>
<reprdef>
<reprelt eltname="schema"/>
<reprcomp abstract="Schema" ref="key-schema">
<propmap name="type_definitions">The simple and complex type definitions
corresponding to all the <eltref ref="simpleType"/> and <eltref ref="complexType"/> element information items in the
&i-children;, if any, plus any included or imported definitions, see <specref ref="compound-schema"/> and <specref ref="composition-schemaImport"/>.</propmap>
corresponding to all the <eltref ref="attribute"/> element information items in the
&i-children;, if any, plus any included or imported declarations, see <specref ref="compound-schema"/> and <specref ref="composition-schemaImport"/>.</propmap>
<propmap name="element_declarations">The (top-level) element declarations
corresponding to all the <eltref ref="element"/> element information items in the
&i-children;, if any, plus any included or imported declarations, see <specref ref="compound-schema"/> and <specref ref="composition-schemaImport"/>.</propmap>
<propmap name="attribute_group_definitions">The attribute group definitions
corresponding to all the <eltref ref="attributeGroup"/> element information items in the
&i-children;, if any, plus any included or imported definitions, see <specref ref="compound-schema"/> and <specref ref="composition-schemaImport"/>.</propmap>
<propmap name="model_group_definitions">The model group definitions
corresponding to all the <eltref ref="group"/> element information items in the
&i-children;, if any, plus any included or imported definitions, see <specref ref="compound-schema"/> and <specref ref="composition-schemaImport"/>.</propmap>
corresponding to all the <eltref ref="notation"/> element information items in the
&i-children;, if any, plus any included or imported declarations, see <specref ref="compound-schema"/> and <specref ref="composition-schemaImport"/>.</propmap>
<propmap name="annotations">The annotations
corresponding to all the <eltref ref="annotation"/> element information items in the
&i-children;, if any.</propmap>
</reprcomp>
</reprdef>
<p>Note that none of the attribute information items displayed above
correspond directly to properties of schemas. The <code>blockDefault</code>,
<code>finalDefault</code>, <code>attributeFormDefault</code>, <code>elementFormDefault</code>and <code>targetNamespace</code> attributes are appealed to in the sub-sections above, as they provide
global information applicable to many representation/component correspondences. The
other attributes (<code>id</code> and <code>version</code>) are for user
convenience, and this specification defines no semantics for them.</p>
<p>The definition of the schema abstract data model in <specref ref="concepts-data-model"/> makes clear that most components have a <xpropref role="anon">target namespace</xpropref>. Most components corresponding to representations within a given <eltref ref="schema"/> element information item will have a <xpropref role="anon">target namespace</xpropref> which corresponds to the <code>targetNamespace</code> attribute. </p>
<p>Since the empty string is not a legal namespace name, supplying
an empty string for <code>targetNamespace</code> is incoherent, and is <emph>not</emph> the same
as not specifying it at all. The appropriate form of schema document
corresponding to a <termref def="key-schema">schema</termref> whose components have no
<propref ref="e-target_namespace"/> is one which has no
<code>targetNamespace</code> attribute specified at all.</p>
<note><p>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, the specification applies the target namespace facility uniformly to all
schema components, i.e. not only declarations but also definitions have a <xpropref role="anon">target namespace</xpropref>.</p>
</note>
<p>Although the example schema at the beginning of this section might be a complete XML document, <eltref ref="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.</p>
<p>Aside from <eltref ref="include"/> and <eltref ref="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 <eltref ref="schema"/> corresponds to
a schema component, and all except <eltref ref="annotation"/> are named. The
sections below
present each such item in turn, setting out the
components to which it may correspond.</p>
<div4 id="refSchemaConstructs">
<head>References to Schema Components</head>
<p>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
(<specref ref="composition-schemaImport"/>) from an external schema (which may,
but need not, correspond to an actual schema document). The form
of all such references is a
<termref def="gloss-QName">QName</termref>.</p>
<p><termdef id="gloss-QName" term="QName">A <term>QName</term> is a name
with an optional namespace qualification, as defined in <bibref ref="ref-xml-namespaces"/>. When used in connection with the XML
representation of schema components or references to them, this refers to the
simple type <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#QName">QName</xtermref> as defined in <bibref ref="ref-xsp2"/></termdef>.</p>
<p><termdef id="gloss-NCName" term="NCName">An <term>NCName</term> is a name
with no colon, as defined in <bibref ref="ref-xml-namespaces"/>. When used in connection with the XML
representation of schema components in this specification, this refers to the
simple type <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#NCName">NCName</xtermref> as defined in <bibref ref="ref-xsp2"/></termdef>.</p>
<p>In each of the XML
representation expositions in the following sections, an attribute is shown as
having type <code>QName</code> if and only if it is
interpreted as referencing a schema component.</p>
<p>The first of these is most probably a local reference, i.e. a reference
to a type
definition corresponding to a <eltref ref="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 <specref ref="composition-schemaImport"/> for a discussion of importing.</p>
</note>
</div4>
<div4>
<head>References to Schema Components from Elsewhere</head>
<p>The names of schema components such as type definitions and element
declarations are not of type <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#ID">ID</xtermref>: 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.</p>
<p>There is currently no provision in the definition of the interpretation
of fragment identifiers for the <code>text/xml</code> MIME type, which is the
MIME type for schemas, for referencing
schema components as such. However,
<bibref ref="ref-xpointer"/> provides a mechanism which maps well onto the
notion of symbol spaces as it is reflected in the XML representation of schema components. A fragment identifier of the form
<code>#xpointer(xs:schema/xs:element[@name="person"])</code> will uniquely identify
the representation of a top-level element declaration with name <code>person</code>, and similar fragment
identifiers can obviously be constructed for the other global symbol spaces.</p>
<p>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 <code>id</code> attribute for the representations of all primary and secondary schema
components, which <emph>is</emph> of type
<xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#ID">ID</xtermref>, has been exploited.</p>
<p>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.</p>
</div4>
</div3>
<div3>
<head>Constraints on XML Representations of Schemas</head>
<constraintnote type="src" id="src-qname">
<head>QName Interpretation</head>
<p>Where the type of an attribute information item in a document involved in
<termref def="key-vn">validation</termref> is
identified as
<termref def="gloss-QName">QName</termref>, its &v-value; is composed of a
<termdef id="q-local" term="local name" role="local"><term>local name</term></termdef> and a <termdef id="q-uri" term="namespace name" role="local"><term>namespace name</term></termdef>. Its &v-value; is determined based on its &i-value; and
the containing element information item's <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">in-scope
namespaces</xpropref> following <bibref ref="ref-xml-namespaces"/>:</p>
<p><olist role="Case">
<item>
<p role="if">its &i-value; is prefixed</p>
<p role="then">
<olist role="and">
<item>
<p>There must be a namespace in the <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">in-scope
namespaces</xpropref> whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.namespace">prefix</xpropref> matches the prefix.</p>
</item>
<item>
<p role="then">its <termref def="q-uri">namespace name</termref> is the
<p role="otherwise">its <termref def="q-uri">namespace name</termref> is <termref def="key-null">absent</termref>.</p>
</item>
</olist>
</item>
</olist></p>
</item>
</olist></p>
<p>In the absence of the <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">in-scope namespaces</xpropref> property in the infoset for the schema document in question, processors must reconstruct equivalent information as necessary, using the <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element"> namespace attributes</xpropref> of the containing element information item and its ancestors.</p>
</constraintnote>
<p><termdef id="key-resolve" term="resolve">Whenever the word <term>resolve</term> in any form is used in this
chapter in connection with a <termref def="gloss-QName">QName</termref> in a
schema document, the
following definition <specref ref="src-resolve"/> should be understood</termdef>:</p>
<constraintnote type="src" id="src-resolve">
<head>QName resolution (Schema Document)</head>
<p>For a <termref def="gloss-QName">QName</termref>
to resolve to a schema component of a specified kind
<olist role="and">
<item>
<p>That component is a member of the value of the appropriate
property of the schema which corresponds to the schema
document within which the <termref def="gloss-QName">QName</termref>
appears, that is
<olist role="case">
<item>
<p role="if">the kind specified is simple or complex type definition</p>
<p role="then">the property is the <propref ref="type_definitions"/>.</p>
</item>
<item>
<p role="if">the kind specified is attribute declaration</p>
<p role="then">the property is the <propref ref="attribute_declarations"/>.</p>
</item>
<item>
<p role="if">the kind specified is element declaration</p>
<p role="then">the property is the <propref ref="element_declarations"/>.</p>
</item>
<item>
<p role="if">the kind specified
is attribute group</p>
<p role="then">the property is the <propref ref="attribute_group_definitions"/>.</p>
</item>
<item>
<p role="if">the kind specified is
model group</p>
<p role="then">the property is the <propref ref="model_group_definitions"/>.</p>
</item>
<item>
<p role="if">the kind specified is notation declaration</p>
<p role="then">the property is the <propref ref="notation_declarations"/>.</p>
</item>
</olist>
</p>
</item>
<item>
<p>its <xpropref role="anon">local name</xpropref> matches the <termref def="q-local">local
name</termref> of the <termref def="gloss-QName">QName</termref>;</p>
</item>
<item>
<p>its <xpropref role="anon">target namespace</xpropref> is identical to the <termref def="q-uri">namespace name</termref> of the <termref def="gloss-QName">QName</termref>;</p>
</item>
<item>
<p>its <termref def="q-uri">namespace name</termref> is either the target
namespace of the schema document containing the <termref def="gloss-QName">QName</termref> or that schema document contains an <eltref ref="import"/> element information item the &v-value; of whose <code>namespace</code> &i-attribute; is identical to that <termref def="q-uri">namespace name</termref>.</p>
</item>
</olist>
</p>
</constraintnote>
</div3>
<div3>
<head>Validation Rules for Schemas as a Whole</head>
<p>As the discussion above at <specref ref="components"/> makes clear, at the level of schema components and <termref def="key-vn">validation</termref>, reference to components by name is normally not involved. In a
few cases, however, qualified names appearing in information items being
<termref def="key-vn">validated</termref> must be resolved to schema components by such lookup. The following
<p>A pair of a local name and a namespace name (or <termref def="key-null">absent</termref>)
resolve to a schema component of a specified kind in the context of <termref def="key-vn">validation</termref> by appeal to the appropriate
property of the schema being used for the <termref def="key-va">assessment</termref>. Each such property indexes components by name. The property to use is determined by the kind of component specified, that is,
<olist role="case">
<item>
<p role="if">the kind specified is simple or complex type definition</p>
<p role="then">the property is the <propref ref="type_definitions"/>.</p>
</item>
<item>
<p role="if">the kind specified is attribute declaration</p>
<p role="then">the property is the <propref ref="attribute_declarations"/>.</p>
</item>
<item>
<p role="if">the kind specified is element declaration</p>
<p role="then">the property is the <propref ref="element_declarations"/>.</p>
</item>
<item>
<p role="if">the kind specified
is attribute group</p>
<p role="then">the property is the <propref ref="attribute_group_definitions"/>.</p>
</item>
<item>
<p role="if">the kind specified is
model group</p>
<p role="then">the property is the <propref ref="model_group_definitions"/>.</p>
</item>
<item>
<p role="if">the kind specified is notation declaration</p>
<p role="then">the property is the <propref ref="notation_declarations"/>.</p>
</item>
</olist>
The component resolved to is the entry in the table whose <xpropref role="anon">local
name</xpropref> matches the local name of the pair and whose <xpropref role="anon">target namespace</xpropref> is identical to the namespace name of the pair.
</p>
</constraintnote>
</div3>
<div3>
<head>Schema Information Set Contributions</head>
<constraintnote type="sic" id="sic-schema">
<head>Schema Information</head>
<p>Schema components provide a wealth of information about the basis of
<termref def="key-va">assessment</termref>, which may well be of relevance to
subsequent processing. Reflecting component structure into a form suitable for
inclusion in the &PSVI; is the way this specification provides for making this
information available.</p>
<p>Accordingly, <termdef id="key-iso" term="item isomorphic to a component"> by an <term>item isomorphic</term> to a component is meant an information item whose type is equivalent to the component's, with one property per property of the component, with the same name, and value either the same atomic value, or an information item corresponding in the same way to its component value, recursively, as necessary</termdef>.</p>
<p>Processors must add a property in the &PSVI;
to the element information item at which <termref def="key-va">assessment</termref> began, as follows:</p>
<proplist item="element" role="psvi">
<propdef id="e-schema_information" name="schema information">A set of <iiName>namespace schema information</iiName> information items, one for each namespace name which appears as the
<xpropref role="anon">target namespace</xpropref> of any schema component in the schema used for that
assessment, and one for <termref def="key-null">absent</termref> if any schema
component in the schema had no <xpropref role="anon">target namespace</xpropref>. Each <iiName>namespace schema information</iiName> information item has the
empty) set of schema component information items, each one an <termref def="key-iso">item isomorphic</termref> to a component whose <xpropref role="anon">target
namespace</xpropref> is the sibling <propref ref="nsi-schema_namespace" role="psvi"/>
property above, drawn from the schema used for <termref def="key-va">assessment</termref>.</propdef>
information item, if available, otherwise <termref def="key-null">absent</termref>.</propdef>
</proplist>
</propdef>
</proplist>
</propdef>
</proplist>
<p>The <propref ref="nsi-schema_components"/> property is provided for
processors which wish to provide a single access point to the
components of the schema which was used during <termref def="key-va">assessment</termref>. Lightweight processors are free to leave it empty, but if it <emph>is</emph> provided, it must contain at a minimum all the top-level (i.e. named) components which actually figured in the <termref def="key-va">assessment</termref>, either directly or (because an anonymous component which figured is contained within) indirectly.</p>
</constraintnote>
<constraintnote type="sic" id="sic-id">
<head>ID/IDREF Table</head>
<p>In the &PSVI; a set of <iiName>ID/IDREF binding</iiName> information items is associated
with the <termref def="key-vr">validation root</termref> element information
item:</p>
<proplist item="element" role="psvi">
<propdef name="ID/IDREF table" id="e-ii_table">A (possibly empty) set of
<iiName>ID/IDREF binding</iiName> information items, as specified below.</propdef>
</proplist>
<p><termdef id="key-eas" term="eligible item set" role="local">Let the
<term>eligible item set</term> be the set of consisting of every attribute or element
information item</termdef> for which
<olist role="andtest">
<item>
<p>its <xpropref role="psviAnon">validation context</xpropref> is the
<p>it was successfully <termref def="key-vn">validated</termref> with respect to an attribute
declaration as per <specref ref="cvc-attribute"/> or element declaration as per
<specref ref="cvc-elt"/> (as appropriate) whose attribute <propref ref="a-simple_type_definition"/> or element <propref ref="type_definition"/> (respectively) is the
built-in <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#ID">ID</xtermref>, <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#IDREF">IDREF</xtermref> or <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#IDREFS">IDREFS</xtermref> simple type definition or a type derived from one of them.</p>
</item>
</olist></p>
<p>Then there is one <iiName>ID/IDREF binding</iiName> in the <propref ref="e-ii_table" role="psvi"/>
for every distinct string which is</p><olist role="orval">
<item>
<p>the &v-value; of a member of the <termref def="key-eas">eligible
item set</termref> whose type definition is or is derived from <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#ID">ID</xtermref> or <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#IDREF">IDREF</xtermref>;</p>
</item>
<item>
<p>one of the items in the &v-value; of a member of the <termref def="key-eas">eligible
item set</termref> whose type definition is or is derived from <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#IDREFS">IDREFS</xtermref>.</p>
</item>
</olist>
<p>Each <iiName>ID/IDREF binding</iiName> has properties as follows:</p>
its &i-attributes; or an element information item in its &i-children; which was <termref def="key-vn">validated</termref> by the
built-in <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#ID">ID</xtermref> simple type definition or a type derived from it whose
<xpropref role="psviAnon">schema normalized value</xpropref> is the <propref role="psvi" ref="iib-id"/> of
this <iiName>ID/IDREF binding</iiName>.</p>
</item>
</olist>
</propdef>
</proplist>
<p>The net effect of the above is to have one entry for every string used as an
id, whether by declaration or by reference, associated with those elements, if
any, which actually purport to have that id. See <specref ref="cvc-id"/> above
for the validation rule which actually checks for errors here.</p>
<note>
<p>The <iiName>ID/IDREF binding</iiName>
information item, unlike most other aspects of this
specification, is essentially an internal bookkeeping mechanism. It is introduced to
support the definition of <specref ref="cvc-id"/> above.
Accordingly, conformant processors may, but are <emph>not</emph> required to,
expose it in the &PSVI;.
In other words, the above constraint may be read as saying <termref def="key-va">assessment</termref> proceeds <emph>as if</emph> such an infoset item existed.</p></note>
</constraintnote>
</div3>
<div3 id="coss-schema">
<head>Constraints on Schemas as a Whole</head>
<p>All schemas (see <specref ref="Schemas"/>) must satisfy the following constraint.</p>
<p>The values of the properties of a schema must be as described in
the property tableau in
<specref ref="Schema_details"/>, modulo the impact of <specref ref="conformance-missing"/>;</p>
</item>
<item id="c-nmd">
<p>Each of the <propref ref="type_definitions"/>, <propref ref="element_declarations"/>, <propref ref="attribute_group_definitions"/>, <propref ref="model_group_definitions"/> and <propref ref="notation_declarations"/> must not contain two or more schema components with the same <xpropref role="anon">name</xpropref> and <xpropref role="anon">target
namespace</xpropref>.</p>
</item>
</olist>
</constraintnote>
</div3>
</div2>
</div1>
<div1 id="composition">
<head>Schemas and Namespaces: Access and Composition</head>
<p>This chapter defines the mechanisms by which this specification establishes the necessary
precondition for <termref def="key-va">assessment</termref>, namely access to
one or more schemas. This chapter also sets out in detail the relationship
between schemas and namespaces, as well as mechanisms for
modularization of schemas, including provision for incorporating definitions
and declarations from one schema in another, possibly with modifications.</p>
<p><specref ref="concepts-conformance"/> describes three levels of conformance for schema
processors, and <specref ref="conformance"/> provides a formal definition of
<termref def="key-va">assessment</termref>. This section sets out
in detail the 3-layer architecture implied by the three conformance levels.
The layers
are: </p>
<olist>
<item><p>The <termref def="key-va">assessment</termref> core, relating schema components and instance
information items; </p></item>
<item><p>Schema representation: the connections between XML
representations and schema components, including the
relationships between namespaces and schema components; </p></item>
<item><p>XML Schema web-interoperability guidelines: instance->schema and
schema->schema connections for the WWW. </p></item></olist>
<p>Layer 1 specifies the manner in which a schema composed of schema components
can be applied to in the <termref def="key-va">assessment</termref> of an instance element information item. Layer 2 specifies the use of <eltref ref="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.</p>
<div2 id="layer1">
<head>Layer 1: Summary of the Schema-validity Assessment Core</head>
<p>The fundamental purpose of the <termref def="key-va">assessment</termref> core is to define <termref def="key-va">assessment</termref> 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. </p>
<p><termref def="key-va">assessment</termref> is defined with reference to an <termref def="key-schema">XML Schema</termref> (note <emph>not</emph> a
<termref def="key-schemaDoc">schema document</termref>) which consists of (at a minimum) the set of schema
components (definitions and declarations) required for that
<termref def="key-va">assessment</termref>. This is not a circular definition, but rather a
<emph>post facto</emph> observation: no element information item can
be fully assessed unless all the components required by any aspect of
its (potentially recursive) <termref def="key-va">assessment</termref> are present in the schema.</p>
<p>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.</p>
<p>Processors have the option to assemble (and perhaps to optimize or
pre-compile) the entire schema prior to the start of an <termref def="key-va">assessment</termref> episode, or to
gather the schema lazily as individual components are required. In all
cases it is required that:</p>
<ulist>
<item><p>The processor succeed in locating the <termref def="key-component">schema components</termref>
transitively required to complete an <termref def="key-va">assessment</termref> (note that components derived
from <termref def="key-schemaDoc">schema documents</termref> can be integrated
with components obtained through other means);</p></item>
<item><p>no definition or declaration changes once it has been established;</p></item>
<item><p>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 <termref def="key-va">assessment</termref> to differ from that which would have
been obtained from the same schema components acquired in bulk.</p></item></ulist>
<note><p> the <termref def="key-va">assessment</termref> core is defined in terms of schema components at the
abstract level, and no mention is made of the schema definition
syntax (i.e. <eltref ref="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.
</p></note>
<p>The obligation of a schema-aware processor as far as the <termref def="key-va">assessment</termref>
core is concerned is to implement one or more of the options for <termref def="key-va">assessment</termref> given below in <specref ref="validation_outcome"/>. Neither the
choice of element information item for that <termref def="key-va">assessment</termref>, nor which of the
means of initiating <termref def="key-va">assessment</termref> are used, is within the scope of this specification.</p>
<p>Although <termref def="key-va">assessment</termref> is defined recursively, it is also intended to be
implementable in streaming
processors. Such processors may choose to incrementally assemble the schema during
processing in response, for example, to encountering new namespaces.
The implication of the
invariants expressed above is that such incremental assembly must
result in an <termref def="key-va">assessment</termref>
outcome that is the
<emph>same</emph> as would
be given if <termref def="key-va">assessment</termref> was undertaken again
with the final, fully assembled schema. </p>
</div2>
<div2 id="layer2">
<head>Layer 2: Schema Documents, Namespaces and Composition</head>
<p>The sub-sections of <specref ref="components"/> define an
XML representation for type definitions and element declarations and so on,
specifying their target namespace and collecting them into schema documents.
The two following sections relate to assembling a complete schema for <termref def="key-va">assessment</termref> from multiple sources. They should <emph>not</emph> be understood as a form of text substitution, but rather as providing mechanisms for distributed definition of schema components, with appropriate schema-specific semantics.</p>
<note><p> The core <termref def="key-va">assessment</termref> 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 <specref ref="concepts-conformance"/>, the precise mechanisms for resolving such references are expected to evolve over time.
In support of such evolution, this specification observes the design principle that references from
one schema document to a schema use mechanisms that directly parallel those used to
reference a schema from an instance document.</p></note>
<note><p>In the sections below, "schemaLocation" really belongs at layer 3.
For convenience, it is documented with the layer 2 mechanisms of import and
include, with which it is closely associated.</p></note>
<div3 id="compound-schema">
<head>Assembling a schema for a single target namespace from multiple schema definition documents</head>
<p>Schema components for a single target namespace can be assembled from
several <termref def="key-schemaDoc">schema documents</termref>, that is several <eltref ref="schema"/> element
information items: </p>
<reprdef>
<reprelt eltname="include"/>
</reprdef>
<p>A <eltref ref="schema"/> information item may contain any number of <eltref ref="include"/> elements. Their <code>schemaLocation</code> attributes, consisting of a URI reference, identify other <termref def="key-schemaDoc">schema documents</termref>, that is <eltref ref="schema"/> information items.
to <eltref ref="schema"/> contains not only the components corresponding to its definition and declaration &i-children;, but also
all the components of all the <termref def="key-schema">XML Schemas</termref> corresponding to any <eltref ref="include"/>d schema documents.
Such included schema documents must either (a) have the same
<code>targetNamespace</code> as the <eltref ref="include"/>ing schema document, or
(b) no <code>targetNamespace</code> at all, in which case the <eltref ref="include"/>d schema document is converted to the <eltref ref="include"/>ing schema document's <code>targetNamespace</code>.</p>
<constraintnote type="src" id="src-include">
<head>Inclusion Constraints and Semantics</head>
<p>In addition to the conditions imposed on <eltref ref="include"/> element
information items by the schema for schemas,
<olist role="and">
<item id="c-ins">
<p>If the &v-value; of the <code>schemaLocation</code> &i-attribute;
successfully resolves
<olist role="or">
<item id="c-vxd">
<p>It resolves to (a fragment of) a resource which is an XML
document (of type
<code>application/xml</code> or <code>text/xml</code> with an XML declaration
for preference, but this is not required), which in turn corresponds to a <eltref ref="schema"/>
element information item in a well-formed information set, which in turn
corresponds to a valid schema.</p>
</item>
<item>
<p>It resolves to a <eltref ref="schema"/>
element information item in a well-formed information set, which in turn
corresponds to a valid schema.</p>
</item>
</olist>
In either case call the <eltref ref="include"/>d <eltref ref="schema"/> item <local>SII</local>, the valid
schema <local>I</local> and the <eltref ref="include"/>ing item's parent <eltref ref="schema"/> item <local>SII’</local>.</p>
</item>
<item>
<olist role="Or">
<item id="c-normi">
<p><local>SII</local> has a <code>targetNamespace</code> &i-attribute;, and its &v-value; is identical to the &v-value; of the <code>targetNamespace</code> &i-attribute; of <local>SII’</local> (which must have such an &i-attribute;).</p>
</item>
<item id="c-normi2"><p>Neither <local>SII</local> nor <local>SII’</local> have a <code>targetNamespace</code> &i-attribute;.</p></item>
<item id="c-chami"><p><local>SII</local> has no <code>targetNamespace</code>
<p role="if"><clauseref ref="c-normi"/> or <clauseref ref="c-normi2"/> above is satisfied</p>
<p role="then">the schema corresponding to <local>SII’</local> must include not only definitions or
declarations corresponding to the appropriate members of its own &i-children;, but also components identical to all the <termref def="key-component">schema components</termref> of <local>I</local>.</p>
</item>
<item id="c-docham">
<p role="if"><clauseref ref="c-chami"/> above is satisfied</p>
<p role="then">the schema corresponding to the
<eltref ref="include"/>d
item's parent <eltref ref="schema"/> must include not only definitions or
declarations corresponding to the appropriate members of its own &i-children;,
but also components identical to all the <termref def="key-component">schema
components</termref> of <local>I</local>, except that anywhere the <termref def="key-null">absent</termref> target
namespace name would have appeared, the &v-value; of the
<code>targetNamespace</code> &i-attribute; of <local>SII’</local> is used. In
particular, it replaces <termref def="key-null">absent</termref> in the following places:
<olist>
<item><p>The <xpropref role="anon">target namespace</xpropref> of named schema
components, both at the top level and (in the case of nested type
definitions and nested attribute and
element declarations whose <code>code</code> was <pt>qualified</pt>) nested within definitions;</p></item>
<item><p>The <propref ref="namespace_constraint"/> of a wildcard, whether negated or not;</p></item>
</olist>
</p>
</item>
</olist>
</item>
</olist>
</p>
<p>It is <emph>not</emph> an error for the &v-value; of the
<code>schemaLocation</code> &i-attribute; to fail to resolve it all, in which case no
corresponding inclusion is performed. It
<emph>is</emph> an error for it to resolve but the rest of clause 1 above to
fail to be satisfied. Failure to resolve may well cause less than complete
<termref def="key-va">assessment</termref> outcomes, of course.</p>
<note>
<p>As discussed in <specref ref="conformance-missing"/>, <termref def="gloss-QName">QName</termref>s in XML representations may fail to
and unusable because of missing subcomponents. During schema construction,
implementations are likely to retain <termref def="gloss-QName">QName</termref> values for such references, in case subsequent processing provides a referent. <termref def="key-null">Absent</termref> target <termref def="q-uri">namespace name</termref>s of such as-yet unresolved reference <termref def="gloss-QName">QName</termref>s in <eltref ref="include"/>d components should also be converted if <clauseref ref="c-docham"/> is satisfied.</p>
</note>
</constraintnote>
<note><p>The above is carefully worded so that multiple <eltref ref="include"/>ing of the same schema document will not constitute a violation of
<clauseref ref="c-nmd"/> of <specref ref="sch-props-correct"/>, but applications are
allowed, indeed encouraged, to avoid <eltref ref="include"/>ing the same schema document more than once to forestall the necessity of establishing identity
<p>In order to provide some support for evolution and versioning, it is
possible to incorporate components corresponding to a schema document
<emph>with modifications</emph>. The modifications have a pervasive impact,
that is, only the redefined components are used, even when referenced from
other incorporated components, whether redefined themselves or not.</p>
<reprdef>
<reprelt eltname="redefine"/>
</reprdef>
<p>A <eltref ref="schema"/> information item may contain any number of <eltref ref="redefine"/> elements. Their <code>schemaLocation</code> attributes, consisting of a URI reference, identify other <termref def="key-schemaDoc">schema documents</termref>, that is <eltref ref="schema"/> information items.
to <eltref ref="schema"/> contains not only the components corresponding to its definition and declaration &i-children;, but also
all the components of all the <termref def="key-schema">XML Schemas</termref> corresponding to any <eltref ref="redefine"/>d schema documents.
Such schema documents must either (a) have the same
<code>targetNamespace</code> as the <eltref ref="redefine"/>ing schema document, or
(b) no <code>targetNamespace</code> at all, in which case the <eltref ref="redefine"/>d schema document is converted to the <eltref ref="redefine"/>ing schema document's <code>targetNamespace</code>.</p>
<p>The definitions within the <eltref ref="redefine"/> element itself are
restricted to be redefinitions of components from the <eltref ref="redefine"/>d
schema document, <emph>in terms of themselves</emph>. That is,
<ulist>
<item>
<p>Type
definitions must use themselves as their base type definition;</p>
</item>
<item>
<p>
Attribute
group definitions and model group definitions must be supersets or subsets of their original
definitions, either by including exactly one
reference to themselves or by containing only (possibly restricted) components
which appear in a corresponding way in their <eltref ref="redefine"/>d selves.</p>
</item>
</ulist>Not all the components of the <eltref ref="redefine"/>d
schema document need be redefined.</p>
<p>This mechanism is intended to provide a declarative and modular approach to
schema modification, with functionality no different except in scope from what
would be achieved by wholesale text copying and redefinition by editing. In
particular redefining a type is not guaranteed to be side-effect free: it may
have unexpected impacts on other type definitions which are based
on the redefined one, even to the extent that some such definitions become
ill-formed.</p>
<note>
<p>The pervasive impact of redefinition reinforces the need for
implementations to adopt some form of lazy or 'just-in-time' approach to
component construction, which is also called for in order to avoid
inappropriate dependencies on the order in which definitions and references appear in (collections of) schema documents.</p>
<p>The schema corresponding to <code>v2.xsd</code> has everything specified
by <code>v1.xsd</code>, with the <code>personName</code> type redefined, as
well as everything it specifies itself. According to
this schema, elements constrained
by the <code>personName</code> type may end with a <code>generation</code>
element. This includes not only the <code>author</code> element, but also the
<code>addressee</code> element.</p>
</note>
<constraintnote type="src" id="src-redefine">
<head>Redefinition Constraints and Semantics</head>
<p>In addition to the conditions imposed on <eltref ref="redefine"/> element
information items by the schema for schemas
<olist role="and">
<item><p>If there are any element information items among the &i-children;
other than <eltref ref="annotation"/> then the &v-value; of the
<code>schemaLocation</code> &i-attribute; must
successfully resolve.</p></item>
<item>
<p>If the &v-value; of the <code>schemaLocation</code> &i-attribute;
successfully resolves
<olist role="or">
<item>
<p>it resolves to (a fragment of) a resource which is an XML document
(see <clauseref ref="c-vxd"/>), which in turn corresponds to a <eltref ref="schema"/>
element information item in a well-formed information set, which in turn
corresponds to a valid schema.</p>
</item>
<item>
<p>It resolves to a <eltref ref="schema"/>
element information item in a well-formed information set, which in turn
corresponds to a valid schema.</p>
</item>
</olist>
In either case call the <eltref ref="redefine"/>d <eltref ref="schema"/> item <local>SII</local>, the valid
schema <local>I</local> and the <eltref ref="redefine"/>ing item's parent <eltref ref="schema"/> item <local>SII’</local>.</p>
</item>
<item>
<olist role="Or">
<item id="c-normir">
<p><local>SII</local> has a <code>targetNamespace</code> &i-attribute;, and its &v-value; is identical to the &v-value; of the <code>targetNamespace</code> &i-attribute; of <local>SII’</local> (which must have such an &i-attribute;).</p>
</item>
<item id="c-normi2r"><p>Neither <local>SII</local> nor <local>SII’</local> have a <code>targetNamespace</code> &i-attribute;.</p></item>
<item id="c-chamir"><p><local>SII</local> has no <code>targetNamespace</code>
<p role="if"><clauseref ref="c-normir"/> or <clauseref ref="c-normi2r"/> above is satisfied</p>
<p role="then">the schema corresponding to <local>SII’</local> must include not only definitions or
declarations corresponding to the appropriate members of its own
&i-children;, but also components identical to all the <termref def="key-component">schema components</termref> of <local>I</local>, with the
exception of those explicitly redefined (see <specref ref="src-expredef"/> below).</p>
</item>
<item>
<p role="if"><clauseref ref="c-chamir"/> above is satisfied</p>
<p role="then">the schema corresponding to <local>SII’</local> must include not only definitions or
declarations corresponding to the appropriate members of its own &i-children;,
but also components identical to all the <termref def="key-component">schema
components</termref> of <local>I</local>, with the
exception of those explicitly redefined (see <specref ref="src-expredef"/>
below), except that anywhere the <termref def="key-null">absent</termref> target
namespace name would have appeared, the &v-value; of the
<code>targetNamespace</code> &i-attribute; of <local>SII’</local> is
used (see <clauseref ref="c-docham"/> in <specref ref="src-include"/> for details).</p>
</item>
</olist>
</item>
<item>
<p>Within the &i-children;, each <eltref ref="simpleType"/> must
have a <eltref ref="restriction"/> among its &i-children; and each <eltref ref="complexType"/> must have a <code>restriction</code> or <code>extension</code> among its grand-&i-children; the &v-value; of whose <code>base</code> &i-attribute; must be the same as the &v-value; of its own <code>name</code> attribute plus target namespace;</p>
</item>
<item>
<p>Within the &i-children;, for each <eltref ref="group"/> <olist role="case">
<item>
<p role="if">it has a <eltref ref="group"/> among its contents at some level the &v-value; of whose
<code>ref</code> &i-attribute; is the same as the &v-value; of its own
<code>name</code> attribute plus target namespace</p>
<p role="then">
<olist role="and">
<item>
<p>It must have exactly one such group.</p>
</item>
<item>
<p>The &v-value; of both that group's <code>minOccurs</code> and
<code>maxOccurs</code> &i-attribute; must be <code>1</code> (or <termref def="key-null">absent</termref>).</p>
</item>
</olist>
</p>
</item>
<item>
<p role="if">it has no such self-reference</p>
<p role="then">
<olist role="and">
<item>
<p>The &v-value; of its own <code>name</code> attribute plus target
namespace must successfully <termref def="key-resolve">resolve</termref> to a
model group definition in <local>I</local>.</p>
</item>
<item>
<p>The <propref ref="model_group"/> of the model group definition which
corresponds to it per <specref ref="declare-namedModelGroup"/> must be a <termref def="cd-model-restriction">valid
restriction</termref> of the <propref ref="model_group"/> of that model group
definition in <local>I</local>, as defined in <specref ref="cos-particle-restrict"/>.</p>
</item>
</olist></p>
</item>
</olist></p>
</item>
<item>
<p>Within the &i-children;, for each <eltref ref="attributeGroup"/>
<olist role="case">
<item>
<p role="if">it has an <eltref ref="attributeGroup"/> among its contents the &v-value; of whose
<code>ref</code> &i-attribute; is the same as the &v-value; of its own
<code>name</code> attribute plus target namespace</p>
<p role="then">it must have exactly one such group.</p>
</item>
<item id="c-agrere">
<p role="if">it has no such self-reference</p>
<p role="then">
<olist role="and">
<item>
<p>The &v-value; of its own <code>name</code> attribute plus target
namespace must successfully <termref def="key-resolve">resolve</termref> to an
attribute group definition in <local>I</local>.</p>
</item>
<item>
<p>The <propref ref="ag-attribute_declarations"/> and <propref ref="ag-attribute_wildcard"/> of the attribute group definition which
corresponds to it per <specref ref="declare-attributeGroup"/> must be <termref def="cd-model-restriction">valid
restrictions</termref> of the <propref ref="ag-attribute_declarations"/> and
<propref ref="ag-attribute_wildcard"/> of that attribute group
definition in <local>I</local>, as defined in <clauseref ref="c-rad"/>, <clauseref ref="c-rad2"/> and <clauseref ref="c-raw"/> of <specref ref="derivation-ok-restriction"/> (where references to the base type definition are understood as references to the attribute group
definition in <local>I</local>).</p>
</item>
</olist></p>
</item>
</olist>
<note>
<p>An attribute group restrictively redefined per <clauseref ref="c-agrere"/> corresponds to an attribute group whose <propref ref="ag-attribute_declarations"/> consist all and only of those attribute uses corresponding to <eltref ref="attribute"/>s explicitly present among the &i-children; of the <eltref ref="redefine"/>ing <eltref ref="attributeGroup"/>. No inheritance from the <eltref ref="redefine"/>d attribute group occurs. Its <propref ref="ag-attribute_wildcard"/> is similarly based purely on an explicit <eltref ref="anyAttribute"/>, if present.</p>
</note>
</p>
</item>
</olist>
</p>
</constraintnote>
<constraintnote type="src" id="src-expredef">
<head>Individual Component Redefinition</head>
<p>Corresponding to each non-<eltref ref="annotation"/> member of the
&i-children; of a <eltref ref="redefine"/> there are one or two schema components in
the <eltref ref="redefine"/>ing schema:</p>
<olist>
<item>
<p>The <eltref ref="simpleType"/> and <eltref ref="complexType"/>
&i-children; information items each
correspond to two components:</p>
<olist>
<item>
<p>One component which corresponds to the top-level definition item with
the same <code>name</code> in
the <eltref ref="redefine"/>d schema document, as defined in <specref ref="components"/>, except that its <xpropref role="anon">name</xpropref> is <termref def="key-null">absent</termref>;</p>
</item>
<item>
<p>One component which corresponds to the information item itself, as defined
in <specref ref="components"/>, except that its <xpropref role="anon">base type definition</xpropref> is
the component defined in 1.1 above.</p>
</item>
</olist>
<p>This pairing ensures the coherence constraints on type definitions
are respected, while at the same time achieving the desired effect, namely that
references to names of redefined components in both the <eltref ref="redefine"/>ing and
<eltref ref="redefine"/>d schema documents resolve to the redefined component
as specified in 1.2 above.</p>
</item>
<item>
<p>The <eltref ref="group"/> and <eltref ref="attributeGroup"/>
&i-children; each correspond to a single component, as defined in <specref ref="components"/>, except that if and when a self-reference based on a <code>ref</code> &i-attribute; whose &v-value; is the same as the item's <code>name</code> plus target namespace is resolved, a component which corresponds to the top-level definition item of that name and the appropriate kind in
<local>I</local> is used.</p>
</item>
</olist>
<p>In all cases there must be a top-level definition item of the appropriate name and kind in
the <eltref ref="redefine"/>d schema document.</p>
</constraintnote>
<note><p>The above is carefully worded so that multiple equivalent <eltref ref="redefine"/>ing of the same schema document will not constitute a violation of
<clauseref ref="c-nmd"/> of <specref ref="sch-props-correct"/>, but applications are
allowed, indeed encouraged, to avoid <eltref ref="redefine"/>ing the same
schema document in the same way more than once to forestall the necessity of
establishing identity component by component (although this will have to be
done for the individual redefinitions themselves).</p></note>
</div3>
<div3 id="composition-schemaImport">
<head>References to schema components across namespaces</head>
<p>As described in <specref ref="concepts-data-model"/>, every top-level schema component is associated with
a target namespace (or, explicitly, with none). This section sets out
the exact mechanism and syntax in the XML form of
schema definition by which a reference to a foreign component is made, that is, a component with a different target namespace from that of the referring component.</p>
<p>Two things are required: not only a means
of addressing such foreign components but also a signal to schema-aware processors that a
schema document contains such references:</p>
<reprdef>
<reprelt eltname="import"/>
</reprdef>
<p>The <eltref ref="import"/> element information item identifies namespaces
used in external references, i.e. those whose
<termref def="gloss-QName">QName</termref> identifies them as coming from a
different namespace (or none) than the enclosing schema document's
<code>targetNamespace</code>. The &v-value; of its <code>namespace</code>
&i-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
<termref def="key-schemaDoc">schema document</termref>; the processor
is free to access or construct components using means of its own
choosing.</p>
<p>The
&v-value; of the <code>schemaLocation</code>, if present, gives a
hint as to where a serialization of a <termref def="key-schemaDoc">schema document</termref> with declarations and definitions for that
namespace (or none) may be found. When no
<code>schemaLocation</code> &i-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 <specref ref="composition-instances"/>. When a <code>schemaLocation</code> is present, it
must contain a single URI reference which the schema author
warrants will resolve to a serialization of a <termref def="key-schemaDoc">schema document</termref> containing the component(s) in the
<eltref ref="import"/>ed namespace referred to elsewhere in the containing
schema document.</p>
<note>
<p>Since both the <code>namespace</code> and <code>schemaLocation</code>
&i-attribute; are optional, a bare <code><import/></code> information item
is allowed. This simply allows unqualified reference to foreign
components with no target namespace without giving any hints as to where to find them.</p>
</note>
<note role="example"><p>The same namespace may be used both for real work, and in the course of
defining schema components in terms of foreign components:</p>
<p role="if">the <code>namespace</code> &i-attribute; is not present</p>
<p role="then">the enclosing <eltref ref="schema"/> must have a <code>targetNamespace</code> &i-attribute;</p>
</item>
</olist>
</item>
<item id="c-ims">
<p>If the application schema reference strategy using the &v-value;s of
the <code>schemaLocation</code> and <code>namespace</code> &i-attributes;,
provides a referent, as defined by <specref ref="schema_reference"/>,
<olist role="or">
<item>
<p>The referent is (a fragment of) a resource which is an XML document
(see <clauseref ref="c-vxd"/>), which in turn corresponds to a <eltref ref="schema"/>
element information item in a well-formed information set, which in turn
corresponds to a valid schema.</p>
</item>
<item>
<p>The referent is a <eltref ref="schema"/>
element information item in a well-formed information set, which in turn
corresponds to a valid schema.</p>
</item>
</olist>
In either case call the <eltref ref="schema"/> item <local>SII</local> and the valid schema <local>I</local>.</p>
</item>
<item>
<olist role="Case">
<item>
<p role="if">there is a <code>namespace</code> &i-attribute;</p>
<p role="then">its &v-value; must be identical to the &v-value; of the <code>targetNamespace</code> &i-attribute; of <local>SII</local>.</p>
</item>
<item>
<p role="if">there is no <code>namespace</code> &i-attribute;</p>
<p role="then"><local>SII</local>
must have no <code>targetNamespace</code> &i-attribute;</p>
</item>
</olist>
</item>
</olist>
</p>
<p>It is <emph>not</emph> an error for the application schema reference
strategy to fail. It
<emph>is</emph> an error for it to resolve but the rest of <clauseref ref="c-ims"/> above to
fail to be satisfied. Failure to find a referent may well cause less than complete
<termref def="key-va">assessment</termref> outcomes, of course.</p>
<p>The <termref def="key-component">schema components</termref> (that is
<propref ref="type_definitions"/>, <propref ref="attribute_declarations"/>, <propref ref="element_declarations"/>, <propref ref="attribute_group_definitions"/>, <propref ref="model_group_definitions"/>, <propref ref="notation_declarations"/>) of a schema corresponding to a
<eltref ref="schema"/> element information item with one or more <eltref ref="import"/> element information items must include not only definitions or declarations corresponding to the appropriate members of its &i-children;, but also, for each of those <eltref ref="import"/> element information items for which <clauseref ref="c-ims"/> above is satisfied, a set of <termref def="key-component">schema components</termref> identical to all the <termref def="key-component">schema components</termref> of <local>I</local>.</p>
</constraintnote>
<note><p>The above is carefully worded so that multiple <eltref ref="import"/>ing of the same schema document will not constitute a violation of
<clauseref ref="c-nmd"/> of <specref ref="sch-props-correct"/>, but applications are
allowed, indeed encouraged, to avoid <eltref ref="import"/>ing the same schema document more than once to forestall the necessity of establishing identity
component by component. Given that the <code>schemaLocation</code>
&i-attribute; is only a hint, it is open to applications to ignore all but the
first <eltref ref="import"/> for a given namespace, regardless of the &v-value; of
<code>schemaLocation</code>, but such a strategy risks missing useful
information when new <code>schemaLocation</code>s are offered.</p></note>
</div3></div2>
<div2 id="composition-instances">
<head>Layer 3: Schema Document Access and Web-interoperability</head>
<p>Layers 1 and 2 provide a framework for <termref def="key-va">assessment</termref> and XML definition of schemas in a broad variety of environments. Over time, a range
of standards and conventions may well evolve to support interoperability of XML
Schema implementations on the World Wide Web. Layer 3 defines the minimum level
of function required of all conformant processors operating on the Web:
it is intended that, over time, future standards (e.g. XML Packages) for interoperability on the
Web and in other environments can be introduced without the need to republish
this specification.</p>
<div3 id="schema-repr">
<head>Standards for representation of schemas and retrieval of schema documents on the Web</head>
<p>For interoperability, serialized <termref def="key-schemaDoc">schema documents</termref>, like all other Web resources, may be identified by
URI and retrieved using the standard mechanisms of the Web (e.g. http, https,
etc.) Such documents on the Web must be part of XML documents (see <clauseref ref="c-vxd"/>), and are represented in the
standard XML schema definition form described by layer 2 (that is as <eltref ref="schema"/>
element information items). </p>
<note><p> there will often be times when a schema document will be a
complete XML 1.0 document whose document element is <eltref ref="schema"/>. There will be
other occasions in which <eltref ref="schema"/> items will be contained in other
documents, perhaps referenced using fragment and/or XPointer notation.
</p></note>
<note>
<p>The variations among server software and web site administration policies
make it difficult to recommend any particular approach to retrieval requests
intended to retrieve serialized <termref def="key-schemaDoc">schema documents</termref>. An <code>Accept</code> header of <code>application/xml,
text/xml; q=0.9, */*</code> is perhaps a reasonable starting point.</p>
</note>
</div3>
<div3 id="schema-loc">
<head>How schema definitions are located on the Web</head>
<p>As described in <specref ref="layer1"/>, processors are responsible for providing the
schema components (definitions and declarations) needed for <termref def="key-va">assessment</termref>. This
section introduces a set of normative conventions to facilitate interoperability
for instance and schema documents retrieved and processed from the Web.</p>
<note><p> As discussed above in <specref ref="layer2"/>, other non-Web mechanisms for delivering schemas for <termref def="key-va">assessment</termref> may exist, but are outside the scope of this specification.</p></note>
<p>Processors on the Web are free to undertake <termref def="key-va">assessment</termref> against arbitrary
schemas in any of the ways set out in <specref ref="validation_outcome"/>. However, it
is useful to have a common convention for determining the schema to use. Accordingly, general-purpose schema-aware processors (i.e. those not
specialized to one or a fixed set of pre-determined schemas)
undertaking <termref def="key-va">assessment</termref> of a document on the web
must behave as follows:
<ulist>
<item>
<p>unless directed otherwise by the user, <termref def="key-va">assessment</termref> is undertaken on the document
element information item of the specified document;</p>
</item>
<item>
<p>unless directed otherwise by the user, the
processor is required to construct a schema corresponding to a schema document
whose <code>targetNamespace</code> is
identical to the
namespace name, if any, of the element information item on which <termref def="key-va">assessment</termref> is undertaken.</p>
</item>
</ulist>
</p>
<p>The composition of the complete
schema for use in <termref def="key-va">assessment</termref> is discussed in <specref ref="layer2"/> above.
The means used to locate appropriate schema document(s) are processor and
application dependent, subject to the following requirements: </p>
<olist>
<item><p>Schemas are represented on the Web in the form specified above in <specref ref="schema-repr"/>;</p></item>
<item><p>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 name. Accordingly whether a processor's default
behavior is or is not to attempt such dereferencing, it must always provide
for user-directed overriding of that default.
</p>
<note><p> Experience suggests that it is not in all cases safe or desirable from
a performance point of view to dereference namespace names 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 specification allows but does not require particular communities to
establish and implement such conventions. Users are always free to supply namespace names as schema location information when dereferencing <emph>is</emph> desired: see below.</p></note></item>
<item>
<p>
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 conforms to that schema, the
<code>schemaLocation</code> and <code>noNamespaceSchemaLocation</code> &i-attributes; (in the XML Schema instance namespace,
that is, <code>http://www.w3.org/2001/XMLSchema-instance</code>) (hereafter
<code>xsi:schemaLocation</code> and
<code>xsi:noNamespaceSchemaLocation</code>) are provided. The first records
the author's warrant with pairs of URI references (one for the namespace name, and
one for a hint as to the location of a schema document defining names for that
namespace name). The second similarly provides a URI reference as a hint as to
the location of a schema document with no <code>targetNamespace</code> &i-attribute;.</p>
<p>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
&v-value; of such
<code>xsi:schemaLocation</code> and <code>xsi:noNamespaceSchemaLocation</code> &i-attributes;, see details below.</p>
</item>
<item> <p><code>xsi:schemaLocation</code> and
<code>xsi:noNamespaceSchemaLocation</code> &i-attributes; can occur on any
element. However, it is an error if such an attribute occurs
<emph>after</emph> the first appearance of an element or attribute information
item within an
element information item initially <termref def="key-vn">validated</termref> whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">namespace name</xpropref> it addresses. According to the rules of
<specref ref="layer1"/>, the corresponding schema may be lazily assembled, but is otherwise
stable throughout <termref def="key-va">assessment</termref>. Although schema location attributes can occur
on any element, and can be processed incrementally as discovered, their effect
is essentially global to the <termref def="key-va">assessment</termref>. Definitions and declarations remain
in effect beyond the scope of the element on which the binding is declared.
</p></item>
</olist>
<note role="example"><p>Multiple schema bindings can be declared using a single
</eg><p>The namespace names used in <code>schemaLocation</code> 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. </p></note>
<constraintnote id="schema_reference" type="src">
<head>Schema Document Location Strategy</head>
<p>Given a namespace name (or none) and (optionally) a URI reference from
<code>xsi:schemaLocation</code> or <code>xsi:noNamespaceSchemaLocation</code>,
schema-aware processors may implement any combination of the following
strategies, in any order:
<olist><item><p>
Do nothing, for instance because a schema containing components for the
given namespace name 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);
</p></item>
<item><p>
Based on the location URI,
identify an existing schema document,
either as a resource which is an XML document or a <eltref ref="schema"/> element
information item, in some local schema repository;
</p></item>
<item><p>
Based on the namespace name, identify an existing schema document,
either as a resource which is an XML document or a <eltref ref="schema"/> element
information item, in some local schema repository;
</p></item>
<item><p>
Attempt to resolve the location URI,
to locate a
resource on the web which is or contains or references a <eltref ref="schema"/> element;
</p></item>
<item><p>
Attempt to resolve the namespace name to locate such a resource.
</p></item>
</olist>
Whenever possible configuration and/or invocation options for selecting and/or ordering
the implemented strategies should be provided.
</p>
</constraintnote>
<p>Improved or alternative conventions for Web interoperability can
be standardized in the future without reopening this specification. For
example, the W3C is currently considering initiatives to standardize the
packaging of resources relating to particular documents and/or namespaces: this
would be an addition to the mechanisms described here for layer 3. This
architecture also facilitates innovation at layer 2: for example, it would be
possible in the future to define an additional standard for the representation of
schema components which allowed e.g. type definitions to be specified piece by
piece, rather than all at once.</p>
</div3>
</div2>
</div1>
<div1 id="conformance">
<head>Schemas and Schema-validity Assessment</head>
<p>The architecture of schema-aware processing allows for a rich characterization of XML documents: schema validity is not a binary predicate.</p>
<p>This specification distinguishes between errors in schema construction and structure, on the
one hand, and schema validation outcomes, on the other.</p>
<div2 id="conformance-schemaValidity">
<head>Errors in Schema Construction and Structure</head>
<p>Before <termref def="key-va">assessment</termref> can be attempted, a schema is required.
Special-purpose applications are free to determine a schema for use in <termref def="key-va">assessment</termref> by whatever
means are appropriate, but general purpose processors should implement the
strategy set out in <specref ref="schema_reference"/>, starting with the
namespaces declared in the document whose <termref def="key-va">assessment</termref> is being undertaken, and the &v-value;s of the
<code>xsi:schemaLocation</code> and <code>xsi:noNamespaceSchemaLocation</code>
&i-attributes; thereof, if any, along with an other information about
schema identity or schema document location provided by users in
application-specific ways, if any.</p>
<p>It is an
error if a
schema and all the components which are the value of any of its properties,
recursively, fail to satisfy all the relevant Constraints on Schemas set out in
the last section of each of the subsections of <specref ref="components"/>.</p>
<p>If a schema is derived from one or more schema documents (that is, one or
more <eltref ref="schema"/> element information items) based on the
correspondence rules set out in <specref ref="components"/> and <specref ref="composition"/>, two additional
conditions hold:
<ulist>
<item>
<p>It is an error if any such schema document would not be fully valid with respect
to a schema corresponding to the <specref ref="normative-schemaSchema"/>, that
is, following schema-validation with such a schema, the <eltref ref="schema"/> element
information items would have a <propref role="psvi" ref="e-validation_attempted"/>
property with value <pt>full</pt> or <pt>partial</pt> and a
<propref role="psvi" ref="e-validity"/> property
with value <pt>valid</pt>.</p>
</item>
<item>
<p>It is an error if any such schema document is or contains any element
information items which violate any of the relevant Schema Representation
Constraints set out in <specref ref="outcome-src"/>.</p>
</item>
</ulist>
</p>
<p>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 <termref def="key-va">assessment</termref> with respect to schema-like entities which do <emph>not</emph>
satisfy all the above conditions is incoherent. Accordingly, conformant
processors must not attempt to undertake <termref def="key-va">assessment</termref> using such non-schemas.</p>
</div2>
<div2 id="validation_outcome">
<head>Assessing Schema-Validity</head>
<p>With a schema which satisfies the conditions expressed in <specref ref="conformance-schemaValidity"/> above, the schema-validity of an element information item can be assessed. Three primary approaches to this are possible:
<olist>
<item>
<p>The user or application identifies a complex type definition from among the
<propref ref="type_definitions"/> of the schema, and appeals to <specref ref="cvc-assess-elt"/> (<clauseref ref="c-td"/>);</p>
</item>
<item id="c-res">
<p>The user or application identifies a element declaration from among the
<propref ref="element_declarations"/> of the schema, checks that its <propref ref="e-name"/> and <propref ref="e-target_namespace"/> match the <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">local name</xpropref> and <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">namespace name</xpropref> of the item, and appeals to <specref ref="cvc-assess-elt"/> (<clauseref ref="c-ed"/>);</p></item>
<item>
<p>The processor starts from <specref ref="cvc-assess-elt"/> with no
stipulated declaration or definition, and either <termref def="key-sva">strict</termref> or <termref def="key-lva">lax</termref> assessment ensues, depending on whether or not the element information and the schema determine either an element declaration (by name) or a type definition (via <code>xsi:type</code>) or not.</p>
</item>
</olist>
</p>
<p>The outcome of this effort, in any case, will be manifest in the
and <xpropref role="psviAnon">validity</xpropref> properties on
the element information item and its &i-attributes; and &i-children;,
recursively, as defined by <specref ref="sic-e-outcome"/> and <specref ref="sic-a-outcome"/>. It is up to applications to decide what constitutes a successful outcome.</p>
<p>Note that every element and attribute information item
participating in the <termref def="key-va">assessment</termref> will also have a <xpropref role="psviAnon">validation context</xpropref> property
which refers back to the element information item at which <termref def="key-va">assessment</termref> began. <termdef id="key-vr" term="validation root">This item, that is the element information item at which <termref def="key-va">assessment</termref> began, is called the <term>validation root</term></termdef>.</p>
<note>
<p>This specification does not reconstruct the XML 1.0 notion of
<emph>root</emph> in either schemas or instances. Equivalent
functionality is provided for at <termref def="key-va">assessment</termref>
invocation, via <clauseref ref="c-res"/> above.</p>
</note>
<note>
<p>This specification has nothing normative to say about multiple <termref def="key-va">assessment</termref>
episodes. It should however be clear from the above that if a processor
restarts <termref def="key-va">assessment</termref> with respect to a &PSVI;
some &PSVI; contributions from the previous <termref def="key-va">assessment</termref>
may be overwritten. Restarting nonetheless may be useful, particularly at a node whose
<xpropref role="psviAnon">validation attempted</xpropref> property is <pt>none</pt>, in which
case there are three obvious cases in which additional useful information may result:
<ulist>
<item>
<p><termref def="key-va">assessment</termref> was not attempted because
of a <termref def="key-vn">validation</termref> failure, but declarations
and/or definitions are available for at least some of the &i-children; or &i-attributes;;</p>
</item>
<item>
<p><termref def="key-va">assessment</termref> was not attempted because a
named definition or declaration was missing, but after further effort the
processor has retrieved it.</p>
</item>
<item>
<p><termref def="key-va">assessment</termref> was not attempted because
it was <pt>skip</pt>ped, but the processor has at least some declarations
and/or definitions available for at least some of the &i-children; or &i-attributes;.</p>
</item>
</ulist>
</p>
</note>
</div2>
<div2 id="conformance-missing">
<head>Missing Sub-components</head>
<p>At the beginning of <specref ref="components"/>, 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 <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#QName">QNames</xtermref>, and the
<termref def="src-resolve">resolution</termref> of such <xtermref href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes#QName">QNames</xtermref> may fail, resulting in one or more values of or containing <termref def="key-null">absent</termref> where a component is mandated.</p>
<p>If at any time during <termref def="key-va">assessment</termref>, an
element or attribute information item is being <termref def="key-vn">validated</termref> with respect to a component of any kind any of whose
properties has or contains such an <termref def="key-null">absent</termref> value,
the <termref def="key-vn">validation</termref> is modified, as following:
<ulist>
<item>
<p>In the case of attribute information items, the effect is
as if <clauseref ref="c-a1"/> of <specref ref="cvc-attribute"/> had failed;</p>
</item>
<item>
<p>In the case of element information items, the effect is
as if <clauseref ref="c-ea"/> of <specref ref="cvc-elt"/> had failed;</p>
</item>
<item>
<p>In the case of element information items, processors may choose to
continue <termref def="key-va">assessment</termref>: see <termref def="key-lva">lax assessment</termref>.</p>
</item>
</ulist>
</p>
<p>Because of the value specification for <propref role="psvi" ref="e-validation_attempted"/> in <specref ref="sic-e-outcome"/>, if this situation ever arises, the
document as a whole cannot show a <propref role="psvi" ref="e-validation_attempted"/>
of <pt>full</pt>.</p>
</div2>
<div2 id="conformance-processorResponsibilities">
<head>Responsibilities of Schema-aware Processors</head>
<p>Schema-aware processors are responsible for processing XML documents,
schemas and schema documents, as appropriate given the level of conformance
(as defined in <specref ref="concepts-conformance"/>) they support,
consistently with the conditions set out above.</p>
</div2>
</div1>
</body>
<back>
<div1 id="normative-schemaSchema">
<head>Schema for Schemas (normative)</head>
<p>The XML Schema definition for &XSP1; 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. </p>
<p>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.</p>
<p>Since an &XSP1; is an XML document, it has optional XML and doctype
declarations that are provided here for completeness. The root
<code>schema</code> element defines a new schema. Since this is a schema for
&XSP1;, the <code>targetNamespace</code> references the XML Schema namespace itself.</p>
<p>And that is the end of the schema for &XSP1;.</p>
</note>
</div1>
<div1 id="normative-references">
<head>References (normative)</head>
<blist>
<bibl id="ref-xsp2" key="XML Schemas: Datatypes">
<emph>XML Schema Part 2: Datatypes</emph>, Paul V. Biron and Ashok
Malhotra, eds., W3C, 2 May 2001. See <loc href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes.html">http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes.html</loc> </bibl>
<emph>XML Schema Requirements </emph>, Ashok Malhotra and Murray Maloney, eds.,
W3C, 15 February 1999. See <loc href="http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215">http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215</loc> </bibl>
Pointer Language (XPointer)</emph>, Eve Maler and Steve DeRose, eds., W3C, 8 January 2001. See <loc href="http://www.w3.org/TR/2001/WD-xptr-20010108/">http://www.w3.org/TR/2001/WD-xptr-20010108/</loc> </bibl>
<bibl id="bib-xpath" key="XPath"><emph>XML Path Language</emph>, James Clark
and Steve DeRose, eds., W3C, 16 November 1999. See <loc href="http://www.w3.org/TR/1999/REC-xpath-19991116">http://www.w3.org/TR/1999/REC-xpath-19991116</loc></bibl>
</blist>
</div1>
<div1 id="outcomes">
<head>Outcome Tabulations (normative)</head>
<p>To facilitate consistent reporting of schema errors and <termref def="key-vn">validation</termref>
failures, this section tabulates and provides unique names for all the
constraints listed in this document. Wherever such constraints have numbered
parts, reports should use the name given below plus the part number, separated
by a period ('.'). Thus for example <code>cos-ct-extends.1.2</code> should be
used to report a violation of the <clauseref ref="c-cte"/> of
<specref ref="cos-ct-extends"/>.</p>
<div2 id="validation_failures">
<head>Validation Rules</head>
<p/>
</div2>
<div2 id="PSVI_contributions">
<head>Contributions to the &PSVI;</head>
</div2>
<div2 id="outcome-src">
<head>Schema Representation Constraints</head>
<p/>
</div2>
<div2 id="outcome-cos">
<head>Schema Component Constraints</head>
</div2>
</div1>
<div1 id="infoset">
<head>Required Information Set Items and Properties (normative)</head>
<p>This specification requires as a precondition for <termref def="key-va">assessment</termref> an information set as defined in <bibref ref="ref-xmlinfo"/> which supports at least the following information items and properties:</p>
<p>This specification does not require any destructive alterations to the input
information set: all the information set contributions specified herein are additive.</p>
<p>This appendix is intended to satisfy the requirements for <xspecref href="http://www.w3.org/TR/2001/WD-xml-infoset-20010316/#conformance">Conformance</xspecref> to the <bibref ref="ref-xmlinfo"/> specification.</p>
<p>They are both wildcards, and the intensional intersection of their <propref ref="namespace_constraint"/>s as defined
in <specref ref="cos-aw-intersect"/> is not the empty set.</p>
</item>
</ulist>
or
<ulist>
<item>
<p>One is a wildcard and the other an element declaration, and the
<propref ref="e-target_namespace"/> of the element declaration, or of any
member of its <termref def="key-eq">substitution group</termref>, is <termref def="key-vn">valid</termref> with respect to the <propref ref="namespace_constraint"/> of the wildcard.</p>
</item>
</ulist>
</p>
<p>A content model will violate the unique attribution constraint if it
contains two particles which <termref def="key-overlap">overlap</termref> and which either
<ulist>
<item>
<p>are both in the <propref ref="particles"/> of a <pt>choice</pt> or
<pt>all</pt> group</p>
</item>
</ulist>
or
<ulist>
<item>
<p>may <termref def="key-vn">validate</termref> adjacent information items and the first has
<propref ref="p-min_occurs"/> less than <propref ref="p-max_occurs"/>.</p>
</item>
</ulist>
</p>
<p>Two particles may <termref def="key-vn">validate</termref> 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.</p>
<p>A precise formulation of this constraint can also be offered in terms of
operations on finite-state automaton: transcribe the content model into an
automaton in the usual way using epsilon transitions for optionality and
unbounded maxOccurs, unfolding other numeric occurrence ranges and treating the heads of substitution groups as if
they were choices over all elements in the group, <emph>but</emph> using not
element QNames as transition labels, but rather pairs of element QNames and
positions in the model. Determinize this automaton, treating wildcard transitions as opaque. Now replace all
QName+position transition labels with the element QNames alone. If the result has any states
with two or more identical-QName-labeled transitions from it, or a
QName-labeled transition and a wildcard transition which subsumes it, or two
wildcard transitions whose intentional intersection is non-empty, the model does not
satisfy the Unique Attribution constraint. </p>
</div1>
<div1 id="nonnormative-references">
<head>References (non-normative)</head>
<blist>
<bibl id="ref-dcd" key="DCD"> <emph>Document
Content Description for XML (DCD)</emph>, Tim Bray et al., eds., W3C, 10 August 1998.
See <loc href="http://www.w3.org/TR/1998/NOTE-dcd-19980731">http://www.w3.org/TR/1998/NOTE-dcd-19980731</loc> </bibl>
<bibl id="ref-ddml" key="DDML"> <emph>Document
Definition Markup Language</emph>, Ronald Bourret, John Cowan, Ingo Macherius,
Simon St. Laurent, eds., W3C, 19 January 1999. See
<bibl id="bib-expo" key="XML Schema: Primer"><emph>XML Schema Part 0:
Primer</emph>, David C. Fallside, ed., W3C, 2 May 2001. See <loc href="http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.html">http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.html</loc></bibl>
<bibl id="ref-sox" key="SOX"> <emph>Schema for
Object-oriented XML</emph>, Andrew Davidson et al., eds., W3C, 1998. See
