X-Technologien

Ein item ist entweder atomarer Wert, ein Knoten oder eine Funktion.

Atomare Werte sind Werte, die einem “atomaren Typ” angehören. Das sind z. B.:

xs:untypedAtomic

Fallback für z. B. Attributwerte, wenn gegen kein Schema geprüft wird. D. h. der Prozessor sieht nur den Textinhalt “2002-10-10T12:00:00-05:00Z” und weiß nicht, dass er ihn z. B. als Datum (xs:dateTime) interpretieren soll.

xs:numeric

Vereinigungstyp aus xs:double, xs:float und xs:decimal. Also Zahlen.

xs:string

Eine Zeichenkette

xs:boolean

Ein Wahrheitswert. D. h. true oder false

…

Es gibt sieben Arten von Knoten:

• document
• element
• attribute
• text
• namespace
• processing instruction
• comment

Jeder Knoten hat eine eindeutige Identität die ihn von allen anderen Knoten im Baum unterscheidet, auch wenn die textuelle Repräsentation von zwei Knoten gleich aussehen mag.

Im folgenden Beispiel gibt es zwei mal das Attribut tag="500". Es handelt sich dabei aber um zwei eindeutig unterscheidbare Knoten im Datenmodell.

<record>
  <datafield tag="500" ind1=" " ind2=" ">
    <subfield code="a">Erste Anmerkung</subfield>
  </datafield>
  <datafield tag="500" ind1=" " ind2=" ">
    <subfield code="a">Zweite Anmerkung</subfield>
  </datafield>
</record>

Der Attributwert 500 ist ein atomicValue. Dieser hat keine Identität. D. h. der Wert 500 ist in beiden Fällen derselbe.

Siehe XPath – Funktionen

Jede valide Instanz des Datenmodells ist eine Sequenz. Eine Sequenz ist eine geordnete Sammlung von null oder mehreren items. Jedes Item in einer Sequenz hat eine stabile Position (ermittelbar durch position()). Das erste Item in einer Sequenz ist auf Position 1 (nicht 0, wie in vielen anderen Programmiersprachen).

Eine Sequenz kann nicht in einer Sequenz enthalten sein. D. h. eine Kombination aus Sequenzen wird “geplättet”. D. h. (1, (2, 3), (), (), 4) wird zu (1, 2, 3, 4)

Ein einzelnes (“singleton”) item wird als eine Sequenz modelliert, die genau dieses eine item enthält.

Alle Knoten eines Dokuments haben eine absolute Reihenfolge. Diese Reihenfolge ist stabil und ändert sich nicht während einer Abfrage oder Transformation. Informell ist die Dokumentreihenfolge definiert als die Reihenfolge, in der die Knoten in einer XML-Serialisierung eines Dokuments erscheinen.

Die Sequenz, die ein Schritt zurückgibt, kann durch Prädikate weiter gefiltert werden. Ein Prädikat wendet eine Prüfung auf jeden Knoten der Sequenz an und entfernt alle, bei denen die Prüfung false ergibt. Daher spricht man auch von Filterausdrücken.

Besipiel:

/collection/record/datafield[@tag="245"]

/collection/record erzeugt eine Sequenz mit allen record-Elementen. /datafield holt wiederum aus all diesen Records alle datafields. Das Prädikat [@tag="245"] lässt aber nur die durch, die ein Attribut tag mit dem Wert 245 haben.

Man kann auch mehrere Prädikate angeben. Diese werden von links nach rechts abgearbeitet:

/collection/record/datafield[@tag="245"][@ind2!="0"]

Hier bekommen wir alle Titelfelder mit zu übergehenden Zeichen am Anfang. Man sieht hier auch, dass es zweckdienlich ist, zuerst die Prädikate anzugeben, die mehr ausfiltern (also kürzere Sequenzen durchlassen). Hätte man die Prädikate oben vertauscht würden zuerst alle datafield selektiert, die keinen zweiten Indikator “0” haben. Diese große Menge wiederum würde erst auf das Vorhandensein von tag="245" geprüft, während in der Version oben nur noch wenige elemente überhaupt die zweite Prüfung erreichen. Das kann gravierende Auswirkungen auf die Laufzeit einer Abfrage haben!

