Denken Sie daran...

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

In vielen Fällen werden Sie feststellen, daß die XML-Module von CPAN bereits 90 Prozent Ihrer Anforderungen erfüllen. Die restlichen 10 Prozent machen allerdings genau den Unterschied zwischen den unersetzbaren Angestellten und denjenigen aus, die beim nächsten Einbruch der Börse auf der Straße stehen. Wir werden unser Bestes tun, daß Sie Ihr in dieses Buch investiertes Geld wieder zurückbekommen. Dazu zeigen wir Ihnen im Detail, wie XML-Verarbeitung in Perl selbst auf der niedrigsten Ebene funktioniert (niedrig im Vergleich zu anderen spezialisierten Formen der Textmanipulation, die man in Perl gewohnt ist). Zu diesem Zweck wollen wir zunächst einmal einige grundlegende Fakten festhalten:

Woher es kommt, ist egal. Sobald der Teil des Programms startet, der das XML-Dokument tatsächlich analysiert, interessiert es uns nicht mehr, von wo diese Daten stammen. Sie können über das Netzwerk gelesen worden sein, aus einer Datenbank stammen oder von der Festplatte. Für den Parser ist es einfach mehr oder weniger ordentliches XML, alles andere interessiert ihn nicht.

Das gilt natürlich nicht für den Rest des Programms bzw. die Anwendung als Ganzes. Wenn wir z. B. auf die Idee kämen, XML-RPC zu implementieren, dann sollten wir besser genau wissen, wie man mit TCP Daten über das Internet schickt oder liest! Aber auf welche Weise wir dieses Problem auch lösen, in jedem Fall müssten wir dasselbe Endprodukt haben: ein sauberes XML-Dokument, wie es unser XML-Prozessor erwartet.

Wir werden uns später in diesem Buch anhand einiger umfangreicherer Beispiele noch damit beschäftigen.

Strukturell sind alle XML-Dokumente ähnlich. Es ist egal, warum oder wie sie zusammengestellt wurden oder wofür sie verwendet werden, alle XML-Dokumente müssen die syntaktischen Regeln der Wohlgeformtheit einhalten: genau ein Wurzelelement, alle Attribute haben Werte, die in einfachen oder zweifachen Anführungszeichen stehen, und so weiter. Die Parserkomponente eines jeden XML-Prozessors wird im Kern dieselben Dinge tun. Konsequenterweise könnten sich alle diese Prozessoren also einen gemeinsamen Kern teilen. In der Praxis geschieht das auch durch den Einsatz eines der frei verfügbaren Parsermodule, nur ganz gelegentlich findet man jemanden, der die Syntaxanalyse eines XML-Dokuments von Hand durchführt.

Die Philosophie »Ein Dokument, ein Element« von XML macht die Verarbeitung von XML gelegentlich zu einem geradezu fraktalen Erlebnis. Ein Dokument, das vom Parser als externes Entity gelesen wird (womöglich von einer ganz anderen Quelle), um es in ein anderes einzufügen, wird dort einfach zu »noch einem Element«. Derselbe Code, der sich Augenblicke vorher noch durch das ursprüngliche Dokument gewühlt hat, verarbeitet im nächsten Moment ein ganz anderes, ohne es zu merken.

In der Bedeutung sind XML-Anwendungen trotzdem verschieden. XML-Anwendungen sind die Existenzberechtigung eines jeden XML-Dokuments, sie definieren auf höherer Ebene weitere Regeln, die das XML-Dokument erfüllen muß, um für einen gewissen Zweck nutzbar zu sein. Egal, ob eine Konfigurationsdatei ausgefüllt werden soll, ein Dokument über das Netzwerk verschickt wird oder die Beschreibung eines Comic-Strips zu speichern ist: XML-Anwendungen geben einem normalen XML-Dokument nicht nur einen höheren Sinn, sie stellen Anforderungen, die das Dokument erfüllen muß. Aus diesem Grund gibt es z. B. unzählige Spezifikationen, die auf XML basieren.

Eine DTD hilft, die Konsistenz der Struktur zu sichern, die durch diese zusätzlichen Regeln vorgegeben wird. Natürlich benötigt eine Anwendung nicht unbedingt ein formales Validierungsschema. Wenn man aber sicherstellen will, daß bei späteren Programmänderungen niemand von dem Pfad abweicht, den man im Sinn hat (am wenigsten man selbst, zwei Wochen später), dann definiert man am besten gewisse Validierungsregeln, die einzuhalten sind. Ganz besonders gilt das, wenn auch andere Leute Programme schreiben sollen, die mit denselben XML-Dokumenten arbeiten werden.

Das Leben eines XML-Programmierers bewegt sich in der Grauzone dieser Dualität von Anwendung und Dokument. In den meisten Fällen wird es für jeden dieser Fakten in Ihrer Software einen Teil geben, der sich damit beschäftigt:

  • Auf irgendeine angemessene Art und Weise wird ein Eingabedokument gelesen – eine Netzwerkanwendung könnte es von einem Socket lesen, eine andere Anwendung würde vielleicht eine Datei laden. Im XML-Bereich ist das normal, und für einen Perl-Programmierer ist Flexibilität selbstverständlich: Mach was Du willst, Hauptsache Du gibst mir die Daten.
  • Die gelesenen Daten werden an einen XML-Prozessor übergeben. Wir würden ein Doughnut darauf verwetten, daß Sie dazu früher oder später einen der Parser verwenden werden, die die Perl-Gemeinschaft in der Vergangenheit bereits geschrieben hat und die laufend weiterentwickelt werden. Ob es XML::Simple ist oder eines der etwas raffinierteren Module, spielt dabei keine Rolle.
  • Was auch immer der Prozessor mit dem XML gemacht hat, irgendwann wird eine Ausgabe produziert werden. Möglicherweise wird wieder XML (oder wenigstens HTML) ausgegeben, eine Datenbankänderung wird vorgenommen, oder eine E-Mail wird an Ihre Mami geschickt. Dies ist der wesentliche Punkt unserer XML-Anwendung – das XML-Dokument soll irgend etwas Nützliches auslösen. Wir können hier nicht einmal annähernd alle Möglichkeiten aufzählen, aber wir können und wollen noch näher auf die bedeutsame Verbindung zwischen dem XML-Prozessor und dem restlichen Programm eingehen.

  

  

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