Die Standard Generalised Markup Language (SGML) ist seit 1986 eine internationale Norm, mit deren Hilfe die logische Struktur und der Inhalt von Dokumenten beschrieben werden können. Zweck von SGML ist auch heute noch, daß durch den Verzicht auf proprietäre Formatierungen der Zugriff und die Wiederverwendbarkeit der in einem Dokument enthaltenen Informationen verbessert werden. Die Spezifikation erlaubt eine effizientere Suche nach Informationen, da sie die internen Strukturen unabhängig von der verwendeten Applikation oder Plattform berücksichtigt.

Um eine SGML-Anwendung zu erzeugen, wird ein Satz von dokumentenspezifischen Objekten ("Titel", "Kapitel", "Absatz" oder "Liste") festgelegt. Die Definition der Objekte und ihrer Abhängigkeiten untereinander erfolgt in der Document Type Definition (DTD), die den Kern der Applikation bildet. Die Objekte in einem SGML-Dokument werden dann entsprechend den in der DTD definierten Regeln markiert.

Ursprünglich wurde SGML für komplexe technische Dokumente etwa in der CALS-Inititive des US-Verteidungsministeriums eingesetzt. Heute ist der Standard das Mittel der Wahl für eine Vielzahl unterschiedlicher Applikationen. Seine besonderen Stärken kommen dann zum Tragen, wenn Dokumente von Arbeitsgruppen erstellt, als umfangreiche Kollektionen verwaltet und elektronisch in unterschiedlichen Formaten verteilt werden sollen.

Es ist daher nicht überraschend, daß die Hypertext Markup Language (HTML), der Standard zur Verteilung von Dokumenten im Web, SGML benutzt. Rein formal ist HTML eine spezielle SGML-Applikation mit einer eigenen DTD und einer festgelegten Anzahl von Tags (Markierungen). Aus technischer Sicht ist die Fragestellung "SGML oder HTML" sinnlos, weil man beim Einsatz von HTML ohnehin automatisch SGML benutzt.

Wenn es allerdings um die Einsatzbereiche von HTML und SGML geht, tauchen immer wieder zwei Fragen auf:

- Kann HTML als generelles Austauschformat angesehen werden oder ist es der kleinste gemeinsame Nenner und damit nur für den gelegentlichen Einsatz brauchbar?

- Kann HTML als Archivierungsformat benutzt werden oder sollte man grundsätzlich HTML-Files aus anderen Quellen erzeugen, beispielsweise aus SGML-basierenden Repositories?

Einige Antworten liegen auf der Hand. So ist HTML zum gegenwärtigen Zeitpunkt für die Verwendung als generelles Repository-Format nicht umfangreich genug.

Da jede Applikation ihre individuellen Anforderungen hat, sollte HTML grundsätzlich nicht in dieser Richtung verwendet werden. Zum Aufbau eines unternehmenseigenen Repositories eignet sich SGML am besten, da es die Definition eigener DTDs erlaubt. HTML dagegen ist lediglich ein Vehikel zur Verteilung der im Repository enthaltenen Informationen über das Web. Mit der Aussage, HTML sei nicht umfangreich genug, büßt HTML natürlich einen Teil seiner Attraktivität ein. Anstatt eine "Universal-Lösung" zur Verteilung von Informationen über das Web zu sein, wird HTML zu einem weiteren Austauschformat reduziert, das geeignet ist, ein begrenztes Set von Web-Browsern anzusteuern.

Die Entwickler von HTML 3.0 haben dafür gesorgt, daß die Norm nicht ähnlich komplex wird wie CALS oder andere klassische Spezifikationen für die technische Dokumentation. Angesichts der erheblich differierenden Anforderungen von WWW-Anwendungen werden die Programmierer allerdings mit Anfragen nach kleineren, anwendungsspezifischen Erweiterungen geradezu überschwemmt. Es besteht also die Gefahr, daß der Standard überladen und damit unübersichtlich beziehungsweise nicht mehr handhabbar wird. In der Summe ist die Anzahl der potentiellen WWW-Anwender und deren Anforderungen um einiges höher als die des US- Verteidigungsministeriums. Die Vorstellung, all diese speziellen Wünsche zu realisieren, ist deshalb geradezu absurd.

HTML erlaubt nur begrenzte Strukturen

