Guide: XML (Basiswissen)

XML – Thema: Basiswissen

Was bedeutet Basiswissen bei XML? Gute Frage. Daher ist meine Schulung sowieso nur in 2 große Hauptteile gegliedert (Einführung und Basiswissen). Mag etwas sinnlos sein, aber egal.

Heute geht es darum: Was ist eigentlich XML? Wie definiert man es und was gibt es für Fachtermini zu dem Thema?

Da dieser Teil “Basiswissen” enorm groß ist – vor uns liegen noch Themen wie XML DTDs, XSD, XPath & XSLT. Vielleicht – aber die Chancen sind äußerst gering. Mach ich einen 3 großen Teil: XML in .NET. Ist ein sehr spannendes Thema, welches sich auch lohnen würde aufzuschreiben. Lassen wir uns überraschen.

II Basiswissen

1. Interpretation von XML
1.1 Clientseitige Interpretation
Beim Clientseitigen XML Interpretieren, bekommt der Client das XML Dokument direkt vom Server geschickt. Nun hat der Client verschiedene Möglichkeiten das Dokument zu formatieren um es in die gewünschte vorm zu bringen, z.B. HTML.

Allerdings ist es heute, im Jahre 2006, noch nicht ganz unproblematisch, ein XML Dokument durch den Browser parsen zu lassen um am Ende die gewünschte Website zu sehen.

Später werden noch einige Beispiele dazu folgen.

1.2 Serverseitige Interpretation
Durch “Content Negotiaten” spricht sich der Server mit dem Client ab, ob dieser XML akzeptiert oder nicht. Wenn dies der Fall ist, wird das XML Dokument Clientseitig durch den Browser geparst. Falls der Client dies aber nicht unterstützt, liefert der Server in den meisten Fällen ein HTML Dokument direkt an den Client, da dies alle Browser beherrschen.

Diese Variante ist in der heutigen Zeit, wohl die am meisten verwendete, da man noch nicht genau sagen kann, wie ein Browser XML parst.

Beispiele dazu werden ebenso später folgen.

2. Grundlegendes für das Verständnis
2.1 XML Deklaration

Beispiel:

<?xml version="1.0" encoding= "EUC-JP" standalone = "yes"?>

Hinter dem ?xml werden so genannte Pseudo-Attribute erwartet. Die XML Spezifikation enthält momentan 3 solcher Pseudo-Attribute:

- Version:
    – Sollte immer Angegeben sein.
    – Enthält XML-Spezifikationsversion
    – 1.0 oder 1.1 sind momentan sinnvolle Werte
- Encoding:
    – Bestimmt Kodierung des XML
    – UTF 8 ist Standard
    - Auch muss das Attribut vom Parser angenommen werden.
- Standalone:
    – Selten verwendet
    – Yes oder No sind die einzig gültigen Werte
    – Yes wird verwendet, wenn Parser externe DTD (oder XSD) ignoriert werden soll

2.2 Fachtermini
Da in den folgenden Kapiteln immer wieder bestimmte “Fachwörter” auftauchen, hier mal eine kurze Erklärung.

Wohlgeformtheit: Ein XML Dokument, welche alle Regeln der Spezifikation einhält ist wohlgeformt (“well formed”).

Gültigkeit: Für den Datenaustausch über XML ist es wichtig, Regeln für das Erstellen von XML Dokumenten zu erstellen. Regeln stehen entweder in der DTD oder in einer XSD. Wenn das XML Dokument diese Regeln einhält, ist es gültig (“valid”).

2.2.1 Parser
Parser sind Programme oder Programmteile, welche das XML Dokument auslesen, interpretieren. Kontrolliert der Parser auch die Gültigkeit, nennt man ihn “validierender Parser”.

Momentan gibt es 2 große “Parserarten”.

Die erste Parserart hat sich zum quasi Standard durchgesetzt. Genannt wird diese Art “SAX”, was voll ausgesprochen Simple API for XML heisst.
SAX ließt XML Dokument über sequentiellen Datenstrom und ruft im Standard definierte Ereignisse vorgegebene Rückruffunktionen auf. Dadurch ist SAX zustandslos und erlaubt keinen freien Zugriff auf alle Inhalte. Das ist insbesondere für große XML Dateien praktisch.

Die zweite Art nennt sich DOM, was auch schon aus z.B. Javascript bekannt sein dürfte. DOM ist ein W3C Standard, welcher voll ausgesprochen Document Object Model heisst. DOM liesst zuerst das komplette XML Dokument ein und bildet den Strukturbaum intern ab. Vorteil davon ist, dass ich auf jedes Element Einfluss nehmen kann und dadurch freien Zugriff auf alle Teile meines XMLs habe und jederzeit verändern kann.

Beide Parserarten haben freie Schnittstellen, sodass bereits für beide Arten in fast allen gängigen Programmiersprachen Zugriffsmöglichkeiten bestehen.

