SGML – Mit Kanonen auf Spatzen

(Auszug aus "DITA - Der neue Standard für Technische Dokumentation" von Johannes Hentrich)

Mit SGML wurde von IBM Mitte der sechziger Jahre im vorigen Jahrhundert eine Meta-Sprache konzipiert, die es ermöglicht, Auszeichnungssprachen für elektronische Dokumente zu entwickeln. Ein bekanntes Beispiel für eine aus SGML entwickelte Auszeichnungssprache ist das im Internet allgegenwärtige HTML (Hypertext Markup Language).

SGML wurde mit dem Ziel entwickelt, elektronische Dokumente sowohl unabhängig von einer bestimmten Plattform als auch von einer bestimmten (Computer-)Anwendung oder eines Dateiformats erstellen zu können. Damit soll gewährleistet werden, dass der Austausch von Dokumenten jederzeit zwischen unterschiedlichen Computersystemen durchführbar ist.

Um dies zu ermöglichen, muss bei einem Dokument der Inhalt vom Layout getrennt werden. SGML befasst sich ausschließlich mit der Auszeichnung von Inhalten beziehungsweise mit der Strukturierung von Inhalten. Die Inhalte werden über so genannte Elemente ausgezeichnet. Elemente und deren Eigenschaften können mittels Attributen näher beschrieben werden. Die Definition der Elemente und der Attribute wird in einer so genannten DTD (Document Type Definition) vorgenommen

Daneben enthält eine DTD einen Satz an Regeln, der verwendet wird, Dokumente eines bestimmten Typs, so genannte Dokumenttypen, zu repräsentieren. Ein Dokumenttyp stellt dabei eine Klasse ähnlicher Dokumente dar. Installationsanweisungen beispielsweise stellen eine andere Klasse an Dokumenten dar als Tutorials.

Eine Meta-Sprache wie SGML ermöglicht die Definition eigener Elemente und Attribute. Damit besteht die Möglichkeit, Elemente zu definieren, um Inhalte ihrer Bedeutung nach auszeichnen zu können. Beispielsweise könnte ein neu definiertes Element mit dem Namen <author> dazu verwendet werden, den Verfasser eines Dokuments zu kennzeichnen:

<author>Charles Darwin</author>

Diese Art von Auszeichnung wird als semantische Auszeichnung bezeichnet.

Daneben besteht auch die Möglichkeit, Inhalte nach ihrer gewünschten Formatierung im Ausgabemedium auszuzeichnen. Diese Art von Auszeichnung wird als „typografische Auszeichnung“ bezeichnet. Hier werden Elemente definiert, um beispielsweise Inhalte im Ausgabemedium mit Kursiv- oder Fettschrift darstellen zu können. So verwendet sowohl HTML als auch DITA Elemente wie <b> für die Verwendung von Fettschrift und <i> für die Verwendung von Kursivschrift. Im folgenden Beispiel wird der Inhalt mit Fettschrift ausgezeichnet:

<b>Der Inhalt wird in HTML fett ausgegeben.</b>

Während eine typografische Auszeichnung immer darauf abzielt, ein bestimmtes Ergebnis in einem Ausgabemedium zu erlangen, orientiert sich die semantische Auszeichnung zunächst einmal nicht daran, wie die ausgezeichneten Inhalte in einem Ausgabemedium später einmal ausgegeben werden sollen.

