Geoinformation III

1. Geoinformation III Vorlesung 13b XML-Schema

2. <monat>Februar</monat> <monat>2</monat> <monat>April</monat> Beispiel für ein Elemente vom Typ <monatsangabe> : 2 Vereinigungstypen (Union Types) • Vereinigung mehrerer Simple Types • Elemente bzw. Attribute eines V.-typen dürfen Werte aus einem der Wertebereiche der angegebenen Typen haben • zulässig sind: • atomare Typen • Listentypen • Vereinigungstypen <xsd:simpleType name=“monatsangabe“> <xsd:union memberTypes=“meinMonatsTyp xsd:positiveInteger“/> </xsd:simpleType> s. V. 13a Folie 19

3. 3 Complex Types (I) • Benannte komplexe Typen (Named Complex Types) • global definiert • können wiederverwendet werden • Bezeichnung muss ein XML-Name sein • Unbenannte komplexe Typen (Anonymous Complex Types) • sind nur innerhalb einer Element-Deklaration definiert • können deshalb nie eingeschränkt, erweitert oder redefiniert werden • Inhalt von komplexen Typen: • einfacher Inhalt (simpleContent) • komplexer Inhalt (complexContent) • nur Elemente (element-only content) • gemischter Inhalt (mixed content) • leer (empty content)

4. 4 Komplexe Inhalte (Content Models) • <sequence> . . . </sequence> • alle darin deklarierten Elemente müssen in genau dieser Reihenfolge im Instanzendokument vorkommen • <choice> . . . </choice> • genau eines der darin deklarierten Elemente muss im Instanzendokument vorkommen • <group> . . . </group> • Gruppiert Deklarationen, die dann über ihren Namen in das Content Model eingefügt werden können

5. 5 Beispiel Complex Types und Content Models <xsd:complexType name=“personenTyp“> <xsd:sequence> <xsd:element name=“vorname“ type=“xsd:string“/> <xsd:element name=“name“ type=“xsd:string“/> <xsd:element name=“telefonnummer“> <xsd:complexType> <xsd:choice> <xsd:element name=“telnummerPrivat“ type=“xsd:string“/> <xsd:element name=“telnummerJob“ type=“xsd:string“/> </xsd:choice> </xsd:complexType> </xsd:element> </xsd:sequence> <xsd:attribute name=“geburtsdatum“ type=“xsd:date“/> </xsd:complexType>

6. ein Schema wird mittels des <include>-Tags in ein anderes Schema eingebettet: <include schemaLocation = “http://www.beispiele.de/verteiltes_schema.xsd“/> 6 Verteilte Schemata • Schemadefinitionen können über mehrere Dokumente verteilt sein • Modularisierung, Wiederverwendbarkeit • Übersichtlichkeit • das eingefügte Dokument muss denselben Target Namespace besitzen, d.h. die Definitionen darin werden demselben Namensraum hinzugefügt • weiterer Möglichkeit mittels <import>, das auch die Verwendung mehrerer Target Namespaces erlaubt

7. Person Name Vorname Student Attribute von Student: Name geerbt von Vorname Person Matrikelnummer Matrikelnummer } 7 Vererbung Eine Vererbung, wie sie bei UML möglich ist, erfolgt in XML-Schema mittels Ableitung eines Typs von einem Basistyp (Oberklasse) durch Erweiterung

8. 8 Ableitung von Typen durch Erweiterung (I) <schema targetNamespace=“http://www.personenregister.de/Personen“ xmlns=“http://www.w3.org/2001/XMLSchema“ xmlns:pers=“http://www.personenregister.de/Personen“> <complexType name=“personTyp“> <sequence> <element name=“name“ type=“string“/> <element name=“vorname“ type=“string“/> </sequence> </complexType> <complexType name=“studentTyp“> <complexContent> <extension base=“pers:personTyp“ <sequence> <element name=“matrikelnr“ type=“positiveInteger“/> </sequence> </extension> </complexContent> </complexType> </schema>

9. Beispiel für ein Instanzdokument mit einer Liste von Studenten: <?xml version=“1.0“> <studentenliste xmlns=“http://www.personenregister.de/Personen“> <student> <name>Zupp</name> <vorname>Jupp</vorname> <matrikelnr>123456789</matrikelnr> </student> </studentenliste> student erbt die Elemente “name“ und “vorname“ von “person“ Erweiterung von “person“ durch eine Matrikelnummer 9 Ableitung von Typen durch Erweiterung (II)

10. 10 Polymorphie • In objektorientierten Programmiersprachen dürfen • Variablen vom Typ einer Oberklasse auch Objekte vom Typ einer ihrer Unterklassen zugewiesen werden • der Inhalt solcher Variablen kann daherpolymorphsein • Beispiel in Java: • class Student extends Person {...} • . . . • Person p; • Student s = new Student(“Jupp“, “Zupp“, 4711); • p=s; • In XML-Schema muss explizit spezifiziert werden, wenn ein Element, dass auf einem spezielleren Typ basiert, im Instanzdokument auch dort vorkommen darf, wo eigentlich ein Element vom Typ der Oberklasse erwartet wird

11. 10 Äquivalenzklassen (substitution groups) • Deklaration einer Gruppe austauschbarer Elemente • Elemente der substitution group müssen global deklariert werden • jedes Element dieser Gruppe kann im Instanzdokument ersetzt werden • jedes Element der substitution group muss vom selben Typ sein wie das zu substituierende Element oder von dessen Typ abgeleitet werden Dürfen dort verwendet werden, wo eigentlich ein Element <pers:person> erwartet wird <element name=“student“ type=“studentTyp“ substitutionGroup=“pers:person“/> <element name=“professor“ type=“professorTyp“ substitutionGroup=“pers:person“/> <pers:student>Jupp Zupp</pers:student> <pers:professor>Carl Friedrich Gauß</pers:professor>

12. 11 Abstrakte Elemente und Typen • Dienen zur Repräsentation übergeordneter abstrakter Konzepte • Elemente mit abstrakten Typen dürfen im Instanzdokument nicht verwendet werden, nur Mitglied(er) der substitution group “studentTyp“ wird von “personTyp“ abgeleitet (und ist nicht abstrakt). <schema xmlns=“http://www.w3c.org/2001/XML-Schema“ targetNamespace=“http://personen.abstraktebeispiele.de/schema“ xmlns:pers=“http://personen.abstraktebeispiele.de/schema“ <complexType name=“personTyp“ abstract=“true“> ... </complexType> <complexType name=“studentTyp“> <complexContent> <extension base=“pers:personTyp“/> ... </complexContent> </complexType> <element name=“person“ type=“pers:personTyp“/> <element name=“student“ type=“pers:studentTyp“/> </schema> “personTyp“ wird als abstrakter Typ definiert. Element “person“ darf nicht im Instanzdokument vorkommen; wohl aber “student“, weil es auf dem abgeleiteten Typ “studentTyp“ basiert.