1.1. Die FreeBSD-Dokumentationsreihe

Das FDP umfaßt vier verschiedene Kategorien:

Jede dieser vier Kategorien wird im FreeBSD-CVS-Baum verwaltet. Das bedeutet, dass alle Änderungen an den Dateien für jeden verfügbar sind und jeder sich mittels eines Programms wie CVSup oder CTM eine lokale Kopie der Dokumentation anlegen kann.

Parallel zum FDP haben viele Menschen Anleitungen geschrieben und Webseiten mit Bezug zu FreeBSD erstellt. Einige davon werden im CVS-Archiv verwaltet, sofern der Autor dem zugestimmt hat. In anderen Fällen hat sich der Autor entschlossen, seine Dokumentation außerhalb des zentralen FreeBSD-CVS-Archivs zu verwalten. Das FDP bemüht sich, so viele Verweise wie möglich auf solche Quellen bereitzustellen.

1.2. Bevor es losgeht

Zum Verständnis der folgenden Kapitel sollte folgendes bereits bekannt sein:

• Wie eine aktuelle Kopie der FreeBSD-Dokumentation entweder auf Basis des FreeBSD-CVS-Archivs mittels CVS, CTM oder CVSup angelegt und gepflegt wird, oder wie mit CVSup eine frische Kopie des CVS-Archivs heruntergeladen wird.

• Wie neue Programme mit Hilfe des FreeBSD-Portsystems oder mittels pkg_add(1) heruntergeladen und installiert werden.

1.3. Der Schnellstart

Falls man einfach loslegen möchte und sich sicher genug fühlt, um alles weitere erst bei Bedarf nachzusehen, kann man einfach den folgenden Anweisungen folgen:

2.1. Notwendige Werkzeuge

2.2. Optionale Werkzeuge

Die in diesem Kapitel genannten Programme müssen nicht unbedingt installiert werden. Allerdings können sie die Arbeit an der Dokumentation erleichtern und die Anzahl an möglichen Ausgabeformaten erhöhen.

3.1. Überblick

In den guten alten Zeiten war der Umgang mit “elektronischem” Text einfach. Man musste lediglich wissen, welcher Zeichensatz (ASCII, EBCDIC oder ein anderer) vorlag. Text war einfach Text und sah so aus, wie man ihn sah. Keine Extras, keine Formatierungen und kein sonstiger Schnickschnack.

Für viele Zwecke war dies allerdings nicht ausreichend. Von einem machinenlesbaren Text wird erwartet, dass er auch von Maschinen gelesen und intelligent weiterverarbeitet werden kann. Einzelne Stellen sollen hervorgehoben werden, andere sollen in ein Glossar aufgenommen werden oder auf andere Textstellen verweisen. Dateinamen wiederum sollen in einer “schreibmaschinenähnlichen” Schrift auf dem Bildschirm dargestellt werden, der Ausdruck soll jedoch in “Schrägschrift” oder in einer beliebigen anderen Darstellungsform erfolgen.

Anfänglich gab es die Hoffnung, dass die Künstliche Intelligenz (KI) helfen würde, dieses Ziel zu erreichen. Computer sollte den Text lesen und dazu in der Lage sein, selbstständig wichtige Formulierungen, Dateinamen, Benutzereingaben oder Beispiele zu erkennen. Leider verlief die Entwicklung in diesem Bereich nicht wie gewünscht und Computer benötigen nach wie vor etwas Unterstützung, bevor sie Texte vernünftig verarbeiten können.

Genauer gesagt, man muss ihnen sagen, was was ist. Sehen wir uns folgende Zeilen an:

Löschen Sie /tmp/foo mittels rm(1).

% rm /tmp/foo

Es fällt uns leicht, zu erkennen, was ein Dateiname, ein einzugebender Befehl oder ein Verweis auf eine Hilfeseite ist. Das kann ein Computer, der einen Text verarbeitet, nicht. Aus diesem Grund ist es notwendig, Texte mit weiteren Informationen “auszuzeichnen”.

