Xcerpt - eine Anfrage- und Transformationssprache für XML

Inhaltsverzeichnis

1 Einleitung

2 Basis-Konstrukte von XCerpt
2.1 Database Terms
2.2 Query Terms
2.2.1 Allgemeines
2.2.2 Der Konstruktor -> (“as”)
2.2.3 Der Konstruktor desc (descendant)
2.3 Construct Terms
2.3.1 Allgemeines
2.3.2 Der Konstruktor all...
2.3.3 Der Konstruktor some.

3 Aufbau eines Xcerpt Programms
3.1 Construct-Query-Rules
3.2 Goals
3.3 Rule Chaining

4 Weitere Konstrukte von Xcerpt
4.1 Attribute
4.2 Groups

5 Ausblick und zukünftige Herausforderungen

Literaturverzeichnis

Anhang A: XML-Quelldatei

1 Einleitung

Die zunehmende Bedeutung von XML als Format für den Datenaustausch und zur Repräsentation von semistrukturierten Datenbanken steigert auch das Interesse an Anfrage- und Transformationssprachen für XML und semistrukturierte Daten. Viele Sprachen wie XPath und XQuery verfolgen dabei einen navigationellen Ansatz, denn für die Variablenbindung wird vom Programmierer verlangt, explizite Pfadangaben durch Dokumente oder Datensätze anzugeben. Im Gegensatz dazu gibt es Anfragesprachen die „musterbasiert“ sind. Die Variablenbindung entspricht der mathematischen Logik, das heißt der Programmierer gibt Muster oder Schablonen an, die an ein oder mehreren Stellen Variablen enthalten können. (vgl. Berger/Bry/Schaffert 2004)

Xcerpt ist eine experimentelle, regel- und musterbasierte Anfrage- und Transformations- sprache für XML und semistrukturierte Daten. Dabei ist Xcerpt insofern experimentell, als dass es als Ziel hat, einen nicht-navigationellen Ansatz zur Anfrage auf Web-Daten zu untersuchen. Es wird somit ein anderer Ansatz verfolgt, als der der am weitesten verbreiteten Anfragesprachen XPath und XQuery. Eine prototypische Implementierung der Sprache kann auf der Seite http://demo.xcerpt.org getestet werden.

Ziel dieser Seminararbeit ist es, den Aufbau von Xcerpt, sowie die Funktionsweise der Anfrage- und Transformationssprache vorzustellen. Da es bisher nur wenig Literatur zum Thema gibt, beschränkt sich die Arbeit vorwiegend auf den Artikel von Bry und Schaffert. (vgl. Bry/Schaffert 2002) Die Beispiele sind dabei zum größten Teil übernommen wurden. Da es sich jedoch um eine Arbeit aus dem Jahr 2002 handelt, zeigten sich bezüglich der Syntax der Anfragen im Vergleich mit dem aktuellen Prototyp einige Abweichungen. In dieser Arbeit wurde die aktuelle Syntax (Xcerpt2) verwendet.

Die folgende Arbeit gliedert sich in 6 Kapitel. Kapitel 2 stellt die Basiskonstrukte von Xcpert vor. Darauf aufbauend wird der Aufbau eines Xcerpt-Programms erläutert (Kapitel 3). Anschließend werden weitere bis dahin nicht genannte Konstrukte vorstellt (Kapitel 4). Eine Zusammenfassung und ein Ausblick hinsichtlich der zukünftigen Herausforderungen schließen die Seminararbeit ab (Kapitel 5).

2 Basiskonstrukte von Xcerpt

In diesem Kapitel werden die grundlegenden Terme und Konstrukte der Anfrage- und Transformationssprache Xcerpt vorgestellt. Zu den Termen gehören Database Terms, Query Terms und Construct Terms.

2.1 Database Terms

Database Terms werden zur Darstellung von XML-Dokumenten und Datensätzen semistrukturierter Datenbanken verwendet. Die Einträge können demnach sowohl in geordneter Form, als auch in ungeordneter Form auftreten. (sortiert oder nicht sortiert)

Beispiel 1: Das folgende Database Term mit der Wurzel „lib“ beschreibt das Buchangebot des Online-Buchladens bn.com. Die dazugehörige XML-Struktur befindet sich im Anhang (Anhang A)

Abbildung in dieser Leseprobe nicht enthalten

Der Database Term enthält 2 unterschiedliche Klammerarten. Dazu gehören zum einen die geschweiften Klammern { } welche ausdrücken, dass die Subelemente unsortiert sind und zum anderen die eckigen Klammern [ ], die ausdrücken, dass die Subelemente sortiert sind.

2.2 Query Terms

2.2.1 Allgemeines

