1. 1. Modellierung mit DTD

Transkript

1 XML-Technologien

2 1 Dieses Buch kann und möchte kein Buch für XML-Einsteiger sein. Dennoch soll durch das Buch alleine die Möglichkeit angeboten werden, sich gleichzeitig mit Oracle und seinen XML-Techniken zu beschäftigen wie auch das grundlegende Wissen zu den in Oracle verwendeten XML-Technologien zu finden. In Seminaren gibt es oft Teilnehmer, die gar nicht ahnen, auf welche Fülle an Technologien sie sich einlassen (sollen) und die ebenfalls neben der Verwendung dieser Technologien in Oracle und den zusätzlichen Werkzeugen, die bspw. noch in PL/SQL-Paketen oder der Oracle XML-Datenbank untergebracht sind, sich auch noch mit den verschiedenen XML-Technologien an sich beschäftigen sollen. In diesem Kapitel befinden sich daher in Form von übersichtlichen Abschnitten, die möglichst kurz gehalten sind, Darstellungen der W3C-Standards zur Modellierung, Abfrage und Transformation. In einem späteren Kapitel zur Erstellung von Webservices gibt es einen ähnlichen Kurzeinstieg in dieses spezielle Thema, das ebenfalls eine Technologie für die Beschreibung von Webdiensten und eine andere für den Nachrichtenversand bzw. die Nachrichtenstrukturierung besitzt. In der Modellierung mit DTD befinden sich die Themen dieses Kapitels grau unterlegt, während andere Themen, die rein Oracle-spezifisch sind oder nur im direkten Zusammenhang mit der Beispieldatenbank dargestellt werden können, sind ohne besondere Füllfarbe. Man findet auch ein Kästchen mit Farbe, das allerdings in Oracle keine Bedeutung mehr besitzt und nur aus Gründen der Vollständigkeit und des klassischen und bewährten Einstiegs in XML noch aufgeführt und auch mit einigen Beispielen in diesem Kapitel versehen ist. Es handelt sich dabei um die Document Type Definition (DTD), die mehr Platz in der offiziellen XML-Spezifikation einnimmt als die Darstellung von XML selbst. Sie stellt eine Möglichkeit dar, XML-Dokumente zu beschreiben und zu strukturieren, was allerdings in technischer Hinsicht besser durch XML Schema durchgeführt wird. XML Schema ist auch die in Oracle eingesetzte Technik, um Datenvalidierung und beschreibung durchzuführen. 27

3 1 Abbildung 1.1: XML-Technologien Modellierung mit DTD Die Document Type Definition wird im Dokument Extensible Markup Language (XML) W3C Recommendation 04 February 2004 unter TR/2004/REC-xml / festgelegt, welches gleichfalls auch die Spezifikation von XML überhaupt ist. Dieses nicht in XML-Struktur geschriebene Dokument legt die Regeln des XML-Formats fest: Benennung, Häufigkeit und Reihenfolge von Elementen, Benennung und Verwendung/Auftreten von Attributen sowie weitere Regeln wie Textinhalte, Schlüssel und Schlüsselverweise Elemente, Attribute Die wichtigsten Regelungen und damit auch die wesentliche Struktur und Syntax, die man von einer Modellierungstechnik kennen muss, stellt die Benennung von Elementen und Attributen, die Zuordnung von Attributen zu Elementen sowie die 28

4 1 jeweiligen zulässigen Inhalte dar. Im nachfolgenden Dokument wurde eine Dozentenliste aus der Datenbank mit Hilfe einer entsprechenden SQL-Abfrage als XML- Struktur extrahiert. Die Fettung zeigt die Verknüpfung zu einer DTD an, wobei das Wurzelelement der zu validierenden Datei ebenfalls angegeben ist. Da dies in der DTD-Struktur nicht mit einem speziellen Element geschieht, ist diese Angabe beim Aufruf dem Prozessor mitzuteilen. Innerhalb des Wurzelelements Dozentenliste befinden sich mehrere Dozent- Elemente, die wiederum ein Attribut Nr sowie zwei Kinder namens Name und Adresse besitzen. Name enthält wiederum ein Attribut Anrede und die beiden Kindelemente Vorname und Nachname mit Textknoten. Adresse dagegen nur Kindelemente mit den verschiedenen Adressbestandteilen. <?xml version= 1.0 encoding= ISO ?> <!DOCTYPE Dozentenliste SYSTEM 111 _ 01.dtd > <Dozentenliste> <Dozent Nr= 1 > <Name Anrede= Frau > <Vorname>Birte</Vorname> <Nachname>Sonnenschein</Nachname> </Name> <Adresse> <Straße>Charlottenhofstr.</Straße> <Hausnr>29</Hausnr> <PLZ>45219</PLZ> <Stadt>Essen, Ruhr</Stadt> <Stadtteil>Kettwig</Stadtteil> <Telnr> </Telnr> </Adresse> </Dozent> _01.xml: Dozentenliste mit mehreren Dozenten (Name und Adresse) Die DTD ist inabbildung 1.2: DTD für die Dozentenlisteg 1.2 angegeben und mit einigen grafischen Hilfen versehen worden. Zwar befindet sich ein XML-Prolog am Anfang des Dokuments, doch ist das DTD-Format kein wohlgeformtes XML, sondern sieht nur auf den ersten Blick nach XML aus. Die einzelnen Elemente werden über die Angabe <!ELEMENT name (inhalt)> angegeben, während die Attri- 29

