URL dieses Artikels:

zu Ausgabe: 5.2003
Ohne Einschränkung
Tool-Unterstützung für XML Schema
von Erik Wilde
XML Schema hat sich mittlerweile vor Konkurrenten wie Relax NG, Schematron oder den alten DTDs als die wichtigste Sprache für Schemas in XML etabliert. In diesem Artikel wird einem oft vernachlässigten, aber sehr wichtigen Aspekt von XML Schema nachgegangen, nämlich der Frage, wie man eigentlich XML Schemas schreibt. Nichts einfacher als das, wird sich der naive XML-Einsteiger denken: Man nimmt sich ein Stück Software, bei dem XML Schema Support auf der Verpackung steht, und macht sich an die Arbeit. In diesem Artikel wollen wir zeigen, dass die Realität leider anders aussieht - und warum das keinem Anwender von XML Schema egal sein sollte.

XML Schemas sind langlebig
XML wird heute in den verschiedensten Anwendungsgebieten eingesetzt, von der Fertigungsautomation bis zum Content Management. In diesen verschiedenen Anwendungsgebieten haben die XML-Dokumente sehr unterschiedliche Lebensdauern, manchmal unter einer Sekunde (wenn zwei Applikationen per XML Daten austauschen) bis hin zu Jahren oder Jahrzehnten (XML für strukturierte Dokumente, z.B. Manuals oder juristisch relevante Dokumente). Wie groß auch immer die Lebensdauer eines Dokuments ist, die des Schemas ist auf jeden Fall mindestens genauso lang, oft aber länger. Ohne Schema lässt sich in kaum einem Fall sinnvoll mit XML umgehen und so gesehen ist es wichtig, dass ein Schema lange Zeit unterstützt wird.


Worum es nun geht, ist die Frage, wie man langlebige XML Schemas schreibt. Es soll hier nicht um die prinzipielle Methodik gehen, sondern eher um die Frage, wie man überhaupt zu einem Schema gelangt, das auch in ein paar Monaten oder Jahren noch verwendet werden kann. Die trivialste Bedingung dabei ist, dass es korrekt sein muss (also tatsächlich ein XML Schema ist), und wie sich zeigen wird, ist schon das etwas, was die heutigen Tools nicht garantieren können. Dazu zunächst ein kleiner Exkurs zu XML Schema.

Schema Component Constraints
XML Schema ist auf so genannten Components aufgebaut, die in definierten Beziehungen zueinander stehen. So ist z.B. eine Typ-Definition eine Component und eine Element-Deklaration eine weitere, die den Typen referenziert. Damit ein XML Schema korrekt ist, muss eine große Zahl von so genannten Constraints erfüllt werden, die definieren, wie die Components definiert sein und zueinander in Beziehung stehen müssen. Die XML-Syntax von XML Schema ist dann nur noch ein Vehikel, um diese Components und ihre Beziehungen aufzuschreiben (siehe Abschnitt XML Schema ist mehr als ein XML-Schema).


Wie sich zeigt, stellt die komplette und korrekte Implementierung (mit einer Ausnahme) der Schema Component Constraints alle getesteten Tools vor Probleme, sodass diese dem XML-Entwickler keine oder nur partielle Hilfestellung dabei geben, die Component Constraints einzuhalten. Als ein Resultat ist es mit praktisch allen Tools nicht möglich, sicher zu sein, ob ein XML Schema tatsächlich ein XML Schema ist oder nur so aussieht.


Im Prinzip gibt es zwei mögliche Fehlertypen:
  • False Negatives: Das Tool lehnt ein Schema ab, obwohl es korrekt ist. Dies ist schade, weil einem ein Feature unzugänglich gemacht wird, dass man vielleicht gebraucht hätte. Dieser Fall tritt seltener ein, ist aber der weniger schlimme, da immerhin jedes Schema, das erzeugt wird, ein korrektes Schema ist.
  • False Positives: Dies ist der gefährliche und leider auch der weitaus häufigere Fall. Hier wird ein Schema akzeptiert, obwohl es nicht korrekt ist. Das heißt, dass ein Export in andere Umgebungen dazu führen kann, dass es dort korrektermaßen zurückgewiesen wird. Ist das Schema dann schon in produktivem Einsatz, hat man ein sehr ernsthaftes Problem.

