# 16 XML Sicherlich mag es Ausnahmen geben, aber in fast allen Anwendungen spielen Daten eine eminent wichtige Rolle: Denken Sie nur an Datenbanken, Textdokumente oder die Tabellen eines Kalkulationsprogramms. In der Vergangenheit war es bei den Softwareunternehmen üblich, eigene, proprietäre Formate zur Datenspeicherung zu entwickeln. Dabei mag die Bindung der Kunden an ein bestimmtes Produkt ein ganz wesentlicher Gedanke gewesen sein. Das Thema dieses Kapitels ist XML sowie die XML-Basisklassen des .NET Frameworks. XML (Extensible Markup Language) hat sich zu einem wichtigen Standard entwickelt, um Daten auszutauschen. Viele Anwendungen tauschen gegenseitig Daten via XML aus, Webservices und RSS-Feeds basieren grundlegend auf XML. Auch innerhalb des .NET Frameworks gibt es kaum einen Bereich, in dem XML keine Rolle spielt: XML wird in Konfigurationsdateien verwendet, die WPF (Windows Presentation Foundation) baut auf XML auf und ebenso ADO.NET – um nur einige Beispiele zu nennen. ## 16.1 XML-Dokumente XML ist eine Spezifikation, die es ermöglicht, Daten im ASCII-Format zu beschreiben. ASCII ist auch der kleinste gemeinsame Nenner aller Plattformen, denn ASCII ist ein universelles Format, das von jeder Plattform verstanden wird. Sie können XML-Dokumente in jedem beliebigen Texteditor öffnen, ändern und die Änderungen speichern. Grundsätzlich ist demnach also keine spezielle Software für XML erforderlich. XML-Dokumente sind somit auch plattformunabhängig. Auf den ersten Blick sehen XML-Dokumente, die als Datei gespeichert die Dateierweiterung .xml haben, HTML-Dokumenten sehr ähnlich. Es gibt auch eine Reihe von Gemeinsamkeiten zwischen HTML und XML. Genauso wie in HTML verwendet XML Tags und Attribute. In HTML ist die Bedeutung aller Tags und Attribute genau festgelegt. Das ist bei XML nicht der Fall, denn um die von XML dargestellten Daten zu beschreiben, sind in XML keine Tags fest vorgeschrieben. Der Entwickler einer Anwendung kann die Namen der Tags, deren Schreibweise, die Häufigkeit des Auftretens und auch die Bedeutung selbst festlegen. Grundsätzlich muss er sich dabei an keine inhaltlichen Vorgaben halten. Nachfolgend sehen Sie ein typisches XML-Dokument. In diesem sind verschiedene Tags definiert: Personen, Person, Vorname usw. Das Dokument beschreibt die privaten Daten einer Person. Dieses Dokument könnte aber auch die Daten von x-beliebig vielen Personen im Dokument beschreiben.
    <?xml version="1.0" encoding="utf-8" ?>
    <Personen>
      <Person>
        <Vorname>Manfred</Vorname>
        <Zuname>Fischer</Zuname>
        <Alter>45</Alter>
        <Adresse Ort="Berlin" Strasse="Bahnhofstr. 34"></Adresse>
      </Person>
    </Personen>