2.2.2 Delimitierung
In einigen Quellen ist von Delimitierung die Rede, was eigentlich recht schnell erklärt ist. Die Delimitierung ist die Abgrenzung zwischen den Tags und den Inhalten dessen, sprich die “<” und “>” Klammer.

2.2.3 Tags und Elemente
Tags repräsentieren meistens Elemente, allerdings muss man bei der Wahl eines Tags bestimmte Regeln einhalten.

Der Tag muss mit Buchstaben (a-z, A-Z) oder mit Unterstrich (_) anfangen. Zahlen sind nicht erlaubt.
Nach der Regel darf nach dem ersten Zeichen wieder Buchstaben (a-z, A-Z), Unterstrich (_), Zahlen (0-9) oder bestimmte Interpunktionen (.,,;) verwenden.
Nicht erlaubt sind Leerzeichen.
Wie bereits erwähnt, sind Elemente und Tags casesensitive.

Jedes Element beginnt mit <tagName> und endet mit </tagName> .

Beispiel aus XHTML:

<p>Das ist toll.</p>

Ausnahmen werden als Empty-Element-Tag bezeichnet und sehen so aus:

Beispiel aus XHTML:

<img src=”bild.jpg” alt=”Bild” />

Reservierte Zeichen:

In XML sind 4 Zeichen reserviert. Diese vier Zeichen sind:
“<”, “>”, das Apostroph und die Anführungszeichen. Für diese Zeichen gibt es, ähnlich wie in HTML die Umlaute, vordefinierte Entities:

< = <
> = >
Apostroph = &apos;
Anführungszeichen = ”

2.2.4 Tags und Elemente
Wie in fast jeder Sprache, gibt es auch in XML die Möglichkeit Kommentare zu setzen:

<!– Das ist ein gar lustiger Kommentar. –>

2.2.5 Attribute

XML – Attribute werden direkt in den Elementtag geschrieben, welche Metainformationen beinhalten.

Attributwerte werden in “” geschrieben.

Nun muss man allerdings drauf achte, wann man ein Attribute einem Tag zuordnet oder ob man direkt ein neues Element unterm dem Element zuordnet.

Um zu verdeutlichen was ich meine, hier kurze Beispiele:

Beispiel mit Informationen in den Attributen:

<person id="01231233328654" lastlogin="05.04.06"> 
     <vorname>Ben</vorname> 
     <nachname>James</nachname> 
     <wohnort>New York</wohnort> 
</person>

Beispiel mit Informationen als neue Elemente:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<person> 
    <lastlogin>05.04.06</lastlogin> 
    <id>01231233328654</id> 
    <vorname>Ben</vorname> 
    <nachname>James</nachname> 
    <wohnort>New York</wohnort> 
</person>

Es gibt dazu keine allgemeingültige Regel, wann man was einsetzt, da es ganz vom Verwendungszweck abhängt. Man sollte allerdings den Sinn des XMLs auch ohne die Attribute verstehen, da dies nur extra Informationen darstellen sollen.Im kommenden Kapitel werden uns die Attribute auch in der DTD und in der XSD begegnen.

2.2.6 URI & URL
In XML reden wir meistens von der URI (“Uniform Ressource Identifier”) gesprochen, hingegen ist den meisten nur die URL (“Uniform Ressource Locator”).

Die URL ist eine Teilmenge von der URI, allerdings kann man beide nicht einfach auseinanderhalten.

“http://www.test.de” könnte eine URL oder URI sein.

Unterschied besteht in dem Sinn. Die URL bezieht sich mehr auf den Speicherort des Dokumentes (“… Locator”) und ist in der Regel eine Internetadresse.

Die URI identifiziert die Ressource und ist eine allgemeine Architektur zur Lokalisierung von Dokumenten. Die URI ist nicht auf Ressourcen im Internet beschränkt.

Wenn wir heute in XML von der URI sprechen, ist es meistens die URL.

3. Namensräume

Insbesondere in größeren Projekten, wird es früher oder später Namensdopplungen geben, wo sie den Sinn entstellen. Als Beispiel haben verwenden wir in einer XML Datei folgendes:

Beispiel:

<!--Adresse 1 -->
<adresse> 
    <strasse>Blabla</strasse> 
    <hausnummer>42</hausnummer> 
    <plz>15023</plz> 
    <ort>Hinterblubdorf</ort> 
</adresse> 
<!--Adresse 2 -->
<rechner> 
    <domain>bla.de</domain> 
    <name>namensblabla</name> 
    <adresse>127.0.0.1</adresse> 
</rechner>

