Validierung von Dokumenten

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

Die Wohlgeformtheit von XML ist eine minimale Anforderung. Begnügt man sich damit, muß das verarbeitende Programm eine Menge in blindem Glauben akzeptieren. Wenn wir ein XML-Dokument erstellen, das die Anforderungen einer bestimmten Anwendung erfüllen soll, tun wir uns keinen Gefallen, wenn ein unbekanntes Element, das wir womöglich noch nie gesehen haben, vom Parser ohne jeden Protest akzeptiert wird. Glücklicherweise steht uns eine wesentlich bessere Qualitätskontrolle zur Verfügung, wenn wir derlei Dinge überprüfen wollen: Wir können ein Dokument validieren.

Validierung ist eine sehr ausgetüftelte Art und Weise, eine Dokumentinstanz mit einem Template oder einer spezifizierten Grammatik zu vergleichen. Sowohl die Anzahl als auch der Typ und die Reihenfolge der Elemente eines Dokuments können überprüft werden. Selbst die Muster der Zeichendaten in Elementen oder Attributen können reguliert werden. Ein validierender Parser gibt darüber Auskunft, ob das Dokument gültig in bezug auf eine gegebene DTD oder ein Schema ist, indem er es damit vergleicht.

Denken Sie daran, daß Sie nicht jedes XML-Dokument validieren müssen, das über Ihren Schreibtisch rutscht. DTD und andere Validierungsschemata eignen sich hervorragend für die Arbeit mit XML-basierten Markup-Sprachen, für die ein Schema festgelegt wurde. Beispiele sind XHTML für Webseiten, MathML für mathematische Gleichungen oder CaveML für die Höhlenforschung. Die strikten Regeln der betreffenden Schemata entscheiden darüber, wo welche Elemente oder Attribute gültig sind. Das ist in diesen Fällen durchaus hilfreich, weil man im Zweifelsfall eine automatisierte Möglichkeit hat, auf eigene Fehler hingewiesen zu werden.

Dagegen ist eine Validierung nicht unbedingt sinnvoll, wenn man eine weniger spezifische Aufgabe mit Perl und XML durchführen möchte. Zum Beispiel kann eine Validierung bereits beim Aufbau eines XML-Dokuments zur Laufzeit eher hinderlich werden. Wenn das Datenformat weniger klar ist, dann kann das auch für das Lesen und die Analyse eines XML-Dokuments gelten.

Wenn Sie bei einer bestimmten Gelegenheit die Validierung eines Dokuments für überflüssig oder gar schlecht halten, dann können Sie also durchaus richtig liegen. Wenn Sie andererseits in einem eher komplizierten und standardisierten XML-Dialekt arbeiten, dann tun Sie vermutlich gut daran, den zusätzlichen Aufwand der Validierung zu akzeptieren, um deren Vorzüge zu genießen. Ihre Werkzeugkiste enthält mit Sicherheit Möglichkeiten, um dies auf eine relativ einfache Art zu bewerkstelligen. Lesen Sie dazu einfach weiter.

DTDs

Document Type Definitions (DTDs) sind Dokumente, die in einer speziellen Markup-Sprache verfaßt sind. Die Syntax der DTDs ist in der XML-Spezifikation festgelegt, obwohl die DTD selbst nicht in XML-Syntax verfaßt wird. Innerhalb einer DTD gibt es nur Deklarationen, die alle mit den Zeichen <! beginnen. Deklariert werden Elemente, Attribute, Entities oder Notationen.

Das folgende Beispiel ist eine relativ einfache DTD.

Beispiel: Eine niedliche kleine DTD

