Die Beständigkeit von Dokumenten

(Auszug aus "XML in a Nutshell" von Elliotte Rusty Harold & W. Scott Means)

XML-Dokumente, die von Computern gelesen werden sollen, sind oft sehr kurzlebig. Ein SOAP-Dokument (Simple Object Access Protocol) beispielsweise, das eine Anfrage an einen Windows-Server repräsentiert, auf dem .NET läuft, existiert nur genau so lange, wie der Client braucht, um die Anfrage an den Server zu senden, und der Server braucht, um sie in seine internen Datenstrukturen einzulesen. Danach wird das Dokument verworfen. Es lebt also weniger als zwei Minuten, geschweige denn zwei Jahre. Es handelt sich um eine flüchtige Kommunikation zwischen zwei Systemen und besteht nicht länger als die Milliarden anderen Meldungen, die Computer tagtäglich austauschen und die in der Regel nicht einmal irgendwo gespeichert oder gar für die Nachwelt archiviert werden.

Manche Anwendungen speichern beständigere computerorientierte Daten in XML. So ist XML das native Dateiformat der Tabellenkalkulation Gnumeric. Dieses Format wird jedoch nur von Gnumeric und möglicherweise anderen Gnome-Anwendungen verstanden. Es soll lediglich die Anforderungen dieses einen Programms erfüllen. Der Austausch von Daten mit anderen Anwendungen, einschließlich solchen, die es noch gar nicht gibt, ist zweitrangig.

XML-Dokumente, die für den menschlichen Gebrauch bestimmt sind, sind jedoch meist langlebiger und nicht an die Software gebunden. Wenn Sie die Unabhängigkeitserklärung der USA in XML kodieren, wollen Sie, dass diese auch in 2, 200 oder 2000 Jahren noch von Menschen gelesen werden kann. Sie soll außerdem mit jedem gewünschten Werkzeug gelesen werden können, einschließlich solchen, die noch gar nicht erfunden wurden. Diese Anforderungen haben einige wichtige Auswirkungen sowohl auf die XML-Anwendungen, die Sie entwerfen, um die Daten aufzunehmen, als auch auf die Werkzeuge, die Sie benutzen, um sie zu lesen und zu schreiben.

Die erste Regel lautet, dass das Format sehr gut dokumentiert sein sollte. Es muss ein Schema geben, und dieses Schema sollte ausführlich kommentiert sein. Darüber hinaus sollte es weitere schriftliche Dokumentationen geben. Solche Dokumentationen können die formale Dokumentation des Schemas nicht ersetzen, sie sind aber eine wertvolle Hilfe für das Verständnis des Schemas.

Standardformate wie DocBook und TEI sind eigenen, einmaligen XML-Anwendungen vorzuziehen. Vermeiden Sie proprietäre Schemas, die einer einzigen Person oder Firma gehören und deren Fortbestand von dem Wohl und Wehe dieser Firma oder Einzelperson abhängt. Und Schemas, die von nicht-kommerziellen Konsortien wie OASIS oder TEI stammen, sollten ausreichend großzügig lizenziert werden, so dass Beschränkungen des geistigen Eigentums es niemandem erlauben, Ihnen Steine in den Weg zu legen. Wenigstens ein XML-Hersteller ist so weit gegangen, tatsächlich Patente auf seine Schemas anzumelden. Diese Anwendungen sollten Sie meiden wie die Pest. Bleiben Sie bei solchen Schemas, die frei kopiert und weitergegeben werden dürfen und die an vielen verschiedenen Stellen zur Verfügung stehen.

Wenn Sie sich dann für eine Standard-Anwendung entschieden haben, vermeiden Sie es nach Möglichkeit, diese zu verändern. Sollte es sich nicht umgehen lassen, dann dokumentieren Sie Ihre Änderungen in allen Einzelheiten. Fügen Sie sowohl in Ihre Schemas als auch in Ihre Dokumente Kommentare ein, die erklären, was Sie getan haben. Benutzen Sie die Parameter-Entities, die in die DTD integriert sind, um neue Elementtypen einzufügen oder alte zu entfernen, anstatt die DTD-Dateien selbst zu verändern.

Umgekehrt sollte es nicht zu schwierig sein, das Format zu rekonstruieren, falls Dokumentation und Schemas verloren gehen. Achten Sie darauf, dass immer die vollständigen Namen für Elemente und Attribute benutzt werden. Das Element para aus DocBook ist dem Element p aus TEI vorzuziehen. Paragraph wäre noch besser.

Die gesamte dem Dokument innewohnende Struktur sollte allein durch das Markup gekennzeichnet werden. Sie sollte nicht vom Benutzer erst erraten werden müssen, noch sollte die Struktur durch Leer- oder andere Trennzeichen gestaltet werden. Hier ist ein Beispiel aus SVG, wie Sie es nicht machen sollten:

Das Attribut style enthält drei getrennte, nicht miteinander verwandte Einträge. Um dieses Element zu verstehen, muss das CSS-Format untersucht werden, das nicht XML ist. Das Attribut points ist sogar noch schlimmer. Es besteht aus einer langen Liste mit Zahlen, aber es gibt keinerlei Informationen darüber, was die einzelnen Zahlen zu bedeuten haben. Sie können zum Beispiel nicht sehen, welches die x- und welches die y-Koordinaten sind. Deshalb ist dieser Ansatz eher zu empfehlen:

Die attributbasierte style-Syntax ist in SVG eigentlich erlaubt. Allerdings war die Debatte darüber, welche Form für Koordinaten benutzt werden soll, in der SVG-Arbeitsgruppe des W3C wirklich hitzig. Die Gruppe beschloss am Ende – unserer Meinung nach fälschlicherweise –, dass die ausführlichere Form wegen ihrer Größe niemals angenommen werden würde, obwohl einige Mitglieder der Gruppe glaubten, dass sie eher dem Geist von XML entspräche. Wir glauben, dass die Arbeitsgruppe die Wichtigkeit der Größe eines Dokuments in einer Ära der exponentiell ansteigenden Festplattenkapazitäten und Netzwerkbandbreiten überbewertet hat, ganz zu schweigen von der Leichtigkeit, mit der das zweite Format für die Übertragung oder Speicherung komprimiert werden könnte.

Stylesheets sind wichtig. Wir sind alle damit vertraut, dass Präsentation und Inhalt getrennt werden. Sie sind oft genug davor gewarnt worden, reine Style-Informationen wie Kursivsetzungen oder Schriftfestlegungen in Ihre XML-Dokumente einzufügen. Achten Sie jedoch auch darauf, dass Sie nicht den anderen Weg gehen und Inhalt in Ihre Stylesheets integrieren. Namen von Autoren, Titel, Copyright-Angaben und andere Informationen, die sich von Dokument zu Dokument ändern, gehören in das Dokument, nicht in das Stylesheet, selbst wenn sie Metainformationen über das Dokument statt des eigentlichen Inhalts enthalten.

Behalten Sie immer im Hinterkopf, dass Sie nicht für die nächsten Monate oder Jahre, sondern möglicherweise für die nächsten Jahrtausende schreiben. Haben Sie ein wenig Mitleid mit dem armen Historiker, der Ihr Markup mit Hilfe eingeschränkter Werkzeuge wird entziffern müssen.