Andererseits birgt auch die Alternative, HTML um jeden Preis zu vereinfachen, einige Probleme. Die größte Gefahr besteht im Verlust von Informationen. Damit sind nicht der Inhalt eines Dokuments oder die Verbindungen (Links) zwischen Dokumenten gemeint, sondern Informationen etwa bei der Gestaltung. Umfangreiche Formatierungen, wie man sie von herkömmlichen Dokumenten gewohnt ist, sind mit HTML nicht möglich. Die einzigen Unterscheidungsmerkmale, die HTML zur Verfügung stellt, sind einige wenige Überschriften und Absatzformatierungen.

Herkömmliche Dokumente enthalten eine Vielzahl von Absatzformen (Zusammenfassung, Biographie, Einleitung, Glossar etc.), die in einem Web-Dokument verlorengehen. Alle Absätze müssen dort als "Paragraph" bezeichnet werden und erhalten die gleiche Formatierungsanweisung.

Ein anderes Problem ist, daß mit den HTML-Basisfunktionen die meisten intelligenten Suchalgoritmen, die auf der Strukturierung von Dokumenten beruhen, nicht angewendet werden können. Besonders wichtig ist dies im Hinblick auf die Informationsexplosion im Web. Dort gibt es zwar die Möglichkeit, sich über Links von einem Dokument zu einem anderen führen zu lassen, einen praktikablen Weg, um das Ausgangsdokument zu finden, kennt indes kaum jemand.

Man kann in "What's new"-URLs suchen, einen zwangsläufig begrenzten Index benutzen oder eine spezielle Software einsetzen, die nach bestimmten Wörtern oder Redewendungen sucht. In einer exponentiell anwachsenden Welt von Informationen gleicht das aber der sprichwörtlichen Suche nach einer Nadel im Heuhaufen. Es wäre deshalb schon sehr hilfreich, wenn man solche automatisierten Suchvorgänge auf Abstracts beschränken könnte oder aber auf Stichworte, die nur in einem bestimmten Zusammenhang auftreten.

Auch die sinnvolle Weiterverwertung von Dokumenten wird durch die HTML-Basisfunktionen erschwert. Die ursprüngliche Strukturierung, die für das Web auf ein Minimum reduziert wurde, läßt sich nicht ohne weiteres wieder herstellen. Es gibt keinen Weg, aus einer einzigen Formatierung wieder 20 verschiedene Strukturelemente abzuleiten.

An diesen Beispielen wird das Dilemma deutlich: Auf der einen Seite würde die Berücksichtigung aller Anforderungen zu einem völlig unübersichtlichen HTML-Standard führen. Andererseits hat die Beschränkung auf eine einfache, handhabbare Lösung zur Folge, daß der Dokumentenaustausch im Web an Attraktivität verliert.

Angesichts dieser Schwierigkeiten gab es Überlegungen, HTML nur noch für sehr einfache Dokumente einzusetzen. Danach sollten Web- Dokumente grundsätzlich nur noch in SGML mit einer Vielzahl von DTDs erstellt werden - je nach Ermessen des Anbieters. Die Argumente dafür sind einleuchtend: Eine einzige DTD - das kann beispielsweise HTML sein - ist nicht in der Lage, alle Anforderungen abzudecken. Anstatt zu standardisieren, was im Grunde nicht zu vereinheitlichen ist, sollte jedem Anwender, so die Überlegungen, die volle Leistungsfähigkeit und Funktionalität von SGML zur Verfügung stehen, um eigene Applikationen zu realisieren.

Dieser Meinung kann sich der Autor nicht anschließen. Obwohl selbst ein Verfechter von SGML, sollte HTML der primäre Backbone des Web bleiben und zwar aus folgenden Gründen:

- HTML ist mittlerweile als das Web-Format anerkannt. Der Versuch eine Änderung vorzunehmen würde nur Verwirrung stiften, wäre kontraproduktiv und letztlich zum Scheitern verurteilt.

- Obwohl es von großer Bedeutung ist, daß komplexe Dokumente über das Web verteilt werden können, sind die meisten Dokumente doch relativ einfach strukturiert. Es gibt deshalb keinen Grund, Anwender zum Einsatz der generalisierten SGML zu zwingen mit der Folge, daß jeder Anwender applikationsspezifische DTDs aufbauen oder zumindest aus einer Bibliothek auswählen müßte, wenn einige kleinere HTML-Erweiterungen für die meisten Anwender ausreichen würden.

