Von
Matthias Hertel, AP Automation + Productivity AG Karlsruhe
und
Prof. Alfred Schätter, Fachhochschule Pforzheim
Wer XML Dateien zum Austausch von Daten verwenden will oder seine XML-Daten mittels XSLT in andere Formate transformieren will benötigt eine formale Beschreibung der Struktur der XML Daten mit einem XML Schema nach dem XSD Standard um syntaktisch gültige XML Daten prüfen zu können und um die üblichen XSLT Editoren sinnvoll verwenden zu können.
XSD Dateien zu erstellen ist im Prinzip nicht schwer denn es sind selbst XML Dateien und viele XML Editoren bieten inzwischen an zu einer XML (Beispiel-) Datei ad-hoc mal schnell ein Schema zu generieren. Das reicht auch aus um sich mit der Schema-Definitionssprache anzufreunden, aber professionelle Qualität ist damit nicht zu erreichen.
Dieser Artikel zeigt einige der üblichen Vorgehensweisen und Probleme bei der Erstellung eines vernünftigen Schemas auf.
Wer XML Daten in seinem eigenen Programm benötigt um z.B. Parameter oder Anwendungsdaten zu speichern sollte sich es gut überlegen, ob tatsächlich ein Schema benötigt wird denn vereinfachen lassen sich damit diese Themen nicht. Im Gegenteil: Man muss ein so genanntes „namespace“ definieren und dieses entsprechend beim Suchen oder Transformieren in diesen Daten mit angeben und dies bedeutet dass man den Namespace Manager verwenden muss und zusätzliche Code-Zeilen zu implementieren hat.
Den Nutzen, den ein XML Schema bringt liegt in anderen Bereichen:
· Die Editoren für XML Daten sind in der Lage beim Eingeben von Daten Vorschläge wie z.B. Intellisense Pop-Ups anzubieten, so dass eine schnelle und effiziente Bearbeitung möglich wird.
· XML Daten können zumindest auf grundlegende Regeln hin überprüft werden. Das umfasst die Schreibweise der Elemente und Attribute aber auch Verschachtelung der Elemente in der vorgesehenen Struktur.
· Wer XML Daten mit der XSLT Technologie umwandeln will und dazu einen speziellen Editor oder in „Mapping“ Werkzeug verwendet bekommt eine besondere Unterstützung angeboten, indem die Transformationsregeln ebenfalls mit Eingabehilfen erstellt werden können und viele typische Fehler damit vermieden werden können.
· Die XML Unterstützung von Applikationen wie z.B. Microsoft Word, Excel oder InfoPath und E-Commerce Spezialisten wie z.B. Biztalk basieren auf der Verfügbarkeit eines XML Schemas.
· Weitere Standards wie z.B. SOAP oder WSDL verwenden die XML Schema Definitionen um beispielsweise die übertragbaren Datentypen selbst nicht erneut spezifizieren zu müssen.
Insbesondere die Garantie, dass XML Daten den im XML Schema spezifizierten Struktur entsprechen ist gerade beim Austausch von Daten über Programmgrenzen hinweg der große Nutzen im E-Commerce Bereich. Alle am Datenaustausch beteiligten Seiten sind in der Lage dies zu prüfen und wer Daten übergibt, die nicht einmal dieser Prüfung standhalten disqualifiziert sich in hohem Maße.
Die Ausführungen in diesem Artikel beziehen sich auf datenorientierte XML – Dokumente, wie sie z.B. beim Datenaustausch zwischen Geschäftspartnern oder bei der Integration von IT – Anwendungen in Unternehmen benötigt werden und nicht auf dokumentenorientierte XML Daten wie z.B. WordML. Viele Organisationen und Institutionen (z.B. UN/CEFACT, OASIS, CommerceNet, OAGIS) beschäftigen sich derzeit mit dem Aufbau von XML - Standards für den Datenaustausch. Dabei werden Business Objects definiert, auf die sich die beteiligten Partner geeinigt haben, und die mittels XML Schemata beschrieben werden. Beispiele für derartige Austauschschemata sind BMEcat, OpenTrans, XML/EDI, GAEB oder CML.
Die einfachste, aber in den meisten Fällen auch die schlechteste Art ein Schema zu XML Daten zu erstellen besteht darin eine Beispieldatei mit den XML Daten zu schreiben und dann einen XML Editor wie z.B. XMLSpy von Altova oder auch dem XML Editor im Visual Studio .NET zu verwenden um ein passendes Schema zu erzeugen. Im Prinzip haben diese Werkzeuge keine wirkliche Ahnung von den Daten und so erzeugen sie (wenn überhaupt) eine mehr oder weniger unbrauchbare Definition die leider aber auch ohne weitere Korrektur veröffentlicht werden. Immerhin kann man Sie gut als erste Ausgangsbasis verwenden.
Gerade in der Komplexität und den vielfältigen Möglichkeiten von XML Schema liegt jedoch auch ein Problem. Auch Lehrbücher vermitteln (bis auf wenige Ausnahmen, z.B. [Klettke03], [Kazakos02], [Schöning03]) oftmals zunächst die Schemasyntax als Voraussetzung, um überhaupt gültige XML Schemata erstellen zu können, XML als Datenmodell wird nur am Rande betrachtet. Sicherlich liegt dies auch daran, dass damals SGML und dann XML als Metasprache für Auszeichnungssprachen und nicht als Datenmodell konzipiert wurden. Die Entwicklung von XML zeigt jedoch, dass gerade in diesem Bereich auch ein großes Potential steckt.
Ein einheitliches Modellierungsverfahren für XML Schema existiert nicht, XML Schema bietet eine Reihe von Modellierungskonzepten an, die optional sind und einander ersetzen können. Obwohl es noch keine formal etablierte XML Entwurfsmethode gibt, sind die bestehenden Konzepte der Datenmodellierung (z.B. ER Modelle oder UML Modelle) beim Aufbau datenorientierter XML Dokumente hilfreich. In den folgenden Ausführungen wird ein Überblick über die grundsätzlichen Entwurfsprobleme und -entscheidungen bei der Erstellung eines XML Schemas gegeben. Es wird dabei davon ausgegangen, dass Grundlagen und Syntax von XML Schema bekannt sind.
Wer Datenbankdesign macht kann sich gut an einigen Designregeln wie z.B. den weithin bekannten Normalformen oder auch den Überlegungen zur Redundanz von Daten halten um zu einem vernünftigen Ergebnis zu kommen. Einige dieser Regeln und Vorgehensweisen lassen sich auch auf das Erstellen eines XML Schema übertragen. Ein XML Schema sollte ebenfalls so konzipiert sein, dass eine Langlebigkeit erreicht wird, denn eine Änderung am Schema führt leicht dazu, dass die zugehörigen XML Daten einschließlich der Programme die diese zu verarbeiten haben angepasst werden müssen. Da diese aber im Gegensatz zum Datenbank-Design oft zwischen Organisationen und Programmen verschiedener Hersteller vereinbart werden ist hier besondere Vorsicht geboten.
Diese Grundregeln klingen geradezu banal (deshalb auch kleines 1x1), scheinen jedoch noch nicht jedes Gremium oder jede Organisation, die sich mit der XML Schemaerstellung auseinandersetzt, erreicht zu haben.
Nutzdaten gehören in die Werte von Elementen und Attributen. Ein schlechtes Beispiel hilft am Besten dies zu verdeutlichen:
<Fuhrpark xmlns="http://tempuri.org/Sample11.xsd"> <BMW>... </BMW> <BMW>... </BMW> <Mercedes> ... </Mercedes> <Mercedes> ... </Mercedes> <Rover> ... </Rover> <Rover> ... </Rover> </Fuhrpark>
Ein passendes Schema (gekürzt) zu diesen Daten könnte so aussehen:
<xs:schema ... >
<xs:element name="Fuhrpark" ... >
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element name="BMW" nillable="true">
...
</xs:element>
<xs:element name="Mercedes" nillable="true">
...
</xs:element>
<xs:element name="Rover" nillable="true">
...
</xs:element>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>
In diesem Beispiel wird sehr deutlich, dass die Anschaffung eines neuen Autos im Fuhrpark z.B. der Marke Audi den Designer der XML Datenstruktur in Verlegenheit bringen wird. Die Verlegung Automarke z.B. in den Wert eines Attributes oder Elementes ist der richtige Schritt diese Art der Kurzlebigkeit zu verhindern. Der Name des Elementes sollte trotzdem nicht gerade „Auto“ genannt werden, denn die Anschaffung eines „LKW“ würde dann genau die gleiche Problematik hervorbringen.
Die in diesem Beispiel sehr deutliche Problematik findet man in vielen XML Datenstrukturen wieder und als Designer dieser Strukturen muss man letztendlich auch eine Entscheidung treffen, ob z.B. der Tagname „Fahrzeug“ (und damit die suggerierte Semantik der Daten) für den Anwendungsfall korrekt zutreffen.
Wenn in einem XML Design auf Elemente aus schon existierenden Standards zurückgegriffen wird muss auch dieser Standard verwendet werden. Auch hier hilft ein Beispiel aus der Praxis dies nachzuvollziehen. In dem Austauschstandard GAEB, der in der Elektro- und Baubranche eine größere Verbreitung und Bedeutung hat und zu dem auch eine auf XML basierte Version existiert, werden Formatierungen in den beschreibenden Texten der einzelnen Positionen ermöglicht.
Hier findet man z.B. Elemente mit den Namen <p> oder <span> oder <div>.
Wer allerdings jetzt vermutet einfach wohlgeformtes (X)HTML aus einem Dokument in die auf diesem Schema basierten Daten übernehmen zu können stößt auf das Problem, dass ein GAEB-<p> Element und ein HTML-<p> nicht identisch sind, da sie nicht zum gleichen namespace gehören. Aus diesem Grund lassen sich komplette Beschreibungstexte nicht komplett mit einem XSLT Befehl übernehmen sondern man ist gezwungen den Beschreibungstext als einzelne Elemente zu übernehmen oder unter Umgehung von Namespaces und Schemaunterstützung „zu tricksen“. Ersteres ist theoretisch möglich, aber sehr aufwendig.
Die Intention dieser Definition ist bei GAEB recht klar, denn man will erreichen, dass nur einige der bekannten Formatierungsmöglichkeiten in den Texten verwendet werden können. Neben der formalen Beschreibung durch ein restriktives Schema lässt sich dieses aber auch als semantische Bedingung außerhalb der Schema-Definition beschreiben. Die Unterstützung weiterer HTML Formatierungen in einer kommenden Version wäre dann auch kein Problem das sich auf das Schema und seine Langlebigkeit auswirkt.
Ohne Anspruch auf eine Vollständigkeit (kleines 1x1) ergeben sich beim Entwurf einige alternative Vorgehensweisen die scheinbar zum gleichen Ziel führen können und bei denen der Designer des Schemas beliebige Wahlfreiheit hat.
Die Nutzdaten können in einem XML Dokument als Elemente oder Attribute dargestellt werden. Es erscheint häufig als Geschmacksache, ob ein Attribut oder Element eingesetzt wird, manchmal spielen sogar ästhetische Aspekte (z.B. durch Attribute wird das Dokument kompakter) eine Rolle. Bei der Verwendung von XML Schema haben (im Gegensatz zu DTD) Attribute keine Eigenschaften, die nicht auch mit Elementen modelliert werden können. Der Zugriff auf Attribute durch XML Prozessoren ist zwar einfacher als auf Elemente, wobei es allerdings auch hier keine Einschränkungen für den Zugriff auf Elemente gibt.
Attribute können, im Gegensatz zu Elementen, keine Unterstrukturen besitzen, keine mehrzeiligen Texte aufnehmen und keine expliziten Nullwerte haben (wichtig, wenn Daten aus relationalen Datenbanksystemen übernommen werden). Weiterhin sind Elemente flexibler, wenn Defaultwerte definiert werden, da diese nur eingesetzt werden, wenn das Element einerseits vorhanden und andererseits leer ist.
Attribute sollten lediglich dann verwendet werden, wenn Zusatzinformationen (Metadaten), ohne die das eigentliche Dokument trotzdem vollständig bleibt, dargestellt werden sollen (z.B. bei einer Preisangabe die Währung) oder wenn Informationen eng zu einem Element gehören, bzw. das Element beschreiben.
Wie bei jedem Entwurf ist es wichtig, dass die Modellierung durchgängig ist, d.h. für ähnliche Informationen sollten nicht einmal Elemente und an anderer Stelle Attribute eingesetzt werden.
Bei der Elementdeklaration können globale und lokale Varianten verwendet werden. Grundsätzlich sind die nachfolgenden drei unterschiedlichen Ansätze möglich. Diese werden nun anhand der einfachen Beispielinstanz erläutert:
<BUCH> <TITEL>XML Workshop</TITEL> <AUTOR>Stein Magnus</AUTOR> </BUCH>
Russische Matroschka (Russian Doll)
Der Russian Doll Ansatz stellt einen Topdown Entwurf dar. Nach der globalen Deklaration des Wurzelelementes werden alle weiteren Elemente lokal deklariert. Dadurch ist eine Wiederverwendung der Elemente an anderen Stellen der Schemadefinition nicht möglich. Anderseits hat eine Änderung an einer Stelle auch keine Auswirkungen auf andere Teile des Dokuments.
Beispiel:
<xs:element name="BUCH" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="TITEL" type="xs:string"/>
<xs:element name="AUTOR" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Salamischeiben (Salami Slice)
Die Salami Slice Methode ist der entgegengesetzte Ansatz zum Russian Doll Design. Alle Elemente werden global deklariert und lokal referenziert. Somit stellt die Salami Slice Methode einen Bottonup Entwurf dar. Dadurch sind alle Elemente wiederverwendbar, übergeordnete Elemente werden aus Basiselementen zusammengesetzt.
<xs:element name="TITEL" type="xs:string"/>
<xs:element name="AUTOR" type="xs:string"/>
<xs:element name="BUCH" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element ref="TITEL"/>
<xs:element ref="AUTOR"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Venezianischer Spiegel (Venetian blind)
Der Ansatz des Venezianisches Spiegeln verbindet die jeweiligen Vorteile des Russian Doll Ansatzes und des Salami Slice Ansatzes. Es werden globale, benannte (also nicht anonyme) Typen gebildet, die lokale Elementdeklarationen enthalten. Die einzige globale Elementdeklaration ergibt sich für das Wurzelelement. Dadurch wird eine kontrollierte Wiederverwendung (der globalen Typen) erreicht. Auch Seiteneffekte beschränken sich auf Änderungen auf der Typebene. Weiterhin können Typen als abstrakt oder final (nicht mehr änderbar) definiert werden.
<xs:complexType name="BUCHTyp" >
<xs:sequence>
<xs:element name="TITEL" type="xs:string"/>
<xs:element name="AUTOR" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:element name="BUCH” type="BUCHTyp" maxOccurs="unbounded">
Der Ansatz des Venezianischen Spiegels ist der flexibelste Ansatz und sollte nach Möglichkeit verwendet werden. Die so erzeugten Schemata sind gut strukturiert, übersichtlich und leicht verständlich. Die Definition abstrakter Typen und deren Wiederverwendbarkeit sind entscheidende Vorteile. Das wird an dem folgenden, etwas komplexeren Beispiel deutlich in dem ein (stark vereinfachter) Auftragsdatensatz dargestellt wird, der eine Liefer- und eine Rechnungsadresse mit gleicher Struktur beinhaltet.
<AUFTRAG>
<AUFTRAG_NR>12345</AUFTRAG_NR>
<BETRAG>2000.00</BETRAG>
<LIEFERADRESSE>
<STRASSE>Eichenweg 45</STRASSE>
<ORT>Karlsruhe</ORT>
<PLZ>76185</PLZ>
</LIEFERADRESSE>
<RECHNUNGSADRESSE>
<STRASSE>Buchenweg 77</STRASSE>
<ORT>Pforzheim</ORT>
<PLZ>75175</PLZ>
</RECHNUNGSADRESSE>
</AUFTRAG>
Ein XML Schema zu diesen Daten entsprechend dem Ansatz der Russischen Matroschka sieht (gekürzt) so aus:
<xs:element name="AUFTRAG">
<xs:complexType>
<xs:sequence>
<xs:element name="AUFTRAG_NR" type="xs:short" />
<xs:element name="BETRAG" type="xs:string" />
<xs:element name="LIEFERADRESSE">
<xs:complexType>
<xs:sequence>
<xs:element name="STRASSE" type="xs:string" />
<xs:element name="ORT" type="xs:string" />
<xs:element name="PLZ" type="xs:int" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="RECHNUNGSADRESSE">
<xs:complexType>
<xs:sequence>
<xs:element name="STRASSE" type="xs:string" />
<xs:element name="ORT" type="xs:string" />
<xs:element name="PLZ" type="xs:int" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
In diesem Entwurf kann man erkennen, wie der Adressblock für die Liefer- und die Rechnungsadresse jeweils neu deklariert wird, obwohl die Struktur in beiden Fällen identisch ist. Das ist auch eine unnötige Vervielfachung des Textes der XML Schemas.
Die Salamischeibentaktik führt zu folgendem Schema:
<xs:element name="AUFTRAG_NR" type="xs:short" />
<xs:element name="BETRAG" type="xs:string" />
<xs:element name="ORT" type="xs:string" />
<xs:element name="PLZ" type="xs:int" />
<xs:element name="STRASSE" type="xs:string" />
<xs:element name="LIEFERADRESSE">
<xs:complexType>
<xs:sequence>
<xs:element ref="STRASSE" />
<xs:element ref="ORT" />
<xs:element ref="PLZ" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="RECHNUNGSADRESSE">
<xs:complexType>
<xs:sequence>
<xs:element ref="STRASSE" />
<xs:element ref="ORT" />
<xs:element ref="PLZ" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="AUFTRAG">
<xs:complexType>
<xs:sequence>
<xs:element ref="AUFTRAG_NR" />
<xs:element ref="BETRAG" />
<xs:element ref="LIEFERADRESSE" />
<xs:element ref="RECHNUNGSADRESSE" />
</xs:sequence>
</xs:complexType>
</xs:element>
Das Salami Slice Design wird schon bei diesem einfachen Beispiel sehr unübersichtlich und deutlich länger, da die Deklaration der Daten an mehreren, unterschiedlichen Stellen vorgenommen wird.
Beim Ansatz des Venezianischen Spiegels wird ein neutraler, komplexer Typ (ADRESSETyp) deklariert, der bei der jeweiligen Adresse (Liefer- oder Rechnung) wieder verwendet wird. Das nachfolgend dargestellte Schema ist kurz, leicht verständlich und entspricht den programmiertechnischen Ansätzen für die Datendeklaration:
<xs:schema>
<xs:complexType name="ADRESSEType">
<xs:sequence>
<xs:element name="STRASSE" type="xs:string" />
<xs:element name="ORT" type="xs:string" />
<xs:element name="PLZ" type="xs:string" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="AUFTRAGType">
<xs:sequence>
<xs:element name="AUFTRAG_NR" type="xs:short" />
<xs:element name="BETRAG" type="xs:float" />
<xs:element name="LIEFERADRESSE" type="ADRESSEType" />
<xs:element name="RECHNUNGSADRESSE" type="ADRESSEType" />
</xs:sequence>
</xs:complexType>
<xs:element name="AUFTRAG" type="AUFTRAGType" />
</xs:schema>
In einem XML Schema müssen komplexe Datenstrukturen grundsätzlich mit „complexType“ dargestellt werden. Dabei stehen drei Konstrukte (compositors) zur Verfügung, mit denen ein komplexer Typ aus (Basis-)Elementen zusammengesetzt werden kann:
· sequence: Die Reihenfolge der Elemente wird eindeutig festgelegt.
· choice: Ein Element wird aus einer Liste von Elementen ausgewählt.
· all: Eine beliebige Kombination und Reihenfolge der Elemente ist möglich.
Einige der heute existierenden XML Parser und Editoren nehmen es mit diesen Unterschieden zwischen den Elementen nicht ganz so genau wie es sein sollte. Die Verwendung der sequence Konstrukte gibt zwar die Reihenfolge der Elemente fest vor, aber beim Prüfen von Daten gegen ein so aufgebautes Schema werden Verdreher oder die gemischte Verwendung der Elemente toleriert. Verlassen kann man sich freilich auf diesen Zustand nicht.
Variiert der Inhalt von Elementen in einem komplexen Typ gibt es zwei sinnvolle Alternativen, wie dies in einem XML Schema abgebildet werden kann. Anhand des folgenden Beispiels eines Literaturverzeichnisses, das Bücher und Zeitschriftenartikel enthalten kann, werden die Unterschiede aufgezeigt.
<LITERATURVERZEICHNIS>
<BUCH>
<TITEL>XML Schema Design</TITEL>
<AUTOR>Maier Hans</AUTOR>
<ISBN>3-565-987-45-1</ISBN>
</BUCH>
<ARTIKEL>
<TITEL>Venezianischer Spiegel</TITEL>
<AUTOR>Ziegler Maria</AUTOR>
<ZEITSCHRIFT>DB Design</ZEITSCHRIFT>
</ARTIKEL>
</LITERATURVERZEICHNIS>
Verwendung von „choice“
Mit dem „choice“ – Konstrukt können unterschiedliche Varianten dargestellt werden können. Dabei wird für jede Variante ein eigener Typ definiert. Die Unterscheidung in verschiedene Varianten erfolgt durch „choice“ bei der (globalen) Elementdeklaration.
<xs:complexType name="BUCHType">
<xs:sequence>
<xs:element name="TITEL" type="xs:string" />
<xs:element name="AUTOR" type="xs:string" />
<xs:element name="ISBN" type="xs:string" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="ARTIKELType">
<xs:sequence>
<xs:element name="TITEL" type="xs:string" />
<xs:element name="AUTOR" type="xs:string" />
<xs:element name="ZEITSCHRIFT" type="xs:string" />
</xs:sequence>
</xs:complexType>
<xs:element name="LITERATURVERZEICHNIS">
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element name="BUCH" type="BUCHType" />
<xs:element name="ARTIKEL" type="ARTIKELType" />
</xs:choice>
</xs:complexType>
</xs:element>
Bei der Verwendung von “choice” kann das Strukturierungsprinzip des Venezianischen Spiegels eingehalten werden, und es werden keine gemeinsamen Obertypen benötigt, d.h. die Varianten sind unabhängig voneinander. Dadurch kann die Erweiterung um weitere Varianten einfach (und unabhängig von den anderen Varianten) erfolgen. Andererseits können gemeinsame Elemente der Varianten nicht zusammengefasst werden (Redundanz im Schema). Dadurch sind Abhängigkeiten der Varianten nur schwer erkennbar.
Einsatzgebiet: stark unterschiedliche Varianten.
Abstrakte Typen und Typsubstitution (objektorientierter Ansatz)
Es wird ein abstrakter globaler Typ definiert, der die gemeinsamen Elemente der Varianten enthält. Die eigentlichen Varianten
werden als Erweiterungen dieses Obertyps definiert. Die Unterscheidung der Varianten in der XML Instanz erfolgt über das Attribut
(xsi:type). Das Attribut xsi:type ist als Teil des XML Schema Namensraumes für Instanzen (http://www.w3.org/2001/XMLSchema-instance) definiert, muss also im Instanzdokument
mit einem Präfix (wie z.B. xsi:) erscheinen, das
mit diesem Namensraum assoziiert ist.
In unserem Beispiel führt dies zu folgendem Schema:
<xs:complexType name="PUBLIKATIONType" abstract="true">
<xs:sequence>
<xs:element name="TITEL" type="xs:string" />
<xs:element name="AUTOR" type="xs:string" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="BUCHType">
<xs:complexContent>
<xs:extension base="PUBLIKATIONType">
<xs:sequence>
<xs:element name="ISBN" type="xs:string" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ARTIKELType">
<xs:complexContent>
<xs:extension base="PUBLIKATIONType">
<xs:sequence>
<xs:element name="ZEITSCHRIFT" type="xs:string" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="LITERATURVERZEICHNIS">
<xs:complexType>
<xs:sequence>
<xs:element name="PUBLIKATION" type="PUBLIKATIONType" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
Diese Variante führt allerdings auch zu der folgenden, gegenüber dem Ausgangsbeispiel, geänderten XML Instanz.
<LITERATURVERZEICHNIS xmlns:xsi="“http://www.w3.org/2001/XMLSchema-instance“">
<PUBLIKATION xsi:type="BUCHType">
<TITEL>XML Schema Design</TITEL>
<AUTOR>Maier Hans</AUTOR>
<ISBN>3-565-987-45-1</ISBN>
</PUBLIKATION>
<PUBLIKATION xsi:type="ARTIKELType">
<TITEL>Venezianischer Spiegel</TITEL>
<AUTOR>Ziegler Maria</AUTOR>
<ZEITSCHRIFT>DB Design</ZEITSCHRIFT>
</PUBLIKATION>
</LITERATURVERZEICHNIS>
Auch bei dieser Variante bleibt das Strukturprinzip des Venezianischen Spiegels erhalten. Die Erweiterung um eine neue Variante hat keine Auswirkungen auf die bisherigen Varianten. Allerdings sind alle Varianten vom gemeinsamen Obertyp abhängig, voneinander unabhängige Varianten können nicht dargestellt werden.
Einsatzgebiet: Varianten mit vielen Gemeinsamkeiten
Das Schema Konzept ist eine Schüsseltechnologie beim XML-Einsatz, der heute teilweise eine noch zu geringe Bedeutung entgegengebracht wird. Auch das Wissen über die Modellierung mit XML Schema scheint vielfach noch nicht ausreichend vorhanden zu sein, wie Erfahrungen in einschlägigen Projekten zeigen. In dem vorliegenden Artikel wurden anhand von einfachen, grundlegenden Beispielen, ohne Anspruch auf Vollständigkeit, einige Modellierungsalternativen aufgezeigt, insbesondere soll jedoch das Bewusstsein geschärft werden, dass gute XML Schemata nicht vom Himmel, bzw. aus einem XML Editor fallen, sondern das Ergebnis eines Konzeptionsprozesses sind.
Wie wir aus der Schule wissen, kommt nach dem kleinen Einmaleins das große Einmaleins. Übertragen auf die Erstellung von XML Schemata sind dies eine Fülle weiterer Modellierungsalternativen, die bedacht und sinnvoll eingesetzt werden müssen. Beispiele hierfür sind:
· Die Definition verschiedener Namensräume
· Schemamodularisierung mit homogenen oder heterogenen Namensräumen
· Abbildung von Objektbeziehungen
· Auflösung von Rekursionen
Einen guten Überblick über die Modellierungsmöglichkeiten geben die „Best Practice“ – Seiten im Internet [Best_URL], in denen die Ergebnisse der Diskussionen von XML Entwicklern über Fragen des Schemaentwurfs festgehalten sind. Voraussetzung, um sich mit dem „großen Schemaeinmaleins“ auseinanderzusetzen, ist jedoch die sichere Beherrschung der Grundlagen.
Es bleibt zu hoffen, dass Gremien und Organisationen, die sich XML-Technologien beschäftigen, ihre Hausaufgaben machen und sich mit den Modellierungskonzepten auseinandersetzen. Insbesondere bei der Definition von Standards für den Datenaustausch werden qualitativ hochwertige Schemata benötigt, da diese ein Pfeiler des eBusiness sind, ohne den auch die schnellste Übertragung auf der Internet - Datenautobahn nicht erfolgreich sein wird.
Matthias Hertel ist Leiter der Software Entwicklung bei der Firma AP Automation + Productivity AG in Karlsruhe, Deutschland und ist Verantwortlich für die Architektur und Realisierung des auf Internet- und XML-Technologien basierenden ERP Systems P2plus.
Prof. Alfred Schätter ist Professor and der Fachhochschule in Pforzheim, Deutschland am Lehrstuhl FB3 Wirtschaftsingenieurwesen und Mitglied des Senats der Fachhochschule mit den Arbeitsschwerpunkten Systemanalyse, Software Engineering, Programmierung, Internet Applikationen (XML), Datenmodellierung, Datenbanksysteme, PPS-Systeme, Qualitätsmanagement
Literatur
[Best_URL] XML Schemas: Best Practice, http://www.xfront.com/BestPracticesHomepage.html
[Kazakos02] Kazakos, Schmidt, Tomczyk, Datenbanken und XML, Berlin 2002
[Klettke03] Klettke, Meyer, XML und Datenbanken, Konzepte und Systeme, Heidelberg, 2003
[Schöning03] Schöning Harald, XML und Datenbanken, Konzepte und Systeme, München, 2003