Gute Frage! Klar, mit der eXtensible Markup Language lassen sich beliebige Sprachen beziehungsweise Formate - aus anwendungsorientierter Perspektive gesehen - definieren. Somit ist XML erweiterbar im Sinne von: das Anwendungsspektrum von XML lässt sich beliebig erweitern. Doch die XML-Anwendungen selbst, namentlich die Formate, sind oftmals erstaunlich verschlossen gegenüber Erweiterungen.

My home is my castle
Das ist verständlich. Denn es macht die Sache für den XML-Schema-Designer wesentlich einfacher. Er definiert nur das, was er kennt und braucht. Es erleichtert auch die Arbeit des Entwicklers. Er weiß, was ihn oder vielmehr sein Programm erwartet. Immerhin ist genau das der Vorteil eines Schemata: es schützt vor bösen Überraschungen, indem es die maschinelle Validierung der Eingabedokumente ermöglicht.

Einer wird sich über diese wohl definierte und in sich abgeschlossene Welt vermutlich jedoch nicht freuen: der Anwender. Denn er ist in dieser Welt gefangen. XML ist aber vor allem ein Format für den Datenaustausch und dient damit der Überwindung von Anwendungs-, Plattform- und Sprachgrenzen. Es erleichtert verschiedenen Anwendungen und deren Anwendern, Daten auszutauschen, indem es ein grundlegendes Regelwerk definiert, wie die Daten zu formatieren sind. XML soll also Menschen aus verschiedenen Anwendungswelten verbinden anstatt sie in diesen einzusperren.

Doch wie so oft kann man es nicht allen recht machen. Dies gilt ganz besonders für die Spezifikation eines anwendungsübergreifenden Dokumentenformats. Software-Anwendungen, insbesondere derselben Gattung wie etwa Textverarbeitungsprogramme, unterscheiden sich insbesondere durch ihre Features, also jene zusätzlichen Programmfunktionen, welche die Kernfunktion eines Programms (Text zu schreiben) ergänzen. Sie bilden ein Alleinstellungsmerkmal gegenüber der Konkurrenz und sind damit oftmals kaufentscheidend.

Ein Format kann aber nicht sämtliche Funktionen aller potenziellen Anwendungen abdecken und sollte dies auch nicht. Es kann dies nicht, weil die Hersteller ihre Anwendungen aufgrund des Wettbewerbs kontinuierlich um weitere Funktionen erweitern werden, ein Format jedoch relativ stabil bleiben muss. Es sollte dies nicht, weil nicht alle Hersteller alle erdenklichen Funktionen umsetzen wollen oder können. Jede zusätzliche Funktion erhöht daher die Wahrscheinlichkeit, dass eine Anwendung diese nicht unterstützt und damit nicht hundertprozentig kompatibel zum Format ist.

Kompatibilität zu einem etablierten Standard ist aber oftmals ein weiteres kaufentscheidendes Feature. Damit aus einem Format jedoch ein Standard wird, bedarf es wiederum genügend kompatibler Programme und die wird es nur geben, wenn das Format einerseits einfach zu implementieren ist, aber andererseits auch genügend Spielraum für anwendungsspezifische Erweiterungen bietet.

Open Gardens
Die Lösung liegt in der Beschränkung auf das Wesentliche:

„Ein Text ist nicht dann vollkommen, wenn man nichts mehr hinzufügen, sondern nichts mehr weglassen kann!“ (Antoine de Saint-Exupéry)

Das Wesentliche ist im Falle eines Dokumentenformats das Gemeinsame – also die den Anwendungen gemeinsamen Funktionen. Doch was ist mit dem Optionalen – also den dem Dokumentenformat unbekannten Funktionen? Sie benötigen, da sie spezifisch für eine Anwendung sind, eine eigene, vom Dokumentenformat getrennte (nicht aber notwendigerweise unabhängige) Formatbeschreibung, demnach ein separates Schemata und folglich auch einen unverwechselbaren Namensraum-URI.