Query Terms sind Muster oder Schablonen die auf Database Terms angewendet werden. Nur wenn der Database Term in das Muster passt, wird er selektiert und anschließend ausgewertet. Nach Bry und Schaffert haben Query Terms folgende Eigenschaften:

1.) in einem Query Term ist es möglich, partielle Termspezifikationen zu verwenden, um irrelevante Teile auszulassen
2.) in einem Query Term können Teilterme, wie in Database Terms, geordnet oder ungeordnet sein
3.) in einem Query Term ist es möglich, Teilterme auf beliebiger Tiefe anzugeben (descendant)

Query Terms enthalten neben einfachen geschweiften und einfachen eckigen Klammern auch doppelt geschweifte {{ }} und doppelt eckige Klammern [[ ]].

Eine einfache Klammerung, { } und [ ], bedeutet, dass die Database Terms, welche ausgewertet werden sollen, an dieser Stelle nur die in der einfachen Klammer angegebenen Terme enthalten dürfen und müssen. Enthält ein Database Term an der Stelle mehr oder nicht exakt die gleichen Terme, fällt er durch das Muster und wird demnach nicht ausgewertet.

Die doppelten Klammern, {{ }} und [[ ]], bedeuten, dass die in den Klammern angegebenen Terme zwar vorhanden sein müssen, jedoch können weitere Terme neben ihnen existieren.

Eckige Klammern in Query Terms zeigen an, dass alle Terme, die in Ihnen angegeben werden, in der gleichen Reihenfolge auch in dem Database Term vorkommen müssen. Geschweifte Klammern bedeuten, dass die Reihenfolge der angegebenen Terme in dem Database Term keine Rolle spielt.

Eine leere doppelte Klammerung bedeutet, dass hier beliebig viele Terme stehen können. Eine leere einfache Klammerung bedeutet, dass der Term keinen Subterm enthalten darf.

Beispiel 2: Der folgende Query Term stellt ein Muster dar, in welches Beispiel 1 passt. Deshalb würde Beispiel 1 bei der Anfrage berücksichtigt werden.

Abbildung in dieser Leseprobe nicht enthalten

Das Muster beschreibt, dass es einen Wurzelknoten „bib“ geben muss, mit einem Subterm „book“. „book“ selbst muss ebenfalls einen Subterm aufweisen namens „title“. „title„ muss und darf nur einen Subterm aufweisen namens „Data on the Web“. Ist die genaue Schreibweise des Subterms nicht bekannt (Data on the Web oder Data_on_the_web etc.) kann durch den Ausdruck .*Data.* beschrieben werden, dass der Subterm lediglich Data enthalten muss.

Beispiel 3: Dieser Query Term ist nur geringfügig verändert gegenüber Beispiel 2 und dennoch würde Beispiel 1 nicht zum Muster passen.

Abbildung in dieser Leseprobe nicht enthalten

Entscheidend ist die einfache Klammerung vor „book“ die angibt, dass es nur den Term namens „book“ an der Stelle geben darf. Beispiel 1 enthält jedoch mehrere Terme an der Stelle („book“, „book“, „book“) weshalb es nicht mehr zum Muster passt und bei der Anfrage nicht berücksichtigt wird.

Beispiel 4: Auch bei dieser Anfrage würde Beispiel 1 nicht das angegebene Muster erfüllen.

Abbildung in dieser Leseprobe nicht enthalten

Die eckige Klammer legt die Reihenfolge von „authors“ und „title“ fest. In Beispiel 1 steht „authors“ jedoch nach „title“. Beispiel 1 erfüllt damit nicht das Muster.

Query Terms können Variablen enthalten, die durch die Anfrage mit entsprechenden Einträgen und Bindungen versehen werden.

Beispiel 5: Dieses Beispiel legt die zwei Variablen X und Y fest.

Abbildung in dieser Leseprobe nicht enthalten

X wird dabei an die Werte von “title” gebunden, Y an die Werte von „author“. Gleichzeitig werden Bindungen zwischen X und Y hergestellt. Bezogen auf das Beispiel 1 werden so beispielsweise folgende Bindungen abgespeichert.

Abbildung in dieser Leseprobe nicht enthalten

2.2.1 Der Konstruktor -> („as“)

In Beispiel 5 nehmen die Variablen den Wert der Terme ein, die an der entsprechenden Stelle vorkommen. Durch den Konstruktor „->“ ist es möglich die Variablen in höheren Positionen festzulegen und die Bindungen mit entsprechenden Einschränkungen zu versehen.

Beispiel 6: Hier wird der Konstruktor „->“ eingesetzt um die Variable Y an den Term „authors“ zu binden.

Abbildung in dieser Leseprobe nicht enthalten

[...]