Der Begriff “Auszeichnung[1]” bedeutet, dass sich der Wert eines Textes erhöht, aber auch seine Kosten. Durch Auszeichnungen wird einem Dokument zusätzlicher Text hinzugefügt, der aber von dem eigentlichen Dokumenteninhalt auf eine bestimmte Art und Weise unterschieden werden kann, so dass Programme die Auszeichnung erkennen können und mittels dieser Informationen während der Verarbeitung in der Lage sind, Entscheidungen zu treffen. Texteditoren können diese Auszeichnungselemente vor dem Benutzer verbergen, um zu vermeiden, dass er durch sie abgelenkt wird.

Die durch die Auszeichnungselemente im Textdokument zusätzlich abgelegten Informationen erhöhen den Wert des Dokuments. Allerdings muss diese Arbeit in den meisten Fällen von einem Menschen getan werden - wären Maschinen dazu fähig, wären zusätzliche Auszeichnungselemente unnötig. Der damit verbundene Aufwand erhöht die Kosten, die durch die Erstellung des Dokuments entstehen.

Das etwas weiter oben gegebene Beispiel sieht im Quelltext so aus:

<para>Löschen Sie <filename>/tmp/foo</filename> mittels <citerefentry/<refentrytitle/rm/<manvolnum/1//.</para>

<screen><prompt>%</prompt> <userinput>rm /tmp/foo</userinput></screen>

Die Auszeichnungselemente sind deutlich vom eigentlichen Inhalt zu unterscheiden.

Die Einführung von Auszeichnungselementen setzt voraus, dass festgelegt wird, welche Bedeutung einzelne Elemente haben und wie diese interpretiert werden. Sie brauchen daher eine Auszeichnungssprache, der Sie folgen, wenn Sie eigene Dokumente verfassen.

Natürlich kann es keine universelle Auszeichnungssprache geben und eine einzige mag nicht ausreichend für alle möglichen Anwendungsfälle sein. Eine Sprache für technische Dokumente wird sich wahrscheinlich stark von einer für Kochrezepte unterscheiden. Die universelle Lösung ist eine Basissprache, mit deren Hilfe weitere Sprachen entwickelt werden können - eine Meta-Auszeichungssprache also.

Genau diese Anforderung wird von der Standard Generalized Markup Language (SGML) erfüllt. Mit ihrer Hilfe wurden viele andere Auszeichungssprachen wie beispielsweise HTML und DocBook, welche beide von FDP genutzt werden, entwickelt.

Die eigentliche Sprachdefinition erfolgt in einer Dokumenten-Typ-Definition (DTD). Innerhalb dieser DTD werden die Namen der einzelnen Elemente, deren mögliche Reihenfolge und Verschachtelung sowie weitere Informationen festgelegt.

Eine DTD ist eine vollständige Definition aller möglichen Sprachelemente, ihrer Reihenfolge[2], optionaler Elemente und so weiter und so weiter. Dank dieser recht formalen Festlegung ist es möglich, SGML-Parser zu entwickeln, die sowohl ein Dokument als auch seine DTD einlesen und anhand dieser DTD prüfen können, ob das Dokument allen Anforderungen der DTD entspricht. Dieser Vorgang wird allgemein als Validierung des Dokuments bezeichnet.

Es ist anzunehmen, dass, wenn man selber vor hat Dokumentation für das FDP zu schreiben, der größte Teil davon mit Hilfe von HTML oder DocBook geschrieben werden wird. Aus diesem Grunde wird an dieser Stelle nicht erklärt, wie eine DTD entwickelt wird.

3.2. Von Elementen, Tags und Attributen

Alle in SGML geschriebenen DTDs haben bestimmte gemeinsame Eigenschaften. Das ist nicht verwunderlich, da sich die hinter SGML stehende Idee unweigerlich bemerkbar macht. Zwei der markantesten Merkmale dieser Idee sind die Begriffe Inhalt und Element.

