XML ist für viele Anwender deshalb etwas schwer greifbar, weil es eigentlich nicht viel tut. Seine Leistung besteht darin, dass man mit den Konzepten und Regeln, die es bereitstellt, eigene Auszeichnungssprachen definieren kann, die ähnlich funktionieren wie HTML. All diese Sprachen bestehen immer wieder aus Elementen, markiert durch Tags, deren Verschachtelungsregeln, und aus Attributen mit erlaubten Wertzuweisungen.
<rechteck oben="100" links="185" breit="427" hoch="110"> <hintergrund typ="verlauf" richtung="waagerecht" startfarbe="#0000FF" endfarbe="#FFFFFF"> <inhalt typ="text" format="stil_6"> Ein kleiner Text </inhalt> </hintergrund> </rechteck>
<projekt sprache="perl" name="Performance-Test IC-Baustein TL410" typ="shell" stand="02-10-2001"> <modul name="main" stand="02-10-2001" ablage="/usr/scripts/tl410/tl410.pl"> <funktion name="datenversorgung" stand="14-09-2001"> <beschreibung> versorgt den Speicherbaustein mit sinnvollen Anfangswerten aus Testreihe T3. </beschreibung> </funktion> </modul> </projekt>
Es wurden absichtlich zwei Beispiele gewählt, um zu verdeutlichen, wie beliebig sich das Auszeichnungssprachenkonzept einsetzen lässt. Im ersten Beispiel geht es um die Definition eines vektorgrafischen Elements, im zweiten Beispiel um die Dokumentation der Arbeits-Scripts eines Elektrotechnikers. Ebensogut lassen sich auf diese Weise Konstruktionszeichnungen, musikalische Kompositionen, Theaterstücke und biochemische Prozesse beschreiben. Eigentlich alles, was irgendwelche benennbaren und beschreibbaren Strukturen aufweist. Mit welcher Software man diese Daten visualisieren, abspielen oder anderweitig verarbeiten kann, ist damit noch nicht festgelegt. Es geht zunächst nur mal darum, Daten sinnvoll zu strukturieren und vollständig zu beschreiben.
Die beiden Beispiele enthalten ganz unterschiedliche Elemente, Attribute, Wertzuweisungen und typische Verschachtelungen. Gemeinsam ist ihnen jedoch, dass sie offensichtlich aus bestimmten erlaubten Elementen, Attributen, Wertzuweisungen und Regeln zur Verschachtelung bestehen. In den beiden Beispielen finden Sie diese Regeln nirgendwo beschrieben. Insofern sind es einfach Phantasiebeispiele. Es gibt jedoch ein standardisiertes Verfahren, um solche Regeln zu definieren und in den Auszeichnungssprachen anzugeben, auf welche Regeln man sich bezieht und wo diese Regeln definiert sind. Dieses standardisierte Verfahren ist XML.
Die Regeln für erlaubte Elemente, Attribute und Verschachtelungsmöglichkeiten einer XML-gerechten Auszeichnungssprache werden unabhängig von den eigentlichen Daten definiert. Die Daten mit den Definitionen stellen eine so genannte Dokumenttyp-Definition (engl. document type definition, Abkürzung DTD) dar. XML-fähige Software sollte idealerweise in der Lage sein, solche DTDs auszulesen und Daten, die auf diese DTD Bezug nehmen, nach den Regeln der DTD beurteilen zu können. Dabei kann die Software feststellen, ob innerhalb der XML-Daten, die sich auf eine bestimmte DTD beziehen, ungültige Notationen vorkommen. Ungültige Notationen sind z.B. Element- oder Attributnamen, die in der DTD nicht definiert werden, oder Elemente an Stellen, an denen sie aufgrund der DTD-Regeln nicht erlaubt sind. Das Verfahren, um zu überprüfen, ob eine XML-Datei nach den Regeln ihrer zugehörigen DTD fehlerfrei ist, nennt man Validierung (von engl. valid = gültig).
Neben den DTDs hat sich mittlerweile ein zweites Verfahren etabliert, um XML-Sprachen zu definieren: XML Schemata oder kurz XSD. Ein Vorteil von XML Schemata gegenüber herkömmlichen DTDs besteht darin, dass es sich selbst um eine XML-Sprache handelt. Die DTD-Syntax leitet sich dagegen von SGML ab, der historischen Mutter aller Auszeichnungssprachen. Ein anderer Vorteil besteht darin, dass sich in XML Schemata Datentypen definieren lassen. Dadurch lässt sich angeben, ob Elementinhalte beispielsweise nummerisch oder als Datum zu interpetieren sind.
Das Verfahren mit den Sprachdefinition und der Validierung mag anfangs etwas umständlich und aufwendig erscheinen. Doch nur durch dieses Verfahren ist sichergestellt, dass XML-Sprachen nicht nur Phantasiegebilde sind, sondern Sprachen, die sich an bestimmte, genau definierte Regeln halten. Nur so ist es möglich, dass sich verschiedene Autoren und verschiedene Software-Produkte an die Konventionen einer Sprache halten und die Sprache nicht durch spontane, undefinierte Erweiterungen verwässert und für interpretierende Software unbrauchbar wird. Eine DTD- oder XML-Schema-basierte XML-Sprache zu erweitern ist durchaus möglich, aber wenn, dann auf dem dafür vorgesehenen Weg, nämlich durch Erweiterung der entsprechenden DTD oder des Schemas.
<!ELEMENT nachricht (titel,text,datum,redakteur)> <!-- Eine Nachricht besteht aus Titel, Text, Datum und Redakteur --> <!ELEMENT titel (#PCDATA)> <!-- Der Titel enthaelt den Titeltext, sonst nichts --> <!ELEMENT text (#PCDATA)> <!-- Der Text enthält den Nachrichtentext, sonst nichts --> <!ELEMENT datum (#PCDATA)> <!-- Das Datum enthaelt die Datumsangabe, sonst nichts --> <!ELEMENT redakteur (#PCDATA)> <!-- "redakteur" enthaelt die Angabe zum Redakteur, sonst nichts -->
Das Beispiel zeigt, wie DTD-Definitionen aussehen, und welche Konsequenzen sie haben. In dem Beispiel werden verschiedene Elementtypen definiert. Das sind gewissermaßen die logischen Vorlagen für Elemente. Eine Definition wie z.B. <!ELEMENT titel (#PCDATA)> bedeutet, dass es in dieser XML-Sprache ein Element titel gibt, das durch die Tags <titel>…</titel> ausgezeichnet wird. Aus den Regeln des Beispiels geht außerdem hervor, dass <titel>…</titel> (und ebenso <text>…</text>, <datum>…</datum> und <redakteur>…</redakteur>) nur innerhalb von <nachricht>…</nachricht> vorkommen darf. Alles, was im Beispiel zwischen <!— … —> steht, ist ein Kommentar und gehört nicht zu den eigentlichen Definitionen.
Aufgrund der Definitionen im obigen Beispiel könnte eine XML-Datei, die sich auf diese Definitionen bezieht, folgende Daten enthalten:
<nachricht> <titel>HTML5-Handbuch erschienen!</titel> <text> Wie der Franzis-Buchverlag heute mitteilte, ist das HTML5-Handbuch mittlerweile an den Handel ausgeliefert worden. Von Schlangen, die sich vor Öffnung der Buchläden an den Türen bildeten, ist zwar nichts bekannt. Aber das kann sich ja noch ändern. </text> <datum>10.12.2010</datum> <redakteur>Ferdinand Schreiberling</redakteur> </nachricht>
Dem Beispiel können Sie entnehmen, dass die Regeln, die zuvor in der Beispiel-DTD definiert wurden, eingehalten wurden. Es gibt das übergreifende Element nachricht, ausgezeichnet durch die Tags <nachricht>…</nachricht>. Innerhalb davon sind die anderen Elemente, die eine Nachricht ausmachen, notiert und mit konkreten Daten versehen. Fragen, die Sie sich jetzt stellen mögen, etwa die, wie eine Datendatei sich auf eine DTD bezieht, werden an dieser Stelle ausgeklammert. Es geht hier nur darum, das Verständnis dafür zu entwickeln, dass das, was man als XML bezeichnet, immer aus dieser Zweiteilung besteht: nämlich aus der Definition von Regeln für eine bestimmte Auszeichnungssprache, und in der konkreten Anwendung dieser Regeln innerhalb dieser Auszeichnungssprache.
Ein XML-gerechtes Dokument besteht aus Elementen, Attributen, ihren Wertzuweisungen, und dem Inhalt der Elemente, der aus Text oder aus untergeordneten Elementen bestehen kann, die ihrerseits wieder Attribute mit Wertzuweisungen und Inhalt haben können. Es gibt Elemente mit und ohne Attribute, Elemente, innerhalb deren viele andere Elemente vorkommen können, und solche, innerhalb deren nur Text vorkommen kann, und sogar leere Elemente, die keinen Inhalt haben können. Die Struktur, die aus diesen Bestandteilen und ihren Grundregeln entsteht, lässt sich als Baumstruktur begreifen.
<spielfilme> <film regie="Tom Tykwer" titel="Lola rennt"> <beschreibung> <name typ="w">Lola</name> rennt für <name typ="m">Manni</name>, der 100000 Mark liegengelassen hat und noch 20 Minuten Zeit hat, das Geld auszuliefern. </beschreibung> </film> </spielfilme>
Wenn man von Knoten redet, meint man die Bestandteile der Baumstruktur.
Jedes XML-Dokument beginnt mit einem Wurzelknoten. Dieser hat jedoch keine konkrete Ausprägung, sondern ist nur der abstrakte Ursprung der Daten. Erst sein unmittelbarer Abkömmling in der Baumstruktur hat eine konkrete Ausprägung: nämlich das Dokument-Element, also das äußerste, den gesamten übrigen Inhalt umfassende Element. Im obigen Beispiel ist dies das Element spielfilme. Aus XML-Sicht ist es das Dokumentelement. Dieser oberste Knoten unterhalb des abstrakten Wurzelknotens hat im Beispiel einen Kindknoten namens film. Aus Sicht des Knotens film ist der Knoten spielfilme der Elternknoten. Der Knoten film hat drei untergeordnete Knoten, nämlich die Attribute regie und titel sowie das Element beschreibung. In der XML-Praxis werden jedoch Attribute eines Elements anders eingestuft als der Inhalt des Elements. Bei Attributknoten spricht man von assoziierten Knoten, beim Inhalt dagegen von Kindknoten.
Ein Attribut wie regie hat zwar selber noch mal einen eigenen Kindknoten, nämlich den Text Tom Tykwer, aber der Wert eines Attributes kann in XML nicht direkt adressiert werden. Jeder andere in der Baumstruktur abbildbare Bestandteil ist also ein Knoten.
Wenn man von Knoten-Sets redet, denkt man aus Sicht der Wege zu den einzelnen Knoten.
Um einzelne Knoten zu adressieren, kann man den Pfad dorthin angeben, ganz ähnlich wie in einer Struktur aus Verzeichnissen, Unterverzeichnissen und Dateien. So hat im Beispiel das erste vorkommende Element name, das ja auch ein Knoten ist, den Pfad /spielfilme/film/beschreibung. Das zweite vorkommende Element name hat allerdings den gleichen Pfad, ebenso wie der restliche Text, der den Inhalt des Elements beschreibung bildet. Wenn man also aus Sicht eines Pfades in der Baumstruktur denkt, gibt es unterhalb eines solchen Pfades keinen, einen oder mehrere Knoten. Diese zunächst unbestimmte Anzahl Knoten, die unterhalb eines bestimmten Pfades liegen, bezeichnet man als Knoten-Set.
XML-basierte Dateien enthalten nichts anderes als logische Auszeichnungen (auch semantische Auszeichnungen genannt). Eine Auszeichnung wie <beschreibung>…</beschreibung> sagt nur etwas über die Bedeutung der an dieser Stelle gespeicherten Daten aus, aber nichts darüber, wie solche Daten darzustellen sind. Die so bezeichneten Daten sind völlig unabhängig vom Ausgabemedium (etwa Bildschirm, Display, Lautsprecher, Drucker), und sie enthalten keinerlei Angaben zur Formatierung (Schriftart, Schriftgröße, Farben usw.). Im Gegensatz zu HTML-Daten, für deren Darstellung ein Browser Default-Werte benutzt, hat er bei XML-Daten keine Anhaltspunkte, wie diese darzustellen sind. Bevor Sie solche Daten also präsentieren können, müssen Sie mit Hilfe einer Style-Sprache angeben, wie die Daten formatiert werden sollen.
Dazu stehen heute zwei Formatsprachen zur Verfügung: CSS und XSL. CSS (Cascading Stylesheets), das auch für HTML eingesetzt wird, ist dabei die „Brot- und Buttersprache“. Sie genügt, um etwa einem Web-Browser mitzuteilen, wie er die Elemente einer XML-Datei darstellen soll. XSL ist dagegen wesentlich mächtiger und enger an den Konzepten von XML orientiert.
XSLT ist eine Komponente der XML-Style-Sprache XSL. Mit Hilfe von XSLT können Sie Daten von einer XML-Sprache in eine beliebige andere XML-Sprache transferieren (konvertieren). So können Sie beispielsweise auch XML-Daten in (X)HTML transformieren — und zwar, bevor der Browser überhaupt etwas davon mitbekommt, also server-seitig. Der Web-Server benötigt dazu eine Schnittstelle, die das Einbinden eines XSL/XSLT-verarbeitenden Software-Moduls erlaubt.
Wenn Sie beispielsweise XML-Daten in HTML transformieren, dann stellen Sie eine Verbindung zwischen Elementen und Attributen Ihrer XML-Daten und bestimmten HTML-Konstrukten her. So können Sie im XSLT-Stylesheet beispielsweise angeben, dass ein Element namens vorname in den HTML-Code <td>[…]</td> umgesetzt werden soll. Wenn Sie nun in Ihren XML-Anwendungsdaten das XSL-Stylesheet einbinden und beispielsweise <vorname>Stefan</vorname> notieren, dann wird daraus beim Transformieren als Ergebnis das HTML-Konstrukt <td>Stefan</td> erzeugt.
Man spricht auch von einem Quellbaum in einen Ergebnisbaum. Dahinter steht die Tatsache, dass sich alle XML-basierten Daten als Baumstruktur darstellen lassen. Das folgende Schaubild verdeutlicht, wie aus einem Quellbaum ein Ergebnisbaum wird — natürlich handelt es sich dabei nur um einen kleinen Ausschnitt:
Durch die Zuordnung zu einer DTD gehören Elemente und Attribute dem Namensraum dieser DTD an. Fehlt jedoch die Dokumenttyp-Deklaration, dann gibt es keine solche eindeutige Zuordnung. Es bleibt unklar, woher (d.h. aus welchem Namensraum) die verwendeten Element- und Attributnamen kommen. Dazu besteht die Möglichkeit, bei einem Elementnamen oder Attributnamen explizit einen Namensraum anzugeben.
Besonders wichtig ist die Bezeichnung des Namensraums, wenn sich Namen von Elementen oder Attributen aus unterschiedlichen Namensräumen in die Quere kommen. Angenommen, in einem XML-Dokument gibt es zweimal ein Element namens div. Einmal bezieht es sich auf einen eigenen Namensraum, und einmal soll es als HTML-Element fungieren. Nur durch die Zuordnung zu einem bestimmten Namensraum ist in dem Fall klar, in welchem Kontext das Element interpretiert werden soll.
Zu diesem Zweck hat das W3-Konsortium den Begriff der qualifizierten Namen (engl. qualified names) eingeführt. Qualifizierte Namen bestehen immer aus einem Präfix, der den Namensraum bezeichnet, und einem lokalen Namensteil, der den Namen des Elements oder Attributs innerhalb des Namensraums bezeichnet. Beim Arbeiten mit mehreren Namensräumen gleichzeitig ist es wichtig, qualifizierte Namen zu notieren.
Sie können innerhalb eines XML-Dokuments „Inseln“ mit Daten aus bestimmten Namensräumen definieren.
<?xml version="1.0" encoding="utf-8" ?> <buch xmlns="http://www.meinserver.de/XML/buch"> <kapitel nummer="1"> <html xmlns="http://www.w3.org/1999/xhtml"> <head><title>Einleitung</title></head> <body> <h1>Einleitung</h1> <p>Das Buch beginnt mit diesem Text...</p> </body> </html> </kapitel> </buch>
Das Beispiel zeigt ein XML-Dokument. Es enthält ein Dokumentelement namens buch. In dessen Einleitungs-Tag ist eine XML-Namensraumdeklaration enthalten. Dazu wird in dem einleitenden Tag das Attribut xmlns notiert (xmlns = XML name space, also XML-Namensraum). Dahinter folgt eine URL-Adresse, die angibt, auf welchen anderen Namensraum in diesem Element Bezug genommen wird. Die URL muss nicht unbedingt eine tatsächlich aufrufbare Adresse sein. Es handelt sich um eine reine Konvention, vergleichbar einer eindeutigen Namensvergabe. Bei eigenen XML-Sprachen können Sie diese Adressen selbst vergeben. Im Beispiel wird http://www.meinserver.de/XML/buch gewählt. Das buch-Element selbst und seine untergeordneten Elemente (Kindelemente) — z.B. das Element kapitel — beziehen sich nun auf den definierten Namensraum. Unterhalb des kapitel-Elements ist im Beispiel jedoch wieder ein Element mit Namensraumdeklaration enthalten: ein html-Element mit xmlns-Attribut. Im Fall von XHTML 4.0 sieht das W3-Konsortium dazu die Angabe http://www.w3.org/1999/xhtml vor. Alle Kindelemente, die nun zwischen <html> und </html> stehen, gehören zum XHTML-Namensraum (oder: zur XHTML-Dateninsel).
Korrekturen, Hinweise und Ergänzungen
Bitte scheut euch nicht und meldet, was auf dieser Seite sachlich falsch oder irreführend ist, was ergänzt werden sollte, was fehlt usw. Dazu bitte oben aus dem Menü Seite den Eintrag Diskutieren wählen. Es ist keine Anmeldung erforderlich, um Anmerkungen zu posten. Unpassende Postings, Spam usw. werden allerdings kommentarlos entfernt.