Stilfragen

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

Ein Schema zu schreiben ist beinahe so etwas, wie ein Programm zu schreiben. Zwei Programmstücke mögen beide funktionieren, aber eines kann besser les- und pflegbar als das andere sein. Lesbarkeit ist gut.

Der Reiz des Einfachen

Auch wenn W3C XML Schema sorgsam so spezifiziert wurde, daß Schema-Prozessoren den Weg auch durch die komplexesten und verwobensten Kombinationen der zahlreichen Konstruktionen finden können, kann dies vom menschlichen Durchschnittsleser nicht erwartet werden. Ich muß gestehen, daß zumindest ich mich in den Mäandern von Schemas mittlerer Komplexität, wie etwa dem berühmten Schema für Schema, schnell verlaufe.

»Genieße den Reiz des Einfachen« ist eine nützliche Grundregel. Selbst wenn W3C XML Schema Ihnen eine große Anzahl von Möglichkeiten an die Hand gibt, müssen Sie nicht alle in jedem Schema verwenden. Jede einzelne erhöht den Preis Ihres Schemas in puncto Lesbarkeit.

Einige der Regeln für Einfachheit, die wir seit einiger Zeit bei Programmiersprachen anwenden, sind auch hier anwendbar, beispielsweise die einander widerstreitenden Regeln der Kürze (»Wenn eine Funktion länger als eine Seite ist, teile sie auf«) und Direktheit (»Eine Funktion sollte mehr als einmal aufgerufen werden«). Natürlich gibt es weitere, wie zum Beispiel »Halte den Code und die Dokumentation an derselben Stelle«, »Wenn du es nicht auf Deutsch sagen kannst, kannst du es auch nicht in C/C++ (oder Java, C#, Perl, Python usw.) sagen« und »Löse keine Probleme, die es nicht gibt«.

Übersetzt in die Welt des XML-Designs könnten diese fünf Regeln so lauten: »Wenn eine Deklaration länger als eine Seite ist, teile sie auf«, »Eine Deklaration sollte mindestens einmal referenziert werden« (wir werden als nächstes sehen, daß es Ausnahmen hiervon geben mag), »Halte den Code und die Dokumentation an derselben Stelle«, »Wenn du es nicht auf Deutsch sagen kannst, kannst du es auch nicht in XML sagen« und natürlich »Löse keine Probleme, die es nicht gibt«.

Global denken

Als ich begann, mit W3C XML Schema zu arbeiten, dachte ich, der Puppe-in-der-Puppe-Entwurf sei der einfachste, da er der Struktur der Instanzdokumente so nahe ist. Nachdem ich das Referenzhandbuch zu W3C XML Schema geschrieben habe, bin ich überzeugt, daß flache Strukturen, bei denen alle Elemente global sind, viel einfacher zu dokumentieren und ebenso einfach zu schreiben sind.

Der Entwurf mit der Puppe in der Puppe beruht auf einer Analogie zwischen objektorientierter Programmierung und Textauszeichnung. Das führt jedoch ein wenig in die Irre, denn es gibt so etwas wie private oder lokale Objekte in einem XML-Dokument nicht (außer vielleicht, wenn man einige Fragmente codiert oder verschlüsselt); wenn Sie ein XML-Dokument öffnen, liegt sein gesamter Inhalt offen, alles ist öffentlich und muß mit der gleichen Genauigkeit dokumentiert werden. Geben Sie einem Begriff einen Namen, um ihn zu beschreiben. W3C XML Schema verlangt die Zuweisung eindeutiger Namen nur für globale Elemente. Auch wenn unterschiedliche Inhaltsmodelle oft als Vorteil gegenüber DTDs dargestellt werden, ist es sehr verwirrend beim Lesen eines Instanzdokuments, wenn sie unter demselben Elementnamen definiert sind. Die praktischste Art, ein Referenzhandbuch für ein XML-Vokabular zu schreiben, ist ein Wörterbuch der Elemente. Denselben Elementnamen für verschiedene Zwecke wiederzuverwenden erzeugt mehrfache Einträge, die verwirrend und schwer lesbar sind (genau wie die Einträge für gängige Wörter wie beispielsweise »place« in einem englischen Wörterbuch); das Beispiel von W3C XML Schema mit den stark unterschiedlichen Bedeutungen von xs:extension ist hier lehrreich. Der zweite Rat besteht also darin, Elemente global zu definieren, soweit möglich. Dieser Rat gilt nicht für unqualifizierte Attribute, die nicht global definiert werden können.

Wenn es ähnlich ist, zeig es

Der dritte und letzte Rat widerspricht dem ersten, und zwischen den beiden muß abgewogen werden. Die ersten beiden Ratschläge führen zu dem, was ich flache Schemas nenne. Diese sind unserem allerersten Beispiel aus Verwendung und Entwicklung von Schemas ähnlich, bei dem sämtliche Elemente und Attribute global sind und lokale Typdefinitionen haben. Dieser Stil ist einfach zu lesen, hebt die Ähnlichkeiten zwischen Elementen jedoch nicht hervor, beispielsweise die Tatsache, daß Autoren und Buchfiguren als Personen betrachtet werden können und einige Eigenschaften gemeinsam haben. Wenn zwischen verschiedenen Elementen starke Ähnlichkeiten bestehen, kann die Verwendung einer der bereits besprochenen Techniken (entweder eine Ableitung komplexer Typen oder die Konstruktion einer Element- oder Attributgruppe) die Lesbarkeit des Schemas erhöhen.

Der dritte Ratschlag besagt, daß Sie die Möglichkeiten von W3C XML Schema nutzen sollten, um starke Ähnlichkeiten dort hervorzuheben, wo sie vorhanden sind.

   

<< zurück

vor >>