Übersicht · Meta-, Schema-, Objekt-Sprache • Meta-Sprache – definiert die Syntax von XML – Überprüfung der Wohlgeformtheit einer XML-Datei

XML Schema-Sprachen 04

G. Görz, J. Schneeberger Lehrstuhl Informatik 8 (KI)

[email protected][email protected]!

1 G. Görz, FAU, Inf.8

Übersicht

•  XML Schema-Sprachen

•  Exkurs: Extended Backus-Naur Form (EBNF) •  Document Type Definition (DTD) •  W3C XML Schema (XSD)

•  RELAX NG


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.

G. Görz, FAU, Inf.8 3

XML Schema-Sprachen


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

6

Eingabe!Dokument in der Objekt!Sprache"

Parser"

Schema De#nition in einer Schema!Sprache"

valide?" ja"

nein"

G. Görz, FAU, Inf.8

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


Extended Backus-Naur Form (EBNF)


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.


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


EBNF

•  Regel ... = ...;

•  Konkatenation ... , ...

•  Alternativen ... | ...

•  Gruppierung ( ... )

•  Optionale Elemente [ ... ]

•  Wiederholung { ... }

11 [EBNF 96] G. Görz, FAU, Inf.8

Beispiel: XML in EBNF

12

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]

… mit eigener Notation (das W3C nennt das „one EBNF“) …ein Ausschnitt (insgesamt 89 Regeln)


DTD – Document Type Definition


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.


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:

15

