Schema-Inklusion

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

Die erste und direkteste Art, Schema-Bibliotheken aufzubauen, ist die Einbindung oder Inklusion. Diese Konstruktion ist der Inklusion bei den traditionellen Programmiersprachen wie etwa C sehr ähnlich. Verglichen mit der »physischen« Einbindung, beispielsweise als Ergebnis der Expansion eines Verweises auf ein externes Entity oder mit Hilfe von XInclude (das im Abschnitt »XInclude« beschrieben wird), ist die Schema-Inklusion ein »logischer« Mechanismus, der die Semantik der Einbindung steuern kann. Schema-Einbindung kann auch als Sonderfall der Schema-Redefinition angesehen werden. Dabei muß man beachten, daß die Einbindung wie auch die Redefinition eines Schemas auf einen einzelnen Namensraum (oder auf gar keinen) festgelegt ist. Ein anderer Mechanismus, nämlich der Schema-Import, der unter Kontrolle über Namensräume besprochen wird, muß verwendet werden, um Definitionen in andere Namensräume zu importieren.

Schema-Einbindungen müssen Elemente der obersten Ebene, also Kinder des Elements xs:schema, sein. Ihr Ergebnis ist der Einschluß aller Deklarationen der obersten Ebene des eingebundenen Schemas (das kein vollständiges Schema sein muß). Die aufgenommenen Top-Level-Elemente werden dann als Top-Level-Elemente des sich ergebenden Schemas angesehen. Es gibt keine Prioritäts- oder Vorrangregeln. Die Konflikte, die entstehen können, wenn eine lokale Definition in beiden Schemas auftritt, werden als Fehler betrachtet. Wir könnten diese Eigenschaft nutzen, um all unsere einfachen Typdefinitionen in einem eigenen Schema anzusiedeln. Dieses Unterschema würde so aussehen:

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:simpleType name="string255">
      <xs:restriction base="xs:token">
         <xs:maxLength value="255"/>
      </xs:restriction>
   </xs:simpleType>
   <xs:simpleType name="string32">
      <xs:restriction base="xs:token">
         <xs:maxLength value="32"/>
      </xs:restriction>
   </xs:simpleType>
   <xs:simpleType name="isbn">
      <xs:restriction base="xs:NMTOKEN">
         <xs:length value="10"/>
         <xs:pattern value="[0-9]{9}[0-9X]"/>
      </xs:restriction>
   </xs:simpleType>
   <xs:simpleType name="bookID">
      <xs:restriction base="xs:ID">
         <xs:pattern value="b[0-9]{9}[0-9X]"/>
      </xs:restriction>
   </xs:simpleType>
   <xs:simpleType name="supportedLanguages">
      <xs:restriction base="xs:language">
         <xs:enumeration value="en"/>
         <xs:enumeration value="de"/>
      </xs:restriction>
   </xs:simpleType>
   <xs:simpleType name="date">
      <xs:restriction base="xs:date">
         <xs:pattern value="[^:Z]*"/>
      </xs:restriction>
   </xs:simpleType>
</xs:schema>

Dies könnten wir in unser Hauptschema mit der folgenden Zeile aufnehmen:

<xs:include schemaLocation="simple-types.xsd"/>

In diesem Beispiel ist die Abhängigkeit eine Einbahnstraße: Die einfachen Typen werden in simple-types.xsd definiert und in unserem Hauptschema verwendet. Das eingebundene Schema ist für sich genommen nicht sehr nützlich. Es deklariert keine Elemente und kann nicht als alleinstehendes Schema benutzt werden, denn es könnte keine Dokumente validieren. Es ist jedoch ein vollständiges Schema, das keine Verweise außer auf vordefinierte einfache Typen enthält. Vollständigkeit des eingebundenen Schemas wird nicht vorausgesetzt, wie wir sehen, wenn wir dasselbe für unsere Definitionen komplexer Typen durchführen:

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:complexType name="elementWithID">
      <xs:attribute ref="id"/>
   </xs:complexType>
   <xs:complexType name="bookTmp">
      <xs:complexContent>
         <xs:extension base="elementWithID">
            <xs:sequence>
               <xs:element ref="isbn"/>
               <xs:element ref="title"/>
               <xs:element ref="author" minOccurs="0" maxOccurs="unbounded"/>
               <xs:element ref="character" minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attribute ref="available"/>
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>
   <xs:complexType name="personType">
      <xs:complexContent>
         <xs:extension base="elementWithID">
            <xs:sequence>
               <xs:element ref="name"/>
               <xs:element ref="born"/>
               <xs:element ref="dead" minOccurs="0"/>
               <xs:element ref="qualification" minOccurs="0"/>
            </xs:sequence>
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>
</xs:schema>

Wir können nun beide Fragmente in unser Hauptschema aufnehmen:

<xs:include schemaLocation="simple-types.xsd"/>
<xs:include schemaLocation="complex-types.xsd"/>

Wir haben jetzt ein eingebundenes Schema (complex-types.xsd), das auf Elemente (beispielsweise author, character oder dead) verweist, die im Hauptschema mit Hilfe von Datentypen definiert sind, die ihrerseits entweder in simple-types.xsd oder in complex-types.xsd definiert werden. Diese Kombination ist in W3C XML Schema problemlos erlaubt, denn der Schema-Prozessor sammelt vor der Prüfung der Verweise alles ein, was er braucht (jedenfalls das meiste, was er braucht, denn Wildcards können Ausnahmen erzeugen, wie wir unter Objektorientierte Konstruktion weiterer Bausteine sehen werden). Diese Flexibilität ist mächtig, sie ist nützlich beim Aufbau flexibler Bibliotheken, und sie ist gelegentlich auch fehleranfällig. Ein komplexer Datentyp, beispielsweise personType, wird immer dieselben Kindelemente haben, diese Kindelemente werden jedoch unterschiedliche Inhaltsmodelle haben, je nach dem Schema, in das complex-types.xsd gerade eingebunden worden ist. Wenn man diese Mechanismen verwendet, muß man sorgfältig die gegenseitigen Abhängigkeiten im Blick behalten, die dadurch erzeugt werden.

   

<< 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