### 16.1.1 Wohlgeformte und gültige XML-Dokumente Bei aller Freizügigkeit hinsichtlich Struktur und Bezeichnung der Elemente innerhalb eines XML-Dokuments sind dennoch einige Regeln zu beachten, die die sogenannte Wohlgeformtheit beschreiben. XML ist nicht so freizügig wie HTML. Beispielsweise müssen Sie die Groß-/Kleinschreibung der Tags exakt beachten, was in HTML nicht erforderlich ist. In HTML können Sie vergessen, das ausleitende Tag zu definieren, ohne dass Ihnen der Browser das übelnehmen wird – zumindest in vielen Fällen. In XML hingegen ist ein ausleitendes Tag ein absolutes Muss. Den XML-spezifischen Regeln werden wir uns später noch eingehend widmen. Ein XML-Dokument, das die XML-Regeln einhält, gilt als wohlgeformt. Ein wohlgeformtes XML-Dokument ist syntaktisch fehlerfrei nach den Vorschriften von XML gestaltet. Da die Tags und deren Reihenfolge grundsätzlich frei wählbar sind, bedeutet das folglich aber auch, dass die Struktur eines XML-Dokuments nicht klar definiert ist. Betrachten Sie dazu das Beispiel oben. Sie können das Tag <Personen></Personen> auch durch <Menschen></Menschen> ersetzen oder auf das Tag <Zuname></Zuname> verzichten. Dennoch ist das XML-Dokument weiterhin wohlgeformt, weil es den sprachlichen Regeln von XML entspricht. Sie können es sich sogar im Internet Explorer anzeigen lassen, denn der integrierte XML-Parser sieht keine Verletzung der Wohlgeformtheit. Grundsätzlich spielen die Struktur eines XML-Dokuments, die Bezeichnung der Tags sowie deren Reihenfolge und auch die Häufigkeit des Auftretens der Elemente hinsichtlich der Wohlgeformtheit keine Rolle. Die beiden folgenden Personenbeschreibungen gelten gleichermaßen als wohlgeformt, obwohl die Angaben Vorname und Zuname bei der zweiten Person fehlen.
    <?xml version="1.0" encoding="utf-8" ?>
    <Personen>
      <Person>
        <Vorname>Manfred</Vorname>
        <Zuname>Fischer</Zuname>
        <Alter>45</Alter>
        <Adresse Ort="Berlin" Strasse="Bahnhofstr. 34"></Adresse>
      </Person>
      <Person>
        <Alter>23</Alter>
        <Adresse Ort="Aachen" Strasse="Neustr. 1"></Adresse>
      </Person>
    </Personen>
Aber was ist, wenn die Angabe von Zuname und Vorname einer Person zwingend erforderlich ist? Kann eine Software hier noch die Elemente korrekt interpretieren und verarbeiten? Was Sie benötigen, ist eine Möglichkeit, die über die Wohlgeformtheit hinausgeht und bestimmte Regeln (Einschränkungen) durchsetzt, die auf das Dokument angewendet werden. Solche Regeln können einem XML-Dokument vorschreiben, welche Elemente es enthalten muss, sie können die Anordnung der Elemente und deren Häufigkeit vorschreiben und darüber hinaus sogar, von welchem Datentyp die beschriebenen Werte sein müssen. Eine solche Regel könnte bei dem oben gezeigten XML-Dokument beispielsweise durchsetzen, dass jedes Element Person genau ein untergeordnetes Element Vorname und Zuname haben muss. Die Struktur eines XML-Dokuments und die auf das XML-Dokument anzuwendenden Regeln können optional durch ein XML Schema beschrieben werden. Ein XML Schema kann sowohl als separate Datei als auch innerhalb eines XML-Dokuments als Inline-Schema definiert sein. Wird ein Schema mit einem XML-Dokument in Beziehung gesetzt, muss das XML-Dokument nicht nur wohlgeformt sein, sondern auch den Vorgaben im Schema entsprechen. Dann gilt ein XML-Dokument auch noch als gültig. XML Schemas sind nicht allgemeingültig für alle XML-Dokumente, sondern meist spezifisch für ein ganz bestimmtes. Zudem können sie im Bedarfsfall an die speziellen Bedürfnisse angepasst werden. Es gibt drei Arten von Schemas, die bei der XML-Programmierung verwendet werden. Dabei handelt es sich um Document Type Definition (DTD), XML Data Reduced (XDR) und XML Schema Definition (XSD). XSD Schema ist eine Empfehlung des W3C aus dem Jahr 2001. Seitdem hat sich dieser Standard überall durchgesetzt. Ein ganz wesentlicher Grund dafür ist, dass XSD selbst auf XML basiert und darüber hinaus eine große Zahl von Datentypen unterstützt. Allerdings gibt es dabei nicht die Freizügigkeit wie bei den XML-Dokumenten, denn die Elemente eines XSD-Schemas sind fest vordefiniert. Damit Sie an dieser Stelle schon eine ungefähre Vorstellung davon bekommen, wie ein XSD Schema aussieht, sei hier das Schema gezeigt, mit dem die Regeln zur Beschreibung einer Person in einem XML-Dokument festgelegt werden.
    <?xml version="1.0" encoding="utf-8"?>
    <xs:schema id="Personen" xmlns=""
        xmlns:xs=http://www.w3.org/2001/XMLSchema
        xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
      <xs:element name="Personen" msdata:IsDataSet="true"
                  msdata:Locale="en-US">
        <xs:complexType>
          <xs:choice minOccurs="0" maxOccurs="unbounded">
            <xs:element name="Person">
              <xs:complexType>
                <xs:sequence>
                  <xs:element name="Vorname" type="xs:string"
                              minOccurs="0" />
                  <xs:element name="Zuname" type="xs:string"
                              minOccurs="0" />
                  <xs:element name="Alter" type="xs:string"
                              minOccurs="0" />
                  <xs:element name="Adresse" minOccurs="0"
                              maxOccurs="unbounded">
                    <xs:complexType>
                      <xs:attribute name="Ort" type="xs:string" />
                      <xs:attribute name="Strasse" type="xs:string" />
                    </xs:complexType>
                  </xs:element>
                </xs:sequence>
              </xs:complexType>
            </xs:element>
          </xs:choice>
        </xs:complexType>
      </xs:element>
    </xs:schema>
