XML Namespaces

Because anyone can invent their own XML tags, combining data from two different sources into one document risks a name collision — two unrelated things that both happen to be called <table>. Namespaces solve this by tying an element name to a unique identifier, so <table> from one vocabulary can never be confused with <table> from another.

The collision problem

Imagine combining furniture data with HTML markup describing that furniture in a single document — both naturally want to use <table>, but for completely different things:

<furniture>
  <table>
    <width>120</width>
  </table>
  <description>
    <table>
      <tr><td>Spec</td><td>Value</td></tr>
    </table>
  </description>
</furniture>

Both <table> elements are perfectly well-formed, but a program processing this document has no way to know that one means "a piece of furniture" and the other means "an HTML data grid" — they're indistinguishable by name alone.

Declaring a namespace

The xmlns attribute declares a namespace, associating a short prefix with a full URI that uniquely identifies that vocabulary:

<furniture xmlns:f="http://example.com/furniture" xmlns:h="http://www.w3.org/1999/xhtml">
  <f:table>
    <f:width>120</f:width>
  </f:table>
  <description>
    <h:table>
      <h:tr><h:td>Spec</h:td><h:td>Value</h:td></h:tr>
    </h:table>
  </description>
</furniture>

Now f:table and h:table are unambiguous — the full, unique name of each element is really its namespace URI plus its local name, and the short prefix (f, h) is just a readable stand-in for that URI within this document.

Default namespaces

If most of a document belongs to one namespace, you can declare it without a prefix, making it the default for any element that doesn't specify one itself:

<book xmlns="http://example.com/books">
  <title>Dune</title>
</book>

Here, both <book> and <title> belong to the http://example.com/books namespace, even though neither uses an explicit prefix.