Namespaces für komplexere XML-Dokumente definieren
https://bildung.social/@oerinformatik/111986750551090101
https://oer-informatik.de/xml-namespaces
XML, Namespace, Namensraum, xmlns, Präfix, Default-Namespace, URI, Local Part, DTD, Wohlgeformtheit
tl/dr; (ca. 9 min Lesezeit): XML-Namensräume bieten eine Möglichkeit, dass Elemente gleichen Namens für unterschiedliche Inhalte stehen können. Das kann vor allem bei allgemeinen Bezeichnern wie
<name/>relevant sein, die dann mit Präfix notiert werden:<person:name />,<firma:name />[AI-Assisted]. (Zuletzt geändert am 27.10.2026)
Dieser Artikel ist Bestandteil einer Serie zu den XML-Grundlagen:
Vorab: Datenaustauschformate: CSV, XML und JSON vergleichen mit zugehörigen Übungsaufgaben
Teil 1: Die Auszeichnungssprache Extensible Markup Language (XML) mit zugehörigen Übungsaufgaben
Teil 2: Valide XML-Dokumente gegen eine Document-Type-Definition erstellen mit zugehörigen Übungsaufgaben
Teil 4: Die Struktur von XML-Dokumenten gegen ein Schema validieren
Teil 5: Datentypen-Definitionen eines XML-Schema zur Validierung nutzen
Übungsaufgaben zur ganzen Serie: Übungsaufgaben zu XML: Wohlgeformtheit, Gültigkeit, DTD und XSD
Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.
Nach Durchlesen des Artikels kann ich…
… Namespaces für XML-Elemente und Attribute an eine URI binden und deklarieren,
… Namespaces an XML-Elemente und Attribute über Präfixe notieren,
… default Namespaces festlegen,
… zuordnen, zu welchen Namespaces Elemente und Attribute gehören,
… beurteilen, welche Attribute nach Berücksichtigung der Namespaces einzigartig (und damit wohlgeformt) sind.
Wenn bei diesen Erläuterungen zu XML-Namespaces Fragen offen bleiben oder Du tiefer in das Thema einsteigen willst, ist der Standard zu Namespaces in XML neben dem XML-Standard 1.0 die erste Adresse für weitere Recherchen.
Die Ausgangsproblematik mit doppelten Elementnamen
Komplexere XML-Dokumente können aus unterschiedlichen Dateien kombiniert werden. Hierbei kann es bei großen XML-Dokumenten vorkommen, dass in unterschiedlichen Bereichen Elemente gleichen Namens existieren. Das wird problematisch, wenn diese einen unterschiedlichen Aufbau haben müssen.
Diese Problematik will ich am Beispiel eines Telefon-Einzelverbindungsnachweises (Anhang einer Telefonrechnung) zeigen. Darin befinden sich Daten aus unterschiedlichen Quellen:
die Unternehmenskontaktdaten aus der Support-Datenbank,
die Anschlussnummer aus der Kundendatenbank
und die Verbindungsdaten aus dem Abrechnungssystem.
Alle verarbeiten Telefonnummern in unterschiedlichen Kontexten. Es kann also gefordert sein, dass ein <telefonnummer />-Element in einem Dokument für die Einzelabrechnung von Verbindungsdaten in verschiedenen Bereichen unterschiedlich aufgebaut sein muss:
Im Absender-Abschnitt soll die Telefonnummer die Kontaktdaten des Supports übergeben, also eine einfache Nummer als Elementeinhalt.
Im Abschnitt mit den Kundendaten dient die Telefonnummer dazu, den Kundenanschluss zu identifizieren. Dazu muss z.B. identifiziert werden, was die Hauptnummer des Anschlusses ist (im Beispiel über ein Attribut).
Im Einzelverbindungs-Bereich dient sie dazu, den korrekten Tarif auszuwählen. Hierfür werden internationale und nationale Vorwahl gesondert ausgewiesen.
Die Szenarien sind etwas konstruiert, aber ich hoffe, der Punkt wird klar. Für ein solches Beispiel könnten wir keine DTD ausfertigen, da unterschiedliche Formate für das <telefonnummer/>-Element erwartet würden:
<einzelverbindungsnachweis>
<briefkopf>
<firma>Deutsche Telefon GmbH</firma>
<support>
<name>Herr Firstlevel</name>
<telefonnummer>0800 12345-67</telefonnummer>
</support>
</briefkopf>
<kunde>
<anschluss>
<telefonnummer art="main">030 123456-78</telefonnummer>
<telefonnummer art="">030 123456-78</telefonnummer>
<telefonnummer art="fax">030 123456-78</telefonnummer>
</anschluss>
</kunde>
<verbindungen>
<verbindung>
<telefonnummer>
<international>+49</international>
<national>030</national>
<anschluss>12345678</anschluss>
</telefonnummer>
<zeitVon>03.02.2024 11:24:05</zeitVon>
<zeitBis>03.02.2024 11:26:20</zeitBis>
<dauer>02:15</dauer>
<tarif>flat</tarif>
</verbindung>
</verbindungen>
</einzelverbindungsnachweis>Ein Weg, das Problem zu lösen, wäre, die Elemente unterschiedlich zu benennen. Das kann aber an anderer Stelle zu Inkompatibilitäten führen.
Namespace-Deklarationen
Damit für jeden Bereich gesonderte Regeln für Elemente angewendet werden können, wurden in XML Namespaces eingeführt: Den Elementnamen wird ein mit Doppelpunkt getrenntes Präfix vorangestellt (z.B. <s:telefonnummer />), der alte Elementname wird dann local part genannt (hier: telefonnummer).
Diese Präfixe werden einmal über ein Namespace-Attribut xmlns definiert, in dem ihnen ein eindeutiger Identifier (URI) zugewiesen wird, z.B. xmlns:s="http://oer-informatik.de/ns/support". Häufig wird als URI eine Internetadresse (URL) verwendet, aber auch andere eindeutige Bezeichner (z.B. ISBN oder andere URNs) wären denkbar. Die URI soll für den Namensraum eindeutig und dauerhaft sein und liegt üblicherweise im Einflussbereich (Domäne) derjenigen, die das XML-Format festlegen. Weitere Funktionen übernimmt die URI nicht. Falls eine URL gewählt wurde, müssen dort also keinerlei Informationen hinterlegt sein.
Für die drei Bereiche aus dem Beispiel könnten wir also drei Namespaces definieren, die alle über ein anders strukturiertes <telefonnummer />-Element verfügen.
<einzelverbindungsnachweis
xmlns:s="http://oer-informatik.de/ns/support"
xmlns:k="http://oer-informatik.de/ns/kunde"
xmlns:v="http://oer-informatik.de/ns/verbindung">
<!-- ... -->
<s:telefonnummer>0800 12345-67</s:telefonnummer>
<!-- ... -->
<k:telefonnummer art="main">030 123456-78</k:telefonnummer>
<!-- ... -->
<v:telefonnummer>
<v:international>+49</v:international>
<v:national>030</v:national>
<v:anschluss>12345678</v:anschluss>
</v:telefonnummer>
<!-- ... -->
</einzelverbindungsnachweis >Die Namensräume gelten für alle Unterelemente der Elemente, in denen sie definiert wurden (und für dieses Element bereits auch). Wie im obigen Beispiel können alle Namensräume im Rootelement deklariert werden (die komplette Datei findet sich hier).
Namespaces müssen nicht im Root-Element angegeben werden, sondern können auch dezentral in dem ersten Element deklariert werden, für das der Namensraum gelten soll (komplettes Beispiel hier):
<s:einzelverbindungsnachweis xmlns:s="http://oer-informatik.de/ns/support">
<s:briefkopf>
<!-- ... -->
</s:briefkopf>
<k:kunde xmlns:k="http://oer-informatik.de/ns/kunde">
<k:anschluss> <!-- ... --> </k:anschluss>
</k:kunde>
<v:verbindungen xmlns:v="http://oer-informatik.de/ns/verbindung">
<v:verbindung> <!-- ... --> </v:verbindung>
</v:verbindungen>
</s:einzelverbindungsnachweis>Namespaces in der Document Type Definition einbinden
Durch die Integration der Namespaces ist es möglich, für jedes der Elemente mit identischem local part eine eigene Elemente-Deklaration in der DTD festzulegen (komplette DTD jeweils in den verlinkten XML-Dateien):
<!-- ... -->
<!ELEMENT s:telefonnummer (#PCDATA)>
<!-- ... -->
<!ELEMENT k:telefonnummer (#PCDATA)>
<!ATTLIST k:telefonnummer art CDATA #IMPLIED>
<!-- ... -->
<!ELEMENT v:telefonnummer (v:international, v:national, v:anschluss)>
<!ELEMENT v:international (#PCDATA)>
<!ELEMENT v:national (#PCDATA)>
<!ELEMENT v:anschluss (#PCDATA)>Eine DTD kennt selbst keine Namensräume: Für sie ist das Präfix fester Bestandteil des Namens, s:telefonnummer ist einfach ein anderer Name als telefonnummer. Auch die xmlns:…-Attribute sind für die DTD gewöhnliche Attribute und müssen deklariert sein, damit das Dokument gültig ist – am einfachsten mit festem Wert:
<!ATTLIST einzelverbindungsnachweis
xmlns:s CDATA #FIXED "http://oer-informatik.de/ns/support">Verwendet ein Dokument für dieselbe URI ein anderes Präfix (z. B. xmlns:x), ist es gegen diese DTD ungültig („No declaration for attribute xmlns:x“), obwohl es für einen namensraumbewussten Parser dasselbe bedeutet.
Default-Namensräume
Es kann ein default Namensraum deklariert werden, bei dem kein Präfix angegeben wird (xmlns="http://oer-informatik.de/ns/support"). Diesem default Namensraum gehören dann alle enthaltenen (Unter-)Elemente an, die nicht per Präfix einem anderen Namensraum zugeordnet wurden. Die zugehörigen Attribute gehören ihm jedoch nicht an, was v.a. eine Rolle spielt, wenn es darum geht, ob Attribute eindeutige Namen haben. (Komplettes Beispiel hier)
<einzelverbindungsnachweis xmlns="http://oer-informatik.de/ns/support">
<briefkopf>
<!-- ... -->
</briefkopf>
<k:kunde xmlns:k="http://oer-informatik.de/ns/kunde">
<!-- ... -->
</k:kunde>
<v:verbindungen xmlns:v="http://oer-informatik.de/ns/verbindung">
<!-- ... -->
</v:verbindungen>
</einzelverbindungsnachweis>Wer tiefer einsteigen will: eine kleine Kopfnuss
Das kann zu etwas verzwickten Konstellationen führen, insbesondere dann, wenn Namensräume auf die gleiche URI zeigen. Wir betrachten mal folgendes Beispiel, in dem ein Bereich ohne Namensraum, ein Bereich mit default Namensraum und zwei Bereiche mit zwei zusätzlichen Namensräumen enthalten sind. Die folgende XML-Datei ist nicht wohlgeformt (ein Parser mit Namespace-Unterstützung lehnt sie ab), wir werden versuchen herauszufinden, warum.
<keinNamensraum>
<defautlNamensraum xmlns="http://oer-informatik.de/ns/default">
<nsZeigtAufDefault xmlns:ns="http://oer-informatik.de/ns/default"
xmlns:nn="http://oer-informatik.de/ns/default">
<a data="1"></a>
<ns:a data="1" ns:data="1"></ns:a>
<nn:a data="1" ns:data="1" nn:data="1"></nn:a>
</nsZeigtAufDefault>
<nsZeigtWoandersHin xmlns:ns="http://oer-informatik.de/ns/woanders"
xmlns:nn="http://oer-informatik.de/ns/default">
<a data="1"></a>
<ns:a data="1" ns:data="1"></ns:a>
<nn:a data="1" ns:data="1" nn:data="1"></nn:a>
</nsZeigtWoandersHin>
<a data="1"></a>
</defautlNamensraum>
<a data="1"></a>
</keinNamensraum> Zunächst sieht alles wohlgeformt aus: auch alle Attribute haben über die Namensräume eindeutige Namen. Wenn wir mal farblich sichtbar machen, zu welchen Namensräumen die einzelnen Elemente und Attribute gehören, sieht es erstmal gut aus:
Alle Attribute gehören zu unterschiedlichen Namensräumen, das scheint also wohlgeformt zu sein.
Wenn wir jetzt aber betrachten, dass jeder Namensraum nur ein Alias ist auf eine URI und wir markieren, welche Attribute und Elemente zu welcher URI gehören, wird das Problem sichtbar:
Der Knackpunkt ist jeweils die Zeile
<nn:a data="1" ns:data="1" nn:data="1"></nn:a>Diese verhält sich im <nsZeigtWoandersHin />-Element anders als im <nsZeigtAufDefault />-Element. Da alle data-Attribute ohne Präfix keinem Namensraum angehören (auch nicht dem Default-Namensraum), sind diese schon mal einzigartig. Aber die Präfixe nn und ns sind ja nur Platzhalter für die jeweiligen URI - und die zeigen im <nsZeigtAufDefault />-Element auf die gleiche URI. Somit sind in diesem Fall ns:data und nn:data beide Attribute mit identischem local name im gleichen Namensraum - was in einem wohlgeformten XML-Dokument nicht sein darf.
Leitfragen
- Welches Problem lösen XML-Namensräume?
Werden Daten aus unterschiedlichen Quellen in einem XML-Dokument kombiniert, können Elemente gleichen Namens (z. B. telefonnummer) unterschiedlich aufgebaut sein müssen. Eine DTD kann für einen Elementnamen aber nur ein Inhaltsmodell festlegen; Namensräume machen gleichnamige Elemente unterscheidbar – siehe Abschnitt „Die Ausgangsproblematik mit doppelten Elementnamen“.
- Wie deklarierst Du einen Namensraum, und welche Aufgabe hat die URI dabei?
Mit dem Attribut xmlns:präfix="URI", z. B. xmlns:s="http://oer-informatik.de/ns/support", bindest Du ein Präfix an eine URI. Die URI ist nur ein eindeutiger Bezeichner des Namensraums; ist sie eine URL, muss dort nichts abrufbar sein – siehe Abschnitt „Namespace-Deklarationen“.
- Wie ordnest Du ein Element über ein Präfix einem Namensraum zu, und wo gilt eine Deklaration?
Du stellst dem Elementnamen (local part) das Präfix mit Doppelpunkt voran, z. B. <k:telefonnummer>. Die Deklaration gilt für das Element, in dem sie steht, und alle seine Unterelemente; sie kann zentral im Wurzelelement oder dezentral im ersten betroffenen Element stehen – siehe Abschnitt „Namespace-Deklarationen“.
- Was ist ein Default-Namensraum, und welche Elemente und Attribute gehören ihm an?
Ein Default-Namensraum wird ohne Präfix mit xmlns="URI" deklariert. Ihm gehören alle enthaltenen Elemente ohne Präfix an; Attribute ohne Präfix gehören dagegen keinem Namensraum an, auch nicht dem Default-Namensraum – siehe Abschnitt „Default-Namensräume“.
- Wie legst Du in einer DTD unterschiedliche Regeln für Elemente mit gleichem local part fest?
Du deklarierst jedes Element mit seinem Präfix als eigenes Element, z. B. <!ELEMENT s:telefonnummer (#PCDATA)> und <!ELEMENT v:telefonnummer (v:international, v:national, v:anschluss)>. Für die DTD ist das Präfix fester Bestandteil des Namens – siehe Abschnitt „Namespaces in der Document Type Definition einbinden“.
- Wann sind zwei Attribute mit unterschiedlichen Präfixen trotzdem nicht eindeutig?
Wenn beide Präfixe an dieselbe URI gebunden sind und die Attribute denselben local name haben, z. B. ns:data und nn:data mit ns und nn auf derselben URI. Dann stehen zwei gleiche Attribute im selben Namensraum, und das Dokument ist nicht wohlgeformt – siehe Abschnitt „Wer tiefer einsteigen will: eine kleine Kopfnuss“.
Links und weitere Informationen
Infos von w3schools zu XML
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Namespaces für komplexere XML-Dokumente definieren” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/xml-namespaces veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/datenformate/xml. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 27.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