Von einem Dokument, unabhängig, ob es sich um eine einzelne Webseite oder ein langes Buch handelt, wird angenommen, dass es einen wie auch immer gearteten Inhalt hat. Dieser lässt sich selbst wiederum in Teilelemente aufspalten, die ebenso zerlegbar sind. Durch die Aufnahme von Auszeichnungselementen in einen Text, werden diese einzelnen Elemente eindeutig benannt und voneinander abgegrenzt.

Nimmt man zum Beispiel ein typisches Buch, so kann man es auf der obersten Ebene als ein Ganzes, als ein Element betrachten. Dieses “Buch”-Element enthält nun Kapitel, die wiederum selbst als Elemente bezeichnet werden können. Jedes einzelne Kapitel enthält weitere Elemente. So gibt es beispielsweise Absätze, Zitate und Fußnoten. Jeder Absatz kann wiederum selbst Elemente enthalten, die helfen, den Absatzinhalt als direkte Rede oder als Namen eines der Protagonisten einer Geschichte zu identifizieren.

Wenn man möchte, kann man sich das als “Unterteilung”[3] des Inhalts vorstellen. Auf der obersten Ebene gibt es ein Element: das Buch selbst. Schaut man ein wenig tiefer, findet man weitere Teilelemente: die einzelnen Kapitel. Diese sind wiederum unterteilt in Absätze, Fußnoten, Namen und so weiter und so weiter.

Anzumerken ist an dieser Stelle, dass das eben gesagte ohne weiteres auf jeden Inhaltstyp angewandt werden kann, auch ohne dass von SGML die Rede ist. Man könnte beispielsweise einfach verschiedene Stifte nehmen und einen Ausdruck dieser Fibel vor sich hinlegen und dann mit verschiedenen Farben die einzelnen Abschnitte des Buchinhalts markieren.

Leider gibt es keinen elektronischen Stift, um das zu tun. Deshalb muss ein anderer Weg gewählt werden, um zu bestimmen, zu welchem Element die einzelnen Inhalte gehören. In SGML-basierten Auszeichnungssprachen wie HTML und DocBook werden dafür so genannte Tags eingesetzt.

Mit einem solchen Tag wird eindeutig festgelegt, wo ein bestimmtes Element beginnt und wo es endet. Allerdings gehört der Tag selber nicht zum Element. Er legt lediglich die Grenzen des Elements fest. Da jede DTD mit dem Ziel entwickelt wurde, einen speziellen Inhaltstyp auszuzeichnen, wird jede DTD verschiedene Elemente kennen, die daher natürlich auch unterschiedlich benannt sein werden.

Der Starttag für ein imaginäres Element mit dem Namen elementname ist <<elementname>>. Sein Gegenstück, der schließende Endtag, ist <</elementname>>.

<p>Das ist ein Absatz. Er beginnt mit Starttag
  für das Element 'p' und endet mit dem Endtag für
  das Element 'p'.</p>

<p>Das ist ein etwas kürzerer Absatz.</p>

Elemente müssen nicht notwendigerweise einen Endtag haben. Ebenso ist es nicht notwendig, dass Elemente einen Inhalt haben. Beispielsweise kann in HTML-Dokumenten mittels eines speziellen Elements festgelegt werden, dass eine horizontale Linie an einer bestimmten Stelle erscheinen soll. Da dieses Element offensichtlich keinen Inhalt hat, wird auch kein Endtag benötigt.

<p>Das ist ein Abschnitt.</p>

<hr>

<p>Das ist ein weiterer Absatz. Eine horizontale Linie
  trennt ihn vom vorherigen Absatz.</p>

Elemente können andere Elemente enthalten. Im anfangs erwähnten Buch enthielt das Buch-Element alle Kapitel-Elemente, die wiederum alle Absatz-Elemente enthielten und so fort.