Das ist, was man erwartet, wenn man an Vergleiche denkt. Hier werden zwei Werte verglichen, also z. B. zwei Strings, zwei Ganzzahlen, etc. Wenn auf einer Seite des Operators mehr als ein Item ist, führt das zu einem Fehler.

Die Operatoren sind:

Ergebnis des Vergleichs zweier Operanden ist ein Wahrheitswert. D. h. 2 eq 2 ist true 2 gt 2 ist false.

Bei general comparisons tritt wieder die Sequenz als Bestimmendes Merkmal des Datenmodells zutage. Hier werden alle Werte der Sequenz auf der linken Seite mit allen Werten auf der rechten Seite verglichen. Wenn einer dieser Vergleiche erfolgreich ist, liefert die general comparison true zurück.

Die Operatoren:

Das ist sehr oft sehr praktisch. Z. B. kann man prüfen, ob eine Sequenz einen bestimmten Wert enthält: 2 = (1, 2, 3, 4) ist true. Es ist aber mit Vorsicht zu genießen, weil 2 != (1, 2, 3, 4) ist auch true. Warum?

Die Dinge, die mit logischen Operatoren verbunden sind, können nicht nur Wahrheitswerte sein. Oft verwendet man den “effective boolean value” (EBV). Ein sehr übliches Beispiel ist ein Prädikat, das auf das Vorhandensein eines Elements prüft, wie datafield[subfield]. Wir haben ja oben gelesen, dass ein Prädikat alle items einer Sequenz durchlässt, bei denen die Bedingung im Prädikat zutrifft, also wahr ist. Nun ist das Ergebnis von subfield nicht true oder false sondern eine (möglicherweise leere) Sequenz aller Subfelder. Trotzdem funktioniert es. Warum? Es gibt Regeln, nach denen ein effektiver Wahrheitswert gebildet wird:

1. leere Sequenz → false
2. eine Sequenz deren erstes Item ein Knoten (node) ist → true
3. bei Einzelwerten der Typen xs:string, xs:anyURI, xs:untypedAtomic und davon abgeleiteten Typen
   1. wenn der Wert die Länge 0 hat → false
   2. sonst: true
4. bei Einzelwerten eines numerischen Typs (also Zahlen)
   1. wenn der numerische Wert NaN oder 0 ist → false
   2. sonst: true
5. In allen anderen Fällen wirft der Prozessor einen Fehler.

Im Beispiel oben (datafield[subfield]) wird einer der Fälle 1. oder 2. zutreffen.

Einsatz in Prädikaten:

/persons/person/name[upper-case(.) eq "ELVIS"]

Findet alle Personen mit Namen “Elvis”, egal ob sie groß oder klein geschrieben sind. Die Funktion gibt immer den Eingabestring in Großbuchstaben zurück und wir prüfen gegen den String “ELVIS”.

/persons/person/name[upper-case(.) eq "Elvis"]

Was bekommen wir hier zurück?

Zur Konstruktion eines neuen Wertes:

<xsl:template match="datafield[@tag='245']/subfield[@code='a']">
  <subfield code="a">
    <xsl:value-of select="replace(., 'foo', 'bar')" />
  </subfield>
</xsl:template>

Dieses Template ändert den Wert von 245$$a, indem es die Zeichenkette foo gegen bar ersetzt .

• Eingabe besteht aus:
  1. Dem Quell-XML-Dokument.
  2. Dem XSLT-Stylesheet (ebenfalls XML-Struktur).
• Beides wird geparst und in den Speicher geladen

• XSLT folgt einem deklarativen Ansatz:
  • Es wird nicht Schritt-für-Schritt programmiert, sondern Regeln (Templates) definieren, wie Knoten im Eingabe-XML in Ausgabestrukturen transformiert werden.
• Die Verarbeitung basiert auf dem Match-and-Apply-Prinzip.
  • “Wenn du diesen Input siehst, generiere Output, der so und so aussieht.”

1. Parsing
   • Das Quell-XML und das XSLT-Stylesheet werden beide zu XML-Baumstrukturen
2. Initiales Template
   • Optional kann man bestimmen, welches Template als erstes ausgeführt werden soll
