Namensraum-Deklarationen

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

Bis hierher haben wir Schemas für Dokumente gesehen, die keinerlei Namensraum-Deklaration hatten und daher zu keinem Namensraum gehörten. Um zu den Dokumenten ohne Namensräume zu passen, hatten auch die Schemas keine Namensraum-Deklaration, abgesehen von der einen, die zur Identifikation des Namensraums von W3C XML Schema selbst benötigt wird.

Damit unser Schema zu Elementen und Attributen paßt, die zu einem Namensraum gehören, müssen wir diesen Namensraum durch das Attribut targetNamespace des Elements xs:schema mit unserem Schema verknüpfen.

Wir ändern die Bibliothek so ab, daß sie einen einzigen Namensraum verwendet:

Nun müssen wir das Schema ändern, indem wir den Namensraum deklarieren und als Ziel-Namensraum festlegen:

Die Definition der Namensräume ist hier besonders wichtig, weil W3C XML Schema sie für zwei Zwecke benötigt.

Wie bei jedem XML-Dokument, das der Namensraum-Empfehlung entspricht, besteht der erste Zweck der Namensraum-Deklaration darin, eine URI-Referenz, die einen Namensraum bezeichnet, mit einem Präfix zu verknüpfen, das eine Abkürzung für diesen Bezeichner ist.

In unserem Beispiel finden wir zwei solche Deklarationen: xmlns:xs="http://www.w3.org/ 2001/XMLSchema" und xmlns:lib="http://dyomedea.com/ns/library".

Die erste der Deklarationen verknüpft den Namensraum von W3C XML Schema mit dem Präfix xs. Wir könnten selbstverständlich jedes beliebige Präfix gewählt oder diesen Namensraum sogar als Default-Namensraum verwendet haben; die Wahl xs ist lediglich allgemein üblich.

Die zweite Deklaration definiert den Namensraum, der in unserem Instanzdokument verwendet wird: xmlns:lib="http://dyomedea.com/ns/library". Hier haben wir das Präfix lib gewählt, obwohl dieser Namensraum für keines der Elemente oder Attribute des Schemas selbst verwendet wird. Wir hätten für diesen Namensraum auch ein beliebiges Präfix wählen oder ihn sogar als unseren Default-Namensraum definieren können.

Diese zweite Deklaration wird für die zweite Verwendung von Namensraum-Präfixen benötigt. W3C XML Schema benutzt Namensraum-Präfixe, um sämtliche Verweise auf die Komponenten eines Schemas (Datentypen, Elemente, Attribute, Gruppen usw.) aufzulösen, und sie werden auch für die XPath-Ausdrücke verwendet, die in den Deklarationen von xs:unique, xs:key und xs:keyref benutzt werden.

Wir haben noch nicht erwähnt, welchen Namensraum dieses Schema beschreibt. Die machen wir mit dem Attribut targetNamespace, das die URI-Referenz festlegt, die den Ziel-Namensraum identifiziert.

Mit diesem letzten Stück an Information weiß ein Schema-Prozessor nun, wie der Ziel-Namensraum lautet. Da die beiden Namensraum-Deklarationen bereits vollständig waren, weiß er auch, welches Präfix wir für ihn und für den Namensraum von W3C XML Schema verwenden wollen. Diese Information reicht aus, um unser Schema zu schreiben.

Die Verwendung der Namensraum-Präfixe, die W3C XML Schema und XSLT gemeinsam haben, wird sehr kontrovers beurteilt, da sie eine Abhängigkeit zwischen W3C XML Schema (als Anwendung betrachtet) und den für die Namensräume gewählten Präfixen schafft. Dies zerstört die Ebenenstruktur der XML-Spezifikationen: Die Auszeichnungen und ihr Inhalt hängen nun voneinander ab und können nicht mehr unabhängig voneinander geändert werden.

Ähnlich wie ein Kommunikationsprotokoll können die XML-Spezifikationen als ein Satz von Umschlägen angesehen werden. XML 1.0 ist die äußerste Hülle, in die die Namensräume eingebunden sind. Während die Anwendungen unabhängig von diesen Umschlägen sein sollten, bindet die Tatsache, daß W3C XML Schema die Namensraum-Präfixe innerhalb seiner eigenen Attribute verwendet, das Schema fest an seinen Umschlag. Dies ist ein sehr gefährliches Vorgehen, von dem bei anderen Vokabularen, die jeweils ihren eigenen Satz an Präfixen definieren, abgeraten werden sollte.

Eine der Folgerungen aus dieser Praxis besteht darin, daß »Canonical XML« (Kanonisches XML) dazu verpflichtet wurde, Namensraum-Präfix-Rewriting aus seinem Anforderungskatalog zu streichen. Daher haben die vier Ausprägungen unserer Bibliothek, die laut Namensraum-Empfehlung streng äquivalent sind, vier verschiedene kanonische Werte, was wiederum zu verschiedenen digitalen Signaturen führt.