l-ray.de: Terme

Terme

Eingabedaten können an Xcerpt entweder als XML- oder dem kürzeren Xcerpt-Format (folgend als XcerptV2 bezeichnet) übergeben werden. Sie werden als Datenterme repräsentiert, welche aus

Basis-Konstanten (bspw. Strings und Integer-Werte),
Bezeichner (Labels) und
zwei Arten von Term-Spezifikationen (eckige und geschweifte Klammern)

aufgebaut sind.

Im Vergleich zu XML wird ein Tag-Namen durch einen Bezeichner mit darauffolgender Term-Spezifikationen dargestellt. Darin eingeschoben sind die dazugehörigen Subterme.

<html> <head> <title>Test</title> </head> <body bgcolor="white"> <h1>Dies ist ein Test </h1> <p>Und es folgt Begleitung</p> </body> </html> html { head{ title [ "Test" ] } body { attributes { bgcolor ["white"] }, h1 ["Dies ist ein Test"], p ["Und es folgt Begleitung"] } }

Geschweifte Klammern ( { und }) spezifizieren, daß die direkten Unterterme in der Reihenfolge innerhalb der Sequenz ungeordnet auftreten. Durch eckige Klammern ([ und ]) wird hingegen eine Ordnung der direkten Subterme angezeigt. XML-Tags besitzen von Grund auf stets eine feste Reihenfolge. So folgt im obigen Beispiel der Paragraph "p" nach der Überschrift "h1".

Attribute

Attribute eines XML-Tags stellen eine weitere, beschreibende Instanz dar, sind jedoch als ungeordnet spezifiziert. Sie werden durch das Konstrukt $attributes \{l_{1} [d_{1}], . . . {,l}_{n} [d_{n}]\}$ dargestellt, wobei $attributes$ ein fester Bezeichner, und $l_{i}$ sowie $d_{i}$ ( $1 \leq i \leq n$ ) die Namen von Attributen und deren respektiven Werten sind.

Jede Basiskonstante stellt einen Datenterm dar. Falls $l$ ein Bezeichner und $d_{1} . . . d_{n} (n> 0)$ jeweils Datenterme sind, so ist $l [d_{1}, . . . {,d}_{n}]$ ein Datenterm mit definierter Reihenfolge der direkten Subterme und $l \{d_{1}, . . . {,d}_{n}\}$ ein Datenterme mit undefinierter Reihenfolge dieser.

Der Subterm eines Datenterms $t$ ist zunächst der Term $t$ selbst. Jeder Subterm von $t_{i} (1 \leq i \leq n)$ ist ebenfalls ein Subterm von $l \{t_{1}, . . . {,t}_{n}\}$ und $l [t_{1}, . . . {,t}_{n}]$ , wobei $l$ ein Bezeichner ist.

Dabei sind $t_{1}, . . {,t}_{n}$ direkte Subterme eines Datenterms $l \{t_{1}, . . . {,t}_{n}\}$ und $l [t_{1}, . . . {,t}_{n}]$ . Subterme von $t_{1}, . . . {,t}_{n}$ , mit Ausnahme von $t_{1}, . . . {,t}_{n}$ selbst sind indirekte Subterme von $l \{t_{1}, . . . {,t}_{n}\}$ und $l [t_{1}, . . . {,t}_{n}]$ .

Aus dieser Definition wird ersichtlich, dass ein Unterschied zu XML besteht, bei dessen Baumstruktur jeder Inhalt mit Ausnahme der Attribute geordnet ist. Als Schlußfolgerung korrespondieren nicht alle Xcerpt-Datenterme mit XML-Daten.

Abfrageterme stellen die Muster zu passenden Datentermen dar. Jeder Basisterm ist gleichzeitig ein Abfrage-Term. Jeder Abfrageterm, von der Definition her ebenso ein Datenterm. Er enthält jedoch zur Musteridentifizierung die zusätzlichen Konstrukte der Variablen, Unvollständigkeiten, Eingaberesourcen sowie Abfrage-Konjunktionen.

Allgemeine Abfrageterme beinhalten Variablen. Sie binden bei einer erfolgreichen Übereinstimmung eines Abfrageterms bestimmte Terme des Datenterme.

Man unterscheidet zwischen verschiedenen Auftreten von Variablen:

