Markup, Elemente und Struktur

(Auszug aus "Perl & XML" von Erik T. Ray & Jason McIntosh)

Eine Markup-Sprache bietet die Möglichkeit, Daten mit einer Beschreibung zu versehen, die dann einem Computer die Möglichkeit zur Verarbeitung gibt. Die meisten Markup-Sprachen sind für einen bestimmten Zweck optimiert. Zum Beispiel widmen sich troff, TeX und HTML der Ausgabe von Dokumenten auf den Drucker oder den Bildschirm. Diese Sprachen ermöglichen eine präsentationsorientierte Beschreibung der Daten. Sie kontrollieren den Zeichensatz, die Zeichengröße, -farbe und ähnliche Eigenschaften. Das Ergebnis solcher Markup-Sprachen ist ein hübsch aussehendes Dokument, aber für die darin stehenden Daten kann eine solche Sprache ein regelrechtes Gefängnis sein: Die reinen Daten zu extrahieren, um sie für einen anderen Zweck zu verwenden, kann mit beträchtlichem Aufwand verbunden sein.

An dieser Stelle kommt XML ins Spiel. Es ist eine generische Markup-Sprache, die Daten anhand ihrer Struktur und ihres Zwecks beschreibt und keine Anweisungen für eine bestimmte Aufgabe gibt. Die für die Präsentation nötigen Informationen werden normalerweise an anderer Stelle abgelegt, zum Beispiel in einem Stylesheet. Damit bleibt eine funktionale Beschreibung Ihres Dokuments übrig, die für viele verschiedene Aufgaben geeignet ist. Wird XML sinnvoll eingesetzt, dann steht Ihnen eine praktisch unbegrenzte Menge von Möglichkeiten und Programmen zur Verfügung.

Schauen wir uns einmal die grundlegenden Komponenten von XML an. Der wichtigste Baustein ist das Element . Elemente sind verschachtelte Teile des Dokuments, die die darin enthaltenen Daten umfassen. Nehmen wir zum Beispiel ein typisches Buch. Es enthält ein Vorwort, verschiedene Kapitel, Anhänge und einen Index. In XML würde jeder dieser Abschnitte innerhalb genau eines Elements stehen. Elemente können andere Elemente enthalten. Das paßt beim Buch sehr gut, man kann jeweils ein weiteres Element für den Titel des Buchs oder des Kapitels, für die Absätze, Beispiele und Teilkapitel verwenden. Diese Gliederung kann nach Belieben fortgesetzt werden, z. B. kann ein Teilkapitel kleinere Teile enthalten, oder ein Absatz kann andere Elemente enthalten, die hervorgehobenen Text, Zitate oder Hypertextlinks markieren.

Abgesehen von der Fraktionierung eines Texts in hierarchisch angeordnete Textbereiche, erlauben Elemente auch, einen Dokumentbereich mit einer beschreibenden Bezeichnung und Eigenschaften zu versehen. Jedes Element hat einen Namen oder Elementtyp , der normalerweise die Funktion des Elements innerhalb des enthaltenden Elements oder des Dokuments erklärt. Ein Kapitelelement könnte »chapter« heißen (oder »kapitel« oder »ch« – was Ihnen lieber ist). Ein Element kann außer seinem Typ auch weitere Eigenschaften in Form von Name/Wert-Paaren besitzen. Diese Eigenschaften heißen Attribute. Der Typ eines Elements und seine Attribute dienen zur Unterscheidung von anderen Elementen desselben Dokuments.

Das folgende Beispiel zeigt ein typisches Stück XML.

Beispiel: Ein XML-Fragment

<list id="eriks-aufgaben-47">
  <title>Dinge, die ich diese Woche erledigen sollte</title>
  <item>Das Aquarium reinigen</item>
  <item>Staubsaugen</item>
  <item priority="wichtig">Die Wale retten</item>
</list>

Sie haben es schon erraten, es handelt sich um eine Liste dreier Aufgaben mit einem Titel. Selbst mit geringen HTML-Kenntnissen wird man die Struktur des Markup verstehen. Die in Kleiner- und Größer-Zeichen (< und >) eingebetteten Wörter sind die sogenannten Tags . Sie sind gewissermaßen die Buchstützen der Elemente. Jedes nicht-leere Element besitzt ein Start-Tag und ein End-Tag. Beide tragen den Elementtyp als Namen. Das Start-Tag darf Attribute enthalten (d. h. Paare aus Attributnamen und -wert wie priority="wichtig" ). Damit ist der Markup klar verständlich und ohne Zweideutigkeiten – selbst ein Mensch kann das lesen.