- Selbst wenn das Web ausschließlich aus SGML-Dokumenten bestehen würde, wäre es notwendig, eine gemeinsame Semantik, also etwas ähnliches wie HTML, zu definieren. Ohne eine gemeinsame Semantik ist ein standardisierter Ablauf von Navigation, Suche, Formatierung oder Wiederverwendung von Web-Dokumenten nahezu unmöglich.

Aus diesen Gründen ist es sinnvoll, an HTML als Web-Standard festzuhalten, wenn auch mit der Möglichkeit, HTML und SGML in intelligenter Weise parallel einzusetzen. Die Frage ist nicht HTML oder SGML, sondern wie sich beide Technologien ergänzen können, um eine echte, skalierbare Architektur aufzubauen, die die Verteilung von einfachen und komplexen Dokumenten erlaubt.

Hier ein Beispiel für Skalierbarkeit: Will man eine Nachricht mit dem Inhalt "Hallo Welt" versenden, so werden dazu nicht mehr als zwei oder drei HTML-Tags benötigt. Soll jedoch der jährliche Unternehmensbericht über das Web veröffentlicht werden und dieser auch noch dem gedruckten Original möglichst ähnlich sein, legt man darüber hinaus auch noch Wert auf die Möglichkeit, gezielt nach Informationen im Text, in Tabellen oder Grafiken suchen zu können, dann werden eine Vielzahl von Tags benötigt. Unter Umständen ist sogar eine anwendungsspezifische SGML-Applikation sinnvoll, die sich über das Web ohne Probleme realisieren läßt.

Für einfache bis komplexe Dokumente skalierbar

Es ist durchaus möglich, diesen Jahresbericht über das gleiche HTML-File sowohl an eine hochentwickelte Grafik-Browser- und Retrieval-Engine als auch an einen einfachen Terminal-Viewer zu schicken. Jeder dieser Viewer/ Browser kann etwas Sinnvolles mit der Information anfangen. Es gibt auch keine grundsätzlichen Hindernisse, einen einfachen Viewer zu bauen, der jedes Dokument unabhängig von seiner Komplexität lesen kann. Das gilt sowohl für reine HTML- als auch für SGML-DTDs.

Eine einfache, aber skalierbare HTML-Lösung sollte auf mehreren Grundsätzen basieren:

Zum einen muß ein akzeptables Framework für Navigation und Linking zur Verfügung gestellt werden. Es enthält nur soviel strukturelle Bedingungen wie unbedingt notwendig.

Man benötigt selbstverständlich Überschriften-Ebenen in mehreren Stufen und einige hierarchische Bedingungen. Es sollten aber Kosten vermieden werden, die durch den Aufbau von DTDs entstehen, um Dokumentenstrukturen aller Art zu unterstützen. Anwender, die komplexe, CALS-ähnliche Dokumente mit Hilfe von SGML durchsuchen wollen, können das mit eigenen DTDs tun. HTML muß über ausreichende Strukturen verfügen, um unter anderem eine Top-level- Navigation zu ermöglichen, Links aufzubauen und Tabellen zu beschreiben. Außerdem muß die Funktionalität ausreichend sein, um semantische Unterscheidungen zwischen anderen Elementen zu treffen.

Es wird nur das absolut notwendige Minimum an Tags und Attributen verwendet.

Um die Nachricht "Hallo Welt" zu kodieren, muß in CALS eine sehr große Anzahl von Tags verwendet werden, weil CALS selbst eine große Zahl von Elementen vorschreibt. CALS war von vornherein nicht skalierbar angelegt, sondern lediglich dazu gedacht, militärische Spezifikationen in komplexen Dokumenten zu beschreiben und Text, Produktdaten sowie andere Informationen in einer speziellen Datenbasis zusammenzufassen. In HTML sollten Elemente und Attribute nur dann verwendet werden, wenn es sinnvoll ist. So muß zum Beispiel gefordert werden, daß ein Link immer auf ein bestimmtes Ziel verweist. Es ist dagegen nicht unbedingt notwendig, daß ein Dokument immer eine Hauptüberschrift hat.

