Chamäleon-Design

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

Dieses Kapitel wäre ohne einen Blick darauf, wie sich Namensräume auf die Einbindung von Schemas mit xs:include und xs:redefine auswirken, nicht vollständig.

Als wir diese Konstruktionen ursprünglich eingeführt haben, haben wir uns nicht um Namensräume gekümmert. Sie zeigen jedoch einige wichtige Interaktionen mit Namensräumen, da W3C XML Schema die Einbindung (bzw. die Redefinition) auf Schema-Teile beschränkt, die entweder denselben Ziel-Namensraum oder gar keinen Ziel-Namensraum haben. (Schemas für andere Sprachen werden »importiert« statt »inkludiert«.)

Wenn ein Teil eines Schemas, das keinen Ziel-Namensraum hat, in ein Schema mit Ziel-Namensraum eingebunden wird, nimmt die eingebundene Definition den Ziel-Namensraum des einbindenden Schemas an und verhält sich genau so, als hätte es denselben Ziel-Namensraum. Dieses Merkmal ermöglicht es, Bibliotheken mit Schema-Teilen zu erstellen, die »namensraumtransparent« sind und die den Namensraum des Schemas, das sie einbindet, annehmen. Diese Methode wird oft »Chamäleon« genannt, weil das eingebundene Schema die »Farbe« des Umfelds, in das es eingebunden wird, annimmt.

Um dieses Merkmal und die sich daraus ergebenden Folgerungen zu veranschaulichen, sehen wir uns nochmals das Beispiel an, das wir in diesem Kapitel bisher verwendet haben:

<?xml version="1.0"?>
<library xmlns="http://dyomedea.com/ns/library">
   <book id="b3810518883">
      <title>
         Auf den Hund gekommen
      </title>
      <authors>
         <person id="CMS">
            <name>
               Charles M. Schulz
            </name>
         </person>
      </authors>
   </book>
</library>

Wenn wir eine Bibliothek von Schema-Stücken wollen, die eine Person beschreiben und in verschiedene Vokabulare eingebunden werden können, können wir ein Schema-Stück aufnehmen, das keinen Ziel-Namensraum hat. Dieses Schema-Stück würde etwa wie das folgende aussehen (wobei wir keinen Ziel-Namensraum definieren):

<?xml version="1.0"?>
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:element name="person">
      <xs:complexType>
         <xs:sequence>
            <xs:element name="name" type="xs:string"/>
         </xs:sequence>
         <xs:attribute name="id" type="xs:string" use="required"/>
      </xs:complexType>
   </xs:element>
</xs:schema>

Und das einbindende Schema würde etwa folgendermaßen aussehen:

<?xml version="1.0"?>
<xs:schema targetNamespace="http://dyomedea.com/ns/library" elementFormDefault="qualified" xmlns="http://dyomedea.com/ns/library" xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:include schemaLocation="very-simple-1-ns-ppl.xsd"/>
   <xs:element name="library">
      <xs:complexType>
         <xs:sequence>
            <xs:element name="book">
               <xs:complexType>
                  <xs:sequence>
                     <xs:element name="title" type="xs:string"/>
                     <xs:element name="authors">
                        <xs:complexType>
                           <xs:sequence>
                              <xs:element ref="person"/>
                           </xs:sequence>
                        </xs:complexType>
                     </xs:element>
                  </xs:sequence>
                  <xs:attribute name="id" type="xs:ID"/>
               </xs:complexType>
            </xs:element>
         </xs:sequence>
      </xs:complexType>
   </xs:element>
</xs:schema>

Auch wenn das einfach und sauber aussieht, sollten wir uns fragen, ob wir wirklich etwas Modulares aufbauen. Einen Teil eines Schemas einzubinden ist so ähnlich wie ein Include einer C-Headerdatei. Auch wenn dies ein wenig besser als Kopieren/Einfügen ist, ist der Grad an Modularität, den wir auf diese Weise erreichen können, sehr eingeschränkt.

Der Namensraum des Elements person ist der Namensraum, den unsere Bibliothek erhalten hat. Eine Anwendung kann durch Betrachten des Instanzdokuments nicht erraten, daß dieses Element dasselbe wie ein Element person ist, das sie später in einem anderen Dokument findet und das dort beispielsweise einen Angestellten beschreibt.

Die Betrachtung des veränderten Infosets und die Prüfung des Datentyps hilft auch nicht weiter, da der Datentyp als ein Datentyp aus einem Schema mit dem Ziel-Namensraum unserer Bibliothek definiert ist und daher nicht zu anderen Ziel-Namensräumen passen wird, die denselben Schema-Teil einbinden.

Die Tatsache, daß dasselbe Element person durch verschiedene Vokabulare verwendet wird, geht durch die Verarbeitung der Einbindung (bzw. der Redefinition) vollständig verloren. Bevor Sie dies verwenden, sollten Sie sich fragen, ob es nicht nützlicher ist, mit Hilfe eines eigenen Namensraums Informationen in das Instanzdokument aufzunehmen oder zumindest Information in das veränderte Infoset aufzunehmen, indem Sie Datentypen aus einem anderen Namensraum importieren, statt gemeinsame Definitionen einzubinden.

   

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema XML Schema bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

Copyright © 2003 O'Reilly Verlag GmbH & Co. KG
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "XML Schema" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

O’Reilly Verlag GmbH & Co. KG, Balthasarstraße 81, 50670 Köln, kommentar(at)oreilly.de