XML Schema

(1)

(2)

Die 3 Strömungen von XML

XML Schema

Dokumenten-

verarbeitung Datenbanken und

Datenaustausch

Semistrukturierte Daten und Informationsintegration gemischte Inhalte

Grammatikorientierung

Typisierung von Elementinhalten

Schemainformation mit den Mitteln des

Datenmodells ausdrücken

Integritätsbedingungen (Schlüssel)

flexible Zuordnung von Schemata

Strukturvariationen

(3)

Einführung XML Schema



Vielzahl von Schemasprachen erforderte Standardisierung



unterstützt dokumenten- und datenorientierte Modellierung



Typkonzept



objektorientierte Konzepte (Vererbungsmechanismen)



XML Schema Recommendation des W3C

–

Teil 2: Datentypdefinitionen

–

Teil 1: Spezifikation anderer Schemastrukturen

Teil 0: “Primer“ mit Erläuterung für Teil 1 und 2

(4)

Überblick über XML Schema

Wiederverwendung

Schemadokumentation

Modularisierung, Erweiterung

Konsistenz

Eindeutigkeit

Schlüssel, Fremdschlüssel

Struktur

komplexe Datentypen

Kardinalitäten, Elementdeklarationen

Datentypen

einfache Datentypen

(5)

Vordefi-

nierte

Typen in

XML Schema

(6)

Typkonzept



einfacher Typ (simple type)

–

beinhaltet weder Attribute noch Kindelemente

–

für Attributwerte und Inhalte mit textuellem Inhalt



komplexer Typ (complex type)

–

Menge von Attributdeklarationen und Inhaltsmodell

–

Inhaltsmodell kann Kindelemente beinhalten, textuellen Inhalt zulassen oder eine Mischung vorsehen (mixed content)



Komponenten eines einfachen Typs

–

Wertebereich (value space)

–

Repräsentationsraum (lexical space)

 mehrere Repräsentationen eines Wertes (z.B. bei Gleitkommazahlen, Datum)

–

Menge von Aspekten (facets)

(7)

Aspekte von Datentypen

Fundamentale Aspekte:



Ordnung eines Datentypes (voll, partiell, nicht)



Kardinalität



Numerisch?

Beschränkende Aspekte des Wertebereichs:



enumeration: Vorgabe einer Menge von Werten



Längenbeschränkung für Zeichenketten: minLength, maxLength, length



direkte Unter-/Obergrenze für geordneten Wertebereich: maxInclusive, maxExclusive, minExclusive, minInclusive



Beschränkung der Anzahl Ziffern und

Nachkommastellen: totalDigits, fractionDigits

(8)

Aspekte von Datentypen (Forts.)

Einschränkung des Repräsentationsraumes



Pattern: Wertebereich für Zeichenketten mittels regulärem Ausdruck (vglb. Perl-Syntax)

Abbildung bestimmter Repräsentationen von Zeichenketten auf Werte



whiteSpace: Einfluß auf die Behandlung von

Leerräumen (preserve, replace, collapse)

(9)

Erzeugung von Datentypen



aus den XML Schema vordefinierten Datentypen neue Datentypen erzeugen



zwei Vererbungsmechanismen:

– Einschränkung (restriction): Ableitung eines Typs aus einem Basistyp durch Angabe von beschränkenden Aspekten

neuer Typ übernimmt Wertebereich und

Repräsentationsraum, eingeschränkt durch die Aspekte

– Erweiterung (extension): erzeugt immer einen komplexen Typ



zwei Aggregationsmechanismen

– Listenbildung (list)

– Vereinigung (union): vereinigt Wertebereiche und Repräsentationsräume der einfachen Basistypen

(10)

Definition einfacher Typen (Beispiele)

<xs:simpleType name=“Wassertemperatur“>

<xs:restriction base=“xs:number“>

<xs:fractionDigits value=“2“/>

<xs:minInclusive value=“0.00“/>

<xs:maxInclusive value=“100.00“/>