Eine semantische Auszeichnung der Inhalte bietet aus folgenden Gründen zahlreiche Vorteile:

  • Eine intelligente Suche wird ermöglicht. Nach semantischen Inhalten kann gezielt gesucht werden, vorausgesetzt, ein entsprechendes System unterstützt die Suche nach Inhalten in einzelnen Elementen. Werden Inhalte innerhalb eines bestimmten Elements gesucht, so wird dadurch automatisch die Suche eingeschränkt. Eine Suche nach „Fink“ innerhalb eines <author>-Elements schließt mit Sicherheit alle Treffer aus, die sich auf den Vogel gleichen Namens beziehen. Wie schwierig sich eine Suche gestaltet, wenn Inhalte nicht semantisch ausgezeichnet werden, zeigt insbesondere das Internet. Eine Suche nach „Fink“ ergibt (bei Google) ca. 16.900.000 Treffer. Erst ausgeklügelte Algorithmen von Google können den Treffern eine gewisse Relevanz verschaffen. Auch in der Technischen Dokumentation kommt dem intelligenten Zugriff auf Informationen eine besondere Bedeutung zu – sowohl im Erstellungsprozess als auch bei der Nutzung. Ein Technischer Redakteur muss bei einer modularen Dokumentation, die wie bei DITA in zahlreiche einzelne Dokumente aufgeteilt sein kann, schnell in der Lage sein, die zu bearbeitenden Inhalte finden zu können. Auch dem Nutzer der Technischen Dokumentation können effektivere Zugriffsmechanismen auf die Inhalte der Technischen Dokumentation zur Verfügung gestellt werden, sofern der Zugriff auf die Informationen auf elektronischem Weg erfolgt.
  • Informationen können besser wiederverwendet werden. Bei der Auszeichnung der Inhalte mit Elementen werden die Inhalte quasi in Container gepackt. Wenn die Container dann noch mit einer eindeutigen Kennung versehen werden, können die Container auf einfache Weise und beliebig häufig referenziert werden. Von dieser Methode macht DITA ausgiebig Gebrauch.
  • Elemente können abhängig vom Ausgabemedium unterschiedlich ausgegeben werden. Soll beispielsweise der Inhalt des <author>-Elements in einer Online-Hilfe mit blauer Schrift hervorgehoben werden, in einer PDF-Datei jedoch in schwarzer Schrift und kursiv gesetzt werden, kann dies über unterschiedliche Stylesheets für die Online-Hilfe und die PDF-Datei realisiert werden. Dies funktioniert deshalb, da in Elementen keine Information hinterlegt ist, wie sie formatiert werden soll. Dies gilt auch für typografische Auszeichnungen. Eine Auszeichnung mit dem <b>-Element für Fettschrift gibt dem Entwickler des Stylesheets lediglich einen Hinweis, dass der Inhalt innerhalb dieses Elements auf besondere Weise, das heißt, wenn möglich in fetter Schrift gesetzt werden soll. Dies kann für HTML-Seiten durchaus realisiert werden, die in einem Browser angezeigt werden, aber unter Umständen nicht möglich sein, wenn eine HTML-Seite in einem Mobiltelefon angezeigt werden soll.

Fasst man die bei der Entwicklung von SGML gesteckten Ziele und der damit verbundenen Prinzipien zusammen, so stellt sich heraus, dass sie von der Sache her einfach konzipiert sind: Die Inhalte werden vom Layout getrennt. Die Inhalte können über frei definierbare Elemente und deren Attribute format-unabhängig ausgezeichnet werden. Das Layout wird in einem späteren Verarbeitungsprozess den Inhalten der Elemente zugeordnet.

So einfach die Prinzipien auch sind, so schwierig erweist sich deren Umsetzung in die Praxis.

Mit SGML steht zwar ein universelles Werkzeug zur Verfügung, um die Definition von fast beliebig komplexen Dokumenttypen und der sie definierenden Elemente zu ermöglichen. Jedoch wurde und wird die Kehrseite der gewonnen Freiheit oft unterschätzt: Es war und ist sehr aufwändig, die den Dokumenttypen zugrunde liegenden DTDs zu definieren.

Denn in der Praxis ist ein Werkzeug zur Definition von Dokumenttypen zunächst wenig hilfreich, da für die Erstellung von Technischer Dokumentation eine fertige Dokumentenstruktur, das heißt ein fertiger Dokumenttyp benötigt wird. Und der Weg zu einer Dokumentenstruktur beziehungsweise zu deren zugrunde liegender DTD kann unter Umständen sehr lang sein.