Variablen ohne Restriktionen (var B) können zu jedem Subterm gebunden werden und besitzen Platzhalter-Funktion. Sie können auch an Stelle eines Bezeichners im Anfrageterm auftreten. Falls x eine Variable ist, dann ist var x ein Abfrage-Term.

Variablen mit Restriktionen (var B -> label {}) sind nur an Subterme des Datenterms bindbar, die mit dem Muster, welches sie beschränkt, passen. Falls x eine Variable ist und G ein Abfrageterm, dann ist var x -> G ein Abfrageterm.

Da Abfrageterme die Rolle von Mustern für Datenterme übernehmen, muss für eine Abfrage nicht die komplette Struktur des Dokumentes bekannt sein. Es wird lediglich genügend Material benötigt, um eine eineindeutige Beschreibung zu erhalten. Unvollständige Abfrageterme können dabei in der Dimension der Breite, als auch der Tiefe definiert werden. Zusätzlich können optionale Subterme gekennzeichnet werden.

Unvollständigkeit in der Breite wird durch die teilweisen Termspezifikatoren [[ und ]] sowie {{ und }} ausgedrückt. Durch sie ausgezeichnete Terme können optional zusätzliche, nicht aufgelistete Subterme enthalten. Ihnen gegenüber stehen die bereits zu Beginn eingeführten totalen Termspezifikationen [ und ] bzw. { und }, welche vollständig angegebene Subterm-Mengen definieren.

totale und teilweise Termspezifikation, Reihenfolge signifikant
`veranstaltung [ titel [ var A ], ort [ var B ], datum [[ tag [ var C1 ], monat [ var C2 ] ]] ]`	`<veranstaltung>> <title>Tanzabend</titel> <ort>Cafe "Blauer Engel"</ort> <datum> <tag>31</tag> <monat>12</monat> <jahr>1980</jahr> </datum> </veranstaltung> >`

Eine Klammer nach dem Bezeichner zeigt demnach, daß nur die angegebenen Elemente in der gegebenen Reihenfolge auftreten. Zwei Eckklammern nach dem Bezeichner (teilweise Termspezifikation) definieren die spezifizierte Reihenfolge, jedoch können andere Elemente ebenfalls vorkommen. Geschweifte Klammern können anstelle der Eckklammern genutzt werden, um anzuzeigen, daß die Reihenfolge nicht signifikant ist.

totale und teilweise Termspezifikation, Reihenfolge nicht signifikant
`veranstaltung { titel [ var A ], ort [ var B ], datum {{ monat [ var C2 ], tag [ var C1 ] }} }`	`<veranstaltung> <title>Tanzabend</titel> <ort>Cafe "Blauer Engel"</ort> <datum> <tag>31</tag> <monat>12</monat> <jahr>1980</jahr> </datum> </veranstaltung>`

Ein Abfrageterm mit Eckklammern findet einen Datenterm nur, wenn die Bezeichner des Abfrageterms genau zu den Bezeichnern des Datenterm passen, sowie die direkten Subterme des Abfrageterms in korrekter Reihenfolge zu den direkten Subterm des Bezeichners im Datenterm.

Falls der Abfrageterm eine totale Termspezifikation besitzt, muss die Anzahl der direkten Subterme des Datenterms identisch zur Nummer der direkten Subterme des Abfrageterms sein. Falls der Abfrageterm eine teilweisen Termspezifikation besitzt, muss die Anzahl der direkten Subterme der Datenterme größer oder gleich zur Anzahl der direkten Subterme des Abfrageterms sein.

Die zusätzlichen direkte Subterme können unbestimmt innerhalb der direkten Subterme auftreten. Ein Abfrageterm mit geschweiften Klammern findet Datenterme in ähnlicher Weise mit der Ausnahme, dass die Datenterme nicht in eine bestimmte Ordnung passen müssen. falls W ein Bezeichner (l) oder eine Variable Abfrage Term (var X) und $q_{1}, . . . . {,q}_{n} (n> 0)$ Abfrageterme sind, dann sind $W [q_{1}, . . . {,q}_{n}]$ , $W \{q_{1}, . . . {,q}_{n}\}$ , $W [[q_{1}, . . . {,q}_{n}]]$ und $W \{\{q_{1}, . . . {,q}_{n}\}\}$ ebenfalls Abfrageterme.

Tiefe

