xml schema. © prof. t. kudraß, htwk leipzig die 3 strömungen von xml xml schema dokumenten-...
TRANSCRIPT
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
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
Überblick über XML Schema
Wiederverwendung Schemadokumentation
Modularisierung, Erweiterung
Konsistenz Eindeutigkeit
Schlüssel, Fremdschlüssel
Struktur komplexe DatentypenKardinalitäten, Elementdeklarationen
Datentypen einfache Datentypen
© Prof. T. Kudraß, HTWK Leipzig
Vordefi-nierte Typen in XML Schema
© Prof. T. Kudraß, HTWK Leipzig
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)
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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)
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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>
© Prof. T. Kudraß, HTWK Leipzig
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>
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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>
© Prof. T. Kudraß, HTWK Leipzig
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“/>
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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 >
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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)
© Prof. T. Kudraß, HTWK Leipzig
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>
© Prof. T. Kudraß, HTWK Leipzig
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>
© Prof. T. Kudraß, HTWK Leipzig
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)
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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)
© Prof. T. Kudraß, HTWK Leipzig
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)