XML: Schemas. aktuelle Version: 1 Verweis auf ein Schema 2

Transkript

1 XML: Schemas Holger Jakobs aktuelle Version: Inhaltsverzeichnis 1 Verweis auf ein Schema 2 2 Zweck eines Schemas 2 3 Validieren von Schemas und Dokumenten 4 4 Aufbau eines Schemas Schema-Deklaration Schema-Verweis Einfache Elemente vordefinierte Datentypen eigene einfache Datentypen Komplexe Elemente Sequenzen Auswahl Alle Häufigkeit gemischter Inhalt Attribute Attribute erlauben Datentyp von Attributen Pflichtattribute Eindeutige und verweisende Attribute Attribute mit festem Wert Spezialfälle Online-Referenz

2 2 ZWECK EINES SCHEMAS Schemas sind die jüngere Form einer Darstellung dessen, was in einem XML-Dokument enthalten sein darf und was nicht. Wie bereits DTDs 1 sind auch Schemas ein W3C-Standard 2 (genauer, seit 2001 eine W3C-Empfehlung) und können wie DTDs dazu verwendet werden, ein XML-Dokument zu validieren. 1 Verweis auf ein Schema Einem XML-Dokument kann ein Schema zugeordnet sein, indem am Beginn ein Verweis darauf enthalten ist. Mit Hilfe eines Validators (siehe Abschnitt 3 auf Seite 4) kann man dann prüfen, ob das Dokument den Vorschriften des Schemas genügt. Man sollte sich aber überlegen, ob man die Auswahl des Schemas, gegen das man prüfen möchte, dem Dokument überlässt oder ob man es nicht lieber selbst separat angeben möchte, z. B. in Form eines Parameters an das validierende Programm. <?xml version="1.0"?> <notiz xmlns:xsi=" xsi:nonamespaceschemalocation="notiz.xsd"> <von>minnie</von> <an>mickey</an> <ueberschrift>reminder</ueberschrift> <text>see you this weekend</text> </notiz> Im Gegensatz zu DTDs kann ein Schema nicht im XML-Dokument selbst enthalten sein, sondern ist immer eine separate Datei. 2 Zweck eines Schemas Warum braucht man Schemas? Der Zweck ist eigentlich der gleiche wie bei Document Type Definitions 3, nur dass sie viel mehr können. Es geht also um die Prüfung, ob ein Dokument richtig strukturiert ist. Die Wohlgeformtheit wird von allen XML-Parsern ohnehin überprüft, weil sie nicht wohlgeformte Dokumente gar nicht verarbeiten können. Die Gültigkeit geht aber sehr viel weiter, und Schemas sind ein hervorragendes Mittel, die Struktur eines XML-Dokuments zu beschreiben. 1) siehe 2) 3) siehe 2

3 2 ZWECK EINES SCHEMAS Dies kann immer dann eingesetzt werden, wenn eine XML-Schnittstelle zwischen zwei Systemen verwendet werden soll, beispielsweise beim Datenaustausch zwischen einem Auftraggeber und einem Auftragnehmer. Mit natürlicher Sprache kann man die erlaubten Elemente, Attribute usw. gar nicht exakt beschreiben, aber ein Schema ist eine klare Anweisung, was erlaubt und notwendig ist und was nicht. Die Prüfung, ob ein erzeugendes System die Daten richtig geschrieben hat, lässt sich leicht automatisieren. Gerade während der Entwicklung neuer Software, die XML-Dokumente erzeugen soll, hilft die Überprüfung der Ergebnisse mit einem Validator. Ebenso bei Streitfällen, wenn ein Dokument nicht oder nicht richtig verarbeitet wurde. Was kann ein Schema alles leisten? Ein XML Schema... ˆ definiert die Elemente, die in einem Dokument vorkommen dürfen. ˆ legt die Attribute fest, die vorkommen dürfen. ˆ legt fest, welche Kind-Elemente ein Element haben darf. ˆ legt die Reihenfolge der Kind-Elemente eines Elements fest. ˆ legt die Anzahl der Kind-Elemente fest. ˆ legt fest, ob ein Element leer sein darf. ˆ legt Datentypen fest. ˆ legt default- und fest eingestellte Werte fest. Schemas sind Nachfolger der DTDs und haben wesentliche Vorteile gegenüber diesen, auch wenn sie sie noch lange nicht vollständig abgelöst haben. XML Schemas... ˆ sind erweiterbar. ˆ sind aussagekräftiger und hilfreicher als DTDs. ˆ sind selbst in XML geschrieben. ˆ unterstützen viele Datentypen, so dass z. B. auch Datumswerte auf Gültigkeit geprüft werden können. ˆ kennen reguläre Ausdrücke. ˆ unterstützen Namensräume. ˆ können aber keine Entities definieren. 3

