Namespaces in XML 1.1
Namespaces in XML 1.1
W3C Proposed
Recommendation 05 November 2003
This version:
Latest version:
Previous version:
Editors:
Tim Bray, Textuality
Dave Hollander, Contivo, Inc.
Andrew Layman, Microsoft
Richard Tobin, University of Edinburgh and Markup
Technology Ltd
- Version 1.1
This document is also available in these non-normative
formats:
XML
W3C
MIT
ERCIM
Keio
), All Rights
Reserved. W3C
liability
trademark
document
use
and
software
licensing
rules apply.
Abstract
XML namespaces provide a simple method for qualifying
element and attribute names used in Extensible Markup Language
documents by associating them with namespaces identified by
IRI
references.
Status of this
Document
This section describes the status of this document at
the time of its publication. Other documents may supersede this
document. A list of current W3C publications and the latest
revision of this technical report can be found in the
W3C technical reports index
at
This document, Namespaces in XML 1.1, is a
Proposed
Recommendation
of the W3C. This document has been produced
by the
W3C XML Core
Working Group
as part of the
XML Activity
W3C Advisory Committee Representatives are invited to submit
their formal review per the instructions in the Call for
Review. The public is also invited to send comments to
xml-names-editor@w3.org
(public
archives
are available). The review period extends to 5 December
2003.
This document is based upon the
Namespaces
in XML 1.1 Candidate Recommendation
of 18 December 2002 and
feedback received during the review period (see the
Disposition of
Comments
document). The XML Core Working Group believes
that this specification addresses its
Requirements
and all Last Call and Candidate Recommendation issues. Known
implementations are documented in the
Namespaces 1.1 implementation report
. A test suite is also
available.
Documentation of intellectual property possibly relevant to
this Recommendation may be found at the Working Group's
public
IPR disclosure page
Publication as a Proposed Recommendation does not imply
endorsement by the W3C Membership. This is a draft document and
may be updated, replaced or obsoleted by other documents at any
time. It is inappropriate to cite this document as other than
work in progress.
Table of Contents
Motivation and
Summary
1.1
A Note on
Notation and Usage
XML Namespaces
2.1
Basic
Concepts
2.2
Use of IRIs as
Namespace Names
2.3
Comparing
IRI References
Declaring Namespaces
Qualified Names
Using Qualified Names
Applying Namespaces to Elements
and Attributes
6.1
Namespace
Scoping
6.2
Namespace
Defaulting
6.3
Uniqueness of
Attributes
Conformance of Documents
Conformance of
Processors
Internationalized Resource Identifiers
(IRIs)
Appendices
References
The Internal Structure of XML
Namespaces
(Non-Normative)
Changes since version 1.0
(Non-Normative)
Changes since the Candidate
Recommendation
(Non-Normative)
Acknowledgements
(Non-Normative)
1 Motivation and
Summary
We envision applications of Extensible Markup Language
(XML) where a single XML document may contain elements and
attributes (here referred to as a "markup vocabulary") that
are defined for and used by multiple software modules. One
motivation for this is modularity: if such a markup
vocabulary exists 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 multiple markup vocabularies,
pose problems of recognition and collision. Software modules
need to be able to recognize the elements 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
name
or
attribute name.
These considerations require that document constructs
should have names constructed so as to avoid clashes between
names from different markup vocabularies. This specification
describes a mechanism,
XML namespaces
, which
accomplishes this by assigning
expanded names
to elements and
attributes.
1.1 A Note on
Notation and Usage
Where
EMPHASIZED
, the key words
MUST
MUST NOT
REQUIRED
SHOULD
SHOULD NOT
MAY
in this document are to
be interpreted as described in
[Keywords]
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.
In this document's productions, the
NSC
is
a "Namespace Constraint", one of the rules that documents
conforming to this specification
MUST
follow.
2 XML
Namespaces
2.1 Basic
Concepts
Definition
: An
XML namespace
is
identified by an
IRI reference
; element and attribute names
may be placed in an XML namespace using the mechanisms
described in this specification. ]
Definition
: An
expanded name
is a
pair consisting of a
namespace name
and a
local name
. ] [
Definition
: For a name
in a
namespace identified by an IRI
, the
namespace name
is
. For a name
that is not in a namespace, the
namespace
name
has no value. ] [
Definition
: In
either case the
local name
is
. ] It is
this combination of the universally managed IRI namespace
with the vocabulary's local names that is effective in
avoiding name clashes.
IRI references can contain characters not allowed in
names, and are often inconveniently long, so expanded names
are not used directly to name elements and attributes in
XML documents. Instead
qualified names
are used. [
Definition
: A
qualified name
is a
name subject to namespace interpretation. ] In documents
conforming to this specification, element and attribute
names appear as qualified names. Syntactically, they are
either
prefixed
names
or
unprefixed names
. An
attribute-based declaration syntax is provided to bind
prefixes to namespace names and to bind a default namespace
that applies to unprefixed element names; these
declarations are scoped by the elements on which they
appear so that different bindings may apply in different
parts of a document. Processors conforming to this
specification
MUST
recognize and act on
these declarations and prefixes.
2.2 Use of IRIs as
Namespace Names
The empty string, though it is a legal IRI reference,
cannot be used as a namespace name.
The use of relative IRI references, including
same-document references, in namespace declarations is
deprecated. Future W3C specifications will define no
interpretation for them.
2.3
Comparing IRI References
IRI references identifying namespaces are compared when
determining whether a name belongs to a given namespace,
and whether two names belong to the same namespace.
Definition
: The two IRIs are treated as
strings, and they are
identical
if and only if the
strings are identical, that is, if they are the same
sequence of characters. ] The comparison is case-sensitive,
and no %-escaping is done or undone.
A consequence of this is that IRI references which are
not identical in this sense may resolve to the same
resource. Examples include IRI references which differ only
in case or %-escaping, or which are in external entities
which have different base URIs (but note that relative IRIs
are deprecated as namespace names).
In a namespace declaration, the IRI reference is the
normalized
value
of the attribute, so replacement of XML character
and entity references has already been done before any
comparison.
Examples:
The IRI references below are all different for the
purposes of identifying namespaces, since they differ in
case:
The IRI references below are also all different for the
purposes of identifying namespaces:
As are these:
If the entity
eacute
has been defined to be
, the start tags below all contain namespace
declarations binding the prefix
to the same IRI
reference,
Because of the risk of confusion between IRIs that would
be equivalent if derefenced, the use of %-escaped
characters in namespace names is strongly discouraged.
3 Declaring
Namespaces
Definition
: A namespace
(or more
precisely, a namespace binding)
is
declared
using a family of reserved attributes. Such an attribute's
name must either be
xmlns
or
begin
xmlns:
. These attributes, like any other XML
attributes, may be provided directly or by
default
Attribute Names for
Namespace Declaration
[1]
NSAttName
::=
PrefixedAttName
DefaultAttName
[2]
PrefixedAttName
::=
'xmlns:'
NCName
[NSC: Reserved Prefixes and
Namespace Names]
[3]
DefaultAttName
::=
'xmlns'
[4]
NCName
::=
NCNameStartChar
NCNameChar
/* An XML
Name
minus the ":" */
[5]
NCNameChar
::=
NameChar
- ':'
[5a]
NCNameStartChar
::=
NameStartChar
- ':'
The attribute's
normalized
value
MUST
be either an IRI
reference — the
namespace name
identifying the namespace —
or an empty string.
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). Uniform Resource Names
[RFC2141]
is an example of a syntax that is
designed with these goals in mind. However, it should be
noted that ordinary URLs can be managed in such a way as to
achieve these same goals.
Definition
: If the attribute name matches
PrefixedAttName
, then the
NCName
gives the
namespace
prefix
, used to associate element and attribute names
with the
namespace name
in the attribute value in the
scope of the element to which the declaration is
attached.]
Definition
: If the attribute name matches
DefaultAttName
, then the
namespace
name
in the attribute value is that of the
default
namespace
in the scope of the element to which the
declaration is attached.] Default namespaces and overriding
of declarations are discussed in
6 Applying Namespaces to Elements
and Attributes
An example namespace declaration, which associates the
namespace prefix
edi
with the namespace name
Namespace constraint: Reserved
Prefixes and Namespace Names
The prefix
xml
is by definition bound to the
namespace name
. It
MAY
, but need not, be
declared, and
MUST NOT
be bound to
any other namespace name. Other prefixes
MUST
NOT
be bound to this namespace name.
The prefix
xmlns
is used only to declare
namespace bindings and is by definition bound to the
namespace name
It
MUST NOT
be declared.
Other prefixes
MUST NOT
be bound to
this namespace name.
All other prefixes beginning with the three-letter
sequence x, m, l, in any case combination, are reserved.
This means that:
users
SHOULD NOT
use
them except as defined by later specifications
processors
MUST NOT
treat them
as fatal errors.
Though they are not themselves reserved, it is inadvisable
to use prefixed names whose LocalPart begins with the letters
x, m, l, in any case combination, as these names would be
reserved if used without a prefix.
4 Qualified
Names
In XML documents conforming to this specification, some
names (constructs corresponding to the nonterminal
Name
MUST
be
given as
qualified
names
, defined as follows:
Qualified Name
[6]
QName
::=
PrefixedName
UnprefixedName
[6a]
PrefixedName
::=
Prefix
':'
LocalPart
[6b]
UnprefixedName
::=
LocalPart
[7]
Prefix
::=
NCName
[8]
LocalPart
::=
NCName
The
Prefix
provides the
namespace prefix
part of the qualified name, and
MUST
be associated with a
namespace
IRI
reference in a
namespace
declaration
. [
Definition
: The
LocalPart
provides the
local part
of the qualified name.]
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.
5 Using Qualified
Names
In XML documents conforming to this specification, element
names
are given as
qualified names
, as follows:
Element Names
[9]
STag
::=
'<'
QName
Attribute
)*
'>'
[NSC: Prefix
Declared]
[10]
ETag
::=
'QName
? '>'
[NSC: Prefix
Declared]
[11]
EmptyElemTag
::=
'<'
QName
Attribute
)*
'/>'
[NSC: Prefix
Declared]
An example of a qualified name serving as an element
name:
Attributes are either
namespace declarations
or their names
are given as
qualified names
Attribute
[12]
Attribute
::=
NSAttName
Eq
AttValue
QName
Eq
AttValue
[NSC: Prefix
Declared]
An example of a qualified name serving as an attribute
name:
Namespace constraint: Prefix
Declared
The namespace prefix, unless it is
xml
or
xmlns
MUST
have been declared in
namespace declaration
attribute in either
the start-tag of the element where the prefix is used or in
an ancestor element (i.e. an element in whose
content
the prefixed markup occurs). Furthermore, the attribute
value in the innermost such declaration
MUST NOT
be
an empty string
This constraint may lead to operational difficulties in
the case where the namespace declaration attribute is
provided, not directly in the XML
document
entity
, but via a default attribute declared in an
external entity. Such declarations may not be read by
software which is based on a non-validating XML processor.
Many XML applications, presumably including
namespace-sensitive ones, fail to require validating
processors.
If correct operation with such applications
is required
, namespace declarations
MUST
be
provided either directly or via default attributes declared
in the
internal
subset of the DTD
Element names and attribute
names
are also
given as qualified names when they appear in declarations in
the
DTD
Qualified Names in
Declarations
[13]
doctypedecl
::=
'QName
ExternalID
)?
('[' (
markupdecl
PEReference
)*
']'
?)?
'>'
[14]
elementdecl
::=
'QName
contentspec
'>'
[15]
cp
::=
QName
choice
seq
('?' | '*' | '+')?
[16]
Mixed
::=
'('
'#PCDATA' (
'|'
QName
)*
')*'
| '('
'#PCDATA'
')'
[17]
AttlistDecl
::=
'QName
AttDef
'>'
[18]
AttDef
::=
QName
NSAttName
AttType
DefaultDecl
Note that DTD-based validation is not namespace-aware in
the following sense: a DTD constrains the elements and
attributes that may appear in a document by their
uninterpreted names, not by (namespace name, local name)
pairs. To validate a document that uses namespaces against a
DTD, the same prefixes must be used in the DTD as in the
instance. A DTD may however indirectly constrain the
namespaces used in a valid document by providing
#FIXED
values for attributes that declare
namespaces.
6 Applying Namespaces to Elements
and Attributes
6.1 Namespace
Scoping
The scope of a namespace declaration declaring a prefix
extends from the beginning of the start-tag in which it
appears to the end of the corresponding end-tag, excluding
the scope of any inner declarations with the same NSAttName
part. In the case of an empty tag, the scope is the tag
itself.
Such a namespace declaration applies to all element and
attribute names within its scope whose prefix matches that
specified in the declaration.
The
expanded
name
corresponding to a prefixed element or attribute
name has the IRI to which the
prefix
is bound as its
namespace name
, and
the
local part
as its
local
name
1.1
"?>
Multiple namespace prefixes can be declared as
attributes of a single element, as shown in this
example:
1.1
"?>
The attribute value in a namespace declaration for a
prefix
MAY
be empty. This has the
effect, within the scope of the declaration, of removing
any association of the prefix with a namespace name.
Further declarations
MAY
re-declare the prefix
again:
6.2 Namespace
Defaulting
The scope of a
default namespace
declaration extends
from the beginning of the start-tag in which it appears to
the end of the corresponding end-tag, excluding the scope
of any inner default namespace declarations. In the case of
an empty tag, the scope is the tag itself.
A default namespace declaration applies to all
unprefixed element names within its scope. Default
namespace declarations do not apply directly to attribute
names; the interpretation of unprefixed attributes is
determined by the element on which they appear.
If there is a default namespace declaration in scope,
the
expanded
name
corresponding to an unprefixed element name has
the IRI of the
default namespace
as its
namespace name
. If
there is no default namespace declaration in scope, the
namespace name has no value. The namespace name for an
unprefixed attribute name always has no value. In all
cases, the
local
name
is
local part
(which is of course the same as the unprefixed name
itself).
1.1
"?>
Moved to
here.
1.1
"?>
A larger example of namespace scoping:
1.1
"?>
This is a funny book!
The attribute value in a default namespace declaration
MAY
be empty. This has the
same effect, within the scope of the declaration, of there
being no default namespace.
1.1
'?>
| Name | Origin | Description |
6.3 Uniqueness
of Attributes
In XML documents conforming to this specification, no
tag may contain two attributes which:
have identical names, or
have qualified names with the same
local part
and
with
prefixes
which have been bound to
namespace
names
that are
identical
This constraint is equivalent to requiring that no
element have two attributes with the same
expanded name
For example, each of the
bad
start-tags is
illegal in the following:
However, each of the following is legal, the second
because the default namespace does not apply to attribute
names:
7 Conformance
of Documents
This specification applies to XML 1.1 documents. To
conform to this specification, a document
MUST
be well-formed
according to the XML 1.1 specification.
In XML documents which conform to this specification,
element and attribute names
MUST
match the production for
QName
and
MUST
satisfy the "Namespace
Constraints". All other tokens in the document which are
REQUIRED
, for XML 1.1
well-formedness, to match the XML production for
Name
MUST
match this
specification's production for
NCName
Definition
: A document is
namespace-well-formed
if it conforms to this
specification. ]
It follows that in a namespace-well-formed document:
All element and attribute names contain either zero or
one colon;
No entity names, processing instruction targets, or
notation names contain any colons.
In addition, a namespace-well-formed document may also be
namespace-valid.
Definition
: A namespace-well-formed document is
namespace-valid
if it is valid according to the XML
1.1 specification, and all tokens other than element and
attribute names which are
REQUIRED
, for XML 1.1
validity, to match the XML production for
Name
match this specification's production for
NCName
. ]
It follows that in a namespace-valid document:
No attributes with a declared type of
ID
IDREF(S)
ENTITY(IES)
, or
NOTATION
contain any colons.
8 Conformance of Processors
To conform to this specification, a processor
MUST
report
violations of namespace well-formedness, with the exception
that it it not
REQUIRED
to check that
namespace names are legal IRIs.
Definition
: A validating XML processor that
conforms to this specification is
namespace-validating
if in addition it reports violations of namespace validity.
9 Internationalized Resource
Identifiers (IRIs)
Work is currently in progress to produce an RFC defining
Internationalized Resource Identifiers (IRIs). Since this
work is not yet complete, this section gives a syntactic
definition of IRIs for the purposes of this specification.
The XML Core Working Group expects to issue an erratum
replacing this section with a reference to the RFC when it is
published. Users defining namespaces are advised to restrict
namespace names to URIs until software supporting IRIs is in
common use.
For a more general definition and discussion of IRIs see
[IRI draft]
(work in progress).
URI references are restricted to a subset of the ASCII
characters; IRI references allow some of the disallowed ASCII
characters as well as most Unicode characters from #xA0
onwards.
Definition
: The
additional characters
allowed in IRIs are: ]
space #x20
the delimiters
#x3C,
#x3E and
#x22
the unwise characters
#x7B,
#x7D,
#x7C,
#x5C,
#x5E and
#x60
the Unicode plane 0 characters #xA0 - #xD7FF,
#xF900-#xFDCF, #xFDF0-#xFFEF
the Unicode plane 1-14 characters #x10000-#x1FFFD ...
#xD0000-#xDFFFD, #xE1000-#xEFFFD
Definition
: An
IRI reference
is a string
that can be converted to a URI reference by escaping all
additional characters as follows: ]
Each additional character is converted to UTF-8
[Unicode 3.2]
as one or more
bytes.
The resulting bytes are escaped with the URI escaping
mechanism (that is, converted to %HH, where HH is the
hexadecimal notation of the byte value).
The original character is replaced by the resulting
character sequence.
Note:
The algorithm in
[IRI draft]
includes a UCS normalization step, but this makes no
difference to which strings are IRI references.
A References
IRI
draft
Internationalized Resource Identifiers
(IRIs)
, M. Duerst and M. Suignard, March 2,
2003. Available at
1.0
Errata
Namespaces
in XML Errata
. Available at
Requirements
Namespaces in XML 1.1 Requirements
, Jonathan
Marsh, ed. March 2002. Available at
Keywords
REF 2119:
Key words for use in RFCs to Indicate Requirement
Levels
, S. Bradner, ed. March 1997. Available at
RFC2141
RFC 2141:
URN Syntax
, R. Moats, ed. May 1997.
Available at
RFC2396
RFC 2396:
Uniform Resource Identifiers (URI): Generic
Syntax
, T. Berners-Lee, R. Fielding, and L.
Masinter, eds. August 1998. Available at
RFC2732
RFC 2732:
Format for Literal IPv6 Addresses in URL's
, R.
Hinden, B. Carpenter, and L. Masinter, eds. December 1999.
Available at
Unicode 3.2
The Unicode Standard, Version 3.2.0
is
defined by
The Unicode Standard, Version 3.0
(The Unicode Consortium. Addison-Wesley, 2000. ISBN
0-201-61633-5) as amended by the
Unicode
Standard Annex #27: Unicode 3.1
(http://www.unicode.org/reports/tr27/), and the
Unicode
Standard Annex #28: Unicode 3.2
(http://www.unicode.org/reports/tr28/).
XML
Extensible
Markup Language (XML) 1.0 (Second Edition)
, Tim
Bray, Jean Paoli, C. M. Sperberg-McQueen, and Eve Maler
eds. 6 October 2000. Available at
XML
1.1
Extensible
Markup Language (XML) 1.1
, Tim Bray, Jean Paoli,
C. M. Sperberg-McQueen, Eve Maler, and John Cowan eds.
Available at
B The Internal
Structure of XML Namespaces (Non-Normative)
This appendix has been deleted.
C Changes since
version 1.0 (Non-Normative)
This version incorporates the errata to version 1.0 as of
6 December 2002
[1.0 Errata]
. There
are two further substantive changes:
A mechanism is provided for undeclaring prefixes;
Namespace names are IRIs, rather than URIs.
There are several editorial changes, including a number of
terminology changes and additions intended to produce greater
consistency. The non-normative appendix "The Internal
Structure of XML Namespaces" has been removed.
D Changes since
the Candidate Recommendation (Non-Normative)
The following changes have been made since the Candidate
Recommendation:
several typographical corrections and minor editorial
changes have been made;
RFC 2119 key words are now flagged;
the term "is null" has been replaced with "has no
value" for the namespace name of names in no
namespace;
the use of %-escaped characters in namespace IRIs is
now discouraged;
example IRIs now use RFC 2606 reserved names;
the paragraph about DTD validation has been
clarified;
in the section on IRIs, an error in the list of
additional characters has been corrected, and a note
about UCS normalization added;
there are now links to productions in the XML 1.1
Proposed Recommendation instead of copies of those
productions;
several references have been updated.
Acknowledgements (Non-Normative)
This work reflects input from a very large number of
people, including especially the participants in the World
Wide Web Consortium XML Working Group and Special Interest
Group and the participants in the W3C Metadata Activity. The
contributions of Charles Frankston of Microsoft were
particularly valuable.