### 16.1.2 Regeln für wohlgeformten XML-Code #### Der Prolog Jedes XML-Dokument muss mit einer Verarbeitungsanweisung beginnen, die auch als Prolog bezeichnet wird und eine Software davon in Kenntnis setzt, dass es sich um ein Dokument mit XML-Daten handelt. Dabei muss die Versionsnummer der XML-Syntax angegeben werden.
    <?xml version="1.0"?>
oder gleichwertig mit Angabe des Zeichensatzes:
    <?xml version="1.0" encoding="utf-8"?>
UTF-8 (Uniform Transformation Format 8-Bit) ist zwar eine universelle Zeichencodierung, kann aber beispielsweise deutsche Umlaute nicht darstellen. Für dieses oder ähnliche Probleme mit anderen Sprachen gibt es mehrere zusätzliche Zeichensätze, die die unterschiedlichen Sprachen berücksichtigen. An dieser Stelle soll nicht auf alle eingegangen werden. Um jedoch zumindest den deutschsprachigen Raum zu berücksichtigen, sollten Sie den Zeichensatz ISO-8859-1 angeben, also:
    <?xml version="1.0" encoding="ISO-8859-1"?>
#### XML-Elemente Die Syntax eines Elements sieht folgendermaßen aus:
    <Elementname>Inhalt</Elementname>
Alle Elemente bestehen aus einem Start- und einem End-Tag. In den spitzen Klammern wird der Tag-Bezeichner angegeben. Das End-Tag erhält vor dem Bezeichner das Zeichen /. Optional können im Start-Tag auch Attribute angegeben werden. In einem XML-Dokument sind die Elementnamen frei wählbar, müssen aber den folgenden Regeln entsprechen: Sie dürfen keine Leerzeichen enthalten. Sie dürfen nicht mit xml, einer Zahl oder einem Satzzeichen beginnen. Zwischen der spitzen Klammer und dem Elementnamen darf kein Leerzeichen stehen. Die Groß- und Kleinschreibung muss bei dem Start- und dem End-Tag identisch sein, das heißt, <Person> darf nicht mit </person> ausgeleitet werden. Ein Element, das keinen Inhalt hat, darf auch nur aus dem End-Tag bestehen (z. B. <Person/>). Elemente können ineinander verschachtelt werden, dürfen sich dabei aber nicht überlappen. Das heißt, dass die folgende Codierung korrekt ist:
    <Person>
      <Zuname>Fischer</Zuname>
    </Person>
Das folgende Fragment ist hingegen nicht wohlgeformt, weil sich die Elemente überlappen:
    <Person>
      <Zuname>
      </Person>
      Fischer
    </Zuname>
#### Das Stammelement (Wurzelelement) Die genannten Regeln sind nicht schwierig zu verstehen. Dazu gesellt sich aber noch eine weitere Regel, die sich auf das gesamte XML-Dokument bezieht: Ein XML-Dokument muss genau ein Element enthalten, das als Stamm- oder auch als Wurzelelement bezeichnet wird. Zwei oder gar noch mehr parallele Elemente als Stammelemente sind nicht zulässig. Im Beispiel weiter oben ist das Element <Personen></Personen> das Stammelement. Dem Stammelement sind alle anderen Elemente untergeordnet. Unterhalb des Stammelements können beliebig viele Elemente parallel angeordnet werden, die nicht zwangsläufig gleichnamig sein müssen. Jedes Unterelement des Wurzelelements darf wieder eigene Unterelemente haben. Da diese Struktur der Struktur eines Baumes ähnelt, wird sie auch als Baumstruktur bezeichnet. Hier klicken, um das Bild zu vergrößern Abbildung 16.1 Die Struktur eines XML-Dokuments #### Attribute Attribute bestehen aus einem Bezeichner und einem zugewiesenen Wert. Die allgemeine Syntax von Attributen sieht wie folgt aus:
    <Elementname Attributname="Inhalt"></Elementname>