4 3 VALIDIEREN VON SCHEMAS UND DOKUMENTEN Die Unterstützung für umfangreiche Datentypprüfungen sind wohl der wesentlichste Vorteil von Schemas gegenüber DTDs. Es sind viel genauere und strengere Prüfungen möglich, weil es erstens viele vordefinierte Datentypen gibt (nicht nur einfach PCDATA), die zudem auch noch mit weiteren Einschränkungen versehen werden können, z. B. mit Längeneinschränkungen und der Prüfung gegen reguläre Ausdrücke bei Zeichenketten und Werteinschränkungen bei Zahlenwerten. Dass die Schemas selbst XML-Dokumente sind, macht die Handhabung viel einfacher, denn man muss keine zweite Sprache mehr erlernen und die Schemas selbst können auch validiert werden. Wenn man sie mit Hilfe eines XML-Editors schreibt, kann man auch nur wohlgeformte Schemadokumente erzeugen. Durch den vordefinierten Datentypen date, der sich sinnvollerweise an ISO orientiert, ist das Formatechaos bei Datumsangaben zumindest in XML-Dokumenten zu Ende, so dass es keine Verwechslungen mehr zwischen dem 4. März und dem 3. April mehr geben kann. Die Erweiterbarkeit von Schemas bedeutet, dass man seine Schemas in anderen Schemas wiederbenutzen kann, dass man eigene Datentypen von den vorhandenen ableiten kann und dass man aus einem Dokument heraus auf mehrere Schemas verweisen kann. Die Wiederholungsfaktoren für Elemente können bei Schemas genau angegeben werden, nicht nur optional, mindestens einmal oder beliebig oft, sondern auch mindestens 3, maximal 5 ist darstellbar. 3 Validieren von Schemas und Dokumenten Das Schöne an Schemas ist, dass sie selbst XML-Dokumente sind, so dass man sie ebenfalls validieren kann. Gelegentlich gelingt nämlich das Validieren eines Dokumentes deshalb nicht, weil das Schema fehlerhaft ist. Genau diesen Fall kann man durch Validieren des Schemas ausschließen. Am einfachsten validiert man online. Dazu ist z. B. folgende Adresse zu empfehlen: ˆ (im Februar 2006 offline) Vielleicht geht der Validator bald wieder online. Andernfalls kann man auf den Validator des W3C zurückgreifen, aber der bemerkt bei weitem nicht alle Verstöße gegen das Schema. Andererseits kann man natürlich auch selbst einen validierenden XML-Prozessor verwenden, z. B. Xerces 5 aus dem Apache-Projekt. Dies hat beispielsweise Sun gemacht, um ihren Multi-Schema-Validator 6 zu schreiben. Dieser kann neben XML Schemas u. a. auch Relax Schemas verwenden. 4) 5) in Java in C++ 6) 4

5 4 AUFBAU EINES SCHEMAS Im Portal gibt es aber auch einen Java-Quellcode für einen kleinen Schema-Validator XmlTester.java, der ebenfalls den Xerces-Parser einsetzt und daher genauso gute Fehlermeldungen liefert. Bei ihm kann man sich sogar aussuchen, ob man den Namen der Schema-Datei als zusätzlichen Parameter angibt oder den Schema-Verweis aus dem XML- Dokument übernimmt. 4 Aufbau eines Schemas 4.1 Schema-Deklaration Da das Schema ein XML-Dokument ist, beginnt es natürlich wie jedes andere XML-Dokument auch mit der entsprechenden Deklaration. Danach wird das Root-Element mit einem Namespace-Verweis geschrieben: <?xml version="1.0"?> <xsd:schema xmlns:xsd=" xmlns=" elementformdefault="qualified"> <xsd:element name="notiz"> <xsd:sequence> <xsd:element name="von" type="xsd:string"/> <xsd:element name="an" type="xsd:string"/> <xsd:element name="ueberschrift" type="xsd:string"/> <xsd:element name="text" type="xsd:string"/> </xsd:schema> Das Schema beschreibt die obige Beispieldatei. Es wird festgelegt, dass es ein Element namens notiz gibt, das eine komplexen Inhalt hat. Der komplexe Typ ist hier nicht benannt, sondern anonym, d. h. wird sofort definiert. Er besteht aus einer Sequenz 7, d. h. die Reihenfolge der in der Sequenz angegebenen Element ist vorgeschrieben. Alle Elemente müssen genau einmal enthalten sein und bestehen aus einem String. Dieses Schema prüft also nicht strenger als die frühere DTD, weil die Fähigkeiten von Schemas hier nur zu einem sehr geringen Teil ausgenutzt werden. Wir haben das Namensraum-Prefix xsd genommen, weil das sehr häufig benutzt wird. Tatsächlich ist der Name aber vollkommen egal, weil er ohnehin durch den kompletten 7) siehe Abschnitt auf Seite 12 5