XML Schema ist mehr als ein XML-Schema
Folgendes Listing verdeutlicht die XML Schema Component Constraints: 

<xs:simpleType name="illegalType">

<xs:restriction base="baseType">

<xs:maxInclusive value="101" />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="baseType">

<xs:restriction base="xs:integer">

<xs:maxInclusive value="100" />

</xs:restriction>

</xs:simpleType>

Obwohl auf den ersten Blick alles aussieht wie ein XML Schema, verletzt die Typableitung des illegalType einen Schema Component Constraint, nämlich die Regel, dass Restriction Facets (in diesem Fall die maxInclusive-Facet) nur eingeschränkt werden dürfen, in diesem Fall aber eine Erweiterung versucht wurde.


Wichtig ist hier, dass die Tatsache, dass es sich um ein illegales (also genau genommen kein) XML Schema handelt, nicht durch reines Testen des XML auf die verwendeten Elemente erkannt werden kann, sondern der Fehler erst durch das Testen auf die Einhaltung der Component Constraints offensichtlich wird.


Technisch gesehen sieht es so aus, dass es einerseits ein so genanntes XML Schema für XML Schema gibt, in dem die XML-Syntax von XML Schema mit dessen eigenen Mechanismen beschrieben wird. Dies ist aber nur ein Teil dessen, was bei XML Schema wichtig ist. Die anderen Randbedingungen sind in den oben erwähnten Component Constraints definiert.

Kompatibilitätsprobleme
Zu befürchten ist, dass zumindest die kommerziellen Tools in naher Zukunft nicht darauf umschwenken werden, die Component Constraints korrekt zu überprüfen. Täten sie das in einem neuen Release, hätte die Firma sicher sehr viele verärgerte Benutzer, die feststellen müssten, dass ihre Schemas, die in der alten Version des Produkts klaglos akzeptiert wurden, plötzlich zurückgewiesen werden. Hier haben sich die Hersteller mit ihrer sehr laxen Art der Implementierung wahrscheinlich selbst keinen Gefallen erwiesen, dem Benutzer jedenfalls ganz sicher nicht.


Wie kommt man nun aus diesem Dilemma heraus? Einerseits will man vielleicht die komfortablen Features und Interfaces nicht missen, die einem Produkte wie xmlspy [1], TurboXML [2] oder der WebSphere Schema Editor [3] zur Verfügung stellen. Andererseits sollte man sich gerade auf diese Produkte nicht verlassen, die im Test sehr bescheiden abgeschnitten haben.


Die Lösung ist einfach, aber umständlich. Sie heißt einfach, das Entwickeln des XML Schemas einerseits mit dem Tool der Wahl anzugehen, andererseits aber regelmäßig mit einem anderen Tool das Schema auf seine Korrektheit zu überprüfen. Hier bietet sich der IBM Schema Quality Checker (SQC) [4] an, der als einziges Tool im Test offenbar alle Component Constraints überprüft. Kleinere Bugs gibt es auch beim SQC, doch sind nicht ähnlich große und offensichtliche Implementierungslücken festzustellen wie bei den anderen Tools.


Der WebSphere Schema Editor hat immerhin die Möglichkeit, den SQC einzubinden und so auf Mausklick das Schema überprüfen zu lassen. Bei den anderen grafisch orientierten Tools muss man jedes Mal das Schema abspeichern und den SQC - ein Java-basiertes Kommandozeilen-Tool - laufen lassen. Danach steht man dann vor der unter Umständen gar nicht so einfachen Aufgabe, die Fehlermeldungen des SQC auf die grafische Darstellung zu beziehen und die erkannten Fehler zu eliminieren. Dies ist umständlich, aber man sollte es sich trotzdem zur Gewohnheit machen -andernfalls hat man keinerlei Sicherheit, dass das erstellte Schema fehlerfrei ist.


MSV [6] und XSV [7] dokumentieren die jeweils implementierte Untermenge des Standards, sind also hinsichtlich ihrer Lücken zumindest ehrlich. Bei den kommerziellen Tools sieht das anders aus, dort wird in Abrede gestellt, dass es Implementierungslücken gebe, und jeder nachgewiesene Fehlerfall wird als individueller Bug Report behandelt.

