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.png
    Source Code veröffentlichen – aber bitte mit Lizenz

    Seit es den Blog gibt wird auch meist der gesamte Demo Source Code mit veröffentlicht. Das Ganze hatte ich am Anfang noch als .zip verteilt, später lag es mal auf Google Code und nun liegen alle Samples und sonstige Sachen auf GitHub. Beim letzten User Group Treffen in Zürich mit dem Titel “Open Source: Get […]

  • Fix: Cannot convert from ‘CConnectProxy::_ComMapClass *’ to ‘AddInDesignerObjects::IDTExtensibility2 *’

    Mal einen etwas esoterischer Blogpost, welcher auftaucht wenn man zu viel mit Office Addins rumspielt. Der Fehler passiert beim Bauen von C++ Projekten, welchen diesen Typ benötigen. Lösung (auf 64bit Systemen): C:\Program Files (x86)\Common Files\DESIGNER>regsvr32 MSADDNDR.DLL And Rebuild. Meine lieben Kollegen hatte mir dies schon mehrfach gesagt, allerdings hatte ich es immer wieder vergessen Das […]

  • Gegen das Gesetz verstoßen: X Jahre Haft. Gegen die Terms of Use verstoßen: Bann auf Lebenszeit. Danke Google & co.

    Bei fast allen Diensten die man im Internet nutzen kann muss man den “Terms of use” zustimmen. Völlig logisch dass da natürlich drin steht was erlaubt und was nicht. Wenn man gegen diese Regelungen verstößt hat das Unternehmen natürlich das Recht etwas dagegen zu unternehmen. In der heutigen Welt beherrschen einige wenige Unternehmen die digitale […]

  • image.png
    RSS Feed samt Kommentaranzahl und andere nicht Standard Elemente mit dem SyndicationFeed auslesen

    Jetzt mal ein Blogpost ohne ein fancy NuGet Package: Seit .NET 3.5 gibt es die SyndicationFeed Klasse. Eine schon etwas ältere API, reicht aber aus um Atom bzw. RSS Feeds zu lesen. In diversen RSS Feeds gibt es aber Erweiterungen, welche man natürlich auch auslesen möchte. So gibt WordPress z.B. auch die Anzahl der geposteten […]

  • image.png
    ASP.NET Bundling & Fontawesome

    Vor einer halben Ewigkeit hatte ich mal geschrieben wie man Fontawesome in ASP.NET nutzen kann. Aufgrund des Alters des Post und einem Kommentar ob man denn Fontawesome auch in das ASP.NET Bundling Framework integrieren kann möchte ich nur ein kurzes Update schreiben. TL;DR: NuGet Package “Fontawesome” runterladen und Pfad in der Bundleconfig angeben. Kurze Schritte […]

Support us!