XML-Schema 9783939701545, 3939701548

Citation preview

---

www.comelio-medien.com

XML Schema

Marco Skulschus Marcus Wiederstein Sarah Winterstone

XML Schema Marco Skulschus Marcus Wiederstein Sarah Winterstone

XML Schema Marco Skulschus Marcus Wiederstein Sarah Winterstone

© Comelio Medien 2011

Alle Rechte vorbehalten. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jeder Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zusimmung des Verlages unzulässig und strabar. Das gilt insbesondere für die Vervielfäligung, Übersetzung, Mikroverilmung und die Einspeicherung und Verbreitung in elektronischen Systemen.

© Comelio GmbH Comelio GmbH Goethestr. 34 D-13086 Berlin Fon: +49 (0) 30-8 14 56 22-00 Fax: +49 (0) 30-8 14 56 22-10 www.comelio-medien.com [email protected] Umschlaggestaltung, Comelio-Graiken, Layout & Satz: Nadine Kilian Druck und Bindung: docupoint magdeburg, Oto-von-Guericke-Allee 14 39179 Barleben Printed in Germany

ISBN 978-3-939701-54-5

Inhaltsverzeichnis

Inhaltsverzeichnis

1. Elemente und Atribute 1. 1.  Entwicklung von XML-Datenmodellen 1. 1. 1.  Phasen in einem Entwicklungsprojekt 1. 1. 2.  Prüfungsschema von XML-Dokumenten 1. 1. 3.  Ansätze der Dokumentmodellierung 1. 1. 4.  Eine Beispielanwendung 1. 2.  Elemente und einfache Inhaltsmodelle deinieren 1. 2. 1.  XML Schema-Deklaraion 1. 2. 2.  Einfache und komplexe Elemente deklarieren 1. 2. 3.  Verschachtelte Strukturen erzeugen 1. 3.  Atribute deklarieren 1. 4.  Lokale und globale Deklaraionen 1. 4. 1.  Globale Deklaraion von Elementen 1. 4. 2.  Globale Deklaraion von Atributen 1. 4. 3.  Allgemeine Überlegungen zu globalen Deklaraionen 1. 4. 4.  Atributorienierte Dokumente 2.

Datentypen und Strukturen 2. 1.  Vordeinierte Datentypen 2. 1. 1.  Primiive Datentypen 2. 1. 2.  Abgeleitete Datentypen 2. 1. 3.  Listentypen und Schlüssel 2. 2.  Deklaraion einfacher Typen 2. 2. 1.  Fasseten 2. 2. 2.  Eigene Datentypen 2. 2. 3.  Datentypdeiniion durch Ableitung 2. 3.  Reguläre Ausdrücke in XML Schema 2. 3. 1.  Einfache Muster 2. 3. 2.  Zusammengesetzte Muster

20 20 21 23 26 31 39 43 43 45 46 48 49 50 53 65 71 71 71 76 81 88 89 102 107 118 118 119

5

Inhaltsverzeichnis

2. 3. 3.  Kurzschreibweisen 2. 3. 4.  Mengenverarbeitung

122 126

3.

Komplexe Typen und Inhaltsmodelle 3. 1.  Deklaraion von komplexen Typen 3. 1. 1.  Lokale komplexe Typen 3. 1. 2.  Einfaches Inhaltsmodell 3. 1. 3.  Globale komplexe Typen 3. 2.  Inhaltsmodelle 3. 2. 1.  Einfache Inhalte 3. 2. 2.  Komplexe Inhalte 3. 2. 3.  Gruppenbildung 3. 3.  Spezielle Inhaltsmodelle 3. 3. 1.  Gemischte Inhaltsmodelle 3. 3. 2.  Leere Inhaltsmodelle

128 128 128 134 141 155 155 163 169 179 179 185

4.

Schlüssel und Verweise 4. 1.  ID und IDREF/IDREFS 4. 1. 1.  Schlüssel- und Verweisdeiniion 4. 1. 2.  Mehrfachverweise 4. 2.  Key, Unique und Keyref 4. 2. 1.  Schlüssel über 4. 2. 2.  Eindeuigkeitsbeschränkung über 4. 2. 3.  Verweise auf Schlüssel und Eindeuigkeitsbeschränkungen

193 193 194 199 203 203 214 220

5.

Auslagerung und Wiederverwendung 5. 1.  Inklusion 5. 1. 1.  Einfache Wiederverwendung 5. 1. 2.  Wiederverwendung mit Redeiniion 5. 1. 3.  Mehrstuige Inklusion und Namensräume 5. 2.  Import von Strukturen 5. 2. 1.  Grundprinzip des Imports 5. 2. 2.  Übernahme ohne Namensraum 5. 2. 3.  Import mit eigener Namensraumangabe

226 227 228 233 241 242 244 249 251

6. Gruppierungen und Ableitungskontrolle 6. 1.  Verwendung von Gruppen 6. 1. 1.  Element- und Atributgruppen 6. 1. 2.  Ersetzungsgruppen für lexible Inhalte

6

255 255 258 262

Inhaltsverzeichnis

7.

6. 2.  Ableitungen kontrollieren 6. 2. 1.  Grundproblem und Lösung 6. 2. 2.  Vorgabemöglichkeiten 6. 2. 3.  Ableitung beeinlussen

275 275 277 282

Namensräume 7. 1.  Namensräume in XML 7. 1. 1.  Verwendung eines einzigen Namensraums 7. 1. 2.  Verwendung mehrerer Namensräume 7. 2.  Deklaraion von Namensräumen 7. 2. 1.  Verwendung eines einzigen Namensraums 7. 2. 2.  Verwendung mehrerer Namensräume 7. 3.  Namensraum-Übernahme 7. 3. 1.  Import 7. 3. 2.  Keine Übernahme: Chamäleon-Design 7. 3. 3.  Beliebige Komponenten akzepieren

287 287 288 290 293 293 300 306 307 311 314

8. Dokumentmodellierung und erweiterbare Schemata 8. 1.  Überlegungen zur Dokumentmodellierung 8. 1. 1.  Abhängigkeit von Instanzdokument und Schema-Dokument 8. 1. 2.  Typen von Syntax-Änderungen 8. 1. 3.  Bedeutung der Dokumentmodellierung 8. 2.  Benennung und Struktur von Elementen und Atributen 8. 2. 1.  Überlegungen zur Element-Benennung 8. 2. 2.  Überlegungen zur Atribut-Benennung und -Verwendung 8. 2. 3.  Überlegungen zu Hierarchien 8. 2. 4.  Design-Alternaiven und erweiterbare Schemata

320 320 321 327 331 334 334 339 353 357

9. Dokumentaion 9. 1.  Möglichkeiten der Dokumentaion 9. 1. 1.  Einfache XML-Kommentare 9. 1. 2.  XML Schema-Kommentar-Elemente 9. 1. 3.  Einsatz von Fremd-Atributen 9. 2.  Auslesen von Kommentaren 9. 2. 1.  Auslesen von XML-Kommentaren 9. 2. 2.  Auslesen von XML Schema-Kommentaren in Textdatei 9. 2. 3.  Auslesen von XML Schema-Kommentaren in HTML 9. 2. 4.  Auslesen von XHTML nach HTML 9. 2. 5.  Auslesen von Fremd-Atributen

361 361 361 363 368 369 370 373 375 377 379

7

Inhaltsverzeichnis

10. DB-Datenmodellierung und XSLT-Transformaion 10. 1.  Datenmodellierung 10. 1. 1.  Datenmodellierung mit Elementen und Atributen 10. 1. 2.  Transformaion in SQL 10. 2.  XML Schema und Datenbanken 10. 2. 1.  Einführung 10. 2. 2.  Oracle 10. 2. 3.  MS SQL Server

384 384 387 394 409 410 411 421

11. XML Schema und OOP 11. 1.  XML Schema und Objektorienierung 11. 1. 1.  Prinzip 11. 1. 2.  Funkionsweise 11. 1. 3.  Erweiterung auf Datenbanken 11. 2.  XML Schema-Bindung in .NET 11. 2. 1.  Prinzip der Klassengenerierung aus XML Schema 11. 2. 2.  XML Schema-Bindung 11. 2. 3.  Mapping und Serialisierung beeinlussen 11. 2. 4.  Generierte Klassen erweitern 11. 2. 5.  Von XML zu Objekten 11. 3.  XML-Schema-Bindung in Java 11. 3. 1.  Prinzip der Klassengenerierung aus XML Schema 11. 3. 2.  XML Schema-Bindung 11. 3. 3.  Mapping und Serialisierung beeinlussen 11. 3. 4.  Von XML zu Objekten

429 429 430 433 436 439 439 442 444 451 452 456 457 459 462 470

8

Vorwort

Vorwort

Vorwort Herzlich willkommen zu einem Fachbuch aus dem Comelio GmbH-Verlag. Wir sind stets bemüht, Ihnen aktuelle Informaionen rund um IT-Technologien in beispielorienierter und verständlicher Weise zu liefern, damit Sie auf diesem Wege in die Lage versetzt werden, Anforderungen mit neuen Werkzeugen umzusetzen.

Zu diesem Buch Dieses Buch handelt von der Modellierung und Beschreibung von Strukturen, die beim Datenaustausch zwischen Anwendungen und Rechnern benöigt werden. Dieser Datenaustausch kann in vielen Fällen besonders gut über XML (eXtensible Markup Language) durchgeführt werden. Mit dem vom W3C (World Wide Web Consorium, www.w3c. org)entwickelten XML Schema ist es möglich, überaus anspruchsvolle, in einzelne Komponenten zerlegbare und mit Datentypen versehene Regeldokumente zu entwerfen, die für die Entwicklung von Datenstrukturen im XML-Bereich und damit für die korrekte Verwendung – oder besser noch – für die Verwendung von korrekten XML-Dokumenten in Applikaionen einsatzfähig sind.

Moivaion Das XML Schema soll nicht nur die ehrwürdige DTD (Document Type Deiniion)1 der ersten Version von XML (XML 1.0) ersetzen, sondern hat dies bereits in vielen Bereichen getan und wird es in anderen noch tun. Sie geriet zeitgleich nicht nur durch das XML Schema in Bedrängnis, sondern auch durch die Microsot-Varianten BizTalk-Schema und XDR(XML Data Reduced)-Schema, die mit dem XML Schema mitlerweile schon gar nicht mehr konkurrieren, sondern schon untergegangen sind. Im ersten Kapitel inden sich noch einige Beispielübertragungen mit der herkömmlichen DTD, da vielleicht einige Leser früher die DTD benutzt haben und nun umsteigen wollen. Die einzige weiterhin exisierende Konkur-

1

10

Informaionen zur DTD beinden sich in der XML-Speziikaion: htp://www.w3.org/TR/xml11/

Vorwort

renztechnologie, die auch in einigen Punkten Vorteile bietet, ist RelaxNG2 von OASIS. Es ist allerdings bei Weitem nicht so weit verbreitet wie XML Schema. Im direkten Vergleich zwischen DTD, deren Syntax viele Leser vom ersten Kontakt mit XML her sicherlich kennen, und XML Schema lassen sich die Unterschiede bzw. Vorteile des XML Schemas hauptsächlich in zwei Punkten charakterisieren: ●

Das XML Schema bietet für komplexe Anwendungen und Anforderungen geeignete Konstrukionen und eine umfangreiche Syntax. Sie überbietet die Möglichkeiten der DTD um ein Vielfaches, erlaubt die Deiniion von Datentypen, die Kombinaion von mehreren Schema-Dokumenten, die Entwicklung von komplexen Datenstrukturen und gestatet einen komponentenorienierten Aubau von Schema-Dokumenten.

●

Während die DTD aufgrund historischer Entwicklungen und der gemeinsamen Muter SGML (Standard Generalized Markup Language)3 eine eigene Syntax besitzt, präseniert sich das XML Schema als XML-Syntax mit eigenem Namensraum, aus dem sich die Elementnamen bedienen. Damit ist, wie auch schon für XSLT (eXtensible Stylesheet Language)4, eine XML-Technologie entwickelt worden, die selbst wieder auf der XML-Syntax beruht. Dadurch soll das Erlernen und das Verständnis diese Technologien vereinfacht werden.

Beispieldateien Für jedes in diesem Buch erstellte XML Schema-Dokument gibt es normalerweise auch ein Instanzdokument, also ein XML-Dokument mit beispielhaten Daten und einer korrekten Verwendung der im Schema-Dokument festgelegten Regeln. Nun kann man sich vorstellen, dass die Bereitstellung von Beispieldokumenten mit abwechselnden Inhalten eine zeitaufwändige Arbeit ist, die man leicht mit verschiedenen Hilfsmiteln automaisieren kann. Alles, was man dazu benöigt, ist eine Datenbank mit mehreren hundertausend Datensätzen. Freundlicherweise stellte uns die RuhrFon GmbH ihre eigene Datenbank zur Verfügung. Sollten Sie von diesem Unternehmen noch nichts gehört haben, obwohl Sie im Ruhrgebiet wohnen, dann ist das nicht weiter von Bedeutung, denn diese Firma ist natürlich ebenso ikiv wie es ihre Telekommunikaions- und Kundendaten sind. 2 3 4

Nähere Informaionen: htp://relaxng.org/ Nähere Informaionen: htp://www.w3.org/MarkUp/SGML/ sowie zum Vergleich von XML und SGML: htp:// www.w3.org/TR/NOTE-sgml-xml-971215 Nähere Informaionen zur Technik: htp://www.w3.org/Style/XSL/, zu XSLT: htp://www.w3.org/TR/xslt, zu XSLFO: htp://www.w3.org/TR/xsl/ und zu XPath: htp://www.w3.org/TR/xpath

11

Vorwort

Wie Sie dem Datenmodell entnehmen können, gibt es Tabellen für Geschäts- und Privatkunden, für Anrufe, für die Telefontarife, Rechnungen, die Rechnungsposten und schließlich für die Mitarbeiter, die all die vielen Daten kontrollieren und dafür sorgen, dass neue Kunden im Telefonnetzwerk miteinander telefonieren. Das Geschätsmodell der Firma, die Sie in den Buchbeispielen näher kennen lernen werden, ist relaiv simpel und baut ganz auf den im Internet hinlänglich bekannten Netzwerkefekt auf, den man auch an der posiiven Geschätsentwicklung nachvollziehen kann. Ist man Teil des Netzwerks bzw. hat man ein Kundenkonto bei der RuhrFon GmbH, kann man über eine geeignete Vorwahl mit anderen Teilnehmern im Netzwerk telefonieren. Das heißt, es lohnt sich für private und geschätliche Kunden, ihre Freunde und Geschätspartner ebenfalls davon zu überzeugen, bei der RuhrFon GmbH Kunde zu werden, damit man im Freundeskreis günsig telefonieren kann.

Abbildung 0.1: Datenmodell für die Beispieldokumente

12

Vorwort

Aus den über eine Million Anrufen in zwei Jahren sowie den anderen in diesem Datenmodell vorhandenen Datenstrukturen wurden dann automaisch die XML-Beispieldokumente und dann ihre zugehörigen Regeldokumente erzeugt. Die in diesem Buch verwendeten, zahlreichen Beispiele können Sie von der Comelio Medien-Webseite herunterladen. Dort können Sie sich auch über evtl. Änderungen und Korrekturen sowie Neuaulagen dieses Buchs informieren. htp://www.comelio-medien.com/ buch-katalog/xml/xml_schema

Schreibkonvenionen Die vielen Beispiele in diesem Buch werden durch dicktengleiche Schrift ausgedrückt. Einige Stellen verdienen eine besondere Aufmerksamkeit Dies geschieht durch eine fette, dicktengleiche Schrift . Wichige Begrife, Datei- oder Ordnernamen sind in kursiver Schrit gekennzeichnet.

Weitere Informaionen Bei einem so internetainen Thema gibt es eine Menge an Webadressen, die in Zusammenhang mit XML Schema von Bedeutung sind. Folgende Auswahl gibt einen kurzen Überblick zu Webressourcen und weiteren Informaionsquellen. ●

Oizielle Dokumente inden Sie auf den Seiten des W3C: ƒ www.w3c.org/TR/xmlschema-0/ (Einführungstext mit Beispielen) ƒ www.w3c.org/TR/xmlschema-1/ (Strukturen von XML Schema) ƒ www.w3c.org/TR/xmlschema-2/ (Datentypen von XML Schema)

●

Seminare und Schulungen zu XML Schema und XML-Technologien: www.comelioseminare.com/dei3_XML.php.

●

Kurzreferenzen zu vielen XML-Themen: htp://www.comelio-medien.com/leserservice/kurz-referenzen

13

Vorwort

●

Weitere Bücher bezüglich XML-Technologien bei Comelio Medien: ƒ XML: Standards und Technologien, ISBN 978-3-939701-21-7 ƒ XSLT, XPath und XQuery, ISBN 978-3-939701-18-7 ƒ XSL-FO, ISBN 978-3-939701-17-0 ƒ Oracle, PL/SQL und XML, ISBN 978-3-939701-10-1 ƒ MS SQL Server, XML und SOAP Web Services, ISBN 978-3-939701-03-3 ƒ PHP und XML, ISBN 978-3-939701-00-2

MS SQL Server: XML und SOAPWebservices

Oracle, PL/ SQL und XML

Verwendung von XML Datenbanken (Speicherung, Verarbeitung, Webservices) Standard: XSL-FO 1 0 Themen: PDF, Druckerzeugnisse

XSL-FO

Verwendung von XML in Programmiersprachen (Erzeugung, Verarbeitung, Transformation) XSLT, XPath und XQuery

PHP und XML

Standards: XSLT 1 0/2.0, XPath 1.0/2.0 und XQuery 1.0 Themen: HTML, Text, XML sowie allgemeiner Algorithmenentwurf

XML: Standards und Technologien

XHTML und CSS

Abbildung 0.2: Struktur der Reihe

14

Standard: XML Schema 1.1 Themen: Modellierung und Beschreibung von XML-Daten

XML Schema

Vorwort

Zielgruppe und Anwenderkreis Dieses Buch richtet sich an Entwickler, Analyiker und Entscheider, die XML in Anwendungen bzw. in Organisaionen einführen und XML-basierte Datenströme beschreiben, erstellen und verarbeiten wollen. Auch wenn die Beispiele in diesem Buch immer in der Gestalt von Dokumenten erscheinen, die in einer einzelnen Datei untergebracht und als solche auch verarbeitbar sind, so muss dies nicht der Regelfall sein. Eine weitere Speichermöglichkeit bieten Datenbanken, wobei die Daten entweder objektrelaional in geeigneten Spaltenstrukturen oder, um beim ersten Einsatzgebiet zu bleiben, direkt als Texte untergebracht sind. Sie können allerdings auch als Textstücke in Datenbankspalten oder anderen Zusammenhängen gespeichert oder erst durch entsprechende Anwendungen für den Datenaustausch generiert bzw. mit gerade im Kontext erzeugten Daten gefüllt werden. In diesen unterschiedlichen Zusammenhängen und Einsatzgebieten kann es sich dabei wiederum um interne Anwendungen zum Datenaustausch, der Datenhaltung, der Wissensrepräsentaion oder der Vorstufe für unterschiedliche Ausgabeformate handeln, so wie dies auch in Anwendungen mit einer externen Ausrichtung der Fall sein kann, in der gleiche oder ähnliche bzw. veränderte Daten für die gleichen Zwecke verarbeitet werden sollen. Die Entscheidung, XML zu verwenden, ist für die Zielgruppe dieses Buchs schon gefallen (und ist es in wohl allen Fällen, in denen klassische kommagetrennte Werte oder andere Formate keine Lösung darstellen). In einem nächsten Schrit muss es nun in jedem XMLEntwicklungsprojekt darum gehen, herauszuinden, welche Datenstrukturen vorhanden sind, und wie diese zu modellieren sind. Dieses Buch vermitelt also keine Grund- oder Aubaukenntnisse über die Verarbeitung von XML-Datenströmen mit z. B. XSLT oder über den Einsatz von XML in diversen Geschätsmodellen oder Programmiersprachen, sondern beschätigt sich ausschließlich mit der Entwicklung von Regeldokumenten. Dabei steht einerseits die Syntax von XML Schema im Rampenlicht. Sie wird bisweilen abgelöst von Entwicklungstechniken der Dokumentmodellierung, die mit XML Schema syntakisch bzw. allgemein möglich sind. Dazu zählt vor allen Dingen die Entwicklung von wieder verwendbaren Komponenten.

Inhalt nach Kapiteln Die Themen der einzelnen Kapitel werden im Folgenden kurz aufgelistet: 1.

Im ersten Kapitel lernen Sie, nach einer allgemeinen Einführung zum Thema XML Schema einfache XML-Dokumente zu modellieren und konzentrieren sich dabei auf

15

Vorwort

die Deiniion von Elementen und Atributen. Nach der Modellierung von lokalen Deiniionen sehen Sie, wie sie globale Elemente und Atribute deinieren, um sie dann mehrfach innerhalb anderer Strukturen zu referenzieren. 2.

Das zweite Kapitel zeigt eine der wesentlichen Besonderheiten von XML Schema: das Datentypsystem. Sie lernen, für Werte von Atribute und Inhalte von Textknoten passende Datentypen aus der vorhandenen Typ-Bibliothek auszuwählen. Neben dieser umfassenden Datentyp-Bibliothek kann man auch spezialisiert Datentypen auf Basis der vorhandenen erstellen. Diese können entweder lokal und damit nur auf ein Element oder ein Atribut bezogen sein oder global erstellt werden, einen Namen erhalten und dann mehrfach in einem XML schema oder durch Einbindung auch in anderen XML Schema-Dokumenten verwendet werden. Das wichigste Werkzeug für die Erstellung von solchen abgeleiteten Datentypen sind die Fasseten, welche verschiedene kombinierbare Wertebereichsbeschränkungen repräsenieren.

3.

Im driten Kapitel beschätigen Sie sich mit Inhaltsmodellen, in denen Elemente in Reihenfolgen erscheinen oder die Alternaiven sowie Auswahlen darstellen. Diese Inhaltsmodelle können unterschiedlich verschachtelt werden, sodass man eine große Anzahl an Kombinaions- und Ausdrucksmöglichkeiten besitzt. Darüber hinaus kann man Strukturen in Form von so genannten globalen komplexen Typen auslagern und dann im selben oder auch in anderen XML Schema-Dokumenten wiederverwenden. Durch den Einsatz von Ableitung durch Einschränkung oder Erweiterung (Vererbung) kann man dann recht umfangreiche Modelle gestalten.

4.

Das vierte Kapitel stellt einen Aspekt in den Vordergrund, der insbesondere bei der Modellierung von Datenbankmodellen mit Hilfe von XML Schema neben der Datentypsystemaik wichig ist, nämlich die Deiniion von Schlüsseln und Schlüsselverweisen/ Fremdschlüsseln. Dies wird entweder durch spezielle Elemente und XPath-Lokalisierungspfade realisiert oder durch DTD-konforme Datentypen, mit denen DTD-ähnliche Schlüssel- und Verweisstrukturen realisiert werden können.

5.

Das fünte Kapitel stellt die drei verschiedenen Varianten dar, mit denen XML SchemaBibliotheken modular aufgebaut werden können. Man unterscheidet hierbei zwischen Import, Einfügung und Redeiniion. Bei der einfachen Einfügung gehen die ausgelagerten Elemente in den Namensraum des einfügenden Dokuments auf, während beim Import zu unterscheiden ist, ob die ausgelagerten Strukturen mit ihrem Namensraum eingefügt werden sollen oder ob diese Strukturen in den Namensraum des einfügenden Dokuments aufgehen sollen. Bei der Redeiniion kann man die eingefügten Strukturen unter gleichem Namen auch noch inhaltlich verändern.

16

Vorwort

6.

Im sechsten Kapitel lernt man die verschiedenen Konzepte kennen, die es ermöglichen, Strukturen auszulagern und sie abzuleiten. Dabei meint Ableitung die Erstellung neuer Strukturen auf Basis von vorhandenen, wobei eine Reihe von Veränderungen möglich sind. Man unterscheidet die beiden Varianten Ableitung durch Einschränkung und Ableitung durch Erweiterung. Wie die Namen schon sagen, können Elemente oder Atribute an bestehende Strukturen angehängt oder verboten werden.

7.

Das siebte Kapitel führt die verschiedenen Techniken ein, mit denen Namensräume in einem XML Schema-Dokument verwendet und auch für die Verwendung in einem Instanzdokument deiniert werden können. Hierbei beschätigen Sie sich noch einmal mit der Technik der Namensräume in XML und sehen, wie Sie die unterschiedlichen Varianten (Standardnamensraum, ein einziger oder mehrere Namensräume) über XML Schema festlegen können.

8.

Das achte Kapitel beschätigt sich mit erweiterbaren Schemata, d. h. Überlegungen, welche die Veränderung von XML Schema-Strukturen und ihre Auswirkungen auf die Instanzdokumente oder das eigentliche Datenmodell bewirken.

9.

Das neunte Kapitel zeigt schließlich verschiedene Elemente und Techniken, mit denen Dokumentaionsinformaionen in einem XML Schema-Dokument angegeben werden können. Es geht auch darauf ein, wie mit XSLT solchermaßen dokumenierten XML Schema-Dokumente in HTML-Dokumente umgewandelt werden können.

10. Das zehnte Kapitel zeigt, welche Möglichkeiten bestehen, XML Schema und Datenbanken gemeinsam zu verwenden. Hier gibt es zwei wichige Opionen: Erstens kann man Datenmodelle für relaionale Datenbanken mit XML Schema beschreiben. Wesentliche Techniken sind hier die vorhandene Typbibliothek und die Schlüssel-/Schlüsselverweise. Für die Erzeugung von SQL-Quelltext lernen Sie hier eine Lösung mit Hilfe von XSLT kennen. Zweitens kann man in XML-fähigen Datenbanken untypisiertes und typisiertes XML verwenden, wobei „typisiertes XML“ durch XML Schema validierte Daten darstellt. Für die beiden Datenbanken Oracle und MS SQL Server erhalten Sie eine Einführung über die Verwendung von XML Schema. 11. Im elten Kapitel wechseln Sie die Perspekive, wie Sie XML Schema betrachten. Es ist nämlich nicht nur möglich, XML Schema für die Modellierung von XML-Daten oder die Beschreibung von relaionalen Datenstrukturen zu verwenden, sondern man kann auch objektorienierte Klassenstrukturen an XML Schema binden bzw. eine Zuordnung zwischen XML Schema-Deiniionen und Klassenstrukturen schafen. Für die beiden Programmiersprachen Java und .NET lernen Sie anhand von Beispielen die entspre-

17

Vorwort

chenden Bibliotheken kennen, um Klassen oder XML Schema-Dateien zu generieren sowie XML-Instanzdaten in Objekte umzuwandeln – oder wieder zurück.

Autoren Ein solches Werk schreibt man nicht alleine, sondern teilt sich die Arbeit nach Interessen und Schwerpunkten auf. Die Autoren arbeiten in verschiedenen Posiionen bei Comelio (www.comelio.com) und haben bereits gemeinsam oder alleine verschiedene Bücher zu ihren Werkzeugen veröfentlicht. ●

Marco Skulschus arbeitet als Projektleiter und Dozent bei der Comelio GmbH in Berlin und beschätigt sich mit Berichts- und Expertensystemen auf Basis von MS SQL Server und Oracle. Er interessiert sich besonders für Ontologien und Data Mining-Techniken.

●

Marcus Wiederstein arbeitet als Projektleiter bei der Comelio GmbH in Berlin für Projekte mit Microsot-Produkten wie MS BizTalk Server, MS Sharepoint Portal Server oder MS Project Server sowie den Business Intelligence-Produkten.

●

Sarah Winterstone arbeitet als Entwicklerin bei der Comelio, Inc. in Miami, FL und programmiert kaufmännische Anwendungen mit .NET und setzt dabei vielfälig XMLTechnologien ein. Ihr Spezialgebiet ist die Integraion von XML in Datenbanken bzw. die Entwicklung von Import-/Export-Schnitstellen auf XML-Basis.

Sie erreichen das Sekretariat der Autoren unter der E-Mail-Adresse [email protected]. Von dort werden Ihre Emails dann weitergeleitet. Die Webseite des Verlags inden Sie unter der Adresse htp://www.comelio-medien.com. Auch in der realen Welt ist der Verlag zu erreichen. Die Hauptzentrale beindet sich in Berlin, Deutschland. Comelio GmbH, Goethestr. 34, D-13086 Berlin

18

Elemente und Atribute

1

1. Elemente und Attribute

