6 Namensräume in XML

But if I bought a radio and found that it accessed only certain stations and not others, I'd be upset. I suppose I could have a half dozen radios, one for each set of stations. It makes no more sense to have a half dozen computers or different operating systems or browsers for Web access.Das aus [bern99] [bern99]Weaving the Web - The Original Design an Ultimate Destiny of the World Wide Web by its Inventor - The Original Design an Ultimate Destiny of the World Wide Web by its Inventor, Tim Berners-Lee, Mark Fischetti, San Francisco, 1999, HarperSanFrancisco stammende Zitat lautet übersetzt: Wenn ich ein Radio kaufte und herausfände, dass ich nur bestimmte Sender empfangen kann, andere aber nicht, wäre ich sauer. Wahrscheinlich könnte ich ein halbes Dutzend Radios haben, immer eins für ein paar Sender. Es ist nicht sinnvoller, ein halbes Dutzend Rechner oder unterschiedliche Betriebssysteme oder Browser für den Webzugang zu haben.
Tim Berners-Lee

Namensraum ist zwar für Programmierer im objektorientierten Umfeld ein möglicherweise vertrauter Begriff, aber in Webautorenkreisen dürfte der Begriff eher Verwirrung auslösen. Es handelt sich dabei um eine vom W3C im Januar 1999 als Empfehlung verabschiedete Regelung, wie Elemente in XML-Dokumenten zu bezeichnen sind, wenn sie aus unterschiedlichen Zusammenhängen (DTDs) stammen. Ein einfaches Beispiel soll das illustrieren.

<!-- Adresse 1 -->

<adresse>
  <strasse>Schneller Weg</strasse>
  <hausnummer>99</hausnummer>
  <plz>12345</plz>
  <ort>Woauchimmer</ort>
</adresse>

<!-- Adresse 2 -->

<rechner>
  <domain>auchschonweg.de</domain>
  <name>meinrechner</name>
  <adresse>168.111.222.333</adresse>
</rechner>

Wollte man die unterschiedlich gemeinten Adressen in einem Dokument verwenden — und bei technischer Dokumentation wäre das ja zumindest möglich —, wäre völlig unklar, was ein Element adresse beinhalten darf und soll. Weil dieses Problem der Zuordnung von Elementen zu einem Inhaltsmodell beziehungsweise einem Namensraum aus Sicht des Konsortiums unbedingt gelöst werden musste, ist die Empfehlung für XML-Namensräume gleich die erste nach der XML-Syntax gewesen, die in diesem Umfeld verabschiedet wurde. Mittlerweile hat sich das dahinter stehende Konzept so weit durchgesetzt, dass beispielsweise XSLT ohne diese Namensräume kaum denkbar wäre (siehe Kapitel 10).

Ein QName ist aus einem lokalen Teil und einem den Namensraum benennenden Präfix zusammengesetzt

Es geht um Elemente und Attribute. Und es geht darum, wie man diese beiden beschreiben soll, ohne dass Konflikte auftreten, welches Element aus welcher DTD gemeint ist. Dazu hat das W3-Konsortium den so genannten qualifizierenden Namen (QName) eingeführt, der aus einem optionalen Präfix und einem lokalen Namen besteht. Das Präfix bezeichnet den Namensraumteil, der lokale Teil besteht aus dem Element- oder Attributnamen, wie er in der DTD steht. Dazwischen steht ein Doppelpunkt. Innerhalb des Dokuments, in dem diese QNames verwendet werden, muss eine Deklaration stattfinden, die klar macht, dass ein Präfix mit einem bestimmten Namensraum-URI assoziiert ist. Dazu verwendet man ein Attribut: entweder xmlns oder xmlns:. Eines vorweg: Alle Buchstabenfolgen, die mit xml beginnen (auch als Großbuchstaben) sind insofern geschützt, als das W3C sich vorbehält, sie im XML-Umfeld für Spezifikationszwecke zu nutzen.

<html xmlns="http://www.w3.org/TR/REC-html40">
  <body>
    <div class="wild_colours">
      <person xmlns:mensch="http://www.auchschonweg.de/"
        anrede="Frau">
        <mensch:name>
        ...
        </mensch:name>
      </person>
    </div>
  </body>
</html>