<p>Das ist ein einfacher <em>Abschnitt</em>, in dem
  einige <em>Worte</em> <em>hervorgehoben</em> wurden.

Welche Elemente andere Elemente enthalten können und welche das sind, wird innerhalb der DTD eines Dokuments festgelegt.

Elemente können selber Attribute haben, die aus einem Namen und einem Wert bestehen. Die Attribute haben die Aufgabe, dem Element zusätzliche Informationen hinzuzufügen. Denkbar sind hier Festlegungen über die Darstellung, Bezeichner, über die das Element eindeutig identifiziert werden kann, oder beliebige andere Informationen.

Elementattribute werden in den Starttag eingefügt und haben die Form Attributename="Wert".

Bei einigen HTML-Versionen kennt das Element <p> das Attribut <align>, mit dessen Hilfe die Textausrichtung eines Absatzes bestimmt werden kann.

align akzeptiert einen von vier vorgegebenen Werten: left, center, right und justify. Ist align nicht angegeben, wird vom Standardwert left ausgegangen.

<p align="left">Die Verwendung des align-Attributs
  für diesen Absatz ist überflüssig, da left
  der Standardwert ist.</p>

<p align="center">Dieser Absatz wird hoffentlich mittig dargestellt.</p>

Einige Attribute akzeptieren nur bestimmte Werte, wie beispielsweise left oder justify. Andere akzeptieren jeden beliebigen Wert. Enthält Attributwert doppelte Anführungszeichen ("), wird der Wert in einfachen Anführungszeichen eingeschlossen.

<p align='right'>Ich stehe rechts!</p>

Manchmal können die Anführungszeichen um den Attributwert weggelassen werden. Allerdings sind die Regeln, die festlegen wann dies zulässig ist, sehr spitzfindig. Am besten schließen Sie Attributwerte immer in Anführungszeichen ein.

Die Informationen über Attribute, Elemente und Tags sind in SGML-Katalogen abgelegt und werden von den verschiedenen Werkzeugen des Dokumentationsprojektes genutzt, um die geschriebenen Dokumente zu validieren. Die Programme die durch textproc/docproj installiert werden, bringen ihre eigenen Katalogvarianten mit, zudem pflegt das FDP seine eigenen Kataloge. Beide Katalogarten müssen von allen Programmen gefunden werden können.

3.3. Die DOCTYPE-Deklaration

Am Anfang jedes Dokuments muss der Name der dem Dokument zugrundeliegenden DTD angegeben werden. Mit Hilfe dieser Information können SGML-Parser die verwendete DTD feststellen und prüfen, ob das Dokument zu ihr konform ist.

Üblicherweise steht diese Information in einer Zeile, die als DOCTYPE-Deklaration bezeichnet wird.

Eine Deklaration für ein HTML-Dokument, das nach den Vorgaben der DTD für HTML 4.0 geschrieben wurde, sieht so aus:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN">

und besteht aus verschiedenen Teilen.

"Besitzer//Schlüsselwort Beschreibung//Sprache"

PUBLIC "-//W3C//DTD HTML 4.0//EN"             "4.0/strict.dtd"

<!DOCTYPE html SYSTEM "/pfad/zur/dokumenten.dtd">

3.4. Die Rückkehr zu SGML

An einer früheren Stelle wurde erwähnt, dass man SGML nur benötigt, falls man selbst eine DTD entwickeln möchte. Genaugenommen ist das nicht 100%ig richtig. Einige Teile der SGML-Syntax können auch in normalen Dokumenten verwendet werden, falls dies gewünscht oder notwendig ist.

In diesem Falle muss dafür Sorge getragen werden, dass ein SGML-Prozessor feststellen kann, dass ein bestimmter Abschnitt des Inhalts SGML ist, das er verarbeiteten muss.

Solche SGML-Abschnitte werden mittels <! ... > in Dokumenten besonders gekennzeichnet. Alles, was sich zwischen diesen Begrenzungen befindet, ist SGML, wie es auch in DTDs gefunden werden kann.

Demnach ist die DOCTYPE-Deklaration ein gutes Beispiel für SGML, das in Dokumenten verwendet werden muss...

3.5. Kommentare

Kommentare sind SGML-Konstrukte, die normalerweise nur in DTDs gültig sind. Dennoch ist es, wie in Abschnitt 3.4 gezeigt, möglich Fragmente mit SGML-Syntax in Dokumenten zu verwenden.

Zum Abgrenzen von SGML-Kommentaren wird ein doppelter Bindestrich “--” verwendet. Mit seinem ersten Auftreten öffnet er einen Kommentar, mit seinem zweiten schließt er ihn wieder.

<!-- Testkommentar -->

<!-- Text innerhalb eines Kommentars -->

<!-- Ein anderer Kommentar    -->

<!-- So können mehrzeilige Kommentare
     genutzt werden -->

<!-- Eine andere Möglichkeit für --
  -- mehrzeilige Kommentare.     -->

Hat man früher schon Erfahrungen mit HTML gesammelt, wird man vielleicht andere Regeln für den Gebrauch von Kommentaren kennengelernt haben. Beispielsweise wird oft angenommen, dass Kommentare mit <!-- begonnen und nur mit --> beendet werden.

Dies ist nicht der Fall. Viele Webbrowser haben fehlerhafte HTML-Parser, die dies akzeptieren. Die SGML-Parser, die vom FDP verwendet werden, halten sich strenger an die SGML-Spezifikation und verwerfen Dokumente mit solchen Fehlern.

<!-- Innerhalb eines Kommentars --

     DIES IST NICHT TEIL EINES KOMMENTARS

  -- Wieder innerhalb eines Kommentars -->

<!DIES IST NICHT TEIL EINES KOMMENTARS>

<!--------------- Eine wirklich schlechte Idee  --------------->

<!--===================================================-->

3.6. Entitäten

Entitäten stellen einen Mechanismus dar, mit dem einzelnen Dokumententeilen ein Name zugewiesen werden kann. Findet ein SGML-Parser während des Parsens eine Entität, ersetzt er diese durch den ihr zugewiesenen Inhalt.

Dadurch steht eine einfache Möglichkeit zur Verfügung, mit der variabler Inhalt in SGML-Dokumenten eingebunden werden kann. Zusätzlich sind Entitäten der einzige Weg, über den eine Datei in eine andere Datei mit SGML-Mitteln eingebunden werden kann.

Es werden zwei Arten von Entitäten unterschieden: Allgemeine Entitäten und Parameterentitäten.

<para>Die aktuelle Version des
  Programms ist &current.version;.</para>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY current.version    "3.0-RELEASE">
<!ENTITY last.version       "2.2.7-RELEASE">
]>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY % param.etwas "etwas">
<!ENTITY % param.text "Text">
<!ENTITY % param.neu  "%param.etwas mehr %param.text">