<xs:restriction>

</xs:simpleType>

<xs:simpleType name=“Telefonnummer“>

<xs:restriction base=“xs:string“>

<xs:pattern value=“0[0-9]+/[0-9]+“ />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name=“Telefonnummer“>

<xs:list itemType=“Telefonnummer“/>

</xs:simpleType>

Liste von Telefonnummern

(11)

Weitere Beispiele

 Aufzählungsdatentyp

<xs:simpleType name=“Kirchensteuer“>

<xs:restriction base =“xs:NMTOKEN“>

<xs:enumeration value = “EV“/>

<xs:enumeration value = “RK“/>

<xs:enumeration value = “KEINE“ />

</xs:restriction>

</xs:simpleType>

(12)

Definition komplexer Typen



Einfacher Inhalt: Erweiterung oder Einschrän- kung eines Typs



Beispiel:

<xs:complexType name=“Gehaltstyp“>

<xs:simpleContent>

<xs:extension base = “xs:positiveInteger“>

<xs:attribute name = “Start“ type = “xs:date“ use = “required“/>

</xs:extension>

</xs:simpleContent>

</xs:complexType>



Beispiel-Element:

(13)

Komplexer Inhalt



Reihung (sequence): Liste von Elementen mit festgelegter Reihenfolge



Konjunktion (all): alle aufgeführten Teile dürfen maximal einmal auftreten in beliebiger

Reihenfolge, keine Verschachtelung möglich



Auswahl (Disjunktion, choice): von den augeführten Elementen darf nur eines auftreten



Kardinalitäten: minOccurs, maxOccurs mit numerischen Werten oder unbounded für beliebig oft, Standard: minOccurs=1,

maxOccurs=1

(14)

Komplexer Inhalt - Beispiel

<xs:complexType name=“Personalien“>

<xs:sequence>

<xs:element name= “Nachname“ type=“xs:string“ />

<xs:element name= “Vorname“ type=“xs:string“

maxOccurs = “unbounded“ />

<xs:element name = “Geburtsdatum“ type = “xs:date“ />

</xs:sequence>

</xs:complexType>

Beispiel-Element

<Nachname>Schmidt</Nachname>

<Vorname>Heinrich</Vorname>

</Personalien>

(15)

Leere Elemente und gemischter Inhalt

<xs:complexType name=“Lohndaten“>

<xs:attribute name=“Steuerklasse“ use = “required“>

<xs:simpleType>

<xs:restriction base = “xs:integer“>

<xs:minInclusive value = “1“ />

<xs:maxInclusive value = “6“ />

<xs:restriction>

</xs:simpleType>

</xs:attribute>

<xs:attribute name=“Kinder“ type=“xs:nonNegativeInteger“ default=“0“/>

<xs:attribute name=“Kirchensteuer“ type=“Kirchensteuer“ use=“required“/>

</xs:complexType>

Beispiel-Element

(16)

Einschränkung bei komplexem Inhalt

<xs:complexType name=“Personalien1“>

<xs:complexContent>

<xs:restriction base=“Personalien“>

<xs:sequence>

<xs:element name = “Nachname“ type=“xs:string“ />

<xs:element name = “Vorname“ type=“xs:string“ maxOccurs = “1“ />

<xs:element name = “Geburtsdatum“ type = “xs:date“ />

</xs:sequence>

</xs:restriction>

</xs:complexContent>

</xs:complexType>

Einschränkungen:

 in der erlaubten Anzahl (minOccurs / maxOccurs)

 Hinzufügen Default-Wert oder festen Wert

 Weglassen einer optionalen Komponente

 Ersetzen eines einfachen Typs durch eine Einschränkung dieses Typs

(17)

Erweiterung bei komplexem Inhalt

<xs:complexType name=“ErweitertePersonalien“>

<xs:complexContent>

<xs:extension base=“Personalien“>

<xs:sequence>

<xs:element name = “Adresse“ type=“Adresse“ />

