Teilbericht

Das Inhaltsverzeichnis steht hier.
Das Stichwortregister steht hier.

Dokumentation der SAUS Document Type Definition Dokumentation der SAUS Document Type Definition

Autoren:

Jan Kuhlmann kelvin, Matr. Nr. 890574

Datum: 05.03.96

Zusammenfassung:

In der Document Type Definition des Projekts SAUS hat sich eine Menge getan. Die Document Type Definition stellt die logischen (und manchmal auch layout-spezifische) Elemente zur Verfügung, die dür eine Dokumentation im Rahmen des Projekts nötig sind. Dieser Bericht dokumentiert die Fähigkeiten der saus.dtd anhand zahlreicher Beispiele.

Einleitung

Die maschinellen Interpretation eines in SGML geschriebenen Dokuments basiert auf einer sog. Document Type Definition. Die Document Type Definition beschreibt die logische Syntax, die in einem Dokument verwendete werden muß, damit ein es übersetzt und in andere Formate wie LaTeX oder HTML überführt werden kann. In dieser Dokumentation werden die Fähigkeiten der Document Type Definition des Projekts SAUS beschrieben. Diese Document Type Definition hat den Namen saus.dtd und steht im Verzeichnis $(SGMLDIR)/dtd/.

Elemente der Document Type Definition

Beschreibungsformat

In dieser Dokumentation hat jedes Element bzw. jede scharf umrandete Elementgruppe einen eigenen Abschnitt. In jedem dieser Absätze werden diese Elemente bzw. Elementgruppen nach folgendem Schema beschrieben:

Beschreibung des Layouts, bzw. ein Layout-Beispiel
Aufzählung der Unterelemente mit Verweis auf die entsprechenden Abschnitte
Ausschnitt aus der saus.dtd
Gegebenenfalls ein Beispiel

Der Anfang und die Dokumenttypen

Die erste Zeile eines SGML-Dokuments beginnt für das Projekt SAUS mit dem folgenden Eintrag:

<!DOCTYPE saus SYSTEM "/sgml/dtd/saus.dtd"[]> Hier werden das erste Starttag und die zu benutzende Document Type Definition festgelegt. Das erste Starttag lautet <saus>, so daß also die zweite Zeile des Dokuments lauten muß: <saus> Als nächstes ist man vor die Wahl gestellt, was man eigentlich schreiben möchte. Man kann eine der folgenden Möglichkeiten wählen:

Ein Bericht ( bericht): Dies wird der Gesamtbericht, wie er abgegeben wird.
Teilberichte ( teilber): In diesem Dokumenttyp sollen die einzelnen Projektgruppen ihre Arbeit vorstellen. Der Gesamtbericht setzt sich hauptsächlich aus Dokumenten diesen Typs zusammen.
Referate ( referat): Mündlich gehaltene Vorträge sollen in diesem Format geschrieben werden.
Dokumentationen ( doku): Dieser Dokumenttyp ist zur Beschreibung von Softwareschnittstellen vorgesehen. Man kann in ihm Quellcode und Klassen dokumentieren.
Protokolle ( protokol): Die wöchentlichen Protokolle der Projekttreffen sollen in diesem Format geschrieben werden.
Ein Glossar ( glossary): Der Glossar soll Erläuterungen für Begriffe enthalten, die in anderen Dokumenten verwendet werden, aber nicht selbsterklärend sind.
Folien ( slides): Mit diesem Dokumenttypen kann man Folien erstellen.

Der Bericht (<bericht>)

Dieses wird der Endbericht. Über seine Eigenschaften muß noch verhandelt werden.

Teilberichte (<teilber>)

Aus Dokumenten diesen Typs soll sich der spätere Endbericht zusammensetzen. Jeder Teilbericht hat eine Titelseite mit einem Titel, den Namen der Autoren, einem Datum und eventuell Fußnoten zu den einzelnen Autoren. Es folgen Inhaltsverzeichnis, Tabellenverzeichnis und Bildverzeichnis, bevor der eigentliche Text beginnt. Am Schluß befinden sich ein Literaturverweis und ein Register.

Der Teilbericht besteht also aus folgenden Elementen:

optionale Einstellungen zur Abschaltung von Verzeichnissen ( settings)
Titelseite mit Titel, Autoren und Datum ( titlepag)
eine optionale Markierung, um im Gesamtbericht Referenzen auf den Teilbericht zu ermöglichen ( xref)
Themen als Stichworte für das Indexregister ( keywords)
Kurzinhalt ( abstract)
Textabschnitten ( section)

Der entsprechende Eintrag in der saus.dtd lautet:

<!ELEMENT teilber - - (settings?,titlepag,label?,keywords?,abstract,section+)>

Ein Teilbericht könnte z.B. folgendermaßen beginnen:

<!DOCTYPE saus SYSTEM "/sgml/dtd/saus.dtd"[]> <saus> <teilber> <settings> <nobiblio> </settings> <titlepag> <title>Dokumentation der SAUS Document Type Definition</title> <authors> <author> <realname>Jan Kuhlmann</realname> <uid>kelvin</uid> <thanks>Matr. Nr. 890574</thanks> </author> </authors> <curdate> </titlepag> <abstract> <p> < /p> </abstract> <section title="Einleitung"> ... </section> </teilber> </saus> Das Beispiel erklärt auch viele der Elemente, die erst in späteren Abschnitten angesprochen werden. Für nähere Informationen zu solchen Elementen sei auf die entsprechenden Abschnitte verwiesen.

Referate (<referat>)

Das Referat hat exakt das gleiche Aussehen wie der Teilbericht (s. Kap. teilber, S. teilber). Aus diesem Grund verzichte ich an dieser Stelle auf den Eintrag in der saus.dtd und ein Beispiel.

Code- und Klassendokumentationen (<doku>)

Dieser Dokumenttyp dient der Dokumentation von Quellcode und Objektklassen. Auf eine Titelseite und ein Inhaltsverzeichnis folgt die Dokumentation und Literatur- sowie Indexregister.

Eine Dokumentation besteht aus folgenden Elementen:

optionale Einstellungen zur Abschaltung von Verzeichnissen ( settings)
Titelseite mit Titel, Autoren und Datum ( titlepag)
eine optionale Markierung, um im Gesamtbericht Referenzen auf die Dokumentation zu ermöglichen ( xref)
Themen als Stichworte für das Indexregister ( keywords)
Kurzinhalt ( abstract)
Dokumentationstext ( srcdoku)

Der Eintrag in der saus.dtd lautet:

<!ELEMENT doku - - (settings?,titlepag,label?,keywords?,abstract,srcdoku+)>

Protokolle (<protokol>)

Mit diesem Dokumenttypen können Protokolle geschrieben werden. Protokolle haben keine Titelseite und keine Verzeichnisse.