3. Template-Matching
   • Der Prozessor sucht zu jedem aktuellen Eingabeknoten das am beste passende Template (<xsl:template match="...">).
   • Falls kein passendes Template existiert, greift die eingebaute Standardregel:
     • Für Texte: Ausgabe des Textinhalts.
     • Für Elemente: rekursives Anwenden auf Kindknoten.
4. Anweisungen im Template
   • Wichtige Deklarationen:
     • xsl:apply-templates → Verzweigt zu anderen Knoten
     • xsl:sequence → Schreibt eine Sequenz von items in die Ausgabe
     • xsl:value-of → Gibt Textwert eines Knotens aus
     • xsl:for-each → Iteration über Knotenmengen
     • xsl:if / xsl:choose → Bedingte Verarbeitung
5. Rekursive Verarbeitung
   • xsl:apply-templates löst wieder Template-Matching aus.
   • Dadurch kann der gesamte Eingabebaum Schritt für Schritt transformiert werden.
6. Ausgabe
   • Der Ausgabebaum wird “serialisiert” (nicht notwendigerweise, aber in unseren Fällen immer)
   • XSLT erzeugt standardmäßig XML oder Text, aber je nach xsl:output auch HTML oder andere Textformate.

• Baumorientiert: XSLT arbeitet immer mit Knotenbäumen, nicht mit Zeichenketten.
• Deklarativ: Man beschreibt was passieren soll, nicht wie.
• Regelgesteuert: Verarbeitung läuft über Template-Matching, nicht lineare Befehlsfolgen.
• Deterministisch: Bei gleichen Eingaben und Stylesheets immer gleiche Ausgaben.

Gegeben:

   <root>
     <item>A</item>
     <item>B</item>
   </root>

Stylesheet:

   <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
     <xsl:template match="/">
       <html><body><xsl:apply-templates/></body></html>
     </xsl:template>

     <xsl:template match="item">
       <p><xsl:value-of select="."/></p>
     </xsl:template>
   </xsl:stylesheet>

Ablauf:

1. Start: Template / → Erzeugt <html><body>…</body></html>.
2. xsl:apply-templates → Findet <item>-Elemente.
3. Für jedes <item>: passendes Template erzeugt <p>Inhalt</p>.

4. Ausgabe:

         <html><body><p>A</p><p>B</p></body></html>
   

xsl:template ist die wohl wichtigste Deklaration in XSLT. Das <xsl:template> element muss entweder ein match und/oder ein name-Attribut haben.

Manche Anweisungen sollen nur dann ausgeführt werden, wenn bestimmte Bedingungen gegeben sind. Hier der Link zur Spezifikation:Contitional Processing

xsl:copy-of und xsl:sequence geben eine Sequenz an Knoten zurück, die durch das @select-Attribut definiert werden. In xsl:sequence kann man statt dem @select auch einen Sequenz-Kostruktur verwenden.

Der Effekt von beiden Anweisungen ist den meisten Fällen der gleiche. xsl:copy-of erstellt allerdings eine tiefe Kopie der selektierten Knoten. xsl:sequence gibt auch vorhandene Knoten zurück, was effizienter sein kann.

Wir wollen alle Felder 500 löschen, die in $$a den Text foo enthalten.

Wir wollen alle Felder 500 löschen, die in $$a den Text foo, aber nicht den Text bar enthalten.

Wir wollen alle Felder 500 löschen, die in $$a den Text foo direkt gefolgt von einer beliebig langen Zahl enthalten. Also foo1, foo667, foo00000000000000001.

Eine Zeitlang war in der CV-Liste für den Term “Backbuch” eine falsche GND-ID, nämlich (DE-588)7502992-3. Richtig wäre (DE-588)1071926306.

• Stylesheet: exercises/ex04/ex04_01.xsl
• Tests: exercises/ex04/ex04_01.xspec

Im Folgenden werden drei mögliche Lösungen vorgestellt. Sie bringen das gleiche Ergebnis. Welche man bevorzugt, ist eine Frage des Stils. Man sollte eine Lösung wählen, von der man glaubt, dass sie die Intention gut darstellt, wenn man den Code später wieder liest.