</xs:sequence>

<xs:attribute name = “Abteilungsnummer“ type = “xs:positiveInteger“ />

</xs:extension>

</xs:complexContent>

Hinweise:

 Erweiterung um Attribute (z.B. Abteilungsnummer) und Elemente

 Anfügen neuer Elemente von hinten (z.B. Adresse)

 Attribut final in der Typdefinition

– final = “restriction“ weitere Einschränkung verboten

– final = “extension“ weitere Erweiterung verboten

(18)

Gruppen

Modellgruppe

<xs:group name=“Gehaltsdaten“>

<xs:choice>

<xs:element name=“Stundenlohn“ type=“Gehaltstyp“ />

<xs:element name=“Jahresgehalt“ type=“Gehaltstyp“ />

</xs:choice>

</xs:group>

Attributgruppe

<xs:attributeGroup name=“Lohndatenattribute“>

<xs:attribute name=“Steuerklasse“ use = “required“>

<xs:simpleType>

<xs:restriction base = “xs:integer“>

<xs:minInclusive value = “1“ />

<xs:maxInclusive value = “6“ />

<xs:restriction>

</xs:simpleType>

</xs:attribute>

<xs:attribute name=“Kinder“ type=“xs:nonNegativeInteger“ default=“0“/>

<xs:attribute name=“Kirchensteuer“ type=“Kirchensteuer“ use=“required“/>

</xs:attributeGroup >

(19)

Verwendung von Gruppen

Referenzen auf die Gruppen (oder: Infos in Typ kopieren)

<xs:complexType name=“Gehaltsdaten“>

<xs:group ref = “Gehaltsdaten“/>

<xs:attributeGroup ref = “Lohndatenattribute“ />

</xs:complexType>

Beispiel-Element

</Gehaltsdaten>

Vergleichbar mit Parameter-Entities in DTD

(20)

Deklarationen

<xs:element name=“Betrag“>

<xs:complexType>

<xs:simpleContent>

<xs:extension base=“xs:decimal“>

<xs:attribute name=“Währung“ type=“xs:string“ />

</xs:extension>

</xs:simpleContent>

</xs:element>

<xs:element name=“Rechnung“>

<xs:sequence>

<xs:element ref=“Betrag“ />

<xs:element name=“Euro“>

<xs:sequence>

<xs:element name=“Betrag“ type=“xs:decimal“ />

</xs:sequence>

</xs:element>

</xs:sequence>

</xs:element>

globale Deklaration des Element-Namens Betrag

lokale Definition des Elements Betrag

bezieht sich auf global definiertes Element Betrag

(21)

Offene Schemata



Aufbau mancher Dokumentteile nicht bekannt oder nicht relevant



Anwendungsbeispiele

– Einbettung von XHTML in XML

– Austausch von XML-Dokumenten zwischen verschiedenen

Firmen auf Basis eines gemeinsamen Schemas (mit möglichen Erweiterungen)



Platzhalter (wildcards)

– für Elemente: any

– für Attribute: anyAttribute



Namensraum kann vorgeschrieben werden



Elementdeklarationen beachten? (processContents)

(22)

Offene Schemata - Beispiel

<xs:element name=“htmlDokument“>

<xs:complexType>

<xs:sequence>

<xs:any namespace=“http://www.w3.org/1999/xhtml“

minOccurs=“1“ maxOccurs=“unbound“

processContents=“skip“ />

</xs:sequence>

<xs:anyAttribute namespace=“http://www.w3.org/1999/xhtml“ />

</xs:complexType>

</xs:element>

(23)

Eindeutigkeit von Werten

 Definition unabhängig vom Typ möglich

 entschieden durch typbezogene Gleichheit (z.B.: 3 gleich 3.0 bei Typ number, aber ungleich bei string)

 Definition für Element- oder Attributinhalte oder Kombinationen darauf

– selector: Knotenmenge von Knoten unterhalb des deklarierten Elements

