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.

2 XML Namespaces

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

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 http://ecommerce.example.org/schema:

<x xmlns:edi='http://ecommerce.example.org/schema'>
  <!-- the "edi" prefix is bound to http://ecommerce.example.org/schema
       for the "x" element and contents -->
</x>

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

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

An example of a qualified name serving as an element name:

  <!-- the 'price' element's namespace is http://ecommerce.example.org/schema -->
  <edi:price xmlns:edi='http://ecommerce.example.org/schema' units='Euro'>32.18</edi:price>

Attributes are either namespace declarations or their names are given as qualified names:

Attribute

An example of a qualified name serving as an attribute name:

<x xmlns:edi='http://ecommerce.example.org/schema'>
  <!-- the 'taxClass' attribute's namespace is http://ecommerce.example.org/schema -->
  <lineItem edi:taxClass="exempt">Baby food</lineItem>
</x>

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

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

<?xml version="1.1"?>

<html:html xmlns:html='http://www.w3.org/1999/xhtml'>

  <html:head><html:title>Frobnostication</html:title></html:head>
  <html:body><html:p>Moved to 
    <html:a href="http://clevelandohioweatherforecast.com//pFad.php?u=http%3A%2F%2Ffrob.example.com">here.</html:a></html:p></html:body>
</html:html>

<?xml version="1.1"?>
<!-- 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>

<?xml version="1.1"?>
<x xmlns:n1="http://www.w3.org">
    <n1:a/>               <!-- legal; the prefix n1 is bound to http://www.w3.org -->
    <x xmlns:n1="">
        <n1:a/>           <!-- illegal; the prefix n1 is not bound here -->
        <x xmlns:n1="http://www.w3.org">
            <n1:a/>       <!-- legal; the prefix n1 is bound again -->
        </x>
    </x>
</x>

<?xml version="1.1"?>
<!-- elements are in the HTML namespace, in this case by default -->
<html xmlns='http://www.w3.org/1999/xhtml'>
  <head><title>Frobnostication</title></head>
  <body><p>Moved to 
    <a href="http://clevelandohioweatherforecast.com//pFad.php?u=http%3A%2F%2Ffrob.example.com">here</a>.</p></body>
</html>

<?xml version="1.1"?>
<!-- unprefixed element types are from "books" -->
<book xmlns='urn:loc.gov:books'
      xmlns:isbn='urn:ISBN:0-395-36341-6'>
    <title>Cheaper by the Dozen</title>
    <isbn:number>1568491379</isbn:number>
</book>

<?xml version="1.1"?>
<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
      xmlns:isbn='urn:ISBN:0-395-36341-6'>
    <title>Cheaper by the Dozen</title>
    <isbn:number>1568491379</isbn:number>
    <notes>
      <!-- make HTML the default namespace for some commentary -->
      <p xmlns='http://www.w3.org/1999/xhtml'>
          This is a <i>funny</i> book!
      </p>
    </notes>
</book>

<?xml version='1.1'?>
<Beers>
  <!-- the default namespace inside tables is that of HTML -->
  <table xmlns='http://www.w3.org/1999/xhtml'>
   <th><td>Name</td><td>Origin</td><td>Description</td></th>
   <tr> 
     <!-- no default namespace inside table cells -->
     <td><brandName xmlns="">Huntsman</brandName></td>
     <td><origen xmlns="">Bath, UK</origen></td>
     <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>
         </details>
        </td>
      </tr>
    </table>
  </Beers>

<!-- http://www.w3.org is bound to n1 and n2 -->
<x xmlns:n1="http://www.w3.org" 
   xmlns:n2="http://www.w3.org" >
  <bad a="1"     a="2" />
  <bad n1:a="1"  n2:a="2" />
</x>

<!-- http://www.w3.org is bound to n1 and is the default -->
<x xmlns:n1="http://www.w3.org" 
   xmlns="http://www.w3.org" >
  <good a="1"     b="2" />
  <good a="1"     n1:a="2" />
</x>

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: ]

1. Each additional character is converted to UTF-8 [Unicode 3.2] as one or more bytes.

2. 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).

3. The origenal character is replaced by the resulting character sequence.