Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort zur 6. Auflage
1 Allgemeine Einführung in .NET
2 Grundlagen der Sprache C#
3 Das Klassendesign
4 Vererbung, Polymorphie und Interfaces
5 Delegates und Ereignisse
6 Strukturen und Enumerationen
7 Fehlerbehandlung und Debugging
8 Auflistungsklassen (Collections)
9 Generics – Generische Datentypen
10 Weitere C#-Sprachfeatures
11 LINQ
12 Arbeiten mit Dateien und Streams
13 Binäre Serialisierung
14 XML
15 Multithreading und die Task Parallel Library (TPL)
16 Einige wichtige .NET-Klassen
17 Projektmanagement und Visual Studio 2012
18 Einführung in die WPF und XAML
19 WPF-Layout-Container
20 Fenster in der WPF
21 WPF-Steuerelemente
22 Elementbindungen
23 Konzepte von WPF
24 Datenbindung
25 Weitere Möglichkeiten der Datenbindung
26 Dependency Properties
27 Ereignisse in der WPF
28 WPF-Commands
29 Benutzerdefinierte Controls
30 2D-Grafik
31 ADO.NET – Verbindungsorientierte Objekte
32 ADO.NET – Das Command-Objekt
33 ADO.NET – Der SqlDataAdapter
34 ADO.NET – Daten im lokalen Speicher
35 ADO.NET – Aktualisieren der Datenbank
36 Stark typisierte DataSets
37 Einführung in das ADO.NET Entity Framework
38 Datenabfragen des Entity Data Models (EDM)
39 Entitätsaktualisierung und Zustandsverwaltung
40 Konflikte behandeln
41 Plain Old CLR Objects (POCOs)
Stichwort

Download:
- Beispiele, ca. 62,4 MB

Jetzt Buch bestellen
Ihre Meinung?

Spacer
Visual C# 2012 von Andreas Kühnel
Das umfassende Handbuch
Buch: Visual C# 2012

Visual C# 2012
Rheinwerk Computing
1402 S., 6., aktualisierte und erweiterte Auflage 2013, geb., mit DVD
49,90 Euro, ISBN 978-3-8362-1997-6
Pfeil 14 XML
Pfeil 14.1 Grundlagen
Pfeil 14.2 XML-Dokumente
Pfeil 14.2.1 Wohlgeformte und gültige XML-Dokumente
Pfeil 14.2.2 Die Regeln eines wohlgeformten XML-Codes
Pfeil 14.2.3 Kommentare
Pfeil 14.2.4 Verarbeitungsanweisungen
Pfeil 14.2.5 Reservierte Zeichen in XML
Pfeil 14.2.6 CDATA-Abschnitte
Pfeil 14.2.7 Namensräume (Namespaces)
Pfeil 14.3 Die Gültigkeit eines XML-Dokuments
Pfeil 14.3.1 XML Schema Definition (XSD)
Pfeil 14.3.2 Ein XML-Dokument mit einem XML-Schema verknüpfen
Pfeil 14.3.3 Die Struktur eines XML-Schemas
Pfeil 14.4 Die Klasse »XmlReader«
Pfeil 14.4.1 XML-Dokumente mit einem »XmlReader«-Objekt lesen
Pfeil 14.4.2 Validieren eines XML-Dokuments
Pfeil 14.5 Eigenschaften und Methoden der Klasse »XmlReader«
Pfeil 14.6 Die Klasse »XmlWriter«
Pfeil 14.6.1 Die Methoden der Klasse »XmlWriter«
Pfeil 14.7 Navigation durch XML (XPath)
Pfeil 14.7.1 Die Klasse »XPathNavigator«
Pfeil 14.7.2 XPath-Ausdrücke
Pfeil 14.7.3 Der Kontextknoten
Pfeil 14.7.4 Beispiele mit XPath-Ausdrücken
Pfeil 14.7.5 Knotenmengen mit der »Select«-Methode
Pfeil 14.7.6 Auswerten von XPath-Ausdrücken
Pfeil 14.8 Das Document Object Model (DOM)
Pfeil 14.8.1 Allgemeines
Pfeil 14.8.2 Arbeiten mit »XmlDocument«
Pfeil 14.8.3 »XmlDocument« und »XPathNavigator«
Pfeil 14.8.4 Die Klasse »XmlNode« (Operationen mit Knoten)
Pfeil 14.8.5 Manipulieren einer XML-Struktur
Pfeil 14.8.6 Ändern eines Knotens
Pfeil 14.8.7 Löschen in einem XML-Dokument
Pfeil 14.9 Serialisierung mit »XmlSerializer«
Pfeil 14.9.1 XML-Serialisierung mit Attributen steuern
Pfeil 14.10 LINQ to XML
Pfeil 14.10.1 Allgemeines
Pfeil 14.10.2 Die Klassenhierarchie von LINQ to XML
Pfeil 14.10.3 Die Klasse »XElement«
Pfeil 14.10.4 Die Klasse »XDocument«
Pfeil 14.10.5 Navigation im XML-Dokument
Pfeil 14.10.6 Änderungen am XML-Dokument vornehmen