Unvollständigkeit in der Tiefe wird durch den Bezeichner desc ausgedrückt. desc t findet somit einen Term, wenn dieser den Bezeichner t trägt. Er findet allerdings auch den Subterm eines Termes, wenn dieser Subterm den Bezeichner t trägt. Dabei ist es unerheblich, ob es sich dabei um einen direkten oder einen indirekten Subterm handelt. Falls q ein Abfrageterm ist, dann stellt des q ebenfalls ein Abfrageterm dar.

Unvollständigkeit in der Tiefe
`desc monat [ var C2 ]`	`<veranstaltung> <title>Tanzabend</titel> <ort>Cafe "Blauer Engel"</ort> <datum> <tag>31</tag> <monat>12</monat> <jahr>1980</jahr> </datum> </veranstaltung>`

Eingaberesourcen

Eingaberesourcen werden zum Durchsuchen externer Ressourcen genutzt. Dies können derzeit lokale sowie über das HTTP-Protokoll erreichbare Quellen im xml-, xcerpt- und eingeschränkt auch html-Format sein.

Falls $u$ eine URI und $t$ ein Type (bspw. Format) definiert, so sind $resource [u,t]$ und $resource \{u,t\}$ Resourcenausdrücke.

Die URI $u$ kennzeichnet das zu verwendende Protokoll (file: oder http:) und weitere protokollspezifische Informationen, wie der zum Zugriff nötige Pfad. Falls das Suffix der URI von Xcerpt erkannt wird, wird $t$ nicht benötigt.

Falls $u$ eine URI ist und eine Resource identifiziert, dann sind $resource [u]$ und $resource \{u\}$ Resourcenausdrücke.

Falls $r$ ein Ressourcenausdruck und $Q$ eine Abfrage ist, so sind $in [r,Q]$ und $in \{r,Q\}$ gezielte Abfrageterme.

Falls $r_{i} (1 \leq i \leq n)$ Resourcenausdrücke sind, so sind $or [r_{1}, . . . {,r}_{n}]$ und $or \{r_{1}, . . . {,r}_{n}\}$ ebenfalls Resourcenausdrücke.

Ein $o r$ -Resourcenausdruck identifiziert verschiedene Resourcen gleichzeitig. Die Abfrage $Q$ wird dann auf alle Datenterme von jeder der identifizierten Resourcen angewendet. Für die Zielabfrage zum Treffer muss $Q$ den Datenterm in mindestens einer der Resourcen finden.

Ein gezielter Abfrageterm assoziiert die Resourcen (n), welche durch den Resourenausdruck r mit einer Abfrage $Q$ beschrieben werden. Eine Resource speichert Datenterme (oder XML-Terme, welche mit den Datentemen korrespondieren). Die Bedeutung eines gezielten Abfrageterms ist, das $Q$ nicht gegen Daten in den Resource(n), welche durch $r$ beschrieben sind, gefunden werden muss.

Abfragen im Körper einer Regel, welche keine Resourcenausdrücke besitzen, werden mit dem durch die Konstruktionsregeln des Xcerpt-Programmes generiert Datenterme verglichen.

Abfragen

Eine Abfrage ist eine Verbindung von 0...* möglicherweise gezielten Abfragetermen unter Nutzung der logischen Verbindungen „and“, „or“ und „not“. Eine Abfrage ist wie folgt induktiv definiert:

Ein Abfrageterm oder gezielter Abfrageterm ist eine Abfrage.

Falls $Q_{1}, . . . {,Q}_{n} (n \geq 0)$ Abfragen sind, so sind $or [Q_{1}, . . . {,Q}_{n}]$ , $or \{Q_{1}, . . . {,Q}_{n}\}$ , $and [Q_{1}, . . . {,Q}_{n}]$ sowie $and \{Q_{1}, . . . {,Q}_{n}\}$ Abfragen.

Falls $Q$ eine Abfrage ist, dann ist $not Q$ ebenfalls eine Abfrage

Dabei verbindet eine „or“ Abfrage ähnlich einer „union“ in relationalen DBMSs die Ergebnismengen von Variablenbindungen der Ergebnisse $Q_{1}$ ,..., $Q_{n}$ . Eine „and“ Abfrage verbindet, ähnlich einem „join“, die gemeinsamen Variablenbindungen in $Q_{1}$ ,..., $Q_{n}$ .

Die „ $not$ “ Abfrage nutzt Negation als Fehler und ist erfolgreich, falls $Q$ fehlschlägt.