<!-- %param.neu ist jetzt "etwas mehr Text" -->
]>

3.7. Dateien mit Entitäten einbinden

Sowohl Allgemeine als auch Parameterentitäten sind nützliche Helfer, wenn es darum geht, eine Datei in eine andere einzubinden.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY kapitel.1 SYSTEM "kapitel1.sgml">
<!ENTITY kapitel.2 SYSTEM "kapitel2.sgml">
<!ENTITY kapitel.3 SYSTEM "kapitel3.sgml">
<!-- Und so weiter... -->
]>

<html>
  <!-- Jetzt werden die Kapitel über die Entitäten eingebunden -->

  &kapitel.1;
  &kapitel.2;
  &kapitel.3;
</html>

<!ENTITY kapitel.1 SYSTEM "kapitel1.sgml">
<!ENTITY kapitel.2 SYSTEM "kapitel2.sgml">
<!ENTITY kapitel.3 SYSTEM "kapitel3.sgml">

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!-- Definieren einer Parameterentität um die Allgemeinen Entitäten für -->
<!-- die Kapitel laden zu können                                        -->
<!ENTITY % kapitel SYSTEM "kapitel.ent">

<!-- Nun wird der Inhalt der referenzierten Datei geladen -->
%kapitel;
]>

<html>
  &kapitel.1;
  &kapitel.2;
  &kapitel.3;