1. Elemente und Atribute Ein Inhaltsmodell beschreibt den Inhalt eines Elements. Dabei kann es sich entweder um einen einfach typisierten Inhalt wie Zeichenketen oder Zahlen handeln oder um komplexen Inhalt wie Kind-Elemente oder Atribute. Diese möglichen Kind-Elemente besitzen dann ihrerseits jeweils ein Inhaltsmodell, sodass sich Ebene um Ebene die Regeln des Dokuments enfalten. Es ist syntakisch leicht, in XML Schema solche Vorgaben zu trefen, aber deutlich schwieriger, Daten korrekt zu modellieren. Auch wenn wir zu diesem umfassenden Gebiet nur einen kurzen Einblick geben können, soll mit diesem Thema das Kapitel beginnen.

1. 1.  Entwicklung von XML-Datenmodellen Eine Ihnen vermutlich auch geläuige Auszeichnungssprache ist HTML. Deren Syntax wurde in einem Schema-Dokument1 festgelegt, das theoreisch in jedem Browser gespeichert und mit Ausgabeformaten versehen ist. Dabei unterscheiden sich zwar in den einzelnen Browsern die tatsächlichen Anzeigeergebnisse, und man steht auch weiterhin bei einigen Tags vor der Hürde, dass sie in unterschiedlichen Browsern auf verschieden Weise angezeigt werden, aber grundsätzlich kann man HTML-Dokumente, die den Regeln im zugehörigen HTML-Regel-Dokument sich unterwerfen, in jedem Browser bzw. in jeder Anwendung, die HTML interpreieren kann, zum Einsatz bringen. So wie HTML nicht von Ihnen modelliert ist, so sind auch viele andere Grammaiken nicht von Ihnen modelliert, sondern von anderen Unternehmen, öfentlichen Behörden und sonsigen Gruppen. Beschätigen Sie sich mit XML Schema, dann stehen Sie möglicherweise zum ersten Mal vor der Aufgabe, für XML-Daten eine Speziikaion selbst zu entwickeln.

1

20

Nähere Informaionen zum Standard: htp://www.w3.org/MarkUp/ und htp://www.w3.org/TR/html4/ sowie zur DTD von HTML: htp://www.w3.org/TR/REC-html40/sgml/dtd.html

1. Elemente und Attribute

1. 1. 1.  Phasen in einem Entwicklungsprojekt XML2 ist die Antwort auf ein Hindernis oder eine Herausforderung, auf die jeder trit, der sich in immer größeren Arbeitsumgebungen mit unterschiedlichen Konzepten der Datenhaltung und -speicherung sowie der Datenausgabe und -formaierung bewegt. Bei der Modellierung kann man die folgenden Teilbereiche und Aufgaben grob unterscheiden: ●

Ideniikaion: Die anfallenden Elemente und ihre evtl. vorhandenen Varianten (evtl. über Atribute abzubilden), also die atomaren Bestandteile der Datenströme, müssen erkannt und klar festgelegt werden. Dazu zählt in einem ersten Schrit, überhaupt zu erkennen, welche Daten in allen oder einzelnen Situaionen anfallen, oder ob es Situaionen in Anwendungen oder Verarbeitungsprozessen gibt, die unterschiedliche Teilbereiche von Datenströmen benöigen und verarbeiten.

●

Charakterisierung: Ihre Datentypen, möglichen Inhalte sowie eindeuige Namen und Kategorisierungen müssen beschrieben werden. Normalerweise sollten die Daten in einer atomisierten Form vorliegen, das heißt, in einer so kleinstrukturierten Form, dass weitere Unterteilungen nicht mehr möglich sind, sofern man nicht in Silben oder Buchstaben unterteilen würde. Dies gilt für gewöhnlich auch für den Datenbankeinsatz, da auch hier die Daten in einer atomisierten Form vorliegen sollten, um eine gute Speicherung und efekive Such- und Verarbeitungsalgorithmen zu gewährleisten.

●

Verlechtung: Zusätzlich müssen die Beziehungen, in denen die Daten zueinander stehen, und ihre Abhängigkeiten untereinander beschrieben und verstanden werden. Die Elemente der Datenströme können in Abhängigkeit vom anwendungsspeziischen Kontext oder aufgrund von datenimmanenten Gegebenheiten mit unterschiedlicher Häuigkeit (mehrfach, gar nicht, einmal) autreten.

●

Entwicklung: Nach den Analysearbeiten steht die Entwicklung der Regelstrukturen an. Dabei geht es noch nicht notwendigerweise um die Entwicklung der eigentlichen Anwendung bzw. die konkrete Verwendung der Regel- und Instanzdokumente im durchzuführenden Projekt. Vielmehr handelt es sich bei der Entwicklung von SchemaDokumenten ebenfalls um einen analyischen Teilbereich oder eine Vorarbeit für die eigentliche Entwicklung einer Applikaion.

2

Nähere Informaionen zum Standard: htp://www.w3.org/XML/ und htp://www.w3.org/TR/2004/RECxml11-20040204/

21

1

1

1. Elemente und Attribute

●

Validierung: Zum Schluss sollte – gerade bei größeren Projekten bzw. Projekten, in denen große Mengen an Datenströmen verwaltet werden, die Datenmengen erheblich und vielgestalig sind oder in denen eine besondere Qualitätssicherung sowie eine nachhalige und zukuntstaugliche Entwicklung gefordert wird – in einem letzten Schrit eine Kontrolle und Validierung stafinden. Dies kann durch eine Prototypentwicklung oder durch die Verwendung der auf dem Regeldokument basierenden Instanzdokumente in einem vorhandenen Prototyp, der um die XML-Fähigkeiten erweitert wird, oder ganz einfach mit vorhandenen Daten geschehen.

Abbildung 1.1: Projektphasen bei XML-Einsatz

In einem letzten Schrit bzw. in der nächsten Phase des Sotware-Entwicklungsprozesses steht die Entwicklung der eigentlich geplanten Anwendung auf dem Zeitplan. Aus XML-Perspekive ergibt sich nun bereits eine längere Testphase, in der ungünsige Strukturen, nicht beachtete Sonderfälle oder ungewöhnliche Realdatengegebenheiten mit dem Regeldokument kollidieren. Durch derarige Rückmeldungen aus dem weiteren Entwicklungsverlauf lassen sich dann iteraiv Veränderungen ableiten, die schließlich zum theoreisch korrekten Regeldokument führen. Des Weiteren werden nun auf der Basis des vorhandenen Schema-

22

1. Elemente und Attribute

Dokuments weitere XML-Technologien angewandt wie z. B. die Transformaion mit XSL oder XSL-FO3 (Umwandlung in Druckdateien wie PDF4).

1. 1. 2.  Prüfungsschema von XML-Dokumenten XML nun erlaubt die Deiniion eigener Auszeichnungsbefehle, die ausschließlich für die Textstruktur (und gerade nicht für Layout oder Darstellung) eingesetzt werden sollten. Zwar gibt es einige Praxisfälle, in denen auch Layoutregeln in XML umgesetzt werden, aber dies ist dann eher eine Modellierung von solchen Regeln zur strukturierten Erfassung und Verarbeitung. Handelt es sich nicht um abstrakte Speicherung für spätere Verarbeitung, sondern ähneln die Daten sehr exisierenden Standards wie DocBook oder FO (Formaing Objets), sollte man eher auf solche Standards ausweichen und das Rad nicht neu erinden. Es ist nicht immer leicht, Kunden, die Layout in XML unterbringen, vom Gegenteil zu überzeugen, können sie doch wunderbar mit XSL auf die Layoutregeln zugreifen, wodurch am Ende weiterhin wunderschöne PDF- und HTML-Dokumente entstehen. Aber für die Zukuntstauglichkeit und die langfrisige Datenstrukturierung und -speicherung lohnt eine vollständige Trennung von Layout und Inhalt bzw. der Semanik mit Hilfe der XML-Dokumente und der XSL-Dokumente. Hier muss sprachlich noch einmal deutlich gesagt werden, dass es sich bei den XML-Dokumenten stets um Instanzdokumente handelt, die korrekt auf bereits exisierenden Regeldokumenten beruhen. In Wirklichkeit gibt es ja nicht „das“ XML-Dokument, weil XML ja ausschließlich ein Konzept oder eine Technologie für die Verwendung und Entwicklung von eigenen Auszeichnungssprachen ist. Tatsächlich bezeichnet man ein XML-Dokument als ein solches, weil Textstücke mit Hilfe von Elementbezeichnungen in spitzen Klammern ausgezeichnet worden sind. Diese Syntax, also die Deiniion der verschiedenen Elementnamen etc., wiederum ist letztendlich immer in einem Regeldokument abgelegt, sodass vor der Verwendung eines Instanzdokumentes oder dem, was bis jetzt immer als XML-Dokument bezeichnet wurde, regelmäßig die Entwicklung eines Regeldokuments liegt. Abbildung 1.3 soll noch einmal die verschiedenen Dokumentypen und deren jeweilige Aufgaben bei der Verwendung von XML kennzeichnen. Wie man sich leicht vorstellen kann, benöigt man in einer kompleten Anwendung noch mindestens ein Dokument mit entsprechendem Quelltext, das die Transformaion startet oder mit den benöigten Parametern versorgt. Zusätzlich lassen sich weitere Dokumente und Strukturen aus dem XML-Umfeld denken wie z. B. solche mit semanischen Informaionen oder solche, die zur semanischen 3 4

Nähere Informaionen zum Standard: htp://www.w3.org/TR/xsl/ Nähere Informaionen zum Standard: htp://partners.adobe.com/asn/tech/pdf/speciicaions.jsp

23

1

1

1. Elemente und Attribute

Untersuchung und Abfrage von exisierenden Instanzdokumenten dienen. Daher handelt es sich bei der Schemadarstellung um das Grundprinzip oder auch um die Minimalanforderungen einer XML-Anwendung mit den folgenden Dokumentypen: ●

XML-Instanzdokument: Es basiert auf einem Regeldokument und befolgt die dort genannten Strukturregeln in Hinblick auf das Vorkommen, die Häuigkeit und die Reihenfolge sowie die Benennung von Elementen sowie entsprechende Datentypen.

●

XSD-Regeldokument: Es deiniert die Strukturregeln im Hinblick auf das Vorkommen, die Häuigkeit und die Reihenfolge sowie die Benennung von Elementen sowie von entsprechenden Datentypen. Seine Inhalte sind bei der Prüfung wichig, ob die Instanzdokumente sich an die getrofenen Regelungen halten, wobei die Prüfung für das XSL-Transformaionsdokument sicherstellt, dass die Transformaion durch den Zugrif auf die vorhandenen Elemente mit ihren sonsigen Eigenschaten erfolgreich verläut.

●

XSL-Transformaionsdokument: In ihm sind die Transformaionsregeln für die Umwandlung der XML-Datenströme in andere Formate enthalten. Es ist darauf angewiesen, dass die Regelungen im XSD-Regeldokument exakt eingehalten werden, da es selbst auf diese Regelungen zurückgreit, um Elemente zunächst zu ideniizieren und dann auch zu verarbeiten.

Abbildung 1.2: Dokumentypen und ihre Funkion bei XML-Verwendung

24

1. Elemente und Attribute

Für die Überprüfung gibt es zwei Dimensionen, in denen unterschiedliche Ergebnisse erreicht werden können: ●

Wohlgeformt5: Ein XML-Dokument ist wohlgeformt, wenn die Syntax korrekt eingesetzt wird, d. h., Atribute in Anführungszeichen gesetzt, leere Elemente extra ausgezeichnet und die allgemeinen Regeln der Namenskonvenion beachtet werden: ƒ Das erste Zeichen eines Namens muss ein Buchstabe, ein Unterstrich oder ein Doppelpunkt sein. ƒ Gülige Zeichen sind Buchstaben, Unterstriche, Zifern, Bindestriche sowie Punkte und Doppelpunkte. ƒ Streng verboten ist die Verwendung des Wortes „XML“ in all seinen Varianten als Namensbeginn, da geschützt ist.

●

Gülig6: Ein XML-Dokument ist gülig, wenn die benutzte Tag-Struktur der Anwendungslogik oder dem inhärenten Sinn des Dokuments genügt, d. h. soweit die Regelungen des Entwicklers erfüllt sind. Diese Regeln beinden sich in einem XML SchemaDokument.

Abbildung 1.3: Grundprinzip der Prüfung 5 6

Zur Deiniion: htp://www.w3.org/TR/2004/REC-xml11-20040204/#sec-well-formed Zur Unterscheidung von Prozessoren: htp://www.w3.org/TR/2004/REC-xml11-20040204/#proc-types htp://www.w3.org/TR/2004/REC-xml11-20040204/#proc-types sowie Unterscheidung beider Begrife: htp://www.w3.org/TR/xmlschema-1/#concepts-schemaConstraints

25

1

1

1. Elemente und Attribute

Ziel sollte also stets ein wohlgeformtes – da sonst ein allgemeiner Fehler autrit – und gleichzeiig güliges Dokument sein – da sonst ein spezieller Fehler in der Anwendungslogik autrit. Im Ergebnis hat man also zwei Prüfungsschrite: zum einen die Prüfung auf Wohlgeformtheit (Syntaxprüfung) und zum anderen die Güligkeitsprüfung (Verwendungsprüfung). Letztere muss nicht unbedingt erfolgen, da sie von der Existenz eines entsprechenden Schema-Dokuments mit Verwendungsangaben abhängt. Der Einsatz eines solchen Schema-Dokuments führt entweder zur Erkenntnis, dass das Instanzdokument gülig im Sinne des Schema-Dokuments ist oder nicht. Gülig und wohlgeformt sind also zur gleichen Zeit angestrebte Ziele, da sie zum einen nachweisen, dass die Regelungen des XML-Standards7 erfüllt sind und zum anderen die Regelungen des Schema-Dokuments befolgt wurden.

1. 1. 3.  Ansätze der Dokumentmodellierung Die Erstellung eines einfachen Regeldokuments für eine Visitenkarte, eine Adressliste etc. ist natürlich keine wirklich schwere Aufgabe. Allerdings kann man auch bei der Verwaltung von Adressen bemerken, dass in verschiedenen Standardanwendungen im Oice- oder Buchhaltungsbereich für die Erfassung der Adressdatenstruktur nicht nur fünf bis 10 Spalten wie in einem handelsüblichen Noizbuch bereit stehen, sondern teilweise mehr als 30. Teilweise sind diese dann auch nicht wirklich normalisiert, sondern im Hinblick auf wiederholende Einträge (alternaive Email-Adressen oder Telefonnummern) auf eine besimmte Anzahl von ähnlichen Einträgen begrenzt. Dies reicht zwar für 95% aller Eintragungen, aber bereits der Arbeitskollege mit Zweitwohnsitz im Ausland lässt sich mit seiner jeweiligen Mobil- und Festnetznummer nicht komplet erfassen. Dennoch kann man davon ausgehen, dass man für Datenstrukturen, die man sehr gut kennt, was natürlich bei solchen AlltagsDatenstrukturen wie Telefon- und Adressbuch der Fall sein dürte, spontan und iteraiv die korrekten Elemente und Strukturen entwickelt. Dabei würde man zunächst die unmitelbar und damit intuiiv einleuchtenden Elemente in einer vorläuigen hierarchischen Struktur und mit einer ebenso vorläuigen Häuigkeitsangabe erfassen. Durch einen iteraiven Prozess aus der Validierung mitels Testdaten bzw. Verarbeitungsnotwendigkeiten oder Verarbeitungswünschen würde man danach in mehreren Schriten, die mit dem endgüligen XML Schema-Dokument terminierten, die weiteren Elemente der zu modellierenden Datenstruktur erfassen. Dieses Vorgehen scheint grundsätzliche Überlegungen, wie Datenstrukturen zu modellieren sind, vollkommen überlüssig zu machen bzw. nur darauf zu beschränken, eine besimmten Syntax, wie in diesem 7

26

Vgl.: htp://www.w3.org/TR/2004/REC-xml-20040204/

1. Elemente und Attribute

Fall jene vom XML Schema, für die Beschreibung der Strukturen einzusetzen. Tatsächlich aber gelingt und terminiert dieser spontane Ansatz nur deswegen erfolgreich mit einem XML Schema-Dokument, weil die Analysephase durch die Erfahrung im Umgang mit der zu modellierenden Datenstruktur überlüssig wird. Ganz anders hingegen stellt sich die Lage dar, wenn eine noch unbekannte Datenlandschat modelliert werden soll, die zunächst einer Analyse und Darstellungsphase bedarf, in der graisch die zu modellierenden Elemente umgesetzt werden. Zwei sehr einfache Möglichkeiten auf der Ebene der einfachen Tags und ihrer hierarchischen Beziehungen sowie der Anzahl von möglichen Unterelementen sind das Block- und das Baumdiagramm. Sie sollen auch gleich bei der Erstellung von güligen und wohlgeformten XML-Dokumenten zum Einsatz kommen: In diesem Fall genügt die grundsätzliche Frage, welche Anforderungen an ein solches Dokument gestellt werden bzw. welche Informaionen in welcher Hierarchie benutzt werden sollen. Sowohl der Blockdiagramm- als auch der Baumdiagramm-Ansatz stellen graische Kodierungen bereit, mit denen Datenstrukturen, ihre Beziehungen untereinander, ihre Benennung und ihr Vorkommen und Autreten symbolisiert werden können. Durch die Verwendung einer graischen Notaion erleichtert man auch den Mitarbeitern das Verständnis und stärkt ihre Integraion in den Analyseprozess. In der Analysephase ist diese Integraion alle Anstrengung wert, weil man auf den Erfahrungsschatz der Mitarbeiter stets zurückgreifen können sollte, um die zuvor erwähnten Vorteile durch die spontan-intuiive Methode der Dokumentmodellierung zu nutzen. Zwar muss hier der Analyiker, der auch als interner Mitarbeiter für ein entsprechendes, fachfremdes Projekt ein externer Berater ist, durch geeignete Moderaion diese Erfahrungen freilegen und den Erkenntnis- und Validierungsprozess anleiten, aber durch eine ordentliche Integraion der mit den Daten täglich umgehenden Organisaionseinheiten (ganze Abteilungen, aber auch deren einzelne Mitarbeiter) erleichtert man die Entwicklung von komplexen Regeldokumenten, senkt die Fehlerquote und damit die Notwendigkeit, durch viele Rückkopplungen aus der Validierungsphase die fehlenden oder fehlerhaten Datenstrukturen zu erfassen. Nicht jede graische Notaion ist zwangsläuig einfach, so wie Schaltpläne auch nicht für jedermann ohne Anleitung und Vorwissen lesbar sind. Bei den im Folgenden vorgestellten Ansätzen jedoch ist die Wahrscheinlichkeit sehr hoch, dass nach einer kurzen Einarbeitungsphase in die Notaionstechnik die gerade erwähnten posiiven Efekte auch tatsächlich freigesetzt werden.

27

1

1

1. Elemente und Attribute

1. 1. 3. 1  Der Blockdiagramm-Ansatz Das Blockdiagramm bietet die Möglichkeit, sehr einfach und anschaulich von einem vorhandenem Dokument wie z. B. einem beliebigen Erfassungsbogen auszugehen und in ihm die einzelnen Einheiten und Abschnite zu umrahmen, die ein Oberelement bzw. einen Auszeichnungsbefehl bilden könnten. Andersherum könnte bei der Erstellung eines Blockdiagramms ohne eine solche Vorlage vor dem inneren Auge des Betrachters ein entsprechendes Formblat entstehen und wegen dieser Anschaulichkeit entsprechend assoziaive Kräte frei werden lassen, welche Texteinheiten noch mit diesem Dokument erfasst werden sollten. Man erhält also in beiden Bereichen eine mögliche Dokumentenstruktur mit einfachen graischen Miteln, die jeder unmitelbar oder höchstens nach einer sehr kurzen Einarbeitungszeit versteht. Bei der Datenmodellierung in einem ohnehin schon durch Formulare, Formbläter und Dokumentvorlagen gekennzeichneten Organisaionsumfeld ist dies ein Ansatz, der bei einfachen oder lachen Datenbeziehungen ausreicht. In jedem Fall kann er in diesen Projekten aber auch als erster Schrit für eine Übertragung der vorhandenen Dokumente dienen, wobei die vorhandenen Vorlagen von den Datenstrukturen, die sie abbilden, getrennt werden. Dadurch können in Gesprächen, die während der gemeinsamen Erstellung des Diagramms stafinden, auch Schwierigkeiten mit den vorhandenen Formularen berücksichigt werden. Zu den klassischen Schwierigkeiten gehören hierbei fehlende Felder oder Daten, die handschritlich immer zusätzlich eingetragen werden, Abkürzungen oder Textblöcke, die schemaisiert einzutragen, aber nicht auszuwählen sind, oder auch Komplikaionen bei der Verarbeitung von weichen Daten, die häuig autreten, aber nicht in eines der vorgegeben harten Rasterfelder eingegeben werden können. Im Rahmen der Analyse sollte auch hier darauf geachtet werden, solche bestehenden Schwierigkeiten aufzudecken, die nicht mit der realen Datenstruktur unmitelbar, sondern eigentlich nur mit der bereits vorliegenden Ableitung aus der realen Datenstruktur zu tun haben, und verbessernd im XML-Projekt zu berücksichigen. Durch den Blockdiagramm-Ansatz bzw. die Ähnlichkeit mit einem tatsächlichen Formular können auch leicht Validierungen vorgenommen werden. Das kann entweder mit Testoder Realdaten geschehen oder durch die Nachbildung eines typischen Verarbeitungsprozesses. Hier ist insbesondere wichig zu ermiteln, wie verständlich und gut die Daten für nachfolgende Organisaionsstellen und Verarbeitungseinheiten aubereitet sind. Gerade für Mitarbeiter, die nur mit erfassten, nicht aber mit den real beobachteten Daten zu tun haben, ist dies ein entscheidender Faktor beim Umgang mit den vorliegenden Daten. Beide Dimensionen dürten dann neue Abhängigkeiten, Hierarchien oder Beziehungen und evtl. sogar benöigte Elemente ofenbaren, die bisher noch keine Berücksichigung fanden.

28

1. Elemente und Attribute

Abbildung 1.4: Blockdiagramm für eine Mitarbeiterdatenstruktur

1. 1. 3. 2  Baumdiagramm-Ansatz Eine Alternaive zu diesem Vorgehen, das für sehr umfangreiche Dokumente mit vielen hierarchischen Beziehungen, die teilweise auch noch ungleichmäßig verteilt sind, besser geeignet ist, ist das Baumdiagramm. Hier hat man die Möglichkeit, sich von größeren Bereichen zu kleineren Einheiten durch die Anwendung zu arbeiten. Zudem kann man sehr einfach ganze Bereiche abdecken bzw. in Powerpoint ausblenden lassen, um einen speziellen Abschnit des Baums ins Blickzentrum zu rücken. Dies ist im Blockdiagramm nicht möglich, da dann der entsprechende Bereich eine leere Fläche bildet und weiterhin stark aufällt. Um ein Dokument auf Güligkeit hin zu prüfen, d. h., darauhin zu testen, ob keine falsch überlappenden Abschnite wie im folgenden Beispiel entstehen, genügt es beim Blockdiagramm, darauf zu achten, dass sich keine Blöcke überlagern. Beim Baumdiagramm hingegen dürfen sich keine Linien schneiden.

29

1

1

1. Elemente und Attribute

Abbildung 1.5: Baumdiagramm für Mitarbeiter-Datenstruktur

1. 1. 3. 3  Erweitertes Baumdiagramm Wir verwenden für die Darstellung eines realisischen Dokuments nun ausschließlich das Baumdiagramm, da es die Abhängigkeiten und Strukturen bei umfangreicheren Dokumenten doch etwas besser als ein Blockdiagramm versinnbildlicht. In einem erweiterten Schema wurden nun in die ursprüngliche Zeichnung folgende weiteren Elemente zur Planung eingebetet: ●

Alle XML-Befehle werden in einem Rechteck dargestellt.

●

Übergeordnete Tags, d. h., solche mit weiteren Untertags, erhalten eine graue Färbung, wobei allerdings keine weitere Unterscheidung über den Rang getrofen wird.

●

Atribute werden direkt mit dem Tag verknüpt, zu dem sie gehören. Zusätzlich erhalten Sie einen gestrichelten Rahmen.

●

Sich wiederholende Gruppen werden umrahmt. Dafür verzichtet man auf die explizite Nennung der Wiederholung durch mehrmalige Verwendung im Schema. Die Anzahl

30

1. Elemente und Attribute

der Wiederholungen kann dann durch einen Zahlwert oder durch eine nach oben ofene Schranke in Form eines Plus-Zeichens dargestellt werden.

Abbildung 1.6: Erweitertes Baumdiagramm für Mitarbeiterliste

1. 1. 4.  Eine Beispielanwendung Die oben theoreisch erläuterten Gedanken zur Notwendigkeit von Dokumentmodellierung soll nun an einem konkreten XML-Instanzdokument, einem Regeldokument in der XML Schema-Syntax und einem XSL-Dokument beispielhat dargelegt werden. Hier spielen erstmals XML Schema und die Verknüpfung von Instanzdokument und Transformaionsdokument eine Rolle. XSLT ist die Anwendung, die auf ein Instanzdokument zugreit und dabei prinzipiell darauf angewiesen ist, dass die Regelungen im Schema-Dokument tatsächlich auch im Instanzdokument erfüllt sind. Zwar ist es möglich, XSL-Dokumente auch so zu erstellen, dass sie relaiv lexibel auf unterschiedliche Gegebenheiten in XML-Instanzdokumenten reagieren bzw. solche Unterschiede gar nicht bemerken. Sie können sogar, solange zumindest die Elementnamen nicht auch noch rücksichtslos verschieden im Vergleich zum Regeldokument sind, die gleiche Ausgabe erzeugen und trotz der Regelverstöße die Daten erfolgreich verarbeiten. Doch das ist in erster Linie eine Rainesse von XSL und in zweiter Linie natürlich keine Anwendung mit hoher Qualität. Ausgehend von obiger Mitarbeiterliste folgt nun eine konkrete Mitarbeiterliste mit den zuvor genannten Elementen, wobei die Adressbestandteile zusammengestrichen wurden, um das Beispiel nicht unnöig kompliziert oder lang zu gestalten.

31

1

1

1. Elemente und Attribute



Anja Doppelt

Technik

Reinhard Bergluft

Technik

Marco Scheffchen

Geschäftsführer

11_01.xml: Mitarbeiterliste mit drei Mitarbeitern

Ob man nun auf der Basis eines gegebenen XML-Dokuments ein mögliches Schema-Dokument erstellt, oder ob man zunächst die Dokumentmodellierung festlegt und dann gülige Instanzen erzeugt, hängt vom jeweiligen Projekt oder der Schwierigkeitsstufe ab. Jene Teilnehmer eines solchen Projekts, die eher beispielhat denken und arbeiten und die lieber direkt mit den Daten bzw. Ergebnissen arbeiten, die ohnehin am häuigsten erstellt werden (in diesem Fall ja gülige Instanzdokumente und nur ein Regeldokument), werden sicherlich ein beispielhates Vorgehen schätzen und die Regelungen zunächst implizit gedanklich verwalten und nachher in die XML Schema-Syntax transferieren. So soll es auch in diesem Beispiel sein.

32

1. Elemente und Attribute

Ein Regeldokument, das also das obige Instanzdokument komplet charakterisiert und in diesem Sinne zu wenig Freiräume lässt, hat die nachfolgende Gestalt. Abgesehen von den Syntaxdetails und den naturgemäß vielen Verschachtelungen, die XML Schema-Dokumente (als kleine, unterschwellige Kriik) ohne Kommenierung oder Freizeilen bisweilen schwer lesbar machen können, sind folgende Regelungen erfasst: ●

Das Wurzelelement heißt Mitarbeiterliste. Es enthält mehrere Unterelemente namens Mitarbeiter und sonst keine weiteren Inhalte.

●

Das Element Mitarbeiter enthält die Elemente Name und Funktion.

●

Das Element Name enthält die Elemente Vorname und Nachname in den Datentypen string sowie das verplichtende Atribut Anrede, das nur die beiden Werte Herr oder Frau enthalten darf.

●

Die beiden Elemente Vorname und Nachname wiederum enthalten – wie schon in den Datentypen dargelegt – Textwerte.

●

Das Element Funktion hingegen enthält nur die beiden Textwerte Geschäftsführer oder Technik.