Ein Protokoll enthält:

Datum als Freitext ( date)
Dauer ( dauer)
ein Autor ( authors)
Anwesenden ( anwesend)
Themen als Stichworte für das Stichwortregister ( keywords)
Tagesordnungspunkte ( tops)

In der saus.dtd sind Protokolle wie folgt definiert:

<!ELEMENT protokol - - (litdate,dauer,author,anwesend,keywords?,tops)>

Ein vollständiges Beispiel soll den Aufbau des Protokolls verdeutlichen:

<!DOCTYPE saus SYSTEM "/sgml/dtd/saus.dtd"[]> <saus> <protokol> <litdate>19.10.1995</litdate> <dauer>90 min</dauer> <author> <realname>Jan Kuhlmann</realname> </author> <anwesend>BKB, 5 Stipendiaten, 17 Studierende</anwesend> <tops> <top title="Organisatorisches"> <p> Auf die Frage nach projektbegleitenden Vorlesungen empfiehlt BKB die Veranstaltung 3-763: Entwicklung verteilter Systeme in CSP von Hui Shi Freitags von 0800-1200 in MZH 7210. </p> <p> Eine Liste mit Leistungseinschätzungen will BKB an das Projektbrett hängen. </p> </top> ... </tops> </protokol> </saus>

Die meisten Einträge sind durch dieses Beispiel vollständig erklärt. Im Unterschied zu Teilbericht, Referat und Codedokumentation kann im Protokoll nur ein Autor erwähnt werden. Für nähere Informationen zu einzelnen Einträgen sei auf die entsprechenden Kapitel verwiesen.

Glossare (<glossary>)

Folien (<slides>)

Dieser Dokumenttyp ist speziell für Folien gedacht: Der Text wird auf die Folienhöhe gestreckt, und es wird ein besonders großer Zeichensatz verwendet. Jede Folie kann um 90° gekippt werden. Eine Folie hat eine Überschrift und kann einen frei definierbaren Text im Kopf haben, z.B. ein Datum oder den Namen des Autors. Folien werden nicht durchnummeriert. Bei Folien entfallen alle Formalitäten der Teilberichte, Referate und Dokumentationen.

Folien anthalten einzelne Folien, die folgende Elemente enthalten:

Titel (Attribut title)
Schalter für das Kippen der Folie (erlaubte Werte: "ja" bzw. "nein", die Voreinstellung ist "nein") (Attribut sideways)
optionaler Text für die rechte obere Seite der Folie (Attribut text)
Textabsätze ( p)

Dazu wieder der Eintrag in der saus.dtd:

<!ELEMENT slides - - (slide+)> <!ELEMENT slide - O (p+)> <!ATTLIST slide title CDATA #REQUIRED sideways (ja|nein) "nein" text CDATA "">

Ein Beispiel soll die Verwendung von Folien veranschaulichen:

<!DOCTYPE saus SYSTEM "/sgml/dtd/saus.dtd"[]> <saus> <slides> <slide title="Folienüberschrift" sideways="ja" text="Jan Kuhlmann"> <p> <itemize> <item>Punkt 1</item> <item>Punkt 2</item> </itemize> </p> ... </slide> </slides> </saus>

Textelemente

Kurzinhalte (<abstract>)

Der Kurzinhalt (engl. "abstract") wird als Absatz in kleinerer Schrift vor den Anfang des eigentlichen Textes gesetzt.

Der Kurzinhalt enthält Absätze ( p).

Der Eintrag in der saus.dtd lautet entsprechend:

<!ELEMENT abstract - - (p+)>

Ein Beispiel zum Kurzinhalt findet sich unter den Teilberichten (Kap. teilber, S. teilber).

Tagesordnungspunkte (<tops>)

Tagesordnungspunkte sind die Abschnitte von Protokollen.

Sie enthalten einzelne Tagesordnungspunkte (<top>), die wiederum folgenden Elemente enthalten:

optionaler Titel (Attribut title)
eine optionale Markierung, um Referenzen auf diesen Tagesordnungspunkt zu ermöglichen ( xref)
beliebig viele Abschnitte ( p)
beliebig viele Fußnoten ( fnote)

In der saus.dtd sieht das dann so aus:

<!ENTITY % sectbeg "label?, p* " > <!ELEMENT tops O O (top+)> <!ELEMENT top - O (%sectbeg;) +(fnote)> <!ATTLIST top title CDATA "">

Das Beispiel zu den Protokollen (Kap. protokol, S. protokol) enthält auch eine Anwendung zu den Tagesordnungspunkten.

Abschnitte (<section>, <section1> usw.)

Abschnitte sind die Hauptgliederungselemente eines Dokuments. Ein Absatz hat immer eine Nummer und eine Überschrift und die meistens im Inhaltsverzeichnis des Dokuments erscheint. Die Größe dieser Überschrift richtet sich dabei nach der Schachtelungstiefe. Die SAUS-Document Type Definition unterscheidet fünf schachtelbare Absatztiefen (<section>, <section1>, <section2>, <section3> und <section4>).

Ein Absatz enthält:

Titel (Attribut title)
eine optionale Markierung, um Referenzen auf diesen Absatz zu ermöglichen ( xref)
beliebig viele Abschnitte ( p)
beliebig viele Absätze der nächsttieferen Schachtelungstiefe
beliebig viele Fußnoten ( fnote)
für <section4> gibt es einen Schalter, der bestimmt, ob der Titel dieses Abschnitts im Inhaltsverzeichnis erscheinen soll (erlaubte Werte: "ja" und "nein", Voreinstellung "ja") (Attribut verz)

In der saus.dtd sieht das so aus:

<!ENTITY % sectbeg "label?, p* " > <!ELEMENT section - O (%sectbeg;, section1*) +(fnote)> <!ATTLIST section title CDATA #REQUIRED> <!ELEMENT section1 - O (%sectbeg;, section2*)> <!ATTLIST section1 title CDATA #REQUIRED> <!ELEMENT section2 - O (%sectbeg;, section3*)> <!ATTLIST section2 title CDATA #REQUIRED> <!ELEMENT section3 - O (%sectbeg;, section4*)> <!ATTLIST section3 title CDATA #REQUIRED> <!ELEMENT section4 - O (%sectbeg;)> <!ATTLIST section4 title CDATA #REQUIRED verz (ja|nein) "ja">

Absätze (<p>)

Absätze sind die Gliederungselemente innerhalb von Abschnitten. Sie werden durch Leerzeilen voneinander getrennt.

Absätze können enthalten:

Text ( inline)
Listen ( itemize)
Formeln ( formula)
Bilder ( figure)
Tabellen ( tabular)
Wortgetreue Umgebungen ( code)