<!ELEMENT memo (to, from, message)>
<!ATTLIST memo priority (urgent|normal|info) 'normal'>
<!ENTITY % text-only "(#PCDATA)*">
<!ELEMENT to %text-only;>
<!ELEMENT from %text-only;>
<!ELEMENT message (#PCDATA | emphasis)*>
<!ELEMENT emphasis %text-only;>
<!ENTITY myname "Ronald McDonald">

Diese DTD deklariert fünf Elemente, ein Attribut des <memo> -Elements, ein Parameterentity, das die anderen Deklarationen verständlicher machen soll, sowie ein Entity, das innerhalb des Dokuments verwendet werden kann. Einem validierenden Parser genügen diese Informationen, um ein Dokument zu akzeptieren oder als ungültig zurückzuweisen. Zum Beispiel wäre das folgende ein gültiges Dokument:

<!DOCTYPE memo SYSTEM "/dtds/memo.dtd">
<memo priority="info">
  <to>Chicken McNugget</to>
  <from>&myname;</from>
  <message>Hör auf, Memos zu lesen, und mach Dich an die Arbeit!</message>
</memo>

Falls Sie das Element <to> entfernen würden, wäre das Dokument hingegen ungültig, obwohl eine Prüfung auf Wohlgeformtheit nach wie vor positiv verlaufen würde. Validierung kann also durchaus Sinn machen.

Eine DTD zu parsen ist relativ einfach. Aus diesem Grund bieten die meisten XML-Parser die Möglichkeit, ein Dokument beim Parsen gegen eine DTD zu validieren. Ein Beispiel ist XML::LibXML. Im folgenden Beispiel sehen Sie, wie das funktioniert.

Beispiel: Ein validierender Parser

use XML::LibXML;
use IO::Handle;    

# Initialisierung des Parsers
my $parser = new XML::LibXML;

# Erzeugen eines Dateihandles und Aufruf des Parsers
my $fh = new IO::Handle;
if( $fh->fdopen( fileno( STDIN ), "r" )) {
    my $doc = $parser->parse_fh( $fh );
    if( $doc and $doc->is_valid ) {
        print "Ja, das Dokument ist gültig.\n";
    } else {
        print "Krass! Das Dokument ist konkret ungültig.\n";
    }
    $fh->close;
}

Wann immer wir ein Dokument lesen, können wir diesen Parser problemlos verwenden. Unglücklicherweise gibt er uns wenig Auskunft über das vorhandene Problem, wenn ein Dokument als ungültig erkannt wurde. Zum Beispiel würden wir gerne wissen, wenn ein Element an einer falschen Stelle steht. Als allgemeines Werkzeug zur Prüfung der Gültigkeit eines Dokuments ist er also eher ungeeignet.

Der Autor bevorzugt ein kleines Kommandozeilen-Tool namens nsgmls. Es gibt auch verschiedene öffentliche Websites, die Dokumente validieren können. Beachten Sie, daß ein zu validierendes XML-Dokument in diesem Fall eine DOCTYPE-Deklaration haben muß, deren Systembezeichner (sofern vorhanden) eine öffentlich zugängliche URL sein muß und kein Pfad im lokalen Dateisystem.

Eine bessere Wahl wäre das Modul XML::Checker von T. J. Mather, das wesentlich konkretere Fehlermeldungen ausgibt.

Schemata

DTDs unterliegen einer Menge Beschränkungen. Zum Beispiel kann man nicht prüfen lassen, welche Art von Textdaten ein Element enthält und ob diese zum Beispiel mit einem vorgegebenen Muster übereinstimmen. Zum Beispiel wäre es schön, wenn ein Parser ein Element <datum> nur dann akzeptieren würde, wenn es auch tatsächlich ein Datum enthielte. In diesem Fall bräuchte man eine bessere Lösung wie zum Beispiel XML Schema. XML Schema ist eine Art DTD der zweiten Generation. Validierung gegen ein XML Schema ist ungleich vielseitiger und flexibler.

Wie wir bereits in Einführung in XML bemerkt haben, genießt XML Schema den etwas zweifelhaften Vorzug, die umstrittenste Schemasprache zu sein. Es gibt zahlreiche XML-Hacker, die das Konzept eines Schemas durchaus befürworten, aber XML Schema als zu komplex oder unverständlich ablehnen.

Alternativen zu XML Schema sind zum Beispiel RelaxNG von OASIS-Open oder Schematron von Rick Jelliffe. Wie XML Schema sind diese Spezifikationen selbst auf XML basierende Sprachen, die zur Beschreibung anderer XML-Sprachen verwendet werden. Wenn man einen geeigneten Parser hat, kann man das Schema zur Validierung anderer XML-Dokumente verwenden. Wir finden besonders Schematron sehr interessant, weil es mit XML::Schematron von Kip Hampton eine Familie von Perl-Modulen gibt, die diese Sprache zugänglich macht.

Schematron basiert auf Technologien, für die gute Perl-Implementierungen zur Verfügung stehen; ein weiterer Punkt, der aus der Sicht von Perl/XML-Hackern für die Sprache spricht. Schematron definiert eine sehr einfache Sprache, mit der man das Aussehen bestimmter Dinge spezifizieren kann. Diese Sprache basiert auf XPath-Ausdrücken. Man muß nicht unbedingt eine alles voraussehende Grammatik spezifizieren, die alles berücksichtigt, was möglicherweise in einem Dokument auftaucht. Statt dessen kann man sich dafür entscheiden, nur bestimmte Teile des Dokuments zu validieren. Man kann auch Elemente und Attribute abhängig von ganz anderen Teilen des Dokuments machen, sofern man das eben mit Hilfe eines XPath-Ausdrucks formulieren kann. In der Praxis läßt sich ein Schematron-Dokument am ehesten mit einem XSLT-Stylesheet vergleichen. Dafür gibt es einen Grund: Schematron ist so gemacht, daß man es mit Hilfe von XSLT implementieren kann. Tatsächlich funktionieren zwei der XML::Schematron-Module, indem sie das vom Benutzer vorgegebene Schema zunächst in ein XSLT-Stylesheet transformieren. Das zu validierende Dokument wird dann einfach mit Hilfe des XSLT-Prozessors geprüft.

Schematron kennt keinerlei eingebaute Datentypen. Man kann also zum Beispiel nicht mit einem Wort festlegen, daß ein Attribut das Datumsformat des W3C zu erfüllen hat. Man kann aber problemlos ein Perl-Programm einen zusätzlichen Schritt einlegen lassen und zum Beispiel mit Hilfe von XML::XPath oder über einen der guten, alten regulären Ausdrücke von Perl verifizieren, ob der Inhalt eines <datum>-Elements stimmt. Beachten Sie auch, daß keine Schemasprache Dinge wie den Vergleich eines Elements mit dem Inhalt einer Datenbank erlaubt oder irgendwelche anderen Aktionen außerhalb des Dokuments vorsieht. An dieser Stelle ist es sehr hilfreich, Perl und Schemata zu vermischen.

  

  

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