XML-Schema. Einordnung

Transkript

1 Einordnung Es gab/gibt eine Reihe von Erweiterungen und Vorschlägen hinsichtlich neuer Schemasprachen. Die größte praktische Bedeutung hat der W3C-Standard XML Schema Definition Language (XSD) kurz:xml-schema Verabschiedung von XSD als W3C-Recommendation.! XML-Schema bildet zusammen mit XML 1.0 und den Namensräumen die Basis aller weiteren W3C-XML-Sprachstandards.! Mittelfristig werden die Grammatiken neu entwickelter XML-Sprachen nicht mehr in der DTD-Syntax formuliert. WT: III-139 Document Languages c STEIN

2 Einordnung (Fortsetzung) Wichtige XML-Sprachen und ihre Grundlagen [ Jeckle 2004 ] : SOAP WSDL XSLT XQuery XML- RDF XHTML XLink Schema XPath XMI XML Namespaces UML Extensible Markup Language DTD Text MOF XML Infoset Unicode WT: III-140 Document Languages c STEIN

3 Bemerkungen:! XSD ist eine Weiterentwicklung von XML: unpraktikable oder fehlerträchtige Sprachbestandteile von SGML werden nicht mehr durch den Grammatikmechanismus unterstützt. Beispiel: Entities können nicht durch Schemata ausgedrückt werden.! Der XSD-Sprachvorschlag gliedert sich in zwei Teilbereiche: XSD-Part 1 Structures InhaltsmodellefürElemente, Attributstrukturen und wiederverwendbare Strukturen. Bildet die Konzepte von DTDs nach. XSD-Part 2 Datatypes Festlegunginhaltlicher Charakteristika wie Datentypen und Constraints zur Konsistenzerhaltung. Es handelt sich um ein eigenständiges Typsystem, das auch in anderen W3C-Arbeitsgruppen Verwendung findet. [vgl. Jeckle 2004 ] WT: III-141 Document Languages c STEIN

4 DTD versus XML-Schema <!ELEMENT Buch (Titel, Subtitel?, Autor+, Preis)> <!ATTLIST Buch ISBN ID #REQUIRED> <!ELEMENT Titel (#PCDATA)> <!ELEMENT Subtitel (#PCDATA)> <!ELEMENT Autor (#PCDATA)> <!ELEMENT Preis (#PCDATA)> WT: III-142 Document Languages c STEIN

5 DTD versus XML-Schema <!ELEMENT Buch (Titel, Subtitel?, Autor+, Preis)> <!ATTLIST Buch ISBN ID #REQUIRED> <!ELEMENT Titel (#PCDATA)> <!ELEMENT Subtitel (#PCDATA)> <!ELEMENT Autor (#PCDATA)> <!ELEMENT Preis (#PCDATA)> <xsd:schema...> <xsd:element name="buch"> <xsd:complextype> <xsd:attribute name="isbn" type="xsd:string" use="required"/> <xsd:all> <xsd:element name="titel" type="xsd:string"/> <xsd:element name="subtitel" type="xsd:string" minoccurs="0" maxoccurs="1"/> <xsd:element name="autor" type="xsd:string" minoccurs="1"/> <xsd:element name="preis" type="xsd:decimal"/> </xsd:all> </xsd:complextype> </xsd:element> </xsd:schema> WT: III-143 Document Languages c STEIN

6 Bemerkungen:! Das Gewöhnungsbedürftige (a) bei XML-Schema ist, dass die (kontextfreie) Grammatik zur Definition einer Dokumentenstruktur nicht mehr in der Form von Regeln, sondern objektorientiert, mittels XSD-Elementinstanzen und deren Schachtelung definiert wird.! Das Gewöhnungsbedürftige (b) bei XML-Schema ist, dass die Syntax der Metasprache (hier: Sprache zur Definition neuer Elementtypen im XML-Schemadokument) gleich der Syntax der Objektsprache (hier: Sprache zur Instanziierung vonelementtypenim XML-Instanzdokument) ist: die Elementinstanzen in einem XML-Schema definieren neue Elementtypen, die in einem XML-Instanzdokument instanziiert werden können.! Beachte, dass Instanzen des <xsd:element>-elements sowohl mit Inhalt (zwischen öffnendem und schließendem Tag) als auch leer Verwendung finden. Die Syntax im ersten Fall folgt dem Entwurfsmuster zur gleichzeitigen Definition eines Elementtyps und eines neuen (hier: anonymen, komplexen) Datentyps; die Syntax im zweiten Fall folgt dem Entwurfsmuster zur Definition von Elementtypen unter Rückgriff auf einen existierenden Datentyp. WT: III-144 Document Languages c STEIN

7 DTD versus XML-Schema (Fortsetzung) Grenzen von DTDs:! DTDs sind schwer zu lesen bzw. zu verstehen. Das betrifft vor allem die Konzepte zur Strukturierung.! DTDs sind nachträglich nicht erweiterbar. Die Definition einer DTD muss vollständig sein und sämtliche Regeln für ihre Anwendung definieren.! DTDs unterstützen nur wenige Datentypen; das Typsystem ist nicht erweiterbar.! DTDs erschweren die Wiederverwendbarkeit: Elementstrukturen können nur innerhalb der definierenden DTD wiederverwendet werden, Attribute sind immer an das umgebende Element gebunden.! DTDs unterstützen keine Vererbung.! Die DTD-Syntax ist nicht XML-konform.! DTDs unterstützen keine Namensräume. WT: III-145 Document Languages c STEIN