Konstruktterme

Konstruktterme sind ähnlich zu Datentermen, enthalten ebenfalls Variablen, jedoch zusätzlich den $all$ - und den $some$ -Ausdruck. Sie werden im Kopf von Ziel- und Konstruktionsregeln genutzt und beinhalten typischerweise Variablen. Die Variablenbindungen, welche im Konstruktionsterm gebunden werden, werden im Körper der Goal- und Konstruktionsregeln (durch Abfragen) aufgelöst.

Ein Konstruktionsterm ist induktiv wie folgt definiert:

Jede Basiskonstante ist ein Konstruktterm.

Falls $X$ eine Variable ist, ist $var X$ ein Konstrukt-Term. Falls $W$ ein Bezeichner oder eine Variable ist und $c_{1}, . . . {,c}_{n} (n \geq 0)$ Konstruktterme sind, dann sind $W [c_{1}, . . . {,c}_{n}]$ und $W \{c_{1}, . . . {,c}_{n}\}$ Konstruktionsterme. Falls $c$ ein Konstruktterm ist, dann ist $all c$ ein Konstruktterm. Falls $c$ ein Konstruktterm und $k$ ein natürliche Nummer, dann ist $some k c$ ein Konstruktionsterm. Damit ist jeder Datenterm ein Konstruktterm.

Sammelkonstrukte

Falls vor einem Konstrukt-Term $c$ der Quantor $all$ auftritt, konstruiert $c$ einen Datenterm per Variablenbindung der Variablen innerhalb der Liste $c$ .

Die möglichen Datenterme, welche durch $some k c$ gebildet werden, besitzen ein oberes Limit $k$ und sind nichtdeterministisch gewählt. Es werden also nur die k ersten Terme der Listenkonstruktion ausgegeben. Falls die Variable x an die Werte „eins“, „zwei“ und „drei“ gebunden wird (im Körper eines Konstrukt-Regel oder Zielregel), produziert der Konstrukt-Term

`results [ all result [ var X ] ]`	`results [ some 2 result [ var X ] ]`
liefert das Ergebnis	liefert das Ergebnis
`results [ result [„eins“], result [„zwei“], result [„drei“], result [„vier“], ]`	`results [ result [„eins“], result [„zwei“] ]`

Durch das Konstrukt „sort by“ können Ergebnismengen nach in Klammern genannten Variablen auf- bzw. absteigend sortiert werden.

Das Konstrukt „group by“ ermöglicht die Gruppierung nach Werten einer Menge von Variablen, wie dies auch aus dem DBMS-Sektor bekannt ist.

Durch die soeben vorgestellten Konstrukte ist es möglich, über die Vorgabe eines Musters einfach entfernte Datenquellen auf Terme, Bezeichner und Attribute abzufragen. Die Unterstützung der Unvollständigkeit in der Breite läßt zum Einen Varianzen bei der in XML stets geordneten Datenrepräsentation zu, zum Anderen kann in wichtigen Fällen die Reihenfolge genutzt werden.

Der Xcerpt-Ansatz eignet sich für die Erstellung von Wrappern [Gamma94], um lokale Datenschemata auf ein integriertes Schema zu vereinen. Es ist übersichtlich und gibt im Gegensatz zu XQuery durch reguläre Ausdrücke die Möglichkeiten der grundlegenden Datenanpassung..

Zum jetzigen Zeitpunkt müssen entsprechende Wrapper jedoch von Hand generiert werden. Im folgenden sollen daher Möglichkeiten vorgestellt werden, wie über Methoden der Strukturanalyse Schemen selbständig erkannt werden können.

Eingabedaten können an Xcerpt entweder als XML- oder dem kürzeren Xcerpt-Format (folgend als XcerptV2 bezeichnet) übergeben werden. Sie werden als Datenterme repräsentiert, welche aus

Basis-Konstanten (bspw. Strings und Integer-Werte),
Bezeichner (Labels) und
zwei Arten von Term-Spezifikationen (eckige und geschweifte Klammern)

aufgebaut sind.

Im Vergleich zu XML wird ein Tag-Namen durch einen Bezeichner mit darauffolgender Term-Spezifikationen dargestellt. Darin eingeschoben sind die dazugehörigen Subterme.