</html>

3.8. Markierte Bereiche

SGML erlaubt es, dass bestimmte Dokumentabschnitte während der Verarbeitung besonders behandelt werden sollen. Diese Abschnitte werden als “markierte Bereiche” [8] bezeichnet.

<![ SCHLÜSSELWORT [
  Inhalt des markierten Bereiches
]]>

Da es sich bei markierten Bereichen um SGML-Konstrukte handelt, werden sie mit <! eingeleitet. Der eigentliche Anfang des markierten Bereiches wird von der folgenden eckigen Klammer bestimmt. Das darauf folgende SCHLÜSSELWORT legt fest, wie der “markierte Inhalt” durch einen SGML-Prozessor während der Verarbeitung behandelt werden soll. Der “markierte” Inhalt selbst beginnt erst nach der zweiten eckigen Klammer und erstreckt sich bis zu den zwei schließenden eckigen Klammern am Ende des Bereiches. Mit Hilfe des > Zeichens wird der mit <! begonnene SGML-Kontext wieder verlassen.

<para>Das ist ein Beispiel, wie man einen Text,
  der viele &lt;- und &amp;-
  Entitäten enthält, in ein Dokument einbinden kann.
  Das Beispiel selbst, das sich innerhalb des markierten Bereiches befindet,
  ist ein HTML-Fragment. Der diesen Text umschließende Tag, beginnend mit
  mit <para> und endend mit </para>, stammt aus der DocBook DTD.</para>

<programlisting>
  <![ RCDATA [  
    <p>Dieses Beispiel demonstriert die Verwendung von HTML-Elementen.
      Da spitze Klammern so oft vorkommen, ist es einfacher, das
      gesamte Beispiel als CDATA Abschnitt auszuweisen, als die
      entsprechenden Entit&auml;ten zu nutzen.</p>

    <ul>
      <li>Das ist ein Listenelement.</li>
      <li>Das ist ein zweites Listenelement.</li>
      <li>Das ist ein drittes Listenelement.</li>
    </ul>

    <p>Und das hier, das ist das Ende des Beispiels.</p>
  ]]>
</programlisting>

<![ INCLUDE [
  Dieser Text wird verarbeitet und eingebunden.
]]>

<![ IGNORE [
  Dieser Text wird weder verarbeitet noch eingebunden.
]]>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY % digitale.kopie "INCLUDE">
]]>

...

<![ %digitale.kopie [
  Dieser Satz sollte nur in der digitalen Version enthalten sein.
]]>

<!ENTITY % digitale.kopie "IGNORE">

3.9. Schlußbemerkung

Aus Platzgründen, und um der Verständlichkeit Willen, wurden viele Gesichtspunkte nicht in aller Tiefe beziehungsweise gar nicht besprochen. Trotzdem sollte in den bisherigen Kapiteln genügend Wissen über SGML vermittelt worden sein, um den Aufbau der Dokumentation des FDPs zu verstehen.

4.1. HTML

HTML, die HyperText Markup Language, ist die Auszeichnungssprache des Internets. Weitere Informationen zu HTML finden sich unter http://www.w3.org/.

Sie kommt bei der Erstellung der Webseiten des FreeBSD-Projektes zum Einsatz. Für technische Dokumentationen sollte HTML jedoch nicht eingesetzt werden, da DocBook eine größere und bessere Auswahl an Elementen bietet. Folglich sollte HTML nur für die FreeBSD-Webseiten verwendet werden.

