Status of this document

This draft specification is a work in progress representing the current
consensus of the W3C XML Working Group.
This is a W3C Working Draft for review by W3C members and other interested
parties.
Publication as a working draft does not imply endorsement by the W3C
membership.

This draft embodies a large-scale revision of the namespace
specification. While it is unfinished in some respects, the
Working Group intends to keep the features it describes
functionally unchanged unless problems are discovered during early
implementation work. To discover such problems as quickly as
possible, a special editorial team has been formed to receive
feedback from implementors during a one-month period beginning
with the publication of the working draft and ending shortly after
the XML Working Group meeting in Montreal August 22-23. Please
send implementation experience reports to
xml-names-issues@w3.org.

While we do not anticipate substantial changes, we still caution that
further changes are possible and therefore we recommend that only
experimental software or software that can be easily field-upgraded be
implemented to this specification at this time.
The XML Working Group will not allow early implementation to constrain its
ability to make changes to this specification
prior to final release.
This is a draft document and may be updated, replaced or obsoleted by other
documents at any time.
It is inappropriate to cite W3C Working Drafts as other than "work in
progress".

It is the intent of the XML Working Group that this namespace facility
should become an integral part of some future version of the
XML specification.

Abstract

XML namespaces provide a simple method for qualifying
names used in Extensible Markup Language documents by associating them
with namespaces identified by URI.

Appendices

We envision the use of Extensible Markup Language (XML) documents which
contain markup that is defined for and used by different software modules.
One motivation for this is modularity; if there is a set of markup
available which is well-understood and for which there is useful software
available, it is better to re-use this markup rather than re-invent it.

Such documents, containing markup from multiple independent sources,
pose problems of recognition and collision. Software modules need to
be able to recognize the markup (tags and attributes) which they are designed
to process, even in the face
of "collisions" occurring when markup intended for some other software
package uses the same element type or attribute name.

[Definition:] An XML namespace
is a collection of names, identified by a URI,
which are used in XML documents as
element types
and attribute names.
XML namespaces
differ from the "namespaces" conventionally used in computing disciplines
in that the XML version has internal structure and is not, mathematically
speaking, a set.
These issues are discussed in
"6. The Internal Structure of XML Namespaces".

Names from XML namespaces may appear as
qualified names,
which contain a single colon, separating the name into a
namespace prefix and the
local part.
The prefix, which is mapped to a URI, selects a namespace.
The combination of
the universally managed URI namespace and the document's own namespace
produces identifiers that are guaranteed universally unique.
A mechanism is provided for defaulting the prefix to avoid clutter
and improve readability.

URIs can contain characters not allowed in names, so cannot
be used directly as namespace prefixes.
Therefore, the
namespace prefix serves as a proxy for a URI.
An attribute-based syntax described below is used
to declare the association of the
namespace prefix with a URI;
software which supports this namespace proposal must
recognize and act on these declarations and prefixes.

[Definition:] A namespace is declared using an
attribute whose prefix is xmlns as follows.
Note that many of the nonterminals in the productions in
this specification are defined not here but in
the XML specification [XML].
When nonterminals defined here have the same names as nonterminals
defined in the XML specification, the productions here
in all cases match a subset of the strings matched by the
corresponding ones there.

[Definition:] The
SystemLiteral
in the NSDef production
is a URI which functions as a namespace name to identify the
namespace.
The namespace name, to serve its
intended purpose, should have the characteristics of uniqueness and
persistence.
It is not a goal that it be directly usable for retrieval of a schema (if
any exists).
An example of a syntax that is designed with these goals in mind is
that for Uniform Resource Names [RFC2141].
However, it should be noted that ordinary URLs can be managed in such a way as
to achieve these same goals.

[Definition:] In the
PrefixDef
production, if the optional colon and
NCName are provided, then that
NCName gives the namespace prefix,
used to associate names with this namespace
in the scope of the element to which the declaration
is attached.

[Definition:] If the colon
and NCName are not provided, then the
associated namespace name is
that of the default namespace
in the scope of the element to which the declaration
is attached.

Namespace Constraint:
Empty URI
The SystemLiteral
may be empty only if the
PrefixDef is simply xmlns, i.e. is
declaring a default namespace.
The effect of such a declaration is to override any higher-level
declaration of the default namespace, setting its value to null.
Default namespaces and overriding of declarations are discussed in
"5. Namespace Scoping and Defaulting".

Note that the prefix functions only as a placeholder for a
namespace name.
Applications should use the namespace name, not the prefix, in constructing
names whose scope extends beyond the
containing document.

Namespace Constraint:
Prefix Declared
The namespace prefix, unless it is xml
or xmlns, must have been
declared in a namespace declaration.
The namespace prefixes xml and xmlns are reserved,
and considered to
have been implicitly declared.
Prefixes beginning with the three-letter sequence x,
m, l, in any case combination, are reserved
for use by XML and XML-related specifications.

Element names and attribute types are also given as qualified names when
they appear in declarations in the
DTD:

The namespace declaration is considered to apply to the
element where it is specified and to all elements within the content
of that element, unless overridden by another namespace declaration
with the same PrefixDef part:

