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.
This version of this document incorporates some editorial changes
from earlier versions.
A list of current W3C Recommendations and other technical documents can be found at
http://www.w3.org/TR/.
1 Introduction
This document sets out the structural part (XML Schema: Structures) of the XML Schema definition language.
Chapter 2 presents a Conceptual Framework (§2) for XML Schemas, including
an introduction to the nature of XML Schemas and an introduction
to the XML Schema abstract data model, along with
other terminology used throughout this document.
Chapter 3, Schema Component Details (§3), specifies the precise
semantics of each component of the abstract model, the representation of each
component in XML, with reference to a DTD and XML Schema
for an XML Schema document type, along with a detailed mapping between the elements and
attribute vocabulary of this representation and the components and properties
of the abstract model.
Chapter 4 presents Schemas and Namespaces: Access and Composition (§4), including the
connection between documents and schemas, the import, inclusion and redefinition of declarations and definitions and
the foundations of schema-validity assessment.
Chapter 5 discusses Schemas and Schema-validity Assessment (§5), including the
overall approach to schema-validity assessment of documents, and responsibilities of schema-aware
processors.
The normative appendices include a Schema for Schemas (normative) (§A) for the XML representation of schemas and
References (normative) (§B).
The non-normative appendices include the DTD for Schemas (non-normative) (§G) and a Glossary (non-normative) (§F).
This document is primarily intended as a language definition reference.
As such, although it contains a few examples, it is not primarily designed
to serve as a motivating introduction to the design and its features, or as a
tutorial for new users.
Rather it presents a careful and fully explicit definition of that design, suitable
for guiding implementations. For those in search of a step-by-step
introduction to the design, the non-normative [XML Schema: Primer] is a much better
starting point than this document.
1.1 Purpose
The purpose of XML Schema: Structures is to define the nature of XML schemas
and their component parts,
provide an inventory of XML markup
constructs with which to represent schemas, and define the
application of schemas to XML documents.
The purpose of an XML Schema: Structures schema is to define and describe a class of
XML documents by using schema components to constrain and document the meaning,
usage and relationships of their constituent parts: datatypes, elements and
their content and attributes and their values. Schemas may also provide for the specification of additional
document information, such as normalization and defaulting of attribute
and element values. Schemas have
facilities for self-documentation. Thus, XML Schema: Structures can be used to define, describe and catalogue XML
vocabularies for classes of XML documents.
Any application that consumes well-formed XML can use the XML Schema: Structures
formalism to express syntactic, structural and value constraints applicable to
its document instances. The XML Schema: Structures formalism allows a useful level of
constraint checking to be described and implemented for a wide spectrum of XML
applications. However, the language defined by this specification does not attempt to provide
all the facilities that might be needed by any
application. Some applications may require constraint capabilities not
expressible in this language, and so may need to perform their own additional
validations.
1.3 Documentation Conventions and Terminology
The section introduces the highlighting and typography as used in
this document to present technical material.
Special terms are defined at their point of
introduction in the text. For example [Definition:] a term is
something used with a special meaning. The definition is
labeled as such and the term it defines is displayed in boldface. The end of the definition is not specially marked
in the displayed or printed text. Uses of defined terms are links to
their definitions, set off with middle dots, for instance ·term·.
Non-normative examples are set off in boxes and accompanied by a brief
explanation:
<schema targetNamespace="http://www.example.com/XMLSchema/1.0/mySchema">
And an explanation of the example.
The definition of each kind of schema component consists of a list of
its properties and their contents, followed by descriptions of the
semantics of the properties:
References to properties of schema components are links to
the relevant definition as exemplified above, set off with curly braces, for instance {example property}.
The correspondence between an element information item which is part
of the XML representation of a schema and one or more schema components is presented in a tableau
which illustrates the element information item(s) involved.
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.
In the XML representation, bold-face
attribute names (e.g. count below) indicate a required
attribute information item, and the rest are
optional. Where an attribute information item has an enumerated type
definition, the values are shown separated by vertical bars, as for
size below; if there is a default value, it is shown
following a colon. Where an attribute information item has a built-in simple
type definition defined in [XML Schemas: Datatypes], a hyperlink to its
definition therein is given.
The allowed content of the information item is
shown as a grammar fragment, using the Kleene operators ?,
* and +. Each element name therein is a hyperlink to
its own illustration.
NOTE:
The illustrations are derived automatically from the Schema for Schemas (normative) (§A). In the case of apparent conflict, the Schema for Schemas (normative) (§A) takes precedence, as it, together with the ·Schema Representation Constraints·, provide the normative statement of
the form of XML representations.
References to elements in the text are links to
the relevant illustration as exemplified above, set off with angle brackets, for instance <example>.
References to properties of information items as defined in [XML-Infoset] are notated as links to the relevant section thereof, set off with square brackets, for example [children].
Properties which this specification defines for information items are
introduced as follows:
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 [new property].
The following highlighting is used for non-normative commentary in
this document:
NOTE:
General comments directed to all readers.
Following [XML 1.0 (Second Edition)], within normative prose in this specification, the words
may and must are defined as follows:
-
may
-
Conforming documents and XML Schema-aware processors are permitted to but need not behave as described.
-
must
-
Conforming documents and XML Schema-aware processors are required to behave as described; otherwise they are in error.
Note however that this specification provides a definition of error and of conformant processors'
responsibilities with respect to errors (see Schemas and Schema-validity Assessment (§5)) which is considerably
more complex than that of [XML 1.0 (Second Edition)].
2 Conceptual Framework
This chapter gives an overview of XML Schema: Structures at the level of its abstract data model. Schema Component Details (§3) provides details on this model, 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 [XML Schema: Primer] for a tutorial introduction, and only then consult the sub-sections of
Schema Component Details (§3) named XML Representation of ... for
the details.
2.1 Overview of XML Schema
An XML Schema
consists of components such as type definitions
and element declarations. These can be used to assess the validity of
well-formed element and attribute information items (as defined
in [XML-Infoset]), and furthermore
may specify augmentations to those items and their descendants. This augmentation makes explicit information which may have
been implicit in the original document, such as normalized and/or default values for
attributes and elements and
the types of element and attribute information items.
Schema-validity assessment has two aspects:
1
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;
2 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.
Throughout this specification, [Definition:] the
word valid and its derivatives are used to refer to
clause 1 above, the determination of local
schema-validity.
Throughout this specification, [Definition:] the word assessment is used to refer
to the overall process of
local validation, schema-validity assessment and infoset augmentation.
2.2 XML Schema Abstract Data Model
This specification builds on [XML 1.0 (Second Edition)] and
[XML-Namespaces]. The concepts and definitions used
herein regarding XML are framed at the abstract level of information
items as defined in [XML-Infoset]. By
definition, this use of the infoset provides a priori guarantees of well-formedness
(as defined in [XML 1.0 (Second Edition)]) and namespace
conformance (as defined in [XML-Namespaces]) for
all candidates for ·assessment· and for all ·schema documents·.
Just as [XML 1.0 (Second Edition)] and
[XML-Namespaces] can be described in terms of
information items, XML Schemas can be described in terms of an
abstract data model. In defining XML Schemas in terms of an abstract
data model, this specification rigorously specifies the information which
must be available to a conforming XML Schema processor. The abstract
model for schemas is conceptual only, and does not mandate any
particular implementation or representation of this information. To
facilitate interoperation and sharing of schema information, a
normative XML interchange format for schemas is provided.
[Definition:] Schema component is the generic term for the building blocks that comprise the abstract data model of the schema.
[Definition:]
An XML Schema is a
set of ·schema components·. There are 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:
- Simple type definitions
- Complex type definitions
- Attribute declarations
- Element declarations
The secondary components, which must have names, are as follows:
- Attribute group definitions
- Identity-constraint definitions
- Model group definitions
- Notation declarations
Finally, the "helper" components provide small parts of
other components; they are not independent of their context:
- Annotations
- Model groups
- Particles
- Wildcards
- Attribute Uses
During ·validation·, [Definition:] declaration components are associated by
(qualified) name to information items being ·validated·.
On the other hand, [Definition:] definition components define
internal schema components that can be used in other schema components.
[Definition:] Declarations and
definitions may have and be identified by names, which are NCNames as defined by [XML-Namespaces].
[Definition:] Several kinds
of component have a target namespace, which is either
·absent· or a namespace name, also as
defined by [XML-Namespaces]. The ·target
namespace· serves to identify the namespace within which the
association between the component and its name exists. In the case of
declarations, this in turn determines the namespace name of, for example, the element
information items it may ·validate·.
NOTE:
At the abstract level, there is
no requirement that the components of a schema share a
·target namespace·. Any schema for use in
·assessment· of documents containing names from more than one namespace
will of necessity include components with different ·target namespaces·. This contrasts with
the situation at the level of the XML representation of components, in which each schema document contributes
definitions and declarations to a single target namespace.
·Validation·, defined in detail in Schema Component Details (§3), is a
relation between information items and schema components. For example, an
attribute information item may ·validate· with respect to an attribute
declaration, a list of element information items may ·validate· with
respect to a content model, and so on. The following sections briefly
introduce the kinds of components in the
schema abstract data model, other major features of the abstract
model, and how they contribute to ·validation·.
2.2.1 Type Definition Components
The abstract model provides two kinds of type definition component: simple
and complex.
[Definition:] This specification uses
the phrase type definition in cases where no distinction
need be made between simple and complex types.
Type definitions form a hierarchy with a single root. The subsections below first describe characteristics of that
hierarchy, then provide an introduction to simple and complex type definitions themselves.
2.2.1.1 Type Definition Hierarchy
[Definition:] Except for a distinguished ·ur-type definition·, every ·type definition· is, by construction, either a
·restriction· or an ·extension· of some other type definition. The graph of these relationships forms a tree known as the Type Definition Hierarchy.
[Definition:] A type
definition whose
declarations or facets are in a one-to-one relation with those of another
specified type
definition, with each in turn restricting the possibilities of the one it
corresponds to, is said to be a restriction.
The specific restrictions might include narrowed ranges or reduced
alternatives.
Members of a type, A, whose definition is a ·restriction· of the definition of another type, B, are always members of type B as well.
[Definition:] A complex type definition
which allows element or attribute content in addition to that allowed by
another specified type
definition is said to be an extension.
[Definition:] A distinguished ur-type
definition is present in each ·XML Schema·, serving as the root of the type
definition hierarchy for that schema. The ur-type definition, whose
name is anyType, has
the unique characteristic that it can function as a complex or a
simple type definition, according to context.
Specifically, ·restrictions· of the ur-type definition can
themselves be either simple or complex type definitions.
[Definition:] A type definition used as the
basis for an ·extension· or
·restriction· is known as
the base type definition of that definition.
2.2.1.2 Simple Type Definition
A simple type definition is a set of constraints on strings and information about the values they encode, applicable to the ·normalized value· of an attribute
information item or of an element information item with no element children.
Informally, it applies to the values of attributes and the text-only content of elements.
Each simple type definition, whether built-in (that is, defined in [XML Schemas: Datatypes]) or
user-defined, is a ·restriction· of some particular
simple ·base type
definition·. For the built-in primitive types, this is the simple
version of the ·ur-type
definition·, whose name is anySimpleType. This
is in turn understood to be a restriction of the ·ur-type
definition·. Simple types may
also be defined whose members are lists of items
themselves constrained by some other simple type definition, or whose
membership is the union of the memberships of some other simple type
definitions. List and union simple type definitions are also understood as
restrictions of the simple ·ur-type
definition·.
For detailed information on simple type definitions, see Simple Type Definitions (§3.14) and [XML Schemas: Datatypes]. The latter also defines an extensive inventory of
pre-defined simple types.
2.2.1.3 Complex Type Definition
A complex type definition is a set of attribute declarations and a content type, applicable to the [attributes] and
[children] of an element information item respectively. The content type may
require the [children] to contain neither element nor character information
items (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.
Each complex type definition is either
or
or
A
complex type which extends another does so by having additional content model
particles at the end of the other definition's content model,
or by having additional attribute declarations, or both.
NOTE:
This specification allows only appending, and not other kinds of
extensions. This decision
simplifies application processing required to cast instances from derived to
base type. Future versions may allow more kinds of extension, requiring more
complex transformations to effect casting.
For detailed information on complex type definitions, see Complex Type Definitions (§3.4).
2.2.2 Declaration Components
There are three kinds of declaration component: element, attribute, and
notation. Each is described in a section below. Also included is a discussion
of element substitution groups, which is a feature provided in conjunction with
element declarations.
2.2.2.1 Element Declaration
An element declaration is an association of a name with a type definition, either simple or
complex, an (optional) default value and a (possibly empty) set of identity-constraint
definitions. The association is either global or scoped to a containing complex type definition. A
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:
<!ELEMENT A . . .>
<!ATTLIST A . . .>
Element declarations contribute to
·validation· as part of model group ·validation·, when their defaults and type components are checked against an element
information item with a matching name and namespace, and by triggering
identity-constraint definition ·validation·.
For detailed information on element declarations, see Element Declarations (§3.3).
2.2.2.2 Element Substitution Group
In XML 1.0, the name and content of an element must correspond exactly to the element type referenced in the corresponding content model.
[Definition:] Through
the new mechanism of element substitution groups, XML Schemas provides a more powerful model supporting substitution of one named element for another.
Any 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 ·validates· not just the head itself, but elements
corresponding to any member of the substitution group as well.
All such members must have type definitions which are either the same as the
head's type definition or
restrictions or extensions of it.
Therefore, although the names of elements can vary widely as new
namespaces and members of the substitution group are defined, the
content of member elements is strictly limited according to the type
definition of the substitution group head.
Note that element substitution groups are not represented as separate components. They are
specified in the property values for element declarations (see Element Declarations (§3.3)).
2.2.2.3 Attribute Declaration
An attribute declaration is an association between a name and a simple type definition, together
with occurrence information and (optionally) a default value. The
association is either global, or local to its containing complex type definition. Attribute declarations contribute to
·validation· as part of complex type definition ·validation·, when their
occurrence, defaults and type components are checked against an attribute
information item with a matching name and namespace.
For detailed information on attribute declarations, see Attribute Declarations (§3.2).
2.2.2.4 Notation Declaration
A notation declaration is an association between a name and an identifier for a
notation. For an attribute information item to be ·valid· with respect to a
NOTATION simple type definition, its value must have been declared
with a notation declaration.
For detailed information on notation declarations, see Notation Declarations (§3.12).
2.2.3 Model Group Components
The model group, particle, and wildcard components contribute to
the portion of a complex type definition that controls an element
information item's content.
2.2.3.1 Model Group
A model group is a constraint in the form of a grammar fragment that applies to
lists of element information items. It consists of a list of particles, i.e.
element declarations, wildcards and model groups. There are three varieties of
model group:
- Sequence (the element information items
match the particles in sequential order);
- Conjunction (the element information items match the
particles, in any order);
- Disjunction (the element information items match
one of the particles).
For detailed information on model groups, see Model Groups (§3.8).
2.2.3.2 Particle
A particle is a term in the grammar for element content, consisting of either an element
declaration, a wildcard or a model group, together with
occurrence constraints. Particles contribute to
·validation· as part of complex type definition ·validation·, when they allow anywhere
from zero to many element information items or sequences thereof, depending on
their contents and occurrence
constraints.
[Definition:] A particle can
be used in a complex type definition to constrain the ·validation·
of the [children] of an element information item; such a particle is called
a content model.
NOTE:
XML Schema: Structures ·content models· are similar to but more expressive than
[XML 1.0 (Second Edition)] content models; unlike [XML 1.0 (Second Edition)], XML Schema: Structures applies ·content models· to the ·validation· of both mixed and element-only content.
For detailed information on particles, see Particles (§3.9).
2.2.3.3 Attribute Use
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.
2.2.3.4 Wildcard
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.
For detailed information on wildcards, see Wildcards (§3.10).
2.2.4 Identity-constraint Definition Components
An identity-constraint definition is an association between a name and one of
several varieties of
identity-constraint related to uniqueness and reference. All the
varieties use [XPath] expressions to pick out sets of
information items relative to particular target element
information items which are unique, or a key, or a ·valid· reference, within
a specified scope. An element information item is only ·valid· with
respect to an element declaration
with identity-constraint definitions if those definitions are all satisfied for all the descendants
of that element information item which they pick out.
For detailed information on identity-constraint definitions, see Identity-constraint Definitions (§3.11).
2.2.5 Group Definition Components
There are two kinds of convenience definitions provided to enable
the re-use of pieces of complex type definitions: model group definitions
and attribute group definitions.
2.2.5.1 Model Group Definition
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.
For detailed information on model group definitions, see Model Group Definitions (§3.7).
2.2.5.2 Attribute Group Definition
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.
For detailed information on attribute group definitions, see Attribute Group Definitions (§3.6).
2.2.6 Annotation Components
An annotation is information for human and/or mechanical
consumers. The interpretation of such information is
not defined in this specification.
For detailed information on annotations, see Annotations (§3.13).
2.3 Constraints and Validation Rules
The [XML 1.0 (Second Edition)] specification describes two kinds of
constraints on XML documents: well-formedness and
validity constraints. Informally, the well-formedness constraints
are those imposed by the definition of XML itself (such as the rules for the
use of the < and > characters and the rules for proper nesting of
elements), while validity constraints are the further constraints on document
structure provided by a particular DTD.
The preceding section focused on ·validation·, that is
the constraints on information items which schema components supply. In fact
however this specification provides four different kinds of normative statements about schema
components, their representations in XML and their contribution to the
·validation· of information items:
-
Schema Component Constraint
-
[Definition:] 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 Schema Component Details (§3)
and tabulated in Schema Component Constraints (§C.4).
-
Schema Representation Constraint
-
[Definition:] Constraints on the
representation of schema components in XML beyond those which are expressed
in Schema for Schemas (normative) (§A). Located in the
third sub-section of the per-component sections of Schema Component Details (§3)
and tabulated in Schema Representation Constraints (§C.3).
-
Validation Rules
-
[Definition:] Contributions to ·validation· associated
with schema components. Located in the
fourth sub-section of the per-component sections of Schema Component Details (§3)
and tabulated in Validation Rules (§C.1).
-
Schema Information Set
Contribution
-
[Definition:] Augmentations to post-schema-validation infosets
expressed by schema components, which follow
as a consequence of ·validation· and/or ·assessment·.
Located in the
fifth sub-section of the per-component sections of Schema Component Details (§3)
and tabulated in Contributions to the post-schema-validation infoset (§C.2).
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 NMTOKENS on attribute white space, and the semantics of
ID and IDREF.) By including schema
information set contributions, this specification makes explicit some features
that XML 1.0 left implicit.
2.4 Conformance
This specification describes three levels of conformance for schema aware processors. The first is
required of all processors. Support for the other two will depend on the application environments
for which the processor is intended.
[Definition:] Minimally conforming processors must completely and
correctly implement the ·Schema Component
Constraints·, ·Validation Rules·,
and ·Schema Information
Set Contributions· contained in this specification.
[Definition:] ·Minimally conforming· processors which accept
processors which accept
schemas represented in the form of XML documents as described in Layer 2: Schema Documents, Namespaces and Composition (§4.2) are
additionally said to provide conformance to the XML Representation of Schemas.
Such processors must, when processing schema documents, completely and
correctly implement all ·Schema Representation
Constraints· in this specification, and must adhere exactly to the
specifications in Schema Component Details (§3) for mapping the contents of
such documents to ·schema
components· for use in ·validation· and ·assessment·.
NOTE:
By separating the conformance requirements relating to the concrete syntax of XML schema
documents, this specification admits processors
which use schemas stored in optimized binary
representations, dynamically created schemas represented as programming language data structures, or implementations in which particular schemas are compiled into executable code
such as C or Java. Such processors can be said to be ·minimally conforming· but not necessarily in ·conformance to the XML Representation of Schemas·.
[Definition:] Fully conforming
processors are network-enabled processors which are not only both ·minimally conforming· and ·in conformance to the XML Representation of Schemas·, but which additionally must be capable of accessing
schema documents from the World Wide Web according to Representation of Schemas on the World Wide Web (§2.7) and How schema definitions are located on the Web (§4.3.2).
.
NOTE: Although this specification provides just these three standard levels of conformance, it is
anticipated that other conventions can be established in the future. For example, the World Wide
Web Consortium is considering conventions for packaging on the Web a variety of
resources relating to individual documents and namespaces. Should such
developments lead to new conventions for representing schemas, or for accessing them on the Web,
new levels of conformance can be established and named at that time. There is no need to modify
or republish this specification to define such additional levels of conformance.
See Schemas and Namespaces: Access and Composition (§4) for a more detailed explanation of the
mechanisms supporting these levels of conformance.
2.5 Names and Symbol Spaces
As discussed in XML Schema Abstract Data Model (§2.2), most schema
components (may) have ·names·.
If all such names were assigned from the same "pool", then
it would be impossible to have, for example, a simple type definition and an element
declaration both with the name
"title" in a given ·target namespace·.
Therefore [Definition:] this specification introduces the term
symbol space to denote a
collection of names, each of which is unique with respect to the others. A symbol space is similar to the non-normative concept of namespace partition introduced in [XML-Namespaces].
There is a single distinct symbol space within a given ·target
namespace· for each kind of definition and declaration component
identified in XML Schema Abstract Data Model (§2.2), except that within a target namespace, simple
type definitions and complex type definitions share a symbol space.
Within a given symbol space, names are unique, but the same name may appear in more than one symbol space without conflict. For example, the same name can appear in both a type definition and an element declaration, without conflict or necessary relation between the two.
Locally scoped attribute and element
declarations are special with regard to symbol spaces.
Every complex type definition defines its own local attribute and element declaration symbol
spaces, where these symbol spaces are distinct from each other and from any of the other
symbol spaces. So, for example, two complex type definitions having
the same target namespace can contain
a local attribute declaration for the unqualified name "priority", or contain a local element declaration
for the name "address", without conflict or necessary relation between
the two.
2.6 Schema-Related Markup in
Documents Being Validated
The XML representation of schema components uses a vocabulary
identified by the namespace name http://www.w3.org/2001/XMLSchema. For brevity, the text and examples in this specification use the prefix
xs: to stand for this namespace; in practice,
any prefix can be used.
XML Schema: Structures also defines several attributes for direct use in any XML documents. These attributes are in a different namespace,
which has the namespace name http://www.w3.org/2001/XMLSchema-instance.
For brevity, the text and examples in this specification use the prefix
xsi: to stand for this latter namespace; in practice,
any prefix can be used. All schema processors have appropriate attribute
declarations for these attributes built in, see Attribute Declaration for the 'type' attribute (§3.2.7),
Attribute Declaration for the 'nil' attribute (§3.2.7), Attribute Declaration for the 'schemaLocation' attribute (§3.2.7) and Attribute Declaration for the 'noNamespaceSchemaLocation' attribute (§3.2.7).
2.6.2 xsi:nil
XML Schema: Structures introduces a mechanism for signaling that an element should
be accepted as ·valid· when it has no
content despite a content type which does not require or even necessarily allow empty content. An
element may be
·valid· without content if it has the attribute xsi:nil with
the value true. An element so labeled must be empty, but can
carry attributes if permitted by the corresponding complex type.
2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation
The xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes can be used in a document to provide
hints as to the physical location of schema documents which may be used for ·assessment·.
See How schema definitions are located on the Web (§4.3.2) for details on the use of these attributes.
