Mehr Freiheit bedeutet auch mehr Verantwortung und mehr Verantwortung bedeutet mehr Aufwand. Diese einfache Formel gilt auch für XML-Formate, die ihren Anwendungen die Freiheit bieten, zusätzliche, also vorab nicht definierte Daten in ein Dokument des jeweiligen Formats zu packen. Hier wären wir wieder, beim Thema Namensräume, und damit bei ihrem dritten Anwendungszweck, der Erweiterbarkeit.

Fremdkörper

Das Thema ist eigentlich durch, zumindest was diese Kolumne anbelangt. So hat sich unter anderem die Folge Wofür steht eigentlich das "X" mit der Notwendigkeit und der Definition so genannter Erweiterungspunkte in XML Schema beschäftigt. Der Schlüssel zum Erfolg ist xs:any. An den Stellen in einem XML-Dokument, die durch das Element xs:any im Schema beschrieben sind, können beliebige, aus einem fremden Namensraum stammende Elemente eingefügt werden, die nicht ausdrücklich im Schema erwähnt werden.

Dank der unterschiedlichen Namensräume können diese Elemente sogar Namen tragen, die bereits für Elemente des Containerformats vergeben sind. Namensräume stellen somit vor allem die Eindeutigkeit von Element- und Attributnamen sicher (siehe hierzu Namensraumverwirrung). Darüber hinaus sind Namensräume für die Validierbarkeit von XML-Dokumenten relevant, da sie die Elemente dem passenden Schema zuordnen – auf logischer Ebene. Die physikalische Zuordnung erfolgt, wie die Folge Türsteher zeigte, mittels des schemaLocation-Ansatzes.

Seitensprung

Zu Recht fragte ein Leser (dem hier mein Dank gebührt) daraufhin, worin denn der Sinn bestünde, dass man mehr als einen Namensraum und ein Schema im schemaLocation-Attribut angeben könne. Man könne doch auch im Hauptschema per xs:import auf andere Schema-Dateien verweisen. Das stimmt.

Die Notwendigkeit, zwei, drei oder mehr Paare von logischen Namensräumen und physikalischen Schema-Dateien anzugeben, ergibt sich erst durch die Verwendung von Erweiterungspunkten und -elementen. Das xs:any-Element und das schemaLocation-Attribut befreien den Entwickler davon, bereits zur Anwendungsentwicklung sämtliche potenziellen Namensräume und Schemas fest in die Anwendung einzuprogrammieren.

Verantwortungsbewusstsein
So viel Freiheit macht manchem Entwickler Angst. Sie oder er fragt sich verständlicherweise: wie soll meine Anwendung mit so viel Ungewissheit umgehen? Wer übernimmt die Verantwortung für die unbekannten Erweiterungselemente?

Antworten auf diese Fragen bietet die XML-Schema-Spezifikation. Sie macht es vor: sie nutzt Namensräume, um Verantwortlichkeiten zuzuordnen. Und genauso können Sie es in Ihren Anwendungen machen. Jedem Namensraum ist ein eigenes Programmmodul, beispielsweise eine Klasse oder Komponente, zugeordnet. Diese kennt das zugehörige Format und weiß um die Verarbeitung der entsprechenden Daten. Ein zentrales Eingabemodul ist dafür verantwortlich, beim Einlesen eines XML-Dokuments die Verarbeitung an die jeweiligen Module zu delegieren und die Teilergebnisse des Prozesses zu einem Ganzen zusammenzufassen.

Dynamik
Das funktioniert statisch, also mit fest kodierten Zuordnungen, aber vor allem auch dynamisch. Eine Konfigurationsdatei, zum Beispiel ein XML-Dokument, ordnet Namensräume Modulen zu. Diese werden logisch durch ihren Namen identifiziert und gegebenenfalls physikalisch durch die Pfadangabe zu einer Programmbibliothek (beispielsweise einer DLL- oder JAR-Datei) lokalisiert. Ähnlich dem Plugin-Modell populärer Programme können solche Anwendungen und deren Dokumentformate einfach um Erweiterungen von Drittherstellern ergänzt werden, indem ein zusätzliches Modul installiert und in der genannten Konfigurationsdatei registriert wird.

Nicht geklärt ist hiermit die Frage, wie die einzelnen Module ineinandergreifen und zusammenarbeiten, um aus den Daten ein brauchbares Gesamtergebnis zu produzieren. Das hängt sehr stark vom jeweiligen Anwendungsfall ab. Eine Publishing-Anwendung, die XML als erweiterbares Datenformat nutzt, könnte beispielsweise den Namensräumen verschiedene Visualisierungsmodule zuordnen.  Für Elemente aus unbekannten Namensräumen werden anstelle der "on-the-fly" visualisierten Daten nur Vorschaubilder angezeigt, die von der Vorgängeranwendung bei der Erstellung der Daten erzeugt und im Dokument abgelegt wurden.

Endergebnis
Mehr Freiheit bedeutet vor allem auch mehr Möglichkeiten und mehr Möglichkeiten bedeuten mehr Lösungsoptionen für die Probleme ihrer Anwender. Natürlich ist damit auch ein Mehr an Aufwand für den Programmierer verbunden. Der steigt jedoch dank des Erweiterungsmodells von XML und mit der Möglichkeit, mittels Namensräumen im Programm Verantwortlichkeiten klar festzulegen, nur linear mit der Anzahl der Erweiterungen. Es bedarf allerdings zu Beginn der Anwendungsentwicklung ein Mehr an Planung und ein Wenig an Weitsicht.

Martin Szugat ist als Fachautor, Konferenzsprecher und Berater für XML-basierte Technologien tätig. Neben der Kolumne Naked XML schreibt er auch für das dot.net magazin an der XML-Corner und betreut für das Webmagazin Create Or Die den Themenbereich "Social Networks". Sie erreichen ihn via E-Mail an martin.szugat@techworker.net.