Multiple namespace prefixes can be declared as attributes of a single element,
as shown in this example:

<?xml version="1.0"?><!-- both namespace prefixes are available throughout --><bk:book xmlns:bk='urn:loc.gov:books' xmlns:isbn='urn:ISBN:0-395-36341-6'> <bk:title>Cheaper by the Dozen</bk:title> <isbn:number>1568491379</isbn:number></bk:book>

A default namespace is considered
to apply to the element where it is declared (if that element has no
namespace prefix), and to all elements
with no prefix within the content of that
element.
Note that default namespaces do not apply directly to attributes.
The namespace of an unprefixed attribute is a function of the type of
the element to
which it is attached, and to the namespace (if any) of that element.
For details, see "6. The Internal Structure of XML Namespaces".

<?xml version="1.0"?><!-- once again, everything is in the HTML namespace, by default --><html xmlns='http://www.w3.org/TR/REC-html40'> <head><title>Frobnostication</title></head> <body><p>Moved to <a href='http://frob.com'>here</a>.</p></body> </html>

In the computing disciplines, the term "namespace" conventionally refers to
a set of names, i.e. a collection containing no duplicates.
However, treating the names used in XML markup
as such a namespace would greatly impair their usefulness.
The primary use of such names in XML documents is to enable identification
of logical
structures in documents by software modules such as query processors,
stylesheet-driven
rendering engines, and schema-driven validators.
Consider the following example:

In this case, the CLASS attribute, which describes the fare basis
and takes values such as "J", "Y", and "C", is distinct at all semantic levels
from the HTML:CLASS attribute, which is used to achieve CSS
formatting effects.

XML 1.0 does not provide a built-in way to declare "global" attributes;
items such as the HTML CLASS attribute are global only in their
prose description and their interpretation by HTML applications.
However, such attributes, an important distinguishing feature of which is that
their names are unique, are commonly observed to occur in a variety of
applications.

In order to support the goal of making both qualified and unqualified names
useful in meeting their intended purpose, we identify the names appearing in
an XML namespace as belonging to one of several disjoint traditional
(i.e. set-structured) namespaces, called namespace partitions.
The partitions are:

The All Element Types Partition

All element types in an XML namespace appear in this partition.
Each has a unique local part; the
combination of the namespace name and the local part uniquely identifies the
element type.

The Global Attribute Partition

This partition contains the names of all attributes which are defined,
in this namespace, to be global.
The only required characteristic of a global attribute is that its name be
unique in the global attribute partition.
This specification makes no
assertions as to the proper usage of such attributes.
The combination of the namespace name and the attribute name uniquely
identifies the global attribute.

The Per-Element-Type Partitions

Each type in the All Element Types Partition has an
associated namespace in which appear the names of the unqualified attributes
that are provided for that element.
This is a traditional namespace because the appearance of duplicate attribute
names on an element is forbidden by XML 1.0.
The combination of the attribute name with the element's type and namespace
name uniquely identifies each unqualified attribute.

In XML documents conforming to this specification, the names of
all qualified (prefixed) attributes are assigned to the global attribute
partition, and the names of all unqualified attributes are assigned to the
appropriate per-element-type partition.

For convenience in specifying rules and in making comparisons, we define an
expanded form, expressed here in XML element syntax, for each element type and
attribute name in an XML document.

[Definition:] An
expanded element
type is expressed as an empty XML element of type
ExpEType.
It has a required type attribute which
gives the type's LocalPart, and an optional
ns attribute which, if the element is qualified, gives its
namespace name.

[Definition:] An
expanded
attribute name is expressed as an empty XML element of type
ExpAName.
It has a required name attribute which gives the name.
If the attribute is global, it has a required ns attribute
which gives the namespace name;
otherwise, it has a required attribute eltype which
gives the type of the attached element, and an optional attribute
elns which gives the namespace name, if known, of the
attached element.

Slight variations on the examples given above will illustrate
the working of expanded element types and attribute names.
The following two fragments are each followed by a table showing
the expansion of the names:

In an XML document conforming to this specification, no element may have
two attributes whose expanded names are equivalent, i.e. have the same
attribute-value pairs and child elements with the same content.

Names in XML documents which conform to this specification are
element types and attribute names which match the production for
QName and
which satisfy the "Namespace Constraints" in this document.

An XML document conforms to this specification if all other
tokens in the document which are required, for XML conformance, to match the
XML production for Name, match
this specification's production for NCName,
and in which elements have attributes with unique expanded names.

The effect of conformance is that in such a document:

All element types and attribute names contain either zero
or one colon.

No entity names, PI targets, or notation names contain any colons.

Strictly speaking, attribute values declared to be of types
ID, IDREF(S), ENTITY(IES),
and NOTATION are also Names,
and thus should be colon-free.
However, the declared type of attribute values is in principle only available
in documents which have been
validated.
Thus, in well-formed XML
documents, there can be no assurance that the contents of attribute values
have been checked for conformance to this specification.

Appendices

This work reflects input from a very large number of people,
including especially the members of the World Wide
Web Consortium XML Working Group and Special Interest Group
and the participants in the W3C Metadata Activity.