Problemstellung
Der Grund für diese Art von Fehlern liegt häufig in den zu permissiven Festlegungen in den Regelwerken. Aus Modellierungsgründen, vor allem bei der Definition von Inline-Elementen wie Fußnoten oder Textauszeichnungen, werden oft rekursive Beziehungen zugelassen. Solche Strukturen bieten bei der Dokumenterstellung unendlich viele Verschachtelungsmöglichkeiten. Oft können diese im Rendering-Prozess nicht vollständig abgebildet werden. Praktikabler wäre es, solche Probleme bereits im Vorfeld durch eine zusätzliche Prüfung oder bereits im XML-Editor abzufangen und per zusätzlicher Fehlermeldung anzumahnen. Der Fehler im obigen Fußnotenbeispiel ist nicht der einzige, der bei der Verwendung von Schema-Sprachen entstehen kann. XML-Dokumente funktionieren häufig nach zusätzlichen Regeln (Business Rules), die nicht in DTDs oder Schemata abgebildet werden können. Beispiele für solche Regeln sind:
- Überprüfung von Kindstrukturen in Abhängigkeit von Attributwerten
- Überprüfung der Häufigkeit von Elementen in Abhängigkeit von Geschwisterelementen
- Überprüfung komplexer Inhaltsregeln wie die fehlerhafte Verwendung von Überspannungen bei CALS-Tabellen
- Einschränkung bei der Verwendung von rekursiven Strukturen
- Vermeidung von speziellen textuellen Inhalten wie Folgen von Unterstrichen oder Punkten, die im dokumentenzentrierten Umfeld oft als Gestaltungselemente „missbraucht“ werden
- Überprüfung von Summen, z. B. innerhalb von Rechnungsformularen
- Überprüfung des Einsatzes von Processing Instructions
Diese Mächtigkeit von Regeldefinitionen, kombiniert mit der Möglichkeit, ausführliche und verständliche Fehlermeldungen an den Autoren oder Ersteller eines XML-Dokuments zurück zu geben, kann zu einer entscheidenden Verbesserung der Datenqualität und zu einem enormen Einsparpotenzial bei der Dokumenterstellung führen.
Lösungsansatz
Einige der oben genannten Probleme könnten durch die Definition strikterer Grammatiken gelöst werden. Doch ist es wirklich sinnvoll, die großen Standards wie Docbook oder DITA diesbezüglich abzuändern? Sind nicht die eingesetzten Tools und die betrieblichen Abläufe genau auf diese Regelwerke abgestimmt? Als Lösung für all diese Anforderungen möchten wir im Folgenden eine regelbasierte Sprache vorstellen, die die bisher eingesetzten grammatikbasierten Sprachen nicht ersetzen sondern komplementieren soll. Der ISO-Standard Schematron leistet die Prüfung von XML-Dokumenten durch ein Regelwerk, das mit der XML-Pfadsprache XPath definiert werden kann.
Funktionsweise
Ein Schematron-Schema ist selbst ein XML-Dokument und besteht aus einem Satz von Regeln. Jede Regel steht für einen Fehlerfall, der im XML-Dokument vorkommen kann und geprüft werden soll. Dabei lassen sich Regeln zu komplexeren Einheiten (Patterns) gruppieren. Eine Regel wird unter Verwendung der Sprache XPath aufgestellt. Das so genannte “Query Binding“ von ISO Schematron ermöglicht es dabei übrigens auch, Konstrukte aus XSLT 1.0, XSLT 2.0, XPath 2.0 oder EXSLT zu verwenden. Voraussetzung ist die Unterstützung dieser Sprachen durch die verschiedenen Implementierungen. Das Wurzelelement deklariert nun das Dokument als ein Schematron-Schema inklusive dem Namespace. Um die einzelnen Regeln einer Business Rule des Schemas zu gruppieren, wird das -Element verwendet:
<?xml version="1.0" encoding="UTF-8"?><sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron"><sch:pattern><sch:rule context="XPath-Ausdruck"><sch:assert test="XPath-Ausdruck">Freiformulierbare Fehlermeldung</sch:assert><sch:report test="XPath-Ausdruck">Freiformulierbare Fehlermeldung</sch:report></sch:rule></sch:pattern></sch:schema>
Das -Element stellt den eigentlichen Kern des Schemas dar. Es enthält alle Tests, die benötigt werden, um eine Regel zu formulieren. Der XPath-Ausdruck im Attribut context enthält den Lokalisierungspfad zum Adressieren einer Knotenmenge aus dem XML-Quelldokument, für die die aufzustellende Regel gelten soll. Diese Konstruktion erinnert stark an den Template-Mechanismus, wie er in der Transformationssprache XSLT verwendet wird. Dies ist kein Zufall, denn die Idee für den Ansatz einer kontextbasierten Validierung entstand bei der Arbeit mit XSLT.