6 4.2 Schema-Verweis 4 AUFBAU EINES SCHEMAS URI ersetzt wird (hier: Wir müssen also vor alle Elemente aus XML Schema das Präfix xsd setzen, z. B. auch bei den Datentypen. Man könnte dem schema-element ein Attribut targetnamespace=" hinzufügen, das verlangen würde, dass die Dokumente, die von diesem Schema definiert werden, zum Namensraum gehören müssen. Das Attribut xmlns=" sagt, dass dies der default-namensraum ist, während das Attribut elementformdefault="qualified" angibt, dass alle Elemente im XML-Dokument, die aus diesem Schema stammen, mit Namensraumangabe versehen sein müssen. 4.2 Schema-Verweis Der oben bereits erwähnte Verweis aus einem XML-Dokument auf ein Schema soll nun weiter erläutert werden. <notiz xmlns:xsi=" xsi:nonamespaceschemalocation="notiz.xsd">... </notiz> Durch die Angabe der xsi:nonamespaceschemalocation wird dem Validator ermöglicht, auf das Schema zuzugreifen; (notiz.xsd) ist der Ort, wo das Schema zu finden ist, wobei die Angabe auch einen (absoluten oder relativen Pfad) enthalten kann; in diesem Beispiel liegt die Schemadefinition also im selben Verzeichnis wie das XML-Dokument. Falls ein Namespace mit angegeben werden soll, sieht es so aus: <notiz xmlns=" xmlns:xsi=" xsi:schemalocation=" </notiz> notiz.xsd"> Hier wird also ein default-namensraum festgelegt, während mit xsi auf den Schema-Instanz-Namensraum verwiesen wird. Durch die Angabe der xsi:schemalocation wird dem Validator ermöglicht, auf das Schema zuzugreifen. Die erste Zeichenkette im Attributwert ( ist der zu verwendende Namensraum, die zweite gibt wie oben beschrieben den Ort des Schemas an. Ein validierender XML-Prozessor würde die Schemadefinition selbständig nachladen und zur Prüfung verwenden. 6

7 4 AUFBAU EINES SCHEMAS 4.3 Einfache Elemente 4.3 Einfache Elemente XML-Schemas legen die Elemente der XML-Dokumente fest. Einfache Elemente enthalten nur Text, aber keine weiteren Elemente und keine Attribute. Hierbei ist die Angabe nur Text etwas irreführend, denn es können schon viele verschiedene Datentypen sein (was im Gegensatz zu DTDs auch wirklich unterschieden wird) vordefinierte Datentypen In XML Schemas gibt es viele unterschiedliche Datentypen, so dass die Prüfung des Dokuments wesentlich präziser erfolgen kann als bei den DTDs. Eine Liste aller wichtigen Datentypen finden Sie in der folgenden Tabelle. Tabelle 1: Basistypen in XML-Schemas Typ Beschreibung Beispiele (durch Komma getrennt) Zeichenkettentypen string Zeichenkette Helmut Meier language ISO Kürzel einer Sprache de, eo, tr, ja normalizedstring Zeichenkette, bei der LF, CR und Abstand ist egal TAB durch 1 Leerzeichen ersetzt werden token Zeichenkette, bei der jeder Whitespace Abstand ist egal durch 1 Leerzeichen ersetzt wird und führende und folgende Leerzeichen entfernt werden ID (nur bei Attributen) eindeutige A ID, darf nicht rein numerisch sein IDREF (nur bei Attributen) Referenz auf eine ID A IDREFS (nur bei Attributen) Referenzen A A12443 BAGHOE auf IDs NMTOKEN (nur bei Attributen) Zeichenkette, hallo die ein Token darstellt NMTOKENS (nur bei Attributen) Zeichenkette, die ein oder mehrere Token darstellt hallo eins ganzzahlige numerische Typen integer Ganzzahl , -1, 0, positiveinteger positive Ganzzahl 1, ) 7