Grundsätzlich darf ein Element beliebig viele Attribute haben, die voneinander durch ein Leerzeichen getrennt werden. Der Attributname darf kein Leerzeichen enthalten und muss auch innerhalb seines Elements eindeutig sein. Mehrere verschiedene Elemente hingegen dürfen auch gleichlautende Attribute aufweisen. Der Wert eines Attributs wird in einfache oder doppelte Anführungszeichen eingeschlossen und durch ein Gleichheitszeichen vom Attributbezeichner getrennt. In unserem Beispiel oben weist das Element Adresse die beiden Attribute Ort und Strasse auf.
    <Adresse Ort="Berlin" Strasse="Bahnhofstr. 34"></Adresse>
Attributbezeichner können Sie (wie auch die Elementbezeichner) selbst festlegen. Welche Attribute in einem Element vorgeschrieben werden und welchen Wert ein Attribut haben darf, kann in einem Schema (XSD) festgelegt werden. #### Attribut oder Element? Vielleicht werden Sie sich an dieser Stelle fragen, was der Unterschied zwischen einem Attribut und einem untergeordneten Element ist. Ließe sich das Element Adresse mit seinen beiden Attributen Ort und Strasse, also
    <Adresse Ort="Berlin" Strasse="Bahnhofstr. 34"></Adresse>
auch gleichwertig in folgender Struktur darstellen?
    <Adresse>
      <Ort>Berlin</Ort>
      <Strasse>Bahnhofstr. 34</Strasse>
    </Adresse>
Die Antwort lautet: Ja. Letztendlich spielt es keine Rolle, ob Sie ein Attribut definieren oder stattdessen ein untergeordnetes Element. Es bleibt Geschmackssache. Im vorliegenden Fall würde ich subjektiv betrachtet eher zu einem Attribut tendieren, da Ort und Straße meiner Meinung nach eng an eine Adresse gebunden sind. ### 16.1.3 Kommentare Kommentare erfüllen in XML-Dokumenten denselben Zweck wie im klassischen Programmcode: Sie erleichtern das Lesen und die Interpretation des Inhalts und geben darüber hinaus auch zusätzliche Informationen. XML-Kommentare werden mit <!-- eingeleitet und mit --> beendet. Sie können anstelle des doppelten Bindestrichs am Anfang auch drei Bindestriche angeben. Am Ende drei Bindestriche zu verwenden, ist jedoch nicht zulässig. Damit ist
    <!-- Dies ist ein Kommentar. -->
ein gültiger Kommentar, ebenso wie:
    <!--- Dies ist ein Kommentar. -->
Innerhalb eines Kommentars darf kein doppelter Bindestrich angegeben werden. Kommentare dürfen zudem nicht innerhalb eines Tags eingeschlossen werden, und sie dürfen auch nicht vor der ersten Verarbeitungsanweisung, dem Prolog, vorkommen (also nicht vor <?xml ... ?>). Damit ist
    <Zuname>Meier<!-- Der Zuname der Person. --></Person>
unzulässig. ### 16.1.4 Verarbeitungsanweisungen Eine XML-Verarbeitungsanweisung (engl. Processing Instruction – PI) dient dazu, eine Befehlsinformation in ein XML-Dokument aufzunehmen, die von der Anwendung oder dem XML-Prozessor verwendet wird. Ein XML-Dokument kann beliebig viele Verarbeitungsanweisungen beinhalten. Vergleichbar ist eine Arbeitsanweisung mit Scriptcode, der innerhalb eines HTML-Dokuments in einen Kommentar eingebettet wird. Verarbeitungsanweisungen beginnen mit einer öffnenden spitzen Klammer, gefolgt von einem Fragezeichen. Beendet wird eine Verarbeitungsanweisung ebenfalls mit einem Fragezeichen, gefolgt mit der schließenden spitzen Klammer. Verarbeitungsanweisungen bestehen immer aus zwei Teilen: Der erste Teil enthält den Namen der Anwendung, von der die Anweisung verarbeitet wird, der zweite Teil beschreibt die eigentliche Anweisung.
    <?Ziel Daten?>
Das folgende Beispiel zeigt eine Verarbeitungsanweisung, die ein SQL-Statement beschreibt, das von einer Anwendung namens MyApplication ausgewertet werden könnte:
    <?MyApplication SELECT * FROM Products ?>