8 DTD versus XML-Schema (Fortsetzung) Durch die Datentypen in XML-Schema sind Aufgaben einfacher geworden:! Definition von Constraints für zugelassenen Inhalt! Überprüfung der Korrektheit von Daten! Verarbeitung von Daten aus Datenbanken! Spezialisierung und Anpassung von Datentypen! Definition komplexer Datentypen! Konvertierung zwischen Daten verschiedenen Typs Weitere Errungenschaften:! XML-Schemata sind modular verwendbar! XML-Schemata sind in XML-Syntax geschrieben! XML-Schemata verwenden das XML-Namensraumkonzept WT: III-146 Document Languages c STEIN

9 DTD versus XML-Schema (Fortsetzung) Unterscheidung von Dokumenten hinsichtlich ihres Aufbaus: 1. Erzählende (narrative) Dokumente. Dokumente, die aus Abschnitten und Unterabschnitten bestehen; die gesamte Struktur ist weitgehend linear: Bücher, Artikel, etc. 2. Datensatzartige Dokumente. stark typisierte Dokumente; zielen auf Datenaustausch ab DTDs sind gut für erzählende Dokumente geeignet, XML-Schema eignet sich gut für datensatzartige Dokumente. WT: III-147 Document Languages c STEIN

10 Aufbau eines XML-Schemas XML-Schemata sind XML-Dokumente: XML- Schema Prolog Body <?xml version="1.0"...?> <xsd:schema xmlns:xsd=... targetnamespace=...> <xsd:element name=...> <xsd:complextype>... </xsd:element> </xsd:schema>! Wurzelelement jedes XML-Schemas ist das Element <xsd:schema>.! Die Attribute von <xsd:schema> definieren Eigenschaften, die für alle im Schema definierten Elemente und Attribute gelten.! Alle Definitionen eines Schemas sind Kindelemente von <xsd:schema> (direkt oder tiefer geschachtelt).! Direkte Kindelemente von <xsd:schema> sind globale Elemente.! Vergleiche hierzu die Grundlagen zum XML-Dokument. WT: III-148 Document Languages c STEIN

11 Bemerkungen:! Globale Elemente können als Wurzelelement eines Instanzdokuments verwendet werden.! Die Dateiendung einer XML-Schemadatei ist.xsd. WT: III-149 Document Languages c STEIN

12 Aufbau eines XML-Schemas (Fortsetzung) <?xml version="1.0"?> <xsd:schema xmlns:xsd=" targetnamespace=" elementformdefault="qualified"> <xsd:element name="note"> <xsd:complextype>... </xsd:element> </xsd:schema> WT: III-150 Document Languages c STEIN

13 Aufbau eines XML-Schemas (Fortsetzung) <?xml version="1.0"?> <xsd:schema xmlns:xsd=" targetnamespace=" elementformdefault="qualified"> <xsd:element name="note"> <xsd:complextype>... </xsd:element> </xsd:schema>! Jedes XML-Schema ist eine eigenständige Datei; die Einbettung in das Instanzdokument, also die Bildung eines Internal Subset, ist nicht möglich.! Zwei Arten von Namensräumen, die deklariert werden können: 1. Ein oder mehrere Namensräume, ausdenendieimschema verwendeten Elemente stammen. 2. Ein Zielnamensraum, zudemdieimschemadefinierten Elemente und Attribute gehören. WT: III-151 Document Languages c STEIN

14 Bemerkungen:! Elemente und Attribute aus dem standardisierten XSD-Vokabular, die in Schemadokumenten verwendet werden, gehören zum Namensraum Übliches Präfix ist xsd: oder manchmal auch xs:, kann aber beliebig gewählt werden.! Alle im Schema definierten Elemente und Attribute sind dem Zielnamensraum zugeordnet. Bei ihrer Instanziierung in einem (schemagültigen) Instanzdokument müssen sie aus dem entsprechenden Namensraum stammen, also entsprechend qualifiziert sein. Auch bei Referenzen innerhalb des Schemas muss diese Namensraumzugehörigkeit berücksichtigt werden.! Das targetnamespace-attribut, also die Deklaration eines Zielnamensraums, ist optional.! Durch Angabe der Attribute elementformdefault und attributeformdefault lässt sich die Vererbung des Zielnamensraums für das Instanzdokument steuern. Standdardmäßig sind diese Attribute auf unqualified gesetzt und ein auf oberster Ebene deklarierter Zielnamensraum bezieht sich auch auf die lokalenelementeund Attribute. Wird der Wert der beiden Attribute auf unqualified gesetzt, so sind die lokalen Elemente und Attribute als unqualified deklariert. WT: III-152 Document Languages c STEIN

15 Verknüpfung von XML-Schema und Instanzdokument <?xml version="1.0"?> <note xmlns=" xmlns:xsi=" xsi:schemalocation=" note.xsd"> <to>tove</to> <from>jani</from> <heading>reminder</heading> <body>don t forget me this weekend!</body> </note> WT: III-153 Document Languages c STEIN

16 Verknüpfung von XML-Schema und Instanzdokument <?xml version="1.0"?> <note xmlns=" xmlns:xsi=" xsi:schemalocation=" note.xsd"> <to>tove</to> <from>jani</from> <heading>reminder</heading> <body>don t forget me this weekend!</body> </note>! Die Attribute schemalocation und nonamespaceschemalocation dienen zur Referenz auf ein Schema. Genau eines muss angegeben sein abhängig davon, ob das Schema einen Zielnamensraum festlegt.! Der erste Parameter von schemalocation ist ein URI für den Zielnamensraum;derzweite Parameter ist eine relative oder absolute URL, die angibt, wo das Schema gefunden werden kann.! nonamespaceschemalocation hat nur den URL-Parameter für das Schema. WT: III-154 Document Languages c STEIN

