In diesem Kapitel beschreibe ich die Technologien, die für diese Diplomarbeit von Bedeutung sind, gebe einen Überblick über vergleichbare Systeme und ordne das von mir entwickelte System ein.
Dieser Abschnitt vermittelt grundlegende Informationen über die Standard Generalized Markup Language (SGML) und die Extensible Markup Language (XML). SGML und XML sind hier von Bedeutung, da ich sie als Eingabeformat für IP4W3 ausgewählt habe. Sie erlauben, die Struktur- und Metainformationen in Texten zu repräsentieren, von denen im ersten Abschnitt die Rede war. Beide Sprachen konzentrieren sich auf diese Art von Auszeichnungen und erlauben keinerlei Formatierung. Damit besitzen sie genau den Schwerpunkt, der hier benötigt wird.
Im Umfeld von SGML geht es stets um Textdokumente, d.h. um solche Dokumente, die zum überwiegenden Teil aus Text bestehen, die aber auch Graphiken, Tabellen und so weiter enthalten dürfen. Textdokumente können etwa in folgende Komponenten aufgegliedert werden.
Generic Markup versus Visual Markup
Bei der Texterstellung unterscheidet man zwischen Generic Markup und Visual
Markup. Letzteres dürfte dem Leser vertrauter sein, denn als ein Spezialfall
des Visual Markup ist das Konzept des What you see is what you get (WYSIWYG)
weitgehend bekannt.
Die Arbeit an einem Dokument konzentriert sich dabei auf die Erfassung des Textes und die Festlegung der äußeren Form. Das für den Verfasser auf den ersten Blick so einfache Vorgehen - er sieht den Text ständig in seiner »endgültigen« Form - birgt auch einige Probleme. So muß er selbst darauf achten, daß gleichartige Information (Name, Begriff usw., s.o.) auch stets gleich aussieht. Bei der Speicherung geht die logische Information und die Strukturinformation verloren. Lediglich die äußeren Attribute werden gespeichert.
Diesen Mißstand zu beheben, hat sich das Generic Markup vorgenommen. Die Idee ist einfach: Der Autor wird von der Bürde befreit, sich während der Texterstellung Gedanken über das Aussehen machen zu müssen und bekommt darüber hinaus die Möglichkeit, strukturorientiert zu arbeiten. Das heißt er kann die Gliederung seines Textes, die er beim Schreiben ohnehin im Kopf hat, in sein Dokument übernehmen, ohne den Umweg über die Formatierung, das Layout usw. machen zu müssen. Die Formatierung wird dann in einem eigenen Schritt mit Bezug auf die logische Information und die Struktur ausgeführt.
Document Type Definition
Für die Umsetzung dieser Ideen ist bei SGML der Dokumenttyp wichtig. Gemeint ist damit
folgendes:
Wenn man sich verschiedene Texte hinsichtlich ihres Aufbaus und ihrer
Struktur ansieht, sind gewisse Gemeinsamkeiten und Unterschiede
feststellbar. Je nachdem wie groß diese Differenzen sind, zählt man
verschiedene Dokumente zum selben oder zu unterschiedlichen Typen.
Bei dem Versuch, den Dokumenttyp »Buch« näher zu charakterisieren, fällt die Gliederung in Kapitel, Abschnitte, Unterabschnitte und letztlich Absätze auf. Die Anzahl und die Tiefe der Gliederungen variiert von Buch zu Buch. Trotz dieser Unterschiede erscheint es sinnvoll, zwei Bücher als gleichartig anzusehen, auch wenn die Anzahl der Kapitel voneinander abweicht.
Eine formale Typisierung von Dokumenten muß also die Gemeinsamkeiten festlegen, zugleich aber genügend Flexibilität für den konkreten Fall lassen. In SGML erfolgt die Charakterisierung eines Dokumenttyps in der Document Type Definition (DTD)4. Die DTD legt fest, welche logischen Elemente ein Text enthalten darf, welche Elemente unbedingt vorhanden sein müssen und in welcher Reihenfolge sie erscheinen dürfen. Um das Beispiel »Buch« weiter zu verfolgen: ein Buch muß in jedem Fall einen Titel haben, der auch zwingend am Anfang erscheinen muß. Ein Index hingegen ist optional.
Eine Verknüpfung mit einem bestimmten Layout ist in der DTD nicht enthalten. Für die Verarbeitung von SGML-Dokumenten gibt es einen weiteren ISO-Standard, mit dem handlichen Namen »Document Style Semantics and Specification Language« (DSSSL, gesprochen »Dissel«, ISO 10179). Die Trennung von Struktur und Aussehen beschert den Dokumenten, neben den genannten Vorteilen, eine weitere positive Eigenschaft: Da ihre Formatierung in keiner Weise feststeht, sind sie vollkommen unabhängig vom Ausgabemedium. Ob also ein Text auf Papier (beliebiger Größe) gedruckt, auf dem Bildschirm (in beliebiger Farbe, Schriftart usw.) ausgegeben oder von einem Sprachsynthesizer gesprochen wird, ist vollkommen offen.
Document Type Definition
Eine DTD für einen selbsterdachten Dokumenttyp zeigen die folgenden Zeilen:
<!-- Element Min Inhaltsmodell -->
<!ELEMENT notiz - -
(titel, autor, datum, absatz+) >
<!ELEMENT titel - - (#PCDATA) >
<!ELEMENT autor - - (#PCDATA) >
<!ELEMENT datum - - (#PCDATA) >
<!ELEMENT absatz - - (#PCDATA | wichtig)* >
<!ELEMENT wichtig - - (#PCDATA) >Dieses einfache Beispiel zeigt eine DTD für eine »Notiz«, die besteht aus
Die ersten drei Elemente enthalten reinen Text, in SGML-Terminologie Parsed Character Data (PCDATA) genannt. Ein Absatz kann wahlweise (dafür steht der senkrechte Strich) aus Character Data oder aus »wichtigem« Text bestehen und zwar beliebig kombinierbar (dafür steht der Stern). Eine DTD läßt sich auch in einer Baumstruktur darstellen. Für das Beispiel zeigt folgende Abbildung eine Baumdarstellung.
Abbildung 3: Die Notiz-DTD als Baumdarstellung
Dokumentinstanz
Ein SGML-Dokument wird auch »Instanz« genannt, abgeleitet von dem
englischen »instance«, zu Deutsch »Beispiel«5. Eine Instanz ist also ein
Beispiel, ein Vertreter aus einer Klasse von Dokumenten, die durch die
Document Type Definition bestimmt ist.
Für die obige DTD sieht eine Instanz etwa wie folgt aus.
<!DOCTYPE notiz SYSTEM "/usr/home/sm/dtd/notiz.dtd" >
<notiz>
<titel>Termine</titel>
<autor>Stefan Mintert</autor>
<datum>1. Februar 1999</datum>
<absatz>
<wichtig>Abgabe der Diplomarbeit</wichtig>
</absatz>
<absatz> ...
</absatz>
</notiz>In der ersten Zeile, der sogenannten Doctype-Deklaration, nennt die Instanz diejenige DTD, zu der sie konform ist. Die weiteren Zeilen sind das eigentliche Dokument. Die Syntax ist recht einfach zu verstehen: Eine Instanz besteht aus hierarchisch verschachtelten Elementen. Ein Element beginnt mit einem Start-Tag (z.B. <notiz>) und endet mit einem End-Tag (z.B. </notiz>). Der englische Begriff »tag« bedeutet so viel wie Schildchen oder Etikett. Verbindet man anschaulich damit die Auszeichnung von Waren mit einem Preisschild, so ist sofort klar, weshalb der englische Oberbegriff »tagging language« mit »Auszeichnungssprache« übersetzt wird.
Zusammen mit der gezeigten DTD verifiziert man leicht, daß das vorliegende Beispiel eine gültige Instanz ist. Für komplexere Fälle gibt es Werkzeuge (Parser), die diese syntaktische Verifikation durchführen.
Die Hypertext Markup Language (HTML) ist nicht etwa eine Konkurrentin für SGML, sondern eine Anwendung davon. Formal ist HTML nichts weiter als eine DTD6. HTML ist zwar die lingua franca des Web, jedoch für die Benutzung als Eingabeformat für IP4W3 nicht ausreichend, da die benötigten Metainformationen nicht oder nur unter unzumutbaren Einschränkungen in HTML-Instanzen kodiert werden können7.
Bei der Extensible Markup Language (XML) handelt es sich um eine Teilmenge von SGML. Damit sind alle hier für SGML gemachten Aussagen auch für XML gültig. Die technischen Unterschiede zwischen XML und SGML spielen innerhalb dieser Diplomarbeit eine untergeordnete Rolle. Wichtig sind die damit verbundenen Konzepte, die bei beiden Sprachen gleich sind (zumindest soweit wie ich sie hier benutze). Aus diesem Grund unterscheide ich im folgenden in der Regel nicht zwischen XML und SGML. Dort wo es notwendig ist, erwähne ich es ausdrücklich. Ein Vergleich beider Sprachen ist in [CLAR97] zu finden8. Da XML zweifellos einen großen Einfluß auf die Zukunft des Web haben wird und möglicherweise SGML verdrängen wird, ist XML hier von mindestens ebenso großer Bedeutung wie SGML.
Eine wesentliche, durch XML eingeführte Neuerung ist, daß Dokumente auch ohne DTD existieren können. Sie müssen nur noch abgeschwächten Bedingungen genügen. In diesem Fall spricht man von der Wohlgeformtheit eines Dokuments. Halten sie sich darüber hinaus auch noch an die Regeln einer DTD, spricht man von Gültigkeit. Ich halte diese Innovation für die schlechteste Veränderung gegenüber SGML, die XML dem Verfasser eines Dokuments zugesteht. Als Folge davon sind nämlich Dokumente zugelassen, die völlig freie Elementnamen besitzen. Unterliegen die Namen jedoch keiner Konvention, so sind sie wertlos. Sämtliche Programme (wie auch Stylesheets) müssen für ein konkretes Dokument geschrieben werden, nicht für eine Klasse von Instanzen. Programme, die nach Informationen in einem Dokument suchen, können die Metainformationen nicht nutzen, weil sie die Elementnamen nicht kennen. Die strukturelle Korrektheit des Dokuments läßt sich nicht verifizieren, da es keine Spezifikation der Abhängigkeiten gibt. Da ich beim Entwurf meines System die Existenz einer DTD vorausgesetzt habe, ist die Wohlgeformtheit von keiner großen Bedeutung. Ich verwende sie allerdings intern an einer Stelle, um eine Effizienzsteigerung zu erzielen.
Die Verarbeitung von SGML-Dokumenten zum Zwecke der Formatierung mit der Document Style Semantics and Specification Language (DSSSL) soll hier nur kurz angerissen werden. Ich verwende DSSSL zwar, um Dokumente in HTML umzuwandeln, jedoch liegt die wesentliche Leistung meiner Arbeit im Bereich SGML/XML, so daß für das Verständnis der folgenden Kapitel schon ein geringes Maß an DSSSL-Kenntnissen genügt.
In der folgenden Abbildung sind die wesentlichen Stationen, die ein Dokument durchläuft, skizziert.
Abbildung 4: Schematische Darstellung der Verarbeitung von SGML-Dokumenten mit DSSSL. Die grauen Teile unterliegen dem Einfluß von DSSSL.
Ausgangspunkt ist natürlich die SGML-Instanz als Eingabeobjekt. Die erste Prüfung führt ein Parser aus, der zu diesem Zweck die DTD benötigt. In einem weiteren Schritt, dem SGML Tree Transformation Process, werden Operationen »auf dem Baum« der Elemente durchgeführt. Möchte man etwa im obigen Beispiel nur den Autor einer Notiz extrahieren, so könnte der SGML Tree Transformation Process - bildlich gesprochen - die anderen Äste aus dem Baum abschneiden und nur den Autor übrig lassen. Dieser Vorgang kann als ein Vorverarbeitungsschritt angesehen werden. Sein Ergebnis ist wieder eine SGML-Instanz, die aber gegebenenfalls zu einer anderen DTD konform ist. Die Formatierung geschieht dann im SGML Tree Formatting Process, an dessen Ende ein Dokument im gewünschten Ausgabeformat steht.
Die obigen Prozesse werden in DSSSL mit der Transformation Language beziehungsweise der Style Language beschrieben. Zur Ausführung ist ein Interpreter nötig, der auch als DSSSL-Maschine bezeichnet wird9. Ihre Aufgabe geht über die in der Grafik grau dargestellten Teile hinaus. Eine DSSSL-Maschine muß nämlich die Formatierungsanweisungen von DSSSL in das konkrete Ausgabeformat umsetzen. DSSSL-Programme (auch »Stylesheet«) sind unabhängig vom Ausgabeformat. Sie können es sein, weil die Sprache typographische Objekte (Flow Object), wie Seiten, Absätze, Tabellen usw. zur Verfügung stellt, die nicht an ein bestimmtes Format gebunden sind. Die DSSSL-Maschine wandelt dann zum Beispiel der Abschluß des Flow Objects »Seite« in die konkrete Anweisung \newpage (TeX), showpage (PostScript) usw. um10.
Zu beachten ist, daß in der Abbildung 4 unter den Ausgabeformaten nicht HTML genannt ist. Zwar handelt es sich de facto bei HTML um das Ausgabeformat für Web-Browser, jedoch ist die Hypertext Markup Language formal nur eine SGML-Anwendung. Um HTML zu erzeugen ist also nur eine Transformation der Eingabeinstanz in eine HTML-Instanz durchzuführen. Diese dopellte Rolle von HTML (Zwsichenformat in der DSSSL-Verarbeitungskette und Ausgabeformat für's Web) sorgt dafür, daß in der Praxis zwei DSSSL-Programme benötigt werden, eines für die HTML-Ausgabe und eines für die Druckausgabe.
Die Extensible Style Language (XSL) ist die »Formatierungssprache für XML«. Sie verhält sich ungefähr so zu DSSSL, wie sich XML zu SGML verhält. Allerdings ist XSL schon aus syntaktischen Gründen keine Teilmenge von DSSSL. XSL wird zur Zeit vom World Wide Web Consortium (W3C) entwickelt. Innerhalb von IP4W3 kommt XSL nicht zum Einsatz. Ich erwähne sie an dieser Stelle, weil sie auf den ersten Blick die Sprache der Wahl ist, wenn es darum geht, XML-Instanzen zu formatieren. Unter funktionalen Gesichtspunkten ist DSSSL aber mindestens genau so gut geeignet. Diese Einschätzung kann in der Zukunft anders ausfallen, wenn XSL fertig ist und möglicherweise breitere Unterstüztung findet.
Um das vorliegende System IP4W3 in die Menge der bestehenden Systeme einzuordnen, stütze ich mich auf die Klassifikation des Whirlwind Guide von Steve Pepper ab [PEPP98]. Dabei handelt es sich um die seit Jahren umfangreichste und stets aktuellste Übersicht über SGML- und mittlerweile auch XML-Software. Pepper benutzt in seiner Übersicht die folgende grobe Kategorisierung:
IP4W3 ordnet sich nach dieser Einteilung in die Kategorien »document storage and management« und »electronic delivery« ein, integriert jedoch auch Komponenten aus der Kategorie »conversion«. Der Unterschied zu den meisten von Pepper aufgeführten Produkten ist, daß IP4W3 kein Programm ist, daß eindeutig einer dieser Kategorien zuzuordnen ist und auch nicht nur eine Aufgabe erfüllt. Vielmehr handelt es sich bei IP4W3 um ein integriertes System, dessen Funktionsumfang ein Querschnitt der oben genannten Kategorien ist. Zu den kommerziellen Produkten, die Funktionen nur einer Kategorie anbieten, kann und will IP4W3 keine Konkurrenz sein. Statt dessen habe ich versucht, Funktionen aus verschiedenen Kategorien zu implementieren, um ein neues Konzept umzusetzen. Am besten läßt sich das dadurch erläutern, daß ich die Unterkategorien von Peppers Whirlwind Guide vorstelle, die von IP4W3 ganz oder teilweise abgedeckt werden.
Die Kategorie »document storage and management« unterteilt sich in »SGML document and component manager«, »SGML document manager«, »SGML DMS middleware« und »SGML document management utility«. IP4W3 enthält einen großen Component-Management-Anteil, was von Pepper folgendermaßen beschrieben wird: »[...] Systeme, die Grove-Komponenten für eine beliebige DTD speichern und verwalten. [...] Die Speicherungseinheit kann das Dateisystem des Betriebssystems, eine Datenbank, ein Netzwerk oder eine Kombination der drei sein.« Reine Vertreter dieser Klasse bieten nur diese Verwaltung von Dokumenten-Komponenten und den Zugriff darauf. Kommerzielle Produkte, wie etwa Astoria von Chrystal Software, bieten eine programmierbare Schnittstelle (API) auf die weitergehende Funktionen aufgesetzt werden können. IP4W3 stellt für den Zugriff auf Dokumenten-Komponenten sogenannte Suchmuster zur Verfügung.
Als nächste relevante Unterkategorie ist »SGML document management utility« zu nennen: »Diese Werkzeuge stellen einige Aspekte von SGML-Dokumenten- oder Komponentenverwaltung (z.B. Indexierung, Suche, Versionskontrolle, Datenbankanbindung) zur Verfügung [...]« IP4W3 gehört dank seiner Indexierung und Suchfunktion auch in diese Kategorie.
Die äußerlich hervorstechendste Eigenschaft von IP4W3 ist die Benutzung von Web-Browsern als Schnittstelle zum Benutzer. Aus diesem Grund gehört das System auch in Peppers Kategorie »electronic delivery/SGML library web server«. Bekanntester kommerzieller Vertreter ist das Programm DynaWeb.
Da IP4W3 die Produkte CoST, Jade (DSSSL-Maschine) und nsgmls (SGML-Parser) benutzt, integriert das System Funktionen aus den folgenden Kategorien/Unterkategorien:
IP4W3 im Vergleich zu anderen
Systemen
IP4W3 läßt sich nicht eindeutig in
eine Kategorie einordnen. Allein diese Tatsache stellt ein
Alleinstellungsmerkmal des Systems dar. Sofern der Vergleich ausschließlich auf
die Kategorie beschränkt ist, in der
das Vergleichsprodukt eingeordnet ist11, kann
IP4W3 im direkten Vergleich mit kommerziellen
Produkten in vielen Fällen nicht bestehen.
Der Grund dafür ist,
daß die Produkte in Peppers Kategorisierung Spezialisten in
der jeweiligen Kategorie sind. Das ist nicht überraschend, da
die von Pepper betrachteten Produkte selbst erst die
Kategorien definieren. Es gibt nur sehr wenige Programme, die
sich nicht eindeutig einordnen ließen.
Es wäre weder inhaltlich sinnvoll, noch wissenschaftlich interessant gewesen, gegen einen dieser Spezialisten anzutreten. Besonders deutlich zeigt sich das an der Kategorie »SGML document manager«, die sich in Peppers Interpretation kaum von klassischen Dokumenten-Datenbanken unterscheidet: »Systeme, die SGML auf Dokumentenebene oder als große Stücke speichern und verwalten, und die Entities oder Elemente auf hoher Ebene der Dokumentenhierarchie repräsentieren.« Im Gegensatz dazu ist der oben schon genannte Bereich der Komponentenverwaltung viel interessanter. IP4W3 sieht Dokumente deshalb nicht als monolithisches Gebilde an, sondern berücksichtigt die interne Struktur und nutzt sie aus, um neue und bessere Funktionen darauf anzubieten.
Zusammenfassend lassen sich als Vorteile von IP4W3 gegenüber vorhandenen Systemen folgende Eigenschaften nennen:
| 4 | Die theoretische Grundlage hierfür bilden die regulären Grammatiken. Für Details siehe [GOLD90] und [WIHE96]. |
| 5 | Obwohl der Begriff »Instanz« im Deutschen eine andere Bedeutung hat, werde ich mich dem üblichen Gebrauch im SGML-Umfeld anschließen und ein Dokument auch Instanz nennen. |
| 6 | Genaugenommen gibt es für HTML 4 mittlerweile drei DTDs mit verschiedenen Aufgaben. |
| 7 | Die Informationen lassen sich zwar als Wert des Attributs class in ein Dokument aufnehmen, jedoch sind die Attributwerte in keiner Weise beschränkt. Es fehlt also eine formale Definition des Dokumenttyps. |
| 8 | Eine sehr lesenswerte Arbeit zum Vergleich der Inhaltsmodelle beider Sprachen ist [KILP98]. |
| 9 | Eine freie Implementation ist James' DSSSL Engine (Jade). |
| 10 | Die TeX- und PostScript-Beispiele sind nicht mehr als Beispiele. Ob eine DSSSL-Maschine tatsächlich genau diese Ausgabe erzeugt, kann ich nicht sagen, da dies auch durch DSSSL nicht festgelegt ist. Es bleibt der Maschine überlassen, wie sie ihr Ziel erreicht. |
| 11 | Ich verstehe das allerdings als unzulässigen Vergleich. |
| 12 | Grundlage für diese Aussage ist die Kategorisierung des Whirlwind Guides [PEPP98]. |