5 1 bute außerhalb von ihrem Element stehen und innerhalb der Angabe <!ATTLIST elementname {attribut inhalt verwendung }> aufgezählt sind. Abbildung 1.2: DTD für die DozentenlisteDie Häufigkeit von Elementen wird über Zeichen, welche dem Elementnamen im Inhaltsmodell folgen, bzw. zwischen den runden Klammern, die dem Elementnamen in <!ELEMENT> folgen, angegeben. Sofern gar kein Zeichen zu finden ist, wie dies für die meisten Kindelemente in der Dozentenliste der Fall ist, treten sie genau einmal auf.dung 1.3 ist die XML-Dokumentstruktur zum Vergleich neben der DTD-Struktur gesetzt worden. Grundsätzlich ist die Reihenfolge der <!ELEMENT> und <!ATTLIST>-Elemente unwesentlich, doch wenn man die Reihenfolge ihres Auftretens in XML auch in der DTD abbildet und dann wenigstens einen Pfad herausgreift, dann stellt man fest, dass die einzelnen Inhaltsmodelle und die in ihnen enthaltenen Kind-Elementaufrufe sowie die dazu passenden Elementdeklarationen einen Baum abbilden. Dieser endet entweder mit einem Textknoten (#PCDATA), einem leeren Element (#EMPTY) oder auch der freien Wahl von beliebigen Elementen (#ANY). Während der letzte Fall natürlich nicht im XML-Baum zu einem Blatt führt, bilden leere Elemente sowie solche mit Textknoten Blätter im XML-Baum aus. Das bedeutet, dass dies die äußerste Struktur des Baums ist und der Ast dort endet. Im angegeben Fall ist dies genau für die Elemente Vorname und Nachname der Fall. 30

6 1 Abbildung 1.3: Dokumentstruktur einer DTD Die Häufigkeit von Elementen wird über Zeichen, welche dem Elementnamen im Inhaltsmodell folgen, bzw. zwischen den runden Klammern, die dem Elementnamen in <!ELEMENT> folgen, angegeben. Sofern gar kein Zeichen zu finden ist, wie dies für die meisten Kindelemente in der Dozentenliste der Fall ist, treten sie genau einmal auf. Zeichen Formel Beschreibung + 1..n Element tritt einmal oder beliebig oft auf.? 0..1 Element tritt keinmal oder genau einmal auf (optionales Element). * 0..n Element tritt beliebig häufig oder keinmal auf. Häufigkeit von Elementen Das Inhaltsmodell der Elemente lässt sich durch einen der folgenden Fälle beschreiben. Inhalt Ein oder mehrere Namen von Elementen #PCDATA #EMPTY #ANY Beschreibung Das Element enthält diese Kind-Elemente mit den angegebenen Häufigkeiten in der angegeben Reihenfolge. Textknoten ohne Datentypangabe Leeres Element wie <Telnr/> Beliebiger Inhalt. Inhaltsmodell von Elementen 31

7 1 Das Inhaltsmodell von Attributen lässt sich durch mehr standardisierte Schlüsselwörter beschreiben. Schlüsselwort / Inhalt wert #IMPLIED #REQUIRED #FIXED wert Beschreibung Vorgabe des Wertes, der bei fehlendem Wert in XML- Dokument zum Einsatz kommt. Keine Vorgabe und kein Wert erforderlich. Keine Vorgabe, aber ein Wert in XML ist erforderlich. Feste Wertvorgabe, die immer zum Einsatz kommt. Wertvorgaben bei Attributen Zusätzlich gibt es eine Reihe von Datentypen. Sie entsprechen nicht den gängigen Datentypen von Programmiersprachen oder XML Schema, sondern haben eher besondere Funktionalitäten als inhaltliche Einschränkungen. Typ CDATA ENTITY ENTITIES Wertliste ID IDREF IDREFS NMTOKEN NMTOKENS NOTATION Beschreibung Textinhalt ohne besondere Eigenschaften oder Einschränkungen. Entität aus der DTD. Durch ein Leerzeichen getrennte Liste von Entitäten. Abgeschlossene Token-Wertemenge in runden Klammern, aus der der Attributwert stammen muss. Gültiger XML-Name, der als Schlüssel fungiert (Primärschlüssel). Schlüsselverweis auf einen gültigen XML-Namen, der als ID-Typ in einem Attribut gespeichert ist (Fremdschlüssel). Durch ein Leerzeichen getrennte Reihe von Schlüsselverweisen (mehrere Fremdschlüssel). Leerzeichenlose Zeichenkette aus Zahlen oder Buchstaben, die in gültigen XML-Namen auftreten können. Durch ein Leerzeichen getrennte Liste, die aus NMTOKENs besteht. Notationsverweis wie z.b. Name einer Datei. Attributdatentypen und ihre Bedeutung 32

8 Komplexe Inhaltsmodelle Neben dem gerade gelösten Beispiel zur Modellierung, in dem im Wesentlichen die Reihenfolge von Elementen die XML-Struktur beschrieb, lassen sich viele andere Varianten denken. Sofern die Daten wie in diesen Beispielen aus (relationalen) Datenbanken stammen, hat man mehr solche Beispiele wie die zuvor beschriebenen auf dem Bildschirm, doch sobald man weniger datenorientierte, sondern mehr dokumentenorientierte Strukturen bearbeitet, stellt man fest, dass der Datenaufbau wesentlich komplexer sein kann und mehr Syntax erfordert als nur die Angabe von Reihenfolge und Häufigkeit. Die nachfolgende Variation der Dozentenliste fußt auf unrealistischen Annahmen, weil sie nicht mit dem zu Grunde liegenden Datenmodell in der Datenbank übereinstimmt. Sie soll allerdings ausschließlich für die Darstellung weiterer Möglichkeiten dienen, Inhaltsmodelle anzugeben. Wie man leicht erkennt, ist im Namen das Element Titel offensichtlich optional, während im Element Adresse alle Elemente außer Telnr optional sind. <Dozentenliste> <Dozent Nr= 2 > <Name Anrede= Frau > <Vorname>Susanne</Vorname> <Nachname>Rollstein</Nachname> </Name> <Adresse> <Straße>Elsenpaß</Straße> <Hausnr>26</Hausnr> <PLZ>46395</PLZ> <Stadt>Bocholt</Stadt> <Stadtteil>Lowick</Stadtteil> <Telnr> </Telnr> </Adresse> </Dozent> <Dozent Nr= 20 > <Name Anrede= Herr > <Titel>Dipl.-Ök.</Titel> <Vorname>Anton</Vorname> <Nachname>Ebenhof</Nachname> </Name> 33

9 1 <Adresse> <Telnr> </Telnr> </Adresse> </Dozent> </Dozentenliste> 112_01.xml: Variation der Dozentenliste mit optionalen Elementen Nun lassen sich verschiedene Möglichkeiten denken, diese Struktur zu beschreiben. In einer ersten Lösung sind die fehlenden Elemente tatsächlich einfach optional, sodass ein Fragezeichen nach ihrer Nennung im Inhaltsmodell des Elternelements gesetzt werden muss. Auf die wesentlichen Zeilen verkürzt sieht die vorherige DTD dann folgendermaßen aus: <!ELEMENT Dozentenliste (Dozent+)> <!ELEMENT Dozent (Name, Adresse)> <!ELEMENT Name (Titel?, Vorname, Nachname)> <!ELEMENT Adresse (Straße?, Hausnr?, PLZ?, Stadt?, Stadtteil?, Telnr)> 112_01.dtd: Lösung mit optionalen Elementen Es ließe sich allerdings auch eine zweite Lösung denken, in der die oben beschriebenen Varianten nicht zufällig durch fehlende Daten aufgetreten sind, sondern tatsächlich gewollt sind. Nebenbei bemerkt ist ohnehin die Darstellung von fehlenden (NULL) Daten über fehlende Elemente nicht die schönste Lösung, da man nicht erkennen kann, dass theoretisch das fehlende Feld auch hätte vorhanden sein können. Die Verwendung von leeren Elementen wie <Stadt/> oder <Stadt></ Stadt> mit dem Hinweis, die erste Schreibweise zu verwenden, weil auch kein leerer Textknoten vorhanden ist, wäre dem anderen Vorgehen vorzuziehen. Die gerade erwähnte Gruppierung wird also über runde Klammern eingerichtet während die verschiedenen, sich gegenseitig ausschließenden Alternativen über einen senkrechten Strich angegeben werden können. Diese Lösung drückt also aus, dass genau diese Kombinationen von Elementen möglich sind. 1. Entweder ist eine vollständige Adressenauflistung notwendig oder nur eine Telefonnummer. 2. Entweder ist eine Namensnennung komplett mit akademischen Grad oder ohne möglich. 34

10 1 <!ELEMENT Dozentenliste (Dozent+)> <!ELEMENT Dozent (Name, Adresse)> <!ELEMENT Name ((Titel, Vorname, Nachname) (Vorname, Nachname))> <!ELEMENT Adresse ((Straße, Hausnr, PLZ, Stadt, Stadtteil, Telnr) Telnr)> 112_02.dtd: Lösung mit gruppierten Elementen Eine weitere Variante besteht darin, eine ganze Gruppe mit einer Häufigkeitsangabe zu versehen. In diesem Fall ist dies die Gruppe, welche die Adressfelder ohne Telefonnummer umschließt. Hier lautet die modellierte Regel: Eine Adresse besteht entweder aus den gruppierten Adressfeldern und zusätzlich der Telefonnummer oder ausschließlich der Telefonnummer. <!ELEMENT Adresse ((Straße, Hausnr, PLZ, Stadt, Stadtteil)?, Telnr)> 112_03.dtd: Lösung mit optionaler Gruppe Schließlich lässt sich auch noch eine weitere Regel denken: Wenn im Element Name das Element Titel auftritt, dann darf in der Adresse nur das Element Telnr auftreten. Diese Regel berücksichtigt Ko-Abhängigkeiten zwischen Daten, was sich noch auf Textinhalte und/oder Attribute beziehen kann. Eine beispielhafte Regel wäre: Wenn Attribut Typ den Wert x hat, dann treten andere Kinder auf als beim Wert y. Solche Strukturen lassen sich mit der Syntax der DTD nicht ausdrücken; das gleiche gilt für XML Schema. Bisweilen gibt es syntaktische Möglichkeiten, abgeschwächte Regeln abzubilden, doch generell sind dies nicht die Einsatzbereiche von DTD oder XML Schema. Es gibt noch weitere Schema- Sprachen wie bspw. Relax NG, die schwachbrüstig in anderen Bereichen sind wie bspw. Datentypen oder Schlüssel/-verweise, aber genau solche Strukturen hervorragend abzubilden wissen Schlüssel- und Schlüsselverweise Die DTD bietet verschiedene Datentypen für die Modellierung von Schlüsseln und Verweisen an, was insbesondere bei Datenbankdaten ein häufiger Anwendungsfall ist. Sie gelten nur für Attribute und haben verschiedene Einschränkungen. 35

11 1 ID: Schlüsselwert für ein Attribut IDREF: Verweis auf einen existierenden Schlüssel für ein Attribut IDREFS: Liste von Schlüsseln als Tokenliste für ein Attribut Trotz der einfachen Verwendung gelten verschiedene Einschränkungen, die meistens mit den DB-Primär- und Fremdschlüsseln nicht korrespondieren und daher Anpassungen beim Datenexport und import erforderlich machen. Der Wert eines Schlüssels muss in der lexikalischen Dimension einem unqualifizierten XML-Namen entsprechen. Dies bedeutet, dass keine Leerzeichen zulässig sind und die Werte nicht mit einer Zahl beginnen können. Damit sind sofort alle Schlüssel, die nur aus Zahlen bestehen, für dieses Format nicht geeignet, da sie ein irgendwie geartetes Präfix in Form mindestens eines Anfangsbuchstabens benötigen. Zudem können keine Schlüssel verwendet werden, die Leerzeichen beinhalten und sich z.b. syntaktisch aus mehreren Einheiten, wie bspw. ein ISBN-Wert, zusammensetzen. Der Schlüsselwert muss innerhalb des Dokuments völlig einzigartig sein. Es darf also nicht noch einmal der gleiche Wert als Schlüssel auftauchen. Dies gilt für alle Elemente, und zwar auch dann, wenn für verschiedene gerade nicht gleiche Elemente (Kunde, Produkt etc.) die gleiche Nummer verwendet würde und sich dieser Wert nur zufällig als gleich herausstellt. Dies kann insbesondere bei reinen Zahlen geschehen, wobei hier schon durch einen vorgestellten Buchstaben für die erste Einschränkung ein Duplikat vermieden werden kann. Diese Buchstaben dienen also dazu, solche gleichwertigen, aber nicht gleichen Elemente voneinander zu unterscheiden. Im nachfolgenden Beispiel liegt eine Buchungsliste vor, in der die Anmeldungen und Teilnehmer jeweils einen Schlüsselwert besitzen. Dabei bezieht sich das Attribut Nr im Anmelder-Element auf das Attribut Nr im Teilnehmer-Element. Die Beziehung drückt aus, dass der Anmelderteilnehmer diesen Teilnehmer angemeldet hat und über diesen Wert sowie die Terminnummer die Kleingruppe erkannt werden kann, um den Rabattpreis zu ermitteln. <Buchungsliste> <Anmeldung Nr= A1438 > <Termin Nr= 338 /> 36

12 1 <Preis>198</Preis> <Anmelder Nr= TN231 /> <Teilnehmer Nr= TN231 > <Name Anrede= Herr > <Vorname>Wolfgang</Vorname> <Nachname>Senff</Nachname> </Name> </Teilnehmer> </Anmeldung> <Anmeldung Nr= A1439 > <Termin Nr= 338 /> <Preis>198</Preis> <Anmelder Nr= TN231 /> <Teilnehmer Nr= TN338 > <Name Anrede= Frau > <Vorname>Sieglinde</Vorname> <Nachname>Voßwinkel</Nachname> </Name> </Teilnehmer> </Anmeldung> 113_01.xml: Verwendung von Schlüsseln und Verweisen In der DTD wirkt sich diese Regel so aus, dass die Schlüsselattribute mit dem ID- Datentyp ausgestattet werden, während die Fremdschlüsselattribute vom IDREF- Datentyp beschrieben werden. <!ELEMENT Buchungsliste (Anmeldung+)> <!ELEMENT Anmeldung (Termin, Preis, Anmelder, Teilnehmer)> <!ATTLIST Anmeldung Nr ID #REQUIRED > <!ELEMENT Preis (#PCDATA)> <!ELEMENT Anmelder EMPTY> <!ATTLIST Anmelder Nr IDREF #REQUIRED > <!ELEMENT Teilnehmer (Name)> <!ATTLIST Teilnehmer 37

13 1 > Nr ID #REQUIRED 113_01.dtd: Schlüssel und Schlüsselverweise Abbildung 1.4: Schlüssel und Schlüsselverweise In der Abbildung 1.4 sind beide Dateien noch einmal nebeneinander dargestellt. Dabei kann man über die Pfeile erkennen, welche Attribute in der XML- und DTD- Darstellung sich referenzieren und welche damit als Primär- und Fremdschlüssel in Betracht kommen Modellierung mit XML Schema Das W3C XML Schema so der vollständige Name stellt eine W3C-Weiterführung der DTD dar. Die DTD wird weiterhin in vielen Anwendungen verwendet. Insbesondere im Druck-/Verlagsbereich ist sie weiterhin häufig anzutreffen. Das XML Schema sollte bei neuen Anwendungen verwendet werden, in denen auf seine Vorteile wie Datentypvalidierung/-erstellung sowie die sehr umfangreichen Möglichkeiten der Ableitung von einfachen und komplexen (aus mehreren Elementen zusammen gesetzten) Datentypen, Wert gelegt wird. Insbesondere die Datentypen stellen einen wichtigen Pfeiler von XML Schema dar und sind in einem eige- 38

14 1 nen Standard spezifiziert, da sie auch in anderen XML-Technologien Verwendung finden. Folgende Ressourcen sind beim W3C verfügbar: Einstiegsseite des W3C: Einführung: Strukturen: Datentypen: Im Gegensatz zur DTD ist das XML Schema überaus umfangreich und bietet vor allen Dingen eine XML-Struktur an. Diese bietet alternative Ausdrucksmöglichkeiten für gleiche Regeln oder wenigstens gleiche Strukturen in den beschriebenen XML-Dateien. Während die DTD in Oracle hauptsächlich im Rahmen der Validierung von abgerufenen oder zu bearbeitenden Daten genutzt wird, kommt dem XML Schema, wie noch zu sehen sein wird, eine ungleich größere Bedeutung zu. Es dient nämlich in vielfältiger Weise der Konfiguration der XML-Datenbank, dem automatischen Einrichten von geeigneten Datenstrukturen für vereinfachte Abfragen sowie der Validierung von XML-Konfigurationsdateien. Einen Überblick über die Namen der Elemente, die teilweise auch bereits ihre Funktion verraten, findet sich in nachfolgender Tabelle. A-D E-N O-Z all annotation any anyattribute appinfo attribute attributegroup choice complexcontent complextype documentation element extension (simplecontent) extension (complexcontent) field group import include key keyref list notation redefine restriction (simpletype) restriction (simplecontent) restriction (complexcontent) schema selector sequence simplecontent simpletype union unique XML Schema-Elemente 39

15 Globale/Lokale Elemente und Attribute Wie auch zuvor bei der DTD sollen zunächst die grundlegenden Techniken vorgestellt werden, was auch hier bedeutet, Elemente und Attribute mit ihren Eigenschaften wie Name und Inhalt und bei Elementen auch Reihenfolge und Häufigkeit vorzugeben. Für das XML Schema gibt es verschiedene Werkzeuge, die eine grafische Oberfläche für die vereinfachte Erstellung von XML Schema-Dateien bieten und teilweise sogar wie Altova XMLSpy auch Oracle-Erweiterungen bieten. Größter Konkurrent ist hier StylusStudio. Kostenlose Testversionen sind jeweils verfügbar und sollen im Rahmen dieses Buches nicht ausdrücklich vorgestellt werden, da wie in vielen Bereichen IDE-Einsatz auch Glaubenskrieg bedeutet. Eine solche grafische Darstellung zeigt die Abbildung 1.5, die anstelle eines erneuten Abdrucks der Dozentenliste noch einmal einen schnellen Überblick über die Datei geben soll. Abbildung 1.5: Struktur der Dozentenliste Wie schon erwähnt, ist das XML Schema eine XML-Datei und kann daher auch mit XML-Techniken erstellt, bearbeitet, abgefragt und in andere Formate umgewan- 40

16 1 delt werden. Der nachfolgende Quelltext zeigt die zur ersten DTD analoge Form, die Babuschka-Design heißt, weil sich auch hier die Verschachtelung der XML-Daten im Modell widerspiegelt. XML Schema bietet noch andere Möglichkeiten der Auslagerung und Wiederverwendung durch Ableitung und Datentyperstellung, die DTD in dieser Form nicht anbietet. <?xml version= 1.0 encoding= UTF-8?> <xs:schema xmlns:xs= elementformdefault= qualified attributeformdefault= unqualified > <xs:element name= Dozentenliste > <xs:complextype> <xs:sequence> <xs:element name= Dozent maxoccurs= unbounded > <xs:complextype> <xs:sequence> <xs:element name= Name > <xs:complextype> <xs:sequence> <xs:element name= Vorname type= xs:string /> <xs:element name= Nachname type= xs:string /> </xs:sequence> <xs:attribute name= Anrede type= xs:string use= required /> </xs:complextype> </xs:element> <xs:element name= Adresse > <xs:complextype> <xs:sequence> <xs:element name= Straße type= xs:string /> <xs:element name= Hausnr type= xs:string /> <xs:element name= PLZ type= xs:string /> <xs:element name= Stadt 41

17 1 type= xs:string /> <xs:element name= Stadtteil type= xs:string /> <xs:element name= Telnr type= xs:string /> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name= Nr type= xs:string use= required /> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> 121_01.xsd: Schema für die Dozentenliste im Babuschka-Design Ein Element lässt sich mit dem Element element festlegen, wobei die Attributliste auf die für den Einsteiger wesentlichen Elemente gekürzt wurde. Der Name wird im name-attribut angegeben, das einen gültigen XML-Namen ohne Namensraumpräfix erwartet. Die Häufigkeit lässt sich sofern das Element nicht genau einmal auftreten soll über die beiden Attribute minoccurs (minimales Auftreten) und maxoccurs (maximales Auftreten) festlegen, die jeweils eine nicht-negative Ganzzahl, d.h. auch den Wert 0 erwarten. Jede beliebige Kombination ist möglich. Sofern ein Element beliebig oft auftreten darf, ist der Standardwert unbounded zu verwenden. Der Datentyp wird über die vordefinierten Namen der XML Schema-Datentypen oder über einen eigenen Namen aus der Liste der selbst erstellten Datentypen (globale simpletype-elemente für einfache und complextype- Elemente für komplexe Strukturen mit Kind-Elementen und Attributen) im type-attribut angegeben. 42

18 1 Eine Referenz auf ein so genanntes globales element-element, das direktes Kind vom Wurzelement ist, wird im ref-attribut über seinen Namen eingerichtet. Ob ein Element leer sein kann, wird über das Attribut nillable angegeben. Der Inhalt eines Elements kann innerhalb vom complextype-kind andere Elemente, Attribute oder Schlüssel- und Schlüsselverweiselemente sein sowie innerhalb vom simpletype-kind genaue Datentypangaben, welche das type-attribut ersetzen. Die Reihenfolgenbeziehung zu anderen Elementen wird nicht innerhalb des Elements selbst angegeben, sondern ist abhängig von seinem direkten Elternelement. <element maxoccurs = (nonnegativeinteger unbounded) : 1 minoccurs = nonnegativeinteger : 1 name = NCName nillable = boolean : false ref = QName type = QName {any attributes with non-schema namespace...}> Content: (annotation?, ((simpletype complextype)?, (unique key keyref)*)) </element> Attribute befinden sich innerhalb des complextype-kindelements innerhalb des element-elements, gehören also zum komplexen Inhalt eines Elements, stehen aber außerhalb der Reihenfolgenangabe wie z.b. dem sequence-element. Der Name wird im name-attribut angegeben, das einen gültigen XML-Namen ohen Namensraumpräfix erwartet. Der Datentyp wird über die vordefinierten Namen der XML Schema-Datentypen oder über einen eigenen Namen aus der Liste der selbst erstellten Datentypen (globale simpletype-elemente für einfache Typen) im type-attribut angegeben. 43

19 1 Eine Referenz auf ein so genanntes globales attribute-element, das direktes Kind vom Wurzelement ist, wird im ref-attribut über seinen Namen eingerichtet. Der Standardwert wird im default-attribut mit einer Zeichenkette angegeben. Der feste Wert wird im fixed-attribut mit einer Zeichenkette angegeben. Die Attributverwendung wird mit vorgegeben Werten im use-attribut angegeben: optional (optional, kann vorkommen oder fehlen), prohibited (verboten, darf nicht auftreten, was nur sinnvoll bei der so genannten Ableitung ist) und required (verpflichtend, muss auftreten). Der Inhalt eines attribute-elements ist sinnvollerweise nur ein simpletype-element, welches das type-attribut ersetzt und genauere Datentypangaben enthält. <attribute default = string fixed = string name = NCName ref = QName type = QName use = (optional prohibited required) : optional {any attributes with non-schema namespace...}> Content: (annotation?, simpletype?) </attribute> In den Erklärungen der allgemeinen Syntax ist bereits die Unterscheidung zwischen globalen und lokalen Strukturen erwähnt worden. Einfache und komplexe Datentypen sowie wie im nächsten Beispiel Elemente und Attribute können einzeln oder auch als Gruppe (Element group für Elemente und Element attributegroup für Attribute) global auftreten. Das bedeutet, dass sie als direkte Kinder vom schema-element erscheinen und im ref-attribut von Elementen und Attributen global oder lokal aufgerufen werden können. Dadurch hat man die Möglichkeit, Auslagerungen und Wiederverwendungen einzurichten und die angegeben Eigenschaften mehrfach im Dokument zu verwenden. 44

20 1 <xs:schema xmlns:xs= elementformdefault= qualified > <xs:element name= Dozent > <xs:complextype> <xs:sequence> <xs:element ref= Name /> <xs:element ref= Adresse /> </xs:sequence> <xs:attribute name= Nr type= xs:string use= required /> </xs:complextype> </xs:element> <xs:element name= Dozentenliste > <xs:complextype> <xs:sequence> <xs:element ref= Dozent maxoccurs= unbounded /> </xs:sequence> </xs:complextype> </xs:element> <!-- Andere Angaben... --> </xs:schema> 121_02.xsd: Verwendung von globalen Elementen Wie oben schon erwähnt, werden die Inhaltsmodelle über einige wenige Elemente ausgedrückt, die als direkte Kinder von complextype bzw. dadurch als Abkömmlinge von element auftreten. Ihre Verwendung ist sehr einfach, wobei die Ausdrucksmöglichkeiten durch Kombinationen und Verschachtelungen der Elemente sowie durch ihre Häufigkeitsangaben in den aus element bekannten Attributen minoccurs und maxoccurs sehr umfangreich sein können. Der all-container drückt aus, dass eine beliebige Reihenfolge der element-kinder im XML-Dokument auftreten kann. <all maxoccurs = 1 : 1 minoccurs = (0 1) : 1 {any attributes with non-schema namespace...}> 45

21 1 Content: (annotation?, element*) </all> Der choice-container drückt aus, dass die direkten Kinder sich gegenseitig ausschließende Alternativen darstellen und daher nur eine von diesen Alternativen im XML-Dokument auftreten darf. <choice maxoccurs = (nonnegativeinteger unbounded) : 1 minoccurs = nonnegativeinteger : 1 {any attributes with non-schema namespace...}> Content: (annotation?, (element group choice sequence any)*) </choice> Der sequence-container drückt aus, dass die Reihenfolge der direkten Kinder ebenfalls im XML-Dokument auftreten muss. Er wird durch die Reihenfolge in Dokumentrichtung (westliche Lesrichtung, von oben nach unten) ausgedrückt, d.h. die Reihenfolge der Kinder entspricht der Reihenfolge im XML-Dokument. <sequence maxoccurs = (nonnegativeinteger unbounded) : 1 minoccurs = nonnegativeinteger : 1 {any attributes with non-schema namespace...}> Content: (annotation?, (element group choice sequence any)*) </sequence> Datentypen Das XML Schema zeichnet sich insbesondere durch die Integration einer überaus umfangreichen Datentypstruktur aus. Mit ihr können für alle Programmiersprachen und Datenbanken Datentypangaben getroffen werden. In Kombination mit eigenen Datentypen und weiteren Einschränkungen können genau die erforderlichen Angaben getroffen werden, die für den aktuellen Einsatz notwendig sind. Die Datentypen sind in einem eigenen Standard beschrieben, da sie auch in anderen XML-Technologien vom W3C verwendet werden. Die nachfolgende Tabelle gibt zunächst einen Überblick über die verschiedenen primitiven Datentypen. Auf die Angabe von Längen und genauen Eigenschaften 46

22 1 muss aus Platzgründen verzichtet werden, doch geben die Namen in jedem Fall bereits die Funktion an. Zahlen Zeichenketten Zeit Logik decimal float double hexbinary base64binary string anyuri QName NOTATION duration datetime time date gyearmonth gyear gmonthday gday gmonth boolean Einfache Datentypen Die nachfolgende Tabelle gibt eine Übersicht der von den primitiven Datentypen abgeleiteten Datentypen. Sie unterscheiden sich von diesen durch weitere Einschränkungen (andere Größen, mit/ohne den Wert 0, positive oder ganze Zahlen) und umfassen auch die bekannten DTD-Datentypen, die aus Kompatibilitätsgründen enthalten sind. Zahlen integer nonpositiveinteger negativeinteger long int short byte nonnegativeinteger unsignedlong unsignedint unsignedshort unsignedbyte positiveinteger Zeichenketten normalizedstring token language NMTOKEN NMTOKENS Name NCName ID IDREF IDREFS ENTITY ENTITIES Abgeleitete Datentypen Die Datums- und Zeittypen erfordern spezielle Formatierungen, die in Datenbanken teilweise nur mit Trigger oder eigenen CHECK-Bedingungen überprüft werden können. Sie sind daher für die DB-Entwicklung besonders interessant und nützlich. Eine Dauer (duration) wird im Format PnYnMnDTnHnMnS mit dem Trennzeichnen T zwischen Datum und Uhrzeit, angegeben: 47

23 1 Jahr Monat Tag Stunde Minute Sekunde ny nm (*) nd (*) nh (*) nm (*) ns (*) (wahlweise auch Dezimalstellen für kleinere Unterteilungen) Bestandteile der Zeitspannenangabe Datum und Uhrzeit (datetime) werden in der Form CCYY-MM-DDThh:mm:ss mit dem Trennzeichnen T zwischen Tages- und Uhrzeitangabe angegeben: Jahr Monat Tag Stunde Minute Sekunde CCYY MM DD hh mm ss (wahlweise auch Dezimalstellen für kleinere Unterteilungen) Bestandteile der Zeitangabe Analog zu diesen beiden Beispielen lauten die anderen Formate für den gregorianischen Kalender: Zeit (time): hh:mm:ss.sss. Datum (date): CCYY-MM-DD Kombinationen und Felder wie Jahr/Monat (gyearmonth) CCYY-MM, Tag/ Monat (gmonthday) MM-DD, Jahr (gyear) CCYY, Monat (gmonth) MM und Tag (gday) DD. Die Abbildung 1.6 fasst die verschiedenen Datentypen noch einmal zusammen. 48

24 1 Abbildung 1.6: Datentypen von XML Schema 49

25 1 Sofern keine bereits vordefinierten Datentypen zum Einsatz kommen können, besteht die Möglichkeit, lokal weitere Einschränkungen zu treffen oder sogar global eigene benannte Datentypen zu erstellen. Dabei kommen so genannte Fassetten zum Einsatz. Nicht jede Fassette ist für jeden Datentyp zulässig. Sie geben typischerweise Längenbeschränkungen für Zeichen oder Grenzen für Zahlen sowie Dezimalaufteilungen an. Sollten dann komplexe Prüfungen notwendig werden, kann man sogar reguläre Ausdrücke verwenden. Die Tabelle fasst alle Fassetten zusammen. Typ length minlength maxlength pattern enumeration whitespace maxinclusive maxexclusive minexclusive mininclusive totaldigits fractiondigits Verwendung Gesamtlänge einer Zeichenkette Minimale Länge einer Zeichenkette Maximale Länge einer Zeichenkette Muster als regulärer Ausdruck für eine Zeichenkette Aufzählung von verwendbaren Werten Leerraumbehandlung Obere eingeschlossene Grenze Obere nicht eingeschlossene Grenze Untere nicht eingeschlossene Grenze Untere eingeschlossene Grenze Gesamtstellenzahl einer Zahl Nachkommastellen einer Zahl Fassetten Abbildung 1.7: Fassetten 50

26 1 Man unterscheidet zwischen grundlegenden und einschränkenden Fassetten, wobei die grundlegenden nicht beeinflusst werden können, sondern Datentypen allgemein charakterisieren. Die einschränkenden dagegen lassen sich über XML Schema-Elemente, die den gleichen Namen tragen wie in der Tabelle und in Abbildung 1.7 innerhalb vom simpletype-element verwenden. Die Fassetten lassen sich innerhalb von lokalen oder globalen simpletype-elementen in beliebiger Reihenfolge verwenden. Ihr Name entscheidet über ihre Funktion, während im value-attribut der dazu passende Wert eingetragen wird. Ansonsten gibt es keine weiteren Verschachtelungen und Strukturen. Der Nachname soll wenigstens ein Zeichen und maximal 30 Zeichen lang sein. <xs:element name= Nachname > <xs:simpletype> <xs:restriction base= xs:string > <xs:minlength value= 1 /> <xs:maxlength value= 30 /> </xs:restriction> </xs:simpletype> </xs:element> 122_01.xsd: Ableitung von xs:string und weitere Einschränkung Das Attribut Anrede soll nur die Werte Herr oder Frau enthalten. Hier ist der ganze Quelltext für das dazugehörige Element Name abgedruckt, um zu zeigen, wie der einfache Datentyp im Attribut platziert wird und welchen Eindruck das ganze Gebilde vermittelt. <xs:element name= Name > <xs:complextype> <xs:sequence> <xs:element ref= Vorname /> <xs:element ref= Nachname /> </xs:sequence> <xs:attribute name= Anrede use= required > <xs:simpletype> <xs:restriction base= xs:string > <xs:enumeration value= Herr /> 51

27 1 <xs:enumeration value= Frau /> </xs:restriction> </xs:simpletype> </xs:attribute> </xs:complextype> </xs:element> 122_01.xml: Ableitung von xs:string und Aufzählung Wie oben erwähnt besteht die Möglichkeit, globale einfache Datentypen zu erstellen. Sie besitzen im Gegensatz zu den lokalen einfachen Datentypen einen Namen im name-attribut, unter welchem man sie später wieder im type-attribut eines Elements oder Attributs aufrufen kann. Der Inhalt ist mit denen der lokalen völlig identisch. Der Vorname basiert auf dem ZKTyp, der eine Zeichenkettenlänge zwischen 1 und 30 vorschreibt. <xs:element name= Vorname type= ZKTyp /> <!-- Globale Datentypen --> <xs:simpletype name= ZKTyp > <xs:restriction base= xs:string > <xs:minlength value= 1 /> <xs:maxlength value= 30 /> </xs:restriction> </xs:simpletype> </xs:schema> 122_02.xsd: Globaler einfacher Datentyp Globale komplexe Typen Neben den einfachen Datentypen gibt es in XML Schema einen weiteren wesentlichen Pfeiler, der sowohl für einfache Auslagerungen und Wiederverwendungen nützlich ist und welcher auch in erweiterten oftmals als objektorientierten - Ableitungstechniken genutzt wird. Dies betrifft die Möglichkeit, die complextype- Kinder von element-elementen ebenfalls zu globalisieren und ihnen einen Namen zu geben, unter dem sie dann im type-attribut genauso wie einfache Datentypen in einem element-element aufgerufen werden können. Diese Technik eröffnet Möglichkeiten, auch komplexe Strukturen mit verschachtelten Inhalten 52

28 1 auszulagern und wieder zu verwenden und auch diese Strukturen abzuleiten, d.h. zu erweitern und zu verkleinern. Im nachfolgenden Beispiel gibt es einen NameType, der die Inhalte Vorname und Nachname enthält, einen nicht abgedruckten AdresseType, der die Inhalte der Dozentenadresse enthält, und einen DozentType, der die Elemente Name und Adresse enthält, welche jeweils die gerade genannten globalen komplexen Typen aufrufen. <xs:schema xmlns:xs= elementformdefault= qualified attributeformdefault= unqualified > <!-- Globaler komplexer Typ: NameType --> <xs:complextype name= NameType > <xs:sequence> <xs:element name= Vorname type= xs:string /> <xs:element name= Nachname type= xs:string /> </xs:sequence> <xs:attribute name= Anrede type= xs:string use= required /> </xs:complextype> <!-- Globaler komplexer Typ: AdresseType --> <! > <!-- Globaler komplexer Typ: DozentType --> <xs:complextype name= DozentType > <xs:sequence> <xs:element name= Name type= NameType /> <xs:element name= Adresse type= AdresseType /> </xs:sequence> <xs:attribute name= Nr type= xs:string use= required /> </xs:complextype> <!-- Wurzelelement --> <xs:element name= Dozentenliste > <xs:complextype> <xs:sequence> <xs:element name= Dozent type= DozentType maxoccurs= unbounded /> </xs:sequence> 53

29 1 </xs:complextype> </xs:element> </xs:schema> 123_01.xs:. Verwendung von globalen komplexen Typen Die Abbildung 1.8 zeigt diese ganz andere Struktur als jene im Babuschka-Design und in der DTD mögliche noch einmal auf. Deutlich erkennt man die verschiedenen Bausteine, aus denen die XML Schema-Syntax und damit die Datenarchitektur zusammengesetzt ist. Abbildung 1.8: Verwendung von globalen komplexen Typen In einem grafischen Editor werden die entsprechenden Strukturen umrandet abgebildet. Der entstehende und deklarierte Baum bleibt derselbe. Es ändert sich auch nichts an den modellierten XML-Strukturen, doch das Wie der Modellierung ist grundsätzlich anders. 54

30 1 Abbildung 1.9: Verwendung von globalen komplexen Datentypen Der nächste Schritt, der allerdings syntaktisch sehr umfangreich ist, besteht in der Ableitung von globalen einfachen und komplexen Strukturen, in dem entweder weitere Einschränkungen durchgeführt werden (weniger Kind-Elemente oder Attribute bzw. kleinerer Datenbereich) oder Erweiterungen stattfinden (Anhängen von Kindelementen oder Attributen) Schlüssel und Schlüsselverweise Die Möglichkeit, Schlüssel und Verweise abzubilden, ist in XML Schema genauso wie in DTD gegeben, wobei allerdings sämtliche Einschränkungen aufgehoben wurden. Aus Gründen der Kompatibilität stehen zwar die DTD-Datentypen zur Verfügung, doch mit Hilfe der XML Schema-Techniken kann man jeden beliebigen Datentyp verwenden, da eigene Elemente für die Einrichtung vorhanden sind. 55

31 1 Da die Einschränkungen aus der DTD in XML Schema nicht berücksichtigt werden müssen, können Schlüssel auch nur Zahlen enthalten oder wie ISBN-Nummern aus Zusammensetzungen aus Buchstaben und Zahlen bestehen. Es ist ebenfalls möglich, Attributwerte und Textknoten als Schlüssel und Verweise zu verwenden sowie den gleichen Schlüsselwert für verschiedene Elemente/Attribute zu verwenden. Dies bedeutet, dass der Einsatz von XML Schema höchstwahrscheinlich geeigneter ist als der DTD-Einsatz ist, weil er für die meisten Datenbankstrukturen und -daten keine Konvertierungsmaßnahmen erfordert. Daher folgt im nächsten Quelltext die gleiche Datenstruktur mit verständlicher angegebenen Schlüsseln und Verweisen. <Buchungsliste> <Anmeldung Nr= 1438 > <Termin Nr= 338 /> <Preis>198</Preis> <Anmelder Nr= 231 /> <Teilnehmer Nr= 231 > <Name Anrede= Herr > <Vorname>Wolfgang</Vorname> <Nachname>Senff</Nachname> </Name> </Teilnehmer> </Anmeldung> <Anmeldung Nr= 1439 > <Termin Nr= 338 /> <Preis>198</Preis> <Anmelder Nr= 231 /> <Teilnehmer Nr= 338 > <Name Anrede= Frau > <Vorname>Sieglinde</Vorname> <Nachname>Voßwinkel</Nachname> </Name> </Teilnehmer> </Anmeldung> 124_01.xml: Verwendung von Schlüsseln und Verweisen Die Identitätsbeschränkungs-Komponenten dienen mit den Elementen key, selector, field, keyref sowie unique dazu, eine Verbindung zwischen einem 56

32 1 qualifizierten Namen und einer Schlüsselangabe herzustellen bzw. eine Referenz auf einen solchen Schlüssel festzulegen. Man setzt dabei XPath-Ausdrücke für die Bestimmung von Lokalisierungspfaden zu den identitätsbeschränkten Selektoren und ihren untergeordneten Feldern ein. Als Syntax für den Schlüsselbezug, also die Referenz auf einen gültigen Schlüssel, verwendet man dabei den qualifizierten Namen des Schlüssels innerhalb des keyref-elements für einen Schlüssel oder den Namen des keyrefs-elements für mehrere Schlüssel. In XML Schema gibt es zwei verschiedene Elemente zur Auswahl, mit denen Schlüssel und ein Element, mit dem Verweise angegeben werden können. Definition eines eindeutigen Schlüssels mit Hilfe der Schema-Komponente unique, wobei die Existenz des Feldes (Attribut oder Element) nicht kontrolliert wird. <unique name = NCName {any attributes with non-schema namespace...}> Content: (annotation?, (selector, field+)) </unique Definition eines eindeutigen Schlüssels und Kontrolle auf Existenz des als Schlüsselbestandteile angegebenen Feldes (Attribut oder Element) mit Hilfe der Schema-Komponente key. <key name = NCName {any attributes with non-schema namespace...}> Content: (annotation?, (selector, field+)) </key> Definition eines Schlüsselverweises mit Hilfe der Schema-Komponente keyref unter Angabe des Schlüsselnamens und des Feldes (Attribut oder Element), welches den referenzierenden Wert enthält. <keyref name = NCName refer = QName {any attributes with non-schema namespace...}> Content: (annotation?, (selector, field+)) </keyref> 57

33 1 Im nachfolgenden Quelltext sieht man die Verwendung von Schlüsseln und Verweisen innerhalb eines XML Schema-Aufbaus mit ausgelagerten globalen Elementen. Im Babuschka-Design verhält sich die Verwendung grundsätzlich etwas einfacher, weil die Reichweite des Schlüssels direkt mit der Position im verschachtelten Quelltext übereinstimmt. Dies ist natürlich nicht vom gewählten Dokumentaufbau abhängig, sondern vielmehr von der inhaltlichen Bedeutung des XML-Aufbaus. Mit dem Element selector wählt man über einen XPath-Ausdruck von dem Element, das den Schlüssel enthält, das Feld von seinen Abkömmlingen aus, welches den Schlüsselwert enthalten soll. In diesem Fall ist es das Attribut Nr, welches mit einem ebensolchen XPath-Ausdruck im field-element eingetragen wird. Die beiden Elemente verhalten sich analog im Verweiselement keyref. <xs:schema xmlns:xs= elementformdefault= qualified > <xs:element name= Anmelder > <xs:complextype> <xs:attribute name= Nr type= xs:string use= required /> </xs:complextype> <xs:keyref name= TNVerweis refer= TNSchluessel > <xs:selector x pat h=. /> <xs:field /> </xs:keyref> </xs:element> <xs:element name= Anmeldung > <xs:complextype> <xs:sequence> <xs:element ref= Termin /> <xs:element ref= Preis /> <xs:element ref= Anmelder /> <xs:element ref= Teilnehmer /> </xs:sequence> <xs:attribute name= Nr type= xs:string use= required /> </xs:complextype> </xs:element> <xs:element name= Buchungsliste > <xs:complextype> <xs:sequence> 58

34 1 <xs:element ref= Anmeldung maxoccurs= unbounded /> </xs:sequence> </xs:complextype> <xs:key name= TNSchluessel > <xs:selector xpath= Anmeldung/Teilnehmer /> <xs:field /> </xs:key> </xs:element> <! > </xs:schema> 124_01.xsd: Verwendung von Schlüsseln und Verweisen Abbildung 1.10: Verwendung von Schlüsseln und Verweisen 59

35 1 In der Abbildung 1.10 kann man sehr schön erkennen, wo die beiden Elemente platziert werden müssen und wie sie sich aufeinander beziehen müssen. Innerhalb der Buchungsliste gilt jedes Nr-Attribut des Teilnehmer-Elements als Schlüssel, auf das sich das Nr-Attribut im Anmelder-Element bezieht. Dabei findet keine zusätzliche Prüfung statt, ob dies auch für den gleichen Termin gilt Abfrage mit XPath Wie gerade schon für die Erstellung von Schlüsseln und Verweisen in XML Schema gezeigt, benötigt man für die Navigation innerhalb eines XML-Dokuments eine möglichst kurze Ausdruckssprache. Dies ist sowohl in XML Schema wie auch in XSLT/XSL-FO oder anderen, in diesem Kapitel nicht behandelten Themen wie XForms, die Navigations- und Abfragesprache XPath. Sie besitzt keine XML-Form, damit sie möglichst kurze Ausdrücke hervorbringt, die allerdings bei steigenden Anforderungen auch sehr umfangreich werden können. Die offiziellen Dokumente finden Sie unter XML Path Language (XPath), Version 1.0, W3C Recommendation 16 November 1999 ( und XML Path Language (XPath) 2.0, W3C Candidate Recommendation 3, November 2005( Die Version 1.0 ist für Oracle und PL/ SQL weiterhin gültig, während mit Java auch bereits die Version 2.0 zu verwenden ist Achsen Ein XPath-Ausdruck findet sieben verschiedene Knotenarten, für die es jeweils eine eigene Syntax gibt: Wurzelknoten (engl. root nodes) Elementknoten (engl. element nodes) Textknoten (engl. text nodes) Attributknoten (engl. attribute nodes) Namensraumknoten (engl. namespace nodes) 60

36 1 Prozessoranweisungen (engl. processing instruction nodes) Kommentare (engl. comment nodes) Knoten wie Elemente, Attribute und Namensräume werden über so genannte Achsen angesteuert, die in Dokumentrichtung (westliche Leserichtung, von oben nach unten) oder entgegen gesetzt zur Dokumentrichtung (von unten nach oben) Knoten finden. Sie ähneln einem Familienstammbaum und decken den gesamten Baum ab, der von einem XML-Dokument aufgespannt wird. Vorwärts child (Kind) descendant (Nachfolger) attribute (Attribut) self (Ich) descendant-or-self (Nachfolger und ich) following-sibling (Folgende Geschwister) following (Folgende) namespace (Namensraum) Rückwärts parent (Eltern) ancestor (Vorfahren) preceding-sibling (Vorhergehende Geschwister) preceding (Vorhergehende) ancestor-or-self (Vorfahren und ich) Achsentypen Die nachfolgenden Abbildungen sollen zusammen mit den Beispielen die Verwendung der verschiedenen Achsen demonstrieren. Die Knoten werden noch ohne Prädikate, d.h. ohne Bedingungen ausgewählt. Als Beispieldokument verwenden die Beispiele das zuvor im letzten Abschnitt modellierte Dokument 124_01.xml. 61

37 1 Abbildung 1.11: Achsen

38 1 Beispiele, ausgehend vom Wurzelknoten: child::* findet das Wurzelelement Buchungsliste in Kurzschreibweise (alle Kinder vom Wurzelknoten). child::buchungsliste findet das Wurzelelement Buchungsliste in Langschreibweise. child::buchungsliste/child::anmeldung/child::termin findet alle Termin-Elemente, die Kinder von Anmeldung, die Kinder von Buchungsliste sind. Kurzschreibweise: Buchungsliste/Anmeldung/Termin. Buchungsliste/Anmeldung/descendant::* findet von jeder Anmeldung Termin, Preis, Anmelder, Teilnehmer und deren Kinder und Kindeskinder. Beispiele ausgehend von einem Termin: parent::* findet in Kurzschreibweise das Eltern-Element Anmeldung, Langschreibweise: parent::anmeldung. parent::anmeldung/preis findet in Kurzschreibweise den zu einem Termin gehörenden Preis, Langschreibweise: parent::anmeldung/ child::preis, Alternative: Auswahl über die following-sibling-achse. 63

39 1 Abbildung 1.12: Achsen