Die HTML-Spezifikation liegt bis jetzt in mehreren Versionen vor: 1, 2, 3.0, 3.2 und (die aktuelle) 4.0. Von letzterer existieren zwei Varianten: “streng” (HTML 4.0 Strict) und “locker” (HTML 4.0 Transitional).

Die HTML-DTDs sind über den Port textproc/html verfügbar und werden automatisch als Teil des Metaports textproc/docproj mitinstalliert.

PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"

<html>
  <head>
    <title>Der Dokumententitel</title>
  </head>

  <body>

    ...

  </body>
</html>

<h1>Erstes Kapitel</h1>

<!-- Hier steht die Einführung -->

<h2>Das ist die Überschrift des ersten Kapitels</h2>

<!-- Hier steht der Inhalt des ersten Kapitels -->

<h3>Das ist die Überschrift des ersten Unterkapitels</h3>

<!-- Hier steht der Inhalt des ersten Unterkapitels -->

<h2>Das ist die Überschrift des zweiten Kapitels</h2>

<!-- Hier steht der Inhalt des zweiten Kapitels -->

<h1>Erstes Kapitel</h1>

<!-- Allgemeines zum Dokument -->

<h3>Unterkapitel</h3>

<!-- h3 folgt direkt auf h1. h2 wurde ausgelassen -->

<p>Das hier, das ist ein Absatz. Absätze können
  andere Elemente enhalten.</p>

<blockquote>
  <p>Artikel 1: Menschenwürde; Grundrechtsbindung der
    staatlichen Gewalt</p>

  <ol>
    <li>
      <p>Die Würde des Menschen ist unantastbar. Sie zu achten
        und zu schützen ist Verpflichtung aller staatlichen
        Gewalten.</p>
    </li>
    <li>
      <p>Das Deutsche Volk bekennt sich darum zu unverletzlichen
        und unveräußerlichen Menschenrechten als Grundlage jeder
        menschlichen Gemeinschaft, des Friedens und der
        Gerechtigkeit in der Welt.</p>
    </li>
    <li>
      <p>Die nachfolgenden Grundrechte binden Gesetzgebung,
        vollziehende Gewalt und Rechtsprechung als
        unmittelbar geltendes Recht.</p>
    </li>
  </ol>
</blockquote>

<p>Jetzt folgt eine unsortierte Liste. Wahrscheinlich werden
  die einzelnen Einträge mit einem vorangehenden Punkt dargestellt.</p>

<ul>
  <li>Erster Eintrag</li>

  <li>Zweiter Eintrag</li>

  <li>Dritter Eintrag</li>
</ul>

<p>Die zweite Liste ist sortiert und ihre Einträge bestehen aus mehreren Absätzen.
  Jeder Listeneintrag ist nummeriert.</p>

<ol>
  <li><p>Das ist der erste Eintrag mit nur einem Absatz.</p></li>

  <li><p>Das ist der erste Absatz des zweiten Eintrags.</p>

    <p>Und das ist der zweite Absatz des zweiten Eintrags.</p></li>

  <li><p>Der dritte Eintrag besteht ebenfalls nur aus einem Eintrag.</p></li>
</ol>

<dl>
  <dt>Erster Begriff</dt>

  <dd><p>Erster Absatz der Erklärung</p>

    <p>Zweiter Absatz der Erklärung.</p></dd>

  <dt>Zweiter Begriff</dt>

  <dd><p>Erster Absatz der Erklärung.</p></dd>

  <dt>Dritter Begriff</dt>

  <dd>Erster Absatz der Erklärung zum dritten Begriff.</dd>
</dl>

<pre>  From: nik@FreeBSD.org
  To: freebsd-doc@FreeBSD.org
  Subject: Neue Version verfügbar

  Es ist eine neue Version der Fibel für neue Mitarbeiter am
  FreeBSD-Dokumentationsprojekt verfügbar:

    <URL:http://people.FreeBSD.org/~nik/primer/index.html>

  Kommentare und Anmerkungen sind willkommen.

  N</pre>