<html> <head> <title>Test</title> </head> <body bgcolor="white"> <h1>Dies ist ein Test </h1> <p>Und es folgt Begleitung</p> </body> </html> html { head{ title [ "Test" ] } body { attributes { bgcolor ["white"] }, h1 ["Dies ist ein Test"], p ["Und es folgt Begleitung"] } }

Geschweifte Klammern ( { und }) spezifizieren, daß die direkten Unterterme in der Reihenfolge innerhalb der Sequenz ungeordnet auftreten. Durch eckige Klammern ([ und ]) wird hingegen eine Ordnung der direkten Subterme angezeigt. XML-Tags besitzen von Grund auf stets eine feste Reihenfolge. So folgt im obigen Beispiel der Paragraph "p" nach der Überschrift "h1".

Attribute

Attribute eines XML-Tags stellen eine weitere, beschreibende Instanz dar, sind jedoch als ungeordnet spezifiziert. Sie werden durch das Konstrukt $attributes \{l_{1} [d_{1}], . . . {,l}_{n} [d_{n}]\}$ dargestellt, wobei $attributes$ ein fester Bezeichner, und $l_{i}$ sowie $d_{i}$ ( $1 \leq i \leq n$ ) die Namen von Attributen und deren respektiven Werten sind.

Datenterme

Jede Basiskonstante stellt einen Datenterm dar. Falls $l$ ein Bezeichner und $d_{1} . . . d_{n} (n> 0)$ jeweils Datenterme sind, so ist $l [d_{1}, . . . {,d}_{n}]$ ein Datenterm mit definierter Reihenfolge der direkten Subterme und $l \{d_{1}, . . . {,d}_{n}\}$ ein Datenterme mit undefinierter Reihenfolge dieser.

Der Subterm eines Datenterms $t$ ist zunächst der Term $t$ selbst. Jeder Subterm von $t_{i} (1 \leq i \leq n)$ ist ebenfalls ein Subterm von $l \{t_{1}, . . . {,t}_{n}\}$ und $l [t_{1}, . . . {,t}_{n}]$ , wobei $l$ ein Bezeichner ist.

Dabei sind $t_{1}, . . {,t}_{n}$ direkte Subterme eines Datenterms $l \{t_{1}, . . . {,t}_{n}\}$ und $l [t_{1}, . . . {,t}_{n}]$ . Subterme von $t_{1}, . . . {,t}_{n}$ , mit Ausnahme von $t_{1}, . . . {,t}_{n}$ selbst sind indirekte Subterme von $l \{t_{1}, . . . {,t}_{n}\}$ und $l [t_{1}, . . . {,t}_{n}]$ .

Aus dieser Definition wird ersichtlich, dass ein Unterschied zu XML besteht, bei dessen Baumstruktur jeder Inhalt mit Ausnahme der Attribute geordnet ist. Als Schlußfolgerung korrespondieren nicht alle Xcerpt-Datenterme mit XML-Daten.

Abfrage-Terme

Abfrageterme stellen die Muster zu passenden Datentermen dar. Jeder Basisterm ist gleichzeitig ein Abfrage-Term. Jeder Abfrageterm, von der Definition her ebenso ein Datenterm. Er enthält jedoch zur Musteridentifizierung die zusätzlichen Konstrukte der Variablen, Unvollständigkeiten, Eingaberesourcen sowie Abfrage-Konjunktionen.

Variablen

Allgemeine Abfrageterme beinhalten Variablen. Sie binden bei einer erfolgreichen Übereinstimmung eines Abfrageterms bestimmte Terme des Datenterme.

Man unterscheidet zwischen verschiedenen Auftreten von Variablen:

Variablen ohne Restriktionen (var B) können zu jedem Subterm gebunden werden und besitzen Platzhalter-Funktion. Sie können auch an Stelle eines Bezeichners im Anfrageterm auftreten. Falls x eine Variable ist, dann ist var x ein Abfrage-Term.

Variablen mit Restriktionen (var B -> label {}) sind nur an Subterme des Datenterms bindbar, die mit dem Muster, welches sie beschränkt, passen. Falls x eine Variable ist und G ein Abfrageterm, dann ist var x -> G ein Abfrageterm.

Unvollständigkeit

Da Abfrageterme die Rolle von Mustern für Datenterme übernehmen, muss für eine Abfrage nicht die komplette Struktur des Dokumentes bekannt sein. Es wird lediglich genügend Material benötigt, um eine eineindeutige Beschreibung zu erhalten. Unvollständige Abfrageterme können dabei in der Dimension der Breite, als auch der Tiefe definiert werden. Zusätzlich können optionale Subterme gekennzeichnet werden.

