1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19Geoinformation3

Geoinformation III

XML-Schema

Vorlesung 13b

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19Geoinformation3

2

• 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

Vereinigungstypen (Union Types)

<xsd:simpleType name=“monatsangabe“> <xsd:union memberTypes=“meinMonatsTyp xsd:positiveInteger“/></xsd:simpleType>

<monat>Februar</monat><monat>2</monat><monat>April</monat>

Beispiel für ein Elemente vom Typ <monatsangabe> :

s. V. 13a Folie 19

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19Geoinformation3

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)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19Geoinformation3

4

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

Komplexe Inhalte (Content Models)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19Geoinformation3

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>

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19Geoinformation3

6

Verteilte Schemata

• Schemadefinitionen können über mehrere Dokumente verteilt sein Modularisierung, Wiederverwendbarkeit Übersichtlichkeit

• ein Schema wird mittels des <include>-Tags in ein anderes Schema eingebettet:

<include schemaLocation = “http://www.beispiele.de/verteiltes_schema.xsd“/>

• 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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19Geoinformation3

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

Person

Name Vorname

Student

Matrikelnummer

Attribute von Student:

Name geerbt vonVorname PersonMatrikelnummer

}

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19Geoinformation3

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>

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19Geoinformation3

Ableitung von Typen durch Erweiterung (II)

9

<?xml version=“1.0“><studentenliste xmlns=“http://www.personenregister.de/Personen“> <student> <name>Zupp</name> <vorname>Jupp</vorname> <matrikelnr>123456789</matrikelnr> </student></studentenliste>

Beispiel für ein Instanzdokument mit einer Liste von Studenten:

student erbt die Elemente “name“ und “vorname“ von “person“

student erbt die Elemente “name“ und “vorname“ von “person“

Erweiterung von “person“ durch eine

Matrikelnummer

Erweiterung von “person“ durch eine

Matrikelnummer

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19Geoinformation3

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 daher polymorph sein

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19Geoinformation3

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

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

Dürfen dort verwendet werden, wo eigentlich ein Element <pers:person> erwartet wird

Dürfen dort verwendet werden, wo eigentlich ein Element <pers:person> erwartet wird

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19Geoinformation3

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

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

“personTyp“ wird als abstrakter Typ definiert.

Element “person“ darf nicht im Instanzdokument vorkommen; wohl aber “student“, weil es auf dem abgeleiteten Typ “studentTyp“ basiert.

Element “person“ darf nicht im Instanzdokument vorkommen; wohl aber “student“, weil es auf dem abgeleiteten Typ “studentTyp“ basiert.

“studentTyp“ wird von “personTyp“ abgeleitet (und ist nicht abstrakt).

“studentTyp“ wird von “personTyp“ abgeleitet (und ist nicht abstrakt).