Steht man erst am Anfang der Entwicklung einer DTD, so ist es notwendig, sich unter anderem mit den folgenden Fragen zu beschäftigen:

  • Welche Grobstruktur weisen die Dokumente auf?
  • Wie weit soll die Struktur verfeinert werden?
  • Welche sonstigen Strukturen innerhalb der Dokumente sollen noch abgebildet werden?
  • Welche Abhängigkeiten weisen die Strukturelemente auf?
  • Welche Elemente soll es für die semantischen und die typografischen Auszeichnungen geben?
  • Gibt es Abhängigkeiten zwischen Elementen von semantischen und typografischen Inhalten?
  • Welche Mechanismen sollen zur Verfügung stehen, um auf die Elemente zugreifen zu können?

Abhängig davon, ob noch Spezialfälle berücksichtigt werden müssen oder ob eine DTD mehrere Dokumenttypen abdecken soll, kann der Fragenkatalog noch deutlich umfangreicher ausfallen. Eine gute Anleitung, wie bei der Entwicklung einer DTD vorzugehen ist, bietet das Buch von Eva Maler und Jeanne El Andaloussi Developing SGML DTDs. Nebenbei zeigt es aber auch, wie komplex der Erstellungsprozess einer DTD sein kann.

Insbesondere wenn nur wenige Handbücher zu produzieren sind, lohnt sich der Aufwand zur Erstellung einer DTD kaum. Der Analyse- und der Definitionsprozess einer DTD kann unter Umständen mindestens so lange dauern, wie die Erstellung der eigentlichen Technischen Dokumentation. Unter diesen Bedingungen wird die Technische Dokumentation schlichtweg zu teuer.

Dies hatte zur Folge, dass SGML vor allem nur von Firmen und Institutionen angewandt wurde und wird, die unter dem Zwang standen, eine standardisierte DTD bereitstellen zu müssen, damit sowohl die Dokumente in der gewünschten Form angeliefert werden können, die durch eine DTD vorgegeben sind, als auch Dokumente zur Verfügung zu stellen, die auf Basis einer DTD untereinander ausgetauscht werden können. Daher findet man heute SGML-DTDs für die Technische Dokumentation insbesondere in großen Industriezweigen wie in der Telekommunikations-, Automobil- oder Flugzeugindustrie. Für „kleine“ Lösungen hingegen hat sich SGML als wenig praktikabel erwiesen.

SGML „light“

Um dennoch die Vorteile von SGML nutzen zu können, das heißt, neben plattform- und anwendungsunabhängigen Dokumenten auch strukturierte Dokumente erstellen zu können, wird oft mit einer halbherzigen SGML-Lösung vorlieb genommen. Das heißt, es wird zwar SGML verwendet, aber die dabei zugrunde liegende DTD ist ziemlich einfach gestrickt.

Bei solchen DTDs wurde weitgehend auf eine umfangreiche Analyse der bestehenden Dokumentenarten verzichtet und nur Elemente in die DTD aufgenommen, die allgemeingültig in einem Dokument oder in den verschiedenen Dokumentenarten verwendet werden können.

Das folgende Beispiel zeigt die Strukturansicht eines SGML-Dokuments, welches eine einfache DTD verwendet. Im Wesentlichen beschränken sich die Strukturelemente auf Absätze (paragraph-Element), Marginalien (marg-Element), Tabellen (table-Element) und verschiedene Listenarten (list-b-Element, list-s-Element). Als einziges „exotischeres“ Element findet sich in dem Beispiel ein Element zur Auszeichnung eines Hinweises (note-Element).

Eine einfache SGML-Struktur

Abbildung: Eine einfache SGML-Struktur.

Ein typisches Merkmal einer einfachen DTD ist das Fehlen so gut wie jeglicher semantischer Auszeichnung. Ein paragraph-Element enthält bestenfalls typografische Auszeichnungen wie Elemente zur Auszeichnung von Fett- und Kursivschrift und Elemente zur Auszeichnung von Indexeinträgen und Querverweisen.