Breite

Unvollständigkeit in der Breite wird durch die teilweisen Termspezifikatoren [[ und ]] sowie {{ und }} ausgedrückt. Durch sie ausgezeichnete Terme können optional zusätzliche, nicht aufgelistete Subterme enthalten. Ihnen gegenüber stehen die bereits zu Beginn eingeführten totalen Termspezifikationen [ und ] bzw. { und }, welche vollständig angegebene Subterm-Mengen definieren.

totale und teilweise Termspezifikation, Reihenfolge signifikant
`veranstaltung [ titel [ var A ], ort [ var B ], datum [[ tag [ var C1 ], monat [ var C2 ] ]] ]`	`<veranstaltung>> <title>Tanzabend</titel> <ort>Cafe "Blauer Engel"</ort> <datum> <tag>31</tag> <monat>12</monat> <jahr>1980</jahr> </datum> </veranstaltung> >`

Eine Klammer nach dem Bezeichner zeigt demnach, daß nur die angegebenen Elemente in der gegebenen Reihenfolge auftreten. Zwei Eckklammern nach dem Bezeichner (teilweise Termspezifikation) definieren die spezifizierte Reihenfolge, jedoch können andere Elemente ebenfalls vorkommen. Geschweifte Klammern können anstelle der Eckklammern genutzt werden, um anzuzeigen, daß die Reihenfolge nicht signifikant ist.

totale und teilweise Termspezifikation, Reihenfolge nicht signifikant
`veranstaltung { titel [ var A ], ort [ var B ], datum {{ monat [ var C2 ], tag [ var C1 ] }} }`	`<veranstaltung> <title>Tanzabend</titel> <ort>Cafe "Blauer Engel"</ort> <datum> <tag>31</tag> <monat>12</monat> <jahr>1980</jahr> </datum> </veranstaltung>`

Ein Abfrageterm mit Eckklammern findet einen Datenterm nur, wenn die Bezeichner des Abfrageterms genau zu den Bezeichnern des Datenterm passen, sowie die direkten Subterme des Abfrageterms in korrekter Reihenfolge zu den direkten Subterm des Bezeichners im Datenterm.

Falls der Abfrageterm eine totale Termspezifikation besitzt, muss die Anzahl der direkten Subterme des Datenterms identisch zur Nummer der direkten Subterme des Abfrageterms sein. Falls der Abfrageterm eine teilweisen Termspezifikation besitzt, muss die Anzahl der direkten Subterme der Datenterme größer oder gleich zur Anzahl der direkten Subterme des Abfrageterms sein.

Die zusätzlichen direkte Subterme können unbestimmt innerhalb der direkten Subterme auftreten. Ein Abfrageterm mit geschweiften Klammern findet Datenterme in ähnlicher Weise mit der Ausnahme, dass die Datenterme nicht in eine bestimmte Ordnung passen müssen. falls W ein Bezeichner (l) oder eine Variable Abfrage Term (var X) und $q_{1}, . . . . {,q}_{n} (n> 0)$ Abfrageterme sind, dann sind $W [q_{1}, . . . {,q}_{n}]$ , $W \{q_{1}, . . . {,q}_{n}\}$ , $W [[q_{1}, . . . {,q}_{n}]]$ und $W \{\{q_{1}, . . . {,q}_{n}\}\}$ ebenfalls Abfrageterme.

Tiefe

Unvollständigkeit in der Tiefe wird durch den Bezeichner desc ausgedrückt. desc t findet somit einen Term, wenn dieser den Bezeichner t trägt. Er findet allerdings auch den Subterm eines Termes, wenn dieser Subterm den Bezeichner t trägt. Dabei ist es unerheblich, ob es sich dabei um einen direkten oder einen indirekten Subterm handelt. Falls q ein Abfrageterm ist, dann stellt des q ebenfalls ein Abfrageterm dar.

Unvollständigkeit in der Tiefe
`desc monat [ var C2 ]`	`<veranstaltung> <title>Tanzabend</titel> <ort>Cafe "Blauer Engel"</ort> <datum> <tag>31</tag> <monat>12</monat> <jahr>1980</jahr> </datum> </veranstaltung>`