4 Die Transformationssprache XSLT 41
5.6 STX-Konzepte
5.6.8 Fehlerbehandlung und Logging in STX
Fehlerkategorien Die in der Sprache STX auftretenden Fehler lassen sich grob in die folgenden Kate-gorien einteilen:
Syntaxfehler
sind Fehler, die auf nicht wohlgeformtes XML oder Verstöße gegen das Schema für STX zurückzuführen sind.
Statische Semantikfehler
sind Fehler, die zur Compile-Zeit erkannt werden können, z.B. der Aufruf einer unbekannten Funktion, die Referenzierung einer nichtdefinierten Variable oder die Verwendung eines bereits vergebenen Gruppennamens.
Dynamische Fehler
sind Fehler, die erst zur Laufzeit auftreten und von den konkreten Eingabedaten abhängen, wie beispielsweise die dynamische Erzeugung von Elementen, Kom-mentaren oder Verarbeitungsanweisungen.
Logische Fehler
sind Fehler, die nicht vom STX-Prozessor erkannt werden können, die sich jedoch durch falsche Transformationsergebnisse bemerkbar machen.
Syntaxfehler
Fehler der ersten Kategorie sind sehr leicht zu erkennen. So werden Fehler auf XML-Ebene bereits vom XML-Parser gemeldet. Verstöße gegen das XML-Schema (siehe Anhang A) können durch geeignete Validierungswerkzeuge erkannt werden. Auch ohne entsprechende Werkzeugunterstützung sollte ein STX-Prozessor bei der Analyse des STX-Transformations-Sheet immer Schemaverstöße melden und die Verarbeitung abbrechen. Häufige Ursachen für Fehler in dieser Kategorie sind Schreibfehler bei Element- oder Attributnamen, fehlende Attribute oder inkorrekte Verschachtelungen der einzelnen STX-Anweisungen.
In die gleiche Kategorie fallen Syntaxfehler innerhalb von STXPath-Ausdrücken.
Für solche Ausdrücke existiert eine eigene Grammatik (siehe Anhang B.2), mit deren Hilfe der in einem STX-Prozessor enthaltene STXPath-Parser diese Ausdrücke ana-lysieren, in eine interne Repräsentation überführen oder gegebenenfalls als fehlerhaft zurückweisen kann.
Statische Semantikfehler
Statische Semantikfehler dagegen lassen sich nicht allein durch die Validierung gegen das Schema für STX entdecken, sondern setzen Wissen über die Bedeutung der ein-zelnen STX-Anweisungen voraus. Dies sind im Wesentlichen Eindeutigkeitsanforde-rungen für alle benannten Elemente (Gruppen, Prozeduren, Variablen) sowie die Existenz des entsprechenden Elements bei der Referenzierung eines solchen Namens.
Da STX den Einschluss anderer STX-Transformations-Sheets mittels stx:include vorsieht, lassen sich diese Eindeutigkeitsanforderungen nicht in XML-Schema aus-drücken. Die dort mittels xs:unique, xs:key und xs:keyref formulierbaren Bedingungen gelten immer nur innerhalb des Dokuments.
Für statische Semantikfehler gilt ebenfalls, dass ein STX-Prozessor einen solchen Fehler meldet und die Verarbeitung abbricht.
Serielle Transformationen von XML. Probleme, Methoden, Lösungen.
100 5 Streaming Transformations for XML
Dynamische Fehler
Schwieriger gestaltet sich die Situation für dynamische Fehler. Eine solche Fehler-quelle lässt sich nicht allein durch Analyse des STX-Transformations-Sheet entdecken.
Beispielsweise kann die Anweisung
<stx:attribute name="{@attname}" select="@attval" />
fehlschlagen, weil an dieser Stelle im Resultat kein Attribut erzeugt werden kann (es wurde kein Element unmittelbar zuvor eröffnet) oder weil das Attribut attname des aktuellen Eingabeknotens entweder gar nicht existiert oder einen unerlaubten Wert für einen XML-Attributnamen enthält.
Behebbare Fehler in XSLT
In XSLT wurde eine Reihe der dynamischen Fehler als behebbar (recoverable) klassifiziert. Jede XSLT-Implementierung darf frei entscheiden, ob sie den Fehler meldet (und die Transformation beendet) oder fortfährt, indem sie die in der Spezifi-kation vorgesehene Aktion durchführt. Im Falle des oben angegebenen Beispiels einer dynamischen Attributerzeugung darf ein XSLT-Prozessor beispielsweise die entspre-chende Anweisung xsl:attribute im Fehlerfall einfach ignorieren. Er ist noch nicht einmal dazu verpflichtet, den Anwender in irgendeiner Weise (etwa durch eine Warnung) vom Auftreten des Fehlers zu unterrichten.
Diese halbherzige Fehlerbehandlung ist ein Ergebnis des besonderen Einsatzgebietes von XSLT. Ein XSLT-Stylesheet, das im Browser des Anwenders die empfangenen XML-Daten in ein Präsentationsformat (in der Regel HTML) überführt, sollte den Anwender möglichst nie mit Fehlerausgaben konfrontieren. Auf der anderen Seite ist bei der Transformation in eigene, spezifische XML-Formate eine Fehlermeldung in solch einem Fall häufig wünschenswert, da das bloße Ignorieren einer Anweisung in der Regel nicht das erhoffte Ergebnis liefert.
In XSLT, das selbst keinen nutzerdefinierten Mechanismus zur Fehlerbehandlung enthält, wurden daher behebbare Fehler als Kompromiss zwischen diesen beiden Anwendungsfällen eingeführt. Diese Freiheit bei der Fehlerbehandlung kann sich jedoch als Problem für die Stylesheet-Entwicklung herausstellen. Im schlechtesten Fall besitzt ein Stylesheet-Autor einen sehr toleranten XSLT-Prozessor, der alle be-hebbaren Fehler ignoriert, während der Anwender oder Kunde einen strengen Prozessor im Einsatz hat, der empfindlich auf diese Fehler reagiert. Beide XSLT-Prozessoren verhalten sich konform zur Spezifikation, trotzdem kann das Stylesheet nicht portabel auf beiden XSLT-Prozessoren eingesetzt werden. Im letzten Entwurf von XSLT 2.0 [W3C03b] hat sich an dieser Situation nichts geändert. Für Stylesheet-Autoren kann damit nur als Konsequenz folgen, einen möglichst strengen XSLT-Prozessor bei der Entwicklung zu benutzen.
Meldung von Fehlern in STX In STX existiert dagegen keine Wahlfreiheit für STX-Prozessoren, einen dynamischen
Fehler zu melden oder zu ignorieren. Insbesondere wurde die Variante, für alle diese Fehlersituationen ein Ausweichverhalten festzulegen, verworfen. Fehlermeldungen sind ein entscheidendes Hilfsmittel, um die Korrektheit eines Programms sicherzu-stellen (vergleiche auch [SMQ03]).
Stattdessen wird STX einen einfachen Fehlerbehandlungsmechanismus anbieten,17 der dem STX-Autor die Entscheidung überlässt, wie mit bestimmten Fehlersituation umgegangen werden soll. Dieser Mechanismus orientiert sich an dem aus
objektori-17Das hier beschriebene Fehlerbehandlungskonzept findet sich zum Zeitpunkt der Entstehung dieser Arbeit noch nicht in der STX-Spezifikation wieder. Ebenso wenig existiert derzeit eine Implementation dafür.
Dissertation, Oliver Becker, 1. Juli 2004
5.6 STX-Konzepte 101
entierten Sprachen bekannten Konzept der Ausnahmen (Exceptions). Beim Auftreten eines Laufzeitfehlers wird eine Ausnahme ausgelöst, die separat an einer geeigneten Stelle im Code behandelt werden kann. Insbesondere werden Anwendungslogik und Fehlerbehandlung voneinander getrennt.
Fehlertypen Für das Transformationsmodell in STX bedeutet dies, dass zunächst alle potenziellen dynamischen Fehler identifiziert und mit einem Namen versehen werden. Beispiels-weise bezeichnet invalid-name den Fehler, der bei dem Versuch auftritt, eine Zeichenkette, die keinen XML-Namen repräsentiert, für die dynamische Konstruktion eines Elements, Attributes etc. zu verwenden. Die STX-Spezifikation enthält eine Liste aller möglichen dynamischen Fehler. Diese bilden keine Hierarchie, sondern stehen gleichberechtigt nebeneinander.
stx:recover Ein solcher dynamischer Fehler kann in STX durch das Element stx:recover behandelt werden. Dieses Element verhält sich wie ein Template. Es kann innerhalb einer Gruppe neben den Templates angegeben werden und es gelten die gleichen Sichtbarkeitsregeln und Vorrangkategorien wie für Templates (siehe Kapitel 5.6.4).
Während ein Template jedoch wie ein Callback-Element für die Knoten der XML-Eingabe aufgerufen wird, fungiert ein stx:recover-Element als Callback für dy-namische Fehler. Der Name des Elementes verdeutlicht, dass in seinem Inhalt eine Recovery-Aktion definiert werden kann. Ob und wie ein dynamischer Fehler behoben werden soll, wird durch den STX-Autor durch die Bereitstellung geeigneter stx:recover-Elemente festgelegt.
Das stx:recover-Element besitzt ein optionales Attribut from, das die konkreten Fehlertypen bezeichnet. Ohne die Angabe dieses Attributs werden alle behebbaren dynamischen Fehler durch das stx:recover-Element behandelt. Ein spezifisches stx:recover-Element mit from-Attribut hat immer den Vorrang vor einem all-gemeinen stx:recover-Element. Soll ein stx:recover für mehrere Fehlertypen zuständig sein, werden deren Namen durch Leerzeichen getrennt im from-Attribut angegeben. Mehrere stx:recover-Elemente für den gleichen Fehlertyp in der gleichen Vorrangkategorie führen zu einem statischen Fehler. Existiert im Fehlerfall kein passendes stx:recover-Element innerhalb der Vorrangkategorien, wird ein normaler Fehler ausgelöst. Dies führt zum Abbruch der Transformation.
Fehlerparameter Informationen über den konkreten Fehler werden in Form von speziellen Parametern übergeben. Die Syntax ähnelt hier ebenfalls der von Templates (und auch Prozeduren), wobei die Parameterübergabe implizit durch den STX-Prozessor geschieht. Folgende Parameter werden übergeben:
error
der aufgetretene Fehlertyp als Zeichenkette message
eine vom STX-Prozessor erzeugte Fehlermeldung, die den aufgetretenen Fehler näher beschreibt
element
der Name des Elements, das den Fehler ausgelöst hat system-id
die System-ID des Transformations-Sheet, zu dem dieses Element gehört line-number
die Zeilennummer des Elements, das den Fehler ausgelöst hat (sofern vorhanden)
Serielle Transformationen von XML. Probleme, Methoden, Lösungen.
102 5 Streaming Transformations for XML
column-number
die Spaltennummer des Elements, das den Fehler ausgelöst hat (sofern vorhanden) Für nicht benötigte Parameterwerte kann die Parameterdeklaration entfallen. Beispiels-weise hat in einem spezifischen stx:recover-Element der Parameter error immer einen bekannten Wert und ist daher irrelevant. Alle Parameter eines stx:recover-Elements sind automatisch obligatorisch, d.h. ihr required-Attribut besitzt implizit den Wert "yes". Auf diese Weise können Schreibfehler in der Para-meterdeklaration durch den STX-Prozessor erkannt werden.
Innerhalb des stx:recover-Elements kann im einfachsten Fall mittels stx:message eine Fehlermeldung ausgegeben werden. Gegebenenfalls kann über das Attribut terminate die Transformation sogar beendet werden.
Das Element stx:recover ist jedoch in erster Linie dazu gedacht, die Transforma-tion trotz eines aufgetretenen Fehlers sinnvoll fortzusetzen. Nachdem alle innerhalb von stx:recover vorkommenden Elemente ausgeführt worden sind, wird die Transformation nach dem Element, das den Fehler ausgelöst hatte, fortgesetzt. Der Inhalt des fehlerhaften Elementes wird ignoriert.
Falls innerhalb von stx:recover wiederum ein behandelbarer Fehler auftritt, wird ebenso ein passendes stx:recover-Element gesucht und benutzt. Allerdings werden alle aktiven stx:recover-Elemente bei dieser Suche ausgeschlossen. So kann es nicht zu unendlichen Fehlerbehandlungsschleifen kommen.
Logische Fehler
Fehler der letzten Kategorie kann ein STX-Prozessor nicht allein erkennen. Hier ist der STX-Programmierer auf zusätzliche Hilfsmittel angewiesen, mit deren Hilfe der Transformationsablauf verfolgt und damit die Fehlerursache ermittelt werden kann.
Mit Hilfe des Elements stx:message lassen sich bereits einfache Debug-Ausschrif-ten erzeugen. Weitaus mächtiger sind spezielle STX-Debugger, wie zum Beispiel der für Joost entwickelte StDB[StDB].
Logging
STX-basierte Transformationen laufen häufig im Hintergrund ab. Typisch sind so genannte Batch-Prozesse, die für die Verarbeitung einer großen Datenmenge eine gewisse Zeit benötigen, oder Transformationen innerhalb eines Servers, in dem XML-Daten auf Anfrage transformiert und an die Klienten ausgeliefert werden. In beiden Szenarien kommt der Anwender nicht direkt mit dem STX-Prozessor in Kontakt. Um so wichtiger ist es, dass eventuell auftretende Fehlernachrichten oder Mitteilungen über den Status der Transformation in entsprechenden Log-Dateien aufgezeichnet werden können. Das aus XSLT übernommene Element stx:message bietet nur die Erzeugung einer einfachen Nachricht, ohne dass auf STX-Ebene verschiedene Empfänger oder unterschiedliche Schweregrade eines Fehlers unterschieden werden können.
Für verschiedene Programmiersprachen wurden bereits geeignete APIs entwickelt, die ein komfortables Erzeugen von Log-Nachrichten ermöglichen. Insbesondere für die Programmiersprache Java existieren gleich mehrere solcher APIs [Sei03].
Eigenschaften von Logging-APIs Logging-APIs zeichnen sich durch die folgenden Punkte aus:
Es können im Quelltext Nachrichten unterschiedlichen Schweregrads produziert werden.
Dissertation, Oliver Becker, 1. Juli 2004
5.6 STX-Konzepte 103
Es können unterschiedliche Empfänger (Logger) verwendet werden.
Es stehen häufig umfangreiche Konfigurierungsmöglichkeiten zur Verfügung, über die sich das Ausgabeformat und die Zuordnung eines Loggers zu einem physikalischen Ziel (z.B. einer Datei) einstellen lassen.
Insbesondere erfolgt die Konfiguration des Logging-Framework unabhängig von der Erzeugung der eigentlichen Nachricht. Eine einmal erstellte Anwendung kann so unabhängig vom Quelltext hinsichtlich ihres Log-Verhaltens konfiguriert werden, in der Regel über separate Konfigurationsdateien.
Die Sprache STX enthält kein eigenes Logging-Framework, sondern bietet eine ein-fache Schnittstelle zu darunter liegenden Logging-Mechanismen. Die jeweilige Konfigurierung muss implementationsspezifisch durch den jeweiligen STX-Prozessor gelöst werden.
stx:message Das Element stx:message wird zu diesem Zweck um zwei Attribute erweitert:
level
Der Schweregrad der Nachricht. Mögliche Werte sind in aufsteigender Reihen-folge "trace", "debug", "info", "warn", "error" und "fatal".18 logger
Der Name eines Loggers, der das Ziel der Nachricht repräsentiert.
Ein STX-Prozessor ohne Logging-Unterstützung darf diese Attribute ignorieren und alle per stx:message erzeugten Nachrichten gleich behandeln.