Namespaces in XML

World Wide Web Consortium Working Draft 2-August-1998

This version:
Latest version:
Previous version:
Tim Bray (Textuality) <tbray@textuality.com>
Dave Hollander (Hewlett-Packard Company) <dmh@corp.hp.com>
Andrew Layman (Microsoft) <andrewl@microsoft.com>

Copyright  ©  1998 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

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.


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

Table of Contents

1. Motivation and Summary
2. Declaring Namespaces
3. Qualified Names
4. Using Qualified Names
5. Namespace Scoping and Defaulting
6. The Internal Structure of XML Namespaces
    6.1 The Insufficiency of the Traditional Namespace
    6.2 XML Namespace Partitions
    6.3 Expanded Element Types and Attribute Names
    6.4 Unique Expanded Attribute Names
7. Conformance


A. Acknowledgements
B. References

1. Motivation and Summary

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.

These considerations require that document constructs should have universal names, whose scope extends beyond their containing document. This specification describes a mechanism, XML namespaces, which accomplishes this.

[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.

2. Declaring Namespaces

[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.

Namespace declaration using attributes
[1] NSDef ::= PrefixDef Eq SystemLiteral [ NSC: Empty URI ]
[2] PrefixDef ::= 'xmlns' (':' NCName)?
[3] NCName ::= (Letter | '_') (NCNameChar)* /* An XML Name, minus the ":" */
[4] NCNameChar ::= LetterDigit | '.' | '-' | '_' | CombiningCharExtender

[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".

An example namespace declaration:

<?xml version="1.0"?>
  <x xmlns:edi='http://ecommerce.org/schema'>
    <!-- the edi namespace applies to the "x" element and contents -->

3. Qualified Names

[Definition:] In XML documents conforming to this specification, some names (constructs corresponding to the nonterminal Name) may be given as qualified names, defined as follows:

Qualified Name
[5] QName ::= (Prefix ':')? LocalPart
[6] Prefix ::= NCName
[7] LocalPart ::= NCName

The Prefix provides the namespace prefix part of the qualified name, and must be associated with a namespace URI 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.

4. Using Qualified Names

In XML documents conforming to this specification, element types are given as qualified names, as follows:

Element Types and Attribute Names
[8] STag ::= '<' QName (S Attribute)* S? '>' [ NSC: Prefix Declared ]
[9] ETag ::= '</' QName S? '>' [ NSC: Prefix Declared ]
[10] EmptyElement ::= '<' QName (S Attribute)* S? '/>' [ NSC: Prefix Declared ]

Attribute names are given as qualified names, as follows:

[11] Attribute ::= QName Eq AttValue [ NSC: Prefix Declared ]

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:

Qualified Names in Declarations
[12] doctypedecl ::= '<!DOCTYPE' S QName (S ExternalID)? S? ('[' (markupdeclPEReferenceS)* ']' S?)? '>'
[13] elementdecl ::= '<!ELEMENT' S QName S contentspec S? '>'
[14] cp ::= (QNamechoiceseq) ('?' | '*' | '+')?
[15] Mixed ::= '(' S? '#PCDATA' (S? '|' S? QName)* S? ')*'
| '(' S? '#PCDATA' S? ')'
[16] AttlistDecl ::= '<!ATTLIST' S QName AttDef* S? '>'
[17] AttDef ::= S QName S AttType S DefaultDecl

5. Namespace Scoping and Defaulting

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:

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

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'
    <bk:title>Cheaper by the Dozen</bk:title>

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'>
  <body><p>Moved to 
    <a href='http://frob.com'>here</a>.</p></body>

<?xml version="1.0"?>
<!-- unprefixed names are from "books" -->
<book xmlns='urn:loc.gov:books'
    <title>Cheaper by the Dozen</title>

A larger example of namespace scoping:

<?xml version="1.0"?>
<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
    <title>Cheaper by the Dozen</title>
      <!-- drop the default into HTML for some commentary -->
      <p xmlns='urn:w3-org-ns:HTML'>
          This is a <i>funny</i> book!

The default namespace, once declared, may be overridden:

<?xml version='1.0'?>
  <!-- the default namespace is now that of HTML -->
  <table xmlns='http://www.w3.org/TR/REC-html40'>
     <!-- drop the HTML namespace inside table cells -->
     <td><brandName xmlns="">Huntsman</brandName></td>
     <td><origin xmlns="">Bath, UK</origin></td>
       <details xmlns=""><class>Bitter</class><hop>Fuggles</hop>
         <pro>Wonderful hop, light alcohol, good summer beer</pro>
         <con>Fragile; excessive variance pub to pub</con>

6. The Internal Structure of XML Namespaces

6.1 The Insufficiency of the Traditional Namespace

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:

<section><title>Book-Signing Event</title>
  <author title="Mr" name="Vikram Seth" />
  <book title="A Suitable Boy" price="$22.95" /></signing>
  <author title="Dr" name="Oliver Sacks" />
  <book title="The Island of the Color-Blind" price="$12.95" /></signing>

In this example, there are three occurrences of the name title within markup, and the name alone clearly provides insufficient information to allow correct processing by a software module.

Another problematic area comes from the use of "global" attributes, as illustrated by this example, a fragment of an XML document which is to be displayed using a CSS stylesheet:

 <NAME HTML:CLASS="largeSansSerif">Layman, A</NAME>
 <SEAT CLASS="Y" HTML:CLASS="largeMonotype">33B</SEAT>

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.

6.2 XML Namespace Partitions

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.

6.3 Expanded Element Types and Attribute Names

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:

<!-- 1 --> <section xmlns='urn:com:books-r-us'>
<!-- 2 -->   <title>Book-Signing Event</title>
<!-- 3 -->   <signing>
<!-- 4 -->     <author title="Mr" name="Vikram Seth" />
<!-- 5 -->     <book title="A Suitable Boy" price="$22.95" />

The names would expand as follows:
1section <ExpEType type="section" ns="urn:com:books-r-us" /> 
2 title<ExpEType type="title" ns="urn:com:books-r-us" /> 
3 signing<ExpEType type="signing" ns="urn:com:books-r-us" />
4 author<ExpEType type="author" ns="urn:com:books-r-us" /> 
4 title <ExpAName name='title' eltype="author" elns="urn:com:books-r-us" />
4 name <ExpAName name='name' eltype="author" elns="urn:com:books-r-us" />
5 book<ExpEType type="book" ns="urn:com:books-r-us" />
5 title<ExpAName name='title' eltype="book" elns="urn:com:books-r-us" />
5 price<ExpAName name='price' eltype="book" elns="urn:com:books-r-us" />
<!-- 1 --> <RESERVATION xmlns:HTML="http://www.w3.org/TR/REC-html40">
<!-- 2 --> <NAME HTML:CLASS="largeSansSerif">Layman, A</NAME>
<!-- 3 --> <SEAT CLASS="Y" HTML:CLASS="largeMonotype">33B</SEAT>
<!-- 4 --> <HTML:A HREF='/cgi-bin/ResStatus'>Check Status</HTML:A>
<!-- 5 --> <DEPARTURE>1997-05-24T07:55:00+1</DEPARTURE></RESERVATION>

2 NAME<ExpEType type="NAME" />
2 HTML:CLASS <ExpAName name="CLASS" ns=http://www.w3.org/TR/REC-html40 />
3 SEAT<ExpEType type="SEAT" />
3 CLASS<ExpAName name="CLASS" eltype="SEAT">
3 HTML:CLASS<ExpAName name="CLASS" ns="http://www.w3.org/TR/REC-html40" />
4 HTML:A<ExpEType type="A" ns="http://www.w3.org/TR/REC-html40" />
4 HREF<ExpAName name="HREF" eltype="A" elns="http://www.w3.org/TR/REC-html40" />

6.4 Unique Expanded Attribute 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.

7. Conformance

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:

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.


A. Acknowledgements

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.

B. References

IETF (Internet Engineering Task Force) RFC 2141: URN Syntax, ed. R. Moats. May 1997.
Extensible Markup Language (XML) 1.0, eds. Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen. 10 February 1998. Available at http://www.w3.org/TR/REC-xml.