textauszeichnung und dokumentgrammatikeng91062/pdf/lobin-ll-2003c.pdf · ter textauszeichnung wird...

Textauszeichnung undDokumentgrammatiken

Henning Lobin

1 Einleitung

Ein zentrales Mittel der Texttechnologie bildet die Textauszeichnung. Un-ter Textauszeichnung wird die Einfügung von Markierungen in einen Textverstanden, aufgrund derer die auf diese Weise ausgezeichneten Textteile inspezieller Weise verarbeitet werden können (vgl. Sperberg-McQueen et al.,2000). Derartige Markierungen, auch Annotation oder Markup genannt, set-zen sich aus einem Anfangs- und einem Endtag zusammen. Der Sinn derTextauszeichnung kann darin bestehen,

• einen Textabschnitt eindeutig identifizierbar zu machen (z. B. als eineDefinition),

• eine Zuordnung zu einer Gruppe gleich zu behandelnder Textabschnittevorzunehmen (z. B. Überschriften) oder

• weitere Informationen, sog. Metadaten, zur Verfügung zu stellen (z. B.Bearbeiter und Datum der letzten Änderung eines Textabschnitts).

Dementsprechend können sehr unterschiedliche Verarbeitungsverfahren vonder Annotation Gebrauch machen:

• In einem Hypertextsystem kann durch Links auf eindeutige Textstellenverwiesen werden – die Textauszeichnung wird also für Browsing-Zweckeverwendet (siehe Storrer, in diesem Band);

• eine Gruppe von gleich ausgezeichneten Textabschnitten kann grafischgleich behandelt werden – die Textauszeichnung bildet dabei die Grund-lage für die visuelle Textgestaltung;

• Metadaten können genutzt werden, um in einem Textkorpus Textab-schnitte mit bestimmten Eigenschaften aufzufinden – die Textauszeich-nung steht hier im Dienste des Information Retrieval .

52 Henning Lobin

Insbesondere für Layoutierungsprogramme werden schon seit den sechzi-ger Jahren Textauszeichnungsverfahren angewendet. Aber erst mit der Stan-dard Generalized Markup Language (SGML), einer standardisierten Me-tasprache zur Spezifikation von Textauszeichnungsvokabularien, stand ab1986 ein Instrumentarium zur Verfügung, durch das die Textauszeichnungvon bestimmten Anwendungssystemen unabhängig wurde und zugleich fürunterschiedliche Anforderungen spezifisch zugeschnitten werden konnte.Die bekannteste Anwendung von SGML wurde in den neunziger JahrenHTML, die „Sprache des World Wide Web“. Eine vereinfachte Version vonSGML, die Extensible Markup Language (XML), hat heute SGML weitge-hend ersetzt.

2 Baumstrukturen und Markup

Eine der grundlegenden Neuerungen im Bereich des Dokument-Markup,die durch SGML eingeführt wurde und auch die Grundlage von XML bil-det, besteht darin, die durch Tags annotierten Textteile in einen hierarchi-schen Zusammenhang zu bringen, anstatt sie lediglich linear anzuordnen(vgl. Lobin, 2000). Die Textteile befinden sich dadurch nicht nur in der, na-türlich immer noch vorhandenen, sequenziellen Reihenfolge, sondern stehenzusätzlich auch noch in einer Teil-Ganzes-Beziehung zueinander. Ein Text-element „Kapitel“ kann danach z. B. aus den Textelementen „Überschrift“,drei Absatz- und einem Abbildungselement bestehen. Das Kapitelelementseinerseits konstituiert mit anderen Elementen ein Textelement „Buch“.

Informationselemente, die in dieser Weise verschachtelt sind, lassen sichgrafisch und formal als Bäume darstellen. Die Interpretation von Textdoku-menten als Bäume hat einige große Vorteile gegenüber einer linearen Text-auszeichnung: Wenn in einem Baum einem Element eine Eigenschaft zuge-ordnet ist, so kann z. B. festgelegt werden, dass diese Eigenschaft auch al-len diesem Element untergeordneten Elementen zukommt, sofern bei ihnennicht explizit etwas anderes vermerkt ist. Das hier angewendete Prinzip derVererbung von Eigenschaften ist also ein Mittel, diese Eigenschaften effizientTeilen eines Dokuments zuzuordnen. Weiterhin erlaubt die Baumstruktureine recht präzise Navigation im Dokument. Ein Ausdruck wie „der zweiteAbsatz im nachfolgenden Kapitel“ kann leicht als ein Pfad durch den Doku-mentbaum dargestellt werden.

Aus Sicht der maschinellen Verarbeitung von annotierten Dokumentenkönnen wegen der Universalität von baumartig strukturierter Informationin der Informationstechnologie viele Verfahren aus anderen Bereichen über-

2. Textauszeichnung und Dokumentgrammatiken 53

nommen werden. Bei der Überprüfung beispielsweise, ob ein Dokumentauch eine korrekt aufgebaute Baumstruktur aufweist, können Verfahren an-gewendet werden, die für die Analyse von Programmen entwickelt wordensind (Compilerbau).

Aus Sicht der Linguistik ist jedoch der wichtigste Vorteil der Verwen-dung von Baumstrukturen, dass man diese durch Grammatiken1 beschreibenkann, und Grammatiktheorie und Grammatikformalismen in der Linguis-tik als gut untersuchte Gebiete gelten können. Den Wert einer Grammatikfür die Verarbeitung strukturierter Dokumente kann man sich am bestendeutlich machen, wenn man sich die Funktion von Grammatiken im Zu-sammenhang mit der natürlichen Sprache vor Augen führt.

Wir nutzen die Regeln der Grammatik einer Sprache, um eine komplexe,oftmals von uns in der Gesprächssituation neu erschaffene Bedeutung aufder Grundlage von Wörtern in eine Laut- oder Buchstabenfolge zu kodie-ren und sie in dieser Form an Kommunikationspartner zu übermitteln. Daauch dem Kommunikationspartner die Wörter und die Grammatikregelnbekannt sind, ist er in der Lage, aus den wahrgenommenen Laut- und Buch-stabenfolgen eine Bedeutung zu rekonstruieren. Die grammatischen Regelnbilden also einen Rahmen zur Rekonstruktion komplexer Bedeutung ausge-hend von kleinen Bedeutungseinheiten (Kompositionalitätsprinzip sprachli-cher Bedeutung).

Im Falle eines Dokuments kann man demzufolgen sagen, dass Regeln ele-mentare Textteile, gewissermaßen die Wörter des Dokuments, so miteinan-der in Verbindung setzen, dass die Dokumentbedeutung transferierbar undrekonstruierbar wird. Was ist nun aber die Dokumentbedeutung? Auf dieseFrage kann keine generelle Antwort gegeben werden, da Dokumentgram-matiken anders als die Grammatik natürlicher Sprachen ihrem jeweiligenVerwendungszweck angepasst sind. Oft geht es allerdings darum, die Cha-rakteristika einer bestimmten Textsorte in der Dokumentgrammatik zu be-schreiben, so dass diese bei der weiteren Verarbeitung eines Dokuments be-rücksichtigt werden können. Ein Gedicht hat einen anderen Aufbau als einwissenschaftliches Papier, und dieser schlägt sich z. B. im Textdesign oder inder Terminologie (Überschrift, Abstract, Einleitung, Literaturliste gegenüberTitel, Strophe, Vers) nieder.

In den einzelnen Phasen des „Lebenszyklus“ von Dokumenten erweistsich die Verfügbarkeit einer Dokumentgrammatik in der folgenden Weiseals nützlich:

1 Ist lediglich die Liste der Elemente eines Dokumenttyps gemeint, so spricht man auch von„Tagsets“ oder „Vokabularien“.

54 Henning Lobin

• Produktion: Während der inkrementellen Produktion eines Dokumentsverfolgen Editoren den Aufbau der Baumstruktur und gleichen ihn mitder Dokumentgrammatik ab. Es kann angegeben werden, welche Ele-mente an einer bestimmten Stelle strukturell eingefügt werden können,und falsche Elementeinfügungen können von vornherein verhindert wer-den.

• Validierung: Ein vorliegendes Dokument wird dahingehend überprüft,ob seine Baumstruktur sich mit den in der Grammatik enthaltenen Re-geln ableiten lässt, die Baumstruktur des Dokuments also konform zurGrammatik ist.

• Retrieval: Das Auffinden von Informationen in Dokumenten kann durchGrammatiken unterstützt werden. Soll beispielsweise ein Textelement„Überschrift“ mit einem bestimmten Stichwort gesucht werden, kann dieSuche auf solche Abschnitte des Dokuments beschränkt werden, in de-nen ein Element „Überschrift“ überhaupt nur vorkommen kann.

