Eventorientierte vs. baumorientierte Verarbeitung

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

Erinnern Sie sich an das Perl-Motto »Es gibt mehr als eine Möglichkeit« (»There’s more than one way to do it«)? Das gilt auch für die Arbeit mit XML. Je nachdem, wie man arbeiten möchte, und abhängig von den vorhandenen Ressourcen, gibt es verschiedene Optionen. Ein Entwickler wird vielleicht eine einfache und leicht zu pflegende Lösung bevorzugen, auch wenn das einen eher schlampigen Umgang mit dem verfügbaren Speicher bedeutet. Ein anderer wird die Betonung auf Geschwindigkeit und Schonung von Ressourcen legen, auch wenn das das Programm erheblich komplizierter macht. Die Aufgaben bei der Verarbeitung von XML sind völlig verschieden, so daß man stets von neuem die passende Lösung auswählen sollte.

Es gibt eine ganze Reihe verschiedener Strategien beim Umgang mit XML. Die meisten fallen in eine von zwei Kategorien: eventorientiert oder baumorientiert. Bei der eventorientierten Strategie wird das Programm permanent vom Parser aufgerufen, der Informationen über die einzelnen Bestandteile des Dokuments übermittelt. Wie in einer Pipeline steckt der XML-Parser am einen Ende XML-Markup hinein, und am anderen Ende purzeln fertig verarbeitete Daten einzeln in Ihr Programm. Diese Pipeline trägt den Namen Eventstrom , weshalb dieses Modell auch stromorientiert genannt wird. Jedes Event und die darin übergebenen Daten signalisieren dem Programm neue und interessante Informationen über den XML-Strom. Zum Beispiel ist der Beginn eines neuen Elements ein sehr bedeutsames Ereignis, ebenso die Entdeckung einer PI im Markup. Jedes Event kann neue Aktionen des Programms bewirken – möglicherweise werden die Daten übersetzt oder an eine andere Stelle übermittelt, auf bestimmte Inhalte hin untersucht oder in einem wachsenden Datenspeicher abgelegt.

Bei der baumorientierten Strategie bewahrt der Parser die Daten selbst auf, bis er das Ende des XML-Dokuments entdeckt. Die aufbewahrten Daten repräsentieren das übergebene Dokument, das in seiner Gesamtheit als Ergebnis an das Programm übergeben wird. Statt einer Pipeline sollte man hier eher eine Kamera als Bild bemühen, die ein Foto macht und diese Replikation als Ergebnis liefert. Meistens ist es erheblich angenehmer, mit der Repräsentation in Form von Datenstrukturen zu arbeiten als mit rohem XML. Zum Beispiel kann man ohne weiteres die gewohnten Arrays und Hashes von Perl verwenden, um die verschachtelten Strukturen des XML-Dokuments abzubilden. Wir haben das bereits in der Ausgabe des vorigen Beispielprogramms gesehen. Noch nützlicher sind meistens Bäume aus Objekten mit Methoden, die die Navigation innerhalb des Baums erleichtern. Der wesentliche Punkt an dieser Vorgehensweise ist eben, daß Ihr Programm genau die Daten anschauen kann, die für Sie wichtig sind – und zwar in beliebiger Reihenfolge.

Warum gibt es zwei Modelle? Jedes hat seine Stärken und Schwächen. Eventströme sind schnell und sehr genügsam, was ihren Bedarf an Hauptspeicher angeht. Andererseits sind sie fast immer komplizierter zu implementieren, und man muß selbst eine geeignete Struktur für die Aufbewahrung der relevanten Daten erzeugen. Läßt man sich einen Baum aufbauen, dann werden die Daten konserviert, solange man sie benötigt, und man kann sich nach Belieben im Baum vor und zurück bewegen. Dadurch entfällt die Notwendigkeit, selbst für die Speicherung von Informationen zu sorgen. Bäume haben aber sehr deutliche Schwächen, wenn es um den ökonomischen Gebrauch von CPU und Hauptspeicher geht.

Alle diese Überlegungen sind natürlich stets relativ. Kleinere Dokumente stellen für einen normalen Computer keine Herausforderung dar, mit jedem Tag werden der CPU-Takt schneller und die Megabytes billiger. Die Vorzüge einer persistenten Datenstruktur überwiegen hier enorm. Wenn man dagegen mit Monsterdokumenten arbeitet, die zum Beispiel ganze Bücher enthalten, dann werden Sie den dafür benötigten Aufwand bei einem Baummodell mit Sicherheit bemerken. Die Arbeit mit einem Eventstrom wird sich hier sehr rasch auszahlen. Leider ist es – von diesen Bemerkungen abgesehen – nicht möglich, eine Faustregel aufzustellen. Aus diesem Grund überlassen wir die Entscheidung für oder gegen eines dieser Modelle besser Ihnen.

Interessant ist möglicherweise der Zusammenhang zwischen dem event- und dem baumorientierten Modell: Ersteres ist die Basis des letzteren. Tatsächlich, der Aufbau einer Baumstruktur funktioniert intern durch den Empfang von Events. Aus diesem Grund erzeugen die meisten Parser auf niederer Ebene Eventströme: Man kann ohne weiteres einen Baum davon ableiten. Die meisten Parser, unter anderem auch XML::Parser, arbeiten so.

Auf ganz ähnliche Weise kann man auch XML-Eventströme dazu verwenden, beliebige Arten von Dokumenten in XML zu konvertieren, indem man Parser schreibt, die die Datenstrukturen des jeweiligen Dokuments in XML-Events abbilden. Das ist eine neuere und echt coole Entwicklung.

Man kann noch viel, viel mehr über Eventströme und den Aufbau von Bäumen sagen – so viel, daß wir diesen Themen gleich zwei ganze Abschnitte gewidmet haben. In Eventströme werden wir uns ausführlich mit der Theorie der Eventströme beschäftigen, indem wir eine Vielzahl von Beispielen vorstellen, wie man daraus nützliche Programme macht. In Baumorientierte Verarbeitung begeben wir uns dann tiefer in den Wald voller baumorientierter Beispiele. Und anschließend zeigt Arbeit mit Bäumen: XPath, XSLT und mehr einige ungewöhnliche Beispiele von hybriden Anwendungen, die das beste aus beiden Welten verbinden.

  

  

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