Der wichtigste Punkt ist ein objektorientierter Ansatz mit einem kleinen Satz von standardisierten Element-Klassen, der vom Anwender um komplexere Objekte wie Tabellen, Grafiken, mathematische Formeln oder Formulare als definierte Layer erweitert werden kann.

Der Grundgedanke dabei ist, auf einer einfachen Basis von Element- Klassen (zum Beispiel einige Überschriftenebenen und Standard- Absatzformate) aufzusetzen, die nicht komplexer sind als die Basiselemente in HTML 2.0. Der Anwender kann durch Erzeugen von Unterklassen einen zusätzlichen, umfangreichen Satz von semantischen Unterscheidungsmerkmalen aufbauen.

HTML beispielsweise kennt zur Bezeichnung von Texten nur das Absatzformat "Paragraph". Weitere Unterscheidungsmerkmale wie Vorspann, Einleitung, Zusammenfassung, Anmerkungen usw. sind nicht vorgesehen, auch wenn sie für die Informationsrückgewinnung nützlich und sinnvoll wären. Alle diese Elemente erhalten die Bezeichnung "Paragraph" - es gibt einfach keine andere Wahl.

Angepaßtes SGML ist eine Alternative für das Web

Die Einschränkungen von HTML haben auch dazu geführt, über "customized SGML" nachzudenken. SGML erlaubt, Elementen beliebige Namen zu geben. Damit taucht aber ein Problem auf. SGML erlaubt zwar höchste Flexibilität und Skalierbarkeit, enthält aber keinerlei Standardisierungs-Ansätze, selbst nicht für solch grundlegenden Funktionen wie Navigation und Links - dafür ist SGML nicht konzipiert. Ein DTD-Designer kann einen Hyperlink mit "a" bezeichnen, ein anderer mit "xref".

Der entscheidende Punkt ist: Mit der allgemeinen SGML gibt es keine Möglichkeit, die Verbindungen zwischen den Elementen in beliebigen DTDs und die Semantik, die ein Browser, eine Such- oder Download-Software benötigt, zu bestimmen. Startet man eine Suche im Web, will man den Links folgen können, ohne jede individuelle SGML-Struktur analysieren zu müssen und herauszufinden, wie sie auf allgemeingültige Objekt-Klassen abgebildet werden muß. Ohne zusätzliche Kenntnisse über die interne Struktur nützt aber auch die entsprechende DTD nichts.

Also muß ein anderer Weg eingeschlagen werden. HTML muß verallgemeinert und erweitert werden, so daß seine Semantik von allen gebräuchlichen Web-Browsern, Retrieval-Produkten und anderen Applikationen verstanden wird. Mit diesem Ansatz ist es möglich, individuelle Web-Dokumente mit beliebigen DTDs in SGML zu kodieren. Jedes SGML-Element in einer DTD wird bei Bedarf auf eine der Standard-HTML-Klassen abgebildet.

Dazu ein Beispiel: Eine DTD hat die Elemente mit den Bezeichnungen "Artikel", "Zusammenfassung", "Vorwort", "Para" und "Sprung". Damit jeder Browser sofort die Basisstruktur des Dokuments erkennt, enthält eine "Standard Map" die Informationen, daß "Artikel" vom Typ "Überschrift" ist, "Zusammenfassung", "Vorwort" und "Para" vom Typ "Absatz" und "Sprung" ein Hyperlink ist.

Die Mehrzahl der einfachen Web-Dokumente wird weiterhin die SGML- DTD mit der Bezeichnung HTML benutzen, bei der alle Elemente auf gemeinsame Objekt-Klassen abgebildet werden. Aber auch diese DTD läßt sich erweitern, um ein gewisses Maß an Skalierbarkeit zu erhalten, ohne jedoch gleich zu einer anwendungsspezifischen SGML- Applikation zu werden.

Kurz & bündig

Während sich der SGML-Standard für das Management komplexer Dokumente eignet, ist das SGML-Derivat HTML zur Verteilung einfach strukturierter Dokumente im Web gedacht. Diese Grenzen will der Autor mit Hilfe von objektorientierten Erweiterungen aufheben, so daß skalierbare Mischlösungen entstehen.

*Eric Severson ist Vice-President und Chefstratege der Interleaf Inc. in Boulder Colorado. Die deutsche Interleaf-Niederlassung befindet sich in Eschborn.