Wenn man die obigen Regelungen genauer betrachtet, fällt zuallererst auf, dass die gesamte Datenstruktur, die für die Erfassung und Verarbeitung von Mitarbeiterdaten bereit liegt und alleine schon in der Buchhaltung und für Sozial- und Krankenkassen benöigt wird, alles andere als vollständig ist. Es müssten noch diverse Zahlwerte die Sozialversicherungs- und Krankenkassennummern sowie das Geburtsdatum eingefügt werden, auf die jedoch in unserem Beispiel verzichtet wird, um keine Langeweile aukommen zu lassen. Des Weiteren erkennt man, dass die Adresse komplet fehlt, was allerdings bereits zuvor ausgeschlossen war. Schließlich sind zwei Aufzählungstypen in die Regelungen eingearbeitet, von denen der eine die Werte im Atribut Anrede und der andere die Werte für das Element Funktion beschränken und vollständig abdecken. Während für die Anrede Herr und Frau ausreichen, ist es sehr unwahrscheinlich, dass der gesamte Mitarbeiterstamm aus Geschätsführern und Technikern besteht. Theoreisch ist auch dies möglich, aber ein Blick in die Beispieldatenbank würde zeigen, dass auch andere Funkionen im Unternehmen angesiedelt sind.

33

1

1

1. Elemente und Attribute























34

1. Elemente und Attribute

11_01.xsd: Mögliches Regeldokument für Mitarbeiterliste

Als Graik ohne Darstellung der Atribute erhält man folgende Repräsentaion des abgedruckten XML Schema-Dokuments. Beachten Sie auch hier noch einmal, dass nur die Elemente Vorname, Nachname und Funktion Daten und keine weiteren Elemente enthalten.

Abbildung 1.7: Struktur des Regeldokuments für die Mitarbeiterliste

Bei der Datenverarbeitung, die in dieser Beispielanwendung durch ein XSL-Dokument als Transformaionsdokument charakterisiert wird, greit man auf die gesamte Mitarbeiterliste zu und erstellt in der HTML-Ausgabe eine unsorierte Liste. Für jedes MitarbeiterElement wird hiernach ein Listenpunkt erzeugt, der als Wert die Elemente adressiert, die Texinhalte speichern. Diese werden in der Reihenfolge Vorname Nachname (Funktion) mit Klammerung und Leerstellen ausgegeben.

• 
  
  


35

1

1

1. Elemente und Attribute

(

)

11_01.xsl: Transformaionsdatei für Mitarbeiterliste

Als Ergebnis erhält man die in Abbildung 1.8 zu sehende Liste.

Abbildung 1.8: Ausgabe nach Transformaion

Natürlich ist die Wahrscheinlichkeit, dass bei einer automaisierten Erzeugung von Instanzdokumenten Fehler wie die folgenden autreten, sehr gering, aber durch entsprechend

36

1. Elemente und Attribute

falsch konstruierte Verarbeitungsbedingungen im Rahmen der Erstellung, können solche und andere Fehler entstehen. Wesentlich höher ist dagegen die Wahrscheinlichkeit, dass bei einer manuellen Erstellung von XML-Dokumenten ohne Editor mit automaischer Syntaxprüfung gerade Reihenfolge, Häuigkeit und Platzierung von Elementen misslingt, die ein entsprechender Editor zwar herausinden und mokieren sollte, die aber bei ungeeigneten Editoren unbemerkt in das System gespeichert werden. Sobald eine solche Datei in der Anwendung mit XSLT verarbeitet wird, erhalten wir ein unschönes Ergebnis. Dies liegt nicht daran, dass XSL direkt auf die XML Schema-Datei zugreit, sondern dass das Transformaionsdokument auf der Grundlage des Schemas erstellt wurde und die gegebenen Lokalisierungspfade im Instanzdokument für die Erzeugung des gewünschten Ergebnisses benöigt.



Anja Doppelt

Technik

Die einzelnen Elemente entstammen dem Namensraum htp://www.w3.org/2001/XMLSchema, der mit dem Präix xs abgekürzt wird. Dieses Präix verwendet man dann für alle folgenden Elemente dieses Namensraums. Das bedeutet für das Element, dass es mit seinem qualiizierten Elementnamen, bestehend aus praeix:elementname, aufgerufen wird. So besteht die Möglichkeit, Elemente und Atribute aus anderen Namensräumen für die Erweiterung von XM Schema zu eigenen Zwecken zu verwenden.

1. 2. 2.  Einfache und komplexe Elemente deklarieren Die einzelnen Elemente lassen sich über den Elementnamen element8 deklarieren, wobei als obligatorisches Atribut name für die Speicherung des Namens steht. Für die Festlegung, welches Inhaltsmodell für dieses Element gilt, gibt es zwei Möglichkeiten: ●

8

Als leeres Element bezieht es sich entweder auf einen vordeinierten oder abgeleiteten Datentyp und enthält die Werte als Inhaltsmodell, die dieser Datentyp speichert. Alternaiv besteht die Möglichkeit, wiederverwendbare Komponenten zu konstruieren und diese dann als Datentyp aufzurufen. Auf diese Weise kann man Inhaltsmodelle konstruieren, die Elemente oder auch gemischte Inhaltsmodelle (Elemente und Text) enthalten, wobei aber die genaue Deklaraion an anderer Stelle im XML Schema-Dokument steht. Für beide Varianten verwendet man das Atribut type, das den Datentyp aufrut. Vgl. htp://www.w3.org/TR/xmlschema-1/#cElement_Declaraions

43

1

1

1. Elemente und Attribute

●

Als Element bezieht es sich zwischen Start- und End-Tag auf die benöigten untergeordneten Elemente. Hierbei müssen syntakisch weitere Strukturen aufgerufen werden, mit denen neben der Idenität auch die Kardinalität und Häuigkeit angegeben werden können.

Im nächsten Ausschnit deiniert man unvollständig das Element Uhrzeit, das später weitere Element enthalten kann.



65

1

1

1. Elemente und Attribute



Anton

Ebenhof

DE

Essen

555

474



14_05.xml: Atributorieniertes Dokument

Die Modellierung solcher Dokumente ist strukturell überaus simpel, wenngleich der Quelltext in diesem Fall dennoch nicht sonderlich kurz ist. Im Matrjoschka-Design hat er folgende Gestalt:







66

1. Elemente und Attribute



















14_05.xsd : Modellierung von atributorienierten Dokumenten

67

1

1

1. Elemente und Attribute

Die eigentliche Struktur ergibt sich durch den Elementbaum, der damit der am wenigsten verschachtelte Baum dieses Textes ist.

Abbildung 1.19: Element-Struktur

Die atributorienierten Dokumente wachsen dynamisch mit ihren Inhalten bzw. bedürfen eben keiner Koniguraion, wenn neue Werte erfasst werden sollen. Während bei elementorienierten Dokumenten immer neue Elemente und Strukturen in die Schema-Datei eingelochten werden müssen, ist es mit einem atributorienierten Dokument möglich, einfach neue Werte zu erfassen, sofern man mögliche Werte für z. B. die Werte attrname-Atributen in einer Aufzählung (xs:enumeration-Elemente) aufnimmt, die dann natürlich genauso wachsen müsste, wie die Elementstruktur in einem elementorienierten Dokument. Die einfache Modellierung, die dynamischen Inhalte und wenig verschachtelte Dokumente erweisen sich als sehr vorteilhat. Die Nachteile dagegen liegen vor allen Dingen in der Verarbeitung wie z. B. mit XSLT: Man benöigt einen XPath-Ausdruck wie child::*[@

attr-name=‘Nachname‘ or @attr-name=‘Vorname‘ or @attr-name=‘Land‘ or @attr-name=‘Ort‘]“, um alle die add-attr-Elemente mit den Werten Nachname, Vorname, Land oder Ort zu inden. Der Ausdruck würde nur Knoten für die Verarbeitung freigeben, deren add-attr-Element gleichzeiig im Atribut attr-name den Wert Ort und dann im value-Element den Textknoten Essen enthält. Dagegen

schreibt der Ausdruck den Wert des Textknotens in den Ausgabestrom. Das heißt, dass jeweils ein extra Prädikat benutzt werden muss, um das passende add-attr-Element auszuwählen, da der Bezeichner, der sonst im Elementnamen zu inden ist, ein Atributwert ist. Sollen dann inhaltliche Einschränkungen vorgenommen werden, die ansonsten das einzige Prädikat darstellen, handelt es sich um ein zusätzliches Prädikat. Daher indet man in den unterschiedlichen XPath-Ausdrücken zwei Prädikate: eines für die Lokalisierung und eines für den Inhalt. Im weiteren Verlauf dieses Buchs werden solche atributorienierten Dokumente nicht weiter verwendet werden, weil sie nur wegen ihrer Grundstruktur ein interessanter Aspekt der Datenmodellierung sind. Die Syntax von XML Schema jedoch lässt sich meistens besser

68

1. Elemente und Attribute

an den elementorienierten Dokumenten zeigen. Wichig ist jedoch, dass man eine solche Möglichkeit der Modellierung überhaupt in Betracht zieht, wenn Daten in XML modelliert werden sollen.

69

1

Fe b

ru

ar

20

11

Datentypen und Strukturen

2. Datentypen und Strukturen

2. Datentypen und Strukturen

2

Dieses Kapitel stellt die Typbibliothek von XML Schema mit Erläuterungen zu den einzelnen Datentypen und vielen Beispielen vor. Für noch genauere Informaionen zu den einzelnen Typen ist es allerdings auch notwendig, die W3C-Referenz zu konsulieren, denn die Typbibliothek ist ein eigener Standard. So können die Datentypen auch von anderen Standards genutzt werden.

2. 1.  Vordeinierte Datentypen In diesem Abschnit sollen zunächst die in XML Schema vordeinierten Datentypen vorgestellt werden, wobei es sich zum einen um primiive und daraus abgeleitete Typen handelt. Grundlegende Elemente sind auch in anderen Programmiersprachen sowie natürlich in Datenbanken bekannt, allerdings gib es eine Vielzahl von sehr speziellen Datentypen, die in dieser Form nur in XML Schema anzutrefen sind. Vordeinierte Datentypen1 sind solche, die bereits von Anfang an in XML Schema bereit stehen und sofort verwendet werden können. Sie teilen sich noch einmal auf in primiive und abgeleitete Datentypen, wobei die primiiven wie in anderen Zusammenhängen auch als Urtypen verstanden werden können, die ohne andere Datentypen oder ohne einen Kontext gülig sind. Abgeleitete Datentypen hingegen basieren auf den beiden Datentypen decimal und string. Sie entstehen durch Einschränkung des Wertebereichs.

2. 1. 1.  Primiive Datentypen Die in XML Schema vorhandenen primiiven2 Datentypen lassen sich in folgende Kategorien einordnen:

1 2

Vgl.: htp://www.w3.org/TR/xmlschema-2/#built-in-datatypes Vgl.: htp://www.w3.org/TR/xmlschema-2/#built-in-primiive-datatypes

71

2. Datentypen und Strukturen

●

Zeichenketen

2

