Neuer Lernstoff

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

Auch wenn dieses Schema dasselbe Dokument wie das Schema aus Das erste Schema beschreibt, verdeutlicht es doch ganz unterschiedliche Aspekte von W3C XML Schema .

Tiefe gegen Modularität?

Selbst wenn wir auf den nächsten Seiten mit den Konstruktionen xs:complexType und xs:group Möglichkeiten zeigen werden, diesen Effekt aufzuwiegen, haben wir doch die Modularität unseres ersten Schemas geopfert, um die Tiefe und Struktur des zweiten zu erhalten. Dies ist eine allgemeine Neigung bei W3C XML Schema .

In der Praxis werden Sie wahrscheinlich versuchen, einen Mittelweg zwischen diesen beiden Stilrichtungen einzuhalten und einen bestimmten Grad an Tiefe unterhalb mehrerer globaler Elemente zuzulassen.

Es gibt jedoch zwei Fälle, bei denen diese beiden Stilarten nicht gleichermaßen geeignet sind. Der erste liegt dann vor, wenn Elemente gleichen Namens mit unterschiedlichem Inhalt an verschiedenen Stellen definiert werden müssen. In diesem Fall sollten lokale Elementdefinitionen (zumindest an allen Stellen bis auf eine) verwendet werden, da Elemente über ihren Namen identifiziert werden.

In unserem Beispiel erscheint das Element name innerhalb von author und character jeweils mit dem gleichen Datentyp. Wir wollen möglicherweise das Element name innerhalb von author und character mit unterschiedlichem Inhaltsmodell definieren, wie es im folgenden Instanzdokument gezeigt wird:

<?xml version="1.0"?>
<library>
   <book id="b3810518883" available="true">
      <isbn>
         3810518883
      </isbn>
      <title lang="de">
         Auf den Hund gekommen
      </title>
      <author id="CMS">
         <name>
            <first>
               Charles
            </first>
            <middle>
               M.
            </middle>
            <last>
               Schulz
            </last>
         </name>
         <born>
            1922-11-26
         </born>
         <dead>
            2000-02-12
         </dead>
      </author>
      <character id="Snoopy">
         <name>
            Snoopy
         </name>
         <born>
            1950-10-04
         </born>
         <qualification>
            extrovertierter Beagle
         </qualification>
      </character>
   </book>
</library>

Da wir nur ein einziges globales Element namens name definieren können, müssen wir zumindest eines der hier unter diesem Namen auftretenden Elemente lokal unterhalb seines Elternelements definieren.

Das W3C Schema für XML Schema zeigt mehrere Beispiele für Elemente, die je nach dem Ort ihres Auftretens unterschiedliche Typen haben. Wir werden dies im nächsten Abschnitt in unserem Puppe-in-der-Puppe-Schema angewendet finden: Globale Definitionen von Elementen haben einen anderen Typ im Schema für Schema als lokale Definitionen oder Verweise, selbst wenn sie denselben Elementnamen (xs:element) verwenden.

Man kann darüber streiten, ob es gute Praxis ist, Elemente mit demselben Namen, aber unterschiedlichem Inhalt zu definieren. Es kann für den menschlichen Autor verwirrend sein, es mag schlecht dokumentierbar sein; W3C Schema bietet mit den lokalen Definitionen jedoch eine Möglichkeit, für die Anwendungen, die diese Dokumente verarbeiten sollen, jede Verwirrung zu vermeiden. So haben wir in unserem Beispiel zwei Vorkommen eines Elements namens name unterhalb von author bzw. unterhalb von character . Es ist ohne weiteres möglich, unterschiedliche Einschränkungen und sogar unterschiedliche Inhalte für diese beiden Elemente zu definieren. Auch wenn man dies als überladene Elementnamen (»character/name« bzw. »author/name«) darstellen könnte, finde ich dieses Vorgehen unzuverlässig, da wir oft keine klare, einfache Methode haben, den jeweiligen Kontext zu bestimmen.

Der andere Fall liegt bei einem rekursiven Schema vor, bei dem ein Element in einem Element gleichen Typs unmittelbar oder auch mittelbar (in einem Kindelement) enthalten sein kann. In diesem Fall muß ein flacher Entwurf mit Verweisen verwendet werden, da die Tiefe dieser rekursiven Strukturen unbeschränkt ist.

