Namespace Kurzanleitung

Als XML Dialekt, verfügt SVG über einen eigenen Namespace. Es ist wichtig, Konzept und Anwendung von Namespaces zu verstehen, will man SVG Inhalte selber erstellen. Der Veröffentlichung von Firefox 1.5 vorausgehende Versionen von SVG zollten diesen kaum Beachtung. Namespaces sind jedoch wichtig für Multi-XML Dialekt unterstützende User Agents wie z.B. Gecko-basierte Browser, die sehr streng damit verfahren.
Nehmen Sie sich die Zeit, Namespaces zu verstehen. Es wird Ihnen allerhand Kopfschmerzen in der Zukunft ersparen.

Hintergrund

Es ist lange schon ein Ziel des W3C, die gleichzeitige Verwendung verschiedener Typen XML-basierter Inhalte im selben XML-Dokument zu ermöglichen.
So können z.B. SVG and MathML direkt in ein XHTML-basiertes wissenschaftliches Dokument eingefügt werden. Die Möglichkeit, verschiedenartige Inhalte zu mischen, bietet viele Vorteile, setzte aber die Lösung sehr konkreter Probleme voraus.

Selbstverständlich beschreibt jeder XML Dialekt die Bedeutung seiner Markup Tag Bezeichnungen in einer eigenen Spezifikation. Das Problem beim Mischen von Inhalten aus verschiedenen XML-Dialekten im selben XML-Dokument ist, dass Tags aus dem einen Dialekt auch im anderen definiert sein können. So gibt es z.B. sowohl in XHTML wie auch in SVG das <title> Tag. Wie soll der User Agent die beiden unterscheiden?
Woran erkennt der User Agent überhaupt die Bedeutung von XML Inhalten oder ob es sich um für ihn bedeutungslose Tags aus einer beliebigen XML-Datei handelt?

Man könnte fälschlicherweise annehmen, dass er dies anhand der DOCTYPE Deklaration erkennt. DTDs wurden jedoch nicht mit Blick auf gemischte Inhalte entworfen und Versuche, DTDs für gemischte Inhalte zu erstellen, sind letztlich gescheitert.

XML und einige XML Dialekte (einschließlich SVG) erfordern keine DOCTYPE Deklaration und SVG 1.2 wird nicht einmal eine haben. Der Umstand, daß DOCTYPE Deklarationen meist dem Typ des Seiteninhalts entsprechen, ist rein zufällig. DTDs werden zur Validierung, nicht zur Identifizierung von Inhalten benötigt. User Agents, die schummeln und XML-Inhalte per DOCTYPE Deklaration identifizieren, verursachen Probleme.

Korrekterweise sollte der XML-Inhalt dem User Agent mitteilen, welchem Dialekt Tag Bezeichnungen angehören, indem den Tags explizite Namespace Declarations zugewiesen werden.

Namensraumzuweisung

Wie sehen Namensraumzuweisungen (Namespace Declarations) aus und wie werden sie konkret verwendet? Hier ein Beispiel:

<svg xmlns="https://www.w3.org/2000/svg">
  <!-- weitere tags folgen... -->
</svg>

Die Namespace Deklaration ist durch das Attribut xmlns gegeben. Dieses Attribut besagt, daß das <svg> Tag und seine Kinder-Tags zu dem XML-Dialekt gehören, der dem Namespace 'https://www.w3.org/2000/svg' entspricht, hier eben SVG.
Die Namespace Deklaration hat nur einmal zu erfolgen und zwar im Ursprungs-Tag (root tag). Diese Deklaration definiert den Namespace als Voreinstellung, sodass der User Agent weiß, daß alle dem <svg> Tag untergeordneten Tags demselben Namespace angehören. User Agents prüfen den Namespace um herauszufinden, ob sie mit dem enthaltenen Markup umgehen können.

Der Namespace Name (sprich das xmlns Attribut) ist ein einfacher String, sodass der Umstand, daß der SVG Namespace wie ein URI aussieht, nicht weiter wichtig ist. URIs werden allgemein benutzt, weil sie einzigartig sind und nicht, um irgendetwas zu verlinken. URIs werden tatsächlich so häufig verwendet, dass allgemein der Begriff "Namespace URI" gebräuchlicher ist als "Namespace Name".

Umdeklarierung eines vorgegebenen Namensraums