17 Bemerkungen:! Elemente und Attribute aus dem standardisierten XSD-Vokabular, die in Instanzdokumenten verwendet werden, gehören zum Namensraum ÜblichesPräfixistxsi:, kannaber beliebig gewählt werden. WT: III-155 Document Languages c STEIN

18 Verknüpfung von XML-Schema und Instanzdokument (Fortsetzung) XML-Schemadokument XML-Instanzdokument XML SGML- Deklaration Dokumentstruktur XML-Parser XSL Transformation- Programm XSLT- Prozessor XML- Ausgabedokument Vergleiche hierzu! die SGML Dokumentenverarbeitung,! die HTML Dokumentenverarbeitung,! und die XML Dokumentenverarbeitung mit DTDs. WT: III-156 Document Languages c STEIN

19 Verknüpfung von XML-Schema und Instanzdokument (Fortsetzung) Definition 1 (gültig hinsichtlich Schema, Instanzdokument) Ein XML-Dokument heißt gültig hinsichtlich eines Schemas (schema valid), wenn es über ein Schema verfügt, und konform zu diesem aufgebaut ist. Das zu validierende Dokument wird als Instanzdokument bezeichnet. WT: III-157 Document Languages c STEIN

20 Bemerkungen:! Der angegebene Gültigkeitsbegriff lässt die Konformität hinsichtlich einer eventuell existierenden DTD außer Acht. So sind Dokumente denkbar, die zwar hinsichtlich einer gegebenen DTD als valid eingestuft werden, jedoch ein zugehöriges Schema verletzen und umgekehrt.! Aufgrund der Realisierung der Schemasprache als XML-Sprache ist jedes Schema auch ein XML-Dokument. Daher eröffnet sich die Möglichkeit, das Schema selbst durch ein Schema zu beschreiben. Dieses Meta-Schema genannte XML-Dokument erlaubt die Validierung (im Sinne der Gültigkeitsdefinition) jedes Schemas. Damit ist eine der Anforderungen an den Schemamechanismus erfüllt: die Validierbarkeit der erstellten Schemata selbst, was für DTDs nicht gegeben war. In der praktischen Anwendung zeigt sich dies in der Möglichkeit, erstellte Schemata mit denselben Werkzeugen zu analysieren, verarbeiten und zu prüfen, die auch für Instanzdokumente Verwendung finden.! Da ein Meta-Schema selbst ein XML-Dokument ist, folgt, dass hierfür wiederum ein Schema angegeben werden kann. Um eine unendliche Reihung zur Validierung notwendiger Schemata zu vermeiden, hat die XML-Standardisierung hier den Ansatz gewählt, das Schema für ein Schema durch sich selbst zu beschreiben. [vgl. Jeckle 2004 ]! W3C-Service zur Schemavalidierung: Altova-Werkzeuge für XML: Java Xerces Library: [steinwebis]$ java dom.writer -v -s Instanzdokument WT: III-158 Document Languages c STEIN

21 Wie man ein XML-Schema entwickelt Voraussetzungen, um ein neues XML-Schema zu entwickeln:! Verständnis für den Zusammenhang zwischen Inhaltsmodell: definiert die Inhaltsstruktur von Elementinstanzen Elementtyp: implementiert ein Inhaltsmodell, ist von einem Datentyp Datentyp eines Elementtyps: deklariert erlaubte Daten! Sicherer Umgang mit (Ziel-, Default-) Namensräumen WT: III-159 Document Languages c STEIN

22 Wie man ein XML-Schema entwickelt Voraussetzungen, um ein neues XML-Schema zu entwickeln:! Verständnis für den Zusammenhang zwischen Inhaltsmodell: definiert die Inhaltsstruktur von Elementinstanzen Elementtyp: implementiert ein Inhaltsmodell, ist von einem Datentyp Datentyp eines Elementtyps: deklariert erlaubte Daten! Sicherer Umgang mit (Ziel-, Default-) Namensräumen Aufgaben bei der Entwicklung eines XML-Schemas: 1. Implementierung von Inhaltsmodellen durch die Definition vonelementtypen und Datentypen. 2. Anwendung eines Entwurfsmusters: anonyme versus benannte Datentypen 3. Optimierung durch Anwendung leistungsfähiger Konzepte (Vererbung, Ableitung, etc.) zur Definition neuer Datentypen. WT: III-160 Document Languages c STEIN

23 Wie man ein XML-Schema entwickelt (Fortsetzung) Zwei Entwurfsmuster zur Elementtypdefinition [ Beispiel ] : 1. <xsd:element name="elementname"> Typedefinition </xsd:element> Definition des Elementtyps Elementname einschließlich der Definition seines Datentyps. 2. <xsd:element name="elementname" type="typename"/> Definition des Elementtyps Elementname unter Verwendung eines gegebenen Datentyps. WT: III-161 Document Languages c STEIN

24 Wie man ein XML-Schema entwickelt (Fortsetzung) Zwei Entwurfsmuster zur Elementtypdefinition [ Beispiel ] : 1. <xsd:element name="elementname"> Typedefinition </xsd:element> Definition des Elementtyps Elementname einschließlich der Definition seines Datentyps. 2. <xsd:element name="elementname" type="typename"/> Definition des Elementtyps Elementname unter Verwendung eines gegebenen Datentyps. Datentypdefinitionen:! <xsd:complextype> Typedefinition </xsd:complextype> Definition eines anonymen, komplexen Datentyps für Instanzen von Elementname. (innerhalb eines <xsd:element name="elementname">-elementes) WT: III-162 Document Languages c STEIN