In der ersten Zeile des Listings ist dem Element html der Namensraum von HTML 4.0 zugewiesen worden. Das Fehlen des Doppelpunkts bewirkt, dass es sich im Folgenden (= in html und allen in diesem enthaltenen Elementen) per Default um diesen Namensraum handelt, ohne dass das jedesmal notiert werden müsste (zum Beispiel body). Das Element person hingegen — durch xmlns: deklariert — hat der Zeichenkette mensch als Präfix den Wert des folgenden Namensraum-URI zugewiesen, sodass innerhalb von person mit mensch:name die weitere Verwendung dieses Namensraums möglich ist. Nach dem Schließen des Elements person gilt wieder der Default-Namensraum (hier der in html vereinbarte); es sei denn, ein neuer wird zugewiesen.

James Clark hat eine einleuchtende Notation dafür gefunden, wie die Namensraumzugehörigkeit sich darstellen lässt [clark99] [clark99]XML Namespaces, James Clark, 1999, http://www.jclark.com/xmlns.htm. Obiges Listing sähe nach seiner Beschreibung aus wie das folgende:

<{http://www.w3.org/TR/REC-html40}html>
  <{http://www.w3.org/TR/REC-html40}body>
    <{http://www.w3.org/TR/REC-html40}div
        class="wild_colours">
      <{http://www.auchschonweg.de/}person
          anrede="Frau">
        <{http://www.auchschonweg.de/}name>
          ...
        </{http://www.auchschonweg.de/}name>
      </{http://www.auchschonweg.de/}person>
    <{http://www.w3.org/TR/REC-html40}div>
  </{http://www.w3.org/TR/REC-html40}body>
</{http://www.w3.org/TR/REC-html40}html>

Um einem Missverständnis vorzubeugen: Der Namensraum-URI hat keinerlei festgelegte Bedeutung, dass heißt, dass hinter ihm nicht ein Dokument in einer bestimmten Form zu stehen hat. Der URI ist pure Konvention. Dass in der beim W3C vorliegenden HTML-Spezifikation in einem Unterverzeichnis tatsächlich eine DTD zu finden ist, dürfte eher die Ausnahme sein, wie der zweite URI zeigt, denn er verweist lediglich auf eine (hier beliebig gewählte) Website, nicht auf ein Dokument.

Was das Listing in Clarks Notation vielleicht noch deutlicher zeigt als das davor stehende, ist, dass Attribute nicht automatisch den Namensraum des zugehörigen Elements erhalten: anrede="Frau" im obigen Beispiel verfügt über keinen Namensraum. Das gilt auch im Falle eines Default-Namensraums. Soll also das Attribut den Namensraum mensch haben, muss man ihn ihm explizit zuweisen:

<person xmlns:mensch="http://www.auchschonweg.de/"
  mensch:anrede="Frau">

oder

<{http://www.auchschonweg.de/}person
  {http://www.auchschonweg.de/}anrede="Frau"

In manchen Fällen kann es sinnvoll sein, auf einen Default-Namensraum zu verzichten, weil sich dann ein zugewiesenes Präfix verwenden lässt (hier mensch). Denn wenn der Default-Namensraum der von HTML ist, haben Attribute wie class keinen Namensraum.

Elemente können durchaus unterschiedliche Namensräume deklarieren, die man in ihnen verwenden darf:

<html xmlns:html="http://www.w3.org/TR/REC-html40"
    xmlns:mensch="http://www.auchschonweg.de/">
  <html:body>
    <html:div class="wild_colours">
      <mensch:person mensch:anrede="Frau">
        <mensch:name>
        ...
        </mensch:name>
      </mensch:person>
    </html:div>
  </html:body>
</html:html>

Auch hier gilt, dass das Attribut class keinen Namensraum besitzt, während mensch:anrede="Frau" das Attribut mit dem zugewiesenen mensch versieht. Um auch class einen Namensraum zuzuweisen, müsste es html:class="wild_colours" heißen. Beachtenswert ist außerdem, dass Elemente nicht Attribute gleichen Namens enthalten dürfen (also nicht anrede="Frau" anrede="Mrs"). Und Präfixe in unterschiedlichen QNames, die denselben lokalen Teil haben, dürfen nicht auf denselben Namensraum verweisenVergleich dazu auch die Ausführungen zu Attributlisten-Deklarationen in Abschnitt A.3.3 der XMl-Spezifikation im Anhang.. Folgendes ist demnach falsch:

<person xmlns:erstes="http://www.auchschonweg.de/"
    xmlns:mensch="http://www.auchschonweg.de/">
<person mensch:anrede="Frau"
        erstes:anrede="Mrs">
  <mensch:name>
    ...
  </mensch:name>
</mensch:person>

Sowohl das Präfix erstes als auch mensch verweisen auf denselben Namensraum, und der lokale Teil ist mit anrede ebenfalls identisch.

Sitemap

6 Namensräume in XML