8 4.3 Einfache Elemente 4 AUFBAU EINES SCHEMAS Tabelle 1: Basistypen in XML-Schemas Typ Beschreibung Beispiele (durch Komma getrennt) negativeinteger negative Ganzzahl nonnegativeinteger positive Ganzzahl oder 0 0, nonpositiveinteger negative Ganzzahl oder , 0 byte 8-bit-Integer mit Vorzeichen -1, 125 unsignedbyte 8-bit-Integer ohne Vorzeichen 0, 250 short 16-bit-Integer mit Vorzeichen -1, unsignedshort 16-bit-Integer ohne Vorzeichen 1, int 32-bit-Integer mit Vorzeichen , -1, 0, unsignedint 32-bit-Integer ohne Vorzeichen long 64-bit-Integer mit Vorzeichen -1, unsignedlong 64-bit-Integer ohne Vorzeichen 0, nicht-ganzzahlige numerische Typen decimal gebrochene Dezimalzahl -1.23, 123.4, float Fließkommazahl -INF -1E4-1.23, -0, 0, 12.78E-2, 12, INF, NaN double Fließkommazahl -INF -1E4-1.23, -0, 0, 12.78E-2, 12, INF, NaN Datum-/Zeit-Typen time Uhrzeit, ggf. mit Zeitzone 11:20:00.000, 12:20: :00, 14:00Z date Datum (immer ISO8601-Format!) gmonthday Monat und Tag gyear Jahr (bringt aber nichts gegenüber 2000 int) gyearmonth Jahr und Monat datetime Zeitstempel T09:00:00, T03:00:00Z Duration Zeitdauer, muss immer mit P beginnen P2Y5M3DT10H30M12S, PT3.24S sonstige Typen boolean logischer Wert true, false, 1, 0 hexbinary binärer hex-string a6b346e2441e base64binary binärer base64-string 9 agfsbg8k anyuri URI; falls Leerzeichen drin sind, mit %20 codieren portale 9) siehe 8

9 4 AUFBAU EINES SCHEMAS 4.3 Einfache Elemente Ein einfaches Element definiert man so, wenn es Ort heißen und eine Zeichenkette (string) enthalten dürfen soll: <xsd:element name="ort" type="xsd:string"/> Statt xsd:string kann jeder andere Basistyp (oder auch selbst definierter Typ, der auch komplex sein darf) verwendet werden. Über weitere Attribute kann man default-werte oder auch feste Werte angeben: <xsd:element name="land" type="xsd:string" default="schweiz"/> <xsd:element name="versendungsform" type="xsd:string" fixed="paket"/> eigene einfache Datentypen Über die Prüfung auf Zulässigkeit der Werte für einen Datentypen hinaus kann man Restriktionen angeben. Bei DTDs gab es immerhin schon die Möglichkeit, in einer Aufzählung alle erlaubten Werte aufzuführen. Bei XML Schemas geht dies sehr viel weiter, über Minimal- und Maximalwerte und Aufzählungen bis hin zu regulären Ausdrücken, denen der Wert genügen muss. Beispiele hierzu finden Sie in Tabelle 2 auf Seite 12. Hinweis: Attribute kann man für einfache Elemente leider nicht erlauben, dafür muss man ggf. ein komplexes Element mit einfachem Inhalt definieren, siehe Abschnitt 4.5 auf Seite 15. Als Gegensatz zu den Restriktionen gibt es die Erweiterung von erlaubten Werten bei einem einfachen Typ. Das können Listen oder Unions sein. Bei Listen sind mehrere Werte desselben Typs möglich, die im Dokument mit Leerzeichen getrennt werden müssen quasi Arrays. Im Beispiel unten gibt es das beim Element Verpackungseinheiten, das mehrere ganzzahlige Werte enthalten kann, wenn ein Artikel in mehreren Packungsgrößen lieferbar ist. Bei Unions dagegen ist nur ein Wert möglich, der aber nicht genau einem Typ genügen muss, sondern nur einem aus einer Liste von Typen. Man könnte also wahlweise eine ganze Zahl oder einen Datumswert erlauben, wie unten im Beispiel des Elements Zeitpunkt gezeigt. <xsd:element name="verpackungseinheiten"> <xsd:list itemtype="xsd:int"/> <xsd:element name="zeitpunkt"> <xsd:union membertypes="xsd:int xsd:date"/> 9