• Textparsing: Soll ein nicht explizit strukturiertes Dokument maschinellanalysiert werden, spricht man auch von Textparsing. Eine schwäche-re Form des Textparsing bildet die Textkategorisierung, bei der es umdie Zuordnung zu bestimmten Text- oder Dokumenttypen geht. In bei-den Fällen können die beteiligten Prozesse durch Dokumentgrammati-ken eingegrenzt und gesteuert werden. Wenn beispielsweise in der Do-kumentgrammatik definiert ist, dass nach dem Autorennamen nur einAbstract oder eine Überschrift erscheinen kann, können Erkennungsrou-tinen aktiviert werden, die Abstracts von Überschriften zu unterschei-den erlauben. Die Dokumentgrammatik enthält in diesem Fall Hypo-thesen über den Aufbau des Dokuments, durch die der Suchraum für dieParsing- und Kategorisierungsprozesse eingeschränkt wird.

Wenn eine wesentliche Neuerung XML-basierter Informationsmodellie-rung darin besteht, normierte Dokumente mit Baumstrukturen zu verwen-den, so wird es wichtig, von vornherein abschätzen zu können, mit wasfür Arten von Bäumen in einem bestimmten Anwendungsbereich gerech-net werden kann. Für die Definition baumartiger Dokumentstrukturen gibtes verschiedene Möglichkeiten. Bäume können zum einen in ihrem Aufbaudurch Regeln beschrieben werden. Die Regeln bilden zusammengenommeneine Grammatik. Da, anders als in der natürlichen Sprache, die beschriebe-nen Dokumentstrukturen in ihren Tags weiterhin die Baumstruktur eindeu-tig beschreiben, spricht man in diesem Fall auch von Baumgrammatiken.Bei diesem Ansatz steht die Idee Pate, dass man komplexe Gebilde durcheine Grammatik konstruktiv beschreibt, also ein Verfahren angibt, wie alle


zulässigen Dokumentstrukturen mit Hilfe der Grammatik gebildet werdenkönnen.

Eine zweite Möglichkeit besteht darin, Bedingungen anzugeben, deneneine Klasse von Dokumenten unterliegen soll. Grundlage dieses Ansatzes bil-det die Vorstellung, dass bestimmte Eigenschaften gefordert werden, die Do-kumente aufweisen sollen, dass aber nicht die komplette Struktur definiertwird wie durch eine Grammatik. Anders als beim regelbasierten Ansatz kön-nen Bedingungen über Baumstrukturen völlig frei definiert werden, da Re-geln immer auf die Zusammenhänge innerhalb eines Teilbaums beschränktbleiben müssen. Werden so viele Bedingungen aufgestellt, dass jeder Aspektdes Dokuments spezifiziert wird, kann man natürlich auch von einer Gram-matik sprechen. Gleichwohl ist einem auf Bedingungen basierenden Ansatzeine gewisse Liberalität bei den zu beschreibenden Strukturen inhärent.

Die dritte Möglichkeit bildet zugleich die einfachste und naheliegendste,nämlich die Spezifikation mittels Beispieldokumenten. Man kann dieses alseinen Sonderfall des regel- oder bedingungsbasierten Ansatzes verstehen, al-lerdings gibt es auch hier interessante Aspekte, die diesen Ansatz von denanderen unterscheidet.

3 Baumgrammatiken und Schemasprachen

3.1 Mächtigkeit und Varianten von Baumgrammatiken

In der Theorie der formalen Sprachen werden Grammatiken eingesetzt, umMengen von Zeichenketten zu definieren. Eine solche Menge wird eine Spra-che genannt. Wenn es umgekehrt gelingt, ein Regelwerk zu finden, das einebestimmte Menge von Zeichenketten erzeugen kann, spricht man von einerGrammatik für diese Sprache. Die für diesen Zweck in der Grammatik ge-nutzten Regeln werden als Produktionsregeln bezeichnet (vgl. z. B. Carstensenet al., 2001).

Eine ähnliche Situation liegt vor, wenn Baumstrukturen erzeugt werdensollen. Eine Menge von Baumstrukturen heißt eine reguläre Baumsprache,eine Grammatik, die diese Baumsprache generiert, eine reguläre Baumgram-matik. Da die in SGML und XML verwendeten Baumgrammatikregeln wiedie Regeln einer kontextfreien Grammatik aussehen, ist der Umstand, dassdamit eine andere Art von Sprache generiert wird, oft übersehen worden.

56 Henning Lobin

Sehen wir uns dazu ein Beispiel an. In (1) ist ein Symbol dargestellt, dasin die Zeichenkette „ab“ überführt wird:

A → ab (1)

Auf der rechten Seite der Regel können auch Symbole erscheinen, die inanderen Regeln auf der linken Seite verwendet werden (non-terminale Sym-bole):

A → AB (2)

A → C

B → BB

B → C

B → x

C → ∅

Diese Grammatik erlaubt die schrittweise Ableitung z. B. der folgenden Zei-chenkette:

A (3)

AB

CBB

∅xx

Durch die Anwendung der Regel einer Baumgrammatik dagegen wird nichtnur eine Zeichenkette gebildet, sondern auch eine Baumstruktur aufgebaut.In XML-Notation lässt sich das folgendermaßen darstellen:

A → �� ab � � � � (4)

Gewöhnlich wird A als Elementtyp bezeichnet, �� als Anfangstag, � � � � alsEndtag und „ab“ als Inhaltsmodell. Werden auf der rechten Regelseite non-terminale Symbole verwendet, führt die wiederholte Anwendung der Regelnzu einer Verschachtelung der Tags und somit zu einer Baumstruktur. Einereguläre Baumgrammatik mit der gleichen Regelstruktur wie die kontextfreieGrammatik (1) sieht folgendermaßen aus:


1. A → �� AB � � � � (5)

2. A → �� C � � � �

3. B → �� BB � � � �

4. B → �� C � � � �

5. B → �� x � � � �

6. C → �� ∅ � � � �

Für Elemente, deren Inhaltsmodell leer bleibt, so dass zwischen dem An-fangs- und dem Endtag nur der leere String stehen kann, wird in XML einebesondere Notation verwendet:

6′. C → �� (6)

Mit (5) und (6) lässt sich somit das folgende ‘Dokument’ ableiten:

�� AB � � � � (7)

�� C � � � � B � � � � (nach Regel 2)

�� C � � � � �� BB � � � � � � � � (nach Regel 3)

�� BB � � � � � � � � (nach Regel 6′)

�� x � � � � B � � � � � � � � (nach Regel 5)

�� x � � � � �� x � � � � � � � � � � � � (nach Regel 5)

Die eingerückte Darstellung lässt die Baumstruktur besser erkennen:

�� (8)

��

��

� � � �

��

�� x � � � �

�� x � � � �

� � � �

� � � �

Die in (5) und (6) dargestellte Grammatik enthält ausschließlich Regeln, beidenen das auf der linken Seite erscheinende Symbol zugleich den Tagnamenbildet. Diese Beschränkung ist nicht notwendig – auf der linken Regelseite

58 Henning Lobin

können durchaus Symbole verwendet werden, die mit anders bezeichnetenTags kombiniert werden. In (9) etwa werden in Regel 3 die Symbole B1und B2 eingeführt, die in den Regeln 4 und 5 beide mit dem Tag �� ver-bunden werden:

1. A → �� AB � � � � (9)

2. A → �� C � � � �

3. B → �� B1B2 � � � �

4. B1 → �� C � � � �

5. B2 → �� x � � � �

6. C → ��

Mit dieser Grammatik lässt sich der Baum

�� x � � � � � � � � � � � � (10)

ableiten, nicht aber der Baum (11):

* �� x � � � � �� x � � � � � � � � � � � � (11)

Auf diese Weise ist es möglich, für ein und dasselbe Tag – hier �� – Ausprä-gungen zu definieren, da für jede dieser Ausprägungen ein anderes abstraktesSymbol in einer Regel verwendet werden kann – hier B1 und B2. Die bis-her verwendeten Schema-Sprachen machen in unterschiedlichem Maße vondieser Möglichkeit Gebrauch.

3.2 Das traditionelle Konzept in SGML und XML: DTDs

Sowohl XML als auch sein Vorläuferstandard SGML definieren nicht nur,wie die Baumstruktur eines Dokuments formal zu notieren ist, beide Stan-dards beinhalten auch eine Sprache zur Definition einer eingeschränkten re-gulären Baumsprache. Die Einschränkung besteht darin, dass in den Regelnder Grammatik keine abstrakten Symbole gebraucht werden dürfen, folglichdurch jedes Symbol, das auf der linken Seite einer Regel erscheint, zugleichauch die Bezeichnung der Tags auf der rechten Regelseite festgelegt wird.Nach Murata et al. (2000) wird diese Einschränkung regulärer Baumgram-matiken als Local Tree Grammar bezeichnet.

Zusätzlich existieren in beiden Standards verschiedene Variablen, die fürbeliebige Dateninhalte stehen. Die wichtigste dieser Variablen ist �

� �� ,die zur Markierung beliebiger Elementinhalte verwendet werden kann. Se-hen wir uns eine leicht modifizierte Beispielgrammatik an:


1. A → �� BBCD � � � � (12)

2. A → ��

3. B → �� C � � ��

4. C → �� a � � � �

5. C → �� b � � � �

6. D → � � � �

Eine Umsetzung dieser Grammatik in die Notation einer SGML-DTD (Do-cument Type Definition) kann folgendermaßen aussehen:

1. � �� (13)

2. � � �� & ��

3. � ��

4. � � �� & ��

5. � ��

Da in DTDs non-terminale Symbole das verwendete Tag eindeutig deter-minieren, wird auf die explizite Definition des Tags in einer Element-Regelverzichtet, weshalb sie von einer kontextfreien Grammatikregel auf den ers-ten Blick nicht zu unterscheiden ist.

Zwei Besonderheiten bedürfen näherer Erläuterung: Während Regeln,die durch � �� eingeleitet werden, Inhaltsmodelle (rechte Regelteile)aufweisen, die aus non-terminalen Symbolen oder der Variablen � � �� bestehen, ist eine durch � � � �� (Attributliste) eingeleitete Regel für sol-che Fälle vorgesehen, in denen auf der rechten Seite nur terminale Symboleerscheinen. Derartige Regeln werden in einer sog. Attribut-Definition zu-sammengefasst. Im annotierten Dokument erscheinen diese Symbole inner-halb des Anfangstags des umgebenden Elements:

(14)�� & � �

�� beliebiger Text � � � �

�� & � � ebenfalls beliebiger Text � � � �

��

� � � �

Den Sinn von Attributen kann man sich am besten in dieser Form ver-ständlich machen. Sie werden gewöhnlich verwendet, um variable Zusatz-und Metainformationen zu kodieren. Die Tatsache, dass in der DTD im-mer eindeutig festgelegt sein muss, ob eine Information als Elementinhalt

60 Henning Lobin

oder als Attributwert kodiert wird, bildet faktisch eine Reihe weiterer for-maler Restriktionen der als DTD kodierbaren Baumgrammatiken, die hiernicht weiter diskutiert werden sollen. Grundsätzlich gilt aber, dass Element-Deklarationen und Attribut-Definitionen nicht miteinander ‘vermischt’ wer-den dürfen, Attribut-Definitionen dürfen aber bei einem Element kumuliertwerden. Auch die Reihenfolge der Attribute untereinander gilt als undefi-niert, ebenso wie das sequenzielle Verhältnis gegenüber dem Elementinhalt.Ein mit �

� � � �� qualifiziertes Attribut kann in einem Anfangstag auch

ausgelassen werden.Die zweite Besonderheit von DTDs besteht darin, dass es für einen Ele-

menttyp nicht mehrere Deklarationen geben darf. Konkurrierende Regelnmüssen deshalb wie in Regel 1. durch eine Oder-Konstruktion vereinigt wer-den. Grundsätzlich können im rechten Regelteil, dem Inhaltsmodell, regu-läre Ausdrücke erscheinen, sofern diese lediglich durch Klammerung, denOder-Konnektor

, den Sequenzkonnektor � sowie den Iterationskonnekto-

ren � (null- oder einmal), � (beliebig oft) und�

(nullmal oder beliebig oft)gebildet sind.

In (13) ist in Regel 1 auch ein Beispiel für einen der Unterschiede zwi-schen SGML und XML enthalten. Während es in SGML grundsätzlich kei-ne Beschränkungen gibt, wie die Variable �

� �� in einem Inhaltsmodellverwendet werden darf, ist für XML aus Gründen der Verarbeitungseffizienzfestgelegt worden, dass �

� �� nur allein im Inhaltsmodell oder als Teileiner iterierten Oder-Gruppe erscheinen darf. In XML wäre diese DTD alsofolgendermaßen umzuformulieren:

1. <!� � �� (#

� � � � � � | � ) ∗> (15)

2.–4. wie in (13)

Damit werden zwar die gleichen Konstruktionen wie in (13) zugelassen, da-rüber hinaus allerdings auch eine Vielzahl weiterer Kombinationen von B-Element und � � � � �� .

SGML- und XML-DTDs sind ein einfacher Formalismus zur Definitionlokaler Baumgrammatiken, der wegen des langen Fehlens mächtigerer Alter-nativen sehr weit verbreitet ist.


3.3 Schemasprachen

Idee

Das Aufkommen von Schemasprachen mit dem Ziel der Ersetzung vonDTDs seit Mitte der neunziger Jahre ist auf drei Anforderungen zurück-zuführen, die DTDs nicht erfüllen können:

1. XML-Notation: Da DTDs in einer proprietären Notation kodiert wer-den, können sie nicht selbst zum Gegenstand von XML-basierten Ver-arbeitungstechniken gemacht werden. Alle Schemasprachen verwenden,anders als DTDs, eine XML-Notation, so dass es möglich wird, Schema-ta mit dem gleichen Instrumentarium zu bearbeiten wie andere XML-Dokumente auch.

2. Reichhaltigere Datentypen: DTDs verfügen nur über ein sehr beschränk-tes Inventar vordefinierter Datentypen. Die Definition neuer Datenty-pen ist mühsam und unflexibel. In vielen Schemasprachen wird dagegenein Inventar an Datentypen angenommen, das sich an den Möglichkei-ten moderner Programmiersprachen orientiert und leicht erweitert wer-den kann.

3. Mächtigere Strukturdefinitionen: Neuere Arbeiten zur Äquivalenz vonXML und regulären Baumsprachen (vgl. z. B. Murata et al., 2000) habengezeigt, dass mit DTDs nur eine sehr eingeschränkte Variante einer re-gulären Baumgrammatik realisiert wird. Mächtigere Varianten erlaubenes, Inhaltsmodelle kontextabhängig zu spezifizieren – eine Anforderung,die oft in praktischen Strukturierungszusammenhängen besteht.

Nachdem über längere Zeit verschiedene Entwürfe von Schemasprachenparallel zueinander verfolgt wurden (vgl. Lee und Chu, 2000), liegt mitXML Schema seit 2001 eine W3C-Empfehlung vor, die mittlerweile von vie-len Software-Systemen alternativ zu DTDs unterstützt wird. Eine radikalereVariante stellt RELAX NG dar, die im Folgenden als zweite Schemasprachedargestellt werden soll.2

XML Schema

Die Deklaration des Elements A nach den Regeln 1 bis 4 in (15) kann inXML Schema folgendermaßen aussehen (siehe z. B. Cagle et al., 2001):

2 Weitere Schemasprachen sind etwa XDR, SOX, DSD, TREX oder XDuce.

62 Henning Lobin

(16)� � ' �� & � ��

� ��$�� ' � � � �� ( ��#� � � ��%��

� ��$�(�� (��% � �� & ��%�� $��

� � ' �� %��" � � � ��

� ��$�(��

� & ��%�(� �� & � ��

� ��( �� ' � � ��

� %��%�(��(�$�� & �#� � � ��

� ��% & ��(�$�� &�' �� & ��

� ��% & ��(�$�� &�' ��

� ��%��%�(��(�$��

� ��( �� ' � � ��

� � & ��%�(� ��

� ��$�� ' ��

� �� ' ��

Ein Inhaltsmodell, der rechte Teil einer Regel, wird in XML Schema alsdas Element

��$�� ' � � � ��modelliert. Die Tatsache, dass es sich dabei in

diesem Fall um ein gemischtes Inhaltsmodell handelt, wird explizit durch� ( �� %�� vermerkt. Der Häufigkeitsindikator wird in (16) durch die

Attribute� (��% � ��

und� & ��% � � � �� $��#��

ausgedrückt, hierkönnen außerdem beliebige Zahlenwerte eingetragen werden. Innerhalb der��$�(��

-Konstruktion wird über das Konstrukt � � ' �� %��#" � � � �� aufdie Deklaration des Elements B verwiesen. Dabei muss es sich innerhalb desSchema-Dokuments um ein global deklariertes Element handeln. In ähnli-cher Weise wie Elemente werden auch Attribute deklariert: Das Attribut C

wird durch das Element��( �� ' � � ��

definiert, bei dem es darum geht, einender vordefinierten Datentypen – hier

��

��– zu nutzen oder abzuwan-

deln. In diesem Fall wird über eine%��%�(��(�$��

-Konstruktion die Mengeder möglichen Werte des Typs

��

��auf die zwei Werte a und b einge-

schränkt.Während (16) im Wesentlichen die DTD-Syntax in XML nachzeichnet,

geht eine alternative Umsetzung über die Möglichkeiten von DTDs hinaus.Dabei wird das Element B nicht als ein globales Element deklariert, sondernals ein lokales. Sein Inhaltsmodell ist dabei nur für den vorliegenden Kontext– hier innerhalb des Elements A – in der angegebenen Weise definiert, inanderen Kontexten kann dagegen für B ein beliebiges anderes Inhaltsmodelldefiniert werden:


(17)��

� ��$�(�� (��%�� & ��% � �� $��#��

<xs:element name="B" type="string">

� ��$�(��

Die konsequente Verwendung lokaler Element-Deklarationen führt dazu,dass die Struktur von Dokumenten durch Schemata beschrieben werdenkann, die schon recht deutliche Ähnlichkeit mit dem spezifizierten Doku-ment aufweisen. Ein solches Schema kann als eine schematische Definitionim engeren Sinne aufgefasst werden, also als ein Dokumentmuster, das esnoch zu konkretisieren gilt.

Mit der Formulierbarkeit kontextabhängiger Inhaltsmodelle geht XML-Schema über die Mächtigkeit von DTDs hinaus – allerdings nur ein wenig:Wie in DTDs muss der Grundsatz eingehalten werden, dass ein Schemakeine Ambiguitäten beinhalten darf. Damit ist gemeint, dass bei der Anwen-dung eines Schemas auf ein Dokument immer eindeutig bestimmbar seinmuss, welcher Teil des Inhaltsmodells zu beachten ist. Damit sind Deklara-tionen wie die folgende ausgeschlossen:

(18)� � ' �� & � ��

� ��$�� ' � � � ��

� ��$�(��

<element name="B">

(Inhaltsmodell 1)� �� ' ��

<element name="B">

(Inhaltsmodell 2)� �� ' ��

� ��$�(��

� ��$�� ' ��

� �� ' ��

Da in XML Schema also die unterschiedlich definierten Elemente gleichenNamens nicht innerhalb eines Inhaltsmodells miteinander in Konkurrenzstehen dürfen, wird diese Variante einer regulären Baumgrammatik von Mu-rata et al. (2000) als single-type tree grammar bezeichnet.

64 Henning Lobin

RELAX NG

(19)� � ' �� & � ��

� ��$�(��

<ref name="B1"/>

<ref name="B2"/>

� ��$�(��

� �� ' ��

� ��#" (�� & �� B1

� �

� � ' �� & �� B��

� %��" � & � ��

� �� ' ��

� ��"�(��

� ��#" (�� & �� B2

� �

� � ' �� & �� B��

� %��" � & � ��

� �� ' ��

� ��"�(��

Mit der Spezifikation von RELAX NG wurde versucht, die volle Mächtigkeitregulärer Baumgrammatiken für die Auszeichnung von Texten nutzbar zumachen. Das in (18) dargestellte Problem lässt sich in RELAX NG wie in(19) dargestellt lösen: Die Markierung der Elemente durch Tags ist hier – wiegenerell in regulären Baumgrammatiken – entkoppelt von der Bezeichnungder Kategorien. Die Deklaration für B1 und B2 lassen sich somit auch in dietraditionelle Notation umsetzen:

A → �� B1 � � � � (20)

A → �� B2 � � � �

B1 → �� C � � � �

B2 → �� D � � � �

Eine weitere Konsequenz aus der kompromisslosen Umsetzung einer regulä-ren Baumgrammatik in das XML-Format besteht darin, in Inhaltsmodellendie Auswahl zwischen Element- und Attribut-Konstruktionen zuzulassen. Inder folgenden Grammatik wird das Element A entweder durch mit B mar-kierten beliebigen Text ausgeprägt oder durch die beim Attribut C erschei-nenden Werte a oder b:


(21)� � ' �� & � ��

� ��$�(��

<element name="B">

� ��

� �� ' ��

<attribute name="C">

� ��$�(��

� � &�' �� & � � � &�' ��

� � &�' �� &�' ��

� ��$�(��

� � & ��%�(� ��

� ��$�(��

� �� ' ��

Trotz der einfacheren Notation bildet RELAX NG gegenüber XML Sche-ma den mächtigeren Typus einer Schemasprache. Dieses wirkt sich auf diedefinierbaren Kontextabhängigkeiten aus, die sich auch auf Attributwerteerstrecken können, betrifft aber auch die Kombination mehrerer Grammati-ken, die nur dann miteinander vereinigt, geschnitten oder voneinander abge-zogen werden können, wenn man sich im Bereich voll ausgeprägter regulärerBaumgrammatiken bewegt. Für all dieses weist RELAX NG bestimmte syn-taktische Konstruktionen auf, deren Darstellung hier zu weit führen würde.

4 Typenhierarchie, Metastrukturen und Constraints

Neben der Mächtigkeit der verwendeten Grammatikvariante fallen bei derBewertung von Schemasprachen aber auch andere Eigenschaften ins Ge-wicht. Zwei davon sollen in diesem Abschnitt besprochen werden: die Idee,Dokumentgrammatiken ähnlich wie Programme objektorientiert aufzubau-en, und die Möglichkeit, beliebige Restriktionen von Dokumenten durchConstraints zu definieren.

4.1 Elemente als Objekte

Das Typenkonzept von XML Schema

Obwohl es bei der Spezifikation von Dokumentgrammatiken in SGML undXML immer um die Definition der Zusammenhänge zwischen Informati-

66 Henning Lobin

onseinheiten geht, letztlich also eine datenorientierte Perspektive eingenom-men wird, wird das dafür besonders geeignete Konzept der Objektorientie-rung erst in XML Schema systematisch integriert.

Bei der objektorientierten Programmierung stehen nicht die Abläufe,sondern die Daten im Mittelpunkt. Datentypen werden zu Klassen zusam-mengefasst, diese durch Eigenschaften beschrieben und mit Prozeduren undFunktionen (Methoden) versehen. Klassen können hierarchisch angeordnetwerden, dabei werden Eigenschaften und Methoden übergeordneter Klassenauf untergeordnete vererbt, die untergeordneten Klassen spezifizieren gleich-zeitig die übergeordneten. Klassen können aber auch in einer Teil-Ganzes-oder einer Abhängigkeitsrelation zueinander stehen. Die Klassen werden beieiner Verwendung des Programms durch Objekte, die realen Daten entspre-chen, instanziiert.

Grundsätzlich besteht zwischen jeder Deklaration eines Elements in ei-ner Schemasprache und dem durch Tags markierten Auftreten eines Ele-ments in einem Dokument eine Instanziierungsbeziehung wie die zwi-schen Klasse und Objekt, weshalb von Element-Deklarationen, genauer auchvon Elementtyp-Deklarationen, gesprochen wird. In XML Schema werdenElementtypen zusätzlich jedoch wie Klassen in einen hierarchischen Zu-sammenhang gebracht. Übergeordnete Klassen werden durch ein Element��$�� ' � � � ��

definiert, aus denen durch das Element� ' ��

solche Klas-sen abgeleitet werden, die sich in Dokumenten als Objekte, also konkreteElemente, instanziieren lassen.

Im folgenden Beispiel wird zunächst der Typ & ��%�� deklariert, da-nach ein Elementtyp & ��%��

:

(22)� ��$�� ' � � � �� & �� & ��%��

� �� #��

� � ' �� & �� % & ��#� � � ��%�(��

� � ' �� & �� & � ��#��% � � ��

� � ' �� & �� $�� ' ��(��! & � ' � ��(��% ��

� � ' �� & �� & �� %�(��

� ��#��

� & ��%�(� �� & �� & ��#� � � �� & ��

� ��$�� ' ��

� � ' �� & � �� & �#%�� & ��%��


Ein Elementtyp kann aber auch durch Erweiterung oder Einschränkungaus einem komplexen Typ hervorgehen:

(23)� � ' �� & � �� & �#%�� (�� '�& ��

� ��$�� ' � � � ��

� ��$�� ' � � � $��

<extension base="adressTyp">

<sequence>

<element name="land" type="string"/>

</sequence>

</extension>

� ��$�� ' �� $��

� ��$�� ' ��

� �� ' ��

In diesem Fall wird durch den Wert des Attributs & �#� in der

� �� (�$��-

Konstruktion auf den Basistyp verwiesen. Das darin definierte Inhaltsmo-dell wird dem Inhaltsmodell des Basistyps sequenziell angehängt. Im Doku-ment muss somit beim Element & �#%�� (�� '�& �� die Sequenz der Elemen-te

��% & ��,� & � �� %

,��$�� ' ��(��! & � ' und '�& �� erscheinen. Zusätzlich

wird dem Element & �#%��#�� (�� '�& �� aus seinem Basistyp das Attribut� & ��#�

vererbt. Die Deklaration des komplexen Typs geschieht in (23) ohne eine ex-plizite Benennung des entstehenden Typs, weshalb eine derartige Konstruk-tion auch eine anonyme Typ-Definition genannt wird.

Eine Reihe von Kontrollattributen erlaubt es dem Schema-Designer, dieAbleitung aus komplexen Typen feiner zu steuern. So kann etwa festgelegtwerden, dass aus einem komplexen Typ nicht unmittelbar ein Elementtypabgeleitet werden kann oder, im Gegenteil, genau dieses der Fall sein muss.

Bei der Ableitung aus einem komplexen Typ wird, wie wir gesehen haben,das Inhaltsmodell und die Menge der Attribute vererbt. Durch Erweiterungoder Einschränkung kann diese Information modifiziert werden. Hinsicht-lich des Inhaltsmodells ist es natürlich durchaus denkbar, auch interessantereErweiterungsformen zuzulassen als lediglich das Anhängen weiterer Elemen-te. Da dieses jedoch die Vergrößerung der syntaktischen Komplexität mitsich gebracht hätte, wurde bei der Entwicklung von XML Schema bewusstdarauf verzichtet.

Explizit nicht zu den Eigenschaften eines komplexen Typs gehört seinerelative Stellung gegenüber anderen Elementen. Das hat zur Folge, dass die

68 Henning Lobin

Verwendung eines Verweises auf einen komplexen Typ in einem Inhaltsmo-dell verboten ist:

(24)� �� #��

� � ' �� & � � � � ��%��$�� & � � � � �� & � ��

<complexType ref="adressTyp"/>

� ��#��

Sinnvoll könnte eine derartige Verwendungsweise durchaus sein: An alle aus& ��%��

��

abgeleiteten Typen könnte die Verwendung vererbt werden, fürabgeleitete Typen könnten darüber hinaus spezielle Verwendungsweisen de-finiert werden.

Weitere Möglichkeiten der objektorientierten Schema-Spezifikation

Als ein wichtiger Vorläufer der Objektorientierung bei XML kann das Kon-zept der Architektur oder Meta-DTD bei SGML angesehen werden. DiesesKonzept ist einerseits konsequenter, andererseits schwächer als das in XMLSchema realisierte. Eine Meta-DTD ist eine gewöhnliche DTD, die durcheinige spezielle Deklarationen einer anderen DTD, der Client-DTD, über-geordnet wird. Die Elementtypen der Client-DTD werden über Kontrollat-tribute Elementtypen der Meta-DTD zugeordnet. Für unser Beispiel könntedas etwa folgendermaßen aussehen:

(25)Meta-DTD: � �� & ��%�� % & �� & � ��#�� % � �� $�� ' ��(��! & � ' � �� & ��

Client-DTD: � �� & �#%�� (�� '�& �� % & ��#� �� & � ��#�� % ��$�� ' ��(��! & � '�� & �� '�& ��

� � � �� & �#%��#�� (�� '�& �� & � � � & ��%��

Da in der Client-DTD auch bei einer Erweiterung das Inhaltsmodell voll-ständig definiert werden muss, ist dieser Ansatz allgemeiner als das Typen-konzept in XML Schema. Der Nachteil dieses Verfahrens liegt darin, dass


in der Standardisierung von Architekturen versäumt worden ist, neben derNotation der Zuordnung auch Vererbungsprozesse zu berücksichtigen. DieNotwendigkeit, alle Vererbungsvorgänge ‘per Hand’ in die DTDs einzutra-gen, und die fehlenden Richtlinien zur Validierung der architektonischenZuordnung haben dazu beigetragen, dass diese Technik nicht aus ihrem Ni-schendasein herausfinden konnte.

Andere Überlegungen gehen dahin, die objektorientierten Strukturen ei-ner Dokumentgrammatik gleich in einem Formalismus zu erfassen, der vor-rangig für diesen Zweck entwickelt worden ist. In XML Schema werdennach dieser Auffassung syntaktische Aspekte – die Anordnung der Elemen-te zu Bäumen – und semantische – die inhaltlichen Bezüge der einzelnenDatentypen zueinander – miteinander vermischt. Eine Entflechtung bestehtdarin, im Schema nur die syntaktischen Aspekte zu behandeln und die se-mantischen, objektorientierten Aspekte in einer Spezialsprache wie der Uni-fied Modeling Language (UML, vgl. Kimber und Heintz, 2000) oder durchEntity-Relationship-Modelle (Mani et al., 2001). UML ist eine grafischeSprache zur Definition der Bezüge zwischen Klassen, sie hat trotz der Ähn-lichkeit im Namen nichts mit XML gemein. Wegen der Komplementari-tät dieser beiden Sprachen wird für die Entwicklung großer Schemata eineKombination der jeweiligen Modellierungsverfahren empfohlen.

4.2 Constraints und Beispieldokumente

Wir haben in Abschnitt 3.1 gesehen, wie baumartig repräsentierte Informa-tion durch Grammatiken beschrieben werden kann. Die dabei verwendetenSchema-Sprachen verfolgen generell den Ansatz, die Menge der möglichenDokumente vollständig zu beschreiben. Ein grundlegend anderer Ansatz be-steht darin, einzelne Zusammenhänge der in dem Baum enthaltenen Datengezielt zu spezifizieren. Dieses kann alternativ zu einer grammatischen De-finition erfolgen oder parallel dazu. Die grammatische Definition ist auchin der voll ausgeprägten Version einer regulären Baumgrammatik im Fallevon RELAX NG auf die Spezifikation lokaler Abhängigkeiten von Elemen-ten und Attributen untereinander beschränkt. Die Spezifikation von Abhän-gigkeiten beliebig weit voneinander entfernt erscheinender Informationsein-heiten erfordert dagegen einen Formalismus, der weit über die Mächtigkeitregulärer Baumgrammatiken hinausgeht. Da es unsinnig ist, mögliche Do-kumente mit einem solchen Formalismus vollständig beschreiben zu wollen,werden derartige Abhängigkeiten eher als Constraints über den Baumstruk-turen interpretiert, deren Einhaltung zu überprüfen ist.

70 Henning Lobin

Die ausschließliche Nutzung von Constraints macht es erforderlich,strukturierte Dokumente entweder ganz ohne grammatische Definitionenzu verwenden – dieses ist in XML mit dem Konzept der wohlgeformten Do-kumente angelegt, in SGML aber verboten – oder einzelne Inhaltsmodellein einer Dokumentgrammatik undefiniert zu lassen und so sämtliche Unter-strukturen zuzulassen. Dieses ist sowohl in XML als auch in SGML möglichdurch die Variable �

�� , die als Inhaltsmodell erscheinen kann.

Schematron

Eine ausgereifte Konvention zur Spezifikation von Constraints über XML-Dokumenten ist Schematron (Jelliffe, 2000). Nehmen wir an, ein XML-Dokument enthält die folgende Information:

(26)� �� '�' ��

� ��%�$�� & ��(��% & �� & % & � � � �� %�$��

� ��%��(�� & ��%�� EUR � �� %��(#��

� & ��%��

� ��% & �� $��% &�� % & ��#� �

� ��% �� % �

� � ' ! �� ' ! �

� �� & �#� ��(�� & �#� �

� '�& �� '�& �� '�& ��

� � & �#%��#� �

� �� '�' ��

Für dieses Dokument soll der Constraint formuliert werden, dass die Wäh-rung

�� nur im Zusammenhang mit dem Land � �� '�& �� in der Lie-

feradresse erscheinen darf, die Währungsbezeichnung �#%

dagegen nur beimZielland

��(!. Es ist nicht möglich, diesen Zusammenhang in einer der

bisher dargestellten Schema-Sprachen auszudrücken.Zwei Schematron-Regeln, die diesen Constraint implementieren, sehen

folgendermaßen aus:


(27)� %�� ' � ��$�� %��(#�#�� & ��%��

� & ��#��%�� '�' �� & ��%�� '�& �� '�& ��

� � & �� (�� #%��(�� (�� %�$ � & %�" ��% "��% ��(��

� �� '�' �� (�� %�$ � ��%�� & �� (��#�� #��(��

� � & ��%��

� ��%�� ' � �

� %�� ' � ��$�� %��(#�#�� & ��%�� %��

� & ��#��%�� '�' �� & ��%�� '�& �� #��(�!��

� � & �� (�� #%��(�� (�� % & � �� & %�" ��% "��% ��(��

� �� '�' �� (�� (�� #��(�! & �� (��#�� #��(��

� � & ��%��

� ��%�� ' � �

Jede Schematron-Regel wird durch das Element%�� ' � kodiert, das als Wert

des Attributs��$��

einen XPath-Ausdruck enthält, durch den der An-wendungskontext der Regel spezifiziert wird. In diesem Fall handelt es sichum das Attribut

& ��%�� beim Element��%��(#�

, sofern es den Wert��

bzw. �#%

aufweist.Die Auswertung derartiger Regeln, die zu einem Schematron-Schema zu-

sammengefasst werden, erfolgt in zwei Schritten. Zunächst wird aus demSchematron-Schema durch eine für alle derartigen Schemata gültige Trans-formation ein XSLT-Skript abgeleitet, dieses ist dann auf das zu überprüfen-de XML-Dokument anzuwenden. Für beide Schritte kann ein gewöhnlicherXSLT-Prozessor verwendet werden. Die Ausgabe des zweiten Transformati-onsprozesses ist ein Validation Report, in dem insbesondere Fehlermeldun-gen für diejenigen Constraints enthalten sind, deren Nicht-Einhaltung beider Validierung festgestellt worden ist. Die Fehlermeldungen werden nichtschematisch generiert, sondern unterliegen ebenfalls der Ausformung durchden Entwickler des Schematron-Schemas als Inhalt des Elements & ��%�� .Für die erste Regel in (27) würde etwa die folgende Fehlermeldung generiertwerden:

(28)��%��(#�#� & ��%�� (�� %��(#� (�� %�$ � & %�" ��% "��%��(�� '�' �� (�� %�$ � ��%�� & �� (��#�� #��(��

Eine Reihe weiterer Elemente erlauben es, Schematron-Schemata zu ent-wickeln, durch die sehr komplexe Überprüfungen von Dokumenten vor-

72 Henning Lobin

genommen werden können in Abhängigkeit vom gegenwärtigen Stand desWorkflows.

Aus einer linguistischen Perspektive können derartige Constraint-Systemeverstanden werden als eine Ebene oberhalb der hierarchischen Dokument-struktur, durch die „Long Distance Dependencies“ ausgedrückt und ‘lexika-lische’ Einflüsse auf die Baumstruktur (analog z. B. zum Konzept der Verb-valenz in der Sprache) beschrieben werden können.

Wegen der orthogonalen Konzeption von Schematron und XML Sche-ma hinsichtlich der Spezifikation von Dokumentstrukturen ist es nahelie-gend, beide Ansätze miteinander zu verbinden. Dieses ist auch recht einfachmöglich, da XML Schema bei jeder Element-Deklaration in einem Element& ��$�� & ��(�$��

Meta-Informationen zu kodieren erlaubt. Die Schematron-Regeln, die für das definierte Element gelten sollen, können im Element& ��(��"�$

aufgeführt werden, vgl. (29). Aus dieser integrierten Repräsentati-on beider Schematypen lässt sich durch einen vorgelagerten Transformati-onsschritt das Schematron-Schema extrahieren.

(29)� � � � � ' �� & � �� %��(#� ��

� � � � & ��$�� & ��(�$��

� � � � & ��(��"�$ �

� �� %�� ' � ��$�� %��(#�#�� & ��%��

� �� & ��%�� '�' �� & �#%�� '�& �� '�& ��

� �� & � �� (�� #%��(#� (�� %�$ � & %�" ��% "��%��(�� '�' �� (�� %�$ � ��%�� & �� (��#�� #��(��

� �� & ��#��%��

� �� %�� ' � �

� � � � � & ��(��"�$ �

� � �� & ��$�� & ��(�$��

� � � � ��$�� ' ��

� � �� $�� ' � � � ��

� � �� ' ��

Beispielbasierte Dokumentspezifikation

Ein anderer Ansatz, Mengen von Dokumenten durch Constraints zu be-schreiben, besteht in der Verwendung von Beispieldokumenten. Bereits vorder Definition von XML stand mit Fred für SGML ein Tool zur Verfügung,das in der Lage war, aus einem Beispieldokument eine DTD abzuleiten.


Fred geht dabei in zwei Schritten vor. Zunächst werden die Strukturendes Dokuments Ebene für Ebene in Element-Deklarationen überführt. Wer-den für einen Elementtyp an verschiedenen Stellen des Dokuments unter-schiedliche Inhaltsmodelle registriert, so werden diese zu einer Oder-Gruppezusammengefasst. Im zweiten Schritt wird eine Reihe von Regeln angewandt,die die Inhaltsmodelle vereinfachen, Ambiguitäten beseitigen und Verallge-meinerungen vornehmen. Diese Regeln bewirken beispielsweise die folgen-den Umformungen (siehe Lindén, 1997):

(a, a, a, a) → (a+) (30)

(a|(b, a)) → (b?, a)

(a + |b)∗ → (a|b)∗

Die automatische Deduktion von Dokumentgrammatiken ist allerdings mitprinzipiellen Schwierigkeiten konfrontiert. Werden die Verallgemeinerungs-regeln sehr eng ausgelegt, ist die DTD vor allem auf das Dokument be-schränkt, aus dem sie abgeleitet worden ist. Dieses kann zwar durchaus sinn-voll sein, wenn abzusehen ist, dass die Dokumentstrukturen konstant blei-ben und vor allem die Inhalte variieren, entspricht aber nicht der üblichenVerwendungsweise strukturierter Dokumente. Werden die Regeln so ausge-legt, dass automatisch deutliche Verallgemeinerungen vorgenommen wer-den, kann die DTD aufgrund ihrer zu großen strukturellen Liberalität ihrenZweck nicht mehr erfüllen.

Inzwischen verfügen Entwicklungssysteme für Dokumentgrammatikenwie XMLSpy (vgl.

�� #� ' �� $��) über Grammatik-Deduktion-

Funktionen, die nicht nur die Ausgabe der Grammatik in verschiedenenSchema-Sprachen erlauben, sondern auch den ‘Stil’ der zu entwickelndenGrammatik zu parametrisieren. So kann bei der Deduktion von Gramma-tiken in XML Schema festgelegt werden, ob Elemente grundsätzlich globaloder lokal, als benannte oder als anonyme komplexe Typen deklariert wer-den sollen. Eine derartige Funktionalität ist insbesondere im Umfeld einesGrammatik-Entwicklungswerkzeugs sinnvoll, da als Grundlage für die Er-stellung einer komplexen Grammatik eine automatisch generierte Rohver-sion stehen kann. Gleichzeitig machen die Deduktionswerkzeuge deutlich,dass die Erstellung von Dokumentgrammatiken ein interpretatorischer Vor-gang ist, der über die Anwendung formaler Regeln hinausgeht, da das kon-zeptuelle System des Gegenstandsbereichs nur zu einem geringen Teil in dieDokumentgrammatik einfließt. Die Abbildung eines solchen konzeptuellenSystems in eine Dokumentgrammatik stellt einen intellektuellen Vorgang

74 Henning Lobin

dar, bei dem Techniken aus dem Bereich des Software Engineering Anwen-dung finden (vgl. Maler und Andaloussi, 1996).

Eine konsequente Weiterentwicklung des Deduktionsansatzes ist mitExamplotron vorgestellt worden (vgl. Examplotron, 2001). Examplotron istein XSLT-Skript, das aus einem Beispieldokument einen Schematron-Vali-dator ableitet. Dabei akzeptiert Examplotron einige spezielle Attribute undElemente im Beispieldokument, die Auskunft darüber geben, welchen allge-meinen Status ein Element erhalten soll. Das Attribut

$��% �etwa erlaubt

die Angabe eines Auftretensoperators wie in DTD-Inhaltsmodellen. Das At-tribut & ��%�� stellt durch einen XPath-Ausdruck Bezüge zu anderen Teilendes Dokuments her, ähnlich dem entsprechenden Element in Schematron.Über ein Element

( ��$�%��können andere Examplotron-Beispieldokumente

eingebunden werden, so dass ein mehrere Beispieldokumente übergreifendesSchema abgeleitet werden kann.

Examplotron weist selbstverständlich nicht die volle Mächtigkeit der re-gulären Schema-Sprachen auf, stellt aber eine interessante, vor allem sehrleicht zu erlernende Alternative dar für die schnelle Spezifikation von Doku-mentgrammatiken.

5 Verwendung von Dokumentgrammatiken

Die Verwendung von Dokumentgrammatiken und Constraints erstrecktsich auf alle Bereiche, in denen Vorteile aus der Vorhersagbarkeit der imDokument vorgefundenen Strukturen gezogen werden können. Elementarist dabei in jedem Fall die Validierung eines Dokuments in Bezug auf einegegebene Dokumentgrammatik.

5.1 Validierung und Parsing

Bei der Validierung eines Dokuments wird überprüft, ob die Sequenz der ei-nem Element direkt untergeordneten Tochterelemente durch das Inhaltsmo-dell der Element-Deklaration lizensiert ist. Sehen wir uns erneut das Beispieleiner Produktbestellung an:


(31)� �� '�' ��

� ��%�$�� & ��(��% & �� & % & � �� %�$��

� ��%��(�� & ��%�� %��(��

� & ��%��

� ��% & �� $��% &�� % & ��#� �

� ��% �� % �

� � ' ! �� ' ! �

� �� & �#� ��(�� & �#� �

� '�& �� '�& �� '�& ��

� � & �#%��#� �

� �� '�' ��

Das DTD-Fragment dazu sieht folgendermaßen aus:

(32)� �� '�' �� %�$�� %��(#� � & ��%��#� � � & ��

� �� %�$#�#� ��

� �� %��(#� � � � ��

� � �� %��(#� & ��%��

Im Falle von DTDs ist der Validierungsalgorithmus denkbar einfach. Wirdim Dokument ein Starttag gefunden, ist die entsprechende Element-Dekla-ration in der DTD zu aktivieren. Die bei diesem Element im Dokument auf-gefundenen Tochterelemente müssen einer der im Inhaltsmodell definiertenmöglichen Elementreihenfolgen entsprechen. So wird in (31) zwischen demStarttag � �� '�' �� und dem Endtag dieses Elements ( � �� '�' �� )die Sequenz der Elemente

��%�$��,��%��(#�

und & �#%��vorgefunden; diese

ist in der DTD (32) mit dem Inhaltsmodell (��%�$��

,��%��(#�

, & ��%��#�) zu

matchen. Beim Matching-Prozess muss berücksichtigt werden, dass durchIterationsoperatoren und Oder-Konstruktionen potentiell unendlich vieleSequenzen durch ein Inhaltsmodell spezifiziert sein können. Der Abgleichzwischen der tatsächlichen Sequenz und dem Inhaltsmodell entspricht for-mal der Anwendung eines regulären Ausdrucks auf eine Eingabe-Sequenzvon Wörtern, wofür es effiziente Verfahren gibt.

Bei allen Tochterelementen ist rekursiv nach dem gleichen Schema zuverfahren, sofern nicht ein leeres Element vorgefunden wird. Dateninhaltund Attribute sind entsprechend mit der DTD abzugleichen. Murata et al.

76 Henning Lobin

(2000) zeigen, wie dieser einfache Algorithmus schrittweise zur Behandlungmächtigerer Schema-Sprachen erweitert werden kann.

In Dokumentgrammatiken können eine Reihe von Konstruktionen inInhaltsmodellen erscheinen, bei denen während des Validierungsprozessesnicht entschieden werden kann, welche Variante zu wählen ist. So ist z. B. in

(33)� �� ∗ � ��

nicht zu entscheiden, ob bei einem Element B als Tochterelement von A imInhaltsmodell noch das erste B gemeint ist oder bereits das zweite. DerartigeAmbiguitäten sind sowohl in XML-DTDs als auch in XML Schema expli-zit verboten, so dass der Grammatik-Entwickler deren Vermeidung selbstzu beachten hat. Zwar ist die Vermeidung von ambigen Inhaltsmodellen einMerkmal von Grammatiken, das die Entwicklung von Validierungsprogram-men einfacher und deren Laufzeitverhalten effizienter macht, doch könnenauch ambige Inhaltsmodelle zur Validierung herangezogen werden, soferndas Validierungsprogramm über Backtracking- oder Chart-Mechanismenverfügt, die falsche Strukturzuordnungen nachträglich zu korrigieren erlau-ben.

Geht es bei der Validierung lediglich um eine Ja-Nein-Entscheidung, obdas Dokument der Grammatik strukturell folgt, wird beim Parsen eines Do-kuments eine Ausgabe produziert, die Informationen enthalten kann, dienicht Teil des Ausgangsdokuments sind. In DTDs betrifft dieses z. B. De-fault-Werte von Attributen. Ist das Attribut

& ��%�� im Beispiel (32) etwamit einem Default-Wert deklariert

(34)� � � �� %��(�� & ��%��

so kann im Dokument auf die Angabe des Attributs verzichtet werden:

(35)��

� ��%��(�� %��(��

Der Parsing-Prozess ergänzt den Default-Wert in der Ausgaberepräsentation:

(36)��

� ��%��(�� & ��%�� %��(��


Die Information, die in einem Dokument tatsächlich enthalten ist, wirdauch als Infoset bezeichnet. Bei der Validierung wird das Infoset des Doku-ments nicht verändert, beim Parsing hingegen vergrößert. In XML Schemawerden u. a. auch die Informationen zum Typ von Daten und Elementen indas Post Schema Validation Infoset (PSVI) übertragen, so dass im PSVI we-sentlich mehr Information der weiteren Verarbeitung zur Verfügung steht alsim Ausgangsdokument. Beim PSVI handelt es sich um eine abstrakte Daten-struktur, die auf unterschiedliche Weise applikationsspezifisch konkretisiertwerden kann.

5.2 Weitere Verwendungsweisen von Dokumentgrammatiken

XML-Editoren bedienen sich ebenfalls der Dokumentgrammatik, um denProduktionsprozess von XML-Dokumenten zu unterstützen. Anders als beider Validierung wird die Grammatik eingesetzt, um für ein Dokument eineListe derjenigen Elemente zu ermitteln, die an einer bestimmten Positioneingefügt werden können. Durch eine Auswahl aus dieser Liste kann derBenutzer die Struktur des Dokuments interaktiv aufbauen; obligatorischeStrukturteile werden in vielen Editoren dabei automatisch eingefügt.

(37)� �� '�' ��

� ��%�$�� & ��(��% & �� & % & � � � �� %�$��

� & ��%��

� ��% & �� $��% &�� % & ��#� �

� ��% �� % �

� � ' ! �� ' ! �

� �� & �#� ��(�� & �#� �

� '�& �� '�& �� '�& ��

� � & �#%��#� �

� �� '�' ��

Einer solchen Funktionalität liegt ein Prozess zugrunde, der ähnlich der Va-lidierung arbeitet, dabei jedoch liberaler verfährt, wenn das Fehlen von Ele-menten registriert wird. Befindet sich der Cursor beispielsweise an der wiein Beispiel 37 dargestellten Position im Dokument, so wird kein Fehler aus-gegeben, sondern gemäß (32) das Element

��%��(#�zur Einfügung angeboten.

Nur wenn allein durch Einfügung weiterer Elemente das Dokument nichtmehr DTD-konform werden kann, wird auch während des Editierprozessesein Fehler ausgegeben. Dieses wäre etwa der Fall, wenn in (37) die Elemente��%�$��#� ��

und & �#%��in umgekehrter Reihenfolge erscheinen würden.

78 Henning Lobin

Eine systematische Einbeziehung von Dokumentgrammatiken bei derTransformation von XML-Dokumenten wird bislang nicht vorgenommen.Murata (1998) hat gezeigt, dass nur bei der Verwendung regulärer Baum-grammatiken gewährleistet werden kann, dass nach einer Transformati-on in eine andere Dokumentstruktur die Validierbarkeit in Bezug auf ei-ne andere Dokumentgrammatik gegeben ist. Insofern haftet der Doku-menttransformation immer etwas Provisorisches an, sofern sie sich auf derEbene der weniger mächtigen Varianten regulärer Baumsprachen bewegt.Wird eine Transformation z. B. in XSLT spezifiziert, so hat der Entwick-ler des Transformationsskripts durch den Aufbau der Regeln sicherzustel-len, ob Anwendungskontexte vorkommen können, in denen durch die Ziel-Dokumentgrammatik nicht abgedeckte Strukturen entstehen. Ein allgemei-nes formales, also automatisierbares Lösungsverfahren existiert für diesesProblem nicht.

In XPath 2.0, das zur Zeit noch nicht als Empfehlung vorliegt, wird allerVoraussicht nach das Post Schema Validation Infoset berücksichtigt werden.Dieses bedeutet, dass zumindest bei der Adressierung auch solche Informa-tionen herangezogen werden können, die nicht im Dokument selbst ent-halten sind, sondern erst bei der Validierung aus dem XML-Schema in dasPSVI einfließen. Dieses betrifft vor allem Datentypen und Standardwerte.

Ein Standardbeispiel ist die Suche in einem strukturierten Dokument:Wenn der Dokumentgrammatik entnommen werden kann, dass z. B. einElement

�� % ��%�(�"��nur als erstes Tochterelement eines Elements

� & ��(�� ' erscheinen kann, kann die Geschwindigkeit der Suche nach Ele-menten dieses Typs durch Auslassung großer Teile des Dokuments um einVielfaches erhöht werden. Bislang ist von dieser Möglichkeit beim Entwurfvon Querying-Tools für XML-Dokumente nicht Gebrauch gemacht wor-den. Zusammen mit dem Entwurf für XPath 2.0 ist für XQuery, die in derEntwicklung befindliche Abfragesprache für XML-Dokumente, ein Daten-modell entwickelt worden (vgl. XQuery, 2002), das auch Informationen ausdem PSVI umfasst.

Eine gänzlich andere Verwendungsart von Dokumentgrammatiken istfür die Zwecke der automatischen Textkategorisierung zu beobachten (vgl.Rehm, 2002). Dabei geht es nicht darum, Dokumentstrukturen durch eineGrammatik zu definieren, sondern Strukturwissen über Dokumente zu re-präsentieren. Für Dokumente, die kategorisiert werden sollen, ist diejenigeDokumentgrammatik zu finden, deren Strukturierung am besten auf diesesangewandt werden kann. Da nicht mit der Verwendung gleicher Element-namen oder auch nur der gleichen Elementhierarchie zu rechnen ist, werden


die Dokumentgrammatiken mit Erkennungsroutinen kombiniert, mit de-ren Hilfe der entsprechende Strukturteil im Dokument identifiziert werdenkann.

6 Ausblick

Wir haben gesehen, dass Dokumentgrammatiken schon heute eine wichtigeRolle spielen, wenn es darum geht, strukturierte Dokumente effizient undmit mächtigen Werkzeugen zu verarbeiten. In welche Richtung werden sichDokumentgrammatiken in der näheren Zukunft entwickeln? Einige Ent-wicklungsperspektiven zeichnen sich bereits heute ab.

Immer häufiger werden Klassen von Dokumenten nicht nur mit Doku-mentgrammatiken kombiniert, sondern auch mit einer formalisierten Be-schreibung der Bedeutung der Struktur. Wird in einer Dokumentgramma-tik z. B. für eine Tabelle lediglich festgelegt, dass sie aus Zeilen besteht unddiese wiederum in eine bestimmte Anzahl von Zellen unterteilt sind, so be-schreibt ein semantisches Modell die gegenseitige Abhängigkeit von Zeilenund Spalten, Zeilen- und Spaltenköpfen, Datenzellen usw. – oftmals Kon-zepte, die im Dokument und in der Dokumentgrammatik nicht explizit er-scheinen. Wie bei der Analyse natürlicher Sprache, bei der zwischen Syntaxund Semantik unterschieden wird, so spiegelt auch eine Dokumentgram-matik lediglich die syntaktische Seite des Dokuments wider, die durch ei-ne semantische Repräsentation ergänzt werden kann. Derartige semantischeRepräsentationen werden Ontologien genannt und ihrerseits als strukturier-te Dokumente auf der Grundlage einiger inzwischen weit verbreiteter Stan-dards dargestellt. Ein Basisformalismus für Wissensrepräsentationszwecke inXML steht mit dem Resource Description Framework (RDF) zur Verfügung,XML Topic Maps (XTM) erlauben die Spezifikation semantischer Netze, undmit dem Ontology Interface Layer (vgl. Horrocks et al., 2000) ist inzwischenauch eine XML-basierte Repräsentation für Ontologien verfügbar, die eineInferenzebene umfasst.

Ausgereifte Ontologien für bestimmte Domänen können als eine inte-grierende Ebene oberhalb der Dokumentgrammatiken verstanden werden.Verschiedene Dokumentgrammatiken setzen das in der Ontologie reprä-sentierte Strukturwissen in jeweils unterschiedlicher Weise syntaktisch um.Ontologien bilden deshalb ein Basis, um zukünftig auch die Erstellungvon Transformationsskripten zwischen XML-Dokumenten zu automatisie-ren. Auch bei den Dokumentgrammatiken selbst sind weitere Entwicklungs-schritte zu erwarten. Das Verständnis der formalen Grundlagen von Schema-

80 Henning Lobin

sprachen hat bereits zu Entwicklungen wie RELAX NG geführt. Eine Inte-gration von regelbasierten und Constraint-basierten Spezifikationstechnikensteht bei der Weiterentwicklung von XML Schema zu erwarten.

Wichtige Erkenntnisse vermag auch die Übertragung von linguistischenMethoden und Konzepten auf Schemasprachen und Dokumentgrammati-ken zu bewirken. Die linguistische Grammatiktheorie befasst sich seit ei-nem halben Jahrhundert mit Methoden der formalen Spezifikation kom-plexer Grammatiken; in diesem Zusammenhang ist ein reichhaltiges Inven-tar von Konzepten geschaffen worden, deren Anwendung auch im nicht-sprachlichen Kontext sinnvoll sein kann. Neben konzeptionellen könnenauch methodische Erkenntnisse aus der Linguistik übertragen werden. Ge-rade in den letzten Jahren haben verstärkt Forschungen dazu eingesetzt, wieein Textkorpus automatisch mit grammatischer Information annotiert undwie aus annotierten Korpora grammatisches Wissen deduziert werden kann(siehe z. B. den Beitrag von Ule und Hinrichs, in diesem Band). Die wis-senschaftliche Durchdringung dieser Zusammenhänge im Bereich beliebigerXML-annotierter Daten steht hingegen noch aus.

Literaturverzeichnis

Cagle, Kurt; Duckett, Jon; Griffin, Oliver; Mohr, Stephen; Norton, Fran-cis; Ozu, Nikola; Stokes-Rees, Ian; Tennison, Jeni und Williams, Kevin(2001): Professional XML Schemas. Birmingham: Wrox Press.

Carstensen, Kai-Uwe; Ebert, Christian; Endriss, Cornelia; Jekat, Susanne;Klabunde, Ralf und Langer, Hagen (Herausgeber) (2001): Computerlin-guistik und Sprachtechnologie. Eine Einführung. Heidelberg, Berlin: Spek-trum akademischer Verlag.

Examplotron (2001): “Examplotron”.�� & �� ' $��%�$�� $�% ��

.Horrocks, Ian; Fensel, Dieter; Broekstra, Jeen; Decker, Stefan; Erdmann, Mi-

chael; Goble, Carole; van Harmelen, Frank; Klein, Michael; Staab, Steffen;Studer, Rudi und Motta, Enrico (2000): “The Ontology Inference LayerOIL”.

�� $��$ ��$ ' �#�� $�% ��$�( ' � � ��$�( ' � ' $�� #� ' .HTML (1999): “HTML 4.01 Specification”. World Wide Web Consortium

(W3C),�� $�% �� '�� .

Jelliffe, Rick (2000): “The Schematron – An XML Structure Validation Lan-guage using Patterns in Trees”.

�� & �� #� ' ��%��$��%�� & ��%�$��

.Kimber, Eliot und Heintz, John (2000): “Using UML to define XML docu-

ment types”. Markup Languages 2 (3): S. 295–320.


Lee, Dongwon und Chu, Wesley W. (2000): “Comparative Analysis ofSix XML Schema Languages”.

�� '�& ��$�� #�$�� & ��%

.Lindén, Greger (1997): Structured Document Transformations. Dissertation,

Department of Computer Science, University of Helsinki, Finland. Re-port A-1997-2,

�� ' ��(��( � " (��

.Lobin, Henning (2000): Informationsmodellierung in XML und SGML. Ber-

lin, Heidelberg: Springer-Verlag, 2. Auflage.Maler, Eve und Andaloussi, Jeanne El (1996): Developing SGML DTDs.

From Text to Model to Markup. Upper Saddle River, New Jersey: Pren-tice Hall.

Mani, Murali; Lee, Dongwon und Muntz, Richard R. (2001): “Seman-tic Data Modeling using XML Schemas”. In: Proc. 20th Internatio-nal Conference on Conceptual Modeling (ER). Yokohama, Japan.

�� $� & �� '�& ��$��#��$�� $��% ��

.Murata, Makoto (1998): “Data Model for Document Transformation and

Assembly”. In: Proc. of PODDP 1998.Murata, Makoto; Lee, Dongwon und Mani, Murali (2000): “Taxonomy of

XML Schema Languages using Formal Language Theory”. In: Proc. ofExtreme Markup Languages 2000.

RDF (1999): “Resource Description Framework (RDF). Model and SyntaxSpecification”. World Wide Web Consortium (W3C),

�� $�%�� #%��"�� & � �� .

Rehm, Georg (2002): “Towards Automatic Web Genre Identification – ACorpus-Based Approach in the Domain of Academia by Example of theAcademic’s Personal Homepage”. In: Proceedings of the Hawai’i Internatio-nal Conference on System Sciences (HICSS-35). Big Island (Hawaii).

RELAX NG (2001): “RELAX NG Specification. Committee Specificati-on”. OASIS – Organization for the Advancement of Structured Informa-tion Standards. James Clark und Makoto Murata (Hrsg.),

�� $ & ��(#��$�� $�% ��$�� (��%�� '�& �� ' .

SGML (1986): ISO 8879:1986. Information Processing – Text and Office Sys-tems – Standard Generalized Markup Language (SGML). International Or-ganization for Standardization, Genf.

Shafer, Keith E. (1995): “Creating DTDs via the GB-Engine and Fred”.�� $�� ' � ��$�% ��"�%��#��$�� ' �� #� ' .Sperberg-McQueen, Michael; Huitfeld, Claus und Renear, Allen (2000):

“Meaning and interpretation of markup”. Markup Languages 2 (3):S. 215–234.

82 Henning Lobin

XML (2000): “Extensible Markup Language (XML) Version 1.0 (SecondEdition)”. World Wide Web Consortium (W3C),

�� $�%��

�� ' ��

.XML Schema (2001): “XML Schema”. World Wide Web Consortium

(W3C),�� $�%�� & .

XPath (1999): “XPath Language Version 1.0”. World Wide Web Consorti-um (W3C),

�� $�% �� & �� .

XQuery (2002): “XQuery 1.0: An XML Query Language”. World WideWeb Consortium (W3C),

�� $�%�� %��

.XSLT (1999): “XSL Transformations Version 1.0”. World Wide Web Con-

sortium (W3C),�� $�%��

�� ' � .

XTM (2001): “XML Topic Maps (XTM) 1.0. TopicMaps.Org Specificati-on”.

�� $��(�� & � � � $�% �� .

textauszeichnung und dokumentgrammatikeng91062/pdf/lobin-ll-2003c.pdf · ter textauszeichnung wird...

Documents