<!ELEMENT collection (description,recipe*)> <!ELEMENT description (#PCDATA)> <!ELEMENT recipe (title,date,ingredient*,preparation, comment?,nutrition,related*)>

[MS 06] G. Görz, FAU, Inf.8

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


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:

17

<!ATTLIST ingredient name CDATA #REQUIRED amount CDATA #IMPLIED unit CDATA #IMPLIED> [MS 06]


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:

18

<!ATTLIST recipe id ID #IMPLIED> <recipe id="r1">...</recipe>


19

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


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" &frac45;"


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

21

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


Beispiel-DTD

22

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


Interne DTD

•  Eine DTD kann direkt im XML-Dokument (intern) oder per Verweis (extern) auf eine Datei angegeben werden.

23

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> < ! DOCTYPE collection [ ... Definition der einzelnen Element ...] > <collection> ... </collection>

interne DTD"

Wurzelelement"


Externe Definition einer DTD

•  Wenn eine DTD für mehrere XML-Dokumente verwendet werden soll, dann wird sie als externe Datei verwaltet.

24

<?xml version="1.0" encoding="UTF-8" standalone="no" ?> <!DOCTYPE collection SYSTEM "datei-oder-uri.dtd"> <collection> ... </collection>

externe DTD"

Referenz"externe DTD"


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.


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


Probleme mit DTDs

•  Zusammenführen mehrerer DTD ist nicht-trivial.

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


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.

28 Siehe Kap. 4.3.7 in [MS 06] G. Görz, FAU, Inf.8

XML Schema–Definition


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.


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


Die XML Schema-Datei

32

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


Ein Beispiel

33

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

simpleType: die Zahlen 6 bis 7666"

Attribut!Deklarationen"

Element!Deklarationen"

complexType: Paar aus id und Zahl"

Namespace' f-r den die Elemente in diesem Schema beschrieben werden"

Dieser Namespace in Benutzung"


34

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

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

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

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

<element name="preparation"> <complexType> <sequence> <element name="step" type="string" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> </element>

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

<element name="related"> <complexType mixed="true"> <attribute name="ref" type="NMTOKEN" use="required"/> </complexType> </element>

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

Noch ein Beispiel: Das recipes Schema

collection"

receipe"

ingredient"

preparation"

nutrition"

related"

simpleType:"nonNegativeDecimal "

simpleType: percentage"[MS 06]

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 G. Görz, FAU, Inf.8

Deklarationen

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

vorschrift

36

<xs:element name="elem" type="xs:yyy" default="wert"/>

<xs:element name="elem"> <complexType>...</complexType> </element>

<xs:attribute name="attrib" type="xs:xxx" default="wert" use="required" />

<xs:attribute name="attrib"> <simpleType>... </xs:attribute>

Referenziert auf Simple oder Complex Type"

Anonyme De#nition"


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.


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.


Simple Types Typ" Werte"string" eine Unicode!Zeichenkette"boolean" true' false' 4' 6"decimal" 8%4547"9oat" :%6;;454<<E;8"double" 5;E<=6"dateTime" ;665!6<!;:T4::;<:66!67:66"time" 4::;<:66!67:66"date" ;665!6<!;:"hexBinary" 5>:7:c:c:f6a"base:5Binary" SGVsbG>K"anyURI" http:??www%brics%dk?ixwt?"QName" rcp:recipe' recipe"%%%" 39 [MS 06] G. Görz, FAU, Inf.8

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

40

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

[MS 06]

Abgeleitete Simple Types (2)

•  Mit einem Listen-Konstruktor

•  Durch Vereinigung

41

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


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


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=“…"> …


Complex Types: Beispiel

44

[MS 06]


Complex Types, Simple Content

45

[MS 06]

Beispiele für die Erweiterung und Beschränkung komplexer Typen mit einfachem Inhalt (Simple Type).

Complex Types, Complex Content

46

<complexType name="basic_card_type"> <sequence> <element ref="b:name"/> </sequence> </complexType>

Achtung: „Extension“ ist nicht invers zu „Restriction“


Abgeleitete Typen / Subsumtion Sei ...

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


Verwendung von Schema-Definitionen

•  Verwendung in einem XML-Dokument –  Mit Namensraum-Definition

–  Ohne Namensraum-Definition

48

<rootelement xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="schemaDatei.xsd"> ... </rootelement>

<rootelement xmlns="Basis-Namensraum" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="schemaDatei.xsd"> ... </rootelement>


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.

49

[MS 06]


Stärken von XML Schema

•  Unterstützung von Namensräumen

•  Das Datentyp-System •  Die Unterstützung der Modularisierung •  Die Ableitung von Datentypen


RELAX NG


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/


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.


Grundstruktur einer RelaxNG-Datei

•  Muster (Patterns) als Bestandteile einer Grammatik

54

<grammar ...> <start> ... </start>

<define name="..."> ... </define>

...

</grammar>

Wurzelelement grammar"

Wurzelelement der Instanz!Dokumente"

Muster f-r Elemente; k0nnen Unterelemente enthalten%"


Muster (Patterns) •  Muster (Patterns) orientieren sich an der

Definition von „Regular Hedge Expressions“

55

Regular hedge expressions z.B.: http://homepages.inf.ed.ac.uk/wadler/planx/planx-eproceed/papers/E00-699879232.pdf

<element name=”...”> ... </element> <attribute name=”...”> ... </attribute> <text/> <group> ... </group> (concatenation) <optional> ... </optional> <zeroOrMore> ... </zeroOrMore> <oneOrMore> ... </oneOrMore> <choice> ... </choice> (union) <empty/> <interleave> ... </interleave> <mixed> ... </mixed>

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.


57

<?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 /> </element> <zeroOrMore> <ref name="element-recipe" /> </zeroOrMore> </element> </start> <define name="element-recipe"> <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> <element name="date"> <text /> </element> <zeroOrMore> <ref name="element-ingredient" /> </zeroOrMore> <ref name="element-preparation" /> <element name="nutrition"> <ref name="attributes-nutrition" /> </element> <zeroOrMore> <ref name="element-related" /> </zeroOrMore> </group> <optional> <element name="comment"> <text /> </element> </optional> </interleave> </element> </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> </element> </define> <define name="element-preparation"> <element name="preparation"> <zeroOrMore> <element name="step"> <text /> </element> </zeroOrMore> </element> </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> </element> </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>

Beispiel: das recipes-Schema

collection"

receipe"

ingredient"

preparation"

nutrition" related"

Number"

percentage"[MS 06]

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


Entwurf von XML Schemas

•  Wie entwirft man ein Schema?

•  Wie nutzt man bestehende Schemas und DTD?

•  Wie verwendet man Vererbung? •  Wie verhindert man Vererbung?


Documents

Übersicht · Meta-, Schema-, Objekt-Sprache • Meta-Sprache – definiert die Syntax von XML – Überprüfung der Wohlgeformtheit einer XML-Datei