10 4.4 Komplexe Elemente 4 AUFBAU EINES SCHEMAS 4.4 Komplexe Elemente Alle Elemente, die wiederum selbst Elemente enthalten können, oder aber auch nur Attribute haben, müssen als komplexe Elemente definiert werden. Es gibt vier Arten von komplexen Elementen: ˆ leere Elemente ˆ Elemente, die nur andere Elemente enthalten dürfen ˆ Elemente, die nur Text enthalten dürfen ˆ Elemente mit Text und andere Elemente enthalten dürfen (gemischter Inhalt) Alle diese Elemente können ggf. Attribute enthalten. Zur näheren Beschreibung komplexer Elemente gibt es sogenannte Indikatoren. Diese legen die Reihenfolge der Kindelemente (order indicators), die Häufigkeit (occurrence indicators) und Gruppierungen (group indicators) 10 fest. Tabelle 2: Restriktionen für einfache Datentypen Art Aufzählung erschöpfende Aufzählung aller erlaubten Werte; nebenstehend zwei Varianten. Bei der zweiten Variante wird ein Typ definiert, der auch von anderen Elementen benutzt werden kann; dies gilt genauso auch für alle weiteren Restriktionen. Beschreibung/Beispiele <xsd:element name="automobil"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="audi"/> <xsd:enumeration value="vw"/> <xsd:enumeration value="bmw"/> <xsd:enumeration value="opel"/> <xsd:enumeration value="mercedes"/> <xsd:enumeration value="porsche"/> <xsd:element name="automobil" type="autotyp" /> <xsd:simpletype name="autotyp"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="audi"/> <xsd:enumeration value="vw"/> <xsd:enumeration value="bmw"/> <xsd:enumeration value="opel"/> <xsd:enumeration value="mercedes"/> <xsd:enumeration value="porsche"/> 10) in diesem Dokument nicht beschrieben 10

11 4 AUFBAU EINES SCHEMAS 4.4 Komplexe Elemente Tabelle 2: Restriktionen für einfache Datentypen Art Länge Angabe von exakter, minimaler und/oder maximaler Länge Beschreibung/Beispiele <xsd:element name="kennwort"> <xsd:restriction base="xsd:string"> <xsd:length value="8"/> <!-- exakt 8 Zeichen --> <xsd:element name="passwort"> <xsd:restriction base="xsd:string"> <xsd:minlength value="5"/> <xsd:maxlength value="10"/> Muster Angabe eines regulären Ausdrucks, dem der Inhalt genügen muss <xsd:element name="artikelcode"> <xsd:restriction base="xsd:string"> <xsd:pattern value="[a-z]{2}-[0-9]{3,5}"/> <xsd:element name="isbn"> <xsd:restriction base="xsd:string"> <xsd:pattern value="[-0-9]{13} unbekannt ohne"/> Wertbeschränkung Angabe von Minimal- und/oder Maximalwerten Whitespace Angabe, wie der XML-Prozessor mit Whitespace umgehen soll. Ohne Angabe (oder mit preserve) bleibt Whitespace erhalten; replace ersetzt alle Whitespaces durch ein Leerzeichen, während collapse zusätzlich noch führende und folgende Leerzeichen entfernt. <xsd:element name="laenge"> <xsd:restriction base="xsd:double"> <xsd:mininclusive value="10.0"/> <xsd:maxexclusive value="20.0"/> <xsd:element name="adresse"> <xsd:restriction base="xsd:string"> <xsd:whitespace value="replace"/> <xsd:element name="beschreibung"> <xsd:restriction base="xsd:string"> <xsd:whitespace value="collapse"/> 11

12 4.4 Komplexe Elemente 4 AUFBAU EINES SCHEMAS Tabelle 2: Restriktionen für einfache Datentypen Art Format maximale Anzahl Stellen festlegen; fraction- Digits bestimmt die maximale Anzahl Nachkommastellen, total-digits die Gesamtanzahl der Stellen Beschreibung/Beispiele <xsd:element name="preis"> <xsd:restriction base="xsd:decimal"> <xsd:fractiondigits value="2"/> <xsd:totaldigits value="10"/> Sequenzen Bei einer Sequenz (sequence) müssen die beschriebenen Elemente in genau der Reihenfolge vorkommen. So sieht die Definition eines komplexen Elements aus, das andere Elemente in festgelegter Reihenfolge enthalten darf bzw. muss: <xsd:element name="mitarbeiter"> <xsd:sequence> <xsd:element name="vorname" type="xsd:string"/> <xsd:element name="familienname" type="xsd:string"/> Denselben Typen kann man auch separat definieren und dann mehrfach verwenden: <xsd:element name="mitarbeiter" type="persontyp"/> <xsd:element name="kunde" type="persontyp"/> <xsd:complextype name="persontyp"> <xsd:sequence> <xsd:element name="vorname" type="xsd:string"/> <xsd:element name="familienname" type="xsd:string"/> Jetzt ist der complextype nicht mehr im Element enthalten, sondern steht dahinter, was man auch an der Einrückung erkennen kann. xsd:element ist daher auch ein leeres Element mit dem / vor der schließenden spitzen Klammer. Besonders handlich ist, dass man Typen auch leicht erweitern kann: <xsd:element name="kunde" type="kundetyp"/> <xsd:complextype name="persontyp"> 12