25 Wie man ein XML-Schema entwickelt (Fortsetzung) Zwei Entwurfsmuster zur Elementtypdefinition [ Beispiel ] : 1. <xsd:element name="elementname"> Typedefinition </xsd:element> Definition des Elementtyps Elementname einschließlich der Definition seines Datentyps. 2. <xsd:element name="elementname" type="typename"/> Definition des Elementtyps Elementname unter Verwendung eines gegebenen Datentyps. Datentypdefinitionen:! <xsd:complextype> Typedefinition </xsd:complextype> Definition eines anonymen, komplexen Datentyps für Instanzen von Elementname. (innerhalb eines <xsd:element name="elementname">-elementes)! <xsd:complextype name="typename"> Typedefinition </xsd:complextype> Definition eines benannten, komplexen Datentyps mit dem Namen Typename. (global, auf oberster Ebene unter <xsd:schema>)! <xsd:simpletype name="typename"> Typedefinition </xsd:simpletype> Definition eines benannten, einfachen Datentyps mit dem Namen Typename. (global, auf oberster Ebene unter <xsd:schema>) WT: III-163 Document Languages c STEIN

26 Bemerkungen:! W3C-Definition von Inhaltsmodell: A content model is a simple grammar governing the allowed types of the child elements and the order in which they are allowed to appear. [ W3C ]! Entwurfsmuster 1 zur Elementtypdefinition kommt zur Anwendung, wenn kein passender Datentyp vorhanden ist und dieser zusammen mit dem Elementtyp (inline, ad-hoc) definiert werden soll. Entwurfsmuster 2 zur Elementtypdefinition kommt zur Anwendung, wenn ein passender Datentyp vordefiniert (built-in) ist oder an anderer Stelle definiert wurde.! Der Begriff des Datentyps in XML-Schema kann für Verwirrung sorgen: allgemein gesprochen ist ein Datentyp ein Konstrukt, das zur Wertebereichsdeklaration verwendet wird. In diesem Sinne entspricht jede Elementtypdefinition in einem XML-Schema der Definition eines Datentyps, der im Instanzdokument verwendet werden kann. Die XSD-Sicht differenziert feiner: Man spricht davon, dass ein Elementtyp ein Inhaltsmodell implementiert, das zum Beispiel Vorgaben für die Häufigkeit des Auftretens von Instanzen des Elementtyps macht. Ein Elementtyp ist von einem Datentyp, der deklariert, von welchem Typ die Daten zwischen Start-Tag und Ende-Tag einer Elementinstanz sein müssen. Dabei kann dieser Datentyp wiederum auf Basis anderer Elementtypen definiert sein. Stichwort: komplexer Datentyp! Die Unterscheidung zwischen Elementtyp und Datentyp schafft eine weitere Möglichkeit zur Abstraktion und Wiederverwendung: verschiedene Elementtypen können auf den gleichen, nur einmal definierten Datentyp zurückgreifen. WT: III-164 Document Languages c STEIN

27 XML-Schema Teil 2: Datentypen [ W3C ] Einteilung der Datentypen:! Primitive Datentypen lassen sich nicht auf Basis anderer Datentypen ableiten. Gegensatz: abgeleitete Datentypen! Vordefinierte Datentypen (Built-in datatypes) sind Teil der Schema Definition Language XSD. Gegensatz: anwenderspezifische Datentypen WT: III-165 Document Languages c STEIN

28 XML-Schema Teil 2: Datentypen [ W3C ] Einteilung der Datentypen:! Primitive Datentypen lassen sich nicht auf Basis anderer Datentypen ableiten. Gegensatz: abgeleitete Datentypen! Vordefinierte Datentypen (Built-in datatypes) sind Teil der Schema Definition Language XSD. Gegensatz: anwenderspezifische Datentypen Schemaelemente zur Definition anwenderspezifischer Datentypen: 1. <xsd:complextype> Definiert einen neuen komplexen Typ für Elemente. Kann weitere Elemente (= Kindelemente) definieren und Attribute haben. 2. <xsd:simpletype> Definiert einen neuen einfachen Typ für Elemente und Attribute, der ausschließlich aus Text besteht und keine Kindelemente definieren darf. WT: III-166 Document Languages c STEIN

29 XML-Schema Teil 2: Datentypen (Fortsetzung) Wichtige Schemaelemente, um Constraints für Kindelemente in komplexen Datentypen zu spezifizieren: Element <xsd:all> <xsd:choice> <xsd:sequence> Semantik jedes Kindelement muss auftreten erlaubt das Auftreten von Kindelementen gemäß Attributen Kindelemente müssen in angegebener Reihenfolge auftreten Weitere Konzepte zur Definition neuer Datentypen:! Vererbung! Ableiten durch Einschränkung! Ableiten durch Erweiterung! Formulierung von Wertebereichs-Constraints durch reguläre Ausdrücke WT: III-167 Document Languages c STEIN