Einen Sonderfall stellt die Verarbeitungsanweisung dar, die grundsätzlich am Anfang eines XML-Dokuments zu setzen ist und auch als Prolog bezeichnet wird:
    <?xml version="1.0" ?>
Sie beginnt mit dem reservierten Schlüsselwort xml und dient dazu, die XML-Version des Dokuments und optional die Zeichencodierung anzugeben. Weiter oben haben wir bereits den Prolog behandelt. ### 16.1.5 Reservierte Zeichen in XML Einige Zeichen werden von XML reserviert. Dazu gehören unter anderem auch die spitzen Klammern, mit denen Tags ein- bzw. ausgeleitet werden. Um ein reserviertes Zeichen innerhalb eines XML-Dokuments zu verwenden, müssen Sie Entitätsverweise setzen. In Tabelle 16.1 sind diese aufgeführt.

Tabelle 16.1 Reservierte Zeichen und deren Entitätsverweise in XML

Reserviertes Zeichen | Entitätsverweis
& | &amp;
< | &lt;
> | &gt;
' (einfaches Hochkomma) | &apos;
" (doppeltes Hochkomma) | &quot;
### 16.1.6 CDATA-Abschnitte CDATA-Abschnitte dürfen überall dort stehen, wo auch Zeichendaten erlaubt sind. Sie dienen dazu, ganze Textblöcke zu schützen, die Zeichen enthalten, die normalerweise als Markup interpretiert würden. In solchen Abschnitten dürfen Sie daher auch die ansonsten reservierten Sonderzeichen benutzen, ohne dass Sie dadurch Schwierigkeiten bekommen. Die Syntax eines CDATA-Abschnitts sieht wie folgt aus:
    <Element><![CDATA[Inhalt]]></Element>
Eingeleitet wird ein CDATA-Abschnitt mit <![CDATA[, und beendet wird er mit ]]>. Dazwischen dürfen Sie alle beliebigen Zeichen und Zeichenkombinationen verwenden. Die einzige Ausnahme ist die schließende Zeichenfolge (]]>), denn das könnte zu einer Fehlinterpretation führen. CDATA-Abschnitte werden gerne verwendet, um das Eingeben und Lesen langer Programme oder von XML-Code zu erleichtern. Hierzu ein Beispiel:
    <Element><![CDATA[<gruss>An alle meine Freunde</gruss>]]></Element>
Zwischen dem Start-Tag <Element> und dem End-Tag </Element> (deren Bezeichnung natürlich frei wählbar ist) wird ein Text eingebettet, der mit den spitzen Klammern seinerseits selbst Zeichen enthält, die ansonsten reserviert sind. Der CDATA-Abschnitt hebt die ansonsten falsche Interpretation auf und verbirgt den beschriebenen textuellen Inhalt. ### 16.1.7 Namensräume (Namespaces) Anwendungen, die XML-Daten verarbeiten, werden mit jedem Element spezifische Operationen ausführen. Stößt eine Anwendung in einem XML-Dokument beispielsweise auf das Element Person, könnte eine gleichnamige Klasse in der Anwendung instanziiert werden. Die Elemente Vorname, Zuname, Alter usw. im XML-Dokument würden dann dazu dienen, die Eigenschaften des Person-Objekts festzulegen. Das funktioniert, solange die Elemente innerhalb eines XML-Dokuments eindeutig sind. Spätestens im Web könnten aber Schwierigkeiten auftreten, weil es dort üblich ist, Daten gemeinsam zu verwenden oder gar XML-Dokumente zusammenzuführen. Dabei kann es dazu kommen, dass mehrere identische Bezeichner für Elemente oder Attribute auftreten. Eine korrekte Interpretation und Verarbeitung der Elemente wird nicht möglich, weil die Elemente nicht eindeutig zugeordnet werden können. Ein typisches Beispiel hierfür zeigt das folgende XML-Fragment, das die Bestellung eines Kunden bei einem Versandunternehmen beschreibt.
    <Lieferung>
      <Kunde>
        <Konto>
          <Nummer>25027</Nummer>
          <Bank BLZ="0815"></Bank>>
        </Konto>
      </Kunde >
      <Artikel>
        <Bank>
          <ArtNummer>12345</ArtNummer>
          <Farbe>braun</Farbe>
        </Bank>
      </Artikel>
    </Lieferung>