ƒ string speichert eine beliebige Zeichenkete (htp://www.w3.org/TR/xmlschema-2/#string). ƒ anyURI speichert Angaben von URI (Uniform Ressource Ideniier) mit absoluter oder relaiver Pfadangabe. Leerzeichen sollten in %20 umgewandelt werden (htp://www.w3.org/TR/xmlschema-2/#anyURI). ƒ QName speichert XML-qualiizierte Namen mit einer Angabe des Namensraums und des eigentlichen Namenswertes, wobei der Namensraum innerhalb der Sichtbarkeit von QName deklariert werden muss (htp://www. w3.org/TR/xmlschema-2/#QName). ƒ NOTATION speichert NOTATION-Atributangaben, wobei sich die Werte aus dem Bereich möglicher QName-Werte rekruieren. Dabei dürfen nur die Notaionsnamen verwendet werden, die im aktuellen Schema deklariert sind (htp://www.w3.org/TR/xmlschema-2/#NOTATION). ●

Logik ƒ boolean speichert Zeichenketen, die die zweiwerige Logik mit Hilfe der beiden Werte {TRUE, FALSE} abbilden. Mögliche Werte entstammen dabei der Menge {true, false, 1, 0} (htp://www.w3.org/TR/xmlschema-2/#boolean).

●

Zahlen ƒ decimal speichert Dezimalzahlen mit beliebiger Genauigkeit, wobei der Dezimaltrenner ein Punkt ist (htp://www.w3.org/TR/xmlschema-2/#decimal). ƒ loat speichert einfach-genaue Zahlenwerte als Dezimalzahlen mit maximaler Länge von 32 Bit. Für die Darstellung von Exponenialzahlen verwendet man eine Zahl für die Manisse, gefolgt von dem Buchstaben E, wiederum gefolgt vom Wert des Exponenten. Der Dezimaltrenner ist in beiden Fällen der Punkt (htp://www.w3.org/TR/xmlschema-2/#loat). ƒ double speichert doppelt genaue Zahlenwerte als Dezimalwerte mit maximaler Länge von 64 Bit. Für die Darstellung von Exponenialzahlen verwendet man eine Zahl für die Manisse, gefolgt von dem Buchstaben E, gefolgt

72

2. Datentypen und Strukturen

wiederum vom Wert des Exponenten. Der Dezimaltrenner ist in beiden Fällen der Punkt (htp://www.w3.org/TR/xmlschema-2/#double). ●

Zeitangaben ƒ duration Dieser Datentyp verarbeitet und speichert Kombinaion aus Zahlen und standardisierten Zeichen, die Platzhalter für Zeitangaben sind, um Zeitspannen auszudrücken. Dabei werden die benöigten Zeitangaben in einem sechsdimensionalen Raum angegeben, bei denen das gregorianische Jahr, Monat, Tag, Stunde, Minute und Sekunde die einzelnen Dimensionen bilden. Das allgemeine Format lautet dabei PnYnMnDTnHnMnS, wobei bei einer konkreten Zeitangabe nicht alle Felder ausgefüllt werden müssen. Der Platzhalter n wird durch einen Integerwert ersetzt, der die Anzahl der angegebenen Einheiten widerspiegelt: Y für Jahr, M für Monat, D für Tag, H für Stunde, M für Minute und S für Sekunde. Die beiden Platzhalter P und T kennzeichnen die gesamte Zeichenkete und trennen Tages- von Uhrzeitangabe (htp://www.w3.org/TR/xmlschema-2/#duraion). ƒ dateTime speichert Datumsangaben aus Datum und Uhrzeit in der Form CCYY-MM-DDThh:mm:ss mit dem Trennzeichnen T zwischen Tages- und Uhrzeitangabe, wobei die Platzhalter der Felder in jedem Fall ausgefüllt werden müssen, d. h., für die Jahresangabe müssen vier Zeichen gesetzt werden und für die restlichen jeweils zwei. Sind in der Zeitangabe weniger als zwei Stellen nöig, so füllt man die zweite Stelle mit Null auf (htp://www.w3.org/ TR/xmlschema-2/#dateTime). ƒ time speichert Uhrzeiten ohne Datumsinhalt in der Form hh:mm:ss.sss (htp://www.w3.org/TR/xmlschema-2/#ime). ƒ date speichert Datumsinformaionen ohne Uhrzeitangabe aus der Menge der Werte des gregorianischen Kalenders. Dabei besteht dieser aus jeweils einen Tag langen Instanzen ohne Berücksichigung der Stundendauer. Die Angabe erfolgt wie bei dateTime, allerdings ohne Uhrzeitangabe, in der Form: CCYY-MM-DD (htp://www.w3.org/TR/xmlschema-2/#date). ƒ gYearMonth speichert Monatsangaben, die zusätzlich mit einer Jahresangabe verknüpt sind. Die Form entspricht dabei der Felderauteilung in dateTime, wobei die beiden CCYY-MM verwendet werden (htp://www.w3.org/ TR/xmlschema-2/#gYearMonth).

73

2

2. Datentypen und Strukturen

ƒ gYear speichert Jahrangaben des gregorianischen Kalenders in der Feldform des Datentyps dateTime, mit CCYY. Auch die Verwendung des Minuszeichens ist erlaubt (htp://www.w3.org/TR/xmlschema-2/#gYear).

2

ƒ gMonthDay speichert Monatsangaben des gregorianischen Kalenders mit Hilfe der Felddarstellung von dateTime, also den Feldern MM-DD (htp:// www.w3.org/TR/xmlschema-2/#gMonthDay). ƒ gDay speichert Tagangaben des gregorianischen Kalenders mit Hilfe der Felddarstellung von dateTime mit dem Feld DD (htp://www.w3.org/TR/ xmlschema-2/#gDay). ƒ gMonth speichert Monatsangaben des gregorianischen Kalenders mit Hilfe der Felddarstellung von dateTime mit dem Feld MM (htp://www.w3.org/ TR/xmlschema-2/#gMonth). ●

Binärdaten ƒ hexBinary speichert Zeichenketen in hexadezimaler Kodierung mit jeweils zwei Zeichen aus dem Wertebereich [0-9a-fA-F] (htp://www.w3.org/TR/ xmlschema-2/#hexBinary). ƒ base64Binary speichert binäre Daten in einer Zeichenketendarstellung aus dem Wertebereich des Base64-Alphabets mit den Zeichen a-z, A-Z, 0-9, +,/,= und dem Leerzeichen (htp://www.w3.org/TR/xmlschema2/#base64Binary). anyType

anySimple Type

anyURI

base64 Binary

Notation

QName

boolean

string

hexBinary

date

duration

time

datetime

Abbildung 2.1: Vordeinierte primiive Datentypen

74

double

float

gYearMonth

decimal

gYear

gMonthDay

gDay

gMonth

2. Datentypen und Strukturen

Folgendes Dokument soll als einfaches Beispiel für den Aufruf der verschiedenen Datentypen dienen. Es enthält einige Umsatzdaten zu verschiedenen Tarifen, ihren Grundpreis pro Minute in Cent sowie den damit umgesetzten Preis im angegebenen Jahr.

Schicht2 1.5 g 72538.02

Abendessen 1 p 70062.24

Mittagspause 1.5 p 64419.35

21_01.xml: Umsatzübersicht mit verschiedenen Datentypen

Das gesamte Dokument besteht aus mehreren bzw. beliebig vielen Umsatz-Elementen, die selbst wieder als komplexer Typ konstruiert werden, da sie weitere Elemente enthalten. Den einzelnen Elemente wird im Atribut type ein passender Datentyp aus den Möglichkeiten der vordeinierten primiiven zugewiesen. Dies gilt sowohl für die Elemente, die mit element deklariert werden, als auch für die Atribute, die mit attribute deklariert werden. Die verschiedenen Datentypen rut man über den in den Abbildungen und Listen angegebenen Namen auf und setzt als Namensraumpräix das bekannte xs: davor. Die Datentypauswahl für die verschiedenen Komponenten ist relaiv simpel und sähe auch in einer beliebigen Programmiersprache ähnlich aus. Für die mit ihrem Klarnamen und z. B.

75

2

2. Datentypen und Strukturen

2

mit nicht ihrem Primärschlüssel angegebenen Tarifnamen greit man auf string zurück, während der Preis als Dezimalzahl den Typ loat erhält. Für die größeren Werte im Element Summe verwendet man decimal, weil in ihm größere Werte gespeichert werden können.













21_01.xsd: Vordeinierte primiive Datentypen

2. 1. 2.  Abgeleitete Datentypen Neben den Datentypen, die durch den Benutzer erstellt werden können und aus vordeinierten Datentypen abgeleitet werden, bietet XML Schema auch eine Reihe an vordeinierten Datentypen an, die ebenfalls von anderen Datentypen abgeleitet3 sind. Als Basistypen sind dies decimal und string, wobei die Datentypen, die auf ihnen basieren, ihrerseits wiederum Basistypen für weitere abgeleitete Datentypen sind. Sowohl in der Referenz als auch in der Übersichtsgraik ist angegeben, welche Basistypen und welche abgeleiteten Datentypen für einen gegebenen vordeinierten Datentyp vorhanden sind. 3

76

Vgl.: htp://www.w3.org/TR/xmlschema-2/#built-in-derived

2. Datentypen und Strukturen

anyType

2

anySimple Type anyURI

base64 Binary

Notation

QName

boolean

string

hexBinary

date

duration

time

datetime

double

float

normalized String

name

nonPositive Integer NMTOKEN negative Integer

NCName

decimal

IDREF

gMonth

gDay

unsigned Long

NMTOKENS

ENTITY

long

nonNegative Integer

unsignedInt

ID

gYear

gMonthDay

integer

token

language

gYearMonth

positive Integer

short

byte

unsignedSh ort

unsigned Byte

Abbildung 2.2: Vordeinierte, abgeleitete Datentypen

Sie lassen sich anhand der gerade genannten Basistypen in genau zwei Kategorien einordnen: ●

Zeichenketen ƒ normalizedString speichert Zeichenketen, die keine Leerzeichen mehr enthalten, wobei die Menge der Zeichen, die in normalizedString gespeichert werden können, folgende Zeichen nicht enthalten: Wagenrücklauf (carriage return, #xD), Zeilenvorschub (line feed, #xA), Tabulatorzeichen (tab, #x9) (htp://www.w3.org/TR/xmlschema-2/#normalizedString). ƒ token speichert Zeichenketen, die als Tokens übersetzt wurden. In der Menge der Zeichen, die in token gespeichert werden können, sind folgende Zeichen nicht enthalten: Wagenrücklauf (carriage return, #xD), Zeilenvorschub (line feed, #xA), Tabulatorzeichen (tab, #x9) und zusätzlich weder zu Beginn oder Ende ein Leerzeichen noch innerhalb der Zeichenkete Folgen von mehr als einem Leerzeichen (htp://www.w3.org/TR/xmlschema-2/#token). ƒ language speichert Zeichenketenfolgen für die Ideniikaion natürlicher Sprachen, die unter htp://www.ief.org/rfc/rfc1766.txt deiniert sind und

77

2. Datentypen und Strukturen

unter htp://www.w3.org/TR/WD-html40-970708/struct/dirlang.html näher erklärt werden. Beispiele: FR (Französisch), DE (Deutsch), IT (Italienisch), NL (Niederländisch), EL (Griechisch), ES (Spanisch), PT (Portugiesisch), AR (Arabisch), HE (Hebräisch), RU (Russisch), ZH (Chinesisch), JA (Japanisch), HI (Hindi), UR (Urdu) und SA (Sanskrit) (htp://www.w3.org/TR/xmlschema2/#language).

2

ƒ NMTOKEN speichert Zeichenketenwerte des NMTOKEN-Atributs (htp:// www.w3.org/TR/xmlschema-2/#NMTOKEN). ƒ NMTOKENS speichert Listeneinträge mit dem Datentyp NMTOKEN, d. h., eine Reihe von Zeichenketen in der Form von NMTOKEN (htp://www.w3.org/TR/ xmlschema-2/#NMTOKENS). ƒ Name speichert XML-Namen mit dem Wertebereich der Zeichenketen, die in XML gülig sind (htp://www.w3.org/TR/xmlschema-2/#Name). ƒ NCName speichert XML-Namen ohne Doppelpunkt (non-colonized names) mit dem Wertebereich der in XML güligen NCName-Zeichenketen (htp:// www.w3.org/TR/xmlschema-2/#NCName). ƒ ID speichert den ID -Atribut-Typ von XML mit dem Wertebereich aller Zeichenketen, die für NCName gülig sind (htp://www.w3.org/TR/xmlschema2/#ID). ƒ IDREF speichert Werte des IDREF-Atribut-Typ von XML mit dem Wertebereich aller Zeichenketen, die für NCName gülig sind (htp://www.w3.org/ TR/xmlschema-2/#IDREF). ƒ IDREFS speichert Werte des IDREFS-Atributs aus XML. Der Wertebereich besteht aus einer Liste von IDREF-Werten. Der lexikalische Bereich ist eine Token-Liste, deren einzelne Werte durch ein Leerzeichen voneinander getrennt sind und deren Datentyp IDREF ist (htp://www.w3.org/TR/xmlschema-2/#IDREFS). ƒ ENTITY speichert das ENTITY-Atribut aus XML. Der lexikalische Bereich ist die Menge der güligen NCName-Zeichenketen (htp://www.w3.org/TR/ xmlschema-2/#ENTITY).

78

2. Datentypen und Strukturen

ƒ ENTITIES und speichert das ENTITIES-Atribut von XML. Der Wertebereich ist die Menge der ENTITY-Werte. Der lexikalische Bereich ist eine TokenListe, deren einzelne Werte durch ein Leerzeichen voneinander getrennt sind und deren Datentyp ENTITY ist (htp://www.w3.org/TR/xmlschema2/#ENTITIES). ●

Zahlen ƒ integer speichert Zahlenwerte, deren fractionDigits-Angabe den Wert 0 aufweist. Es sind demnach Ganzzahlen. Eine führende Null sowie ein führendes Plus-Zeichen sind nicht gestatet (htp://www.w3.org/TR/ xmlschema-2/#integer). ƒ nonPositiveInteger speichert negaive Zahlenwerte, deren fractionDigits-Angabe den Wert 0 aufweist, demnach negaive Ganzzahlen. Der Wert 0 der maxInclusive-Angabe schließt die Null mit ein. Führende Nullen sind nicht erlaubt (htp://www.w3.org/TR/xmlschema2/#nonPosiiveInteger). ƒ negativeInteger speichert negaive Zahlenwerte, deren fractionDigits-Angabe den Wert 0 aufweist, also negaive Ganzzahlen. Der Wert –1 der maxInclusive-Angabe schließt die Null aus. Führende Nullen sind nicht erlaubt (htp://www.w3.org/TR/xmlschema-2/#negaiveInteger). ƒ long speichert Zahlenwerte im Bereich von maxInclusive 9223372036854775807 und minInclusive – 9223372036854775807. Eine führende Null sowie ein führendes Plus-Zeichen sind nicht gestatet (htp:// www.w3.org/TR/xmlschema-2/#long). ƒ int speichert Zahlenwerte im Bereich von maxInclusive 2147483647 und minInclusive –2147483647. Eine führende Null sowie ein führendes PlusZeichen sind nicht gestatet (htp://www.w3.org/TR/xmlschema-2/#int). ƒ short speichert Zahlenwerte im Bereich von maxInclusive 32767 und minInclusive –32767. Eine führende Null sowie ein führendes Plus-Zeichen sind nicht gestatet (htp://www.w3.org/TR/xmlschema-2/#short). ƒ byte speichert Zahlenwerte im Bereich von maxInclusive 127 und minInclusive –128. Eine führende Null sowie ein führendes Plus-Zeichen

79

2

2. Datentypen und Strukturen

sind nicht gestatet (htp://www.w3.org/TR/xmlschema-2/#byte).

2

ƒ nonNegativeInteger speichert Zahlenwerte, deren minInclusive-Angabe auf 0 gesetzt wurde, d. h., posiive Ganzahlen einschließlich der Null (htp://www.w3.org/TR/xmlschema-2/#nonNegaiveInteger). ƒ unsignedLong speichert posiive Ganzzahlen einschließlich der Null, deren maxInclusive auf 18446744073709551615 festgesetzt ist. Führende Nullen sind nicht erlaubt (htp://www.w3.org/TR/xmlschema2/#unsignedLong). ƒ unsignedInt speichert posiive Ganzzahlwerte einschließlich der Null, deren maxInclusive auf 4294967295 festgesetzt ist. Führende Nullen sind nicht erlaubt (htp://www.w3.org/TR/xmlschema-2/#unsignedInt). ƒ unsignedShort speichert posiive Ganzzahlwerte einschließlich der Null, deren maxInclusive auf 65535 festgesetzt ist. Führende Nullen sind nicht erlaubt (htp://www.w3.org/TR/xmlschema-2/#unsignedShort). ƒ unsignedByte speichert posiive Ganzzahlwerte mit Null, deren maxInclusive auf 255 festgesetzt ist. Führende Nullen sind nicht erlaubt (htp:// www.w3.org/TR/xmlschema-2/#unsignedByte). ƒ positiveInteger speichert posiive Ganzzahlwerte ohne Null, deren minInclusive auf 1 festgesetzt ist. Ein führendes Pluszeichen oder führende Nullen sind nicht erlaubt (htp://www.w3.org/TR/xmlschema2/#posiiveInteger). Mit Hilfe der abgeleiteten Typen lässt sich eine genauere Einschränkung der im vorherigen XML-Instanzdokument verwendeten Elemente erreichen. Da die Tarifnamen Zeichenketten ohne Leerzeichen darstellen, lassen sie sich genauer auch mit dem Typ normalizedString speichern. Gleiches gilt für den Anrutyp. Da dieser allerdings nur zwei Buchstaben speichert, lässt sich hier alternaiv der Datentyp token verwenden. Die Entscheidung für normalizedString oder token ist nicht von der Zeichenketenlänge abhängig, sondern eher davon, dass man in der DTD auch für solche ein- oder zweielemenigen Zeichenketen eher token verwenden würde. Das bisher als posiive Ganzzahl gespeicherte Jahr des Attributs lässt sich auch genauer mit gYear angeben, da dieser Typ explizit nur Jahres- und keine weiteren Zeitangaben speichert.

80

2. Datentypen und Strukturen

2













21_02.xsd: Vordeinierte, abgeleitete Datentypen

2. 1. 3.  Listentypen und Schlüssel Die Listentypen werden durch die aus XML und in der DTD deinierbaren Datentypen IDREFS, NMTOKENS und Entities besimmt. Sie stellen jeweils eine Liste dar, deren ein-

zelne Werte durch kein Trennzeichen wie z. B. ein Komma und ebenfalls durch keinen Tag wie z. B. das aus HTML bekannte

-Element getrennt werden. Da sie keine Leerzeichen enthalten, handelt es sich um normalisierte Zeichenketen, die jede für sich ein einzelnes Listenelement bilden. Daher sind diese Datentypen nicht nur von normalizedString, sondern insbesondere von token abgeleitet, ein ebenfalls in XML bekanntes Konstrukt für solchermaßen ausgestatete Zeichenketen. Ob man sich unbedingt für die Angabe von Listen auf diese Datentypen stützen sollte, ist eine wohl diskussionswürdige Frage. Auf der einen Seite bieten alle drei Datentypen genau die Eigenschaten in XML Schema an, die sie bereits in der DTD anbieten. Dies hat den Efekt, dass Regeldokumente in DTD-Syn-

81

2. Datentypen und Strukturen

2

tax leicht in XML-Strukturen übertragen werden können und diese Merkmale besonders deutlich im transformierten XML Schema-Dokument hervortreten. Mit besonderem Blick auf die beiden Datentypen ID, IDREF und der für diesen Abschnit besonders interessante Listendatentyp IDREFS eignen sie sich darüber hinaus dazu, Schlüssel und Bezüge einzurichten. Dies wird im XML Schema-Umfeld unter idenitätsbeschränkenden Strukturen zusammengefasst und wartet mit anderen Konzepten auf, die später noch in einem eigenen Kapitel gezeigt werden. Auf der anderen Seite sind diese Datentypen und die damit verbundenen Mechanismen und Einschränkungen bekannt. Dazu zählt z. B. die Einschränkung, dass für Werte von ID nur XML-Namen eingesetzt werden können. Dies bedeutet wiederum, dass sie gerade nicht mit einer Zahl beginnen dürfen und deshalb im nachfolgenden Beispiel auch keine Möglichkeit besteht, nur eine einfache Primärschlüsselzahl ohne vorgestellten Buchstaben oder ohne Präix zu verwenden. Dieser Buchstabe ist auch schon deswegen nöig, weil für ein Dokument nur eine begrenzte Anzahl an ID-Werten zur Verfügung steht und der gleiche Schlüsselwert wie z. B. eine 12 als Primärschlüsselwert nicht für mehrere Elemente autreten kann. Dies gilt nicht nur für das gleiche Element, sondern sogar für Elemente mit anderem Namen, d. h., gleiche Primärschlüsselwerte für Tarif und Kundennummer in einem Dokument sind nicht zulässig.

string

normalized String

token

language

ID

name

NMTOKEN

NCName

NMTOKENS

IDREF

ENTITY

IDREFS

Abbildung 2.3: Listentypen

82

ENTITIES

2. Datentypen und Strukturen

Diese Vor- und Nachteile sollten immer berücksichigt werden, bevor man diese herkömmlichen Strukturen einsetzt und nicht sofort auf die anspruchsvolleren, aber natürlich auch in der Anwendung komplizierteren Verfahren der Idenitätsbeschränkung von XML Schema zurückgreit. Dazu aber, wie bereits gesagt, später noch mehr Details und verschiedene Beispiele. Für den Moment mag das Wissen genügen, dass diese Datentypen überhaupt in XML Schema vorhanden sind und dass man insbesondere Listen mit ihnen konstruieren kann. Allgemein wird auch hier empfohlen, dass man diese Datentypen für Listenkonstrukionen in Elementen eher meidet und statdessen auf die später vorgestellten XML Schema-Konstrukionen ausweicht. Das hauptsächlich deshalb, weil man natürlich auf die Elemente einer solchen, durch Leerzeichen getrennten Liste nicht mit XPath zugreifen und daher auch solche Listen nicht ordentlich verarbeiten und z. B. wieder in

-Elementen auf einer Webseite ausgeben kann. Nachteilig wirkt sich zudem aus, dass nur leerzeichenlose Zeichenketen abgespeichert werden können, was nur auf sehr wenige Ausnahmen in Dokumenten – wie hier z. B. standardisierte Abkürzungen oder Namen – zutrefen dürte. Insgesamt empfehlen daher viele Autoren, diese Datentypen ausschließlich für Listen in Atributen einzusetzen, die ansonsten auch keine anderen Listenformen zulassen. Als Beispiel für die Verwendung dieser Datentypen soll eine Rechnung benutzt werden, wobei die Rechnung selbst in einem ID -Atribut einen Primärschlüsselwert besitzt, der seinerseits wiederum von jedem Posten aus über ein IDREF-Atribut aufgerufen wird. Innerhalb der Rechnung speichert man zusätzlich eine Liste der Primärschlüsselwerte eines jeden Postens, wobei diese Liste in Form einer IDREFS-Liste organisiert wird. Dies geschieht durch normalisierte Zeichenketen in einem Atribut. Die zugehörigen Primärschlüsselwerte liegen in einem entsprechenden ID -Atribut in jedem Posten. Zum Schluss erfolgt noch eine Aulistung sämtlicher benutzter Tarife in einem einzigen Atribut für das RechnungElement in Form einer Token-Liste.

22,32 12 p

Frühstück

83

2

2. Datentypen und Strukturen

2,85

Mittagspause 9,37

Abendessen 8,7

2

Mondschein1 1,4

21_03.xml: Rechnung mit Schlüssel und Bezügen sowie Liste

In der Element-Übersicht erhält man folgende Darstellung. Die allgemeinen Rechnungsinformaionen liegen entweder in Atributen für das Element Rechnung oder in direkt untergeordneten Elementen vor. Die einzelnen Posten wiederum beinden sich in ebenfalls als Kind-Element organisierten Posten-Elementen, die jeweils den entsprechenden Tarif und die Einzelkosten für diesen Tarif als Kind-Elemente enthalten und mehrfach autreten können.

Abbildung 2.4: Rechnungsübersicht mit Schlüsseln und Bezügen

84

2. Datentypen und Strukturen

Diese Schlüssel, Bezüge und Listen würde man in einer herkömmlichen DTD, die noch einmal als Vergleich angeführt wird, folgendermaßen modellieren: Für jedes ID -Atribut verwendet man gerade nicht CDATA als Angabe für ein Inhaltsmodell des Atributs, sondern ID. Analog verläut die Modellierung für die beiden Atribute mit den Datentypen IDREF und IDREFS.







21_03.dtd: Deiniion von ID, IDREF und IDREFS sowie Liste

Die Abbildung 2.5: Schlüssel und Bezüge soll noch einmal verdeutlichen, wie die jeweiligen Atribute und ihre Werte wirken. Aus der Liste der Posiionsprimärschlüssel im Atribut P _ IDREFS verläut für jeden Listeneintrag ein Bezug zu einem Schlüssel eines Postens, der wiederum in einem P _ ID -Atribut gespeichert ist. Für diesen wie für den Primärschlüssel der gesamten Rechnung steht in einem Atribut P _ ID bzw. R _ ID ein entsprechendes Atribut mit einem geeigneten Datentyp und Wert als Bezugsziel zur Verfügung. Interessant ist für die Betrachtung der Modellierung von Listen zunächst nur die P _ IDREFS-Liste und die Tarife-Liste, da hier die beiden Listendatentypen IDREFS und NMTOKENS zum Einsatz kommen. Für die Verwendung eines IDREFS-Atribut muss allerdings zwangsläuig auch ein entsprechendes Bezugsziel in Form eines ID -Atributs bereitstehen, sodass diese ebenfalls Gegenstand der Betrachtung werden.

85

2

2. Datentypen und Strukturen

2

Mehrpfadige Verweise

22,32 12 p

Frühstück 2,85

Mittagspause 9,37

Abendessen 8,7

Mondschein1 1,4

Einpfadige Verweise

Abbildung 2.5: Schlüssel und Bezüge

In XML Schema nun kann man die notwendigen, aber nicht zum eigentlichen Objekt der Betrachtung gehörenden Atribute für die Speicherung der Primärschlüsselwerte und der einfachen Bezüge wie in einer herkömmlichen DTD mit den gleich lautenden Datentypen als Atribute für das Rechnung-Element speichern. Für die beiden Listen gilt nun das Gleiche, da hier die durch Aulistung abgeleiteten und vordeiniert zur Verfügung stehenden Listendatentypen IDREFS und NMTOKENS verwendet werden können.



86

2. Datentypen und Strukturen



2













22_03.xsd: Deiniion von ID, IDREF und IDREFS sowie Liste

Zum Schluss soll noch darauf hingewiesen werden, dass natürlich auch Elemente als Listen über die Listendatentypen mit einem Datentyp versehen werden können. Alternaiv häte man sich auch vorstellen können, die Tariliste gerade nicht in einem Atribut, sondern in einem speziellen Tarife-Element auszuzeichnen. Frühstück Mittagspause Abendessen Mondschein1

87

2. Datentypen und Strukturen

2

Die Modellierung erfolgt dann über eine später noch darzustellende Ableitung durch Auflistung mit der Angabe, welchen Datentyp diese Liste haben soll. In diesem Fall handelt es sich um NMTOKENS.



2. 2.  Deklaraion einfacher Typen Die Verwendung der vordeinierten Datentypen ist genauso einfach wie in einer Datenbank oder einer Programmiersprache: Man rut sie einfach bei der Deklaraion eines Elements oder eines Atributs auf und übernimmt ihre Eigenschaten in das Dokument für die jeweilige Komponente. Möchte man, wie es in Datenbanken üblich ist, genauere Eigenschaten vorgeben, so erstellt man einen eigenen Datentyp durch zwei grundlegende Techniken, die miteinander kombiniert werden können: ●

Fasseten: Durch den Einsatz der fundamentalen (vorgegebenen) und einschränkenden (benutzerdeinierten) Fasseten lassen sich genaue Angaben machen, welche Eigenschaten ein Datentypen haben soll, damit gülige und ungülige Werte in einem Instanzdokument erkannt werden können. Dabei gibt es eine Reihe von Atributen, die man bei der Deiniion eines Datentyps aufrufen kann und mit denen solche einschränkenden Eigenschaten wie Länge oder obere und untere Schranken festgelegt werden können. Besonders anspruchsvolle Bedingungen lassen sich über reguläre Ausdrücke realisieren.

●

Ableitungstypen: Mit Hilfe der Ableitungen durch Einschränkung, Aulistung und Vereinigung lassen sich die beispielhate Wertvorgaben in Listenform bzw. in kombinierten Listen oder in den gerade beschriebenen Einschränkungen erzeugen, mit denen der Wertebereich oder der lexikalische Bereich eines Datentyps genauer besimmt werden kann.

88

2. Datentypen und Strukturen

2. 2. 1.  Fasseten Mit den Fasseten lassen sich Datentypen genauer beschreiben, wobei sie einige typische Eigenschaten wie Länge, obere und untere Schranken (einschließend und nicht einschließend) oder Anzahl der Vor- und Nachkommastellen etc. umfassen. Sie eignen sich für die Beschreibung von Datentypen in der Art, wie es in Datenbanken üblich ist, bieten aber einige weitere Möglichkeiten, wie z. B. die Verwendung von regulären Ausdrücken für die Charakterisierung des Wertebereichs eines Datentyps. Wie Abbildung 2.6 nahe legt, lassen sich Fasseten in zwei Bereiche unterteilen, wobei die ersten, also die grundlegenden oder auch fundamentalen Fasseten, dem Datentyp bereits mitgegeben sind und die zweiten, also die einschränkenden Fasseten, vom Benutzer bzw. vom Autor des Schema-Dokuments eingesetzt und aufgerufen werden können. Nicht alle Datentypen lassen sich mit allen Fasseten verbinden. So ist es natürlich nicht möglich, die Anzahl der Vor- und Nachkommastellen für Zeichenketendatentypen anzugeben. Die genaue Angabe, welche Fasseten für welchen Datentyp in Frage kommen, indet man ebenso wie eine genaue Beschreibung der einzelnen Fasseten in der Referenz am Ende des Buchs.

Abbildung 2.6: Fasseten für die Beschreibung von Datentypen

89

2

2. Datentypen und Strukturen

2. 2. 1. 1  Grundlegende Fasseten

2

Die grundlegenden Fasseten4 repräsenieren Eigenschaten eines Datentyps, die sich vom Benutzer nicht beeinlussen lassen, sondern bereits für jeden vordeinierten Datentyp a priori vorhanden sind. Folgende fünf sind vorhanden: ●

equal: Für jeden Datentyp gilt die Gleichheitseigenschat in der Form, dass zwei Wer-

te aus seinem zugehörigen Wertebereich nur gleich oder ungleich sein können, aber nicht beides gleichzeiig. Sie sind zudem auch gleich, wenn sie jeweils zu einem driten Wert gleich sind (htp://www.w3.org/TR/xmlschema-2/#equal). ●

ordered: In einem Wertebereich eines Datentyps lassen sich verschiedene Ordnungsbeziehungen feststellen, die sich in die beiden Typen total oder pariell auteilen lassen. Eine parielle Ordnung lässt sich inden, sobald die Ordnungsbeziehung die Eigenschaten der Irrelexivität (ein Wert aus einem Wertebereich hat zu sich selbst keine Ordnung), der Asymmetrie (für zwei Werte gilt nur eine Ordnung und nicht verschiedene, d. h., sie können nicht gleichzeiig größer und kleiner sein) und der Transiivität (die Ordnung, die zwei Werte auf einen driten Wert haben, gibt eindeuigen Aufschluss über die Ordnung der beiden Werte) aufweisen (htp://www.w3.org/TR/ xmlschema-2/#rf-ordered).

●

bounded: Sobald in einem Wertebereich ein Wert eine obere/untere inklusive/exklu-

sive Schranke ist, besitzt der jeweilige Datentyp die Eigenschat, beschränkt zu sein. Dabei ist nicht gemeint, dass man eine solche Schranke vorgeben muss oder kann, wie es mit Hilfe der einschränkenden Fasseten geschehen kann, sondern, dass der Datentyp überhaupt die Möglichkeit besitzt, beschränkt zu werden. Logische Werte sind dies z. B. niemals (htp://www.w3.org/TR/xmlschema-2/#rf-bounded). ●

cardinality: Die Anzahl der Werte in einem Wertebereich kann endlich oder abzählbar unendlich sein. Die Möglichkeit, dass Wertebereiche auch überabzählbar unendlich sein können, wird in der Datentypen-Speziikaion nicht berücksichigt. Jeder Datentyp besitzt also einen Wert für die Kardinaliät aus dem Wertepaar {endlich, abzählbar unendlich} (htp://www.w3.org/TR/xmlschema-2/#rf-cardinality).

●

numeric: Sollten die Werte eines Wertebereichs für Quanitäten stehen und soll man

sie in einem mathemaischen Zahlensystem abbilden können, besitzt der jeweilige Datentyp die Eigenschat, numerisch zu sein. Alle anderen sind nicht numerisch, so4

90

Vgl.: htp://www.w3.org/TR/xmlschema-2/#rf-fund-facets

2. Datentypen und Strukturen

dass diese Fassete Werte aus dem Wertepaar {numerisch, nicht numerisch} rekruiert (htp://www.w3.org/TR/xmlschema-2/#rf-numeric).

2. 2. 1. 2  Einschränkende Fasseten Während die zuvor vorgestellten fundamentalen Fasseten lediglich als Eigenschaten für die einzelnen Datentypen vorhanden sind und entweder erfüllt oder nicht erfüllt waren oder aus einem vorgegebenen Wertebereich einen Wert übernahmen, können über die einschränkenden Fasseten5 spezielle Charakterisika eines Datentyps angegeben werden.

Lothmann GmbH Büromaschinen- Büroorganisation 653.26

Unterrather Str. 182 40468 Düsseldorf

211 563480

Zwinger Großschlachterei 252.49

Am Kuhlenfeld 48 47199 Duisburg

5

Vgl.: htp://www.w3.org/TR/xmlschema-2/#rf-facets

91

2

2. Datentypen und Strukturen

2

2841 524743

22_01: Kundenliste

Abbildung 2.7: Elemente der Kundenliste

92

2. Datentypen und Strukturen

Ä Allgemeine Syntaxregeln Die einzelnen Fasseten werden innerhalb einer Element-Deklaraion, also innerhalb des element-Containers aufgerufen. Da sie einen Datentyp näher beschreiben, platziert man sie zudem noch in einen simpleType-Container, der dann zunächst die Datentypbasis enthält, die näher beschrieben wird. Diese gibt man durch das Element restriction an. Es erhält im Atribut base den zugrunde liegenden Datentyp und als Inhalt eine für diesen Datentyp gülige Fassete. Nicht alle Fasseten sind für alle Datentypen gülig. Eine Tabelle mit allen Datentypen und ihren jeweiligen Fasseten indet man in der Referenz des Buchs. Als typische Beispiele seien hier die Fasseten minInclusive oder maxInclusive genannt, welche Werte beschreiben, die als untere oder obere erreichbare Schranke angegeben werden können. Bei diesen nur für Zahlenwerte geltenden Schranken gehören die Werte selbst mit zum Wertebereich. Es ist wichig anzumerken, dass die Verwendung einer geeigneten Fassete eine Ableitung durch Einschränkung darstellt, da über die Verwendung von einschränkenden Fasseten ja gerade der Wertebereich eines Datentyps beschränkt werden kann.

Ä Längenangaben ●

length: Mit einer Angabe vom Datentyp nonNegativeInteger, demnach einer Ganzzahl einschließlich der Null, lässt sich die Länge eines Wertes angeben, wobei bei Zeichentexten dies die Anzahl der Zeichen, beim Datentyp anyURI ebenfalls die Anzahl der Zeichen und bei den Datentypen hexBinary, base64Binary bzw. davon abgeleiteten Datentypen die 8-Bit-Oktete sind, aus denen sich der jeweilige Wert zusammensetzt. Bei Listen-Datentypen gibt die Längenangabe Auskunt über die Anzahl der Listeneinträge (htp://www.w3.org/TR/xmlschema-2/#rf-length).

●

minLength: Mit einer Angabe vom Datentyp nonNegativeInteger, demnach einer Ganzzahl einschließlich der Null, lässt sich die minimale Länge eines Wertes angeben, wobei sich dies bei Zeichentexten auf die Anzahl der Zeichen, beim Datentyp anyURI ebenfalls auf die Anzahl der Zeichen und bei den Datentypen hexBinary, base64Binary bzw. davon abgeleiteten Datentypen auf die 8-Bit-Oktete bezieht, aus denen sich der jeweilige Wert zusammensetzt (htp://www.w3.org/TR/xmlschema-2/#rfminLength).

93

2

2. Datentypen und Strukturen

●

maxLength: Mit einer Angabe vom Datentyp nonNegativeInteger, demnach einer Ganzzahl einschließlich der Null, lässt sich die maximale Länge eines Wertes angeben, was sich bei Zeichentexten auf die Anzahl der Zeichen, beim Datentyp anyURI ebenfalls auf die Anzahl der Zeichen und bei den Datentypen hexBinary, base64Binary bzw. davon abgeleiteten Datentypen auf die 8-Bit-Oktete bezieht, aus denen sich der jeweilige Wert zusammensetzt. Bei Listen-Datentypen gibt die Längenangabe die Anzahl der Listeneinträge an (htp://www.w3.org/TR/xmlschema-2/#rf-maxLength).

2

Die gemeinsame allgemeine Syntax für die drei Längenangaben lautet:

Inhalt: (annotation?)

Über das Atribut ixed legt man für die Fassete length fest, ob die angegebene Länge tatsächlich eingehalten werden soll (mindestens und maximal n Zeichen bei TRUE) oder ob es sich nur um einen maximalen Wert handelt (FALSE). Dies bedeutet, dass bei der Vorgabe einer maximalen Länge nur darauhin überprüt wird, ob die Zeichenketenlänge den angegebenen Wert nicht übersteigt. Dies steht ganz im Gegensatz zu einer ixierten Länge, bei der nur solche Zeichenketen mit der angegebenen Länge korrekte Werte darstellen. Für die beiden Fasseten minLength und maxLength legt man dagegen über das Atribut ixed fest, ob Typen mit diesem Typ als Basistyp einen anderen Wert für minLength angeben können (FALSE) oder nicht (TRUE). Das besimmt, ob ein Überschreiben möglich ist, wenn bei globalen Datentypdeiniionen auf einen mit diesen Fasseten beschränkten Datentyp zurückgegrifen wird. Die in diesem Abschnit gezeigten Beispiele stellen alle lokale Deklaraionen dar, d. h., die Eigenschaten des Datentyps werden direkt für ein gegebenes Element eingeführt. Es besteht aber auch die Möglichkeit, wie in einem späteren Abschnit zu sehen sein wird, neue Datentypen in globalen Deklaraionen festzulegen. Für solche ist es wichig, ob bei einer weiteren Ableitung Schranken, die über Fasseten festgelegt wurden, weiterhin Bestand haben sollen oder nicht. Zum Schluss gibt es noch folgende, leicht verständliche Regel: Bei gleichzeiiger Angabe von minLength und maxLength muss gelten minLength DBMS_XMLSCHEMA.DELETE_CASCADE_FORCE); */ END; 102_02.sql: Registrieren eines XML Schemas

10 414

10. DB-Datenmodellierung und XSLT-Transformation

Das registrierte XML Schema kann für die Deiniion von XML-Spalten, Variablen/Parametern oder sogar Tabellen und Sichten zum Einsatz kommen. Im nächsten Beispiel folgen verschiedene Konzepte, die jeweils für sich genommen bereits eigene Kapitel füllen könnten. Zunächst erstellt man die Tabelle maliste _ x1, welche eine so genannte XMLType-Tabelle auf Basis von dem gerade registrierten XML Schema darstellt. Sie akzepiert ausschließlich zu diesem Schema passende Daten und speichert auch keine anderen Daten. Sie hat eine Spalte mit dem unschönen Standardnamen sys _ nc _ rowinfo$. CREATE TABLE maliste_x1 OF XMLTYPE XMLSCHEMA „http://www.ruhrfon.biz/mitarbeiterliste.xsd“ ELEMENT „Mitarbeiterliste“; 102_03.sql: Erstellung einer XMLType-Tabelle

Die Tabelle füllt man dann über zwei unterschiedliche Techniken. Eine drite – nämlich der Einsatz einer XMLType-Variablen – folgt später noch. Man kann sehr leicht aus relaionalen Daten über SQL XML-Daten erstellen, indem man die sogenannten SQL/XML-Funkionen einsetzt. Dies ist ein ISO-Standard, der in Oracle und bspw. auch in IBM DB2 umgesetzt ist. Die Funkion XMLElement() erstellt ein XML-Element; XMLAttributes() kann mehrere Atribute erstellen; XMLForest() kann in analoger Syntax mehrere Geschwister-Elemente erstellen; und XMLAgg() gruppiert Elemente (teilweise ist zusätzlich GROUP BY notwendig). Die Abfrage liefert wohlgeformtes XML, das darüber hinaus auch noch gülig für das XML Schema ist und daher in der Tabelle gespeichert werden kann. INSERT INTO maliste_x1 VALUES ( (SELECT XMLElement(„Mitarbeiterliste“, XMLAgg( XMLElement(„Mitarbeiter“, XMLElement(„Name“, XMLAttributes(M_Anrede AS „Anrede“), XMLForest(M_Vorname AS „Vorname“, M_Nachname AS „Nachname“) ), XMLElement(„Funktion“, M_Funktion) ) )) AS MaListe FROM mitarbeiter WHERE M_Nr < 20) ); 102_03.sql: XML-Erstellung über SQL/XML-Funkionen

415

10

10. DB-Datenmodellierung und XSLT-Transformation

Eine einfachere, aber wenig beeindruckende Alternaive, ist es, XML-Zeichenketen direkt im als Konstruktor fungierenden XMLType-Schlüsselwort vorzugeben. So fügt man über die vorherige Abfrage 19 Datensätze aus der MITARBEITER-Tabelle als einen einzigen XMLDatensatz und nun noch einen weiteren Datensatz ein. Damit noch vor dem eigentlichen Speichervorgang auf Schema-Güligkeit geprüt wird, ergänzt man den XMLType um den Methodenaufruf createSchemaBasedXML(). Dies erzeugt typisiertes XML. In einer Variablen bspw. könnte man dann nur gülige Daten speichern. INSERT INTO maliste_x1 VALUES ( XMLType( ‚

Marco Scheffchen

Geschäftsführer

‘ ).createSchemaBasedXML(‚http://www.ruhrfon.biz/ mitarbeiterliste.xsd‘) ); -- Abfragen SELECT sys_nc_rowinfo$ AS MaListe FROM maliste_x1; 102_03.sql: Verwendung einer XMLType-Tabelle

10. 2. 2. 2  XMLType-Datentyp und seine Methoden Es stehen für die Arbeit mit XML Schema die folgenden Unterprogramme zur Verfügung. Man kann sie direkt an solchermaßen typisierten Variablen, Spalten oder Parametern verwenden. Teilweise gibt es auch zusätzliche SQL-Funkionen mit ähnlicher Funkionalität. In einer ersten Gruppe beinden sich Methoden, die XML Schema berücksichigen oder nicht berücksichigen.

10 416

10. DB-Datenmodellierung und XSLT-Transformation

●

createSchemaBasedXML(): Erzeugt eine XMLType-Instanz mit Schema-Verknüp-

fung. MEMBER FUNCTION createSchemaBasedXML( schema IN varchar2 := NULL ) RETURN XMLType

●

createNonSchemaBasedXML(): Erzeugt eine XMLType-Instanz ohne Schema-Ver-

knüpfung. MEMBER FUNCTION createNonSchemaBasedXML RETURN XMLType

Eine zweite Gruppe verwendet ein angemeldetes XML Schema für die Validierung und liefert/setzt den Güligkeitsstatus einer XMLType-Instanz. ●

schemaValidate(): Validiert die Eingabedaten einer XMLType-Instanz auf Basis ei-

nes XML Schemas. MEMBER PROCEDURE schemaValidate

●

isSchemaValidated(): Prüt, ob die XMLType-Instanz validiert wurde. MEMBER FUNCTION isSchemaValidated RETURN number

●

setSchemaValidated(): Setzt das posiive Validierungsergebnis von vorneherein fest, um eine Validierung zu verhindern. MEMBER PROCEDURE setSchemaValidated(lag IN BINARY_INTEGER := 1)

●

isSchemaValid(): Prüt, ob die XMLType-Instanz gülig ist. MEMBER FUNCTION isSchemaValid( schemaurl IN VARCHAR2 := NULL, elem IN VARCHAR2 := NULL) RETURN number

Eine drite Gruppe liefert nützliche Informaionen bei einem verwendeten XML Schema wie den Status, ob ein XML-Dokument mit einem XML Schema verknüpt ist oder die URL des Schemas. ●

isSchemaBased(): Liefert 1 zurück, wenn die XMLType-Instanz auf einem Schema

basiert, oder 0, wenn sie allein steht. MEMBER FUNCTION isSchemaBased RETURN number

10 417

10. DB-Datenmodellierung und XSLT-Transformation

●

getSchemaURL(): Liefert die XML Schema-URL, wenn eine vorhanden ist. MEMBER FUNCTION getSchemaURL RETURN varchar2

●

getRootElement(): Liefert das Wurzelelement oder NULL bei einem Fragment. MEMBER FUNCTION getRootElement RETURN varchar2

●

getNamespace(): Liefert den Namensraum des Wurzelelements eines schema-basierten Dokuments. MEMBER FUNCTION getNamespace RETURN varchar2

Für das nächste Beispiel erstellt man eine Tabelle, die weniger beeindruckend als die vorherige ist. Sie enthält eine XMLType-Spalte neben anderen Spalten, die durch „herkömmliche“ Datentypen eingeschränkt sind. Die einfachste Form einer solchen Spalte stellt untypisiertes XML dar. So eine Spalte prüt nur auf Wohlgeformtheit und würde sich bspw. in einem Import-Szenario eignen, in dem zunächst eingehende Daten zur späteren Prüfung erst einmal gespeichert werden. Im aktuellen Fall folgt allerdings der Hinweis, dass die XMLType-Spalte sich auf ein besimmtes XML Schema bezieht. CREATE TABLE maliste_x2 ( MAL_Nr NUMBER, MAL_Datum DATE, MAL_Inhalt XMLType) XMLTYPE COLUMN MAL_Inhalt ELEMENT „http://www.ruhrfon.biz/mitarbeiterliste.xsd #Mitarbeiterliste“; 102_04.sql: Tabelle mit XMLType-Spalte und weiteren Spalten

Um auch in dieser Tabelle XML-Daten zu speichern, erstellen wir als Alternaive zunächst eine XMLType-Variable, welche sich auf das registrierte XML Schema bezieht. Sie wird über SELECT...INTO und die SQL /XML-Funkionen mit dem passenden XML gefüllt und schließlich in einem INSERT-Befehl genauso verwendet wie alle anderen Variablen bzw. Ausdrücke. Allerdings prüt man zunächst, ob die Regeln aus dem XML Schema auch für die abgerufenen Daten gelten, bevor die Einfügeoperaion durchgeführt wird. DECLARE v_Mitarbeiterliste XMLType; BEGIN

10 418

10. DB-Datenmodellierung und XSLT-Transformation

-- Daten laden SELECT XMLElement(„Mitarbeiterliste“, XMLAgg( XMLElement(„Mitarbeiter“, XMLElement(„Name“, XMLAttributes(M_Anrede AS „Anrede“), XMLForest(M_Vorname AS „Vorname“, M_Nachname AS „Nachname“) ), XMLElement(„Funktion“, M_Funktion) ) )) AS MaListe INTO v_Mitarbeiterliste FROM mitarbeiter; v_Mitarbeiterliste := v_Mitarbeiterliste. createSchemaBasedXML( ‚http://www.ruhrfon.biz/mitarbeiterliste.xsd‘); -- XML-Daten validieren ... v_Mitarbeiterliste.schemaValidate(); IF v_Mitarbeiterliste.isSchemaValidated() = 1 THEN -- ... und gemeinsam mit anderen Daten einfügen INSERT INTO maliste_x2 VALUES (1, ‚01.05.2004‘, v_Mitarbeiterliste ); END IF; END; 102_04.sql: Verwendung einer XMLType-Variable

Für eine als XMLType angegebene Spalte stehen wie auch für Variablen oder Parameter innerhalb von PL/SQL verschiedene SQL-Funkionen zur Validierung mit XML Schema (XMLIsValid()), zur Abfrage mit XPath oder XQuery (extract() und existsNode()) oder auch zur Transformaion mit XSLT (XMLTransform()) zur Verfügung. SELECT Mal_Nr, Mal_Inhalt FROM maliste_x2; 102_04.sql: Abfragen einer XML-Spalte

10 419

10. DB-Datenmodellierung und XSLT-Transformation

10. 2. 2. 3  Data Dicionary-Sichten Eine Reihe von Sichten informieren über vorhandene XML Schema-Dateien. Sie werden kurz aufgelistet. Wie bei anderen Sichten auch erfolgt bei den Sichten, die das Wort USER im Namen tragen, eine automaische Filterung nach dem angemeldeten Benutzer. Die Spaltennamen sind leicht verständlich. ●

USER _ XML _ SCHEMAS: Alle registrierten XML Schema-Dokumente in Besitz des Be-

nutzers. ●

ALL _ XML _ SCHEMAS: Alle registrierten XML Schema-Dokumente, die vom aktuellen Benutzer genutzt werden können.

●

USER _ XML _ TABLES: Alle XMLType-Tabellen in Besitz des aktuellen Benutzers.

●

ALL _ XML _ TABLES: Alle XMLType-Tabellen, die vom aktuellen Benutzer genutzt

werden können. ●

USER _ XML _ TAB _ COLS: Alle XMLType-Tabellenspalten in den Tabellen des aktu-

ellen Benutzers. ●

ALL _ XML _ TAB _ COLS: Alle XMLType-Tabellenspalten, die vom aktuellen Benutzer

genutzt werden können. ● ●

USER _ XML _ VIEWS: Alle XMLType-Sichten in Besitz des aktuellen Benutzers. ALL _ XML _ VIEWS: Alle XMLType-Sichten, die vom aktuellen Benutzer genutzt wer-

den können. ●

USER _ XML _ VIEW _ COLS: Alle Spalten von XMLType-Sichten in Besitz des aktuellen

Benutzers. ●

ALL _ XML _ VIEW _ COLS: Alle Spalten von XMLType-Sichten, die vom aktuellen Be-

nutzer genutzt werden können. Ein Startpunkt bei der Verwendung der Sichten kann bspw. SELECT table _ name, xmlschema, element _ name FROM user _ xml _ tables; sein, der die Speichertabellen von XML Schema-basierten Daten, die URL des XML Schemas und das Wurzelelement angibt.

10 420

10. DB-Datenmodellierung und XSLT-Transformation

10. 2. 3.  MS SQL Server Der MS SQL Server bietet, wie die Tabelle zuvor gezeigt hat, eine umfangreiche Fülle an Techniken für die Speicherung, Zerlegung, Erzeugung und Verarbeitung von XML-Daten. Da T-SQL nicht so umfangreich ist wie PL/SQL in Oracle, ist der Funkionsumfang geringer. Allerdings sind einige Techniken syntakisch viel einfacher gelöst. Zentral ist dabei der Datentyp XML, für dessen erfolgreichen Einsatz es verschiedene Prozeduren und Funkionen gibt. Wir konzentrieren uns in diesem Abschnit auf den Themenbereich XML Schema und hier wiederum auf eine kurze Darstellung der wichigsten Aspekte. Weitere Informaionen inden Sie in unserem Buch „MS SQL Server –XML und SOAP Web Services“ (ebenfalls von Comelio Medien).

10. 2. 3. 1  XML Schema registrieren und verwalten Um ein XML Schema zu speichern, welches aus einer Zeichenkete oder einer Datei über die Anweisung OPENROWSET eingelesen wird, verwendet man einen speziellen CREATEBefehl. Neben dem zu erwartenden Begrif XML SCHEMA enthält er zudem auch noch COLLECTION, da es möglich ist, mehrere XML Schema-Dokumente in einem, d. h. mehrere xs:schema-Elemente in einer Sammlung, zu besitzen. Im Normalfall dürte man allerdings unter einem Namen in der Datenbank nur ein einziges XML Schema und nicht gleich eine ganze Sammlung von ähnlichen Dokumenten speichern. Im Parameter sql _ identiier trägt man einen Namen ein, unter dem dieses XML Schema dann verfügbar sein wird, während man im opionalen Parameter relational _ schema das Datenbank-Schema eintragen kann. Sollte dieser Parameter fehlen, wird das XML Schema einfach im Standardschema gespeichert. CREATE XML SCHEMA COLLECTION [

. ]sql_identiier AS Expression

Ist ein XML Schema gespeichert, besteht die Möglichkeit, es nicht nur zu löschen und neu zu erstellen, sondern auch zu ändern. Dabei lässt sich eine neue Komponente zu einem bestehenden XML Schema oder gleich ein ganz neues XML Schema zu einer Sammlung hinzufügen. Die letzte Möglichkeit dürte in den meisten Fällen nicht so häuig sein, sofern keine Sammlungen mit mehreren XML Schema-Angaben genutzt werden. Als Parameter enthält relational _ schema wieder das DB-Schema, in dem sich nun in diesem Fall das bereits vorhandene XML Schema beindet, welches über den verplichtenden Parameter sql _ identiier angesprochen werden kann. An das Schlüsselwort ADD schließt sich

421

10

10. DB-Datenmodellierung und XSLT-Transformation

dann genauso ein XML Schema an wie bei der CREATE-Anweisung. Sofern ein vorhandenes XML Schema aktualisiert werden soll, enthält es das gleiche xs:schema-Element. Sofern dagegen ein neues XML Schema in der Sammlung angehängt werden soll, ist dies ein neues xs:schema-Element. ALTER XML SCHEMA COLLECTION [ relational_schema. ]sql_identiier ADD ‚Schema Component‘

Schließlich möchte man auch noch ein einmal in der Datenbank gespeichertes XML Schema löschen können. Dies ist gerade auch dann notwendig, wenn der ALTER-Befehl für eine grundlegende Änderung nicht mehr ausreicht und es statdessen einfacher ist, das XML Schema zu löschen und geändert neu zu speichern. In diesem Fall muss natürlich ausdrücklich berücksichigt werden, dass Objekte, die das XML Schema referenzieren, eine Löschung verhindern. DROP XML SCHEMA COLLECTION [ relational_schema. ]sql_identiier

Um alle drei Anweisungen zu zeigen, soll das folgende sehr kurze Datenmodell in XML Schema-Syntax in der Datenbank gespeichert werden. Da es sich dabei letztendlich um eine XML-Datei handelt, kann man eine solche Datendeiniion sowohl als Zeichenkete (was nun für ein Beispiel einfacher ist) wie auch aus einer Textdatei laden. Die Regeln der XMLBearbeitung in T-SQL bleiben allesamt erhalten. Auch wenn ein XML Schema in der Lage ist, andere XML-Daten zu beschreiben und man durch eine solche Angabe Daten validieren kann, so handelt es sich doch nur um eine XML-Datei. In der Datei 102_05.sql wird zunächst ein Tabelle mit den Mitarbeitern der RuhrFon GmbH angelegt und in diese Tabelle 20 Datensätze eingefügt. CREATE TABLE Mitarbeiter ( „M_NR“ decimal(4,0) NOT NULL, „M_ANREDE“ nvarchar(5), „M_VORNAME“ nvarchar(20), „M_NACHNAME“ nvarchar(30), „M_FUNKTION“ nvarchar(30), CONSTRAINT PK_MNr PRIMARY KEY („M_NR“) ); 102_05.sql: Tabelle erstellen (und Daten laden)

10 422

10. DB-Datenmodellierung und XSLT-Transformation

Danach registriert man ein XML Schema, welches einfach als Zeichenkete vorgegeben wird und einen eindeuigen Bezeichner in der Datenbank erhält. Es handelt sich um die schon bekannte Mitarbeiterliste mit mehreren Mitarbeitern und Vor-/Nachname sowie einer Funkionsbezeichnung. CREATE XML SCHEMA COLLECTION MaListe AS N‘



...

‘ GO -- DROP XML SCHEMA COLLECTION MaListe 102_06.sql: XML Schema registrieren (und löschen)

10. 2. 3. 2  XML Schema verwenden Um nun zu zeigen, wie man auf der einen Seite ein gespeichertes XML Schema verwendet und wie man darüber typisiertes und damit überprübares XML erstellt, sollen im nächsten Beispiel verschiedene Szenarien vorgeführt werden. Dazu ist zunächst wichig, dass ein XML Schema in der Datenbank angemeldet ist. Es entspricht dem vorherigen eingetragenen Schema. Zunächst erstellt man eine T-SQL-Funkion, die als Rückgabewert XML im hochgeladenen Schema zurückliefert. Hier sieht man, wie der xml-Datentyp an der Stelle eines gewöhnlichen Datentyps verwendet wird. Er hat allerdings die Möglichkeit, in zwei verschiedenen Varianten zu erscheinen, wobei in diesem Fall die erweiterte Form zum Einsatz kommt und das XML Schema angegeben wird. Diese Funkion liefert also nur güliges XML zurück. Dann beschat man aus relaionalen Daten der zuvor angelegten Tabellen XML-Daten im passenden Format. Dabei wird die sehr einfache Technik, XML zu erzeugen, vom MS SQL Server genutzt. Eine gewöhnliche Abfrage ergänzt man um die Klausel FOR XML, welche verschiedene Eigenschaten besitzt. In diesem Fall gibt man die beiden häuigsten an,

10 423

10. DB-Datenmodellierung und XSLT-Transformation

nämlich den Namen für das Reihen-Element und den Namen für das Wurzelelement. Die Verschachtelung bzw. der gesamte Aubau des XML-Dokuments regeln dann die Spaltenaliasnamen, welche für jedes Element/Atribut den gesamten Pfad enthalten, den sie im Dokument bis zu den Blätern einnehmen. Handelt es sich dann um ein Atribut, so setzt man ein @-Zeichen vor den eigentlichen Atribut-Namen. Bei diesen Ausdrücken ergibt sich die Reihenfolge im resulierenden Dokument ganz einfach durch die Spaltenreihenfolge. Eine ähnliche Technik exisiert auch für den umgekehrten Weg, wenn XML-Daten wieder relaional zerlegt werden sollen. CREATE FUNCTION getMaListe (@funktion nvarchar(20)) RETURNS xml (MaListe) AS BEGIN DECLARE @MaListeXML xml (MaListe); SET @MaListeXML = ( SELECT M_Anrede AS ‚Name/@Anrede‘, M_Vorname AS ‚Name/Vorname‘, M_Nachname AS ‚Name/Nachname‘, M_Funktion AS ‚Funktion‘ FROM dbo.Mitarbeiter WHERE M_Funktion = @funktion FOR XML PATH(‚Mitarbeiter‘), ROOT(‚Mitarbeiterliste‘)) RETURN @MaListeXML END 102_06.sql: Funkion mit typisiertem Rückgabewert

Nachdem man nun diese Funkion erstellt hat, welche ja auch verschiedene XML-bezogene Konzepte bereits enthielt, geht es darum, sie aufzurufen und das ermitelte XML zunächst in eine Variable und dann in eine Tabelle(-nvariable) einzutragen. Dabei sieht man nun, wie einfach man eine als XML angegebene und mit einem XML Schema verbundene Variable und Spalte erstellen kann. -- Typisiertes XML erstellen DECLARE @MaListeXML xml (MaListe) -- Tabelle mit XML Schema-Beschränkung DECLARE @MaListeTab table( nr int identity(1,1), data xml (MaListe)); -- Typisierte Daten abrufen und speichern

10 424

10. DB-Datenmodellierung und XSLT-Transformation

SET @MaListeXML = dbo.getMaListe (‚Technik‘) -- Typisiertes XML speichern INSERT INTO @MaListeTab (data) VALUES (@MaListeXML) -- Test SELECT * FROM @MaListeTab 102_06.sql: Typisiertes XML verwenden

Im nächsten Beispiel löst man durch fehlerhat abgerufenes XML einen Validierungsfehler aus. Alle bekannten Fehlerfunkionen können zum Einsatz kommen, um auf diesen Fehler zu reagieren bzw. ihn zunächst zu bemerken und zu analysieren. DECLARE @MaListeXML xml (MaListe); BEGIN TRY SET @MaListeXML = ( SELECT M_Anrede AS ‚@Anrede‘, M_Vorname AS ‚Vorname‘, M_Nachname AS ‚Nachname‘, M_Funktion AS ‚Funktion‘ FROM dbo.Mitarbeiter FOR XML PATH(‚Mitarbeiter‘), ROOT(‚Mitarbeiterliste‘)) END TRY BEGIN CATCH SELECT ERROR_NUMBER() AS Nr, ERROR_SEVERITY() AS Schwere, ERROR_STATE() AS Status, ERROR_LINE() AS Zeile, ERROR_MESSAGE() AS Meldung END CATCH 102_07.sql : Ausnahmebehandlung für ungüliges XML

Man erhält die verschiedenen ermitelten Fehlerwerte zurück, weil ja die Hierarchie-Ebene, die vom Element Name aufgespannt wird, fehlt. Dabei erscheint im Ergebnis nur der erste Fehler und nicht etwa eine Liste mit allen möglichen Fehlern. In einigen Fällen ist dies ärgerlich oder wünschenswert, aber es entspricht dem üblichen Verhalten von Prozessoren,

10 425

10. DB-Datenmodellierung und XSLT-Transformation

dass abhängige Fehler oder Folgefehler nicht auch noch aufgelistet werden, sondern die Verarbeitung beim ersten Fehler unterbrochen und eine Fehlermeldung ausgegeben wird. Nr

Schwere

Status

Zeile

Meldung

------ -------- ------- ------ ---------------------------6905

16

3

3

XML-Überprüfung: Das ‚Anrede‘-At

tribut ist in diesem Kontext nicht zulässig. Ort: /*:Mitarbeiterliste[1]/*:Mitarbeiter[1]/@*:Anrede.

10. 2. 3. 3  Data Dicionary-Sichten In den beiden Sichten sys.xml _ schema _ collections und sys.xml _ schema _ namespaces kann man sich zum einen über die gespeicherten XML Schema-Angaben und

zum anderen über die gespeicherten Namensräume informieren. Während die erste Sicht tatsächlich das EmpList-Schema indet, liefert die zweite Sicht Informaionen zu dem im XML Schema gespeicherten Namensraum. -- Welche XML Schema sind in der DB? SELECT * FROM sys.xml_schema_collections WHERE Name = ‚MaListe‘ -- Welche Namensräume sind in der DB? SELECT * FROM sys.xml_schema_namespaces WHERE Name = ‚http://www.ruhrfon.biz/MaListe‘ 102_08.sql: Data Dicionary abfragen

Der MS SQL Server bietet insbesondere sehr anspruchsvolle Möglichkeiten, XML-basierte Web Services auf Basis von Prozeduren und Funkionen zu erstellen. Oracle hat eine ähnliche Technik, die allerdings wohl erst ab Version 12 die Funkionalität vom MS SQL Server erreicht. Unabhängig von der Perspekive, XML Schema auch in Datenbanken zu verwenden, ist die Kombinaion aus XML und relaionaler Datenbank eine echte Erweiterung des Werkzeugkastens für Import-/Export-Szenarien oder auch die XML-basierte Anwendungsentwicklung. Datenbanken wie die beiden genannten und auch IBM DB2 bieten Validierung, Erstellung und Verarbeitung (Filterung, Transformaion) direkt über die jeweilige SQL-Er-

10 426

10. DB-Datenmodellierung und XSLT-Transformation

weiterung oder über interne Programmierung mit anderen Sprachen. Es lohnt sich, sich für die verwendete Datenbank mit dieser Themaik zu beschätigen.

10 427

XML Schema und OOP

11. XML Schema und OOP

11. XML Schema und OOP

XML Schema ist ein Standard für die Modellierung von Datenformaten mit der Benennung von Feldern (aufgeteilt in Elemente und Atribute) und ihren Eigenschaten wie ihr zulässiger Inhalt (Datentyp ihres Inhalts oder Unter-Feld-Struktur sowie Schlüssel und Fremdschlüssel), Reihenfolgen- und Hierarchiebeziehungen. Bei der Modellierung stehen eindeuig der Aspekt des Datenformats und die Strukturierung von Dateien oder Nachrichten im Vordergrund, nicht aber bspw. der Aspekt der reinen Datenmodellierung (Auteilung in Ober- und Unterklassen und Zuordnung von möglicherweise ebenfalls hierarchisierten Eigenschaten) oder die Abbildung von Beziehungen zwischen Daten. Ein wenig ist dies mit verschiedenen Techniken von XML Schema grundsätzlich möglich, aber es gibt hierzu weitere und besser geeignete Techniken wie bspw. die objektorienierte Modellierung mit der UML (Uniied Modelling Language) oder OWL (Web Ontology Language). Nichtsdestoweniger lässt sich eine interessante und nützliche Beziehung zwischen einer objektorienierten Datenabbildung und XML Schema herstellen, die mit relaiv geringem Aufwand erfolgreich genutzt werden kann. In diesem Kapitel möchten wir Ihnen die Beziehung zwischen der Abbildung von Daten in einer objektorienierten Lösung und in XML Schema sowie die leichte Umwandlung von XML-Daten in Objekte und wieder zurück in Java und .NET zeigen.

11. 1.  XML Schema und Objektorienierung XML Schema bietet mit der Technik der Ableitung durch Erweiterung/Einschränkung von globalen komplexen Typen, der Redeiniion sowie der Element-Ersetzungsgruppe objektorienierte Techniken für die Modellierung und Beschreibung von Datenformaten an. Diese Ähnlichkeiten sind interessant zu diskuieren und zu betrachten, da ja die Deiniion einer Java-/.NET-Klasse sich syntakisch völlig anders darstellt als die Erstellung einer XML Schema-Datei. Doch solche Technologie-Vergleiche sind in diesem Kapitel nicht das Thema. Es geht vielmehr darum, wie eine Abbildung der gleichen oder sehr ähnlichen Daten erfolgreich sowohl in XML (modelliert über XML Schema) und in Java/.NET (modelliert über die Klassen) gelingen kann und welche Technologien beide Sprachen dafür bereitstellen.

429

11

11. XML Schema und OOP

11. 1. 1.  Prinzip Bei objektorienierter Sotware gibt es Szenarien, in denen komplexe Objektstrukturen nach und nach durch den Benutzer über Formulare und Datenbearbeitung oder über Datenzugrife, Berechnungen und die Anwendungslogik aufgebaut werden. Man kann sich bspw. vorstellen, wie über mehrere hintereinander aufgerufene Formulare bei einem Buchungs- und Bestellvorgang Daten wie die ausgewählten Produkte, Versandopionen und schließlich Rechnungs- und Versandadresse erfasst oder bearbeitet werden. Sollen diese dann einer anderen Anwendung bereitgestellt werden, benöigt man ein Nachrichtenformat, in dem die Objektstruktur als Text-Repräsentaion abgebildet wird. Diese Repräsentaion entspricht der intern in der Sotware verwendeten Datenstruktur, sodass es sich lohnt, sie möglichst ähnlich zu modellieren, damit eine leichte Übertragung möglich ist und man selbst aus Sicht des Modellierers oder Entwicklers bei der Entwicklungs- und Planungsarbeit ein einheitliches Modell vor sich sieht und nicht etwa zwischen verschiedenen Darstellungen, Bezeichnungen und Strukturen wechseln muss. In folgenden Situaionen kann eine sehr enge und ähnliche Abbildung von Daten Sinn machen: ●

Die gleichen Daten sollen in mehreren Anwendungen genutzt werden und werden über XML-/Text-Nachrichten (typischerweise Web Services) ausgetauscht und nicht durch Zugrif auf die gleiche Datenbank.

●

Eine Sotware soll fähig sein, oline und online zu arbeiten, sodass online zu speichernde Daten möglichst leicht zu serialisieren sind, um sie dann wieder in Objekte einzulesen und sie dann direkt aus der serialisierten Darstellung an die zentrale Datenbank zu senden.

●

Eine Sotware soll ein eigenes Dateiformat besitzen, welches man möglichst einfach aus Objektzuständen erstellen möchte.

Für diese Anforderungen lässt sich leicht eine XML-Struktur denken. Da die Daten der Anwendung gespeichert und wieder eingelesen werden sollen, liegt es auf der Hand, dass die Art der Daten sowohl in der Sotware wie auch im Datei-/Exporformat sehr ähnlich sind. Daher lohnt es sich, auch die Modellierung von beiden Welten aufeinander abzusimmen bzw. gibt es nur wenige Gründe, Felder und Strukturen extra anders zu benennen oder Daten völlig umzustrukturieren. Dies würde man eher machen, wenn man bspw. auf der Grundlage eines nicht gelungenen Datenmodells ein besser überlegtes und geplantes Modell erstellen möchte und daher eine solche Umstrukturierung vornehmen würde. Es lässt

430

11

11. XML Schema und OOP

sich lediglich noch annehmen, dass insbesondere beim Ursprung der Daten noch mehr interne Daten erhoben werden, deren Export keinen Sinn ergibt, und dass natürlich Verarbeitungslogik exisiert, die keinen Zustand darstellt und auch nicht exporiert werden kann. Wir gehen also davon aus, dass eine Objektstruktur möglichst ähnlich als Export-Daten bereitgestellt werden muss. Darüber hinaus gehen wir auch davon aus, dass das einzige sinnvolle Vorgehen darin besteht, XML zu verwenden und diese Daten mit XML Schema zu deinieren. Möglicherweise sind auch noch relaionale Strukturen in einer Datenbank zu berücksichigen. In diesem typischen Szenario besteht dann unser Vorgehen darin, die Daten in Sotware, Datenbank und Export möglichst einheitlich mit XML Schema zu beschreiben, um so ein Daten-Element leicht in den verschiedenen Teilen der Gesamt-Architektur zu ideniizieren. In der Abbildung hat man über eine XML Schema-Darstellung eine weitere Ebene eingefügt, welche eine Hierarchie in XML in Klassen mit Eigenschaten zerlegt. Das Vorgehen ist hierbei recht simpel: ●

Jede Hierarchie-Ebene bzw. jeder Teilbaum steht für eine Klasse.

●

Ein Element, das einen Textknoten enthält, und ein Atribut betrachtet man als Eigenschaten einer Klasse. Es ist lediglich bei der Übertragung von Daten festzuhalten, welche Eigenschaten nun Elemente und welche Atribute sind.

●

Ein Element, das selbst wieder Kind-Elemente hat, stellt eine Eigenschat einer Klasse dar, die ein Objekt enthält.

●

Eine Gruppe von Geschwister-Elementen stellt die Eigenschaten einer Klasse dar. Dabei unterscheidet man zwischen primiiv typisierten und über eine Klasse typisierte Eigenschaten.

●

Kann ein Element mehrfach im Instanzdokument erscheinen, ist es als Collecion oder Array zu betrachten.

Das Beispiel setzt die schon an anderer Stelle verwendete Erfolgsübersicht ein. Für die Abbildung der gesamten Struktur benöigt man eine Klasse, die eine Eigenschat besitzt, welche als Collecion mehrere Erfolge speichern kann. Jeder Erfolg ist wiederum eine Klasse mit insgesamt vier Eigenschaten, von denen zwei in XML als Atribut und zwei als Element modelliert sind. Während die beiden Atribut-Eigenschaten primiiv typisiert sind, bilden die beiden Element-Eigenschaten zwei Teilbäume in XML ab. Diese modelliert man in der

431

11

11. XML Schema und OOP

objektorienierten Variante als zwei Klassen, von denen jeweils eine Instanz in den Eigenschaten referenziert wird. Diese beiden Klassen besitzen dann einmal zwei und einmal drei primiiv typisierte Eigenschaten. Dieses Beispiel bietet keine großen Anknüpfungspunkte für Diskussionen, wie man diese oder jene Struktur gut in Java oder .NET abbilden könnte. Statdessen kann man sich leicht vorstellen, wie die XML-Daten fast 1:1 als Objektstruktur dargestellt werden können. Ein typisches Beispiel, bei dem nicht nur eine staische Struktur, sondern auch Verarbeitungslogik einzusetzen wäre, ist der Einsatz von Schlüsseln und Fremdschlüsseln. Der Prüfmechanismus ist in XML Schema deklaraiv, während die Logik in Java/.NET tatsächlich implemeniert werden müsste.

Abbildung 11.1: Zuordnung zwischen XML-Elementen/-Strukturen und Klassen-Elementen/-Strukturen

Als Zusammenfassung dieses Abschnits kann man nun noch beide Welten – die objektorienierte und die XML Schema-Welt – zusammen in eine Abbildung bringen. Sie zeigt die folgenden Aspekte: ●

432

11

Das Datenmodell und damit die Strukturdeiniionen sind in XML Schema und in der Klassendeiniion hinterlegt. Es ist nicht immer notwendig, eine 1:1-Zuordnung herzustellen, denn ot wird nur ein Teil der Daten in XML oder der Sotware benöigt.

11. XML Schema und OOP

●

Die Instanzen sind dann entweder die XML-Instanzdokumente, da sie gülige Entsprechungen des XML Schema sind, oder die Objekte, da sie auf Basis der Klassen instanziiert wurden.

●

Die Erzeugung von XML Schema-Dateien aus den Klassendeiniionen oder umgekehrt, lässt sich durch schon vorhandene Generator-Sotware durchführen. Ebenfalls vorhandene weitere Sotware nutzt Anmerkungen in den Klassen oder auch der XML SchemaDatei, um die Instanzen ebenfalls bei Bedarf zu überführen.

Abbildung 11.2: Vergleich XML Schema und Klassen sowie deren Instanzen

11. 1. 2.  Funkionsweise Der grundsätzliche Nutzen der Vorgehensweise ist sicherlich deutlich geworden. Es ist lediglich unklar, welche Arbeitsschrite und welcher Aufwand bei der Entwicklung der entsprechenden Import-/Export-Sotware oder Zuordnungs- und Übertragungssotware not-

433

11

11. XML Schema und OOP

wendig sind. Man kann sich sicherlich leicht vorstellen, dass man bei der Planung gleichzeiig die XML Schema-Datei und die entstehenden bzw. notwendigen Klassen berücksichigt und wie man einfach beides parallel und aufeinander abgesimmt entwickelt. Dies sind allerdings nur die einfachen staischen Strukturen. Man benöigt ja noch eine weitere Komponente, mit der aus XML-Daten die Objekte und aus den Objekten die XML-Daten erzeugt werden. Hier ahnt man vielleicht, dass man einen generischen Algorithmus benöigt, der unter Rückgrif auf die XML Schema-Datei oder weitere Daten die passenden Zuordnungen vornimmt. Doch wie dies genau gelingen soll, liegt etwas im Nebel und scheint schwierig so planbar, dass man die Sotware später gut erweitern oder auch wiederverwenden kann. Statdessen ist es so, dass man in Java und .NET auf eine voll entwickelte Bibliothek zurückgreifen kann und nicht gezwungen ist, den gesamten Mechanismus selbst zu entwickeln. Wenn die Bindung zwischen XML Schema und den Klassen eingerichtet ist, verringert sich der Arbeitsaufwand der Instanzdaten-Übertragung auf wenige Quelltextzeilen. Die Bindung selbst wiederum lässt sich wiederum mit ferigen Sotware-Komponenten bewerkstelligen und erfordert normalerweise nur Anmerkungen in der XML Schema-Datei (wenn die Klassen generiert werden sollen) oder in der Klasse (wenn die XML Schema-Datei generiert werden soll). Diese Anmerkungen werden dann auch bei der Instanzdatenumwandlung ausgelesen.

Abbildung 11.3: Generierung und (Un)Marshalling

434

11

11. XML Schema und OOP

Es gibt also in beiden Technologien ein Kommandozeilentool, mit dem die XML Schemaund Klassen-Dateien generiert werden können. Und ebenfalls gibt es in beiden Technologien Klassen, welche für die Serialisierung und Deserialisierung genutzt werden können. Allerdings heißt das Vorgehen nicht mehr (De)Serialisierung, sondern (Un)Marshalling. Marshalling meint dabei die Umwandlung von Objekten in XML, während Unmarshalling die Umwandlung von XML in Objekte meint. Die zweite Abbildung dieses Abschnits fasst dann die verschiedenen Konzepte noch einmal zusammen. ●

Die Klassen werden an das XML Schema gebunden und umgekehrt. Dafür gibt es Kommandozeilentools zur Generierung der fehlenden Dateien.

●

Die XML-Instanzdaten folgen ihrem XML Schema.

●

Die Objekte folgenden ihren Klassendeiniionen.

●

Zwischen den Instanzdaten in Objekten und XML indet eine Umwandlung stat – Marshalling und Unmarshalling genannt. Dafür gibt es Framework-Klassen zur Umwandlung der Instanzdaten unter Rückgrif auf die Bindungsinformaionen.

Abbildung 11.4: Architektur-Überblick über XML Schema-Klassen-Bindung

435

11

11. XML Schema und OOP

11. 1. 3.  Erweiterung auf Datenbanken Der Zusammenhang zwischen den verschiedenen Konzepten (XML Schema, Objektorienierung, relaionale Modellierung), die auch wieder unter verschiedenen Perspekiven (Betonung der Gemeinsamkeiten oder der Unterschiede von Datenerfordernissen, Berücksichigung von vorgegebenen Datenschnitstellen) betrachtet werden können, lässt sich noch sehr viel ausführlicher beschreiben, wenn man alternaive Design-Möglichkeiten und Sonderfälle, die sich ja immer inden lassen, hinzunimmt. Projektspeziische Fragestellungen können dann natürlich noch einmal weitere Kriterien oder andere Gewichtungen erfordern. Daher sind die bisherigen Ausführungen oberlächlich und können nur die wesentlichen Prinzipien darstellen, ohne Vor- und Nachteile von Varianten und Vorgehensweisen zu diskuieren. Trotz dieser Kürze – es sollen ja auch noch konkrete Beispiele in Java und .NET - soll eine häuige Erweiterung und damit ein zusätzlicher Aspekt beleuchtet werden: die Integraion einer Datenbank und damit der relaionalen Modellierung. Es ist leicht vorstellbar, dass viele Sotwarelösungen, die XML-Daten und damit auch Import/Export oder Oline-/OnlineKapazitäten erforderlich machen, auch eine zentrale Server-Datenbank beinhalten. Diese Datenbank kann dann wiederum eine eigene Datenbank sein, während die Import-/ExportDaten fremde Datenbanken und fremde Server betrefen könnten und damit noch die Aspekte Datenübertragung, Sicherheit oder Plaformunabhängigkeit mit ins Spiel bringen. Wie man sieht, lässt sich das Spiel der Komplexitätserweiterung ins Unendliche fortsetzen. Daher sollen nur die folgenden zentralen Gedanken zum Thema Datenbank-Integraion noch präseniert werden: Ot wird es so sein, dass für ein Import-/Export-Szenario die Datenstrukturen auch in einer relaionalen Datenbank wiederzuinden sind. Möglicherweise sind – wie auch in der Sotware – noch weitere zusätzliche Datenelemente vorhanden, doch man kann einen gemeinsamen Datenbestand als Schnitmenge der verschiedenen Einheiten Sotware, Datenbank und Import-/Export-Schnitstelle (nach außen oder intern) ausmachen. Dann lohnt es sich natürlich zur Redukion der Anwendungs- und Entwicklungskomplexität, die Daten, die zwischen diesen verschiedenen Einheiten transporiert werden, einheitlich zu modellieren. Damit ist nicht gemeint, dass bspw. aus der Datenbank die benöigten Daten exporiert werden sollen oder die Datenbank nur die benöigten Daten erhält. Dies ist trivial und ohnehin erforderlich, um überhaupt eine sinnvolle Schnitstelle zu konstruieren. Es geht vielmehr darum, dass nicht die Sotware zunächst mit einer SQL-Abfrage die Daten aus der Datenbank abrut und dann gemäß der Import-/Export-Schnitstelle passend

436

11

11. XML Schema und OOP

zusammensetzt, sondern dass bereits die Datendeiniion in der Datenbank direkt Berücksichigung indet. Man verlagert also einen Teil der Anwendungslogik. Dies gelingt, wenn man bei Datenbank-Prozeduren auf die XML Schema-Datei zurückgreit und die Prozeduren nicht nur tradiionelle Ergebnismengen liefern, sondern sofort XML-Daten im passenden Format. Mit Datenbanken von Oracle, Microsot und IBM hat man dafür geeignete SQL-Erweiterungen, um XML-Daten zu liefern, zu validieren und auch umzuwandeln. Eine solche XML-fähige Datenbank erlaubt es, ein XML Schema zu laden und als eigene Ressource wie einen sehr umfassenden Datentyp für Spalten, Variablen, Parameter oder Rückgabewerte zu nutzen. Dies bedeutet, dass Prozeduren oder Funkionen nicht nur im Export-Fall die passenden XML-Daten liefern, sondern sie auch akzepieren und intern weiterverarbeiten können. Selbstverständlich ist es nicht immer zweckmäßig oder gewünscht, Prozeduren in der Datenbank zu entwickeln, weil bspw. die Sotware sowohl für Oracle wie auch für den MS SQL Server nutzbar sein soll. Doch auch in einem solchen Fall sollte das Sotware-Modul, welches die DB-Daten umwandelt, unter Rückgrif auf die XML Schema-Datei die passenden Daten liefern oder erstellen und diese Logik zentralisieren. Weil die Sotware selbst wiederum (Un)Marshalling einsetzt, verschwimmen dadurch die Grenzen zwischen der intern genutzten Objektstruktur und den gelieferten Import-Daten oder den extern benöigten Export-Daten. An allen Stellen der Architektur, die sich mit den hin und her transferierten Daten abmühen, greit man auf die gleiche zentrale Modellierung zurück. Im schönsten Fall hat man sogar ein Benennungsschema für die Datenelemente, welches durchgängig von Datenbank über Sotware bis zu den Dateien genutzt werden kann, und so die Komplexität bei der Anwendungsentwicklung reduziert. Wie Sie vielleicht schon erahnen, gelangt man zum Thema „einheitliches Unternehmensdatenmodell“, das nicht nur für die hier immer erwähnte Sotware, sondern für alle im Unternehmen eingesetzten Sotware-Lösungen zum Einsatz kommt. Dies bleibt in den meisten Fällen aus Gründen, die hier zu weit führen, eine Utopie, oder wird trotz Existenz einer zentralen Datenbeschreibung auch häuig bei Insel-Lösungen durchbrochen. Doch man schat sich über das beschriebene und nun um Datenbanken erweiterte Vorgehen einige lokale stabile Datenstrukturen. Die Abbildung stellt zwei verschiedene Vorgehensweisen dar: ●

Setzt man den tradiionellen Weg über SQL und Ergebnismengen ein, so rut man Daten in einem nicht weiter typisierten Format ab und formt aus diesen dann die benöigten Objektstrukturen. Sollen Daten wieder zur Datenbank geschickt werden, muss

437

11

11. XML Schema und OOP

man sie in einzelne SQL-Anweisungen umwandeln, die dann die relaionalen Strukturen referenzieren und die entsprechenden Daten einhalten. ●

Setzt man auf die XML Schema-Bindung, dann erhält man direkt von der Datenbank das benöigte XML, welches dann in die benöigten Objekte umgewandelt wird. Der umgekehrte Weg ist genauso einfach, denn hier wandelt man die Objektstruktur in XML um und übergibt dieses an die Datenbank, die dann die XML-Daten relaional zerlegen muss.

(De)Serialisierung XML data

Datenbank XMLSchnittstelle

Sicht (Un)Marshalling

Tabelle 1

Tabelle 2

SQLSchnittstelle

Ergebnismenge (Objekte)

Umwandlung SQL-Befehle und Daten

Relationale Modellierung

Objekte

XMLModellierung

Gemeinsame Daten-Elemente

Abbildung 11.5: Architektur-Überblick mit zusätzlicher Datenbank

438

11

Objektorientierte Modellierung

11. XML Schema und OOP

11. 2.  XML Schema-Bindung in .NET Ab .NET 2.0 besteht die Möglichkeit, aus XML Schema .NET-Klassen zu erzeugen oder aus einer Laufzeitassemblydatei (Erweiterung .exe oder .dll) XML Schema-Klassen. Dabei setzt man ein im Visual Studio-Ordner vorhandenes Kommandozeilen-Tool namens XSD.exe ein. Die Klassen werden bei der Generierung automaisch mit Annotaionen versehen, welche die Zuordnung zwischen .NET und XML Schema festlegen. Durch diese Annotaionen kann man das zu erstellende XML Schema aus den Klassen sowie dann auch später das (Un) Marshalling beeinlussen.

11. 2. 1.  Prinzip der Klassengenerierung aus XML Schema Die klassische Vorgehensweise besteht darin, zunächst zu testen, was überhaupt passiert, wenn man eine einfache XML Schema-Datei zu Klassen umwandelt. Die einfachste XML Schema-Datei ist dabei eine, die im Matrjoschka-Design erstellt wurde. Im nachfolgenden Beispiel ersetzen die drei Punkte jeweils den Pfad zur XSD.exe-Datei, zur XML Schema-Datei und zum Ausgabeordner. C:\...\xsd.exe „C:\...\matrjoschka.xsd“ /c „/l:CS „ „/o:C:\...\CS-1“

Die wichigsten Parameter sind in der nachfolgenden Liste enthalten: ●

/h[elp] oder /? - Listet die Befehlsopionen auf.

●

/o[utputdir]:directory - Legt das Verzeichnis für Ausgabedateien fest (Standardwert: aktuelles Verzeichnis).

●

/c[lasses] - Generiert Klassen entsprechend dem angegebenen XML Schema.

●

/f[ields] - Generiert Felder anstelle von Eigenschaten (Standardeinstellung).

●

/l[anguage]:language - Gibt die Programmiersprache an (CS, Standard), VB, JS oder VJS.

●

/n[amespace]:namespace - Legt den Laufzeitnamespace fest (Standardnamespace ist Schemas).

439

11

11. XML Schema und OOP

●

/o[ut]: directoryName - Legt das Ausgabeverzeichnis fest (Standardverzeichnis ist der aktuelle Ordner).

Weitere Informaionen inden Sie unter htp://msdn.microsot.com/de-de/library/ x6c1kb0s(v=vs.80).aspx. Zu diesem Konsolenprogramm gibt es von der Firma Sot3K ein nützliches einfaches GUIWerkzeug (htp://www.sot3k.com/Visual-XSD-p8651.htm). Neben den verschiedenen Opionen, die man einfach markieren und ggf. mit Werten versehen kann, rut es das XSD.exeProgramm auf und zeigt auch den eingegebenen Konsolenaufruf sowie mögliche Fehler an.

Abbildung 11.6: Verwendung von VisualXSD

Die sehr einfach aufgebaute Datei matrjoschka.xsd führt zu Klassen, die man ernsthat nicht weiter verwenden kann. Um die verschachtelte Klassenhierarchie abzubilden, sind mehrere Klassen notwendig. Die Namen setzen sich bei einem Matrjoschka-Design einfach aus den in der XML-Hierarchie aufeinander folgenden Element-Namen zusammen.

440

11

11. XML Schema und OOP

Dadurch werden diese Namen sehr unhandlich. Man kann allerdings dennoch mit einer solch einfachen Datei das allgemeine Vorgehen testen. Die Abbildung zeigt das XML Schema-Diagramm und in grauen Kästchen die Namen der erzeugten Klassen.

Abbildung 11.7: Generierte Klassen aus Matrjoschka-Design (matrjoschka.cs)

Die generierten Klassen enthalten den angekündigten Aubau. Dies bedeutet, dass aus Elementen und Atributen jeweils Eigenschaten der Klassen werden. Atribute und einfach typisierte Elemente werden mit einem passenden Datentyp erzeugt. Enthalten Elemente dagegen weitere Kind-Elemente oder Atribute, so wird eine neue Klasse generiert mit den jeweiligen Elementen oder Atributen als Eigenschaten. Da im Beispiel ein Element mehrfach autrit, wird auch ein Array erzeugt, in dem dann in der Eigenschat der Klasse mehrere Objekte des passenden Typs enthalten sein können. Die Abbildung zeigt die um die so genannten Annotaionen und weitere generierte Kommentare bereinigten Klassendeiniionen. Man erkennt leicht den Aubau aus der XML Schema-Datei wieder.

441

11

11. XML Schema und OOP

Abbildung 11.8: Generierte Klassen (matrjoschka.cs)

11. 2. 2.  XML Schema-Bindung Das vorherige Beispiel zeigte, dass zwar auch aus einer solch einfachen XML Schema-Datei ein Klassensystem erzeugt wird, doch die Klassennamen sind nicht für die weitere Verwendung geeignet. Man möchte also wenigstens die Klassenstruktur etwas genauer vorgeben und vielleicht sogar die Namen in XML verschieden von denjenigen in den Klassen und Eigenschaten vorgeben. In der XML Schema-Datei komplexeTypen.xsd ist nun die typische Form enthalten, die bei der Generierung von Klassen zu Grunde gelegt wird: Jeweils ein neuer globaler komplexer Typ bildet eine Hierarchie-Ebene in der XML Schema-Datei. Die Namen dieser Typen legen dann die zu erzeugenden Klassennamen fest, sofern keine anderen Einstellungen getrofen

442

11

11. XML Schema und OOP

wurden. Des Weiteren ist in der Datei eine Vererbungshierarchie zwischen den Typen UmsatzTyp und GesamtTyp vorhanden, bei der in GesamtTyp noch ein weiteres Element angehängt wird. Diese Vererbung wird ebenfalls in eine Klassen-Hierarchie übertragen.

{

{}

}

class

{

}

{

}

{

}

schema

Abbildung 11.9: Generierte Klassen aus globalen komplexen Typen (komplexeTypen.cs)

Die Klassen haben nun die gewünschten Namen und besitzen auch die entsprechende Vererbungshierarchie. Die Eigenschaten referenzieren nun natürlich die neu gebildeten Klassen, sind aber ansonsten ähnlich wie zuvor aufgebaut.

443

11

11. XML Schema und OOP

public partial class Erfolguebersicht { private ErfolgTyp[] erfolgField; public ErfolgTyp[] Erfolg { get { return this.erfolgField; } set { this erfolgField = value; } } }

public partial class ErfolgTyp {

public partial class GesamtTyp : UmsatzTyp {

private GesamtTyp gesamtField; private UmsatzTyp proKopfField; private string stadtField; private string monatField; public GesamtTyp Gesamt { get { return this gesamtField; } set { this gesamtField = value; } } public UmsatzTyp ProKopf { get { return this proKopfField; } set { this.proKopfField = value; } }

private int kundenField; public int Kunden { get { return this kundenField; } set { this.kundenField = value; } } } public partial class UmsatzTyp { private decimal umsatzField; private decimal anrufeField; public decimal Umsatz { get { return this umsatzField; } set { this.umsatzField = value; } }

public string Stadt { get { return this.stadtField; } set { this.stadtField = value; } } public string Monat { get { return this.monatField; } set { this.monatField = value; } } }

public decimal Anrufe { get { return this anrufeField; } set { this.anrufeField = value; } } }

Abbildung 11.10: Generierte Klassen (komplexeTypen.cs)

11. 2. 3.  Mapping und Serialisierung beeinlussen Manchmal ist bereits eine Klassenstruktur vorhanden, die nach XML Schema überführt werden soll, um aus den daraus resulierenden Objektstrukturen vorher festgelegte XMLInstanzdaten zu gestalten. In diesem Fall muss man sich mit den verschiedenen Atributen beschätigen, die man für Klassen und Eigenschaten/Felder verwenden kann, um die Serialisierung vorzugeben. Sie kommen auch zum Einsatz, wenn man Web Service-Nachrichten strukturieren möchte. Diese Atribute waren auch in den vorab generierten Klassen enthalten, wurden aber nicht in die Abbildungen übernommen oder weiter diskuiert, da ihre Einstellungen und Syntax-Varianten doch recht umfangreich sind, obwohl ihre Anzahl wiederum sehr überschaubar ist.

444

11

11. XML Schema und OOP

Die verschiedenen Atribute sind für unterschiedliche Klassenmember oder sogar eine ganze Klasse gülig. Für die meisten stehen überladene Versionen bereit, mit denen man mehr oder weniger Eigenschaten setzen kann. Das einfachste Beispiel ist sicherlich XmlElement. Eine überladene Version erwartet als Zeichenkete nur den Namen, eine andere lässt Namen, Datentyp und weitere Eigenschaten in der Form name = wert zu. In den nachfolgenden Beispielen werden alternaive Verwendungen gezeigt. Aus Platzgründen können allerdings nicht alle Varianten diskuiert werden. Für dieses Kapitel soll es genügen, sie beispielhat einzuführen. Im nachfolgenden Beispiel legt man Einstellungen für die Klasse Erfolguebersicht fest. Da sie die oberste Klasse der Klassenstruktur darstellt, kann man mit XmlRoot festlegen, dass ein Zielnamensraum generiert werden soll und wie Name und globaler komplexer Typ für diese Klasse und das oberste Element sein sollen. Alternaiv – so war es im XML Schema in der Datei komplexeTypen.xsd – kann man auch einen so genannten anonymen Typ verwenden. Dann ist der komplexe Typ nur lokal und hat also keinen Namen (anonym). Die folgenden Eigenschaten sind für die verwendeten Atribute besonders wichig: ●

XmlRoot legt das XML-Wurzel-Element fest.

ƒ ElementName - Explizit vorgegebener Name des XML-Elements oder automaisch aus der Eigenschat abgerufen. ƒ DataType - Explizit vorgegebener XML Schema-Datentyp oder automaisch aus .NET-Datentyp abgeleitet/angepasst. ƒ IsNullable - Legt fest, dass ein leeres Element mit xsi:nil-Atribut generiert wird, wenn kein Wert im Objekt gespeichert ist. ƒ Namespace - XML-Namespace des XML-Wurzel-Elements. ●

XmlType legt Eigenschaten für Klassen, Strukturen, Enumeraionen oder Schnitstellen fest und hat selbst folgende Eigenschaten:

ƒ AnonymousType - Legt fest, ob ein globaler komplexer Typ erstellt werden soll oder ob er nur lokal sein soll.

445

11

11. XML Schema und OOP

ƒ IncludeInSchema - Legt fest, ob der Typ in das XML Schema aufgenommen werden soll. Normalerweise ist dies bei verbundenen Strukturen der Fall, damit die Deklaraionen gülig bleiben. ƒ Namespace - Legt den Namensraum des Typs fest. ƒ TypeName - Legt den Namen des Typs fest. Normalerweise ist dies der Name von Klasse, Schnitstelle etc. using System.Xml.Serialization; [XmlRoot(Namespace = “http://www.ruhrfon.biz”, ElementName = “Uebersicht”)]

// Alternative: anonymer Typ //[XmlType(AnonymousType=true)] [XmlType(“UebersichtTyp”)]

public partial class Erfolguebersicht { private ErfolgTyp[] erfolg; [XmlElement(ElementName = “Erfolg”, IsNullable = false)] public ErfolgTyp[] Erfolg { get;

set;

} } komplexeTypenAnnotaionen.cs: Wurzelelement und seine Kinder

Aus öfentlichen Eigenschaten werden normalerweise automaisch XML-Elemente generiert. Möchte man lieber Atribute, den Namen oder automaisch gewählten Datentyp ändern sowie natürlich Eigenschaten nicht serialisieren, gibt man dies mit den Atributen XmlElement, XmlAttribute oder XmlIgnore an. Die folgenden Eigenschaten dieser Atribute sind besonders wichig: ●

XmlElement legt fest, wie das Klassenmember aus Element generiert werden soll.

ƒ ElementName - Explizit vorgegebener Name des XML-Elements oder automaisch aus der Eigenschat abgerufen.

446

11

11. XML Schema und OOP

ƒ DataType - Explizit vorgegebener XML Schema-Datentyp oder automaisch aus .NET-Datentyp abgeleitet/angepasst. ƒ Type - Explizit vorgegebener komplexer Typ des XML-Elements oder aus .NET-Objektyp abgerufen. ƒ IsNullable - Legt fest, dass ein leeres Element mit xsi:nil-Atribut generiert wird, wenn kein Wert im Objekt gespeichert ist. ƒ Form - Legt fest, ob das XML-Element qualiiziert (mit Namensraum-Präix) sein muss oder nicht. ƒ Namespace - XML-Namespace des XML-Elements. ƒ Order - Platz in der Ordnungsreihenfolge in XML. ●

XmlAttribute legt fest, wie das Klassenmember aus Atribut generiert werden soll.

ƒ AttributeName - Explizit vorgegebener Namen des XML-Atributs oder automaisch aus der Eigenschat abgerufen. ƒ DataType - Explizit vorgegebener XML Schema-Datentyp oder automaisch aus .NET-Datentyp abgeleitet/angepasst. ƒ Namespace -XML-Namespace des XML-Atributs. public partial class ErfolgTyp { private GesamtTyp gesamt; private UmsatzTyp proKopf; private string stadt; private string monat; private string region; // Berücksichtigung als Element mit Umbenennung [XmlElement(ElementName = “Total”, IsNullable = true)] public GesamtTyp Gesamt { get; set; } // Berücksichtigung als Element gleichen Namens [XmlElement(IsNullable = true)]

447

11

11. XML Schema und OOP

public UmsatzTyp ProKopf { get; set; } // Unberücksichtigt lassen [XmlIgnore] public string Region { get; set; } // Berücksichtigung als Attribut und Namensänderung //[XmlAttribute(“Ort”)] [XmlAttribute(AttributeName = “Ort”, DataType=”string”)] public string Stadt { get; set; } // Berücksichtigung als Attribut gleichen Namens [XmlAttribute()] public string Monat { get;

set; }

} komplexeTypenAnnotaionen.cs: Elemente und Atribute deinieren

Da ja grundsätzlich über die Standard-Serialisierung auch schon ein XML Schema bzw. aus nicht weiter annoierten Objektstrukturen auch XML-Daten erzeugt werden können, gibt es dafür geeignete Vorgabewerte. Diese kann man teilweise im nächsten Beispiel sehen. Da GesamtTyp von UmsatzTyp erbt und auch aus der Klasse Erfolguebersicht aufgerufen wird, muss er in das XML Schema aufgenommen werden, damit die Deklaraionen alle gülig bleiben. Als Name für den entstehenden globalen komplexen Typ wird dann der Klassenname verwendet. Die Vererbung wird ebenfalls über Ableitung durch Erweiterung nachgebildet. Des Weiteren kann man noch die Kurzformen für die Umbenennung von Elementen/Atributen sowie die explizite Berücksichigung von verbundenen .NET-Typen (Klasse UmsatzTyp) über das XmlInclude-Atribut sehen. // Keine expliziter Hinweis auf Verwendung public partial class GesamtTyp : UmsatzTyp { private int kunden; // Berücksichtigung als Element und Umbenennung [XmlElement(“Kundenzahl”)] public int Kunden { get; set;

448

11

11. XML Schema und OOP

} } // Expliziter Hinweis auf Verwendung [XmlInclude(typeof(UmsatzTyp))] public partial class UmsatzTyp { private decimal umsatz; private decimal anrufe; // Explizite Berücksichtigung als Element [XmlElement(“Umsatz”)] public decimal Umsatz { get; set; } // Implizite Berücksichtigung als Element public decimal Anrufe { get; set; } } komplexeTypenAnnotaionen.cs: Weitere Angaben und Syntax-Varianten

Man setzt dann ebenfalls das XSD.exe-Tool ein, um aus der DLL, welche aus dem Projekt AtributTest entstanden ist, die XML Schema-Datei zu erzeugen. Da in den meisten DLLs wohl mehr als nur eine Klasse zu inden sein dürte, muss man angeben, bei welcher Klasse die Generierung beginnen soll. In diesem Fall handelt es sich um die oberste Klasse des Baums Erfolguebersicht. Nachfolgend inden Sie den verwendeten Kommandozeilenaufruf, wobei die drei Punkte wieder die Dateipfade abkürzen. Die Assembly bzw. das Visual Studio-Projekt inden Sie im Ordner AttributTest. C:\...\xsd.exe „C:\...\AttributTest.dll“ „/o:C:\...\AttributTest“ „/t:Erfolguebersicht“

Im Wesentlichen entspricht das generierte XML Schema demjenigen, mit dem wir zu Anfang begonnen haben.

449

11

11. XML Schema und OOP

Abbildung 11.11: Generiertes XML Schema

Um die verschiedenen Einstellungsmöglichkeiten zu zeigen, welche bei den Serialisierungsatributen denkbar sind, gibt es aber dennoch einige Unterschiede: Der Zielnamensraum ist im XML Schema enthalten; jedoch wurde automaisch der Standardpräix tns erzeugt und bei der Verwendung von globalen Komponenten sowie auch bei den lokalen Komponenten verwendet, obwohl dies nicht unbedingt notwendig ist. Einige Elemente haben einen anderen Namen als zuvor, da sie in der Klasse anders vorgegeben wurden. Das Wurzelelement besitzt keinen anonymen komplexen Typ, sondern es gibt nun einen neuen globalen komplexen Typ namens UebersichtsTyp. Die Elemente können schließlich leer (nillable) sein.



450

11

11. XML Schema und OOP



... Generiert.xsd: Ausschnit aus der generierten XML Schema-Datei

Weitere Informaionen zu den verschiedenen Atributen und ihren Eigenschaten inden Sie unter: htp://msdn.microsot.com/de-de/library/83y7df3e.aspx

11. 2. 4.  Generierte Klassen erweitern In den meisten Fällen möchte man nicht nur die Objektstruktur für die reine Datenspeicherung und als objektorienierte Abbildung einer komplexen Datenstruktur nutzen, sondern auch weitere Verarbeitungslogik oder weitere Felder/Eigenschaten einfügen. Im aktuellen Fall könnte man sich vorstellen, dass man noch eine Gesamtanzahl aller Anrufe oder den gesamten Umsatz ausrechnet und als Eigenschat anbietet. Auch die Verwaltung von mehrfach autretenden Elementen, die in .NET als einfaches Array umgesetzt werden, bietet Erweiterungsmöglichkeiten. Das wichigste Ziel ist dabei natürlich, dass die generierten Klassen nicht direkt in der generierten Datei geändert werden, weil ja diese Datei bei einer erneuten Generierung überschrieben wird. Diese generierten Dateien müssen also unangetastet bleiben. Das nachfolgende Beispiel zeigt daher eine einfache Lösung, um weitere Elemente über eine ErfolgHinzufuegen()-Methode hinzuzufügen und nicht etwa die Array-Verwaltung außerhalb des gesamten Klassensystems durchzuführen. Dabei erstellt man in einer zweiten Datei im gleichen Namensraum weitere Teile der ja bereits durch die Generierung als pariell erzeugten Klassen. Beim Anruf können dann beide Dateien/Deiniionen als Einheit genutzt werden. namespace MarshallingTest { public partial class Erfolguebersicht { public void ErfolgHinzufuegen(ErfolgTyp erfolg) { List erfolge = new List(); if (this.Erfolg != null) {

451

11

11. XML Schema und OOP

erfolge.AddRange(this.Erfolg); } erfolge.Add(erfolg); this.Erfolg = erfolge.ToArray(); } } } komplexeTypenErweitert.cs: Erweiterung der generierten Klassen

11. 2. 5.  Von XML zu Objekten Nun fehlen noch zwei Beispiele, die zeigen, wie leicht man über diese gesamte Technik XML-Daten in Objekte umwandeln kann und auch wieder zurück von Objekte in XML gelangt.

11. 2. 5. 1  Marshalling Im ersten Beispiel erstellt man über die generierten Klassen eine verschachtelte Objektstruktur. Im Gegensatz zur Arbeit mit anderen XML-Bibliotheken wie bspw. mit dem DOM (Document Object Model) beschätigt man sich im Quelltext überhaupt nicht damit, dass man später eine XML-Datei generieren will. Man kann auch den Aspekt der XML-Erstellung völlig außen vor lassen und zunächst weiter mit den Objekten arbeiten. Während man beim DOM von vornherein einen überaus langen und meist auch durch Wiederholung geprägten Quelltext erstellt, an dem man manchmal bei sehr ief verschachtelten Strukturen gar nicht mehr erkennen kann, was für eine XML-Struktur über Zeilen hinweg formuliert wird, arbeitet man nun nicht mit einer objektorienierten Dokument-Darstellung, sondern mit einer objektorienierten Daten-Darstellung. Dies bedeutet, dass man nicht als zu Grunde liegendes Datenmodell in den Kategorien „Element“, „Atribut“ oder „Textknoten“ denkt, sondern in „ProKopf“, „Gesamt“ und „Erfolg“. // Erstellung einer Erfolgsübersicht Erfolguebersicht uebersicht = new Erfolguebersicht(); ErfolgTyp erfolg = new ErfolgTyp(); erfolg.Monat = „10.04“; erfolg.Stadt = „Essen, Ruhr“;

452

11

11. XML Schema und OOP

GesamtTyp gesamt = new GesamtTyp(); gesamt.Anrufe = 18869; gesamt.Kunden = 200; gesamt.Umsatz = (decimal)7154.01; UmsatzTyp proKopf = new UmsatzTyp(); proKopf.Anrufe = (decimal)94.35; proKopf.Umsatz = (decimal)35.77; erfolg.Gesamt = gesamt; erfolg.ProKopf = proKopf; //ErfolgTyp[] erfolgListe = { erfolg }; //uebersicht.Erfolg = erfolgListe; uebersicht.ErfolgHinzufuegen(erfolg); Program.cs: Marshalling – Erstellung der Objektstruktur

Die Klasse XmlSerializer aus dem Namensraum System.Xml.Serialization bietet die notwendige Funktonalität zur Umwandlung einer Objektstruktur in XML an. Der Konstruktor ewartet die Typ-Angabe der obersten Klasse der Klassenstruktur und kann dann die Serialisierung über die Serialize()-Methode vornehmen, welche das oberste Objekt, das alle anderen enthält, ewartet. // Serialisierung XmlSerializer serializer = new XmlSerializer(typeof(Erfolguebersicht)); TextWriter writer = new StreamWriter(ilename); serializer.Serialize(writer, uebersicht); writer.Close(); Program.cs: Marshalling – Tatsächliche Umwandlung in XML

11. 2. 5. 2  Unmarshalling Der umgekehrte Weg ist ebenfalls sehr einfach. Die gerade erzeugte XML-Datei wird über den nachfolgenden Vorgang wieder in eine Objektstruktur eingelesen und kann dann wie-

453

11

11. XML Schema und OOP

der über die Eigenschaten/Felder angesprochen werden. Häte man noch weitere Methoden oder Eigenschaten in pariellen Klassen erstellt, so könnte man diese ebenfalls für die Weiterverarbeitung nutzen. Ebenfalls ist wieder die XmlSerializer-Klasse zu instanziieren. Sie erwartet erneut die Typ-Angabe des obersten Elements der zu erzeugenden Objektstruktur und führt den Umwandlungsvorgang dann mit der Deserialize()-Methode durch. // Deserialisierung XmlSerializer serializer = new XmlSerializer(typeof(Erfolguebersicht)); FileStream fs = new FileStream(ilename, FileMode.Open); Erfolguebersicht uebersicht; uebersicht = (Erfolguebersicht)serializer.Deserialize(fs); // Ausgabe und Weiterverwendung Console.WriteLine(„Anrufe gesamt: „ + uebersicht.Erfolg[0].Gesamt.Anrufe); Console.WriteLine(„Anrufe pro Kopf: „ + uebersicht.Erfolg[0].ProKopf.Anrufe); Program.cs: Unmarshalling

11. 2. 5. 3  Standard-XML-Serialisierung Man kann die XmlSerializer-Klasse und damit die gesamte Technik der XML-Serialisierung auch verwenden, wenn man sich nicht XML Schema beschätigt hat und/oder in dem zu serialisierenden Klassensystem auch keine Atribute zur Art und Weise des XML-Aubaus vorhanden sind. In diesem Fall erhält man eine Standard-Lösung, die zwar irgendwie unserem XML Schema entsprechen würde, aber natürlich nicht genau unseren Regeln folgt. Anstat also diese Standard-XML-Serialisierung zu verwenden, greit der XmlSerializer auf die in den Klassen vorhandenen Atribute zurück und erstellt die XML-Daten nach diesen Vorgaben. Es fällt leicht, sich vorzustellen, dass keine Zeit im Projekt vorhanden ist, sich umfassend mit XML Schema zu beschätigen und dann auch noch die XML Schema-Bindung zu lernen. Gleichzeiig kann man sich aber sicherlich auch sehr leicht vorstellen, wie schnell eine solchermaßen unkoordinierte und ungeplante Verwendung von XML, das möglicherweise auch noch die Grenzen der eigenen Anwendung verlässt, zu größtem Chaos führen kann. Irgendwann sind evtl. doch mehr Anforderungen für die Datenmodellierung vorhanden,

454

11

11. XML Schema und OOP

und dann muss man möglicherweise aus Kompaibilitätsgründen eine ungünsige Modellierung beibehalten und neue Strukturen mehr hineinquetschen als strukturiert ergänzen. Die nachfolgende Abbildung enthält die Struktur der generierten XML-Datei. Es handelt sich um das gleiche Programm wie zuvor, wobei jedoch das Klassensystem um sämtliche Atribute bereinigt wurde. Diese Lösung inden Sie im Projekt StandardXML zur Ansicht. Da keine Atribute zur Festlegung, wie das XML aussehen soll, mehr exisieren, kann natürlich auch keine Unterscheidung zwischen XML-Elementen und XML-Atributen mehr vorgenommen werden. Auch eine Umbenennung zwischen .NET-Namen und XML-Namen ist nicht möglich. Besonders ärgerlich und verräterisch ist allerdings, dass der Klassenname ErfolgTyp noch einmal als weitere überlüssige Hierarchie-Ebene im XML vorhanden ist.

Abbildung 11.12:Über die Standard-Serialisierung generierte XML-Struktur

Auch eine XML Schema-Datei kann aus solchen Klassendeiniionen erzeugt werden. Hierzu kann man aus dem Projekt StandardXML die Datei StandardXML.exe verwenden. Da hier mehrere Klassen enthalten sind und ggf. auch mehrere Objektstrukturen deiniert sein könnten, gibt man den Start-Typ über den letzten Parameter gesondert an. C:\...\xsd.exe „C:\...\StandardXML.exe“ „/o:C:\...\StandardXML“ „/t:Erfolguebersicht“

Wie schon die generierte XML-Datei nahe gelegt hat, entstehen aus allen Eigenschaten Kind-Elemente. Diese erscheinen in der Reihenfolge wie in der Klasse. Die Klassennamen selbst erscheinen als Namen der globalen komplexen Typen. Für die Wiederholung der ErfolgTyp -Elemente ist eine Hierarchie-Ebene zuviel erzeugt worden, welche in einem eigenen globalen komplexen Typ namens ArrayOfErfolgType enthalten ist.

455

11

11. XML Schema und OOP

Abbildung 11.13:Über Standard-XML-Serialisierung generiertes XML Schema

11. 3.  XML-Schema-Bindung in Java Mit Hilfe von JAXB (Java Architecture for XML Binding) ist es in Java möglich, XML SchemaDateien an Java-Klassen zu binden und über wenige Programmzeilen zwischen objektorienierten Strukturen und XML-Daten zu wechseln. Mehr Informaionen zu diesem Projekt inden Sie unter htp://jaxb.java.net/. Es besitzt Unterstützung für die Generierung von Java-Klassen aus XML Schema-Daten heraus, den umgekehrten Weg, d. h. die Generierung von XML Schema-Dateien aus Java-Klassen, das Marshalling (Serialisierung von Objekten) und das Unmarshalling (Deserialisierung von XML in Objekte). Sofern Sie nicht ohnehin schon das Java EE-Framework auf Ihrem Rechner installiert haben, laden Sie sich von der Projekt-Seite die aktuelle Sotware herunter. Im bin-Ordner inden Sie dann die beiden benöigten Batch-Dateien jxc.bat (Java-Klassen aus XML Schema generieren) und schemagen.bat (XML Schema aus Java generieren).

456

11

11. XML Schema und OOP

11. 3. 1.  Prinzip der Klassengenerierung aus XML Schema Die klassische Vorgehensweise besteht darin, zunächst zu testen, was überhaupt passiert, wenn man eine einfache XML Schema-Datei zu Klassen umwandelt. Die einfachste XML Schema-Datei ist dabei eine, die im Matrjoschka-Design erstellt wurde. Im nachfolgenden Beispiel ersetzen die drei Punkte jeweils den Pfad zur xjc.bat-Datei, zur XML Schema-Datei und zum Ausgabeordner. C:\...>xjc matrjoschka.xsd parsing a schema... compiling a schema... generated\Erfolguebersicht.java generated\ObjectFactory.java

Die Verwendung des Generators ist relaiv einfach, da er nur wenige Parameter besitzt bzw. auch nicht alle immer benöigt werden. Im allereinfachsten Fall genügt die Angabe des umzuwandelnden XML Schemas. Die allgemeine Syntax ist: xjc [-options ...] Folgende Opionen sind vorhanden: ●

-nv: keine strikte Validierung des XML Schemas

●

-extension: Erweiterungen verwenden, die über die JAXB-Speziikaion hinausgehen

●

-b : Berücksichigung von Koniguraionsdateien zur erweiterten Vorgabe von

Bindungsopionen, wobei mehrere -b-Parameter/-Dateien genutzt werden können

●

-d : Ausgabeverzeichnis

●

-p : Ziel-Paket der generierten Dateien

●

-classpath : weitere benutzerdeinierte Java-Klassen

●

-readOnly: generierte Dateien sind nur lesbar (da sie nicht geändert werden sollen)

●

-xmlschema: Verwendung von W3C XML Schema (Standard)

457

11

11. XML Schema und OOP

●

-relaxng und -dtd: Verwendung von RELAX NG und XML DTD (experimentell)

●

Allgemeines: -quiet (keine Textausgabe), -help (Hilfetext) und -version

Das XML Schema wird ausgelesen, und die erzeugten Java-Klassen inden Sie dann im generated-Ordner/Paket. Im Standardverfahren erzeugt der Generator eine einzige Klasse mit dem Namen des Wurzelelements, welche für jede Ebene im XML Schema-Dokument bzw. Matrjoschka-Design eine staische innere Klasse erzeugt. Die sehen Sie in der Abbildung, in welcher für jede Hierarchie-Ebene der entsprechende Klassenname eingetragen ist.

Abbildung 11.14: Matrjoschka-Design und generierte Klassen

Grundsätzlich ist dieses Verfahren nicht schlecht. Sollten Sie den Abschnit über .NET auch gelesen haben, dann wissen Sie, dass dort die Standardlösung ist, einzelne Klassen zu erzeugen, wobei aber die Namen aus der sich aubauenden Hierarchie abgeleitet werden, was natürlich zu erschreckend langen Klassennamen führen kann. Dies bleibt einem in Java erspart. Dafür muss man aber mit der doch eher umständlichen Notaion für staische innere Klassen umgehen. In der Abbildung sehen Sie die generierten Klassen und ihre jeweilige Referenzierung.

458

11

11. XML Schema und OOP

Abbildung 11.15:Über Matrjoschka-Design generierte Klassen

11. 3. 2.  XML Schema-Bindung Es macht also Sinn, dem Generator ein XML Schema zu liefern, welches zu Klassen führt, mit denen man auch tatsächlich nachher in einer Anwendung arbeiten möchte. Wie auch schon bei .NET ist es überaus zweckmäßig, für jede Hierarchieebene (nur evtl. nicht unbedingt für die oberste Ebene) einen globalen komplexen Typ zu erstellen. Aus jedem einzel-

459

11

11. XML Schema und OOP

nen von ihnen wird dann eine neue Klasse generiert. Auch die Vererbung zwischen UmsatzTyp und GesamtTyp wird in Java umgesetzt.

Abbildung 11.16: Globale komplexe Typen und daraus generierte Klassen

Der Aufruf des Generators bleibt weitestgehend gleich, allerdings haben wir als Beispiel noch ein Verzeichnis, das schon exisieren muss und nicht vom Generator angelegt wird, angegeben. C:\...>xjc komplexeTypen.xsd -d KomplexeTypen parsing a schema... compiling a schema... generated\ErfolgTyp.java

generated\Erfolguebersicht.java generated\GesamtTyp.java

generated\ObjectFactory.java generated\UmsatzTyp.java

460

11

11. XML Schema und OOP

Abbildung 11.17:Über globale komplexe Typen generierte Klassen

Das entstehende Klassensystem sollte nun der Form entsprechen, die man mit Blick auf das XML Schema ohnehin erwarten würde:

461

11

11. XML Schema und OOP

●

Für jede Hierarchie-Ebene erhält man eine eigene Klasse.

●

Die Wiederholung des Erfolg-Elements ist in der Java-Abbildung eine generische Liste der entstehenden Erfolg-Klasse. Es gibt keine set()-Methode, sondern man verwendet die get()-Methode, um die Erfolg-Objekte abzurufen und dann über die add()-Methode der Liste ein neues Objekt einzufügen.

●

Die Eigenschaten sind alle protected, damit man auf sie in Kind-Klassen zugreifen kann.

●

Die Geter- und Seter-Methoden sind alle öfentlich.

●

Aus Elementen und Atributen wurden Felder mit Geter-/Seter-Methoden.

●

Es wurden passende Java-Datentypen für XML Schema-Datentypen verwendet.

In den generierten Dateien beindet sich noch die wichige Warnung, dass man natürlich keine Änderungen an ihnen vornehmen soll. Erweiterungen der Klassen wie neue Eigenschaten oder Methoden müssen dann in Kind-Klassen ergänzt werden. Schließlich wurde hier und beim vorherigen Beispiel noch eine weitere Klasse erzeugt: die ObjectFactory, in der create()-Methoden enthalten sind, welche Instanzen der einzelnen Klassen erzeugen.

11. 3. 3.  Mapping und Serialisierung beeinlussen Manchmal möchte man Strukturen genauer vorgeben oder ganz einfach das Standardverhalten der Bindung überschreiben. JAXB bietet zwei unterschiedliche Möglichkeiten, Bindungseinstellungen vorzugeben: ●

462

11

Zum einen kann man aus Java-Klassen heraus XML Schema-Dateien generieren. Hierzu gibt es zwar viele Standardvorgaben, aber – wie Sie möglicherweise auch schon in vollständigen den Beispielen gesehen haben – in den Klassen setzt man Annotaionen ein, um festzulegen, welche Eigenschaten zu Elementen oder Atributen werden sollen oder wie der Name von Klassen zu globalen komplexen Typen werden soll. Diese Annotaionen haben wir in den vorherigen Abbildungen gelöscht, um nur die Strukturen der Klassen an sich anzugeben.

11. XML Schema und OOP

●

Zum anderen gibt es die Möglichkeit, direkt in der XML Schema-Datei oder sogar in einer externen Bindungsdatei (aber im gleichen Format, was die Einstellungen anbetrit) Angaben zu trefen, wie die Klassen aus einer XML Schema-Datei heraus generiert werden sollen.

Wichig ist zu berücksichigen, dass es nicht nur um die Generierung von Klassen oder XML Schema-Dateien geht, sondern diese ganzen Einstellungen ja auch jedes Mal bei der späteren Übertragung von Objekten oder XML-Daten ausgelesen und genutzt werden. Daher sind dies auch nicht ausschließlich Einstellungen für die Erzeugung, sondern auch solche für das (Un)Marshalling.

11. 3. 3. 1  Annotaion in Java-Klassen Manchmal möchte man die Art der Zuordnung zwischen XML Schema und den Klassen genauer angeben oder aus bestehenden Klassen ein XML Schema erzeugen. Dazu kann man die Klassen mit Annotaionen ausstaten, von denen wir einige in diesem Abschnit kurz vorstellen. Mit XmType kann man für eine Klasse festlegen, welcher globale komplexe Typ erzeugt werden soll, ob er einen Namensraum besitzt (auch einzeln für Elemente deinierbar) oder in welcher Reihenfolge die Eigenschaten der Klasse als XML-Elemente erscheinen sollen. Sämtliche Standardeinstellungen sind so gewählt, dass die Klasse „möglichst gut“ oder „möglichst ähnlich“ abgebildet wird. Dies bedeutet, dass zunächst die Klassennamen oder die bestehende Reihenfolge verwendet werden. @XmlType ( name = “##default”, propOrder = {“”}, namespace = “##default”, factoryClass = DEFAULT.class, factoryMethod = “” )

Mit XmlRootElement legt man dann den Namen für ein Element und seinen Namensraum fest. Man kann es auch ohne diese Angaben verwenden, um eine Eigenschat als Element zu serialisieren. Dies wäre allerdings auch der Standard.

463

11

11. XML Schema und OOP

@XmlRootElement ( name = “##default”, namespace = “##default” )

Mit XmlAccessorType legt man die Standardeinstellungen für Felder, Eigenschaten (haben Geter und Seter) oder einfach öfentliche Felder und Eigenschaten fest. @XmlAccessorType ( value = AccessType.PUBLIC_MEMBER | PROPERTY | FIELD | NONE )

Nachfolgend sind die Einstellungen so gewählt, dass das bestehende XML Schema entsteht. Lediglich der Namensraum ist neu. import javax.xml.bind.annotation.*; @XmlAccessorType(XmlAccessType.FIELD) @XmlType( name = “”, propOrder = {“erfolg”}, namespace = “http://www.ruhrfon.biz” ) @XmlRootElement(name = “Erfolguebersicht”) public class Erfolguebersicht { @XmlElement(name = “Erfolg”, required = true) protected List erfolg; ... AnnotaionenTest/Erfolguebersicht.java: Wurzelelement festlegen

Mit XmlElement legt man dann fest, dass diese Eigenschat als Element serialisiert wird und kann Vorgaben für den Namen, fehlender Textknoten, den Namensraum und auch den Typ machen. Für einfache Datentypen gibt es eine Übertragung zwischen Java und XML Schema (Zeichenketen, Zahlen, Wahrheitswerte). Für komplexe wird natürlich die Klasse der Eigenschat verwendet. @XmlElement (

464

11

11. XML Schema und OOP

name = „##default“, nillable = false, namespace = „##default“, type = DEFAULT.class, defaultValue = „\u0000“ )

Ähnlich verhält es sich mit der Angabe XmlAttribute, wenn eine Eigenschat als Atribut ausgegeben werden soll. Neben Namen und Namensraum kann man noch angeben, ob es opional oder verplichtend ist. @XmlAttribute ( name = ##default, required = false, namespace = „##default“ )

Die Einstellung XmlTransient ist besonders kurz, denn sie hat keine weiteren Angaben und legt nur fest, dass diese Eigenschat nicht in XML erscheint. @XmlTransient

Nachfolgend sind die Einstellungen für die Kind-Elemente und Atribute des Erfolg-Elements zu inden. Sie entsprechen den Einstellungen im schon bekannten XML Schema. Lediglich eine weitere Eigenschat ist neu in Java hinzugekommen, die aber nicht in XML ausgegeben wird. @XmlAccessorType(XmlAccessType.FIELD) @XmlType( name = “ErfolgTyp”, propOrder = { “gesamt”, “proKopf” } ) public class ErfolgTyp { @XmlElement(name = “Gesamt”, required = true) protected GesamtTyp gesamt; @XmlElement(name = “ProKopf”, required = true) protected UmsatzTyp proKopf; // Berücksichtigung mit anderem Namen

465

11

11. XML Schema und OOP

@XmlAttribute(name = “Ort”, required = true) protected String stadt; @XmlAttribute(name = “Monat”, required = true) protected String monat; // Nicht berücksichtigen @XmlTransient private String region; ... AnnotaionenTest/ErfolgTyp.java: Angaben für Elemente und Atribute

Im Verzeichnis, in dem sich auch die Batch-Datei zur Verwendung des Klassengenerators beindet, gibt es eine weitere, mit der man aus Java-Klassen (.java oder .class) eine XML Schema-Datei erzeugen kann. Dies ist schemagen.bat mit einer wiederum einfachen Bedienung: schemagen [-options ...]

Folgende Opionen sind möglich. ●

-d : Ausgabeverzeichnis

●

-cp oder -classpath : Pfad zu weiteren Java-Dateien

●

-help: Hilfetext

Weitere Informaionen: htp://jaxb.java.net/jaxb20-ea3/docs/schemagen.html

11. 3. 3. 2  Deklaraionen für Klassenbindung in XML Schema Auch in XML Schema gibt es die Möglichkeit, Anmerkungen zu hinterlegen, mit denen die Generierung der Klassen und damit natürlich auch die Umwandlung der Objekte-/XMLDaten beeinlusst werden kann. Der wohl häuigste Grund ist ein Mapping zwischen Namen in XML und Java. Aber auch die Aulösung von möglichen Namenskollisionen, komplexe Vorgaben wie der Umgang mit Elementgruppen oder Übertragung von anonymen Typen/ Gruppen zu Klassen sind interessante Anwendungsgebiete. Man spricht hier von Anpassungen (engl. customizaions) und unterscheidet interne und externe Anpassungen:

466

11

11. XML Schema und OOP

●

Bei internen Anpassungen (engl. inline customizaion) trägt man die Anpassungen direkt in das XML Schema. Hierzu verwendet man innerhalb des xs:annotationElements das Kind-Element xs:appinfo. Dieses ist in der Lage, Elemente aus einem anderem Namensraum zu enthalten, sodass man hier deutlich mehr Informaionen eintragen kann, als dies über Fremd-Atribute möglich wäre.

●

Bei externen Anpassungen (engl. external binding customizaion iles) beinden sich die Anpassungen in einer eigenen JAXB-Anpassungsdatei, wobei im Rahmen einer Generierung mehrere solcher Dateien über den –b-Parameter angegeben werden können. Diese folgen dem JAXB-Standard, benöigen allerdings keine besimmte Endung. Es wird .xjb vorgeschlagen.

Die Möglichkeiten sind recht umfangreich und stehen darüber hinaus in einem hierarchischen Verhältnis zueinander. Standardvorgaben werden von globalen Vorgaben überschrieben, welche wiederum von lokalen Einstellungen außer Krat gesetzt werden. Allgemeine Schema-Vorgaben betrefen die Erzeugung des Java-Pakets oder sogar mehrerer Java-Pakete, wenn eine Anpassungsdatei für mehrere XML Schema-Dokumente auf einmal gelten soll. Darüber hinaus enthalten sie Regelungen, welche die allgemeinen Benennungskonvenionen überschreiben.

[ package ] [ ... ]*

Paket-Dokumentation für generiertes Paket “statistik”.]]>



komplexeTypen-Annotaionen.xsd: Angaben für das XML Schema bzw. Paket

Für Elemente oder komplexe Typen ist es wichig, die aus ihnen zu erzeugende Java-Klasse anzugeben. Elemente mit einem Textknoten sowie Atribute können dann zu Eigenschaften umgewandelt werden. Sowohl class wie auch property hat ein name-Atribut. Das Element property erlaubt es dann, bei Elementen mit mehrfachem Autreten die Art der Collecion anzugeben (Array oder Liste) und bei Atributen einen festen Wert auf eine Klassenkonstante zu mappen.

[ ... ]

Umsatz]]>



... komplexeTypen-Annotaionen.xsd: Umbenennen einer Klasse

469

11

11. XML Schema und OOP

Schließlich wird noch festgelegt, dass eine java.util.List als Collecion für die mehrfach autretenden Erfolg-Elemente verwendet wird. Diese wird auch in Java umbenannt, sodass im Namen schon deutlich wird, dass es sich um eine Liste handelt.





komplexeTypen-Annotaionen.xsd: Angabe der Collecion-Art

Dieses erweiterte XML Schema kann man dann ebenfalls mit xjc.bat in Java-Klassen umwandeln.

11. 3. 4.  Von XML zu Objekten Nun fehlen noch zwei Beispiele, die zeigen, wie leicht man über diese gesamte Technik XML-Daten in Objekte umwandeln kann und auch wieder zurück von Objekten in XML gelangt.

11. 3. 4. 1  Marshalling Im ersten Beispiel erstellt man über die generierten Klassen eine verschachtelte Objektstruktur. Im Gegensatz zur Arbeit mit anderen XML-Bibliotheken wie bspw. mit dem DOM (Document Object Model) beschätigt man sich im Quelltext überhaupt nicht damit, dass man später eine XML-Datei generieren will. Man kann auch den Aspekt der XML-Erstellung völlig außen vor lassen und zunächst weiter mit den Objekten arbeiten. Während man beim DOM von vornherein einen überaus langen und meist auch durch Wiederholung geprägten Quelltext erstellt, an dem man manchmal bei sehr ief verschachtelten Strukturen gar nicht mehr erkennen kann, was für eine XML-Struktur über Zeilen hinweg formuliert wird, arbeitet man nun nicht mit einer objektorienierten Dokument-Darstellung, sondern mit einer objektorienierten Daten-Darstellung.

470

11

11. XML Schema und OOP

Die einzelnen Objekte für die Bestandteile der Objektstruktur erstellt man über die create()-Methoden der Klasse ObjectFactory. // Erstellung einer Erfolgsübersicht ObjectFactory of = new ObjectFactory(); Erfolguebersicht uebersicht = of.createErfolguebersicht(); GesamtTyp gesamt = of.createGesamtTyp(); gesamt.setAnrufe(BigDecimal.valueOf(18869)); gesamt.setUmsatz(BigDecimal.valueOf(7154.01)); gesamt.setKunden(200); UmsatzTyp proKopf = of.createUmsatzTyp(); proKopf.setAnrufe(BigDecimal.valueOf(94.35)); proKopf.setUmsatz(BigDecimal.valueOf(35.77)); ErfolgTyp erfolg = of.createErfolgTyp(); erfolg.setMonat(„10.04“); erfolg.setStadt(„Essen, Ruhr“); erfolg.setGesamt(gesamt); erfolg.setProKopf(proKopf); uebersicht.getErfolg().add(erfolg); MarshallingTest.java: Erstellung der Objektstruktur

Man benöigt verschiedene Importe, die nachfolgende aufgelistet sind: import javax.xml.bind.JAXBContext; import javax.xml.bind.JAXBException; import javax.xml.bind.Marshaller; import javax.xml.bind.Unmarshaller;

Man erstellt zunächst einen JAXBContext, der mit dem Namen des Pakets iniialisiert wird, in welchem die verschiedenen Klassen zu inden sind, die beim (Un)Marshalling genutzt werden. Für das Marshalling steht die Klasse Marshaller zur Verfügung, während analog Unmarshaller für den Weg von XML in Objekte genutzt wird. Der Marshaller hat verschiedene Opionen, die über die Methode setProperty() und die Verwendung einer Konstanten gesetzt werden. Zu ihnen zählen JAXB _ ENCODING (String), JAXB _ FOR-

471

11

11. XML Schema und OOP

MATTED _ OUTPUT (Formaierung des XML ein-/ausschalten, Boolean), JAXB _ SCHEMA _ LOCATION (Angabe von xsi:schemaLocation im XML, String) oder JAXB _ NO _ NAMESPACE _ SCHEMA _ LOCATION (analog). Die Methode marshal() ist – wie nicht anders

zu erwarten – in vielen überladenen Varianten vorhanden, damit verschiedene Ausgaben leicht verwendet werden können. // Serialisierung try { JAXBContext jc = JAXBContext.newInstance(„generated“); Marshaller m = jc.createMarshaller(); m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE); m.marshal(uebersicht, new File(„erfolguebersicht.xml“)); } catch (JAXBException e){ e.printStackTrace(); } MarshallingTest.java: Durchführung der Serialisierung

11. 3. 4. 2  Unmarshalling Der umgekehrte Weg ist ebenfalls sehr einfach. Die gerade erzeugte XML-Datei wird über den nachfolgenden Vorgang wieder in eine Objektstruktur eingelesen und kann dann wieder über die Eigenschaten/Felder angesprochen werden. Häte man noch weitere Methoden oder Eigenschaten in pariellen Klassen erstellt, so könnte man diese ebenfalls für die Weiterverarbeitung nutzen. Wie oben schon erwähnt, ist erneut ein Objekt vom Typ JAXBContext, iniialisiert mit dem Paket, welches die zu erzeugenden Klassen enthält, notwendig. Nun erstellt man ein Unmarshaller-Objekt, dessen entscheidende Methode selbstverständlich unmarshal() ist, die in vielen überladenen Varianten exisiert. try { // Deserialisierung JAXBContext jc = JAXBContext.newInstance(„generated“); Unmarshaller u = jc.createUnmarshaller(); Erfolguebersicht uebersicht = (Erfolguebersicht)u.

472

11

11. XML Schema und OOP

unmarshal( new FileInputStream(„erfolguebersicht.xml“)); // Ausgabe und Weiterverwendung Iterator iter = uebersicht.getErfolg().iterator(); while (iter.hasNext()){ ErfolgTyp erfolg = iter.next(); System.out.println(„Anrufe gesamt: „ + erfolg.getGesamt().getAnrufe()); System.out.println(„Anrufe pro Kopf: „ + erfolg.getProKopf().getAnrufe()); } } catch (JAXBException e){ e.printStackTrace(); } catch (FileNotFoundException e){ e.printStackTrace(); } MarshallingTest.java: Deserialisierung von XML in Objekte

JAXB bietet sehr viele fortgeschritene Erweiterungsmöglichkeiten, mit denen man umfassend in die Prozesse der Erstellung von XML Schema oder Klassen eingreifen kann, um die vielen verschiedenen Opionen, die XML Schema bietet, oder die bei der Modellierung in einem konkreten Fall notwendig sind, umsetzen zu können. Darüber hinaus kann man auch in die Prozesse der Daten-Umwandlung selbst eingreifen und Standardverhalten überschreiben oder zusätzliche Logik einbauen.

473

11

Index

Index

Index

Symbols

Ableitung durch Einschränkung 103 Ableitung durch Liste 103 Ableitung durch Vereinigung 103 #all 278, 280, 281, 282 #all 103 ##any 315 ##local 315 Matrjoschka-Design 208 .NET 429 ##other 315 ##targetNamespace 315

A Abgeleitete Datentypen 76 Abhängigkeitstypen 321 Ableitung 330 Atributgruppe 239 Durch Einschränkung 333 Durch Erweiterung 333 Einschränkung 109, 152, 162, 181, 236 Erweiterung 148, 181 Erweiterung 233 Grundproblem 275 Liste 111 Namensraum 241 Techniken 147 Vereinigung 112 von einfachem Inhalt 136 Ableitung 109

Ableitungen 103 Ableitungen kontrollieren 275 Ableitungskontrolle 358 Einfache Typen 280 Elemente 278 Komplexe Typen 279 Schema-Standardeinstellung 281 Ableitungstechniken 277 abstract 267 abstract 264 Abstraktes Element 267 Abstraktes Element 264 ADO 384 all 168 ALL_XML_SCHEMAS 420 ALL_XML_TAB_COLS 420 ALL_XML_TABLES 420 ALL_XML_VIEW_COLS 420 ALL_XML_VIEWS 420 Anforderungen an Schema-Sprachen 40 Anmerkung 363 annotaion 363, 467 Annotaion in Java-Klassen 463 Anpassungen in JAXB 466 any 315 anyAtribute 315 anyType 268 anyURI 72 appinfo 364, 467 atribute 47, 52

475

Index

Atribute 47, 56, 334, 339, 387 Globale Deklaraion 50 Lokale Deklaraion 47 Atribute 46 Element-Ersetzungsgruppe 274 atributeFormDefault 246, 296 atributeGroup 178, 256 atributeGroup 169 Atributgruppe Ableitung 239 Atributgruppen 178, 256 Atributgruppen 261 Atributorienierte Dokumente 65 Auslagerung 105 Auslagerungstechniken 116 Auslagerung und Wiederverwendung 326, 330, 348, 357 Ableitungsgkontrolle 275 Ersetzungsgruppen 257 Globale Elemente und Atribute 255 Import 242 Import mit eigenem Namensraum 251 Übernahme ohne Namensraum 249 Auslagerung und Wiederverwendung 227 Gruppen 255 Auslesen von Kommentaren 369 Fremd-Atribute 379 XHTML nach HTML 377 Auslesen von XML-Kommentaren 370 Auslesen von XML-Schema-Kommentaren In HTML 375 In Textdatei 373 Auswahl 166

B Babuschka. Siehe Matrjoschka Babuschka-Design 294, 296, 301, 357 base 102, 109, 238 base64Binary 74

476

Basistyp 102 Baumdiagramm-Ansatz 29 Beliebige Inhalte akzepieren 314 Beziehungen 39, 55 block 278, 279 block 277 blockDefault 281 Blockdiagramm-Ansatz 28 boolean 72 bounded 90

C

cardinality 90 Chamäleon-Design 311 Charakterisierung von Elementen 21 choice 166 complexContent 155 complexType 44, 129, 160, 171, 176, 180 complexType 128 createNonSchemaBasedXML() 417 createSchemaBasedXML() 417 CREATE XML SCHEMA COLLECTION 421

D Data Dicionary-Sichten MS SQL Server 426 Oracle 420 date 73 Datenbank 324 XML Schema-/Klassen-Mapping 438 Datenbank-Datenmodellierung 384 Datenbanken MS SQL Server 421 Oracle 411 XML-Tabelle in Oracle 415 Datenbanken und XML 409 Datenbeschreibung 386 Datenmodellierung 384 Datenorienierung 337

Index

Dokumentenmodellierung 337 Datenmodellierung 387, 389 Datenorienierung 54, 337 Datenstruktur 64 Datentypen Abgeleitet 76 Ableitung 88 Basistyp 102 Binärdaten 74 Eigene 102 Globale 105 Listentypen 81 Logik 72 Vordeinierte 71 Zahlen 72, 79 Zeichenketen 72, 77 Zeitangaben 73 Datentypen 347, 384 Datentypen durch Ableitung deklarieren 109 dateTime 73 DBMS_XMLSCHEMA 411 DB-Strukturen 389 DDL 386 decimal 72 Deiniion von Eindeuigkeit 215 Deiniion von Schlüsseln 204 deleteSchema() 413 Deserialisierung 435 Design-Alternaiven 357 Direkter Inhalt 156 DocBook 23 documentaion 364, 377 Dokumentaion 360, 361 Dokumentenorienierung 54, 337 Dokumentmodellierung 39, 320, 331, 333 Atribute 56 Atributorienierte vs. elementorienierte Technik 65

Baumdiagramm 29 Bewertungskriterien verschiedener Techniken 63 Blockdiagramm 28 Datenorienierung 54 Dokumentenorieniert 179 Dokumentenorienierung 54 Erweitertes Baumdiagramm 30 Schlüssel 194 Syntax-Änderungen 321 Techniken im Vergleich 58 Dokumentypen 24 DOM 322, 452 double 72 DTD 10, 131 Schlüssel 194 duraion 73

E Eigene Datentypen 102 Eindeuigkeitsbeschränkung 214 Einfache Inhalte 155 Einfacher Inhalt Ableitung durch Einschränkung 139, 162 Ableitung durch Erweiterung 137 Einfache Typen 330 Einfache Wiederverwendung 228 Einschränkende Fasseten 91 Einzigarigkeitsbeschränkung bei Auswahl 219 element 43, 49 Element-Benennung 334 Elemente 334, 387 Globale Deklaraion 49 Element-Ersetzungsgruppe 274 Element-Ersetzungsgruppen 262 elementFormDefault 246, 296 Elementgruppen 171, 256 Elementgruppen 259

477

Index

Elementorienierte Dokumente 65 ENTITIES 79 ENTITY 78 Entwicklungsphase in XML-Projekten 21 enumeraion 96 equal 90 ER-Modell 386 Ersetzungsgruppen 269 Ersetzungsgruppen für Elemente 257 Erweiterbare Schemata 333, 357 Erweiterbarkeit 357 Erweitertes Baumdiagramm 30 Existenz 328 extension 278, 280, 281, 282 extension 135 Extrakion von XML-Kommentaren 372

F Fasseten Deiniion 88 Dezimalauteilung 100 Einschränkende Fasseten 91 Grenzen und Schranken 98 Grundlegende Fasseten 90 Längenangaben 93 Wertmuster 95 ield 205, 402 inal 278, 279 inal 277 inalDefault 282 loat 72 FO 23 form 246 fracionDigits 101 Fremd-Atribute 368

G gDay 74 Gemischte Inhaltsmodelle 179

478

Gemischter Inhalt 129 Ableitung durch Einschränkung 181 Ableitung durch Erweiterung 181 getNamespace() 418 getRootElement() 418 getSchemaURL() 418 Globale Deklaraion 48, 49, 128 Globale Komponenten 357 gMonth 74 gMonthDay xs gMonthDay 74 group 171, 176 group 166, 169, 255 Gründe für die Verwendung von globalen Datentypen 105 Grundlegende Fasseten 90 Gruppen 169 Atribute 178 Elemente 171 Gruppierungen 255, 330 Gülig 25 Güligkeitsbereiche von Schlüsseln 211 gYear 74 gYearMonth 73

H Häuigkeit 130 hexBinary 74 Hierarchie 55, 329 Hierarchie 339, 353 Hierarchiebeziehungen 329 HTML 20, 324

I IBM DB2 415 ID 78, 193, 197 Ideniikaion 105 Ideniikaion von Elementen 21

Index

Idenität 39, 55 IDREF 197 IDREF 78 IDREFS 78 IDREFS 199 import 243, 310 Import 357 Import 242, 251, 275, 301, 307, 333 Import-/Export-Schnitstellen 410 include 227 Inhaltsmodell 20, 39 Einfache Inhalte 155 Inhaltsmodelle 155 Auswahl 166 Gemischte Inhaltsmodelle 179 Gruppenbildung 169 Reihenfolge 163 Zusammenstellung 168 Inklusion 275, 333 Inklusion 227, 301, 311, 312, 357 Instanzdokument 24, 31 int 79 integer 79 isSchemaBased() 417 isSchemaValid() 417 isSchemaValidated() 417 itemType 111

J Java 429 jaxb class 468 nameXmlTransform 467 package 467 property 468 schemaBindings 467 JAXB 456 JAXBContext 471

K Kardinalität 39, 55, 130, 328 key 204, 295 key 399 keyref 295, 400 keyref 399 Knotenlokalisierung 64, 68 Kommagetrennte Werte 324 Kommentare 368 Kommentar-Elemente 363 Komplexe Inhalte 163 Komplexen Typen 128 Komplexe Typen 330, 345 Ableitung durch Einschränkung 152 Ableitung durch Erweiterung 148 Globale komplexe Typen 141 Lokale komplexe Typen 128 Kopf-Element 267, 277

L language 77 lax 315 Leerzeichenbehandlung 97 length 93 Lesbarkeit 63 list 280, 282 Liste 111 Listentypen 81 Beispiel 83 Lokale Deklaraion 47, 128 Lokale komplexe Typen 128 Lokalisierung 64, 68 long 79

M Mapping zwischen XML und Objekten 431 Marshalling 435 Java 470 .NET 452

479

Index

Übersicht 434 Matrjoschka-Design 129, 133, 440 maxExclusive 98 maxInclusive 98 maxLength 94 maxOccurs 52, 131 maxOccurs 152, 164 Mehrfache Einfügung von Dokumenten 242 Mehrfachverweise 199 memberTypes 112 minExclusive 99 Minimalanforderungen an Inhaltsmodelle 40 minInclusive 99 minLength 93 minOccurs 131, 152 minOccurs 164 mixed 180 Modellierung 21, 26 MS SQL Server 410 Data Dicionary-Sichten 426 Typisiertes XML 423 XML Schema registrieren 421

N name 102 Name 78 Namensraum 418 Namensräume 241, 377 Chamäleon-Design 311 Keine Übernahme 311 Verwendung eines einzigen Namensraums 288 Verwendung mehrerer Namensräume 300 Namensräume 251, 287 Übernahme 306 Verwendung bei globalen

480

Komponenten 304 namespace 303, 315 namespace 243 NCName 78 negaiveInteger 79 NMTOKEN 78 NMTOKENS 78 nonNegaiveInteger 80 nonPosiiveInteger 79 normalizedString 77 NOTATION 72 numeric 90

O OASIS 11 ObjectFactory 462, 471 Objektorienierung 430 Objektypen generieren 412 ODBC 384 Oracle 406, 410 Data Dicionary-Sichten 420 Relaionale Daten in XML 415 SQL/XML-Funkionen 415 Typisiertes XML 416 XML Schema registrieren 411 XMLType-Tabelle 415 XSLT, XPath und XQuery 419 Oracle 389 ordered 90 OR-Modell 386

P patern 95 patern 118 PDF 23, 324 posiiveInteger 80 processContents 315 Projektphasen bei XML-Einsatz 22 Projektphasen eines XML-Projekts 15

Index

Prüfung 25

Q QName 72

R RDF 322 redeine 227 redeine 233 Redeiniion 233, 301 Redeiniion 275, 311, 313, 357 ref 50, 52, 171, 176, 261, 277 refer 220 Reformulierung Mit Eigenschatsänderung 328 Ohne Eigenschatsänderung 330 Reformulierung Ohne Eigenschatsänderung 328 Regeldokument 24, 33 registerSchema() 411 registerURI() 413 Reguläre Ausdrücke 118 Einfache Muster 118 Kurzschreibweisen 122 Meta-Zeichen 120 Zusammengesetzte Muster 119 Reihenfolge 39, 55, 163, 329 Relaionale Daten in XML Oracle 415 Relaionalen Daten in XML MS SQL Server 423 RelaxNG 11 restricion 238, 278, 281, 282 restricion 102, 135, 152, 280

S SAX 322 Schema-Dokument 24 schemagen.bat 466

schemaLocaion 303, 310 schemaLocaion 243 schemaValidate() 417 Schlüssel 199, 203 ID und IDREF 193 Schlüssel 205, 209 selector 205, 402 sequence 132 sequence 164 Serialisierung 435 setSchemaValidated() 417 SGML 11 short 79 simpleContent 155 simpleContent 135 simpleType 102, 104, 112, 160 simpleType 109 skip 315 source 364 Speicherung von XML 410 Spezialisierung 106 SQL 364, 384, 386, 392, 406, 408 SQL/XML-Funkionen 415 Standard DocBook 23 DTD 10 FO 23 HTML 20 PDF 23 RelaxNG 11 SGML 11 XDR 10 XML 11, 21 XSL-FO 23 XSLT 11 Standardnamensraum 289 strict 315 string 72 Strukturänderungen 328

481

Index

subsituion 278 subsituion 281 subsituionGroup 262, 268 subsituionGroup 257 SVG 364 Syntax-Änderungen 326 Syntax-Änderungen in XML-Schema 321 sys.xml_schema_collecions 426 sys.xml_schema_namespaces 426

T

unsignedInt 80 unsignedLong 80 unsignedShort 80 Untypisiertes XML 418 use 152 USER_XML_SCHEMAS 420 USER_XML_TAB_COLS 420 USER_XML_TABLES 420 USER_XML_VIEW_COLS 420 USER_XML_VIEWS 420

Tabellenfelder Als Atribute 388, 398 Als Kind-Elemente 394 Kind-Elemente 387 targetNamenspace 242 targetNamespace 243, 294, 303 Textknoten 156 ime 73 token 77 Tokenliste 202 totalDigits 100 Transformaion in SQL 394 Transformaionsdokument 24, 35 type 144, 255, 277 Typisiertes XML 416, 423

V

U

W

Übernahme ohne Namensraum 249 UML 429 union 112, 280 union 282 unique 204, 214 unique 295 Unmarshalling 435 Java 472 .NET 453 Übersicht 434 unsignedByte 80

W3C 10 whiteSpace 97 Wiederverwendung mit Redeiniion 233 Wohlgeformt 25 Wurzelelement 418

482

Validierung 22, 25 Gülig 25 Wohlgeformt 25 Verlechtung von Elementen 21 Vergleich DTD und XML-Schema 41, 43, 47, 85, 130, 193, 196, 200, 294, 332 Verweise auf Eindeuigkeitsbeschränkungen 220 Verweise auf Schlüssel 220 Verwendung von einem einzigen Namensraum 288 Verwendung von globalen Datentypen 105 VisualXSD 440 Vordeinierte Datentypen 71

X XDR 10 XHTML 377 XHTML-Daten 366 xjc.bat 457

Index

xml lang 364 XML 11, 21, 322 Buchempfehlungen 14 Gülig 25 Projektphasen 15 Wohlgeformt 25 XmlAtribute Java 465 .NET 447 XML-Daten in Objekte 429 XML-Eingabestrom 24 XmlElement Java 464 .NET 446 XML-Kommentare 361 XML-Kommentaren 370 xmllang 288 xmlns 288, 294, 296 XmlRoot 445 XmlRootElement 464 XML Schema MS SQL Server 421 Oracle 411 URL 418 Vergleich mit Klassen 433 XMLSchema Verrweise zu den Standards 13 XML Schema-Klassen-Bindung 435, 441, 443, 458, 460 XML Schema-OO-Mapping Java 466 Java-Annotaionen 462 .NET-Atribute 444 XmlSerializer 454 XML Spy 133 XMLSpy 366, 384, 386 XML Topic Maps 322 XmlTransient 465

XmlType .NET 445 XmType Java 463 XPath 64, 68, 173, 206, 221, 246, 262, 290, 354, 371, 373, 377, 380, 401 XPath 295, 328 xs all 168 annotaion 363 any 315 anyAtribute 315 anyType 268 anyURI 72 appinfo 364 atribute 47, 52 atributeGroup 169, 178, 256 base64Binary 74 boolean 72 choice 166 complexContent 155 complexType 44, 128, 129, 160, 176, 180 date 73 dateTime 73 decimal 72 double 72 duraion 73 element 43, 49 ENTITIES 79 ENTITY 78 enumeraion 96 extension 135 ield 205, 402 loat 72 fracionDigits 101 gDay 74 gMonth 74 group 166, 169, 171, 176, 255 gYear 74

483

Index

gYearMonth 73 hexBinary 74 ID 78, 197 IDREF 78 IDREF 197 IDREFS 199 IDREFS 78 import 243 include 227 int 79 integer 79 key 204, 295, 399 keyref 295, 399, 400 language 77 length 93 long 79 maxExclusive 98 maxInclusive 98 maxLength 94 maxOccurs 164 minExclusive 99 minInclusive 99 minLength 93 minOccurs 164 Name 78 NCName 78 negaiveInteger 79 NMTOKEN 78 NMTOKENS 78 nonNegaiveInteger 80 nonPosiiveInteger 79 normalizedString 77 NOTATION 72 patern 95, 118 posiiveInteger 80 QName 72 redeine 227, 233 restricion 135, 152 selector 205, 402

484

sequence 132, 164 short 79 simpleContent 135, 155 simpleType 102, 104, 112, 160 string 72 ime 73 token 77 totalDigits 100 union 112 unique 204, 214 unique 295 unsignedByte 80 unsignedInt 80 unsignedLong 80 unsignedShort 80 whiteSpace 97 xs\ annotaion 467 appinfo 467 XSD.exe 439, 449 XSL 23 XSL-FO 23 XSLT 11, 375, 386, 394 XSLT 15, 37, 243, 295, 400

Z Zerlegung von XML 410 Zusammenstellung 168

Unsere Empfehlungen

Die • Empfehlung des Hauses •

Empfehlungen

XML: Standards und Technologien

Skulschus Wiederstein Themen • Einführung in XML: Deinition, Architektur, Einsatzbereiche • Modellierung mit der Document Type Deinition (DTD) und XML Schema • Filtern und lokalisieren mit XPath • Abfragen und umwandeln mit XQuery • Abfragen, umwandeln, darstellen und verarbeiten mit XSLT • Druckformate darstellen mit XSL-FO • (Objekt)relationale Datenbanken und XML – MS SQL Server und Oracle • Architektur und Techniken von Webservices: Deinition, Einsatz, SOAP und WSDL 416 Seiten, € 39,95 ISBN: 978-3-939701-21-7

Inhalt XML (eXtensible Markup Language) ist seit mehreren Jahren als Technologie für die Abbildung, den Transport und die Speicherung von strukturierten Daten etabliert und stellt in immer mehr IT-Prozessen und Anwendungen einen wesentlichen Baustein dar. Dieses Buch erklärt die gängigen Standards und Technologien, die im Bereich XML eingesetzt werden, liefert dabei zu jedem Thema viele Syntax-Beispiele und gibt Hinweise zum richtigen Einsatz. Sie lernen die beiden Standards DTD und XML Schema für die Modellierung und Validierung von XML-Daten kennen. Mit Pfadausdrücken in XPath sehen Sie, wie Sie Knoten lokalisieren und XML-Strukturen iltern, während Sie mit XQuery ganz neue XML-Dokumente auf Basis von SQL-ähnlichen Abfragen erzeugen. Die tatsächliche Umwandlung von XML sehen Sie anhand von XSLT für HTML, XML und Text und anhand von XSL-FO für Druckformate wie PDF. Serviceorientierte Architekturen werden mit Webservices aufgebaut, die ebenfalls in diesem Buch mit einer allgemeinen Beschreibung und den beiden wesentlichen Standards SOAP und WSDL eingeführt werden.

486

Empfehlungen

XSL-FO

Skulschus Kozik Wiederstein Themen • Seitenvorlagen, Seitenverlaufsvorlagen und Dokumentaufbau Blöcke und Gebiete, Tabellen und Listen • Zeichen- und Absatzformatierung, Graik und Farbe • Bucherstellung, Inhaltsverzeichnis, Verweise und Links, lebende Kolumnentitel, Seiten- und Absatzkontrolle • Wieder verwendbare Komponenten • Einsatz in .NET und Java 300 Seiten, € 24,95 ISBN: 978-3-939701-17-0

Inhalt XSL-FO (eXtensible Stylesheet Language / Formatting Objects) ist eine W3C-Syntax, die speziell für die Transformation von XML-Dokumenten in PDF- und andere Druck-Formate geschaffen wurde. Dabei stellen die Formatierungsobjekte eine Zwischenschicht dar, in der die XML-Daten zunächst umgewandelt werden, bevor sie mit einem geeigneten Prozessor in hr Zielformat gebracht werden. Dieses Buch enthält alles, was man zum Einsatz von XSLFO benötigt: eine Darstellung des Standards, sehr viele Beispieldateien, Schemazeichnungen zum besseren Verständnis und Referenzen. XSL-FO-Prozessoren sind kostenlos und – je nach Anforderung – kostenplichtig erhältlich. Dieses Buch setzt den Open Source-Prozessor Apache FOP ein und zeigt seine Verwendung in Java und .NET. XSL-FO entfaltet mit den beiden anderen Standards XSLT und XPath seine wahre Größe, da so die Möglichkeit besteht, komplexe Transformationen und Algorithmen zur Umwandlung zu erzeugen, die ebenfalls in XSLT eingebettet sind und anstelle von typischen HTML-Ausgaben nun PDF erzeugen können.

487

Empfehlungen

XSLT, XPath und XQuery

Skulschus Wiederstein Winterstone Themen • XSLT 1.0:Vorlagen/Templates, Kontrollanweisungen,Variablen und Parameter, Sortierungen und Gruppierungen, Ausgaben in HTML, Text/ CSV und XML • XSLT 2.0: Stylesheet-Funktionen, dynamisches XSLT, 2.0-Besonderheiten, Integration von XML Schema, strukturgetriebene Verarbeitung • XPath 1.0: Grundlagen, Knoten lokalisieren und iltern, Funktionsbibliothek • XPath 2.0: Kontrollanweisungen, 2.0-Besonderheiten und –Funktionen • XQuery 1.0: Abfragen und Umwandlung als Ersatz von XSLT/XPath • Integration: Einsatz in .NET, Java, PHP und Datenbanken (Oracle PL/SQL, MS SQL Server T-SQL)

470 Seiten, € 44,95 ISBN: 978-3-939701-50-7

Inhalt XSLT (eXtensible Stylesheet Language for Transformations) ist eine W3C-Syntax, die speziell für die Transformation von XML-Dokumenten geschaffen wurde. Mit XSLT können XMLDokumente in Formate wie HTML, Text und andere XML-Formate transformiert werden. Diese Technologie lässt sich in (fast) allen Programmiersprachen und in vielen Datenbanken nutzen und stellt die beste Möglichkeit dar, aus mehreren Anwendungen heraus die gleiche XML-Transformation aufzurufen. XPath setzt man als in XSLT eingebettete Pfadbeschreibungssprache für Lokalisierung, Filterung und Bearbeitung von XML-Knoten ein. XQuery teilt sich mit XPath die Funktionsbibliothek und bietet als „SQL für XML“ die Möglichkeit, im Rahmen einer Abfrage komplexe Ausgabeströme in XML anzugeben und stellt so eine verkürzte Technik für XSLT und XPath dar. Dieses Buch führt Einsteiger durch die genannten Umwandlungstechniken.

488

Skulschus | Wiederstein | Winterstone

XML Schema Verlag

Themen • Modellierung von einfachen XML-Strukturen mit XML Schema • Typbibliothek von XML Schema und Erstellung eigener abgeleiteter Datentypen • Komplexe Inhaltsmodelle und globale komplexe Datenstrukturen und Vererbung • Schlüssel und Verweise in XML-Dokumenten deinieren • Auslagerung und Wiederverwendung • Deklaration und Verwendung von Namensräumen • Beschreibung von Datenbankmodellen mit XML Schema • Generierung von SQL mit Hilfe von XSLT aus XML Schema • Verwendung von XML Schema in Oracle und MS SQL Server

Comelio Medien gehört zur Comelio GmbH, einem in Europa und den USA arbeitenden IT-Unternehmen. Der Verlag bietet den Mitarbeitern der Comelio GmbH die Gelegenheit, Technologien aus ihren Projekten in Buchform aufzubereiten und ihr Wissen der Entwicklergemeinde zur Verfügung zu stellen. An verschiedenen Standorten führen sie auch Seminare zu ihren Themen durch.

Inhalt

Autoren

XML Schema ist der W3C-Nachfolger zur Document Type Deinition (DTD). Er stellt die Deinition von datenorientierten Dokumenten in den Vordergrund und bietet umfangreiche Möglichkeiten, feine Angaben zu XML-Strukturen zu treffen. Mit diesem Buch erhalten Sie eine vollständige Einführung in XML Schema, sodass Sie in der Lage sind, eigene SchemaDeinitionen unter Anwendung aller Mechanismen zu erstellen. Dazu gehören Deinition von Elementen und Attributen, Zuweisung und Erstellung von Datentypen, Auslagerung und Wiederverwendung von Teil-Dokumenten und Ableitung von globalen Strukturen oder auch den Einsatz von Schlüsseln und Verweisen. Sie lernen auch, wie Sie XML Schema-Dokumente für die Beschreibung von Datenbankstrukturen verwenden und diese mit XSLT in SQL-Quelltext transformieren können. Dabei unterstützen Sie Beispiele aus dem Umfeld einer Spielirma, Vergleiche mit der DTD und die Abbildung von Syntaxstrukturen in Zeichnungen.

Marco Skulschus, Marcus Wiederstein und

Auf der Webseite zum Buch inden Sie alle XML-, DTD- und XML Schema-Dateien zum Download.

Einsteiger

www.comelio-medien.com

Softwareentwicklung und Weiterbildung bei der Comelio GmbH. Sie beschäftigen sich seit Beginn der XML-Zeitrechnung mit diesem Thema. Spezialgebiete sind hierbei Datenbanken und XML sowie Ontologien auf XML-Basis. Dies ist ihr zehntes Buch zum Thema XML mit Verkaufszahlen über 15.000 Exemplaren. Bis jetzt liegen Bücher zu einzelnen XML-Standards und zur Verwendung von XML in Datenbanken vor. Ihre Kurzreferenzen zu vielen XML-Themen verkauften sich über 40.000 mal.

Ebenfalls erhältlich:

Internet

Medien

Sarah Winterstone arbeiten im Bereich

Fortgeschrittene

© 2011 Comelio GmbH

XSLT, XPath und XQuery ISBN 978-3-939701-50-7

Prois

29,95 € (D) ISBN 978-3-939701-57-6

9 783939 701576