30 Bemerkungen:! Ein Beispiel für einen primitiven Datentyp ist xsd:float. Dagegenist xsd:integer kein primitiver Datentyp, weil er durch Spezialisierung von xsd:decimal abgeleitet ist.! Alle vier Datentypkombinationen sind möglich: primitive wie auch abgeleitete Datentypen können vordefiniert (built-in) oder anwenderspezifisch sein.! Die Definition anwenderspezifischer Datentypen kann anonym oder benannt geschehen. Eine Benennung erfolgt durch das name-attribut im <xsd:complextype> bzw. <xsd:simpletype>-element. Anonyme Datentypen beziehen sich nur auf die Elementtypdefiniton, in der sie eingeführt wurden; benannte Datentypen sind für alle tieferliegenden Baumstufen sichtbar und lassen sich mittels des type-attributes zur Datentypdeklaration verwenden.! Bei der Erzeugung anwenderspezifischer Datentypen können noch die Schemaelemente <xsd:simplecontent> und <xsd:complexcontent> zum Einsatz kommen. Innerhalb einer <xsd:complextype>-definition dienen sie zur Deklaration des Inhalts im Zusammenhang mit restriction (falls der Inhalt auf bestimmte Datentypen eingeschränkt sein soll) oder mit extension (falls der Inhalt bzgl. bestimmter Datentypen erweitert werden soll). WT: III-168 Document Languages c STEIN

31 XML-Schema Teil 1: Inhaltsmodelle Überblick: "implementiert durch" Elementtyp- Inhaltsmodell definition "ist vom" "enthält weitere" komplexen Datenyp (anonym oder benannt) Elementtypdefinitionen "benötigt" Attributdefinitionen einfachen Datenyp (anonym oder benannt) XML-Schema WT: III-169 Document Languages c STEIN

32 XML-Schema Teil 1: Inhaltsmodelle Überblick: "implementiert durch" Elementtyp- Inhaltsmodell definition "ist vom" "enthält weitere" komplexen Datenyp (anonym oder benannt) Elementtypdefinitionen "benötigt" Attributdefinitionen einfachen Datenyp (anonym oder benannt) XML-Schema Wichtige Inhaltsmodelle: [ vgl. DTD ] (a) einfacher Inhalt: unstrukturierter, typisierter Text (b) explizite Kindelemente: feste Struktur vorgeschrieben (c) gemischter Inhalt: Kombination von Elementen und unstrukturiertem Text (d) beliebiger Inhalt: jedes Element kann als Kindelement angegeben werden (e) leerer Inhalt WT: III-170 Document Languages c STEIN