13 4 AUFBAU EINES SCHEMAS 4.4 Komplexe Elemente <xsd:sequence> <xsd:element name="vorname" type="xsd:string"/> <xsd:element name="familienname" type="xsd:string"/> <xsd:complextype name="kundetyp"> <xsd:complexcontent> <xsd:extension base="persontyp"> <xsd:sequence> <xsd:element name="lieferadresse" type="xsd:string"/> <xsd:element name="rechnungsadresse" type="xsd:string"/> </xsd:extension> </xsd:complexcontent> Auswahl Bei einer Auswahl (choice) darf nur eines der genannten Kindelemente vorhanden sein, nicht aber mehrere. <xsd:element name="motor" type="motortyp"/> <xsd:complextype name="motortyp"> <xsd:choice> <xsd:element name="kwleistung" type="xsd:positiveinteger"/> <xsd:element name="psleistung" type="xsd:positiveinteger"/> </xsd:choice> Die Leistung ist also entweder in kw oder in PS anzugeben, nicht aber in beidem (weil man es ineinander umrechnen kann). Die Leistung eines Motors kann man also in einer dieser beiden Formen angeben: <motor> <kwleistung>100</kwleistung> </motor> <motor> <PSLeistung>136</PSLeistung> </motor> Natürlich kann man eine solche Auswahl auch in einer Sequenz (und umgekehrt) verwenden, d. h. da, wo ein <xsd:element> steht, kann auch ein <xsd:choice> oder ein <xsd:sequence> oder das unten erläuterte <xsd:all> vorkommen. 13

14 4.4 Komplexe Elemente 4 AUFBAU EINES SCHEMAS Alle Bei der Verwendung von all müssen alle genannten Kindelemente genau einmal vorkommen, aber die Reihenfolge ist egal dies ist mit DTDs nicht festlegbar. <xsd:element name="person" type="persontyp"/> <xsd:complextype name="persontyp"> <xsd:all> <xsd:element name="vorname" type="xsd:string"/> <xsd:element name="familienname" type="xsd:string"/> </xsd:all> Folgende zwei XML-Elemente würden also obiger Beschreibung genügen: <person> <familienname>meier</familienname><vorname>hugo</vorname> </person> <person> <vorname>erna</vorname><familienname>schmitz</familienname> </person> Durch Hinzufügen von minoccurs="0" kann man Elemente wahlfrei machen. maxoccurs darf aber nur mit dem Wert 1 verwendet werden (was ohnehin default ist) Häufigkeit Mit Häufigkeitsindikatoren (occurrence indicators) wird festgelegt, wie oft ein Element vorkommen darf. Im Gegensatz zu DTDs sind beliebige Anzahlen als Unter- und Obergrenze festlegbar. minoccurs="anzahl" bestimmt, wie oft ein Element mindestens vorkommen muss; ein Wert von 0 bedeutet, dass es optional ist. maxoccurs="anzahl" sagt aus, wie oft ein Element maximal vorkommen darf. Soll die Anzahl nicht beschränkt sein, so trägt man die Zeichenkette unbounded ein. Die Attribute minoccurs und maxoccurs können auch bei <xsd:sequence>-, <xsd:all>- oder <xsd:choice>-elementen verwendet werden, wenn sich die ganze Gruppe wiederholen kann. Hier würde festgelegt, dass zu einem Familiennamen mindestens ein und maximal zehn Kindnamen gehören. <xsd:element name="person"> <xsd:sequence> <xsd:element name="familienname" type="xsd:string"/> <xsd:element name="kindname" type="xsd:string" maxoccurs="10"/> 14