Die saus.dtd definiert Absätze folgendermaßen:

Wortgetreue Segmente (<code> und <verb>)

Worgetreue Segmente sind für den unübersetzten (1:1) Abdruck von Texten gedacht. In ihnen werden keine Entites übersetzt, und sogar SGML-tags dürfen im Klartext eingegeben werden. Allein Enttags (wie z.B. </saus> dürefn nicht benutzt werden, weil sich darüber der SGML-Übersetzer beschwert. Ansonsten werden alle Zeichen wortgetreu ausgegeben, sogar Leerzeichen und Zeilenumbrüche. Wortgetreue Segmente werden in Schreibmaschinenschrift ausgegeben. Sie beginnen immer in einer neuen Zeile, und Text nach der wortgetreuen Umgebung beginnt auch wieder in einer neuen Zeile. Die <code>-Umgebung setzt den wortgetreuen Text zusätzlich noch zwischen zwei horizontale Linien. Als Beispiele für das Aussehen von <code>-Umgebungen sollen die Zitate aus der saus.dtd reichen.

Wortgetreue Segmente enthalten Freitext.

Die Zeilen für wortegtreue Umgebungen in der saus.dtd:

<!ELEMENT verb - - RCDATA> <!ELEMENT code - - RCDATA>

Text (%inline;)

In vielen Elementen der SAUS Document Type Definition kann Text eingefügt werden. Hierbei handelt es sich nicht nur um Freitext, sondern auch um einzelne weitere Elemente, wie:

Hervorhebungen ( modified)
Schlüsselworte ( keywords)
Glossare ( glossary)
Dateinamen ( filename)
Referenzen ( xref)
wörtliche Rede ( quote)
Zitate ( quote2)
Identifizierer ( id)
mathematische Elemente ( formula)

Die saus.dtd definiert folgende Entities:

Wörtliche Rede (<quote>)

Wörtliche Rede wird in deutsche Anfühungszeichen ("") gestellt.

Sie enthält Text ( inline).

<!ELEMENT quote - - (%inline;)>

Zitate (<quote2>)

Zitate werden abgesetzt und beidseitig eingerückt dargestellt. Zu ihnen muß immer auch eine Quellenangabe vorhanden sein.

Zitate enthalten folgende Elemente:

Den eigentlichen Text ( quote).
Die Quellenangabe ( cite).

In der saus.dtd sieht das dann so aus:

<!ELEMENT quote2 - - (quote, (cite | ncite))>

Visualisierungselemente

Tabellen (<tabular>)

Tabellen sind Konstrukte zur Visualisierung von formatierbaren Daten. Sie sind in Zeilen und Spalten unterteilt, die jeweils durch Linien voneinander getrennt sein können. Sie können in gewissen Grenzen positioniert werden, mit einer Bezeichnung und einer Markierung für spätere Referenzierungen versehen werden.

Tabellenkonstrukte enthalten:

eine Positionierungsangabe (Voreinstellung "htbp", s.u.) (Attribut loc)
die eigentliche Tabelle (s.u.)
optionale Bezeichnung ( caption)
optionale Markierung zur späteren Referenzierung der Tabelle ( xref)

Die Werte der Positionierunsangabe haben in der LaTeX-Umsetzung folgende Bedeutung:

'h' für here, also an der Stelle der Definition
't' für top, also am Kopf der (ggf. nächsten) Seite
'b' für bottom, also am Fuß der (ggf. nächsten) Seite
'p' für page, also allein auf der nächsten Seite

Die eigentliche Tabelle steht in der <table>-Umgebung und enthält folgende Elemente:

eine Formatierungsangabe (s.u.) (Atrribut ca)
beliebig viele Zeilenumbrüche (<hline>, s.u.)
beliebig viele Datenzeilen (<tabrow>, s.u.)

Die Formatierungsangabe der Tabellen kann aus folgenden Zeichen in beliebiger Reihenfolge bestehen:

'l', für left, also eine linksbündige Spalte
'r', für right, also eine rechtsbündige Spalte
'c', für centered, also eine zentrierte Spalte
'p', gefolgt von einer Breitenangabe mit Einheit in geschweiften Klammern (also z.B. '{5cm}') zur Festlegung der Spaltenbreite. Text, der diese Breite überschreitet, wird umgebrochen. Zu beachten ist dabei, daß keine Worte getrennt werden, was zu unschönem Aussehen führen kann.
'|', also eine vertikale Linie zwischen den Spalten

Die Summe der Zeichen l, r und c bestimmt die Zahl der Spalten der Tabelle. Die einzelnen Spalten werden innerhalb einer Zeile mit dem Element <colsep> getrennt. Für nähere Informationen steht weiter unten ein Beispiel zur Verfügung.

Tabellen werden in der saus.dtd wie folgt definiert:

<!ELEMENT table - - (tabular, caption?, label?)> <!ATTLIST table loc CDATA "htbp"> <!ELEMENT tabular - - (hline | tabrow)*> <!ATTLIST tabular ca CDATA #REQUIRED> <!ELEMENT hline - O EMPTY> <!ELEMENT tabrow - O (%inline;, (colsep, %inline;)*)> <!ELEMENT colsep - O EMPTY>

rechtsbündig zentriert umgebrochen linksbündig

rot grün rot, grün und blau zugleich blau

Eine einfache Tabelle Eine Tabelle wie Tabelle tab00 kann wie folgt erzeugt werden: <table loc="h"> <tabular ca="r||c|p{2cm}|l"> <hline> <tabrow>rechtsbündig<colsep>zentriert<colsep>umgebrochen<colsep>linksbündig</tabrow> <hline> <hline> <tabrow>rot<colsep>grün<colsep>rot, grün und blau zugleich<colsep>blau</tabrow> <hline> </tabular> <caption>Eine einfache Tabelle</caption> <label id="tab00"> </table>

Bilder (<figure>)

Die Bildumgebung erlaubt es, Bilder in einen Text einzufügen. Bilder können in gewissen Grenzen positioniert werde, ihre Größe kann bestimmt werden, ihnen kann eine Bezeichnung und eine Merkierung gegeben werden. Auf Bilder wird aus dem Text heraus über den Filenamen des Bildes zugegriffen.

Eine Bildumgebung enthält also folgende Elemente:

eine Positionierungsangabe (Voreinstellung "htbp", s.u.) (Attribut loc, s. Kap. tabular, S. tabular)
das eigentliche Bild (s.u.)
optionale Bezeichnung ( caption)
optionale Markierung zur späteren Referenzierung der Tabelle ( xref)

Die Positionierungsangabe hat dieselbe Funktion, wie die der Tabellen.

Das Bild selbst wird über die <eps>-Umgebung eingebunden, die folgende Elemente enthält:

Name des Bildes (Attribut file)
optionale Höhe in cm (Attribut height)
optionale Breite in cm(Attribut width)
optionaler Drehwinkel in Grad (Attribut angle)

Ein Blick in die saus.dtd verrät für die Darstellung von Bildern folgendes Konstrukt:

<!ELEMENT figure - - (eps, caption?, label?)> <!ATTLIST figure loc CDATA "htbp"> <!ELEMENT eps - O EMPTY> <!ATTLIST eps file CDATA #REQUIRED height CDATA #IMPLIED width CDATA #IMPLIED angle CDATA #IMPLIED>

(Abbildung: Ein kleines Bild ) Um z.B. Bild bild00 mit einer Breite von 5 cm in den Text einzubauen, kann man angeben:

<figure> <eps file="mini" width="5cm"> <caption>Ein kleines Bild</caption> <label id="bild00"> </figure>

Aufzählungen (<itemize>, <enum> und <descrip>)

Die SAUS-DTD unterscheidet drei Arten von Aufzählungen, die sich in der Art der Markierung der einzelnen Elemente unterscheiden. Die <itemize>-Umgebung nutzt einen Punkt, die <enum>-Umgebung Zahlen und die <descrip>-Umgebung selbst definierte Texte. Aufzählungen können beliebig geschachtelt werden. Die Elemente der Aufzählungen werden jeweils je nach Schachtelungstiefe eingerückt.

Aufzählungen enthalten:

im Fall von <itemize> und <enum> einzelne Elemente (<item>, s.u.)
im Fall von <descrip> optionale Markierungen (<tag>) gefolgt von Elementen (s.u.).

Die einzelnen Elemente wiederum bestehen aus beliebig vielen Absätzen.

Die saus.dtd defiert Aufzählungen wie folgt:

<!ENTITY % sectpar "%list; | formula | figure | table | %litprog;"> <!ELEMENT itemize - - (item+)> <!ELEMENT enum - - (item+)> <!ELEMENT item O O (p*) > <!ELEMENT descrip - - (tag?, p*)+ > <!ELEMENT tag - O (%inline;)>

Es folgen drei Beispiele und der dazugehörige Programmtext:

Punkt 1
Punkt 2

Punkt 1
Punkt 2

Punkt 1: Text zu Punkt 1
Punkt 2: Text zu Punkt 2

<itemize> <item>Punkt 1</item> <item>Punkt 2</item> </itemize> <enum> <item>Punkt 1</item> <item>Punkt 2</item> </enum> <descrip> <tag>Punkt 1</tag> <p>Text zu Punkt 1</p> <tag>Punkt 2</tag> <p>Text zu Punkt 2</p> </descrip>

Formeln (<formula>)

Formeln erscheinen abgesetzt mit Nummer, abgesetzt ohne Nummer oder in Text eingebettet (ohne Nummer). Es werden viele spezielle mathematische Symbole unterstützt, sowie eine an die Höhe der Formeln angepaßte Klammerung. Hierzu ist anzumerken, daß alle Klammern bis auf '|' beliebig geschachtelt werden können. Die Bar ('|') kann nicht geschachtelt werden, weil es hier keinen Unterschied zwischen linker und rechter Klammer gibt. Eine runde Klammer muß nicht unbedingt von einer runden Klammer geschlossen werden, und man muß Klammern nicht unbedingt schließen.

Formeln enthalten:

Hoch- oder tiefgestellte Schrift (<hoch> und <tief>)
Brüche (<frac>)
Wurzeln (<sqrt>)
Funktionen mit Grenzen (<sum>, <prod>, <int>, <det>, <gcd>, <inf>, <lim>, <liminf>, <limsup>, <max>, <min>, <Pr> und <sup>)
Punkte (<ldots>, <cdots>, <vdots> und <ddots>)
Akzente (<hat>, <check>, <breve>, <acute>, <grave>, <tilde>, <bar>, <vec>, <dot> und <ddot>)
Über- und Unterstreichungen bzw. -klammerungen (<overline>, <underline>, <overbrace> und <underbrace>)
Übereinandergestellte Symbole (<stack>)
Tabellen mit mathematischen Symbolen (<array>)

Die saus.dtd hält einige Zeilen bereit:

<!ENTITY % accent "(hat|check|breve|acute|grave|tilde|bar|vec|dot|ddot)"> <!ENTITY % func1 "(frac|sqrt|sum|prod|int)"> <!ENTITY % func2 "(det|gcd|inf|lim|liminf|limsup|max|min|Pr|sup)"> <!ENTITY % dots "(ldots|cdots|vdots|ddots)"> <!ENTITY % lines "(overline|underline|overbrace|underbrace|stack|array)"> <!ENTITY % math2 "(hoch|tief|%accent;|%func1;|%func2;|%dots;|%lines;)"> <!ENTITY % math "(#PCDATA|%math2;)*"> <!ELEMENT formula - - (%math;)+> <!ATTLIST formula label (ja|nein) "ja"> <!ELEMENT hoch - - (%math;)+> <!ELEMENT tief - - (%math;)+> <!ELEMENT frac - - (numerator, denumerator)> <!ELEMENT numerator - O (%math;)+> <!ELEMENT denumerator - O (%math;)+> <!ELEMENT sqrt - - (%math)+> <!ATTLIST sqrt base CDATA ""> <!ELEMENT sum - - (from?, to?)> <!ELEMENT prod - - (from?, to?)> <!ELEMENT int - - (from?, to?)> <!ELEMENT from - O (%math;)+> <!ELEMENT to - O (%math;)+> <!ELEMENT ldots - O EMPTY> <!ELEMENT cdots - O EMPTY> <!ELEMENT vdots - O EMPTY> <!ELEMENT ddots - O EMPTY> <!ELEMENT det - - (from2?)> <!ELEMENT gcd - - (from2?)> <!ELEMENT inf - - (from2?)> <!ELEMENT lim - - (from2?)> <!ELEMENT liminf - - (from2?)> <!ELEMENT limsup - - (from2?)> <!ELEMENT max - - (from2?)> <!ELEMENT min - - (from2?)> <!ELEMENT Pr - - (from2?)> <!ELEMENT sup - - (from2?)> <!ELEMENT from2 - O ((%math;)+, to2?)> <!ELEMENT to2 - O (%math;)+> <!ELEMENT hat - - (%math;)+> <!ELEMENT check - - (%math;)+> <!ELEMENT breve - - (%math;)+> <!ELEMENT acute - - (%math;)+> <!ELEMENT grave - - (%math;)+> <!ELEMENT tilde - - (%math;)+> <!ELEMENT bar - - (%math;)+> <!ELEMENT vec - - (%math;)+> <!ELEMENT dot - - (%math;)+> <!ELEMENT ddot - - (%math;)+> <!ELEMENT overline - - (%math;)+> <!ELEMENT underline - - (%math;)+> <!ELEMENT overbrace - - (%math;)+> <!ELEMENT underbrace - - (%math;)+> <!ELEMENT stack - - (oben, unten)> <!ELEMENT oben - O (%math)+> <!ELEMENT unten - O (%math)+> <!ELEMENT array - - (arrayrow)*> <!ATTLIST array ca CDATA #REQUIRED> <!ELEMENT arrayrow - O (%math;, (colsep, %math;)*)>

Ein paar Beispiele sollen diese Umgebungen demonstrieren: $a+ b+&cdots;+y$ ¹²³+z_αβγ Hier folgt eine Formel im Text: $a$ _{b_n}=$\cos$²π Man schaltet einfach nicht die <formula>-Umgebung ein. $(n a$ ^b)$\not$$\ge${{a+b[a-b]}}^&infty;inf;_x=0 $((ab cd) {e+f g-h} 0 | ij kl |)$ Die obigen Formeln wurden durch folgenden Text definiert:

<formula> <underbrace>a+<overbrace>b+<cdots>+y</overbrace><hoch>123</hoch>+z</underbrace><tief>αβγ</tief> </formula> Hier folgt eine Formel im Text: <vec>a<tief>b<tief>n</tief></tief></vec>=$\cos$<hoch>2</hoch>π Man schaltet einfach nicht die <em><formula></em>-Umgebung ein. <formula label="nein"> (<sqrt base="n">a<hoch><sqrt>b</sqrt></hoch></sqrt>)$\not$$\ge${<frac><numerator>a+b<denumerator>[a-b]</frac>}<hoch>&infty;inf;</hoch><tief>x=0</tief> </formula> <formula> (<array ca="cc"> <arrayrow>(<array ca="c"><arrayrow>ab<arrayrow>cd</array>)<colsep><frac><numerator>e+f<denumerator>g-h</frac> <arrayrow>0<colsep>|<array ca="c"><arrayrow>ij<arrayrow>kl</array>| </array>) </formula>

Schriftmodifikation (<rm>, <bf>, <tt>, <it>, <sl>, <sc>, <sf>, <em>)

Diese Umgebungen dienen dazu, Textteile in ihrem Aussehen zu modifizieren.

Sie enthalten alle Text ( inline)

In der saus.dtd steht dazu:

<!ENTITY % modified "(rm|bf|tt|it|sl|sc|sf|em)"> <!ELEMENT rm - - (%inline;)> <!ELEMENT bf - - (%inline;)> <!ELEMENT tt - - (%inline;)> <!ELEMENT it - - (%inline;)> <!ELEMENT sl - - (%inline;)> <!ELEMENT sc - - (%inline;)> <!ELEMENT sf - - (%inline;)> <!ELEMENT em - - (%inline;)>

Folgendes Aussehen hat modifizierte Schrift:

(<rm>) Dieser Text ist im Roman-Schrifttyp gesetzt.
(<bf>) Dieser Text erscheint in Fettdruck (bold face).
(<tt>) Hier schreibt die Schreibmaschine.
(<it>) Dies ist italic-Schrift.
(<sl>) Slanted ist nicht nur ein anderer Zeichensatz.
(<sc>) Dieses sind die sog. Small Caps.
(<sf>) Diese Schrift ist ohne Serifen.
(<em>) Und das hier ist "emphasized".

Dokumentationselemente (<srcdoku>)

Eine Dokumentation kann sich auf Klassen, Funktionen oder Kommandos beziehen

Sie enthält daher:

Klassendokumentationen ( classdok)
Moduldokumentationen ( moduldok)
Kommandodokumentationen ( cmddok)

In der saus.dtd sieht das wie folgt aus:

<!ELEMENT srcdoku O O (classdok | moduldok | cmddok)+>

Klassendokumentation (<classdok>)

Klassendokumentationen beschreiben die Klasse mit Namen, Referenzen und ihren Elementen.

Sie enthalten:

Name der Klasse (Attribut name)
Kurzbeschreibung ( doktext)
Importanweisungen ( import)
Bibliotheken ( library)
beliebig viele Basisklassen als Text ( inline)
Elemente der Klasse (<classdef>, s.u.)

Die <classdef> bestehet aus:

beliebig vielen öffentlichen Elementen (<public>)
beliebig vielen geschützten Elementen (<protected>)
beliebig vielen privaten Elementen (<private>)

Diese drei Elemente wiederum enthalten

Funktionen ( funcdok)
Variable ( vardok)

Die saus.dtd definiert das so:

<!ELEMENT classdok - - (doktext, import, library, baseclas*, classdef)> <!ATTLIST classdok name CDATA ""> <!ELEMENT baseclas - O (%inline;)> <!ELEMENT classdef O O (public | protect | private)*> <!ENTITY % clasmbr "(funcdok | vardok)+"> <!ELEMENT public - O %clasmbr;> <!ELEMENT protect - O %clasmbr;> <!ELEMENT private - O %clasmbr;>

Moduldokumentation (<moduldok>)

Moduldokumentationen dokumentieren Funktionen und Variable.

Sie enthalten daher

Name des Moduls (Attribut name)
Kurzbeschreibung ( doktext)
Importanweisungen ( import)
Bibliotheken ( library)
Funktionsdokumentationen ( funcdok)
Variablendokumentationen ( vardok)

In der saus.dtd steht:

<!ELEMENT moduldok - - (doktext, import, library, (funcdok|vardok)+)> <!ATTLIST moduldok name CDATA "">

Kommandodokumentation (<cmddok>)

Dies kann z.B. die Dokumentation zu einem Shell-Skript oder im Projekt erstellten binary sein. Da in einem Kommando keine Funktionen oder aähnliches exportiert werden, ist hier nur die Beschreibung der Funktionalität und evtl. benötigter Parameter erforderlich.

Die Kommandodokumentation enthält:

Name des Kommandos (Attribut name)
Dokumentationstext ( doktext)
mindestens eine Funktionsdokumentation ( funcdok)

In der saus.dtd steht:

<!ELEMENT cmddok - - (doktext, funcdok+)> <!ELEMENT doktext - - (p+)>

Dokumentationstext (<doktext>)

Dies ist ein kurzer Text, der den Sinn und Zweck der dokumentierten Arbeit beschreibt.

Er besteht aus mindestens einem Absatz ( p)

Die saus.dtd definiert:

<!ELEMENT doktext - - (p+)>

Importanweisungen (<import>)

Hier werden die Namen der einzubindenden header-files oder sonstiger Definitionsdateien angegeben.

Die Anweisung enthält Text ( inline)

<!ELEMENT import - - (%inline;)>

Bibliotheksreferenz (<library>)

Hier wird der Name der zu linkenden Bibliothek(en) engegeben

Die Referenz enthält Text ( inline)

<!ELEMENT library - - (%inline;)>

Funktionsdokumentation (<funcdok>)

Mit diesem Element wird eine einzelne Funktion dokumentiert, also die Parameter mit Typen und die Funktionalität bzw. Aufgabe.

Dieses Element enthält daher:

Einen Prototypen als Text ( inline)
Die eigentliche Dokumentation (<dokpar>), die wiederum aus mindestens einem Absatz besteht ( p)

Die saus.dtd definiert:

<!ELEMENT prototyp O O (%inline;)> <!ELEMENT dokpar O O (p+)> <!ELEMENT funcdok - O (prototyp, dokpar)>

Variablendokumentation (<vardok>)

Die Definition der Variablendokumentation läuft völlig analog zur Funktionsdokumentation ( funcdok)

Verschiedenes

Einstellungen (<settings>)

Die Einstellungen dienen zum An- bzw. Abschalten bestimmter Eigenschaften.

Die Settings können folgende Elemente enthalten:

optional <notoc> zum Abschalten des Inhaltsverzeichnisses
optional <nolot> zum Abschalten des Tabellenverzeichnisses
optional <nolof> zum Abschalten des Bildverzeichnisses
optional <notbiblio> zum Abschalten des Literaturverzeichnisses
optional <noindex> zum Abschalten des Stichwortverzeichnisses

Die saus.dtd definiert sie durch folgende Zeilen:

<!ELEMENT settings - - (notoc?, nolof?, nolot?, nobiblio?, noindex?)> <!ELEMENT notoc - O EMPTY> <!ELEMENT nolot - O EMPTY> <!ELEMENT nolof - O EMPTY> <!ELEMENT nobiblio - O EMPTY> <!ELEMENT noindex - O EMPTY>

Titelseiten (<titlepag>)

Die Titelseite ist die erste Seite von Teilberichten, Referaten und Code- bzw. Klassendokumentationen. Auf eine Titelzeile folgen zweispaltig die Autoren mit eventuellen Fußnoten und ein Datum.

Das Element Titelseite enthält:

Titel als Text ( inline)
Autoren ( authors)
Datumsangabe ( date)

In der saus.dtd sind folgende Zeilen für die Titelseite verantwortlich:

<!ELEMENT titlepag - - (title, authors, %date;)> <!ELEMENT title - O (%inline;)>

Ein Beispiel für eine Titelseite ist in Kapitel teilber zu finden. Der eigentliche Titel (<title>) kann fast beliebige Textelemente enthalten.

Autoren (<authors> und <author>)

Autoren erscheinen auf Titelseiten von Teilberichten, Referaten und Dokumentationen, bzw. einzeln in Protokollen. Eine optionale Anmerkung erscheint in der LaTeX-Übersetzung auf der Titelseite am Fuß und in der HTML-Übersetzung hinter dem Namen. Die User-Id erscheint nur in der HTML-Übersetzung. Der entsprechende Eintrag wird der Datei $(SGML)/$(PROJECT)/homepagedb entnommen. Es kann sich hier um eine email-Referenz oder eine Referenz auf die WWW-HomePage des Autoren handeln.

Die <authors>-Umgebung besteht aus beliebig vielen einzelnen Autoren (<author>), die wiederum folgende Elemente enthalten:

Name des Autors (<realname>)
optional die User-Id des Autoren (<uid>)
optional eine Anmerkung zum Autoren (<thanks>)

Beide Elemente können beliebigen Text enthalten.

Die saus.dtd definiert:

<!ELEMENT authors O O (author)+> <!ELEMENT author O O (realname, uid?, thanks?)> <!ELEMENT realname - - (#PCDATA)> <!ELEMENT uid - - (#PCDATA)> <!ELEMENT thanks - - (#PCDATA)>

Ein Beispiel zu Autoren ist im Abschnitt zu den Teilberichten (Kap. teilber) zu finden.

Datumsangaben (<litdate>, <curdate> und <rcsdate>)

Die SAUS-DTD erlaubt drei verschiedene Arten, ein Datum anzugeben. <litdate> kann frei definiert werden, <curdate> steht für das aktuelle Datum, eingeleitet durch "Bremen, den") und <rcsdate> (?).

<!ELEMENT litdate - O (#PCDATA)> <!ELEMENT curdate - O EMPTY> <!ELEMENT rcsdate - O (#PCDATA)>

Schlüsselworte (<keywords> und <keyword>)

Auf die Titelseite folgt optional eine Liste von Schlüsselworten, die auch im Stichwortverzeichnis auftauchen. In Absätzen können ebenfalls Stichworte definiert werden, die ebenfalls (nur) im Stichwortverzeichnis erscheinen (also nicht an der Stelle im Text, an der sie definiert wurden). Zu beachten ist dabei, daß die Stichworte keine Kommata beinhalten sollten, denn sonst werden sie nicht richtig dargestellt.

Die <keywords> enthalten einzelne <keyword>-Elemente, die wiederum jeweils Freitext ( inline) enthalten.

Die saus.dtd definiert:

<!ELEMENT keywords - - (keyword+)> <!ELEMENT keyword - - (%inline;)>

Fußnoten (<fnote>)

In der LaTeX-Übersetzung erscheinen Fußnoten in Kleintext nach Möglichkeit am Fuße derjenigen Seite, auf der sie referenziert wurden. Sie werden durch eine horizontale Linie vom Haupttext optisch getrennt. In HTML wird ihr Text in Klammern dargestellt. (Dies ist z.B. eine Fußnote mit Formel: $\tan$ 2α= ${2$\tan$α 1-$\tan$$ ²α}) .

Fußnoten enthalten:

Text ( inline)
abgesetzte Formeln ( formula)

<!ELEMENT fnote - - (%inline; | formula)*>

Bezeichnungen (<caption>)

Bezeichnungen sind kleine Texte unter Tabellen und Bildern, die diesen Objekten einen Namen geben.

Sie enthalten Text Freitext.

Die saus.dtd hält eine Zeile bereit:

<!ELEMENT caption - O (#PCDATA)>

In den Beispielen zu Tabellen (Kap. tabular) und Bildern (Kap. figure) wird auch die Bezeichnung benutzt.

Referenzen

Referenzen innerhalb des Textes (<label>, <ref> und <pageref>)

Mit Referenzen innerhalb eines Textes kann man sich in einem Dokument die Kapitel- und/oder Seitennummern markierter Stellen beziehen.

Markierungen und Referenzen enthalten einen Namen (Attribut id).

Die saus.dtd definiert hierzu:

<!ELEMENT label - O EMPTY> <!ATTLIST label id CDATA #REQUIRED> <!ELEMENT ref - O EMPTY> <!ATTLIST ref id CDATA #REQUIRED> <!ELEMENT pageref - O EMPTY> <!ATTLIST pageref id CDATA #REQUIRED>

Um z.B. eine bestimmte Stelle zu markieren, gibt man ein:

<label id="markierung"> An anderer Stelle kann man wie folgt auf die Abschnittsnummer und die Seitennummer der Merkierung zugreifen: Die Markierung steht im Abschnitt <ref id="markierung"> auf Seite <pageref id="markierung">. Die Markierung steht im Abschnitt markierung auf Seite markierung.

Referenzen außerhalb des Textes (<cite> und <ncite>)

Referenzen auf benutzte Literatur werden mit diesen Umgebungen realisiert. Am Ende von Teilberichten, Referaten und Dokumentationen wird ein Literaturverzeichnis angelegt, wenn es nicht mit <nobiblio> explizit abgeschaltet wurde. Alle referenzierten Dokumente müssen in $(SGMLDIR)/lib/saus.bib eingetragen sein.

Referenzen außerhalb des Textes enthalten:

Die Identifikation des referenzierten Dokuments (Attribut id).
Im Falle von <ncite> eine Bemerkung (Attribut note).

In der saus.dtd finden sich folgende Zeilen:

<!ELEMENT cite - O EMPTY> <!ATTLIST cite id CDATA #REQUIRED> <!ELEMENT ncite - O EMPTY> <!ATTLIST ncite id CDATA #REQUIRED note CDATA #REQUIRED>

Es folgt eine Referenz (bajaraja ) ohne Bemerkung und nun eine mit eigener Bemerkung .

Es folgt eine Referenz <cite id="bajaraja"> ohne Bemerkung und nun eine mit eigener Bemerkung <ncite id="barghoutikaiser91" note="S. 64 ff.">.

Dauer (<dauer>)

Hier wird die Dauer eines Protokolls eingetragen. Sie erscheint abgesetzt vom übrigen Text mit einem Punkt wie in der Aufzählungsumgebung <itemize> ( itemize).

Die Dauer enthält Text ( inline).

<!ELEMENT dauer - - %inline;>

Anwesende (<anwesend>)

Die Liste der Anwesenden während einer Sitzung erscheint im Protokoll hinter dem einführenden Wort "Anwesende:". Sie kann als Text oder als Aufzählung realisiert werden.

Diese Umgebung enthält:

Text ( inline)
oder eine Aufzählung ( itemize)

Die saus.dtd definiert:

<!ELEMENT anwesend - - (%inline; | %list;)+ >

Dateinamen (<filename>)

Dateinamen werden in Schreibmaschinenschrift gesetzt. Diese Umgebung ist dafür gedacht, daß sich Dateinamen erstens von anderem Text absetzen und zweitens in allen Dokumenten gleich aussehen.

Dateinamen anthalten Text ( inline).

<!ELEMENT filename - - (%inline;)>

Ein Dateiname sieht so aus: foo.tmp.

Ein Dateiname sieht so aus: <filename>foo.tmp</filename>.

Identifizierer (<uid>, <gid>, <url> und <mail>)

Diese Umgebungen dienen dazu, bestimmte Texte als Identifizierer für Namen oder Funktionen o.ä. besonders kenntlich zu machen. Sie können in jedem Text ( inline) erscheinen. Es sind Identifizierer für einzelne Personen (<uid>), Gruppen (<gid>), URLs (Uniform resource location, <url>) und e-mail-Adressen (<mail>) vorgesehen. Diese Identifizierer machen besonders in der HTML-Übersetzung Sinn, denn hier werden entsprechende Referenzen auf WWW-Seiten aufgebaut, die man dann entsprechend benutzen kann.

Identifizierer enthalten:

Freitext
Im Falle von URLs das Schema (Attribut scheme) und den Pfad (Attribut path) des bezeichneten Dokuments.

<!ENTITY % id "(uid|gid|url|mail)"> <!ELEMENT uid - - (#PCDATA)> <!ELEMENT gid - - (#PCDATA)> <!ELEMENT mail - - (#PCDATA)> <!ATTLIST mail destin CDATA #REQUIRED> <!ELEMENT url - - (#PCDATA)> <!ATTLIST url scheme CDATA "http://" path CDATA #REQUIRED>

Die einzelnen Identifizierer haben folgendes Aussehen:

<uid> : kelvin
<gid> : Gruppe42
<url> : Dokumentation der SAUS Document Type Definition
<mail> : Jan Kuhlmann

Die einzelnen Identifizierer haben folgendes Aussehen: <itemize> <item> <uid;gt; : <uid>kelvin</uid> </item> <item> <gid> : <gid>Gruppe 42</gid> </item> <item> <url> : <url path="ftp.uni-bremen.de/~kelvin/www/dtddoku.html">Dokumentation der SAUS Document Type Definition</url> </item> <item> <mail> : <mail destin="kelvin@wowbagger.pc-labor.uni-bremen.de">Jan Kuhlmann</mail> </item> </itemize>

Technisches

Damit die Übersetzung der SGML-Quelltexte funktioniert, müssen zwei Umgebungsvariablen gesetzt sein:

SGMLDIR : Diese Variable muß den Pfad des Verzeichnisses sgml enthalten.
PROJECT : Hier muß der Name des Projekts stehen (also "saus"). Andere Projekte können so ohne größere Umstände das SGML-System an ihre Zwecke anpassen.

Der Übersetzungsprozeß vom Originaltext zum ausdruckbaren oder anzeigbaren Dokument ist stark abhängig vom verwendeten Interpretierer. Derzeit werden Übersetzungen nach LaTeX (und damit weiter nach postscript) und HTML unterstützt. Die Übersetzung geschieht auf der Basis eines makefiles, das derzeit nur GNU-make versteht. Auch das Skript für den Makroprozessor m4 wird derzeit nur von GNU-m4 verstanden.

Die LaTeX-Übersetzung

Die Übersetzung von SGML nach LaTeX findet in insgesamt sechs Stufen statt:

special-chars1

Dieses selbstgeschriebene Programm hat drei grundlegende Aufgaben:

Es wird dafür gesorgt, daß in <code> und <verb> Umgebungen stehende entities (also Worte, die mit '&' beginnen und mit ';' enden) später nicht übersetzt werden. Dies wird geleistet, indem das einführende '&' durch ein spezielles 'magisches' Wort (Es handelt sich hier um das Wort 'MaGiCaMpErSaNd'.) ersetzt wird, das in keinem Text auftauchen darf. Erst in der sechsten Stufe dieses 'magische' Wort wieder nach '&' zurücküberstzt.
Einige Zeichen, die fur LaTeX besondere Bedeutung haben (nämlich '$', '_', '^', '{', '}', '|', '#', '%', '\', '~'), werden für die spätere richtige Darstellung vorbereitet. Dabei muß zwischen wortgetreuen und nicht-wortgetreuen Umgebungen unterschieden werden. Zudem hat '|' im <tabular> Mode für LaTeX eine spezielle Bedeutung, so daß auch daruf Rücksicht genommen wird.
Die Klammern ('(', ')', '[', ']', '{', '}', aber auch '|') werden für die <formula> Umgebung vorbereitet. In dieser Umgebung werden die Klammern nämlich an die Größe der Formel angepaßt (s. Kap. formula).

sed

In dieser Stufe werden die entities ersetzt. Wie schon erwähnt wurde, werden alle entities mit '&' eingeleitet und enden mit ';'. Wörter, die dieser Form entsprechen, aber nicht als entity deklariert sind, werden wortgetreu ausgegeben (z.B. '&test;'). Damit sich sgmls nicht über solche nicht deklarierten entities beschwert, wird das '&' auch wieder in das 'magische' Wort (s.o.) übersetzt, so daß also nach dem Durchlauf von sed kein '&' mehr im Text steht. sed muß vor sgmls laufen, damit das '&' und nicht deklarierte entities im Originaltext benutzt werden können, ohne daß sich sgmls darüber beschwert.

sgmls

Das Programm sgmls testet die Syntax des Dokumentes anhand der in der saus.dtd vorgegebenen Grammatik. Es überführt den Text dann in ein Format, das sgmlsasp versteht.

sgmlsasp

sgmlsasp nimmt wieder Ersetzungen im Text vor. Hier werden die meisten LaTeX-Befehle in den Text eingebaut. Es braucht dafür das File mapping. An dieser Stelle werden viele Zeichen eingefügt, die für LaTeX besondere Bedeutung haben, was auch der Grund ist, daß derartige im Originaltext sthenden Zeichen schon im ersten Schritt ihrer Sonderbedeutung für LaTeX beraubt wurden.

m4

Einige der Elemente der saus.dtd haben Attribute, die optional sind oder deren Werte sich nicht einfach in eine für LaTeX verständliche Form bringen lassen. m4 schafft bei solchen Fällen (z.B. bei Bildern, Folien und Wurzeln) Abhilfe.

special-chars2

Auch dieser Teil hat mehrere Aufgaben:

Wie schon mehrfach erwähnt, wird an dieser Stelle das 'magische' Wort wieder in '&' übersetzt.
Es wird dafür gesorgt, daß die mathematische Umgebung für LaTeX nicht mehrmals nacheinander angeschaltet wird, bevor sie wieder ausgeschaltet wird.
Ebenfalls in der mathematischen Umgebung reagiert LaTeX allergisch auf Leerzeilen, die in dieser Phase unschädlich gemacht werden.
Die deutschen Anführungsstriche in der <quote> Umgebung und die Anführungszeichen oben (") werden hier erzeugt.

Die HTML-Übersetzung

Die Übersetzung von SGML nach HTML ist leider evtl. noch nicht ganz fertig. Das Problem ist die Umsetzung von mathematischen Symbolen, die erst in HTML3 definiert sind. Derzeit (Stand Januar 1996) scheint es aber keinen Browser zu geben, der HTML3 zufriedenstellend oder gar vollständig anzeigen kann. Getestet wurden diesbezüglich NetScape 2.03b und Arena 0.97g, wobei entsprechende Recherchen darauf schließen lasse, daß auch Mosaic kein HTML3 kennt. Dementsprechend ist HTML3 nur gemäß der Definition aus dem RFC, wie er im World Wide Web unter "http://www.w3.org./pub/WWW/MarkUp/html3/" zu finden ist, implementiert, und es kann sein, daß sich später noch Fehler aufzeigen werden, die dann entsprechend korrigiert werden müssen.

Die jetzige Übersetzung von SGML nach HTML findet in acht Stufen statt:

special-chars1: Dieses lex-Script hat die Aufgabe, ähnlich wie in der LaTeX-Übersetzung defür zu sorgen, daß Entities in den Verbatim-Umgebungen (<verb> und <code>) nicht umgesetzt werden. Auch dieses Script benutzt dafür das 'magische' Wort, das auch schon die LaTeX-Übersetzung verwendet (s.Kap. latex).
sed: In dieser Stufe übersetzt ein sed-Script die Entities in ihr in entites.sed definiertes Pendant. Im übrigen gilt das für die LaTeX-Übersetzung gesagte (s. Kap. latex).
sgmls: Das Programm sgmls testet die Syntax des Dokumentes anhand der in der saus.dtd vorgegebenen Grammatik. Es überführt den Text dann in ein Format, das sgmlsasp versteht.
sgmlsasp: sgmlsasp nimmt wieder Ersetzungen im Text vor. Hier werden die meisten HTML-Befehle in den Text eingebaut. Es braucht dafür das File mapping.
m4: Einige der Elemente der saus.dtd haben Attribute, die optional sind oder deren Werte sich nicht einfach in eine für HTML verständliche Form bringen lassen. m4 schafft bei solchen Fällen Abhilfe. Außerdem werden in diesem Schritt das Inhaltsverzeichnis und das Stichwortverzeichnis vorbereitet.
special-chars2: Hier handelt es sich wieder um ein lex-Script, das zum einen das 'magische' Wort wird wieder in '&' übersetzt und zum anderen dafür sorgt, daß die mathematische Umgebung für HTML nicht mehrmals nacheinander angeschaltet wird, bevor sie wieder ausgeschaltet wird.
awk, Teil 1: Hier wird aus dem vorbereiteten Inhaltsverzeichnis das endgültige Inhaltsverzeichnis erstellt. Das Inhaltsverzeichnis wird dabei in eine Datei mit der Endung .index.html geschrieben, auf die die eigentliche Zieldatei per Referenz zugreift. Auch über das Inhaltsverzeichnis läuft dann nochmal das lex-Script special-chars2, um die Ampersands wieder in '&' zu verwandeln.
awk, Teil 2: Schließlich wird das vorbereitete Stichwortverzeichnis sortiert und das endgültige Stichwortverzeichnis erstellt. Das Stichwortverzeichnis wird dabei in eine Datei mit der Endung .keyword.html geschrieben, auf die die eigentliche Zieldatei per Referenz zugreift. Auch über das Stichwortverzeichnis läuft dann nochmal das lex-Script special-chars2, um die Ampersands wieder in '&' zu verwandeln.

rechtsbündig	zentriert	umgebrochen	linksbündig
rot	grün	rot, grün und blau zugleich	blau