Verknüpfung von Schemas mit Instanzdokumenten

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

Das erste Stück an Information, das für einen Schema-Prozessor nützlich sein kann, sind Hinweise auf den Ort, an dem der Schema-Prozessor Schemas finden kann, die für das Instanzdokument relevant sind. Dies ist dem SYSTEM-Bezeichner der XML-Doctype-Deklaration ähnlich, weist aber einige bedeutsame Unterschiede auf. Der erste Unterschied liegt darin, daß ein einziges Schema möglicherweise nicht ausreicht, um ein Dokument zu beschreiben, da jedes Schema nur einen einzigen Namensraum (oder den Mangel an selbigem) beschreiben könnte und die Zusammensetzung der Schemas im Instanzdokument geschehen kann. Der zweite Unterschied besteht darin, daß die Orte, die in den Instanzdokumenten angezeigt werden, nur als Hinweise betrachtet werden und sowohl vom Benutzer als auch vom Schema-Prozessor anders festgelegt werden können.

Die feste Verbindung zwischen einem XML-Dokument und seiner DTD hat zu vielen Debatten in der XML-Gemeinschaft geführt. Viele Entwickler erinnern sich noch daran, was geschah, als Netscape die Website umstrukturierte. Die DTD-Adresse für RSS 0.91 ("http://my.netscape.com/publish/formats/rss-0.91.dtd") lieferte plötzlich nur noch einen Fehler 404, wodurch Hunderte von Anwendungen nicht mehr liefen. Eine weitere Motivation für »weiche« Verbindungen zwischen Instanzdokumenten und ihren Schemas liegt darin, daß dies die Anwendung unterschiedlicher Schemas, entsprechend den jeweils lokal benutzten Verarbeitungsregeln, erlaubt. Beispielsweise kann ein Lieferant, der einen Auftrag als XML-Dokument erhält, spezielle Regeln haben, um das Dokument mit seinem eigenen Schema zu überprüfen.

Aus all diesen Gründen legt die Recommendation fest, daß ein Schema-Prozessor, der derartige Informationen in einem Dokument findet, versuchen sollte, die Schemas an der angegebenen Stelle zu finden, daß er von der aufrufenden Anwendung oder dem Benutzer jedoch auch andere Anweisungen erhalten könnte. Fehlt eine solche Information, kann ein Schema-Prozessor von der aufrufenden Anwendung ebenfalls angewiesen werden, an bestimmten Orten nachzusehen. Wenn weder die aufrufende Applikation noch das Instanzdokument irgendeine Information bereitstellt, darf der Schema-Prozessor auf beliebige Weise nach einem Schema suchen. Zu den Methoden, die für diesen Fall aufgeführt sind, gehört, daß ein Schema-Prozessor versuchen kann, die unter dem Namensraum-URI verfügbare Ressource zu laden, um zu prüfen, ob dort ein Schema veröffentlicht ist; er könnte jedoch auch andere Techniken probieren, beispielsweise RDDL- oder Katalogsysteme.

W3C XML Schema definiert zwei Attribute, um erstens eine Liste von Schema-Orten, die mit Ziel-Namensräumen verbunden sind, und zweitens den Ort eines Schemas ohne Ziel-Namensraum festzulegen. Das Attribut, das angewendet werden soll, wenn es keinen Ziel-Namensraum gibt, ist xsi:noNamespaceSchemaLocation. Sein Wert ist ein URI, der auf das entsprechende Schema zeigt. Auch wenn dieses Attribut ohne Deklaration in jedem Element eines jeden Instanzdokuments verwendet werden kann, muß es vom Schema-Prozessor gefunden werden, bevor er irgendein Element oder Attribut validieren muß (d.h. spätestens am letzten Punkt des ersten Elements ohne Namensraum, das in dem Dokument angetroffen wird). Zudem ist sein Gültigkeitsbereich global das ganze Dokument, und der Wert kann nicht redefiniert werden.

In der Praxis wird das Attribut xsi:noNamespaceSchemaLocation oft im Dokumentenelement untergebracht werden. Wir können ein Schema namens first.xsd im selben Verzeichnis wie das Instanzdokument des in diesem Kapitel verwendeten Beispiels (das keinen Namensraum verwendet) finden:

<library xsi:noNamespaceSchemaLocation="first.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  .../...
</library>

Um auf Schemas mit Ziel-Namensraum zu verweisen, müssen mit dem Attribut xsi:schemaLocation URI-Listen angegeben werden. Tatsächlich ist diese Liste sogar eine Liste von URI-Paaren. Bei jedem Paar bezeichnet der erste URI einen Ziel-Namensraum, und der zweite URI bezeichnet den Ort eines Schemas mit diesem Ziel-Namensraum. Dieselbe Regel wie schon bei xsi:noNamespaceSchemaLocation gilt auch für die Position dieses Attributs: Für jeden Ziel-Namensraum, für den Sie einen Schema-Ort angeben wollen, müssen Sie diese Information liefern, bevor ein Schema-Prozessor mit seiner Arbeit beginnen muß.

Um die Verwendung des Attributs xsi:schemaLocation zu veranschaulichen, sehen wir uns eine vereinfachte Fassung eines Beispiels mit den beiden Namensräumen an, die unter Kontrolle über Namensräume beschrieben wurden. Das Instanzdokument sieht wie folgt aus (ganz ohne xsi:schemaLocation):

<?xml version="1.0"?>
<book id="b3810518883" xmlns="http://dyomedea.com/ns/library" xmlns:mkt="http://dyomedea.com/ns/library/mkt">
   <title>
      Auf den Hund gekommen
   </title>
   <author>
      Charles M. Schulz
   </author>
   <mkt:cover>
      Paperback
   </mkt:cover>
   <mkt:pages>
      128
   </mkt:pages>
</book>

Wir nehmen ein offenes Schema für die Haupt-Namensräume, das beliebige Elemente aus anderen Namensräumen zuläßt, etwa wie das folgende:

<?xml version="1.0"?>
<xs:schema targetNamespace="http://dyomedea.com/ns/library" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:lib="http://dyomedea.com/ns/library" xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:element name="book">
      <xs:complexType>
         <xs:sequence>
            <xs:element name="title" type="xs:token"/>
            <xs:element name="author" type="xs:token" maxOccurs="unbounded"/>
            <xs:any namespace="##other" processContents="lax" minOccurs="0"maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="id" type="xs:ID"/>
      </xs:complexType>
   </xs:element>
</xs:schema>

Wir formulieren auch ein Schema für die zwei Elemente, die zum Namensraum unserer Marketing-Abteilung gehören:

<?xml version="1.0"?>
<xs:schema targetNamespace="http://dyomedea.com/ns/library/mkt" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:element name="cover" type="xs:NMTOKEN"/>
   <xs:element name="pages" type="xs:nonNegativeInteger"/>
</xs:schema>

Dieses Beispiel ist sorgfältig so gewählt worden, daß es zwei Schemas für zwei Namensräume gibt, die nicht untereinander verbunden sind. Es gibt keinen Verweis auf den Marketing-Namensraum aus der Bibliothek und umgekehrt. Wir haben nun mehrere Möglichkeiten, je nachdem, welche Tips der Schema-Prozessor erhalten hat. Wenn wir das Instanzdokument ohne ein Attribut xsi:schemaLocation und ohne entsprechende Informationen von der Anwendung oder vom Programmaufruf validieren, bleibt es dem Schema-Validierer überlassen, ein Schema zu suchen. Je nach dem Verfahren, das in dem Prozessor implementiert ist, versucht er vielleicht, auf die Namensraum-URIs des Dokumentenelement zuzugreifen (d.h., er versucht, eine Ressource zu laden, die hier möglicherweise zu finden ist). In unserem Fall ist dies "http://dyomedea.com/ns/library". Wenn es dort kein Schema gibt, kann er nicht entscheiden, ob das Dokument gültig ist oder nicht. Alternativ kann der Schema-Prozessor versuchen, ein RDDL-Dokument an dieser Stelle zu laden, und hoffen, darin einen Verweis auf ein Schema zu finden.

Typischerweise wird der Autor des Instanzdokument aber wohl nett genug sein, den Ort des Schemas für den Bibliotheks-Namensraum anzugeben – zum Beispiel:

<?xml version="1.0"?>
<book xsi:schemaLocation="http://dyomedea.com/ns/library library.xsd" id="b3810518883" xmlns="http://dyomedea.com/ns/library" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:mkt="http://dyomedea.com/ns/library/mkt">
   <title>
      Auf den Hund gekommen
   </title>
   <author>
      Charles M. Schulz
   </author>
   <mkt:cover>
      Paperback
   </mkt:cover>
   <mkt:pages>
      128
   </mkt:pages>
</book>

Wir haben keine Möglichkeit auszuwählen, wo wir xsi:schemaLocation unterbringen, denn die Information wird benötigt, um das Dokumentenelement zu validieren. Wenn wir das Attribut angeben wollen, muss es im Dokumentenelement sein. Dieses Attribut enthält ein einzelnes, Whitespace-separiertes Wertepaar:

"http://dyomedea.com/ns/library library.xsd"

Wie bereits erwähnt, bezeichnet der erste Wert den Ziel-Namensraum, während der zweite Wert den Ort des Schemas angibt. Mit diesen Informationen kann der Prozessor das Schema lesen und damit beginnen, das Instanzdokument zu validieren. Irgendwann trifft er dann auf den Marketing-Namensraum, der auf das Wildcard xs:any paßt. Dessen Attribut processContents besagt, daß nach Möglichkeit eine Validierung durchgeführt werden soll, und daher sucht der Prozessor möglicherweise erneut nach einem Schema für diesen Namensraum, indem er auf den Namensraum-URI zugreift. Kann er ein Schema finden, validiert er die Elemente aus dem Marketing-Namensraum; wenn nicht, betrachtet er sie als gültig, da das Attribut processContents auf »lax« steht.

Wenn wir unsere Chance erhöhen wollen, ein Schema für die Marketing-Bibliothek zu finden, können wir dessen Ort ebenfalls in einem xsi:schemaLocation-Attribut festlegen. Die Stelle im Instanzdokument, an dem wir die Information angeben können, ist das erste Element, das diesen Namensraum verwendet, also etwa:

<?xml version="1.0"?>
<book id="b3810518883" xsi:schemaLocation="http://dyomedea.com/ns/library library.xsd" xmlns="http://dyomedea.com/ns/library" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:mkt="http://dyomedea.com/ns/library/mkt">
   <title>
      Auf den Hund gekommen
   </title>
   <author>
      Charles M. Schulz
   </author>
   <mkt:cover xsi:schemaLocation="http://dyomedea.com/ns/library/mkt marketing.xsd">
      Paperback
   </mkt:cover>
   <mkt:pages>
      128
   </mkt:pages>
</book>

Der Schema-Prozessor hat nun alle Hinweise, die er benötigt, um die Schemas für beide Namensräume zu holen. Er sollte nun die zum Marketing-Namensraum gehörenden Elemente vollständig validieren. Wahlweise können wir auch alle Hinweise zu Schema-Orten im selben xsi:schemaLocation-Attribut unterbringen:

<?xml version="1.0"?>
<book id="b3810518883" xsi:schemaLocation="http://dyomedea.com/ns/library library.xsd http://dyomedea.com/ns/library/mkt marketing.xsd" xmlns="http://dyomedea.com/ns/library" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:mkt="http://dyomedea.com/ns/library/mkt">
   <title>
      Auf den Hund gekommen
   </title>
   <author>
      Charles M. Schulz
   </author>
   <mkt:cover>
      Paperback
   </mkt:cover>
   <mkt:pages>
      128
   </mkt:pages>
</book>

In diesen Beispielen haben wir relative URIs verwendet, um die Schemas aufzufinden. Dies ist nur dann eine gute Lösung, wenn Sie annehmen, daß die Schemas zusammen mit den Instanzdokumenten verschoben werden. In vielen Fällen wären absolute URIs zu bevorzugen. Wenn dies der Fall ist, können sie durch einen Mechanismus wie XML Catalogs wieder zurück auf lokale Ressourcen abgebildet werden. XML Catalogs ist eine OASIS-Spezifikation, die von einer wachsenden Zahl von Tools implementiert wird.

   

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