15 4 AUFBAU EINES SCHEMAS 4.5 Attribute gemischter Inhalt Soll im komplexen Typ neben den enthaltenen Elementen (und ggf. den Attributen) auch Textinhalt vor, zwischen und nach den Elementen erlaubt sein, so muss man den komplexen Typen als mixed kennzeichnen: <xsd:element name="bericht" type="berichttyp"/> <xsd:complextype name="berichttyp" mixed="true"> <xsd:sequence> <xsd:element name="fett" type="xsd:string" maxoccurs="unbounded"/> Hier wird ein Element namens bericht vom Typ berichttyp beschrieben, das Text enthält und darüber hinaus beliebig viele Kindelemente namens fett vom Typ string. Es handelt sich also um einen solchen Text: <bericht> In diesem <fett>bericht</fett> sind Teile des Textes zwischendrin <fett>auch mal fett</fett> gedruckt. Es ist also eigentlich ein Text mit ein paar <fett>auszeichnungen</fett>. </bericht> 4.5 Attribute Attribute erlauben Um einem Element Attribute zu erlauben, muss es in jedem Fall als komplexer Typ definiert werden, auch wenn es nur einfachen oder sogar gar keinen Inhalt hat. <xsd:element name="produkt"> <xsd:attribute name="id" type="xsd:positiveinteger"/> Produkt ist als komplexer Typ definiert, aber es sind keine Kindelemente erwähnt, also auch nicht zugelassen. Es handelt sich also um ein leeres Element, das nur ein Attribut namens id haben kann, dessen Wert eine positive Ganzzahl ist. Falls das Element nicht leer ist und nur einfachen Inhalt enthält, so wird festgelegt, dass der Inhalt einfach ist, auf einem bestimmten Basistypen fußt und darüber hinaus ein Attribut hat. Basistypen können mittels extension erweitert werden (hier um ein Attribut), oder aber mittels restriction eingeschränkt werden (siehe Abschnitt auf Seite 9). 15

16 4.5 Attribute 4 AUFBAU EINES SCHEMAS <xsd:element name="produkt"> <xsd:simplecontent> <xsd:extension base="xsd:string"> <xsd:attribute name="id" type="xsd:positiveinteger"/> </xsd:extension> </xsd:simplecontent> Wenn neben dem Attribut die Elemente beschreibung und preis enthalten sind (in dieser Reihenfolge enthalten sein müssen), so wird eine Sequenz vor der Attribut-Definition eingetragen: <xsd:element name="produkt"> <xsd:sequence> <xsd:element name="beschreibung" type="xsd:string"/> <xsd:element name="preis" type="xsd:decimal"/> <xsd:attribute name="id" type="xsd:positiveinteger"/> Datentyp von Attributen Da Attribute keinerlei Unterstruktur enthalten dürfen, sondern nur einfachen Text, sind sie oft vom Typ xsd:string, aber auch jeder andere einfache Datentyp ist erlaubt im obigen Beispiel kommt auch xsd:positiveinteger vor. Über die fest eingebauten einfachen Datentypen hinaus sind auch die für Elementinhaltstypen beschriebenen Einschränkungen bezüglich des Wertebereiches mit Ober- und Untergrenzen, Aufzählung der erlaubten Werte oder durch reguläre Ausdrücke usw. sind alle möglich siehe Abschnitt auf Seite 9 und Tabelle 2 auf Seite 12. Im folgenden Beispiel wird für das Attribut id eine Zeichenkette mit ein oder zwei Großbuchstaben und 4 Ziffern gefordert. <xsd:element name="produkt"> <xsd:attribute name="id"> <xsd:restriction base="xsd:string"> <xsd:pattern value="[a-z]{1,2}[0-9]{4}"/> 16

17 4 AUFBAU EINES SCHEMAS 4.5 Attribute Pflichtattribute Um das Attribut zu einem Pflichtattribut zu machen, muss man noch eine use-klausel hinzufügen: <xsd:element name="produkt"> <xsd:attribute name="id" type="xsd:positiveinteger" use="required"> Bei wahlfreien Attributen kann man auch use="optional" schreiben, aber das ist ohnehin der default-wert Eindeutige und verweisende Attribute Bereits in DTDs gab es eindeutige und verweisende Attribute (ID und IDREF), diese kann man übergangsweise auch in Schemas ähnlich verwenden. Das soll in diesem Dokument wegen der nach wie vor bestehenden Einschränkungen (Schlüssel dürfen nicht rein numerisch sein) aber nicht weiter erläutert werden. Für Schemas gibt es eine neue Art, eindeutige und verweisende Attribute festzulegen. Dies ist gegenüber der im vorigen Abschnitt vorgestellten DTD-Art zu bevorzugen. Über die klarere Syntax hinaus ist auch mehr an Funktionalität enthalten, denn es kann festgeschrieben werden, auf welches Attribut Bezug genommen wird. Um festzulegen, dass ein Attribut eindeutig sein muss, verwendet man ein <xsd:key>- Element. Dieses hat ein Attribut name, dessen Inhalt den Schlüssel identifiziert was aber erst bei verweisenden Attributen tatsächlich verwendet wird, aber die Syntax schreibt es vor. Inhalt des <xsd:key>-elements sind zwei leere Elemente <xsd:selector> und <xsd:field>. Das erste enthält einen Pfad zum Element, das das eindeutige Attribut hat, das zweite ist die Bezeichnung des eindeutigen Attributs selbst. Fügt man die beiden zusammen, so enthält man einen XPath-Pfad zum eindeutigen Attribut relativ zum Element, in dem die Angabe steht. Hier ein Beispielschema namens key.xsd: <xsd:schema xmlns:xsd=" > <xsd:element name="wurzel"> <xsd:sequence minoccurs="1" maxoccurs="1"> <xsd:element name="aaa" type="myaaa"> 17