Die eigentlichen Daten erwartet der Benutzer allerdings weiterhin im Dokument. Niemand möchte ein Sammelsurium aus Dateien beispielsweise per E-Mail verschicken müssen. Hier kommt das „X“ in XML zum Tragen. XML erlaubt es, Daten aus verschiedenen Namensräumen miteinander zu kombinieren – sofern das jeweilige Schemata dies zulässt. Denn zumindest bei der XML-Schema-Spezifikation gilt: was nicht ausdrücklich erlaubt ist, ist grundsätzlich verboten.

Hot spots
Und so überrascht es wenig, dass nur ca. 15 Prozent von 1400 untersuchten Schemata Wildcards nutzen. Eine Wildcard definiert einen Erweiterungspunkt („extension point“ oder auch „hot spot“ genannt), an dem Anwendungen ihre spezifischen Daten „reinhängen“ können. Anderen Anwendungen steht es in der Regel frei, diese Fremddaten zu verarbeiten oder zu ignorieren. Zur Identifikation des Datenformats dient der Namensraum-URI.

Ein bekanntes Beispiel für ein erweiterbares Format ist SOAP. So ermöglicht der SOAP-Header den Kommunikationspartnern eines Web Services beliebige, zusätzliche Daten mit der SOAP-Nachricht zu versenden:

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" 
   soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
<auth:id xmlns:auth="http://www.aboutxml.de/2007/authentification" 
   soap:mustUnderstand="1">Martin Szugat</auth:id>
</soap:Header>
...
</soap:Envelope>

Je nach Wert des Attributs mustUnderstand obliegt es dem Client beziehungsweise dem Server die zusätzliche Information zu ignorieren oder angemessen darauf zu reagieren. Das Attribut mustUnderstand ist allerdings eine Spezialität von SOAP und keineswegs ein Bestandteil der XML-Schema-Spezifikation. Die kennt nur zwei sehr einfache Typen von Wildcards: einen für Elemente und einen für Attribute. Die Beschreibung des Header-Elements nutzt beide Spielarten und erlaubt damit für das Header-Element sowohl beliebige Attribute als auch beliebige Elemente:

<xs:complexType name="Header" > 
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" 
   maxOccurs="unbounded" />
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>

Das Element any steht hierbei als Platzhalter („wildcard“) für Elemente, wobei der Zusatz „##any“ Elemente aus beliebigen Namensräumen erlaubt. Das Element anyAttribute ist folglich ein Platzhalter für Attribute. Die Angabe von „##other“ beschränkt die Auswahl der Attribute jedoch auf Fremdattribute, also auf Attribute, die nicht dem SOAP-Namensraum entstammen. Schließlich sorgt das Attribut processContents dafür, dass die fremden Inhalte nach Möglichkeit, d.h. sofern ein passendes Schemata vorhanden ist, validiert werden. Andernfalls kann der XML-Parser auf die Validierung der Fremddaten verzichten, ohne jedoch die Gültigkeit des gesamten Dokuments in Frage stellen zu müssen.

200X
Das „X“ hat XML also durchaus verdient. Es obliegt jedoch dem Sprachenentwickler aus einer Markup-Sprache eine erweiterbare Markup-Sprache zu machen. Die Mittel hierfür sind in XML Schema vorhanden. Alles, was Sie brauchen, um in 2007 erweiterbare XML-Formate zu entwickeln, kennen Sie nun. Doch der Teufel steckt bekanntlich im Detail und so wird uns das Thema Erweiterbarkeit auch im neuen Jahr begegnen und beschäftigen.

Einen guten Rutsch und ein erfolgreiches Jahr 2007 wünscht Ihnen

Ihr Martin Szugat

Martin Szugat ist Fachautor, Softwareentwickler und Blogger und spezialisiert auf das Thema XML. Sie erreichen ihn bei Fragen und Feedback via E-Mail an nakedxml@entwickler.de.