Rheinwerk Computing - Zum Seitenanfang

14.2 XML-DokumenteZur nächsten Überschrift

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 von jeder Plattform verstandenes, universelles Format. 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>

Listing 14.1 Einfaches XML-Dokument


Rheinwerk Computing - Zum Seitenanfang

14.2.1 Wohlgeformte und gültige XML-DokumenteZur nächsten ÜberschriftZur vorigen Überschrift

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«, den ausleitenden Tag zu definieren, ohne dass Ihnen der Browser das übel nehmen wird – zumindest in vielen Fällen. In XML hingegen ist ein ausleitender 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 spielt 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>

Listing 14.2 XML-Dokument mit mehreren 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 auf die speziellen Bedürfnisse angepasst werden.

Es gibt drei Arten von Schemata, 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-Schemata sind eine Empfehlung vom 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>

Listing 14.3 Beispiel einer XSD-Schemadatei


Rheinwerk Computing - Zum Seitenanfang

14.2.2 Die Regeln eines wohlgeformten XML-CodesZur nächsten ÜberschriftZur vorigen Überschrift

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 eine universelle Zeichencodierung, die es auch gestattet, Inhalte in Griechisch oder Russisch anzuzeigen. Demgegenüber ist der Zeichensatz utf-8, der alternativ zu UTF-8 angegeben werden kann, mehr auf die westeuropäischen Bedürfnisse ausgerichtet.

XML-Elemente

Die Syntax eines Elements sieht folgendermaßen aus:

<Elementname>Inhalt</Elementname>

Alle Elemente bestehen aus einem Start- und einem Endtag. In den spitzen Klammern wird der Tagbezeichner angegeben. Das Endtag erhält vor dem Bezeichner das Zeichen »/«. Optional können im Starttag 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 Endtag identisch sein, d. h., <Person> darf nicht mit </person> ausgeleitet werden.
  • Ein Element, das keinen Inhalt hat, darf auch nur aus dem Endtag 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 noch eine weitere, die sich auf das gesamte XML-Dokument bezieht: Ein XML-Dokument muss genau ein Element enthalten, das als Stamm- oder auch 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.

Abbildung

Abbildung 14.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 Geschmacksache. 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.


Rheinwerk Computing - Zum Seitenanfang

14.2.3 KommentareZur nächsten ÜberschriftZur vorigen Überschrift

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

<!--- Dies ist ein Kommentar. -->

Innerhalb eines Kommentars darf kein doppelter Bindestrich angegeben werden. Kommentare dürfen zudem nicht innerhalb eines Tags eingeschlossen werden und 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.


Rheinwerk Computing - Zum Seitenanfang

14.2.4 VerarbeitungsanweisungenZur nächsten ÜberschriftZur vorigen Überschrift

Eine XML-Verarbeitungsanweisung (engl.: Processing Instruction, PI) dient dazu, eine Befehlsinformation in einem 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 einem Kommentar eingebettet wird.

Verarbeitungsanweisungen beginnen mit einer öffnenden spitzen Klammer, gefolgt von einem Fragezeichen. Beendet wird eine Verarbeitungsanweisung ebenfalls mit einem Fragezeichen, gefolgt von 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 ?>

Ein 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.