Ein Mensch kann es lesen, aber was noch wichtiger ist: Ein Computerprogramm kann es besonders einfach lesen. Die Entwickler von XML haben sich große Mühe gegeben, die Arbeit der XML-Parser zu erleichtern, damit das Dokument möglichst einfach von jedem beliebigen XML-Prozessor lesbar ist – und zwar unabhängig von den Tag-Namen oder dem Zusammenhang, in dem das Dokument steht. Wenn sich Ihr Markup korrekt an die Syntaxregeln hält, dann ist Ihr XML-Dokument frei von Unklarheiten. Die Verarbeitung wird dadurch erheblich vereinfacht, denn man kann sich Code zur Behandlung exotischer Sonderfälle sparen.

Betrachten wir zum Vergleich HTML, wie es ursprünglich definiert war (als eine Anwendung des XML-Vorgängers SGML). (Anmerkung: Bereits jetzt sind HTML-Autoren angehalten, nicht klassisches HTML zu schreiben, sondern XHTML, eine an XML angepaßte und aufwärtskompatible Variante von HTML. XHTML wird bereits jetzt von den neueren Browsern unterstützt. In absehbarer Zeit werden auch noch eine Menge Tools (XHTML-Editoren, Syntaxprüfer oder Formatierer) hinzukommen. XML erleichtert die Verarbeitung durch verschiedene Programme. Vermutlich wird man im Web bald öfter DocBook und MathML als weitere von XML abgeleitete Sprachen finden, die dann neben HTML treten.) Für gewisse Elemente war es akzeptabel, die End-Tags wegzulassen. Tatsächlich war es aus dem Kontext heraus oft möglich, zu beurteilen, wo ein Element enden sollte. Trotzdem war der Aufwand zur Auflösung solcher zweideutiger Situationen enorm und immer noch mit gelegentlichen Fehlern verbunden. Stellen wir uns als nächstes einen Prozessor vor, der jeden beliebigen Elementtyp und nicht nur die HTML-Elemente behandeln muß. Jedes Gefühl für den Kontext geht verloren. XML-Prozessoren können nicht raten, wie Elemente genau anzuordnen sind. Eine zweideutige Situation wie das Weglassen eines End-Tags könnte zu einem Desaster führen.

Man kann XML-Stücke wie das obige in einem Diagramm darstellen, das wir als Baum bezeichnen. Die meisten Programmierer sind mit dieser Struktur vertraut. Am oberen Ende (in der Informatik wachsen Bäume von oben nach unten) ist das sogenannte Wurzelelement. Vom Wurzelelement zweigen diejenigen Elemente ab, die in der Hierarchie eine Stufe tiefer stehen. Jedes Element kann seinerseits weitere Elemente enthalten und so weiter. Irgendwann endet man aber in jedem Fall bei Elementen ohne Kinder, den Blättern, die den Boden des Baums darstellen. Die Blätter enthalten Textdaten, sie können aber auch leer sein. Jedes Element, egal wo es sitzt, ist stets der Stamm seines eigenen Baums (oder Unterbaums, wenn Ihnen das lieber ist). Ein Baumdiagramm des vorigen Beispiels sehen Sie in der folgenden Abbildung.

Die Aufgabenliste als Baumstruktur

Abbildung: Die Aufgabenliste als Baumstruktur

Neben der Analogie zu Bäumen verwendet man in einem XML-Dokument auch gerne Begriffe aus der Genealogie. Die in einem Element enthaltenen Daten und Elemente werden dann als dessen Kinder bezeichnet. Das enthaltende Element ist der Vater (das Eltern-Element ) seiner Kinder. Entsprechend spricht man auch von Nachkommen oder Ahnen, wenn diese einige Stufen entfernt sind. In unserem Beispiel sind die <item>-Elemente Kinder desselben Vaters, des <list>-Elements. Zusammen sind sie Geschwister der jeweils anderen. (Damit lassen wir es aber auch bewenden, denn vom Enkel des Cousins dritten Grades zu sprechen wäre wohl eher verwirrend.) Wir werden in diesem Buch sowohl die Baumbezeichnungen als auch die Familienterminologie verwenden, um die Beziehungen zwischen den verschiedenen Elementen zu beschreiben.

  

  

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema Perl & XML bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

Copyright © 2003 O'Reilly Verlag GmbH & Co. KG
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "Perl & XML" 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.

O’Reilly Verlag GmbH & Co. KG, Balthasarstraße 81, 50670 Köln, kommentar(at)oreilly.de