Aus der Struktur und den verwendeten Elementen ist nicht ersichtlich, um welchen Dokumenttyp es sich handelt. Ob hier Informationen angeboten werden, die den Nutzer zu einer Handlung auffordern, oder ob Informationen angeboten werden, die der Nutzer benötigt, um ein Konzept zu verstehen, bleibt dem Betrachter und dem Nutzer der Struktur verschlossen. Und die fehlenden semantischen Auszeichnungen können natürlich auch keinen Aufschluss darüber geben, was hier beschrieben wird.

Tatsächlich erinnert die verwendete Struktur mit ihrer Aneinanderreihung von Titeln, Absätzen, Tabellen und Listen an HTML, welches selbst eine SGML-Anwendung ist. Der Vergleich mit HTML ist nicht zufällig, denn bei der Entwicklung von HTML war eines der primären Ziele, eine DTD zu schaffen, die möglichst wenig Elemente enthält, mit denen jedoch möglichst viel ausgezeichnet werden kann.

Da mit Elementen, wie sie beispielsweise für HTML definiert worden sind, fast beliebiger Inhalt erfasst werden kann, wird diese Art von Auszeichnung als „generisches Markup“ bezeichnet. Die Elemente dienen als neutrale Informationscontainer, deren Inhalte wenig Bezug zu den Elementen aufweisen. Oftmals werden die Informationscontainer auch dazu verwendet, nicht nur Inhalte zu erfassen, sondern sie auch zu formatieren. Das <table>-Element in HTML dürfte dafür das bekannteste Beispiel darstellen. Mit diesem Element werden nicht nur Tabellen formatiert, sondern häufig wird damit auch das Layout einer HTML-Seite strukturiert.

Dieses generische Markup ersparte zwar die Entwicklung einer komplexen DTD, mit der zum Beispiel eine passende Struktur und die semantischen Auszeichnungen für ein Administrationshandbuch für ein Softwareprodukt bereit gestellt werden können, aber die Nachteile sind nicht von der Hand zu weisen. Insbesondere der bei HTML so beklagte Mangel, Inhalte nur in sehr eingeschränkter Form wiederverwenden zu können, oder das Fehlen der Möglichkeit, Inhalte kontextabhängig zu suchen, zeigt sich in aller Deutlichkeit auch bei Dokumenten, die auf einer generischen DTD basieren.

Ein weiterer Nachteil von generischem Markup offenbart sich dann, wenn solche Dokumente beispielsweise in XML-Strukturen wie DITA übergeführt werden sollen. DITA weist einen deutlich höheren Grad an Strukturierung auf und ermöglicht sowohl die Auszeichnung der Inhalte gemäß ihres Typs, das heißt, ob Aufgaben, Konzepte, Referenzinformationen oder Glossareinträge beschrieben werden, als auch eine Auszeichnung der Inhalte gemäß ihrer Bedeutung. Die Überführung der mit generischem Markup ausgezeichneten Inhalte nach DITA unterscheidet sich nur wenig von der Überführung von unstrukturierten Dokumenten, zum Beispiel Word-Dateien, nach DITA. „Der Umstieg auf DITA“ geht detailliert auf die Fragen ein, wie bestehende unstrukturierte, beziehungsweise nur wenig strukturierte Dokumente nach DITA übergeführt werden können.

Als wesentliches Hindernis für die Verbreitung von SGML erwies sich also, dass es keine allgemein zugänglichen DTDs gab, die kleinere und mittlere Unternehmen als Basis für ihre Technische Dokumentation verwenden konnten. In der Not entschied man sich daher oftmals für einfache DTDs, die eine generische Auszeichnung ermöglichten. Die Grenzen solcher DTDs wurden aber häufig nur deutlich, als man, aus welchen Gründen auch immer, sich dazu gezwungen sah, die generischen Dokumente in stärker strukturierte Dokumente überzuführen.