– field: identifiziert relativ dazu genau einen Knoten

 unique vs. key (vgl. SQL)

 Beispiel: <xs:element name=“Abteilung“>

<xs:sequence>

<xs:element name=“Angestellte“ type=“Personalien“

minOccurs=“1“ maxOccurs=“unbound“ />

</xs:sequence>

<xs:attribute name“Name“ type=“xs:string“ />

<xs:attribute name=“Abtnr“ type=“xs:positiveInteger“ />

<xs:key name=“Persnr“>

<xs:selector xpath=“Angestellte“ />

(24)

Referenzbeziehungen



Analogie zur Primär-/Fremdschlüsselbeziehung im Relationenmodell – beschränkt auf eine

Instanz!



Referenzmechanismus über key/keyref



Besonderheiten gegenüber ID/IDREF (DTD)

–

Attribute und Elemente (bzw. Kombinationen daraus) als Schlüssel möglich (bei ID nur Attribute)

–

Schlüsseleigenschaft zusätzlich zum Datentyp (ID Ersatz für Datentyp)

–

getypte Referenzen

–

Eindeutigkeit für key und unique auf Elementtypen

beschränkt (bei ID dokumentweit)

(25)

Referenzbeziehungen - Beispiel

<xs:element name=“Projekt“>

<xs:complexType>

<xs:sequence>

<xs:element name=“Mitarbeiter“

minOccurs=“2“ maxOccurs=“unbounded“>

<xs:complexType>

<xs:attribute name=“PersNr“ type=“xs:positiveInteger“

use=“required“ />

<xs:attribute name=“Rolle“ type=“xs:string“ />

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:keyref name=“Phantomverhinderung“ refer=“Persnr“>

<xs:selector xpath=“Mitarbeiter“/>

<xs:field xpath=“@PersNr“/>

</xs:keyref>

alle Angestellten, die in einem Projekt

mitarbeiten, müssen auch in der

entsprechenden

Abteilung vorkommen

(26)

Defizite bei Referenzbeziehungen

 keyref berücksichtigt nicht einzelne Elemente einer Liste (list), d.h. mit einem Wert in keyref kann man nicht ein einzelnes Element einer Liste, die im key steht, referenzieren

 Vorgängerachsen im XPath-Ausdruck von field nicht zugelassen → kein Verweis möglich mit hierarchischem Schlüssel (d.h. Anteile über

mehrere Element verteilt, die in hierarch. Beziehung stehen)

– Beispiel:

Eindeutigkeit der Spielernummer pro Verein gegeben kein key aus Vereinsname und Spielernummer möglich

Ausdruck in field muss genau einen Wert liefern, keine Navigation „nach oben“

 keine instanzübergreifenden Integritätsbedingungen, z.B.

Schlüsselbedingungen in einer Menge von XML-Dokumenten oder Referenzbeziehungen zwischen verschiedenen XML-Dokumenten

(27)

Namen und Namensräume



Gültigkeitsbereich

– einfache und komplexe Typen teilen sich Gültigkeitsbereich (symbol space)

– Element kann heißen wie einfacher Typ



Namensraum

– Vokabular von XML Schema:

http://www.w3.org/2001/XMLSchema

– Präfix xs steht für diesen Namensraum

– Elemente und Attribute eines Dokuments können zu höchstens einem Namensraum gehören (im

targetNameSpace des umgebenden schema-Elements angegeben)

– globale Elemente, Attribute und Definitionen gehören immer dem Namensraum des Schemas an

(28)

Ableitung, Ersetzung



Ableitung von Typen (Einschränkung, Erweiterung) möglich

– Einschränken durch final

– Aspekte fixieren: fixed=“true“



Ersetzungsgruppen (substitution groups)



globales Element kann Ersatz für anderes globales Element sein (Ersetzungsgruppenkopf, substitution group head)



Motivation: ermöglicht Interoperabilität zwischen

Schemata unterschiedlicher Herkunft mit demselben