W3C XML Schema bietet mehrere Beispiele solcher Elemente mit lokalen Elementdefinitionen, die rekursiv geschachtelt werden können, wie es in unserem zweiten Schema der Fall ist. Hier muß ein flacher Entwurf verwendet werden, da diese Elemente referenziert werden müssen, wenn wir die maximale Tiefe der Struktur nicht beschränken wollen, und das Schema für Schema benutzt einen Verweismechanismus. (Der in diesem Fall verwendete Mechanismus besteht in einer Elementgruppe, einem Baustein, den wir noch nicht zu sehen bekommen haben. Er ist äquivalent mit einer tatsächlichen Referenz auf ein Element.)

Die Puppe in der Puppe und der objekt-orientierte Entwurf

Der Stil, Elemente und Attribute lokal zu definieren, wird oft als Puppe-in-der-Puppe-Entwurf (Russian Doll Design) bezeichnet, denn die Definition jedes Elements ist in die Definition seines Elternelements eingebettet, genau wie bei den russischen Puppen eine in der anderen steckt.

Wenn wir uns die Puppe in der Puppe mit unserer objektorientierten Brille ansehen, können wir sagen, daß die Objekte nun lokal dort, wo sie gebraucht werden, erzeugt werden, statt global erzeugt und dann bei Bedarf lokal geklont zu werden (wie es in unserem ersten Schema der Fall war).

An dieser Stelle müssen wir noch lernen, wie wir Typen erzeugen können, die das Gegenstück zu Klassen von Objekten und Containern sind. Damit werden wir dann Objektmengen bearbeiten können.

Wo sind die Elementtypen geblieben?

Diejenigen Leser, die mit XML (oder SGML) und der DTD vertraut sind, sind daran gewöhnt, die Elemente durch den Ausdruck »Elementtyp« zu identifizieren. Die Empfehlung zu XML 1.0 besagt, »daß jedes Element einen Typ hat, der durch den Namen identifiziert wird«. Dies wird in der Namensraum-Spezifikation durch die folgende Erläuterung weiter geklärt: »Ein XML-Namensraum ist eine Sammlung von Namen, die durch eine URI-Referenz [RFC2396] identifiziert wird und die in XML-Dokumenten für Elementtypen und Attributnamen verwendet wird.”

Eine verblüffende Eigenschaft unseres Puppe-in-der-Puppe-Schemas besteht darin, daß dieser fundamentale Begriff des Elementtyps vollständig verschwunden ist und daß es keine Möglichkeit gibt festzustellen, was für einen Elementtyp name hat. Zwei verschiedene Elemente sind definiert worden, deren Name in beiden Fällen name lautet. Sie haben unabhängige Definitionen, die in unserem Beispiel zwar identisch sind, aber ebensogut unterschiedlich sein könnten – wenn wir beispielsweise den Vornamen und den Nachnamen für Autoren getrennt angeben würden, für Buchfiguren jedoch nicht. Der Begriff des Elementtyps name besagt gar nichts, solange wir nicht den Kontext angeben, in dem er verwendet wird.

Dieser Verlust hat so geringe Bedeutung, daß nur Wenige ihn überhaupt bemerkt haben. Es gibt jedoch einige Situationen, in denen wir Elemente identifizieren müssen – beispielsweise bei der Dokumentation von XML-Vokabularen. Ein praktisches Vorgehen beim Schreiben eines Referenzhandbuchs für ein XML-Vokabular besteht darin, eine Aufstellung aller Elemente mitsamt ihrer Definition zu machen. Das wird deutlich komplizierter, wenn es keine klare Zuordnung von Elementtypen und ihren Definitionen bzw. Inhaltsmodellen gibt.

RDF ist eine weitere Anwendung, die auf Elementtypen beruht. RDF verwendet Elementtypen, um in seinen Tripeln Elemente als Objekte zu verwenden. Das Element »name« des Namensraums "http://dyomedea.com/ns" ist durch "http://dyomedea.com/ns#name" identifiziert. Wenn man die Verbindung zwischen Elementtypen und ihren Schema-Definitionen durchtrennt, wird es schwierig oder gar unmöglich, grundlegende Fragen zu beantworten, etwa die nach dem Inhaltsmodell von "http://dyomedea.com/ns#name" oder danach, wo dieses Element definiert ist.

Ich stand vor diesem Problem, als ich den Referenzteil dieses Buchs schrieb, denn das W3C XML Schema für W3C XML Schema verwendet viele lokale Elementdefinitionen. Ich kam zu dem Schluß, daß die Tatsache, daß derselbe Elementtyp (beispielsweise der Typ xs:restriction, den wir später kennenlernen werden) unterschiedliche Inhaltsmodelle mit unterschiedlicher Semantik haben kann, das Verstehen der Sprache und das Lesen eines Schemas erheblich erschwert.

   

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