Bedarf für offene Schemas

(Auszug aus "XML Schema" von Eric van der Vlist)

In diesem Kapitel haben wir die Möglichkeiten erörtert, mit denen sich die in einem Schema definierten Komponenten wiederverwendbar und flexibel gestalten lassen. Das ist definitiv etwas Erstrebenswertes, aber die Auswirkung dieser Bemühungen ist auf die Erzeugung und Pflege von Schemas beschränkt, es gibt jedoch wenig oder gar keine Auswirkungen auf die Dokumente selbst. Selbst wenn die Designer von Anwendungen XML-Instanzdokumente oft als eng mit ihrem Schema und mit der Anwendung, für die sie zunächst entworfen wurden, gekoppelt ansehen, übersteigt häufig die Lebensdauer von Dokumenten die ihrer Anwendungen und Schemas. XML-Dokumente oder -Fragmente werden oft auch in anderen Zusammenhängen wiederverwendet oder dienen als Behälter, denen weitere Informationen hinzugefügt werden, wodurch Kombinationen entstehen, an die ihr ursprünglicher Autor nie gedacht hat.

Die Öffnung von XML-Vokabularen, um eine solche Entwicklung zu erleichtern und zu steuern, ist eine ziemliche Herausforderung und geht über den Entwurf offener Schemas hinaus. Sie erfordert einen anderen Blick darauf, was ein XML-Dokument ist, und hat Auswirkungen darauf, wie die Anwendungen geschrieben werden (die beispielsweise so tolerant wie möglich gegenüber unerwarteten Elementen und Attributen sein sollten). Grammatikbasierte Schemas wie W3C XML Schema haben ein grundsätzliches Problem mit offenen Vokabularen: Alles, was nicht ausdrücklich erlaubt ist, ist verboten, und daher sind diese Schemas letztlich »standardmäßig geschlossen«.

Wenn wir die Offenheit eines Schemas als die Fähigkeit definieren, das explizit durch das ursprüngliche Schema definierte Inhaltsmodell zu modifizieren, ohne ein neues Schema zu definieren (wir haben die Veränderung des Inhaltsmodells durch Modifikation des Schemas bereits unter Erweiterbare Schemas besprochen), sind die vorhandenen Werkzeuge die Typersetzung mit xsi:type und die Wildcards.

xsi:type

Diese Art von Offenheit ist standardmäßig erlaubt. Eine Reihe von Anwendungen, die Ableitungen komplexer Typen durch Erweiterung, Ableitungen einfacher Typen durch Vereinigung oder Bausteine, für die kein Attribut block oder blockDefault definiert ist, verwenden, würden wahrscheinlich durch eine Typersetzung im Instanzdokument ziemlich überrascht.

Jenseits dieser Fälle »unerwarteter« Offenheit kann es ein erster Ansatz zur Öffnung eines Schemas sein, Erweiterungen der komplexen Typen, die zur Definition der Elemente verwendet werden, zu erzeugen, die dann in den Instanzdokumenten mit Hilfe des Attributs xsi:type ersetzt werden können. Dadurch lassen sich auch Überraschungen unter Kontrolle halten. In diesem Fall kann das Attribut xsi:type von den Anwendungen verarbeitet werden, um zu bestimmen, welcher Art von Erweiterung sie gegenüberstehen.

Wildcards

Namensräume und Wildcards sind die mächtigsten Werkzeuge zur Erzeugung offener Schemas. Viele Vokabulare (wie auch W3C XML Schema) lassen Attribute, die einen anderen Namensraum als den Ziel-Namensraum haben, in all ihren Elementen zu, während sie gleichzeitig unqualifizierte Attribute wie auch Attribute aus ihrem eigenen Namensraum streng unter Kontrolle halten. Die Werte des Attributs processContents (lax, skip und strict) können angepaßt werden, um den Grad an Offenheit zu bieten, der Ihrer Einschätzung nach am besten zu Ihrem Schema paßt. skip ist vollständig offen, strict erfordert die Bereitstellung von Schemas für die Namensräume, die während der Validierung gefunden werden, und lax ist eine Einschränkung in der Mitte dazwischen.

Elemente aus anderen Namensräumen werden oft im Vergleich zu Attributen stärker als Eindringlinge empfunden und können in Containern gehalten werden. Das praktiziert W3C XML Schema auch für sein eigenes Vokabular, indem es beliebige Elemente aus beliebigen Namensräumen innerhalb von Beschreibung zuläßt. Andere Vokabulare, zum Beispiel RELAX NG oder RSS 1.0, akzeptieren einfach jedes Element, das einen anderen Namensraum außer ihrem eigenen Ziel-Namensraum hat.

Obwohl diese Praxis viel Flexibilität für die Einbindung unerwarteter Informationen in Instanzdokumente bietet, bleibt festzuhalten, daß sie bei gleichzeitiger Definition mehrerer Namensräume nur beschränkt anwendbar ist, weil es keinen Spezialwert gibt, um »jeder Namensraum außer denen, die in dem konsolidierten Schema definiert werden« anzugeben.

Und Ersetzungsgruppen?

Wenn wir hier xsi:type erwähnen, sollten wir dann nicht auch Ersetzungsgruppen erwähnen? Ja und nein. Ja, weil ihre Verwendung eine gute Möglichkeit ist, mehrere alternative Inhaltsmodelle zu definieren. Andererseits nein, weil sie nur verwendet werden können, wenn sie in einem Schema definiert worden sind. xsi:type hingegen kann benutzt werden, selbst wenn das Schema dies nicht besonders vorbereitet hat. Ungeachtet der Ähnlichkeiten gehören Ersetzungsgruppen in Wahrheit viel stärker zu flexiblen Schemas als zu offenen Schemas.

   

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema XML Schema 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 "XML Schema" 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