Inhalt

(29)

Ersetzungsgruppe (Beispiel)

<xs:complexType name=“Personalien“>

<xs:sequence>

<xs:element ref = “Nachname“ />

<xs:element ref = “Vorname“ maxOccurs = “unbounded“ />

<xs:element ref = “Geburtsdatum“ type = “xs:date“ />

</xs:sequence>

<xs:attribute name =“Personalnr“ type=“xs:positiveInteger“ />

<xs:element name=“Nachname“ type=“xs:string“ />

<xs:element name=“Vorname“ type=“xs:string“ />

<xs:element name=“Geburtsdatum“ type=“xs:date“ />

<xs:element name=“birthday“ type=“xs:date“ substitutionGroup=“Geburtsdatum“ />

Beispiel-XML-Fragment validiert gegen Schema:

<Personalien>

<Nachname>Schmidt</Nachname>

<Vorname>Otto</Vorname>

(30)

Schema-Import



Zusammensetzung aus mehreren Schemadokumenten möglich



include-Element: Einfügen von

Schemadokumenten mit Deklarationen zum selben Namensraum



Umdefinition möglich (redefine)



Schemadokumente aus anderem Namensraum

über import einbindbar

(31)

Instanzbezogene Konzepte (xsi



Attribut xsi:type

– i. Allg. Typ eines Elements durch Deklaration im Schema bestimmt

– Instanz mit einem bestimmten Typ definiert werden mittels xsi:type (kompatibel mit Typ lt. Schemadefinition – durch Erweiterung /

Einschränkung)



Attribut xsi:nil

– Element ohne Inhalt (nillable=“true“) kann als gültig akzeptiert werden, wenn Attribut xsi:nil=“true“

– Unterschiede zu NULL-Werten in Datenbanken: XML Schema unterscheidet nicht vorhandenes Element, Element mit (ggf.

leerem) Inhalt und nil-Element (trotzdem keine dreiwertige Logik)



xsi:schemaLocation und xsi:noNamespaceSchemaLocation

– Identifikation des entsprechenden Schemas

(32)

Physisches Schema



XML Schema = logisches Schema



Anbindung physischer Informationen an Schemaelemente

– entkoppelte Information: eigenes Dokument mit Namen aus der XML Schemadefinition (z.B. Abbildung XML auf Tabellen)

– proprietäre Schemasprache, z.B. XDR-basierte Definitionssprache von XML Views in MS SQL Server

– Schema Adjunct: separates Dokument, allg. Framework, Konsistenzwahrung möglich

– Schemasprachenerweiterung

1. zusätzliche Attribute für spezifische Informationen (mit anderem Namensraum) – Beispiel Oracle (siehe später)

2. Hinzufügen von annotation-Elementen für Benutzerinformation

(documentation) und für maschinell auswertbare Information (appInfo), Beispiele: SQL/XML und Tamino-Schemasprache

(33)

XML Schema - Zusammenfassung



viele mächtige Modellierungskonzepte

– umfangreiches Typsystem

– lokale Definitionen möglich

– Vererbungsmechanismus und Beschränklungen



hohe Komplexität ist aber auch Nachteil (Kritik von James Clark, Tim Bray u.a.)



zunehmende Verwendung in kommerziellen Produkten



Schema nicht für Mengen von Dokumenten ausgelegt (z.B. Konsistenzbedingungen nur innerhalb einer Instanz)



XML Schema durch ein XML Schema als Metaschema

beschreibbar (Grundlage für Validierung)

(34)

Einige Defizite von XML Schema



ungeordneter Inhalt nur schwer zu beschreiben



keine Möglichkeit, gegenseitige Abhängigkeit zwischen Attributen auszudrücken



Erweiterungen bei komplexen Typen nur am Ende möglich



Validierung liefert zusätzliche Daten zum validierten XML- Dokument, z.B. Default-Werte unterschiedliches Verhalten von nichtvalidierenden Anwendungen da andere Daten