Rheinwerk Computing - Zum Seitenanfang

14.2.5 Reservierte Zeichen in XMLZur nächsten ÜberschriftZur vorigen Überschrift

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 14.1 sind diese aufgeführt.

Tabelle 14.1 Reservierte Zeichen und deren Entitätsverweise in XML

Reserviertes Zeichen Entitätsverweis

&

&amp;

<

&lt;

>

&gt;

' (einfaches Hochkomma)

&apos;

" (doppeltes Hochkomma)

&quot;


Rheinwerk Computing - Zum Seitenanfang

14.2.6 CDATA-AbschnitteZur nächsten ÜberschriftZur vorigen Überschrift

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 von langen Programmen oder XML-Code zu erleichtern. Hierzu ein Beispiel:

<Element><![CDATA[<gruss>An alle meine Freunde</gruss>]]></Element>

Zwischen dem Starttag <Element> und dem Endtag </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.


Rheinwerk Computing - Zum Seitenanfang

14.2.7 Namensräume (Namespaces)Zur nächsten ÜberschriftZur vorigen Überschrift

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 ist 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>

Listing 14.4 XML-Dokument mit nicht eindeutigem Element >Bank>

Das Element Konto hat den untergeordneten Knoten Bank, 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>

Listing 14.5 XML-Dokument mit XML-Namespaces

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 Resource 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. Sogar 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-Namespaces

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.

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.

Abbildung

Abbildung 14.2 Syntax der Deklaration eines XML-Namespaces

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-Namespaces spätestens im Starttag des Elements erfolgen muss, das den in seinem Attribut angegebenen Namespace das erste 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>

Listing 14.6 Element-Namespace-Zuordnung

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 (siehe dazu auch Listing 14.5).

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>

Listing 14.7 Verschachtelte Elemente und deren Zuordnung zu Namespaces

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-Namespaces auf die Angabe des Präfixes verzichtet, z. B.:

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>

Listing 14.8 Namespace-Zuordnung untergeordneter Elemente (1)

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 Namespaces TestURN.

<?xml version="1.0" encoding="utf-8" ?>
<Personen xmlns="TestURN">
<Person>
<Zuname>Fischer</Zuname>
<Adresse Ort="Bonn"></Adresse>
</Person>
</Personen>

Listing 14.9 Namespace-Zuordnung untergeordneter Elemente (2)

Zum Abschluss noch ein drittes Beispiel. Hier sei 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.

<?xml version="1.0" encoding="utf-8" ?>
<Personen xmlns:x="TestURN">
<Person>
<Zuname>Fischer</Zuname>
<Adresse Ort="Bonn"></Adresse>
</Person>
</Personen>

Listing 14.10 Namespace-Zuordnung untergeordneter Elemente (3)

Beispielprogramm

Auf der Beispiel-CD 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. Starten Sie die Anwendung, wird die XML-Datei analysiert und jeder relevante Knoten mit dem Namespace ausgegeben, der ihm zugeordnet ist (siehe Abbildung 14.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.

Abbildung

Abbildung 14.3 Die XML-Namespaces der Datei »Lieferung.xml«

Anmerkung

Der Markt ist überschwemmt von vielen XML-Tools zur Erzeugung von XML-Dokumenten. Manche sind 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 downloaden können.

Einem geschenkten Gaul schaut man nicht ins Maul – dieser Spruch gilt sicherlich 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 weiter gehende Beschreibung der Bedienung sei an dieser Stelle verzichtet, denn sie ist – wie bereits erwähnt – einfach und intuitiv.



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Visual C# 2012

Visual C# 2012
Jetzt Buch bestellen


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Professionell entwickeln mit Visual C# 2012






 Professionell
 entwickeln mit
 Visual C# 2012


Zum Rheinwerk-Shop: Windows Presentation Foundation






 Windows Presentation
 Foundation


Zum Rheinwerk-Shop: Schrödinger programmiert C++






 Schrödinger
 programmiert C++


Zum Rheinwerk-Shop: C++ Handbuch






 C++ Handbuch


Zum Rheinwerk-Shop: C/C++






 C/C++


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo





Copyright © Rheinwerk Verlag GmbH 2013
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern