Zunächst muss im Start-Tag eines Elements der Namensraum definiert werden. Die Definition wird als Attribut im Start-Tag eines Elements angegeben und hat folgenden Aufbau:

  <MYEL xmlns:präfix=URI>

xmlns ist ein reservierter Attributname für die Definition von Namensräumen. Dieser Zeichenkette folgt eine Zuordnung von einem Präfix zu einem URI. Der URI bezeichnet den Namensraum. Das Präfix fungiert nachfolgend gewissermaßen als Alias für den URI und kann Element- oder Attributnamen vorangestellt werden, um den Namensraum anzugeben.

In einem Start-Tag können auch mehrere Namensräume definiert werden, wie das folgende Beispiel zeigt:

  <MYEL xmlns:nsp1="http://www.cirosec.de/schemas"
        xmlns:nsp2="http://www.dpunkt.de/bibliography">

Wenn eine Applikation nun eine bestimmte DTD erwartet, kennt sie auch den URI, unter dem die DTD »bekannt« ist. Das Präfix dient nur als Ersatz innerhalb des Dokuments und kann abgesehen von folgender Einschränkung beliebig gewählt werden: Das Präfix xml ist reserviert und dient dazu, den Inhalt dem Default-Namensraum zuzuordnen. Sofern kein Namensraum explizit angegeben wurde, wird der Inhalt dem Default-Namensraum zugeordnet, der mit folgender URL assoziiert ist: http://www.w3.org/XML/1998/namespace

Zwei Namensräume gelten als gleich, wenn der URI übereinstimmt, und zwar unabhängig vom Präfix. Der Präfix dient also nur als Platzhalter oder Kurzschreibweise für den URI.

Bei vielen namensraumbezogenen Methoden des DOM-API wird aus diesem Grund die Kombination aus URI und lokalem Namen anstatt von Präfix und lokalem Namen übergeben. Das der URI ausschlaggebend ist und nicht das Präfix sieht man auch am Verhalten einiger dieser Methoden, z. B. der Methode setAttributeNS() der Klasse Element, die ein Element repräsentiert. setAttributeNS() dient zum Setzen oder Ändern eines Attributwerts unter Angabe eines Namensraums. Sie hat drei Parameter:

• den URI,
• einen qualifizierten Namen,
• den Attributwert.

Beim Aufruf der Methode wird nachgeschaut, ob es bereits ein Attribut in dem durch den URI gegebenen Namensraum und den im qualifizierten Namen enthaltenen lokalen Namen gibt. Ist das der Fall, wird der Wert geändert. Das Präfix wird hier bei der Suche gar nicht berücksichtigt.

Falls das Präfix des übergebenen Attributs vorher anders lautete, wird es einfach auf das im qualifizierten Namen übergebene Präfix gesetzt.

Prinzipiell ist der Inhalt und Aufbau des URI ebenfalls beliebig, es sollte nur »weltweite« Eindeutigkeit gewährleistet sein. Von daher bietet es sich oft an, die URL der Organisation voranzustellen, von der die DTD stammt. In diesem Fall ist es aber nicht so, dass diese URL vom XML-Parser oder der XML-Applikation in irgendeiner Weise für einen Schema-Download verwendet wird.

Dieser Sachverhalt ähnelt der Benennung von Paketen bei Java. Die Sprachspezifikation empfiehlt, dem Paketnamen den umgedrehten Domain-Namen voranzustellen, z. B. com.ibm. Auch hier dient diese Konvention nur dazu, Eindeutigkeit zu gewährleisten. Es ist also nicht so, dass der Java-Interpreter versucht, Klassen im Paket com.ibm vom Webserver von ibm.com herunterzuladen.

Oft findet man auch Pakete, die gegen diese Konvention verstoßen und beispielsweise nur den Firmennamen oder andere (hoffentlich) eindeutige Zeichenketten voranstellen.

Wie bereits erwähnt, geht es nur um eine symbolische Unterscheidung innerhalb des Dokuments, es ist nicht erforderlich, dass unter den URIs auch tatsächlich die DTD-Dateien abgelegt werden.