Wie sie hier sehen, wir das Element “adresse” 2 mal gebraucht und beides mal in einem anderen Zusammenhang. Will man unterschiedlich gemeinte Elemente in einem Dokument benutzen, was ja bei großen Projekten durchaus vorstellbar ist, braucht man Namensräume.In der XML sind Namensräume an URIs gebunden. Um einen Namespace zu definieren wird “xmlns”, der Präfix und die zugehörige URI angegeben. Der Präfix “xml” ist reserviert und kann daher nicht neu definiert werden.

Beispiel:

<x xmlns:test='http://test.org/schema'> 
    <!-- Das "test"-Präfix wird für das Element "x" und Inhalt an http://test.org/schema gebunden. --> 
</x> 

Der QName ist eine Zusammensetzung aus dem Präfix und dem lokalen Namen. 

“Default Namespaces” können verwendet werden, wenn ein Namensraum häufiger als andere verwendet wird. Allerdings kommen damit einige Parser und Browser nicht vollständig zurecht.

Beispiel:

<x xmlns:test='http://test.org/schema'> 
    <test:y>Dies hier ist mit Namespacepräfix.</test:y> 
</x>
<default xmlns='http://test.org/schema'> 
    <test>Hier wird der default Namespace verwendet, welcher festgelegt wurde.</test> 
</default>

Damit unser oberes Beispiel funktionieren kann, müssen wir nun ein paar kleine Veränderungen durchführen. 

Beispiel:

<!--Adresse 1 -->
<adresse xmlns:adresse="http://www.test.de/schema"> 
    <adresse:strasse>Blabla</adresse:strasse> 
    <adresse:hausnummer>42</adresse:hausnummer> 
    <adresse:plz>15023</adresse:plz> 
    <adresse:ort>Hinterblubdorf</adresse:ort> 
</adresse>
<!--Adresse 2 -->
<rechner xmlns:rechner="http://www.test.de/schema"> 
    <rechner:domain>bla.de</rechner:domain> 
    <rechner:name>namensblabla</rechner:name> 
    <rechner:adresse>127.0.0.1</rechner:adresse> 
</rechner>
 

Der Präfix ist im Prinzip nichts anderes als eine Erweiterung der URI.

Statt rechner=”http://www.test.de/schema” könnte man auch “http://www.test.de/schema/rechner” sagen.

[Fortsetzung: XML (DocumentType Definitions DTDs)]

Letzte Posts

  • image_thumb.png
    NuGet Package Restore & Build Server wie z.B. AppVeyor

    NuGet ist ja mittlerweile weit verbreitet, aber eine Frage stellt sich natürlich immer noch: Checkt man die NuGet Packages ein oder nicht? In meinem kleinen Side-Projekt, welches auf GitHub liegt und ich über AppVeyor auch bauen lasse nutze ich das Package Restore Feature von NuGet, d.h. in meinem Repository befindet sich kein NuGet Package mehr, […]

  • image.png
    Microsoft Account Login via ASP.NET Identity

    Der Microsoft Account ist die zentrale Identifikationsstelle in der “Consumer-Microsoft-Welt”, allerdings ist das Einbinden eben dieser in die eigene Applikation eher schwierig. Das “Live SDK” ist nun unter dem OneDrive Dev Center zu finden und ganz professionell wurden auch alle Links zum alten Live SDK damit unbrauchbar gemacht. Beim Microsoft Account ist es auch unmöglich […]

  • image.png
    Zeitgesteuerte Azure WebJobs – so einfach kann Azure sein

    Das noch in Entwicklung befindliche Azure WebJob SDK bietet einige coole Features zum Verarbeiten und Bereitstellen von Daten. Bekanntes Beispiel ist das Sample welches auf eine Azure Queue lauscht und sobald ein Item da vorhanden ist anfängt dies zu verarbeiten. Szenario: Zeitgesteuerte Aktivitäten – ohne Queue und co. Mein Szenario war allerdings wesentlich trivialer: Ich […]

  • image.png
    Get Involved in OSS! Ja, aber wie geht das denn mit GitHub?

    Auch im .NET Lager gibt es Bewegung im OSS Bereich und es gibt verschiedene Arten wie man bei einem Open Source Projekt “Contributed”. Was zählt alles zu “Contribution”? Unter “Contribution” läuft eigentlich alles – ob es Fragen/Probleme zu dem Projekt via Issues ist oder Dokumentation nachreicht oder ob man darüber bloggt oder das Projekt vorstellt. […]

  • HowTo: Web.config samt eigener ConfigSection zur Laufzeit ändern

    In dem HowTo geht es darum wie man die Web.config zur Laufzeit ändert und was es dabei zu beachten gilt. Das ganze klappt auch mit komplexeren ConfigSections. Eigene ConfigSection? Vor einer ganzen Weile habe ich mal über das Erstellen einer eigenen ConfigSection geschrieben – im Grunde nutzen wir jetzt fast dieselbe Config. Zur Laufzeit? Startet […]

Support us!