Das Element Konto hat den untergeordneten Knoten Bank auf, der zur Angabe der Bankleitzahl dient. Zu einem Namenskonflikt führt, dass es noch ein zweites Element namens Bank im XML-Dokument gibt, womit hier der vom Kunden bestellte Artikel gemeint ist. Die Eindeutigkeit des Elements Bank ist bereits in diesem kurzen XML-Fragment nicht gewährleistet. Potenzielle Namenskonflikte sind auch in der Programmierung nicht neu. Im .NET Framework wurden sie durch die Einführung der Namensräume (Namespaces) gelöst. Eine sehr ähnliche Lösung bietet auch eine Empfehlung des W3-Konsortiums aus dem Jahr 1999: XML-Namespaces. Ehe wir uns den XML-Namespaces detailliert widmen, möchte ich Ihnen zeigen, wie das Problem der Eindeutigkeit in unserem Beispieldokument gelöst werden könnte.
    <?xml version="1.0" encoding="utf-8" ?>
    <Lieferung xmlns:customer="http://www.MyCompany.de"
               xmlns:product="http://www.MyCompany.de/products">
      <Kunde>
        <customer:Konto>
          <customer:KtoNummer>25027</customer:KtoNummer>
          <customer:Bank BLZ="0815"></customer:Bank>/>
        </customer:Konto>
      </Kunde >
      <Artikel>
        <product:Bank>
          <ArtNummer>12345</ArtNummer>
          <Farbe>braun</Farbe>
        </product:Bank>
      </Artikel>
    </Lieferung>
XML-Namespaces werden in der Regel über einen Uniform Resource Identifier (URI) beschrieben. Dabei handelt es sich um normale Webadressen. Ob sich dahinter tatsächlich eine reale Website verbirgt oder der URI fiktiv ist, spielt keine Rolle, da er nicht zu einem Webaufruf verwendet wird. Wichtig ist ausschließlich, dass ein XML-Namespace innerhalb eines Dokuments eindeutig ist und der XML-Prozessor die Elemente einem XML-Namespace zuordnen kann. Nur eindeutig zugeordnete Elemente können korrekt interpretiert und nach bestimmten Regeln verarbeitet werden. In dem Beispiel sind mit
    xmlns:customer="http://www.MyCompany.de"
    xmlns:product="http://www.MyCompany.de/products"
zwei XML-Namespaces deklariert. http://www.MyCompany.de dient dabei der Identifizierung der Kundendaten, http://www.MyCompany.de/products der Identifizierung des bestellten Artikels. Das World Wide Web Consortium (W3C) hat im Mai 1997 mit der im RFC 2141 spezifizierten URN-Syntax (URN – Unified Ressource Name) versucht, eine Lösung für die Vermeidung von ins Leere weisenden Hyperlinks anzubieten. Das Neue an URNs ist, dass sie keine absoluten Adressangaben verwenden, sondern unter Ausnutzung der Namespace-Funktionalität interpretierbare, abstrakte Zielbezeichnungen einführen.
    xmlns="urn:schemas-microsoft-com:xml-data"
Die allgemeine URN-Syntax ist wie folgt definiert:
    urn:<namespace identifier>:<namespace specific string>
Ob Sie selbst URIs oder URNs bevorzugen, hat zumindest technisch keine Auswirkungen. Im Allgemeinen haben sich aber URNs nicht durchgreifend durchgesetzt. #### Interpretation von Namespaces Die Nutzung von Namespaces ist nicht immer optional. Ihnen wird in vielen Dokumenten eine bestimmte Namespace-Angabe vorgeschrieben. In einem XML Schema beispielsweise müssen Sie den Namespace
    http://www.w3.org/2001/XMLSchema
angeben, in einer WPF-Anwendung sind beispielsweise
    http://schemas.microsoft.com/winfx/2006/xaml
und
    http://schemas.microsoft.com/winfx/2006/xaml/presentation
vorgeschrieben. Sie dürfen an den Angaben keinerlei Änderungen vornehmen, auch nicht hinsichtlich der Groß-/Kleinschreibung. Eine Software, die ein bestimmtes XML-Dokument oder einen bestimmten XML-Typ untersuchen soll, wird versuchen, die Elemente anhand des zugeordneten Namensraums eindeutig zu identifizieren, um darauf die erforderlichen Operationen auszuführen. Schon geringste Abweichungen von der Vorgabe führen dazu, dass das XML-Dokument nicht mehr gelesen werden kann. Eine Fehlermeldung ist die resultierende Konsequenz. #### Deklaration eines XML-Namespace XML-Namespaces werden grundsätzlich als Attribute deklariert und müssen einer strengen syntaktischen Vorgabe entsprechen. Sehen wir uns zunächst die Syntax der XML-Namespace-Deklaration an. Hier klicken, um das Bild zu vergrößern Abbildung 16.2 Syntax der Deklaration eines XML-Namespace Die Deklaration wird mit xmlns eingeleitet. Getrennt durch einen Doppelpunkt wird festgelegt, welches Präfix im XML-Dokument für den jeweiligen Namespace verwendet werden soll. Das Präfix kann frei gewählt werden. Hinter dem Präfix gibt man den URI an. Elementen, die einem bestimmten XML-Namespace zugeordnet werden sollen, wird das Präfix vorangestellt. Präfix und Elementname werden dabei durch einen Doppelpunkt getrennt, z. B.:
    <customer:Bank> ... </customer:Bank>
Das Präfix muss sowohl im einleitenden als auch im ausleitenden Tag angegeben werden. XML-Namespaces werden als Attribut innerhalb eines beliebigen Elements bekannt gegeben. In der Beispiellösung wurde dazu das Stammelement Lieferung verwendet. Allerdings muss bei der Wahl des Elements eine Sichtbarkeitsregel beachtet werden, denn ein XML-Namespace kann erst ab dem Element verwendet werden, in dem der XML-Namespace als Attribut deklariert wird. Das bedeutet, dass die Deklaration eines XML-Namespace spätestens im Start-Tag des Elements erfolgen muss, das den in seinen Attribut angegebenen Namespace zum ersten Mal verwendet. Durch die Wahl des Stammelements Lieferung stehen die beiden Präfixe customer und product jedem Element unseres XML-Dokuments zur Verfügung, auch Lieferung selbst. Hätten wir uns für die folgende XML-Namespace-Deklaration entschieden, wäre die Situation anders:
    <?xml version="1.0" encoding="utf-8" ?>
    <Lieferung>
      <Kunde xmlns:customer="http://www.MyCompany.de">
        ...
      </Kunde>
      <Artikel xmlns:product="http://www.MyCompany.de/products">
        ...
      </Artikel>
    </Lieferung>
Der Namespace http://www.MyCompany.de mit dem Präfix customer ist nun als Attribut des Elements Kunde deklariert. Das Element Kunde sowie dessen untergeordnete Elemente (Konto, KtoNummer und Bank) können dem Kontext customer zugeordnet werden, dem Element Artikel und dessen untergeordneten Elementen Bank, ArtNummer und Farbe jedoch nicht. Es können in einem Element auch mehrere Namespaces deklariert werden. Dabei ist allerdings auf die Verschachtelung der Elemente zu achten. Würden im Element Kunde beide Namespaces deklariert, also
    <Kunde xmlns:customer="http://www.MyCompany.de"
           xmlns:product="http://www.MyCompany.de/products">
      ...
    </Kunde>
    <Artikel>
      <product:Bank>
        <ArtNummer>12345</ArtNummer>
          <Farbe>braun</Farbe>
      </product:Bank>
    </Artikel>
wäre das XML-Dokument nicht mehr wohlgeformt, weil das Präfix product in einem nebengeordneten Element Verwendung findet und nicht in einem untergeordneten. Richtig wäre es hingegen, nun die Namespace-Deklarationen im Stammelement Lieferung vorzunehmen:
    <Lieferung xmlns:customer="http://www.MyCompany.de"
               xmlns:product="http://www.MyCompany.de/products">
Die Präfixe customer und product können jetzt von jedem Element im XML-Dokument benutzt werden. Zudem lässt sich auch nicht von der Hand weisen, dass das Dokument besser lesbar ist. Genau diesen Lösungsansatz finden Sie auch im Beispiel oben. #### Standard-Namespaces In einem XML-Dokument, in dem kein Namespace deklariert ist, gehören die Elemente auch keinem Namespace an. Sie können aber bei Bedarf alle Elemente ohne Präfix einem bestimmten Standard-Namespace zuordnen. Ein Standard-Namespace wird deklariert, indem man bei der Deklaration des XML-Namespace auf die Angabe des Präfix verzichtet, zum Beispiel:
    xmlns="http://www.DefaultNamespace.de"