Erst mit der DocBook DTD, deren Entwicklung 1991 begann, wurde erstmals eine DTD kostenfrei öffentlich zur Verfügung gestellt, die auch in dem Bereich der Technischen Dokumentation angewendet werden konnte. In „Wider die Topics: DocBook“ wird dieser Standard genauer vorgestellt und einem Vergleich mit DITA unterzogen. Schon hier sei angemerkt, dass DocBook das Konzept beziehungsweise die Struktur eines gedruckten Buchs zugrunde liegt. Deshalb können einige Anforderungen aus der Technischen Dokumentation, wie zum Beispiel das Publizieren von linearen Handbüchern und das Produzieren von topicbasierten Online-Hilfen, aus einer einzigen Datenquelle nur mühsam mit DocBook realisiert werden.

Weiterverarbeitung von SGML

Als weiteres Hindernis für die Verbreitung von SGML stellte sich die Schwierigkeit heraus, die elektronischen SGML-Dateien in ein Ausgabeformat zu konvertieren, das die Produktion von bedrucktem Papier erlaubt. Zwar steht mit DSSSL (Document Style Semantics and Specification Language) eine Formatierungssprache zur Verfügung, aber ebenso wie bei SGML ist die Komplexität der Sprache nicht dazu angetan, die benötigen Stylesheets mühelos und kostengünstig für die Ausgabe erstellen zu können.

Als Lösung des Problems wurde unter anderem der Weg eingeschlagen, Editoren zu entwickeln, die mit SGML-Dateien „irgendwie“ umgehen konnten. Neben einer möglichen WYSIWYG-Darstellung des SGML-Dokuments sollte auch auf bekannte Produktionsmechanismen zurückgegriffen werden können, wie beispielsweise auf den Mechanismus zur Produktion einer PDF-Datei. Adobe FrameMaker machte sich in der Technischen Dokumentation hier einen Namen und bot sowohl die WYSIWYG-Funktionalität als auch über den Acrobat Destiller die passende Software zur Produktion von PDF-Dateien an.

Der Nachteil bei FrameMaker und ähnlichen Lösungen besteht darin, dass sie nicht mit nativem SGML arbeiten, das heißt mit der eigentlichen SGML-Datei. Bei FrameMaker muss eine so genannte EDD (Element Definition Document) erstellt werden, welche die Struktur der SGML-Anwendung und ihrer Formatierung in FrameMaker wiedergibt. Bearbeitet werden somit nicht die eigentlichen SGML-Dokumente, sondern die FrameMaker-Dokumente, die die SGML-Dokumente abbilden.

Um eine SGML-basierte Dokumentation erstellen und bearbeiten zu können, ist neben der Entwicklung einer DTD für die SGML-Dokumente des Weiteren noch die Entwicklung einer EDD für FrameMaker erforderlich. Für komplexe DTDs bedeutet dies, dass auch komplexe EDDs erstellt werden müssen. WYSIWYG und ein gängiger Produktionsmechanismus fordern damit ihren Preis.

Die Schwierigkeit SGML auf einfache Weise weiterzuverarbeiten beziehungsweise überhaupt erst anwenden zu können, hat dazu geführt, dass SGML nie den großen Durchbruch geschafft hat. Insbesondere kleineren und mittleren Dokumentationsabteilungen blieb die Verwendung von SGML aufgrund des dafür notwendigen immensen Aufwands vorenthalten.

Somit bleibt und blieb SGML mehr oder minder einem exklusiven Kreis vorbehalten, der die Kosten für den Einsatz nicht scheut. Ein abgespecktes SGML in Form von generischem Markup ermöglichte es den „kosten-sensitiven“ Anwendern immerhin, eine Auszeichnungssprache zu verwenden, ohne jedoch innewohnende Möglichkeiten wirklich nutzen zu können. Wie wenig generisches Markup zu leisten imstande ist, zeigt sich den Andwendern von generischem Markup dann, wenn daraus gut strukturierte Dokumente, wie zum Beispiel für DITA, produziert werden sollen.

So bietet SGML zwar alle Möglichkeiten, um beliebig komplexer Dokumenentstrukturen Herr zu werden, jedoch nur auf Kosten von einer kaum bewältigbaren Komplexität.

  

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema DITA bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

Copyright © 2008 XLcontent Verlag
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "DITA - Der neue Standard für Technische Dokumentation" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

XLcontent Verlag, Pflegerstraße 40, 81247 München