18 4.5 Attribute 4 AUFBAU EINES SCHEMAS <xsd:key name="keyid"> <xsd:selector xpath="./a"/> <xsd:field xpath="@artnr"/> </xsd:key> <xsd:complextype name="myaaa"> <xsd:sequence minoccurs="1"> <xsd:element name="a" minoccurs="1" maxoccurs="unbounded"> <xsd:attribute name="artnr" type="xsd:positiveinteger" use="required"/> </xsd:schema> und ein passendes Dokument key.xml: <wurzel xsi:nonamespaceschemalocation="key.xsd" xmlns:xsi=" > <AAA> <a artnr="12"/> <a artnr="13"/> </AAA> </wurzel> Wie man sieht, dürfen hier die eindeutigen Attribute auch rein numerisch sein was bei DTDs nicht erlaubt war. Hinweis: Bitte unbedingt mit Hilfe von nicht eindeutigen Werten testen, ob die Überprüfung auf Eindeutigkeit wirklich stattfindet. Hat man sich beim xpath-attribut von <xsd:selector> verschrieben, so wird das Attribut nicht gefunden und damit auch ohne Warnung gar nicht auf Eindeutigkeit geprüft. So könnten Dokumente trotz nicht eindeutiger Werte leicht eine Gültigkeitsprüfung überstehen. Um auf ein eindeutiges Attribut zu verweisen als Fremdschlüssel auf einen Primärschlüssel benötigt man noch zusätzlich zu einem <xsd:key>- ein <xsd:keyref>-element. Dieses enthält dieselben Elemente wie <xsd:key>, aber zusätzlich ein Attribut refer, dessen Inhalt den Namen des Keys trägt. Als Schema sieht keyref.xsd das dann so aus: <xsd:schema xmlns:xsd=" > 18

19 4 AUFBAU EINES SCHEMAS 4.5 Attribute <xsd:element name="wurzel"> <xsd:sequence minoccurs="1" maxoccurs="1"> <xsd:element name="aaa" type="myaaa"/> <xsd:element name="bbb" type="mybbb"/> <xsd:key name="keyid"> <xsd:selector xpath="./aaa/a"/> <xsd:field </xsd:key> <xsd:keyref name="keyidref" refer="keyid"> <xsd:selector xpath="./bbb/b"/> <xsd:field </xsd:keyref> <xsd:complextype name="myaaa"> <xsd:sequence minoccurs="1"> <xsd:element name="a" minoccurs="1" maxoccurs="unbounded"> <xsd:attribute name="artnr" type="xsd:string" use="required"/> <xsd:complextype name="mybbb"> <xsd:sequence minoccurs="1"> <xsd:element name="b" minoccurs="1" maxoccurs="unbounded"> <xsd:attribute name="artnrref" type="xsd:string" use="required"/> </xsd:schema> Dies wäre ein passendes Dokument keyref.xml: <wurzel xsi:nonamespaceschemalocation="keyref.xsd" xmlns:xsi=" 19

20 4.6 Spezialfälle 4 AUFBAU EINES SCHEMAS <AAA> <a artnr="x"/> <a artnr="y"/> </AAA> <BBB> <b artnrref="x"/> <b artnrref="y"/> <b artnrref="y"/> </BBB> </wurzel> Zur Abwechslung sind die Schlüsselwerte hier einmal als Zeichenketten festgelegt Attribute mit festem Wert Soll ein Attributwert fest sein, so schreibt man in die Attributdefinition zusätzlich fixed= "festerwert" hinein. Diesen Wert hat das Attribut dann immer egal, ob es im Dokument angegeben wurde oder nicht. Falls es im Dokument einen anderen Wert hat, so entspricht das Dokument nicht mehr dem Schema. 4.6 Spezialfälle Es gibt noch viele weitere Möglichkeiten von Schemas, z. B. das Zerlegen in mehrere Unter- Schemas, die man später zusammenführen und Ähnliches. Diese Besonderheiten werden in dem vorliegenden Dokument nicht erläutert. Immerhin gibt es Bücher über Schemas mit einem Umfang von mehr als 500 Seiten, so dass das Thema hier nicht erschöpfend behandelt werden kann. 4.7 Online-Referenz Eine Online-Referenz zu Schemas findet man unter $Id: XML-Schema.tex,v a5120cdeb /11/06 11:45:29 bibjah $ 20