Alle Elemente ohne Präfixangabe gehören nun zu dem Kontext, der durch den Standard-Namespace beschrieben wird. #### Namespace-Zuordnung untergeordneter Elemente Untergeordnete Elemente eines Elements mit Präfixangabe besitzen nicht automatisch denselben Namensraum wie deren übergeordnetes Element. Im folgenden Beispiel ist dem Element das Präfix x zugeordnet, das den Namensraum TestURN beschreibt. Die Elemente Person, Zuname und Adresse weisen kein Präfix auf und gehören keinem spezifischen Namespace an.
    <?xml version="1.0" encoding="utf-8" ?>
    <x:Personen xmlns:x="TestURN">
      <Person>
        <Zuname>Fischer</Zuname>
        <Adresse Ort="Bonn"></Adresse>
      </Person>
    </x:Personen>
Anders ist die Situation, wenn ein Standard-Namespace definiert wird. Dieser gilt dann tatsächlich für alle Elemente gleichermaßen. Im folgenden Beispiel sind also die Elemente Personen, Person, Zuname und Adresse Mitglieder des Namespace TestURN.
    <?xml version="1.0" encoding="utf-8" ?>
    <Personen xmlns="TestURN">
      <Person>
        <Zuname>Fischer</Zuname>
        <Adresse Ort="Bonn"></Adresse>
      </Person>
    </Personen>
Zum Abschluss noch ein drittes Beispiel. Hier ist ein Namespace im Wurzelelement definiert, dem ein Präfix zugeordnet ist. Das Präfix wird aber von keinem der Elemente im XML-Dokumente benutzt. Alle Elemente des Dokuments können demnach nicht dem Namespace zugeordnet werden und gehören tatsächlich keinem Namespace an.
    <Personen xmlns:x="TestURN">
      <Person>
        <Zuname>Fischer</Zuname>
        <Adresse Ort="Bonn"></Adresse>
      </Person>
    </Personen>
#### Beispielprogramm Auf der DVD zu diesem Buch finden Sie das Projekt XMLNamespaces. Zu dem Projekt gehört die XML-Datei Lieferung.xml, die folgendermaßen definiert ist:
    <?xml version="1.0" encoding="utf-8" ?>
    <Lieferung xmlns:customer="http://www.MyCompany.de"
               xmlns:product="http://www.MyCompany.de/products"
               xmlns="http://MyDefaultNamespace">
      <Kunde>
        <customer:Konto>
          <customer:KtoNummer>25027</customer:KtoNummer>
          <customer:Bank BLZ="0815"></customer:Bank>/>
        </customer:Konto>
      </Kunde >
      <product:Artikel>
        <product:Bank>
          <ArtNummer>12345</ArtNummer>
          <Farbe>braun</Farbe>
        </product:Bank>
      </product:Artikel>
    </Lieferung>
Der zu diesem Projekt gehörende Programmcode soll an dieser Stelle nicht erläutert werden. Wenn Sie die Anwendung starten, wird die XML-Datei analysiert, und es wird jeder relevante Knoten mit dem Namespace ausgegeben, der ihm zugeordnet ist (siehe Abbildung 16.3). Sie können zudem durch einfache Änderungen an der XML-Datei ausprobieren, wie sich eine Änderung der Namespaces auf die Zuordnung des entsprechenden Elements auswirkt.
Anmerkung
Der Markt ist überschwemmt von den vielen XML-Tools zu Erzeugung von XML-Dokumenten. Manchmal sind diese kostenlos erhältlich, teilweise ist dafür ein erheblicher Preis zu zahlen. An dieser Stelle sollte erwähnt werden, dass Microsoft mit XML-Notepad 2007 ein solches Tool anbietet, das Sie kostenlos von der Microsoft-Website herunterladen können. »Einem geschenkten Gaul schaut man nicht ins Maul« – dieser Spruch gilt auch für XML-Notepad. Es kann sicherlich nicht alle Anforderungen erfüllen, die an ein professionelles Tool gestellt werden. Es eröffnet aber auf einfache Weise Möglichkeiten, intuitiv XML-Dokumente zu erzeugen. Insbesondere um die Ausführungen des folgenden Abschnitts nachzuvollziehen, sollten Sie sich dieses Werkzeug herunterladen. Auf eine weitergehende Beschreibung der Bedienung sei an dieser Stelle verzichtet, denn sie ist – wie bereits erwähnt – einfach und intuitiv.
Hier klicken, um das Bild zu vergrößern