XML Schema. © Prof. T. Kudraß, HTWK Leipzig Die 3 Strömungen von XML XML Schema Dokumenten-...

XML Schema

© Prof. T. Kudraß, HTWK Leipzig

Die 3 Strömungen von XML

XML Schema

Dokumenten-verarbeitung

Datenbanken undDatenaustausch

Semistrukturierte Daten und Informationsintegration

gemischte InhalteGrammatikorientierung

Typisierung vonElementinhalten

Schemainformationmit den Mitteln desDatenmodells ausdrücken

Integritätsbedingungen(Schlüssel)

flexible Zuordnungvon SchemataStrukturvariationen


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


Überblick über XML Schema

Wiederverwendung Schemadokumentation

Modularisierung, Erweiterung

Konsistenz Eindeutigkeit

Schlüssel, Fremdschlüssel

Struktur komplexe DatentypenKardinalitäten, Elementdeklarationen

Datentypen einfache Datentypen


Vordefi-nierte Typen in XML Schema


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)


Aspekte von DatentypenFundamentale 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


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)


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


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


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>


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:<Gehalt Start=“2002-07-01“>12345</Gehalt>


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


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<Personalien Personalnr=“2002“> <Nachname>Schmidt</Nachname> <Vorname>Otto</Vorname> <Vorname>Heinrich</Vorname> <Geburtsdatum>1961-02-03</Geburtstdatum></Personalien>


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<Lohndaten Steuerklasse=“3“ Kirchensteuer=“RK“/>


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


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></xs:complexType>

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

abstract = „true“ keine direkte Verwendung des Typs möglich


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


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 Steuerklasse = “3“ Kirchensteuer = “RK“ Kinder = “3“ >

<Jahresgehalt Start=“2002-01-01“98765</Jahresgehalt>

</Gehaltsdaten>

Vergleichbar mit Parameter-Entities in DTD


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:complexType></xs:element>

<xs:element name=“Rechnung“> <xs:complexType> <xs:sequence> <xs:element ref=“Betrag“ /> <xs:element name=“Euro“> <xs:complexType> <xs:sequence> <xs:element name=“Betrag“ type=“xs:decimal“ /> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType></xs:element>

globale Deklaration des Element-Namens Betrag

lokale Definition des Elements Betrag

bezieht sich auf global definiertes Element Betrag


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)


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>


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:complexType> <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:complexType> <xs:key name=“Persnr“> <xs:selector xpath=“Angestellte“ /> <xs:field xpath=“@Personalnr“ /> </xs:key></xs:element>


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)


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></xs:element>

alle Angestellten, die in einem Projekt mitarbeiten, müssen auch in der entsprechenden Abteilung vorkommen


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: <Verein Name=“Sachsen Leipzig“>

<Spieler Nummer=“1“ Name=“… /><Spieler Nummer=“2“ Name=“… />

Eindeutigkeit der Spielernummer pro Verein gegebenkein key aus Vereinsname und Spielernummer möglichAusdruck 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


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

– Namensraumzugehörigkeit auch für Unterelemente definierbar


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


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

<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> <birthday>1960-10-12</birthday></Personalien


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


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


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

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


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)


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 erhalten

Hinzufügen von Aspekten und Repräsentationen nicht vorgesehen

XML Schema baut nicht auf Konzepten der Objektorientierung auf (keine wirkliche Vererbung, nur ähnliches Konzept)

XML Schema. © Prof. T. Kudraß, HTWK Leipzig Die 3 Strömungen von XML XML Schema Dokumenten-...

Documents

Transcript of XML Schema. © Prof. T. Kudraß, HTWK Leipzig Die 3 Strömungen von XML XML Schema Dokumenten-...