Messerhelden

Eher aus historischen als aus inhaltlichen Gründen bezeichnet man XSLT-Programme als Stylesheets. Denn es handelt sich um eine Programmiersprache, deren Einsatz nach einem Entwickler und nur selten nach einem Designer verlangt. Bei der Suche nach einem Werkzeug, das einem das Schreiben von XSLT-Programmen erleichtert, ist es deshalb legitim, Maßstäbe anzulegen, die sonst für Java- und andere Entwicklungsumgebungen gelten.

Trotz der hohen Spezialisierung von XSLT gibt es eine große Zahl von Programmen, die behaupten, die Arbeit damit zu erleichtern. Dafür gibt es zwei Gründe: Einerseits hat XSLT im Zuge des XML-Booms an Beliebtheit gewonnen, und andererseits sind alle XSLT-Programme in XML geschrieben; eine Syntax, die viele Editoren unterstützen.

Thema dieses Artikels sind XSLT-Editoren und Mapping-Tools: Die XML-Spy-Suite sowie Mapforce von Altova, Tibcos XML Transform, Tagfree von Dasan, das Stylus Studio von Sonic, Oxygen von Syncro, DesignerXSL der United Business Technologies, Komodo von Activestate, der Xselerator von MarrowSoft sowie das Open-Source-Produkt Jedit.

Da einige der Firmen durch dasselbe oder ein anderes Produkt darüber hinaus Editoren für Schemata (DTDs, XML-Schema) anbieten, behandelt der gesonderte Textkasten auf Seite 58 diesen Aspekt der XML-Arbeit.

Erwartungen an Editoren

XSLT-Programme sind wie XML-Dokumente regelmäßig aufgebaut. Sie erfüllen mindestens die Wohlgeformtheit gemäß der XML-Spezifikation. Ein XSLT-Editor sollte das Einhalten dieser Wohlgeformtheit unterstützen. Das kann bedeuten, dass er diesbezügliche Verletzungen anzeigt oder gar nicht erst zulässt. Ein bequemes Schließen offener Elemente (das Einfügen des passenden End-Tags) sind ebenso als Selbstverständlichkeit anzusehen wie eine syntaxbetonende Darstellung (Syntax Highlighting oder Coloring).

Die XML-Struktur der XSLT-Programme schreit förmlich nach einem strukturorientierten Browser, in dem man etwa Teile seines Programms auf- und zuklappen kann. Wenn die Software ordentliches Einrücken (Pretty Printing) unterstützt oder selbst erledigt, dürften sich viele Entwickler ebenfalls freuen.

Neben diesen rein syntaktischen Wünschen ist es sicherlich nicht zu viel verlangt, wenn man von der Software Kenntnisse über korrektes XSLT verlangt. Bei der Eingabe sollten Werkzeuge kontextsensitiv nur solche XSLT-Elemente anbieten, die an der jeweiligen Stelle tatsächlich erlaubt sind. Das Abfragen von Werten der erforderlichen Attribute sowie eine bequeme Eingabe von optionalen Attributen zählt ebenfalls zu den Standard-Features.

XSLT-Programme wandeln Daten von einem in solche eines anderen XML-Vokabulars. Häufige Ausgabesprachen sind (X)HTML oder XSL-FO. Eine Eingabehilfe für diese beliebten Ausgabeformate wäre durchaus hilfreich. Noch besser wäre es, wenn eine XSLT-IDE die Quell- und Ziel-DTD (beziehungsweise das -Schema), zwischen denen das zu schreibende XSLT-Programm übersetzen soll, lesen würde. Man könnte sich hier vorstellen, dass Editoren beim Schreiben von XSLT-Templates den XPath-Ausdruck im match-Attribut auf Plausibilität gegen Quell-DTD/Schema prüfen. Eine Eingabehilfe für Elemente der Ziel-DTD/-Schema könnte in diesem Falle ein vergleichsweise einfaches, aber nicht minder sinnvolles Feature sein.

Eine Transformation aus der IDE heraus zu starten, ist einfach. Entscheidender erscheint die Frage, welche Produkte einen Debugger mitbringen. Hier bestehen die klassischen Anforderungen: schrittweises Ausführen des Programms, Setzen von Breakpoints und so weiter. So flexibel XSLT ist, in realen Projekten sind Grenzen schnell erreicht. Diese überschreiten selbst programmierte Erweiterungen der XSLT-Engine. Wie das geht, soll in einer späteren Ausgabe Thema eines Artikels sein.

Einige verbreitete XSLT-Engines sind in Java geschrieben. Folglich kommen als Erweiterungen Java-Klassen infrage. Spannend wird es nun beim Zusammenspiel von XSLT-Programm, Java-Erweiterungen und dem Debugger. Der Entwickler wünscht sich selbstverständlich einen Debugger, der den kompletten Programmlauf erfasst, also die Ausführung von XSLT und Java. Leider gibt es keine einheitliche Schnittstelle zum Schreiben der Erweiterungen - jede XSLT-Engine kocht ihr eigenes Süppchen. Für Debugger eine echte Herausforderung.

XSLT-Programme können ein erstaunliches Laufzeitverhalten an den Tag legen. Selbst überschaubare Datenmengen auf durchaus leistungsfähigen Rechnern können Transformationen zu einem Geduldspiel geraten lassen. Die Ursachen mögen vielfältig sein: im Umgang mit einer funktionalen Sprache ungeübte Programmierer, Mängel in der Implementierung der Engine, große DOM-Speicherrepräsentationen der Ausgangsdaten und so weiter. Kann eine IDE mit Funktionen zum Profiling helfen, die Laufzeit zu verstehen und zu optimieren?

Nicht zuletzt sollte der Debugger beziehungsweise die eingebaute XSLT-Engine in der Lage sein, Kataloge, seien es OASIS- oder XML-Catalogs, zu verstehen, um Referenzen auf externe Entities (Dokumentteile oder DTD/Schemata) auflösen zu können.

Kataloge stellen ein Verzeichnis dar, in dem Namen von externen Entities, die als Formal Public Identifier (FPI) oder als URL-System-Identifier angegeben sind, auf lokale Dateinamen abzubilden. Neben der grundsätzlichen Sinnhaftigkeit der Kataloge, besteht diese noch mehr für Entwickler, die in der Regel nicht in der späteren Produktionsumgebung arbeiten, sondern in einer anderen Umgebung.

Alles in allem ein breites Spektrum an Anforderungen, angefangen bei schlichten Hilfen, die Tipparbeit zu sparen, bis hin zu komplexen, sprachübergreifenden Debugging-Funktionen und Profiling. Einen Überblick über die Leistungsfähigkeit der Produkte bietet die Tabelle.

Den vollständigen Artikel samt einer Tabelle mit den Eigenschaften finden Sie in der aktuellen Printausgabe. (hb)