Wenn alle Nachkommen des Ursprungs-Tags automatisch dem dadurch vorgegebenen Namespace angehören, wie streut man dann Inhalte aus einem anderen Namespace ein? Die einfache Antwort lautet, man redefiniert den Vorgabe-Namespace. So zum Beispiel:

<html xmlns="https://www.w3.org/1999/xhtml">
  <body>
    <!-- some XHTML tags here -->
    <svg xmlns="https://www.w3.org/2000/svg" width="300px" height="200px">
      <!-- some SVG tags here -->
    </svg>
    <!-- some XHTML tags here -->
  </body>
</html>

In diesem Beispiel deklariert das xmlns Attribut des ursprünglichen <html> Tags den vorgegebenen Namensraum als XHTML. Somit werden dieses und alle nachkommenden Tags als XHTML intepretiert, mit Ausnahme des <svg> Tags. Das <svg> Tag hat sein eigenes xmlns Attribut und deklariert somit den ursprünglichen Namensraum um, was bewirkt, dass dieses Tag mitsamt Nachkommen (sofern diese nicht ihrererseits Namensräume erneut umdeklarieren) vom User Agent als SVG erkannt wird.

Na also, war doch nicht schwer.

Namensraumpräfixe deklarieren

XML-Dialekte definieren außer eigenen Tags auch eigene Attribute. Ursprünglich gehören Attribute zu keinem Namensraum und sind nur deshalb einzigartig, weil sie einem Element mit einzigartigem, eindeutigem Namen zugeordnet sind.

Manchmal ist es jedoch nötig, Attribute zu definieren, die in vielen verschiedenen Elementen wiederverwendbar sein müssen und trotzdem dasselbe Attribut verkörpern, egal von welchem Element sie verwendet werden. Ein besonders gutes Beispiel hierfür ist das von der XLink Spezifikation definierte href Attribut. Dieses Attribut wird allgemein auch von anderen XML-Dialekten verwendet zum Verlinken externer Quellen. Aber wie teilt man dem User Agent mit, zu welchem XML-Dialekt das Attribut gehört, z.B. XLink? Betrachten wir dazu folgendes Beispiel:

<svg xmlns="https://www.w3.org/2000/svg"
     xmlns:xlink="https://www.w3.org/1999/xlink">
  <script xlink:href="cool-script.js" type="text/ecmascript"/>
</svg>

Hier sehen wir das etwas merkwürdige Attribut xmlns:xlink. Vom xmlns Bestandteil ist abzuleiten, daß hier eine weitere Namensraumdeklaration vorliegt. Allerdings wird hier nicht der Vorgabenamensraum festgelegt, sondern der Namensraum für ein "Namensraum Präfix". In diesem Fall wurde das Präfix xlink (der zweite Teil des Attributs) gewählt, um damit dem User Agent etwas über Attribute aus dem Namensraum XLink mitzuteilen.

Der Begriff Namensraumpräfix deutet bereits an, dass damit Attribut- und Tag-Bezeichnungen in Ihrer Bedeutung eingegrenzt werden (ähnlich wie Vorsilben bzw. Präfixe die Bedeutung von Begriffen in menschlicher Sprache modifizieren). Dies geschieht indem das Namensraumpräfix und ein Doppelpunkt dem Attributnamen vorangestellt werden, wie im obigen Beispiel beim <script> Tag zu sehen. Das erklärt dem User Agent, daß dieses spezielle Attribut zu dem Namensraum gehört, der mit dem Namenraumpräfix XLink deklariert wurde, und ein Attribut ist, das mit derselben Bedeutung in anderen Tags verwendet werden kann.

Es ist ein XML Fehler, ein Präfix zu benutzen, das nicht an einen Namenraum gebunden wurde. Die mit dem xmlns:xlink Attribut erzeugte Bindung im obigen Beispiel ist unverzichtbar, wenn das xlink:href Attribut keinen Fehler hervorrufen soll. Dieses XLink Attribut wird regelmäßig in SVG benutzt, u.a. mit <a>, <use> und <image> Tags. Darum ist es eine gute Idee, die XLink Deklaration in allen Dokumenten miteinzubeziehen.

Es ist nützlich zu wissen, dass Namensraumpräfixe auch als Tag Namen genutzt werden können. Dies vermittelt dem User Agent die Zugehörigkeit eines bestimmten Tags (in diesem Fall jedoch nicht seine Kinder!) zu dem Namensraum des Präfixes. Dieses Wissen erspart einige Verwirrung, falls man Markup wie dem folgenden begegnet:

<html xmlns="https://www.w3.org/1999/xhtml" 
      xmlns:svg="https://www.w3.org/2000/svg">
  <body>
    <h1>SVG embedded inline in XHTML</h1>
    <svg:svg width="300px" height="200px">
      <svg:circle cx="150" cy="100" r="50" fill="#ff0000"/>
    </svg:svg>
  </body>
</html>

Weil hier das Namensraumpräfix verwendet wurde für das <svg:svg> Tag und sein Kind <svg:circle>, war es nicht nötig, den Standardnamensraum erneut zu deklarieren. Allgemein ist es jedoch besser, den Standardnamensraum erneut auszuweisen als eine Menge Tags derart mit Präfixen zu versehen.

Scripting in namespaced XML

Namespaces affect not only markup, but also scripting. If you write scripts for namespaced XML such as SVG, read on.

The DOM Level 1 recommendation was created before the original Namespaces in XML recommendation was released; therefore, DOM1 isn't namespace aware. This causes problems for namespaced XML such as SVG. To resolve these problems, DOM Level 2 Core added namespace aware equivalents of all the applicable DOM Level 1 methods. When scripting SVG, it is important to use the namespace aware methods. The table below lists the DOM1 methods that shouldn't be used in SVG, along with their equivalent DOM2 counterparts that should be used instead.

DOM1 (don't use)	DOM2 (use these instead!)
createAttribute	createAttributeNS
createElement	createElementNS
getAttributeNode	getAttributeNodeNS
getAttribute	getAttributeNS
getElementsByTagName	getElementsByTagNameNS (also added to Element)
getNamedItem	getNamedItemNS
hasAttribute	hasAttributeNS
removeAttribute	removeAttributeNS
removeNamedItem	removeNamedItemNS
setAttribute	setAttributeNS
setAttributeNode	setAttributeNodeNS
setNamedItem	setNamedItemNS

The first argument for all the DOM2 namespace aware methods must be the namespace name (also known as the namespace URI) of the element or attribute in question. For SVG elements this is 'https://www.w3.org/2000/svg'. However, note carefully: the Namespaces in XML 1.1 recommendation states that the namespace name for attributes without a prefix does not have a value. In other words, although the attributes belong to the namespace of the tag, you do not use the tag's namespace name. Instead, you must use null as the namespace name for unqualified (prefixless) attributes. So, to create an SVG rect element using document.createElementNS(), you must write:

document.createElementNS('https://www.w3.org/2000/svg', 'rect');

But to retrieve the value of the x attribute on an SVG rect element, you must write:

rect.getAttributeNS(null, 'x');

Note that this isn't the case for attributes with a namespace prefix (attributes that don't belong to the same XML dialect as the tag). Attributes such as the xlink:href attribute require the namespace name that was assigned to that prefix (https://www.w3.org/1999/xlink for XLink). Hence to get the value of the xlink:href attribute of an <a> element in SVG you would write:

elt.getAttributeNS('https://www.w3.org/1999/xlink', 'href');

For setting attributes that have a namespace, it is recommended (but not required) that you also include their prefix in the second argument so that the DOM can later be more easily converted back to XML (if for instance you want to send it back to the server). For example:

elt.setAttributeNS('https://www.w3.org/1999/xlink', 'xlink:href', 'otherdoc.svg');

As a final example, here's a demonstration of how you should dynamically create an <image> element using script:

var SVG_NS = 'https://www.w3.org/2000/svg';
var XLink_NS = 'https://www.w3.org/1999/xlink';
var image = document.createElementNS(SVG_NS, 'image');
image.setAttributeNS(null, 'width', '100');
image.setAttributeNS(null, 'height', '100');
image.setAttributeNS(XLink_NS, 'xlink:href', 'flower.png');

Conclusion

Make sure you always declare the namespaces you use in your XML files. If you don't, user agents such as Firefox won't recognize your content and will simply show the XML markup or inform the user that there's an error in the XML. It's a good idea to use a template that includes all the commonly used namespace declarations when creating new SVG files. If you don't already have one, make one up starting with the following code:

<svg xmlns="https://www.w3.org/2000/svg"
     xmlns:xlink="https://www.w3.org/1999/xlink">
</svg>

Even if you don't use all those namespaces in a particular document, there's no harm in including the namespace declarations. It may save you from some annoying errors if you end up adding content from one of the unused namespaces at a later date.

A full example

For a full example see SVG: Namespaces Crash Course: Example.