XML Schema-Sprachen 04 G. Görz, J. Schneeberger Lehrstuhl Informatik 8 (KI) goerz@informatik.uni-erlangen.de! josef.schneeberger@fh-deggendorf.de! 1 Übersicht XML Schema-Sprachen Exkurs: Extended Backus-Naur Form (EBNF) Document Type Definition (DTD) W3C XML Schema (XSD) RELAX NG 2
Literatur [W3C 08] T. Bray e.a., Extensible Markup Language (XML) 1.0 (Fifth Edition), 2008. http://www.w3.org/tr/rec-xml/ [MS 06] A. Møller, M. Schwartzbach, An Introduction to XML and Web Technologies, Addison-Wesley, 2006. Kapitel als PDF verfügbar: http://www.brics.dk/ixwt/ixwt_c04c.pdf [Scowen 96] R. Scowen, Extended BNF, ISO/IEC 14977 : 1996(E)! ISO Standard zu EBNF (final draft version SC22/N2249) http://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf [EBNF 96] Extended BNF, ISO 14977, 1996. 3 XML Schema-Sprachen 4
Meta-, Schema-, Objekt-Sprache Meta-Sprache definiert die Syntax von XML Überprüfung der Wohlgeformtheit einer XML-Datei. Schema Eine formale Spezifikation der Elemente einer XML- Sprache. Überprüfung der Validität einer XML-Datei. Schema-Sprache Eine Syntax zur Definition eines Schemas. XSD (XML-Schema-Definition) ist eine Schema- Sprache zur Definition eines Schemas mit Hilfe der XML Meta-Syntax. Objekt-Sprache 5 Validierender Parser Schema De#nition in einer Schema! Sprache" Eingabe! Dokument in der Objekt! Sprache" Parser" valide?" ja" nein" 6
Schema-Sprachen Drei Schema-Sprachen sind weit verbreitet DTD Document Type Definition wurde mit SGML definiert XSD XML Schema-Definition W3C Spezifikation RELAX NG - Regular Language Description for XML New Generation OASIS / ISO Spezifikation 7 Extended Backus-Naur Form (EBNF) 8
EBNF EBNF steht für Extended Backus-Naur Form Die EBNF dient dazu, die Syntax von Programmiersprachen zu definieren. Die Syntax einer Programmiersprache legt fest, welche Programme grammatisch wohlgeformt sind. Mit Hilfe einer Syntax, die selbst formal notiert ist, kann ein Programm erzeugt bzw. verwendet werden, das die grammatische Korrektheit der gegebenen Programme überprüfen kann. Solche Programme bezeichnet man als Parser. 9 EBNF Viele Väter, viele Schreibweisen: J. Backus Erfinder einer Syntax-Notation für Algol P. Naur Verfeinerung der Notation D. Knuth Vorschlag der Benennung in Backus- Naur Form N. Wirth Verwendung für viele Projekte und Vereinheitlichung. ISO 14977 10
EBNF Regel... =...; Konkatenation...,... Alternativen...... Gruppierung (... ) Optionale Elemente [... ] Wiederholung {... } [EBNF 96] 11 Beispiel: XML in EBNF mit eigener Notation (das W3C nennt das one EBNF ) ein Ausschnitt (insgesamt 89 Regeln) document ::= prolog element Misc* element ::= EmptyElemTag STag content ETag STag ::= '<' Name (S Attribute)* S? '>' ETag ::= '</' Name S? '>' EmptyElemTag::= '<' Name (S Attribute)* S? '/>' Attribute ::= Name Eq AttValue Name ::= (Letter '_' ':') (NameChar)* NameChar ::= Letter Digit '.' '-' '_' ': CombiningChar Extender markupdecl ::= elementdecl AttlistDecl EntityDecl NotationDecl PI Comment elementdecl ::= '<!ELEMENT' S Name S contentspec S? '>' contentspec ::= 'EMPTY' 'ANY' Mixed children Mixed ::= '(' S? '#PCDATA' (S? ' ' S? Name)* S? ')*' '(' S? '#PCDATA' S? ')' [W3C 08] 12
DTD Document Type Definition 13 DTD DTD ist das Regelwerk, nach dem sich Objekt- Dokumente richten müssen: welche Elemente das Dokument enthalten darf, welchen Inhalt die Elemente haben dürfen, welche Attribute erlaubt sind, welche Werte die Attribute annehmen können, wie die Elemente und in welcher Reihenfolge die Elemente ineinander geschachtelt werden dürfen, welche speziellen Zeichen (d.h. Entities) verwendet werden können. 14
Element-Deklaration <!ELEMENT Element-Name Inhalts-Modell> Das Inhalts-Modell: EMPTY das Element hat keinen Inhalt (leer) ANY jedes andere Element der DTD kann enthalten sein. mixed content (#PCDATA e1 e2... en)* PCDATA: Parsed Character DATA element content Deklaration der Unterelemente getrennt durch, (Komma). Beispiele: <!ELEMENT collection (description,recipe*)> <!ELEMENT description (#PCDATA)> <!ELEMENT recipe (title,date,ingredient*,preparation, comment?,nutrition,related*)> [MS 06] 15 Operatoren in der DTD $ %%% &" Unterelemente werden in Klammern gesetzt%" %%% ' %%%" Mehrere Unterelemente werden durch Komma getrennt% Damit wird auch die Reihenfolge der Unterelemente festgelegt% " (" Oder!Operator: Man kann eines der angegebenen Unterelemente w)hlen%" *PCDATA " Der Inhalt des Elements kann aus beliebigen Zeichenketten bestehen% " Operatoren zur Angabe der Wiederholungen eines Elements"?" Das Element darf weggelassen oder nur einmal angegeben werden% " *" Das Element kann beliebig o+ angewendet oder ganz weggelassen werden%"," Das Element kann beliebig o+ eingef-gt werden' es muss jedoch mindestens einmal vorkommen% " 16
Attribute von Elementen Attribute werden verwendet, um Elemente näher zu spezifizieren. Eine Attributlisten-Definition in einer DTD hat folgende Eigenschaften: Sie legt fest, welchem Element bestimmte Attribute zugewiesen werden können. Es wird der Typ eines Attributs und die möglichen Werte beschrieben. Sie kann eine bestimmte Voreinstellung eines Attributs erzeugen. Notation <!ATTLIST Element AttributName (Attributtyp)> Beispiel: <!ATTLIST ingredient name CDATA #REQUIRED amount CDATA #IMPLIED unit CDATA #IMPLIED> [MS 06] 17 Typen von Attributen CDATA eine beliebige Zeichenkette NMTOKEN / NMTOKENS damit können die erlaubten Zeichen (Buchstaben, Ziffern. : - _) für ein Attribut festgelegt werden ID das Attribut muss in der Datei eindeutig sein. IDREF / IDREFS verweist auf ein Element, das zuvor mit dem Attributtyp ID angelegt wurde. Es kann also nur angewendet werden, wenn ein Element mit der entsprechenden Referenz-ID vorhanden ist. #REQUIRED notwendige Angabe #IMPLIED mögliche Angabe Beispiel: <!ATTLIST recipe id ID #IMPLIED> <recipe id="r1">...</recipe> 18
Entities / Platzhalter für Zeichen Entities (Platzhalter) stellen Sonderzeichen mit Hilfe von Bezeichnungen dar. Notation: &Bezeichnung; Deklaration einer Entity: <!ENTITY bezeichnung zeichenkette > Wird häufig wie ein Macro verwendet, um Zeichenfolgen abzukürzen. Beispiel: <!ENTITY abloeschen "Den Bratensatz mit Wein ablöschen."> 19 Beispiel: Entities in HTML )" deutscher Umlaut' ae klein" ä"." deutscher Umlaut' Ae gro/" Ä" 0" deutscher Umlaut' oe klein" ö " 1" deutscher Umlaut' Oe klein" Ö " 2" deutscher Umlaut' Ue gro/" Ü " -" deutscher Umlaut' ue klein" ü" /" deutsches Sonderzeichen sz" ß" "" Euro!Zeichen" " " Paragraphen!Zeichen" " 3" ein Viertel" ⅘" 20
Typen von Attributen Verweis auf externe ( parsed ) Quellen: <!ENTITY bezeichnung SYSTEM "url"> url enthält XML, das für die Entity verwendet wird (Macro Expansion). Verweis auf externe (unparsed) Quellen, die kein XML enthalten. Beispiele (Verwendung eines Bildes): <!ENTITY logo SYSTEM "http://www.url.de/logo.gif" NDATA gif > <!NOTATION gif SYSTEM "http://www.iana.org/assignments/media-types/image/gif"> <!ATTLIST thing img ENTITY #REQUIRED> 21 Beispiel-DTD <!ELEMENT collection (description,recipe*)> <!ELEMENT description (#PCDATA)> <!ELEMENT recipe (title,date,ingredient*,preparation, comment?,nutrition,related*)> <!ATTLIST recipe id ID #IMPLIED> <!ELEMENT title (#PCDATA)> <!ELEMENT date (#PCDATA)> <!ELEMENT ingredient (ingredient*,preparation)?> <!ATTLIST ingredient name CDATA #REQUIRED amount CDATA #IMPLIED unit CDATA #IMPLIED> <!ELEMENT preparation (step*)> <!ELEMENT step (#PCDATA)> <!ELEMENT comment (#PCDATA)> <!ELEMENT nutrition EMPTY> <!ATTLIST nutrition calories CDATA #REQUIRED carbohydrates CDATA #REQUIRED... 22 [MS 06]
Interne DTD Eine DTD kann direkt im XML-Dokument (intern) oder per Verweis (extern) auf eine Datei angegeben werden. interne DTD" <?xml version="1.0" encoding="utf-8" standalone="yes"?> <! DOCTYPE collection [... Definition der einzelnen Element...] > <collection> Wurzelelement"... </collection> 23 Externe Definition einer DTD Wenn eine DTD für mehrere XML-Dokumente verwendet werden soll, dann wird sie als externe Datei verwaltet. <?xml version="1.0" encoding="utf-8" standalone="no"?> <!DOCTYPE collection SYSTEM "datei-oder-uri.dtd"> <collection>... </collection> externe DTD" Referenz" externe DTD" 24
Gültigkeit / Validität Ein wohlgeformtes XML-Dokument muss aus einem Prolog und mindestens einem Element bestehen. In einem gültigen Dokument (engl. valid document ) müssen zusätzlich die folgenden Kriterien erfüllt sein: Eine interne oder externe DTD muss spezifiziert sein. Das Dokument muss sich an die Regeln der DTD halten. Es dürfen nur die in der DTD definierten Elemente innerhalb des Dokuments benutzt werden. Alle notwendigen Attribute müssen verwendet werden. Die Werte der Attribute müssen gültig sein. Alle Inhalte der Elemente müssen den festgelegten Datentypen entsprechen. 25 Mischen von DTDs Mischen von DTDs ist nicht einfach Beispiel für eine DTD, die mehrere andere DTDs zusammenführt (XHTML+MathML+SVG mit Namespaces): www.w3.org/tr/xhtmlplusmathmlplussvg/ Einfacher: DTDs zusammenkopieren und Namespaces dazufügen. DTDs unterstützten keine Namespaces (verbieten sie aber auch nicht) In der DTD müssen die Elementnamen dann einfach zusammen mit dem Namespace-Präfix angegeben werden. Beispiel: <!ELEMENT rcp:recipe... statt <!ELEMENT recipe... 26
Probleme mit DTDs Zusammenführen mehrerer DTD ist nichttrivial. Sehr grobe Typenklassen Keine Beschränkung auf Zahlen-Bereiche Keine Booleschen Werte Keine Zeitangaben... Daher als Basis für den Datenaustausch zwischen Softwaresystemen nur sehr bedingt brauchbar. 27 Beschränkungen von DTDs 1. Zeichenketten können nicht weiter eingeschränkt werden (z.b. @ bei Email Adressen). 2. Die Spezifikation von Attributen ist sehr beschränkt (z.b. alle Attribute sind optional oder keines) 3. Element- und Attribut-Deklarationen sind kontextsensitiv. 4. Zeichenketten können nicht durch reguläre Ausdrücke beschrieben werden. D.h., wenn Text und Elemente kombiniert werden, dann kann für die Elemente weder eine Reihenfolge noch Wiederholungsbeschränkungen angegeben werden. 5. Die Reihenfolge von Elementen kann nicht flexibel spezifiziert werden. 6. Nur sehr eingeschränkte Unterstützung zur Modularisierung, Wiederverwendung und Weiterentwicklung von DTDs. 7. Schlechte Unterstützung bei der Normalisierung von Leerzeichen (whitespace characters). 8. Keine eingebaute Selbstdokumentation von Elementen in DTDs. 9. Der ID/IDREF Mechanismus von DTDs ist sehr beschränkt. 10. DTDs benutzen eine eigene Syntax nicht die XML Syntax. 11. Keine Unterstützung von Namenräumen. Siehe Kap. 4.3.7 in [MS 06] 28
XML Schema Definition 29 Anforderungen an XML Schema W3C Standard zur Ersetzung von DTDs Entwurfsprinzipien: Ausdrucksstärker als DTDs. Verwendung der XML Meta-Syntax. Selbstbeschreibend in einem XML Schema können deklarierte Elemente auch kommentiert werden. Technische Anforderungen: Unterstützung von Namespaces. Datentypen sollen durch den Benutzer definierbar sein. Vererbung. Evolutionäre Weiterentwicklung von XML Schemas. 30
XML Schema Objekt-orientierte Typ-Deklarationen für XML-Dokumente. Eine XML-Schema-Datei enthält: Direktiven Import weiterer Dateien und Deklarationen Typen (Beschreibungen der Objekte der Domäne) Einfache Typen (simple types): Unicode Zeichenketten Zusammengesetzte Typen (complex types) in einer Typhierarchie. Element-Deklarationen Attribute-Deklarationen Attribute können auch als Attributgruppen deklariert werden. Kompositionsmechanismen Mechanismen zur eigenen Spezifikation abgeleiteter Typen (Typenhierarchien) String-Muster zur Definition von abgeleiteten Basis-Typen 31 Die XML Schema-Datei <?xml version="1.0" encoding="utf-8"> <xs:schema xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns="http://my.namespace.uri"> <xs:element name="rootelement">... </xs:element>... </xs:schema> Namespace f-r XML Schema " Der Standard! Namespace f-r die deklarierten Elemente" 32
Ein Beispiel Namespace' f-r den die Elemente in diesem Schema beschrieben werden" <?xml version="1.0" encoding="utf-8"?> <xsd:schema targetnamespace="http://www.example.org/beispiel" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:tns="http://www.example.org/beispiel" elementformdefault="qualified"> <xsd:element name="recipe" type="tns:recipetype" /> <xsd:attribute name="id" type="xsd:string"/> <xsd:attribute name="calories" type="tns:calories"/> <xsd:complextype name="recipetype"> <xsd:attribute ref="tns:id" use="required"/> <xsd:attribute ref="tns:calories" use="optional"/> </xsd:complextype> <xsd:simpletype name="calories"> <xsd:restriction base="xsd:integer"> <xsd:mininclusive value="0"/> <xsd:maxinclusive value="5000"/> </xsd:restriction> </xsd:simpletype> </xsd:schema> Dieser Namespace in Benutzung" complextype: Paar aus id und Zahl" simpletype: die Zahlen 6 bis 7666" Element! Deklarationen" Attribut! Deklarationen" 33 Noch ein Beispiel: Das recipes Schema <schema xmlns="http://www.w3.org/2001/xmlschema" xmlns:r="http://www.brics.dk/ixwt/recipes" targetnamespace="http://www.brics.dk/ixwt/recipes" elementformdefault="qualified"> collection" <element name="collection"> <complextype> <sequence> <element name="description" type="string"/> <element ref="r:recipe" minoccurs="0" maxoccurs="unbounded"/> </sequence> </complextype> <unique name="recipe-id-uniqueness"> <selector xpath=".//r:recipe"/> <field xpath="@id"/> </unique> <keyref name="recipe-references" refer="r:recipe-id-uniqueness"> <selector xpath=".//r:related"/> <field xpath="@ref"/> </keyref> receipe" <element name="recipe"> <complextype> <sequence> <element name="title" type="string"/> <element name="date" type="string"/> <element ref="r:ingredient" minoccurs="0" maxoccurs="unbounded"/> <element ref="r:preparation"/> <element name="comment" type="string" minoccurs="0"/> <element ref="r:nutrition"/> <element ref="r:related" minoccurs="0" maxoccurs="unbounded"/> </sequence> <attribute name="id" type="nmtoken"/> </complextype> [MS 06] <element name="ingredient"> <complextype> <sequence minoccurs="0"> <element ref="r:ingredient" minoccurs="0" maxoccurs="unbounded"/> <element ref="r:preparation"/> </sequence> <attribute name="name" use="required"/> <attribute name="amount" use="optional"> <simpletype> <union> <simpletype> <restriction base="r:nonnegativedecimal"/> </simpletype> <simpletype> <restriction base="string"> <enumeration value="*"/> </restriction> </simpletype> </union> </simpletype> </attribute> <attribute name="unit" use="optional"/> </complextype> <element name="preparation"> <complextype> <sequence> <element name="step" type="string" minoccurs="0" maxoccurs="unbounded"/> </sequence> </complextype> <element name="nutrition"> <complextype> <attribute name="calories" type="r:nonnegativedecimal" use="required"/> <attribute name="protein" type="r:percentage" use="required"/> <attribute name="carbohydrates" type="r:percentage" use="required"/> <attribute name="fat" type="r:percentage" use="required"/> <attribute name="alcohol" type="r:percentage" use="optional"/> </complextype> <element name="related"> <complextype mixed="true"> <attribute name="ref" type="nmtoken" use="required"/> </complextype> <simpletype name="nonnegativedecimal"> <restriction base="decimal"> <mininclusive value="0"/> </restriction> </simpletype> <simpletype name="percentage"> <restriction base="string"> <pattern value="([0-9] [1-9][0-9] 100)%"/> </restriction> </simpletype> </schema> preparation" nutrition" related" ingredient" simpletype:" nonnegativedecimal " 34 simpletype: percentage"
Deklarationen XML Schema-Dateien enthalten Deklarationen für: Elemente Attribute Simple Types Complex Types Simple und Complex Types werden verwendet, um Elemente zu deklarieren. Attribute können nur mit Hilfe von Simple Types deklariert werden. Simple/Complex Types werden von Element-/Attribut- Deklarationen auf zwei Arten verwendet: durch Referenz mit dem type-attribut auf den Namen des Simple/Complex Type. durch Spezifikation direkt im Element/Attribut ohne Namen (anonym). 35 Elemente Name des Elements Ein Typ, Complex oder Simple, kann auch direkt spezifiziert werden. Default-Wert Attribute Name des Attributs Referenz auf Typ Default-Wert Verwendungsvorschrift Deklarationen Referenziert auf Simple oder Complex Type" <xs:element name="elem" type="xs:yyy" default="wert"/> <xs:element name="elem"> <complextype>...</complextype> Anonyme <xs:attribute name="attrib" De#nition" type="xs:xxx" default="wert" use="required" /> <xs:attribute name="attrib"> <simpletype>... </xs:attribute> 36
Simple und Complex Types SimpleType Dient zur Deklaration von Elementen, die ausschließlich Text enthalten d.h. keine Unterelemente. Der enthaltene Text kann aber durch die Angabe eines Datentyps eingeschränkt werden. Attribute können nur mit Hilfe von Simple Type deklariert werden. ComplexType Dient zur Deklaration von Elementen, die weitere Elemente als Unterelemente haben können. Wenn die Unterelemente sowohl Text als auch Mark- Up (Elemente) sind, wird das als mixed bezeichnet. Ein Complex Type setzt sich aus Referenzen auf Element- und Attribut- Deklarationen zusammen. 37 Abgeleitete Typen (Derived Types) Neue Simple Types als auch neue Complex Types können durch Bezug auf bestehende Simple bzw. Complex Types deklariert werden. Dabei erbt der neue (Simple/Complex) Type die Eigenschaften des bestehenden Type. Abgeleitete Simple Types benutzen einen der vielen vordefinierten Simple Types Auch unter den vordefinierten Simple Types gibt es abgeleitete S.T. Simple Types können durch Erweiterungen oder Einschränkungen des Element-Inhalts und der Attribute abgeleitet werden. Abgeleitete Complex Types Complex Types können von Simple Types abgeleitet werden das heißt dann Simple Content. Complex Types können von Complex Types abgeleitet werden das heißt dann Complex Content. Complex Types können durch Erweiterungen oder Einschränkungen des Element-Inhalts und der Attribute abgeleitet werden. 38
Typ" string" Werte" Simple Types eine Unicode!Zeichenkette" boolean" true' false' 4' 6" decimal" 8%4547" 9oat" double" datetime" :%6;;454<<E;8" 5;E<=6" ;665!6<!;:T4::;<:66!67:66" time" 4::;<:66!67:66" date" ;665!6<!;:" hexbinary" base:5binary" anyuri" QName" 5>:7:c:c:f6a" SGVsbG>K" http:??www%brics%dk?ixwt?" rcp:recipe' recipe" %%%" [MS 06] 39 Abgeleitete Simple Types (1) Mögliche Einschränkungen der Standard-Typen: Länge einer Zeichenkette oder Zahl Minimale bzw. maximale Länge Durch einen regulären Ausdruck Vorgabe der Werte durch eine Aufzählung Ober- und Untergrenze für Zahlen Länge der Teile einer Zahl vor und nach dem Dezimalpunkt <simpletype name="nonnegativedecimal"> <restriction base="decimal"> <mininclusive value="0"/> </restriction> </simpletype> 40 [MS 06] <simpletype name="percentage"> <restriction base="string"> <pattern value= "([0-9] [1-9][0-9] 100)%"/> </restriction> </simpletype>
Abgeleitete Simple Types (2) Mit einem Listen- Konstruktor Durch Vereinigung <simpletype name="integerlist"> <list itemtype="integer"/> </simpletype> <simpletype name="boolean_or_decimal"> <union> <simpletype> <restriction base="boolean"/> </simpletype> <simpletype> <restriction base="decimal"/> </simpletype> </union> </simpletype> [MS 06] 41 Vordefinierte abgeleitete Simple Types string normalizedstring token language DTD Emulation Name, NCName ID, IDREF notation Zeitangaben date time duration decimal integer (positive/negative) short (unsigned) long (unsigned) int byt (unsigned) enumeration totaldigits, fractiondigits,... float double 42
Complex Types Dienen sowohl zur Beschreibung von Elementen als auch Attributen. Complex Types werden beschrieben durch reguläre Ausdrücke mit folgenden Bestandteilen: Referenzen auf Elemente <element ref="name"/> Aneinanderreihung (Konkatenation) <sequence> </sequence> Vereinigung mit optionaler Benutzung: <union> </union> Vereinigung mit verpflichtender Benutzung: <all> </all> Wildcard Referenzen auf Elemente: <any namespace= " processcontents= "> </any> Referenzen auf Attribute <attribute ref="name"/> Wildcard Referenzen auf Attribute: <anyattribute namespace= processcontents= "> 43 Complex Types: Beispiel [MS 06] 44
Complex Types, Simple Content Beispiele für die Erweiterung und Beschränkung komplexer Typen mit einfachem Inhalt (Simple Type). [MS 06] 45 Complex Types, Complex Content <complextype name="basic_card_type"> <sequence> <element ref="b:name"/> </sequence> </complextype> Achtung: Extension ist nicht invers zu Restriction [MS 06] 46
Sei... Abgeleitete Typen / Subsumtion T ein Typ und T- ist ein abgeleiteter Typ von T mit Einschränkungen (Restriction) T+ ist ein abgeleiteter Typ von T mit Erweiterungen (Extension) Subsumtion: Immer, wenn T in einem Instanz-Dokument benötigt wird, dann kann eine T- Instanz verwendet werden (trivial), oder eine T+ Instanz kann verwendet werden, wenn die Instanz xsi:type= T+ hat. (wobei xmlns:xsi=http://www.w3.org/2001/xmlschema-instance) Ableitung, Instanziierung und Subsumtion können durch die Schlüsselwörter final, abstract, und block weiter beschränkt werden. 47 Verwendung von Schema-Definitionen Verwendung in einem XML-Dokument Mit Namensraum-Definition <rootelement xmlns="basis-namensraum" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="schemadatei.xsd">... </rootelement> Ohne Namensraum-Definition <rootelement xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:nonamespaceschemalocation="schemadatei.xsd">... </rootelement> 48
Beschränkungen von XML Schema 1. Die Spezifikation ist sehr komplex mit vielen sehr speziellen Details 2. Deklarationen können nicht auf den Kontext Bezug nehmen (wird aber häufig gebraucht, z.b. wenn zwei Attribute voneinander abhängen) 3. XML Schema kann nicht mit XML Schema beschrieben werden. 4. Wenn Elemente Text und Unterelemente enthalten (mixed content), dann können keine Beschränkungen für den Text definiert werden. 5. Die Verwendung anonymer lokaler Elemente (unqualified local elements) widerspricht der Verwendung von Namensräumen. 6. Das Wurzelelement kann nicht festgelegt werden (es sei denn, es gibt nur ein definiertes globales Wurzelelement). 7. Standardwerte für Elemente können keine Auszeichnungen (Unterelemente) enthalten. 8. Das Typ-System ist übermäßig kompliziert. 9. xsi:type ist problematisch. 10. Die Simple Type-Definitionen sind unflexibel. [MS 06] 49 Stärken von XML Schema Unterstützung von Namensräumen Das Datentyp-System Die Unterstützung der Modularisierung Die Ableitung von Datentypen 50
RELAX NG 51 RELAX NG Unterstützung durch OASIS + ISO in Konkurrenz zum W3C Nur Validierung keine Normalisierung Zielsetzung bei der Definition: Einfachheit Ausdrucksstärke Saubere mathematische Grundlagen http://www.relaxng.org/ 52
Verarbeitungs-Modell Ausgehend von einem Wurzelelement muss das Dokument die RelaxNG-Spezifikation in Form eines Musters (Pattern) erfüllen. Ein Muster kann auf Elemente, Attribute oder Zeichenketten passen ( matchen ). Muster für Elemente können wiederum Unterelemente enthalten, die wiederum Zeichenketten und Attribute enthalten können. 53 Grundstruktur einer RelaxNG-Datei Muster (Patterns) als Bestandteile einer Grammatik <grammar...> <start>... </start> <define name="...">... </define>... Wurzelelement grammar" Wurzelelement der Instanz!Dokumente" Muster f-r Elemente; k0nnen Unterelemente enthalten%" </grammar> 54
Muster (Patterns) Muster (Patterns) orientieren sich an der Definition von Regular Hedge Expressions <element name=... >... <attribute name=... >... </attribute> <text/> <group>... </group> (concatenation) <optional>... </optional> <zeroormore>... </zeroormore> <oneormore>... </oneormore> <choice>... </choice> (union) <empty/> <interleave>... </interleave> <mixed>... </mixed> Regular hedge expressions z.b.: http://homepages.inf.ed.ac.uk/wadler/planx/planx-eproceed/papers/e00-699879232.pdf 55 Weitere Eigenschaften Unterstützung für die Modularisierung der Schema-Definitionen Es gibt auch eine alternative Notation in einer C-ähnlichen (nicht XML) Syntax Datentypen es wird fast immer die XML Schema-Spezifikation verwendet. 56
Beispiel: das recipes-schema <?xml version="1.0" encoding="utf-8"?> <grammar xmlns="http://relaxng.org/ns/structure/1.0" ns="http://www.brics.dk/ixwt/recipes" datatypelibrary="http://www.w3.org/2001/xmlschema-datatypes"> <start> <element name="collection"> <element name="description"> <text /> collection" <zeroormore> <ref name="element-recipe" /> </zeroormore> </start> <define name="element-recipe"> receipe" <element name="recipe"> <optional> <attribute name="id"> <data datatypelibrary="http://www.w3.org/2001/xmlschema-datatypes" type="id" /> </attribute> </optional> <interleave> <group> <element name="title"> <text /> <element name="date"> <text /> <zeroormore> <ref name="element-ingredient" /> </zeroormore> <ref name="element-preparation" /> nutrition" <element name="nutrition"> <ref name="attributes-nutrition" /> <zeroormore> <ref name="element-related" /> </zeroormore> </group> <optional> <element name="comment"> <text /> </optional> [MS 06] </interleave> </define> <define name="element-ingredient"> <element name="ingredient"> <attribute name="name" /> <choice> <group> <attribute name="amount"> <choice> <value>*</value> <ref name="number" /> </choice> </attribute> <optional> <attribute name="unit" /> </optional> </group> <group> <zeroormore> <ref name="element-ingredient" /> </zeroormore> <ref name="element-preparation" /> </group> </choice> </define> <define name="element-preparation"> <element name="preparation"> <zeroormore> <element name="step"> <text /> </zeroormore> </define> <define name="attributes-nutrition"> <attribute name="calories"> <ref name="number" /> </attribute> <attribute name="protein"> <ref name="percentage" /> </attribute> <attribute name="carbohydrates"> <ref name="percentage" /> </attribute> <attribute name="fat"> <ref name="percentage" /> </attribute> <optional> <attribute name="alcohol"> <ref name="percentage" /> </attribute> </optional> </define> <define name="element-related"> <element name="related"> <attribute name="ref"> <data datatypelibrary="http://www.w3.org/2001/xmlschema-datatypes" type="idref" /> </attribute> </define> <define name="percentage"> <data type="string"> <param name="pattern">([0-9] [1-9][0-9] 100)%</param> </data> </define> <define name="number"> <data type="decimal"> <param name="mininclusive">0</param> ingredient" preparation" related" Number" percentage" 57 Vorteile von RelaxNG Deklarationen in XML oder einer eigenen Syntax (Nachteil?) Starke Unterstützung von ungeordneten Inhalten Elemente können in einer beliebigen Reihenfolge notiert werden. Erlaubt nicht-deterministisches Inhaltsmodell / Instanz-Dokumente. Es können Zusammenhänge zwischen Attributen und zwischen Attributen und Unterelementen formuliert werden. Beispiel: Wenn kein Attributname angegeben ist, dann muss ein Unterelement <name> vorhanden sein. RelaxNG Schemas können in XML Schemas und DTDs konvertiert werden. Umgekehrt geht das nicht. Siehe: http://en.wikipedia.org/wiki/xml_schema_language_comparison 58
Entwurf von XML Schemas Wie entwirft man ein Schema? Wie nutzt man bestehende Schemas und DTD? Wie verwendet man Vererbung? Wie verhindert man Vererbung? 59