33 XML-Schema Teil 1: Inhaltsmodelle (Fortsetzung) Inhaltsmodell für einfachen Inhalt d. h., unstrukturierten, typisierten Text: <xsd:element name="elementname" type="typename"/> Vergleichbare DTD-Definition, ohne Typ-Deklaration: <!ELEMENT Elementname (#PCDATA)> Beispiel einer Elementtypdefinition für einfachen Inhalt: <xsd:element name="vorname" type="xsd:string" minoccurs="1" maxoccurs="unbounded"/> WT: III-171 Document Languages c STEIN

34 XML-Schema Teil 1: Inhaltsmodelle (Fortsetzung) Wichtige Attribute in der Elementtypdefinition: Attribut Semantik default Zeichenkette mit Default-Wert, der konform zum gewählten Datentyp ist minoccurs Mindestanzahl zulässiger Instanzen dieses Elementtyps, Default ist 1 maxoccurs Höchstanzahl zulässiger Instanzen dieses Elementtyps, Default ist 1 name unqualifizierter Name des Elementtyps ref Verweis auf eine globale Elementtypdefinition type Deklaration des Datentyps für den Elementtyp WT: III-172 Document Languages c STEIN

35 Bemerkungen:! Für einfache Inhaltsmodelle mit unstrukturiertem Text ist in DTDs nur der Datentyp #PCDATA vorgesehen. XML-Schema Part 2 definiert 44 primitive Datentypen. WT: III-173 Document Languages c STEIN

36 XML-Schema Teil 1: Inhaltsmodelle (Fortsetzung) Inhaltsmodell mit explizit angegebenen Kindelementen: <xsd:element name="person"> <xsd:complextype> <xsd:sequence> <xsd:element name="vorname" type="xsd:token" maxoccurs="3"/> <xsd:element name="nachname" type="xsd:token"/> </xsd:sequence> </xsd:complextype> </xsd:element> Vergleichbare DTD-Definition, ohne Anzahl-Constraint: <!ELEMENT Person (Vorname+, Nachname)> Beispiel einer Elementinstanz: <Person> <Vorname>Tim</Vorname> <Nachname>Berners-Lee</Nachname> <Person> WT: III-174 Document Languages c STEIN

37 Bemerkungen:! Hierbei handelt es sich um das für die Modellierungspraxis wichtigste Inhaltsmodell.! In dem Beispiel wurde ein Elementtyp zusammen mit seinem Datentyp (einem anonymen, komplexen Datentyp) definiert. WT: III-175 Document Languages c STEIN

38 XML-Schema Teil 1: Inhaltsmodelle (Fortsetzung) Inhaltsmodell für gemischten Inhalt: <xsd:element name="brief"> <xsd:complextype mixed="true"> <xsd:sequence> <xsd:element name="anrede" type="xsd:string"/> <xsd:element name="ps" type="xsd:string"/> </xsd:sequence> </xsd:complextype> </xsd:element> Vergleichbare DTD-Definition, Zeichendaten nur in der Mitteerlaubt: <!ELEMENT Brief (Anrede #PCDATA PS)> Beispiel einer Elementinstanz: <Brief> <Anrede>Sehr geehrter Herr Berners-Lee</Anrede> Die W3C-Empfehlung für XSD bringt nicht nur Verbesserungen gegenüber DTDs. <PS>Viele Grüße</PS> </Brief> WT: III-176 Document Languages c STEIN

39 Bemerkungen:! W3C-Definition von Mixed Content: An element type has mixed content when elements of that type MAY contain character data, optionally interspersed with child elements. In this case, the types of the child elements MAY be constrained, but not their order or their number of occurrences. [ W3C ]! Ein gemischtes Inhaltsmodell (Mixed content model) liegt vor, wenn die Instanz eines Elementtyps sowohl einfachen Inhalt (unstrukturierten Text) als auch Kindelemente aufnehmen kann.! In dem Beispiel wurde ein Elementtyp zusammen mit seinem Datentyp (einem anonymen, komplexen Datentyp) definiert.! Während gemischte Inhalte aus Auszeichnungssymbolen und freiem Text durch DTD-validierende Parser nur rudimentär geprüft werden können, ermöglicht XSD eine vollständige Validierung gemischter Inhalte. Die Strukturvalidierung der DTD erlaubt zwar die Spezifikation von innerhalb unstrukturierter Textpassagen auftretenden Elementen, nicht jedoch die Überwachung deren Auftrittshäufigkeit oder Reihenfolge. [vgl. Jeckle 2004 ] WT: III-177 Document Languages c STEIN

40 XML-Schema Teil 1: Inhaltsmodelle (Fortsetzung) Inhaltsmodell ohne Beschränkung, freies Inhaltsmodell: <xsd:element name="elementname" type="xsd:anytype"> </xsd:element> bzw. <xsd:element name="elementname"> </xsd:element> oder <xsd:element name="elementname"/> Vergleichbare DTD-Definition: <!ELEMENT Elementname ANY> WT: III-178 Document Languages c STEIN

41 Bemerkungen:! Wird das type-attribut nicht spezifiziert oder alternativ explizit der Wert xsd:anytype zugewiesen, so können Instanzen dieses Elementtyps beliebige, XML-wohlgeformte Inhalte aufnehmen. WT: III-179 Document Languages c STEIN

42 XML-Schema Teil 1: Inhaltsmodelle (Fortsetzung) Inhaltsmodell ohne Inhalt, leeres Inhaltsmodell: <xsd:element name="elementname"> <xsd:complextype/> </xsd:element> Vergleichbare DTD-Definition: <!ELEMENT Elementname EMPTY> WT: III-180 Document Languages c STEIN

43 XML-Schema Teil 1: Inhaltsmodelle (Fortsetzung) Inhaltsmodell ohne Inhalt, leeres Inhaltsmodell: <xsd:element name="elementname"> <xsd:complextype/> </xsd:element> Vergleichbare DTD-Definition: <!ELEMENT Elementname EMPTY> Beispiel einer Elementtypdefinition ohne Inhalt: <xsd:element name="internationalprice"> <xsd:complextype> <xsd:attribute name="currency" type="xsd:string"/> <xsd:attribute name="value" type="xsd:decimal"/> </xsd:complextype> </xsd:element> Beispiel einer Elementinstanz: <internationalprice currency="eur" value="423.46"/> WT: III-181 Document Languages c STEIN

44 Bemerkungen:! Leere Inhaltsmodelle vermitteln ihre Information auschließlich über Attribute oder über ihre Position innerhalb anderer Elemente.! Ein XML-Schema-validierender Parser verhält sich hierbei identisch zu einem DTD-validierenden Parser für das Inhaltsmodell EMPTY. D.h.,es werden nur die beiden folgenden Darstellungen zur Angabe eines leeren Elements akzeptiert: <elementname/> <elementname></elementname> WT: III-182 Document Languages c STEIN

45 XML-Schema Teil 1: Attribute Beispiel: <xsd:attribute name="mydecimal" type="xsd:decimal"/> Innerhalb des <xsd:attribute>-elements lassen sich (durch Attribute) spezifische Eigenschaften festlegen u. a.: Attribut default fixed name ref type Semantik Zeichenkette mit Default-Wert, der konform zum gewählten Datentyp ist unveränderliche Wertbelegung unqualifizierter Name des Attributes Verweis auf eine globale Attributdefinition Deklaration des Datentyps für das Attribut Vergleiche hierzu die DTD-Attribut-Deklaration. WT: III-183 Document Languages c STEIN

46 Bemerkungen:! Attribute dürfen nur von einfachem Typ sein. WT: III-184 Document Languages c STEIN

47 Schemaentwurf [ Vlist 2001 ] Instanzdokument: Being a Dog Is a Full-Time Job von Charles M. Schulz Darsteller 1: Name: Snoopy befreundet mit: Peppermint Patty seit: Eigenschaften: extroverted beagle Darsteller 2: Name: Peppermint Patty seit: Eigenschaften: bold, brash and tomboyish WT: III-185 Document Languages c STEIN

48 Schemaentwurf [ Vlist 2001 ] Instanzdokument: Being a Dog Is a Full-Time Job von Charles M. Schulz Darsteller 1: Name: Snoopy befreundet mit: Peppermint Patty seit: Eigenschaften: extroverted beagle Darsteller 2: Name: Peppermint Patty seit: Eigenschaften: bold, brash and tomboyish Mögliche DTD: <!ELEMENT book (title, author, character+)> <!ELEMENT title (#PCDATA)> <!ELEMENT author (#PCDATA)> <!ELEMENT character (name, since?, qualification*)>... WT: III-186 Document Languages c STEIN

49 Schemaentwurf XML-Source des Instanzdokuments: <?xml version="1.0" encoding="utf-8"?> <book isbn=" "> <title> Being a Dog Is a Full-Time Job </title> <author>charles M. Schulz</author> <character> <name>snoopy</name> <friend-of>peppermint Patty</friend-of> <since> </since> <qualification>extroverted beagle</qualification> </character> <character> <name>peppermint Patty</name> <since> </since> <qualification>bold, brash and tomboyish</qualification> </character> </book> WT: III-187 Document Languages c STEIN

50 Entwurfsmuster 1a: Russian Doll Design Elementtypdefinitionen isoliert betrachtet: <xsd:element name="book"> <xsd:complextype> <xsd:sequence>... </xsd:sequence> </xsd:complextype> </xsd:element> WT: III-188 Document Languages c STEIN

51 Entwurfsmuster 1a: Russian Doll Design Elementtypdefinitionen isoliert betrachtet: <xsd:element name="book"> <xsd:complextype> <xsd:sequence>... </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name="title" type="xsd:string"/> <xsd:element name="author" type="xsd:string"/> <xsd:element name="character" minoccurs="0" maxoccurs="unbounded"> <xsd:complextype> <xsd:sequence> <xsd:element name="name" type="xsd:string"/>... <xsd:element name="qualification" type="xsd:string"/> </xsd:sequence> </xsd:complextype> </xsd:element> WT: III-189 Document Languages c STEIN

52 Entwurfsmuster 1a: Russian Doll Design (Fortsetzung) Elementtypdefinitionen ineinander geschachtelt: <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" <xsd:element name="book"> <xsd:complextype> <xsd:sequence> <xsd:element name="title" type="xsd:string"/> <xsd:element name="author" type="xsd:string"/> <xsd:element name="character" minoccurs="0" maxoccurs="unbounded"> <xsd:complextype> <xsd:sequence> <xsd:element name="name" type="xsd:string"/>... <xsd:element name="qualification" type="xsd:string"/> </xsd:sequence> </xsd:complextype> </xsd:element> </xsd:sequence> <xsd:attribute name="isbn" type="xsd:string"/> </xsd:complextype> </xsd:element> </xsd:schema> WT: III-190 Document Languages c STEIN

53 Entwurfsmuster 1a: Russian Doll Design (Fortsetzung) Elementtypdefinitionen ineinander geschachtelt: <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" <xsd:element name="book"> <xsd:complextype> <xsd:sequence> <xsd:element name="title" type="xsd:string"/> <xsd:element name="author" type="xsd:string"/> <xsd:element name="character" minoccurs="0" maxoccurs="unbounded"> <xsd:complextype> <xsd:sequence> <xsd:element name="name" type="xsd:string"/>... <xsd:element name="qualification" type="xsd:string"/> </xsd:sequence> </xsd:complextype> </xsd:element> </xsd:sequence> <xsd:attribute name="isbn" type="xsd:string"/> </xsd:complextype> </xsd:element> </xsd:schema> WT: III-191 Document Languages c STEIN

54 Entwurfsmuster 1a: Russian Doll Design (Fortsetzung) Elementtypdefinitionen ineinander geschachtelt: <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" <xsd:element name="book"> <xsd:complextype> <xsd:sequence> <xsd:element name="title" type="xsd:string"/> <xsd:element name="author" type="xsd:string"/> <xsd:element name="character" minoccurs="0" maxoccurs="unbounded"> <xsd:complextype> <xsd:sequence> <xsd:element name="name" type="xsd:string"/>... <xsd:element name="qualification" type="xsd:string"/> </xsd:sequence> </xsd:complextype> </xsd:element> </xsd:sequence> <xsd:attribute name="isbn" type="xsd:string"/> </xsd:complextype> </xsd:element> </xsd:schema> WT: III-192 Document Languages c STEIN

55 Bemerkungen:! Bei dem Entwurfsmuster Russian Doll Design ist das entstehende XML-Schema eng an das Instanzdokument angelehnt; die Elementtypen werden entsprechend ihrer Verwendung im Instanzdokument definiert.! Nachteil: Es können tiefgeschachtelte Schemata entstehen, die schwer zu verstehen und zu pflegen sind. Insbesondere unterscheiden sie sich in ihrem Aufbaudeutlichvonden entsprechenden DTDs. WT: III-193 Document Languages c STEIN

56 Entwurfsmuster 1b: Verweis auf globale Elementtypdefinitionen <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" <!-- definition of simple type elements --> <xsd:element name="title" type="xsd:string"/> <xsd:element name="author" type="xsd:string"/>... <xsd:element name="qualification" type="xsd:string"/> <xsd:attribute name="isbn" type="xsd:string"/> WT: III-194 Document Languages c STEIN

57 Entwurfsmuster 1b: Verweis auf globale Elementtypdefinitionen <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" <!-- definition of simple type elements --> <xsd:element name="title" type="xsd:string"/> <xsd:element name="author" type="xsd:string"/>... <xsd:element name="qualification" type="xsd:string"/> <xsd:attribute name="isbn" type="xsd:string"/> <!-- definition of complex type elements --> <xsd:element name="character"> <xsd:complextype> <xsd:sequence> <xsd:element ref="name"/>... <xsd:element ref="qualification"/> <!-- simple type elements are referenced with "ref" attribute --> <!-- definition of cardinality when elements are referenced --> </xsd:sequence> </xsd:complextype> </xsd:element> WT: III-195 Document Languages c STEIN

58 Entwurfsmuster 1b: Verweis auf globale Elementtypdefinitionen (Fortsetzung) <xsd:element name="book"> <xsd:complextype> <xsd:sequence> <xsd:element ref="title"/> <xsd:element ref="author"/> <xsd:element ref="character" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute ref="isbn"/> </xsd:complextype> </xsd:element> </xsd:schema> WT: III-196 Document Languages c STEIN

59 Bemerkungen:! Wie bei dem Russian Doll Design werden auch hier die Elementtypen entsprechend ihrer Verwendung im Instanzdokument definiert. Schachtelungen werden dadurch vermieden, dass ausgehend von den Blättern (also bottom-up) für jede Ebene des Dokumentbaums eine Liste der in dieser Ebene neu hinzukommenden Elementypen erstellt wird. Die Definition von Elementypen mit Kindelementen geschieht mittels Verweise auf Elementtypen aus dieser Liste. Vergleiche dazu das Russian DollDesign,beidemstatt der Verweise die gesamte Elementtypdefinition eingebettet wird.! Man könnte die Entwurfsmuster (1a) und (1b) als Entwurf auf Basis anonymer Datentypen bezeichnen: die Elementtypdefinitionen für character und book basieren auf einem direkt (inline, ad-hoc) definierten, anonymen Datentyp. Sind mehrere Elementtypen gleich aufgebaut, so besitzen sie bis auf ihren Namen die gleiche Definition, was zu erheblicher Redundanz führen kann. Alternative: Definition eines benannten Datentyps! Durch das Referenzierungskonzept existiert eine erste Möglichkeit zur Wiederverwendung bereits im Schema definierter Elementtypen. Bei dieser einfachen Form der Textersetzung werden die Elementtypen literal, also mit ihrem Namen eingebunden. Im Grunde genommen ist diese Art der Wiederverwendung bereits mit den Mitteln von DTDs möglich. [vgl. Jeckle 2004 ]! Another authoring style, applicable when all element names areuniquewithina namespace, is to create schemas in which all elements are global. This is similar in effect to the use of <!ELEMENT> in a DTD. [ W3C ] WT: III-197 Document Languages c STEIN

60 Entwurfsmuster 2: Definition benannter Datentypen <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" <!-- definition of simple types --> <xsd:simpletype name="nametype"> <xsd:restriction base="xsd:string"> <xsd:maxlength value="32"/> </xsd:restriction> </xsd:simpletype> WT: III-198 Document Languages c STEIN

61 Entwurfsmuster 2: Definition benannter Datentypen <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" <!-- definition of simple types --> <xsd:simpletype name="nametype"> <xsd:restriction base="xsd:string"> <xsd:maxlength value="32"/> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name="sincetype"> <xsd:restriction base="xsd:date"/> </xsd:simpletype> <xsd:simpletype name="desctype"> <xsd:restriction base="xsd:string"/> </xsd:simpletype> <xsd:simpletype name="isbntype"> <xsd:restriction base="xsd:string"> <xsd:pattern value="[0-9]10"/> </xsd:restriction> </xsd:simpletype> WT: III-199 Document Languages c STEIN

62 Entwurfsmuster 2: Definition benannter Datentypen (Fortsetzung) <!-- definition of complex types --> <xsd:complextype name="charactertype"> <xsd:sequence> <xsd:element name="name" type="nametype"/>... <xsd:element name="qualification" type="desctype"/> </xsd:sequence> </xsd:complextype> WT: III-200 Document Languages c STEIN

63 Entwurfsmuster 2: Definition benannter Datentypen (Fortsetzung) <!-- definition of complex types --> <xsd:complextype name="charactertype"> <xsd:sequence> <xsd:element name="name" type="nametype"/>... <xsd:element name="qualification" type="desctype"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="booktype"> <xsd:sequence> <xsd:element name="title" type="nametype"/> <xsd:element name="author" type="nametype"/> <xsd:element name="character" type="charactertype" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="isbn" type="isbntype" use="required"/> </xsd:complextype> <!-- The "book" element is of the data type "booktype" --> <xsd:element name="book" type="booktype"/> </xsd:schema> WT: III-201 Document Languages c STEIN

64 Gegenüberstellung der Entwurfsmuster 1. Elementtypdefinition mit anonymen Datentyp: <xsd:element name="bondcar"> <xsd:complextype> <xsd:sequence> <xsd:element name="color" type="xsd:string"/> <xsd:element name="enginepower" type="xsd:integer"/> </xsd:sequence> </xsd:complextype> </xsd:element> 2. Definition eines benannten Datentyps und Elementtypdefinition damit: <xsd:complextype name="automobile"> <xsd:sequence> <xsd:element name="color" type="xsd:string"/> <xsd:element name="enginepower" type="xsd:integer"/> </xsd:sequence> </xsd:complextype> <xsd:element name="bondcar" type="automobile"/> WT: III-202 Document Languages c STEIN

65 Quellen zum Nachlernen und Nachschlagen im Web: Referenz! D. C. Fallside. XML Schema Part 0: Primer. W3C Recommendation. H. S. Thompson et al. XML Schema Part 1: Structures. W3C Recommendation. P. V. Biron, A. Malhotra. XML Schema Part 2: Datatypes. W3C Recommendation. MSDN-Library. Referenz zu XML-Schemata (XSD). msdn2.microsoft.com/de-de/library/ms WT: III-203 Document Languages c STEIN

66 Quellen zum Nachlernen und Nachschlagen im Web: Usage! E. v. d. Vlist. Using W3C XML Schema. Cover Pages. xml.coverpages.org/schemas.html! W3 Schools. WT: III-204 Document Languages c STEIN