Gibt es XML-Zertifizierung?
Dieser Artikel beleuchtet nur einen Aspekt der generellen Fragestellung, inwieweit Software, die bestimmte Leistungsmerkmale für sich in Anspruch nimmt, diese tatsächlich auch erfüllt. Im Bereich der XML-Technologien ist dies ein besonderes Problem, da sehr schnell sehr viele Produkte das Label XML-enabled führten, ohne dass wirklich klar war, was das heißen sollte. Erstaunlicherweise tauchen sogar immer öfter noch in Entwicklung befindliche Standards (W3C Working Drafts) in den Feature-Listen der Herstellen auf, so z.B. XQuery. Wie diese unvollständigen und in Veränderung befindlichen Standards in einem Produkt wenigstens halbwegs stabil unterstützt werden können, bleibt ein Geheimnis der Softwareanbieter.


Das W3C hat lange Zeit nichts davon wissen wollen, im Bereich Conformance Testing aktiv zu werden. Mittlerweile hat sich diese Einstellung geändert und die W3C-Matrix [5] zeigt eine zunehmende Tendenz bei den Test-Suites. Das Problem liegt hauptsächlich im rechtlichen Bereich, da durch praktisch alle Software-Lizenzen verboten wird, die Software systematisch zu testen und die Resultate zu veröffentlichen.


Es gibt auch für XML Schema eine Test-Suite (eine zweite ist in Entwicklung), doch diese führt (zumindest bisher) noch ein eher verstecktes Dasein und solange Kunden beim Erwerb von Software nicht ausdrücklich nach der Test-Performance eines Produkts fragen, wird das wohl auch so bleiben. Eigene Tests sind angesichts der Größe der Test-Suites von einigen Tausend Beispielen nur sehr aufwändig zu realisieren.


Zudem ist der Umgang der Hersteller mit den Standards manchmal lax, manchmal schlicht inkompetent. So hat z.B. einer der Hersteller der getesteten Produkte in seiner FAQ auf dem Web den Kommentar, er halte die Einschränkung von XML Schema auf deterministische Content Models für falsch und werde dies deshalb auch nicht implementieren. Darauf angesprochen, wurde die Behauptung aufgestellt, sowohl bei DTDs als auch bei XML Schema sei die Verpflichtung auf deterministische Content Models ja nur ein Kommentar im Standard. Nachdem dem Hersteller dann sowohl in der XML- als auch in der XML Schema-Spezifikation die Stellen gezeigt wurden, an denen Determinismus explizit verlangt wird, kam keine Antwort mehr.


Kaum ein Kunde wird sich die Arbeit machen und bei einem Produkt nicht nur die Liste der implementierten Features mit der tatsächlichen Leistungsfähigkeit des Produkts vergleichen. Schon gar nicht werden Kunden die Zeit investieren, selber in den Standards die relevanten Stellen zu suchen und damit gewisse Versäumnisse nachzuweisen. Es wäre daher wünschenswert, wenn es unabhängige Zertifizierungsstellen gäbe, die Produkte testen und bewerten, jedoch ist eine solche Entwicklung momentan nicht abzusehen.

Fazit
Zusammenfassend lässt sich sagen, dass der Stand der Implementierungen bei XML Schema sehr bescheiden ist. Leider ist die mit Abstand beste Implementierung im Test, der SQC von IBM, kein XML Schema Processor, d.h. man kann mit ihm keine Dokumente validieren. Das hat zur Folge, dass man mit dem SQC zwar bereits ein Tool in der Hand hat, mit dem sich korrekte XML Schemas erstellen lassen, aber noch kein Tool existiert, um dieses Schema dann auch fehlerfrei auf Dokumente anzuwenden.


Inwiefern einen die in diesem Artikel angesprochenen Probleme betreffen, hängt sehr vom Einsatzgebiet von XML Schema ab. Handelt es sich dabei um ein Gebiet, wo die Dokumente oder das Schema eine lange Lebensdauer haben, so sollte darauf geachtet werden, dass das Schema tatsächlich korrekt ist. Die meisten der momentan verfügbaren Tools weisen in diesem Bereich große Lücken auf, und nur der Schema Quality Checker (SQC) von IBM scheint überhaupt eine komplette Implementierung aufweisen zu können.

Links und Literatur
© 2004 Software & Support Verlag GmbH. Vervielfältigung nur mit Genehmigung des Verlags. Fragen?