Auszeichnungssprache

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Markup)
Zur Navigation springen Zur Suche springen

Eine Auszeichnungssprache (englisch markup language, abgekürzt ML) ist eine maschinenlesbare Sprache für die Gliederung und Formatierung von Texten und anderen Daten. Der bekannteste Vertreter ist die Hypertext Markup Language (HTML), die Kernsprache des World Wide Webs.[1]

Mit Auszeichnungssprachen werden Eigenschaften, Zugehörigkeiten und Darstellungsformen von Abschnitten eines Textes (Zeichen, Wörtern, Absätzen usw. – „Elementen“) oder einer Datenmenge beschrieben. Dies geschieht in der Regel, indem sie mit Tags markiert werden.

Der Artikel behandelt besonders die mit der Standard Generalized Markup Language (SGML) empfohlene „Trennung von Struktur und Darstellung“.

Wortherkunft und Geschichte

[Bearbeiten | Quelltext bearbeiten]

Der typografische Begriff Auszeichnung kommt aus der Druckersprache. Ursprünglich war damit lediglich die Methode gemeint, Teile eines Textes durch von der Grundschrift abweichende Schriften zu gestalten, z. B. durch andere Schriftgrößen und -arten, aber auch durch Unterstreichen, Sperren oder andere Druckfarben. Für den Schriftsetzer wurden die entsprechenden Stellen früher handschriftlich auf dem zugehörigen Manuskript kenntlich gemacht; auch dies wurde Auszeichnen genannt.[2] Mit der Weiterentwicklung der Typografie für digitale Texte wurden daraus maschinenlesbare Sprachen, und das Konzept wurde auf Fußnoten, Literaturhinweise, Absätze, Überschriften etc. erweitert. Dann wurde der Gedanke der Trennung von Inhalt und Form (ursprünglich ein Schlagwort der Formalen Soziologie) populär, so dass in den Quelltexten für Dokumente Hinweise auf die Formatierung von Textteilen mehr und mehr durch Kennzeichnungen der Art von Information ersetzt wurden, die jeweils mitgeteilt werden sollte. Dies führte 1986 zu SGML als internationalem Auszeichnungsstandard (ISO 8879) und 1998 zur Spezifikation von XML durch das World Wide Web Consortium. XML wurde in den folgenden Jahren auch für andere Zwecke als für die Formatierung von Textdokumenten eingesetzt, etwa für Datenformate („Datenserialisierung“).

Wie ausgezeichneter Text aussieht

[Bearbeiten | Quelltext bearbeiten]

Typische Auszeichnungssprachen kennzeichnen Teile von Texten oder anderen Daten mit Tags. Die Quelltexte dafür werden mit einem computerlesbaren Zeichensatz verfasst, in der Regel ASCII oder UTF-8. Oft bietet die Sprache auch die Möglichkeit, Sonderzeichen zu beschreiben, meist mit Hilfe einer numerischen Zuweisung (Unicode) oder durch Benennung (benannte Zeichenentitäten), für µ zum Beispiel \mu in LaTeX und µ in HTML.

Ergebnis und Code in Beispielen

[Bearbeiten | Quelltext bearbeiten]
Beispiel für … Darstellungs-
beispiel
HTML LaTeX MediaWiki-Wikitext Markdown AsciiDoc
Überschrift Abschnitt <h2>Abschnitt</h2> \section{Abschnitt}
== Abschnitt ==
## Abschnitt == Abschnitt
Aufzählung
  • Punkt 1
  • Punkt 2
  • Punkt 3
<ul>
<li>Punkt 1</li>
<li>Punkt 2</li>
<li>Punkt 3</li>
</ul>
\begin{itemize}
\item Punkt 1
\item Punkt 2
\item Punkt 3
\end{itemize}

* Punkt 1
* Punkt 2
* Punkt 3

- Punkt 1
* Punkt 2
- Punkt 3
* Punkt 1
* Punkt 2
* Punkt 3
Hyperlink W3C <a href="http://www.w3.org/">W3C</a> \href{https://www.w3.org}{W3C} [http://www.w3.org/ W3C]
[W3C](http://www.w3.org/)
http://www.w3.org/[W3C]
fetten Text fett <b>fett</b> \textbf{fett} '''fett'''
**fett** oder __fett__
*fett*
kursiven Text kursiv <i>kursiv</i> \textit{kursiv} ''kursiv''
*kursiv* oder _kursiv_
_kursiv_

Der Hyperlink mit LaTeX funktioniert nicht allgemein, jedenfalls aber mit dem Zusatzpaket hyperref und bei Erzeugung eines Ergebnisses im PDF-Format.

Beispiele „darstellender“ gegenüber „beschreibender“ Auszeichnung

[Bearbeiten | Quelltext bearbeiten]

Fett“ und „kursiv“ in der vorigen Tabelle bedeuten eine bestimmte Darstellung (Formatierung, hier konkret Wahl eines Schriftschnitts), während „Überschrift“ ein semantisches Merkmal ist und im Allgemeinen keine Darstellung etwa als fett festlegt. In Druckwerken werden Überschriften statt durch Fetten auch durch Kapitälchen oder Kursivstellung formatiert.

Zu HTML und LaTeX gibt die vorige Tabelle daher für „fett“ und „kursiv“ den Code für die Schriftauszeichnung an;[3] tatsächlich erzeugt die MediaWiki-Software der Wikipedia aus dem Wikitext '''fett''' den HTML-Code <b>fett</b>.[Anm. 1] Im Gegensatz dazu bietet HTML die semantische Auszeichnung durch strong an, was „Wichtigkeit“ ausdrücken soll,[4] Beispiel:

HTML Ergebnis mit Voreinstellungen
<strong>wichtig!</strong> wichtig!

Das HTML-Element strong wird also normalerweise (in Browser-Voreinstellungen) durch fetten Text dargestellt.[5]

Analog zum Verhältnis des HTML-Elements b zum HTML-Element strong ist die Beziehung des HTML-Elements i zu em: Dieses Element steht für „Betonung“, seine voreingestellte Darstellung ist Kursivstellung.[6] In LaTeX gibt es ebenfalls eine „semantische Variante“ \emph der Darstellungsauszeichnung \textit:[7][8]

HTML LaTeX Ergebnis mit Voreinstellungen
<body>
eine <em>Betonung</em>
in normaler Umgebung
</body>
\begin{document}
eine \emph{Betonung}
in normaler Umgebung
\end{document}
eine Betonung in normaler Umgebung

Innerhalb eines kursiv gesetzten Texts aber ist Kursivstellung zur Betonung ungeeignet, LaTeX berücksichtigt das:

HTML Ergebnis mit Voreinstellungen
<i>eine <em>Betonung</em> in kursiver Umgebung</i> eine Betonung in kursiver Umgebung
\textit{eine \emph{Betonung} in kursiver Umgebung} eine Betonung in kursiver Umgebung
LaTeX Ergebnis

Wikitext verhält sich hier in gewisser Weise wie LaTeX; in HTML kann das Verhalten von LaTeX durch die CSS-Deklaration i em { font-style: normal; } (ansatzweise) erzielt werden. Nach HTML5-Spezifikation soll Verschachtelung von em-Elementen verstärkte Betonung ausdrücken[9] (was anscheinend noch kaum implementiert ist). LaTeX hingegen schaltet bei Verschachtelung von \emph nur zwischen Kursiv- und Aufrechtstellung hin und her, so dass beim Lesen dreifache Betonung von einfacher Betonung nicht zu unterscheiden ist. Letztlich sind demnach gebräuchliche und gleichzeitig sinnvolle Implementierungen von „Betonung“ in HTML nur für die einfachsten Fälle und in LaTeX nur für die einfachsten und die zweiteinfachsten Fälle bekannt.

Bei HTML wurde lange angestrebt, darstellende (der Jargon ist in diesem Falle „präsentationale“) Elemente abzuschaffen[Anm. 2] (HTML4-Varianten „strict“[10] vs. „transitional“). Mit HTML5 soll dieses Ziel erreicht sein,[11] obwohl b und i immer noch vorhanden sind – für Fälle, in denen Fetten bzw. Kursivstellung „dringend erwünscht“ ist. Eine Aufzählung von Fällen, in denen die konkrete Schriftschnittwahl angebracht ist, wird als „semantische Definition“ der beiden Elemente betrachtet.[12]

Innere Systematik – Abstraktionsstufen

[Bearbeiten | Quelltext bearbeiten]

„Darstellend“ gegenüber „beschreibend“ – Übersicht

[Bearbeiten | Quelltext bearbeiten]

1981 unterschied Charles Goldfarb auf einer Konferenz[13] (der „Lausanne-Konferenz“)[14] und in einem einflussreichen[15] Artikel[16] zwischen prozeduraler (englisch procedural markup) und deskriptiver (beschreibender, englisch descriptive markup) Auszeichnung von Dokumenten. 1987 wurde präsentational (englisch presentational markup) im Zusammenhang mit WYSIWYG-Textverarbeitung als weitere Art, Text auszuzeichnen, genannt.[17][18][19] Recht bald[20] wurde „präsentational“ jedoch als mit „prozedural“ synonym (oder als Oberbegriff davon, dazu unten #„Prozedural“ und „präsentational“) verwendet – wir nennen das hier darstellend. Letzteres bestimmt die Textformatierung, also etwa die Schriftauszeichnung durch Wahl einer Schriftart, eines Schriftschnitts, des Schriftgrads, einer Schriftfarbe oder einer Unterlegung; auch die Ausrichtung von Text (relative Abstände, absolute Position auf der Seite).[21] Weitere Synonyme wurden später häufiger verwendet:[22]

zu „darstellend“/„präsentational“
visuell, physisch, spezifisch;
zu „deskriptiv“
strukturell, deklarativ, verallgemeinert („generalized“), generisch, inhaltlich, logisch, konzeptuell (englisch conceptual markup),[23] semantisch.

Der Ausdruck generic coding anstelle von descriptive markup stammt von William W. Tunnicliffe. Furuta verwendete 1992 zur Darstellung von Goldfarbs (und Brian Reids, s. u.) Unterscheidung nicht „prozedural“ und „deskriptiv“, sondern „präsentational“ und „generisch“[15] (außerdem separation between content specification and format specification[18] und zu „generisch“ logical structure rather than its physical appearance.)[24] In den Spezifikationen (und Entwürfen) zu HTML 4.0 und HTML 4.01 ist das vorherrschende Gegensatzpaar „präsentational“ (auch presentation elements and attributes)[25] versus „strukturell“[25] (Separate structure and presentation),[26] auch von visual formatting ist die Rede.[21]

Zu Beginn seines Artikels erklärt Goldfarb,[27] das Markup trenne die logischen Elemente voneinander und gebe („typischerweise“ – wohl in Bezug auf das bis dahin bekannte prozedurale Markup) die Verarbeitungsfunktionen („processing functions“) an, die auf diese Elemente angewendet werden sollen.

Popularität beschreibender Auszeichnung (Vorteile, historische Entwicklung)

[Bearbeiten | Quelltext bearbeiten]

Goldfarb, William W. Tunnicliffe und Brian Reid empfahlen damals,[15] Dokumente beim Verfassen nur „beschreibend“ auszuzeichnen – z. B. Phrasen und Blöcke nur als „Titel“, „Abschnittsüberschrift“, „Blockzitat“ usw. zu kennzeichnen –, um typografisch hochwertigen Satz auch ohne typografische Fachkenntnisse und Programmierkenntnisse der Verfasser zu ermöglichen, den Darstellungsstil mit geringem Aufwand ändern zu können, nicht auf bestimmte Werksatzanbieter angewiesen zu sein und um automatische Informationsgewinnung zu erleichtern, etwa um beim Durchsuchen von Dokumenten nach Stichwörtern Vorkommnisse in Überschriften stärker zu gewichten. Goldfarb[27] weist etwa darauf hin, dass durch die bloße Kennzeichnung von Wörtern als zu zentrieren die Information verloren geht, ob es sich um eine Überschrift oder die Beschriftung einer Tabelle oder Abbildung handelt. Deskriptive Auszeichnung erleichtert auch die Darstellung in unterschiedlichen Ausgabeformaten/-geräten wie HTML, PDF und Screenreader (Barrierefreiheit, vgl. Accessible Rich Internet Applications).[11] Im Falle von HTML kann die Nutzung präsentationaler Attribute anstelle von Stylesheets auch die HTML-Dateien „aufblähen“. Entsprechend wurde später bei HTML darauf hingearbeitet, nur „strukturelle“ oder „semantische“ Elemente und Attribute anzubieten und die Darstellung völlig in die Cascading Style Sheets auszulagern (Trennung von Inhalt und Form).

William W. Tunnicliffe sprach sich bereits 1967 auf einer Konferenz für die Trennung von Inhalt und Form in der Textverarbeitung aus, was jedoch zunächst geringe Wirkung hatte (immerhin gibt Goldfarb an, davon beeinflusst worden zu sein). 1981 stellte Brian Reid sein Satzsystem Scribe in derselben Sitzung der „Lausanne-Konferenz“ vor, in der Goldfarb seine Ideen vorstellte.[13] Scribes Trennung von Inhalt und Form(atierung) beeindruckte als besonders gut gelungen.[18] In den nächsten Jahren entwickelte Leslie Lamport das Makropaket LaTeX für das TeX-Programm besonders mit der Motivation, ebenfalls Autoren eine deskriptive Auszeichnungssprache anzubieten.[28] 1985 wurde es veröffentlicht. Bereits 1992 war LaTeX sehr populär,[15] zunächst unter nordamerikanischen Mathematikern, in den nächsten Jahren überhaupt im wissenschaftlich-akademischen Bereich und in der Industrie.[29] In den nächsten Jahren übernahm ein fast rein europäisches Entwicklungsteam die Weiterentwicklung von LaTeX von Lamport und verbesserte seine Flexibilität hinsichtlich Verwendung unterschiedlicher „Stylesheets“ (Makrodefinitionsdateien mit Endungen .sty für „style“ wie bei Lamport und .cls für die Deklaration der „Dokumentenklasse“ mit \documentclass) und hinsichtlich der Verwendung mit nicht-englischen Sprachen, wodurch die Bedeutung von LaTeX noch gesteigert wurde.[30]

Tunnicliffe und Goldfarb führten dagegen die Weiterentwicklung von IBM Generalized Markup Language zu SGML als Grundlage für die Definition rein deskriptiver Auszeichnungssprachen an, woraus später XML entstand, das im Werksatz ebenfalls eine bedeutende Rolle spielt.

Definition als „Sprache“

[Bearbeiten | Quelltext bearbeiten]

Eine Auszeichnungssprache sollte eine Sprache sein, die auch maschinenlesbar ist. Dazu müssen jeweils Syntax und Semantik angegeben werden, was in folgenden Fällen zutrifft:

  1. Der Quellcode eines Dokuments ist ein Programm mit Anweisungen einer (domänenspezifischen) Programmiersprache; Syntax und Semantik sind also wie bei anderen Programmiersprachen auch definiert und bilden eine formale Sprache, deren Syntax etwa durch Produktionsregeln (etwa in Backus-Naur-Form) gebildet wird. Dies gilt etwa für PostScript, troff und TeX (für dieses auf Token-Ebene nach Expansion von Makros u. a.).[31]
  2. Bei gemäß SGML bzw. XML definierten Auszeichnungssprachen wird jedenfalls die Syntax präzise durch eine Dokumenttypdefinition dargestellt. Unter Umständen gibt das World Wide Web Consortium auch eine (informelle) Semantik an, die aus an Nutzer und Entwickler gerichteten Empfehlungen besteht.

Etwas schwieriger ist es im Fall von TeX und LaTeX, wo durch Makrodefinitionen (hauptsächlich vor dem Einlesen des Codes, der den Inhalt eines Dokuments darstellt) eine sehr umfangreiche „prozedurale“ Sprache (wir greifen etwas vor) entsteht. Durch die Wahl „sprechender“ Makronamen entsteht jedenfalls eine „Illusion“ von rein „deskriptiver“ Auszeichnung. Durch Verschweigen (im Handbuch) oder Verbieten[Anm. 3] der durchaus verfügbaren Möglichkeiten „prozeduraler“ oder „präsentationaler“ Auszeichnung kann man zu einer „rein deskriptiven“ Auszeichnungssprache gelangen. Auf ähnliche Weise war HTML 4.01 Strict eine durch „Verbieten“ präsentationaler, von Browsern aber weiterhin interpretierter Elemente und Attribute eine rein deskriptive Auszeichnungssprache.

„Prozedural“ und „präsentational“

[Bearbeiten | Quelltext bearbeiten]

In einem bedeutenden[15] Aufsatz von 1987[17] wurden neben „prozedural“ und „deskriptiv“ weitere Auszeichnungsarten beschrieben, von denen der XML-Koautor Tim Bray in seinem Blog[19] „präsentational“ übernahm. Gemeint war mit letzterem solches Markup, das von WYSIWYG-Textverarbeitungsprogrammen automatisch in den Dokument-Quellcode eingefügt wurde, wenn Nutzer bestimmte Tastenkombinationen eingaben (genannt wird WordStar). Statt des Quellcodes bekommt der Nutzer aber nur eine Vorschau der Druckausgabe zu sehen. „Präsentational“ hat hierbei offenbar eine andere, speziellere Bedeutung als in den HTML-Spezifikationen, in denen keine Rede von WYSIWYG-Editoren ist. Eine Gemeinsamkeit besteht aber darin, dass der Auszeichnungscode knapper ist als der für „auffällig prozedurales Markup“ in folgendem Sinne:

In dem von Goldfarb[27] angegebenen Beispiel geht einer Liste, wie sie etwa in HTML mit <ol> eingeleitet wird, folgender Code voraus:

tb 4
of 4
sk 1

Die ersten beiden Zeilen stellen dabei Wertzuweisungen für Parameter dar, die den hängenden Einzug des folgenden Absatzes steuern, die dritte Zeile erzeugt dessen vertikalen Abstand zum vorhergehenden Absatz. Die dabei verwendete Auszeichnungssprache ist das (troff-ähnliche) SCRIPT. Es handelt sich offenbar um einen Teil eines Computerprogramms in einer imperativen Programmiersprache. <ol> in HTML ist kürzer und verzichtet auf Details der Formatierung. Das Beispiel ist allerdings nur dazu geeignet, Goldfarbs Vorstellung von „prozeduraler Auszeichnung“ anzudeuten, und illustriert nur den Unterschied zur „deskriptiven Auszeichnung“.

Bray illustriert „prozedurales Markup“ mit den PostScript-Befehlen gsave und grestore.[32] Diese beiden Befehle verhalten sich zueinander wie \begingroup und \endgroup in TeX.[33][34] Die Anweisung \begingroup bewirkt, dass bei jeder folgenden Parameterwertänderung der vorige Parameterwert in einem Stapelspeicher abgelegt wird. Der entsprechende Befehl \endgroup stellt die Parameterwerte vor dem entsprechenden \begingroup wieder her. Beide Befehle haben keine unmittelbare Auswirkung auf die Formatierung, die Wirkung hängt vielmehr davon ab, die Werte welcher Parameter zwischen ihnen geändert werden.

In PostScript gibt es außerdem den Befehl selectfont, der an den LaTeX-Befehl \selectfont erinnert:[Anm. 4]

%!
/Courier
20 selectfont
72 500 moveto
(Hallo Welt!) show
showpage

Insgesamt legen die vorigen Beobachtungen folgendes Beispiel nahe:

Kursivstellung mit HTML und LaTeX, letzteres mit high-level- gegenüber low-level-Befehlen
Darstellung HTML LaTeX high-level LaTeX mit \begingroup LaTeX mit { statt \begingroup
kursiv gesetzt
<body>
<i>kursiv</i>
gesetzt
</body>
\begin{document}
\textit{kursiv}
gesetzt
\end{document}
\begin{document}
\begingroup
\fontshape{it}\selectfont
kursiv\/\endgroup\
gesetzt
\end{document}
\begin{document}
{\fontshape{it}\selectfont
 kursiv\/} gesetzt
\end{document}

Die beiden low-level-Beispiele rechts kommen dem sehr nahe, wie LaTeX den high-level-Befehl \textit tatsächlich umsetzt. \endgroup gesetzt würde in „kursivgesetzt“ resultieren, daher wird \endgroup\ verwendet. Die Notwendigkeit dieses Tricks vermeidet man im rechten Beispiel, wo die geschweiften Klammern die Befehle \begingroup und \endgroup vertreten, während sie nach \textit nur dessen Anwendungsbereich angeben. Der Befehl \/ verhindert, dass durch die Rechtsneigung des „v“ der Abstand zwischen „kursiv“ und „gesetzt“ optisch zu eng ausfällt (sogenannte Kursivkorrektur).

In allen vier Beispielen liegt eine darstellende Auszeichnung vor, die den Schriftschnitt variiert. Einer der Nachteile prozeduraler Auszeichnung, die Goldfarb nennt,[35] soll darin bestehen, dass sie die Beherrschung einer Vielzahl von Programmierbefehlen erfordert, als Beispiel nennt er ausdrücklich Knuths TeX. Die Kursivkorrektur ist auch eine typografische Feinheit, deren Notwendigkeit bei der Nutzung von TeX für Autoren nicht selbstverständlich ist. Der LaTeX-Befehl \textit erspart dem Anwender die Kenntnis einiger low-level-Befehle und der Kursivkorrektur. Das i-Element in HTML ist ebenso einfach zu beherrschen. Goldfarbs hier angesprochener Kritikpunkt richtet sich (im Unterschied zu anderen) offenbar nicht gegen jede darstellende Auszeichnung, sondern nur gegen programmiersprachenartige Auszeichnung wie in den beiden Beispielen rechts und gegen PostScript-Befehle weiter oben.

Im Falle des HTML-Beispiels erscheint die Bezeichnung der Auszeichnung durch <i> und </i> als „prozedural“ auch unpassend. Während in den „umständlichen“ Beispielen einzelne Befehle an den Textprozessor gerichtet werden (Goldfarb: „processing functions“),[27] die erst durch ihre Kombination die gewünschte Darstellung erreichen, stellt das i-Element nur eine abstrakte Schnittstelle zum Webbrowser dar, dessen prozedurale Verarbeitung des linken Beispiels für Verfasser von HTML-Dokumenten gar nicht zugänglich ist. Der Unterschied ähnelt dem zwischen imperativer Programmierung („echt prozedural“ in den rechten Beispielen) und deklarativer Programmierung, in der die Algorithmen zum Erreichen eines beschriebenen Zustands (hier: Kursivschrift) nicht explizit genannt werden.

„Prozedurale“ und „deskriptive“ Auszeichnungssprachen

[Bearbeiten | Quelltext bearbeiten]

In der Literatur wird auch von „deskriptiven Auszeichnungssprachen“ (englisch descriptive markup languages)[22] im Gegensatz zu „prozeduralen Auszeichnungssprachen“ (englisch procedural markup languages) gesprochen;[22] wann eine Aussprache „prozedural“ bzw. „deskriptiv“ ist, soll vielleicht im Anschluss an Erläuterungen von „prozeduraler Auszeichnung“ bzw. „deskriptiver Auszeichnung“ selbstverständlich sein. Eine „deskriptive Auszeichnungssprache“ dürfte eine Auszeichnungssprache sein, die weder „prozedurales“ noch „präsentationales“ Markup ermöglicht, also „rein deskriptiv“ ist – wie es die Intention/„Philosophie“[22] von SGML war. Dies trifft auf DocBook und TEI zu. Das Prädikat „prozedurale Auszeichnungssprache“ scheint auf Auszeichnungssprachen zuzutreffen, in denen Wertzuweisungen und andere Ähnlichkeiten mit imperativen Programmiersprachen „unübersehbar“ sind, vielleicht auch auf Auszeichnungssprachen, die Formatierungsanweisungen in eher deklarativer Weise geben, wie HTML (vor HTML5). Jedenfalls könnten PostScript, TeX und troff dazu gezählt werden.[32]

Die vorige Deutung steht allerdings im Widerspruch dazu, dass LaTeX laut Furuta[18] (und dem 1994er LaTeX-Begleiter[36] „in hohem Maße“) eine „generische Markup-Sprache“ sein soll, trotz des darstellenden \textit (mit dem im LaTeX-Begleiter beschriebenen LaTeX 2e) bzw. \it (mit dem 1992 gültigen LaTeX 2.09). Vielleicht ist eine generische (oder deskriptive) Markup-Sprache doch eine Sprache, die neben präsentationalem Markup auch ein „gewisses Maß“ an generischem Markup bietet.

Darstellungsstufen

[Bearbeiten | Quelltext bearbeiten]

Auf eine Arbeit von 1988 unter seiner Beteiligung Bezug nehmend, spricht Furuta[37] von drei „Erscheinungsformen“ (representations) eines Dokuments:

  1. einer abstrakten, die durch Bearbeitung mit einem Editor verändert wird (abstract representation),
  2. einer physischen, die aus einer abstrakten durch Formatierung entsteht (physical representation), und
  3. einer Seitenerscheinungsform, die für ein bestimmtes Ausgabegerät erforderlich ist (page representation).

Entsprechend ist Furutas Artikel gegliedert.

Durch „darstellendes Markup“ kann man wie oben dargelegt (beginnend mit Beispiele) Schriftschnitt, Farben, und Textausrichtung bestimmen, ein entsprechender Abschnitt in den Spezifikationen zu HTML 4.0 und 4.01[21] beschreibt diesen „physischen“ Aspekt einigermaßen umfassend. In HTML5 ist mit dem style-Attribut eine Möglichkeit verblieben, z. B. Schriftschnitte (durch CSS-Code) zu wählen, auch Tabellen bewirken eine „physisch“ einigermaßen strikte Darstellung, die der seitenorientierten Darstellung näher kommt als die Wahl von Schriftschnitten. Auszeichnung dieser Art entspricht dem ursprünglichen, engeren Begriff (Textformatierung bzw. traditionelles Auszeichnen wie am Anfang des Artikels beschrieben).

Was bei solcher Auszeichnung im Allgemeinen nicht bestimmt wird, ist in einem Fließtextabsatz der Zeilenumbruch. Bei einem Wort ab der Mitte eines längeren Absatzes lässt man sich davon „überraschen“, ob es im dargestellten Absatz auf dem Bildschirm oder auf der ausgedruckten Seite eher links oder eher rechts steht oder ob es beim Zeilenumbruch getrennt wird. So ist es auch bei der üblichen Verwendung von LaTeX, ConTeXt und plain TeX. Bei Bedarf kann man (mit etwas fortgeschrittenen Kenntnissen) die Zeilen eines Absatzes manuell fixieren (bei Webseiten mit white-space: nowrap und <br />, bei LaTeX mit \makebox und \linebreak). Häufiger ist man in einzelnen Fällen mit dem automatischen Zeilenumbruch nicht zufrieden und legt einen Zeilenwechsel manuell fest, oder man unterbindet einen Zeilenumbruch innerhalb einer Phrase. Neben dem Zeilenumbruch werden auch die Zeilenabstände typischerweise automatisch bestimmt (sie sollten gleichmäßig sein, etwa bei mathematischen Formeln mit Brüchen müssen sie aber oft größer gewählt werden). TeX trat auch mit der Besonderheit hervor, die Zeichen in mathematischen Formeln in verschiedenen Größen zu setzen und relativ zueinander zu so anzuordnen, dass die Proportionen hohen typografischen Ansprüchen genügen.

Gegenüber Webseiten muss im Drucksatz zusätzlich der Seitenumbruch bestimmt werden. Auch den überlässt man meist dem Satzprogramm und korrigiert das automatische Ergebnis gelegentlich manuell. Bei der Gestaltung der Titelseite eines Buchs überlässt man dagegen „nichts dem Zufall“.

Dateiformate, die alle Zeilenumbrüche in Fließtexten einer Ausgabeseite und auch die exakte Position von Textelementen und Grafiken auf ihr fixieren und festlegen, heißen (oder entsprechen) Seitenbeschreibungssprachen.[38] Solche sind etwa PostScript und PDF von Adobe, das ursprüngliche Ausgabeformat DVI von TeX oder XML Paper Specification von Microsoft (weitere im Hauptartikel). PDF und DVI kann man allerdings nicht in einem Texteditor betrachten und ändern oder verfassen. In Postscript ist dies möglich, man kann im Prinzip ein Buch in PostScript verfassen und bestimmt dabei ähnlich wie mit der Schreibmaschine die exakten Positionen aller Zeichen auf den einzelnen Seiten.[39] In der Praxis werden PostScript-Dateien eher etwa aus mit LaTeX ausgezeichneten Quelltextdateien erzeugt, indem man die von TeX erzeugte DVI-Datei mit einem weiteren Programm (dvips) in PostScript umwandelt.

Im Allgemeinen versieht also der Verfasser den Text nur mit deskriptivem oder auch „physischem“ Markup (in einem Editor), ohne Zeilen-/Seitenumbrüche festzulegen, diese (und weitere Anordnungsweisen) werden vielmehr automatisch erzeugt und unter Umständen in einer Seitenbeschreibungsdatei abgelegt. Seitenbeschreibungsdateien kann man mit einem Viewer wie Ghostview (Postscript), Adobe Reader (PDF) oder YAP (für DVI unter Windows) bzw. xdvi (für DVI unter Linux – vgl. DVI-Betrachter) als Vorschau am Bildschirm betrachten und ausdrucken lassen. Sie sind auch für den elektronischen Austausch von Dokumenten bzw. ihre Verbreitung (Online-Publikation) gegenüber den Quellformaten vorteilhaft, da sie dem Empfänger das Neuerzeugen der Ansichtsversion des Dokuments (was sogar scheitern kann) ersparen („Austauschformate“).

Die „Seitenerscheinungsform“ oder „Seitendarstellung“ eines Dokuments muss jedoch nicht als eigene Seitenbeschreibungsdatei vorliegen. Bei manchen „Editoren“ kann/konnte man sie „direkt“ am Bildschirm betrachten oder ausdrucken. troff wurde zu ditroff erweitert, das eine eigene Seitenbeschreibungsdatei erzeugen kann, andere Textverarbeitungsprogramme wurden mit der Möglichkeit ausgestattet, PDF zu erzeugen.

Bei Webbrowsern (genauer: HTML-Renderern) und E-Book-Readern (die etwa HTML oder EPUB darstellen) wird die Seitendarstellung (der Umbruch von Fließtextabsätzen) schnell an sich ändernde Fensterbreiten oder Schriftgrößen angepasst.

Implementierung der Stilvariation bei generischer Auszeichnung

[Bearbeiten | Quelltext bearbeiten]

Implementierung einer Darstellungsweise

[Bearbeiten | Quelltext bearbeiten]

Für die Formatierung generisch ausgezeichneten Texts werden allgemeine Regeln zur Behandlung der einzelnen Tags (eventuell abhängig von „Attributen“ bei SGML-artigen Auszeichnungssprachen) in einer formalen Sprache (in einer Art Programm) festgelegt. Entsprechende „Regeldateien“ werden im SGML-Umfeld „Stylesheets“ genannt (bei LaTeX nicht). Zum Teil oder in einem ersten Schritt besteht die Formatierung darin, die generische Sprache in eine präsentationale zu „übersetzen“.

Im Falle von HTML wird die Formatierung einzelner Elemente durch entsprechende Anweisungen in CSS-Code bestimmt. Beispielsweise besagt die CSS-Zeile body { color: blue; background-color: yellow; }, dass eine HTML-Datei mit blauem Text auf gelbem Grund dargestellt werden soll, und mit em { color: red; } soll der Text in em-Elementen rot sein. In folgendem Beispieldokument

<head>
  <title>Hallo Welt!</title>
  <style type="text/css">
    body { color: blue; background-color: yellow; }
    em   { color: red; }
  </style>
</head>
<body>

<em>Hallo,</em> Welt!

<em>Hörst</em> du?

</body>

erscheint dieser CSS-Code in einem style-Element innerhalb des head-Elements. Das Ergebnis sollte in etwa

Hallo, Welt!

Hörst du?

sein und das gleiche wie mit

<head>
  <title>Hallo Welt!</title>
</head>
<body style="color: blue; background-color: yellow; ">

<em style="color: red; ">Hallo,</em> Welt!

<em style="color: red; ">Hörst</em> du?

</body>

In der zweiten Datei wurde <body> durch <body style="color: blue; background-color: yellow;"> ersetzt, und jedes em-Tag – generisches Markup – der ersten Datei wurde durch das präsentationale <em style="color: red; "> ersetzt. Die CSS-Anweisung tag { stil } wirkt also wie das Einfügen von style=stil in alle tag-Anfangstags.

Was HTML-Renderer tatsächlich tun, um CSS und HTML zusammenzuführen, kann hier nicht dargestellt werden. Immerhin handelt es sich bei den Beispieldateien sogar um XHTML, also Code einer XML-Sprache, und die „Übersetzung“ stellt eine Transformation dar, die (wiederum leicht missbräuchlich) durch XSL Transformation (XSLT) dargestellt werden könnte. XSL steht für Extensible Stylesheet Language. Im Falle von XML besteht die „puristische“ Anwendung von XSL und XSLT darin, generische XML-Sprachen gemäß XSL-Stylesheets in die präsentationale Sprache XSL-FO („XSL Formatting Objects“) zu übersetzen. In einfachen Fällen bedeutet das, wie oben, Ersetzen generischer durch präsentationale Tags. Genaueres ist den Artikeln zu entnehmen, auf die eben verwiesen wurde. XSL-FO ist selbst noch keine Seitenbeschreibungssprache und muss zum Ausdrucken erst etwa in eine PDF-Datei umgewandelt werden.

Eine XSL-Transformation erzeugt aus generischem Quellcode eines Dokuments tatsächlich eine Datei in einem anderen Textformat. Im Falle von LaTeX aber ist es ähnlich wie bei HTML-Renderern: generische Befehle werden in präsentationale bzw. (schließlich) prozedurale übersetzt, allerdings intern, auf Tokenebene. \emph{Hallo} wird zu einer Tokenkette emph{1H11a11l11l11o11,12}2, dann werden die beiden ersten Token und das letzte nach und nach durch einige andere ersetzt, wenn einige Prüfungen überstanden sind und die Neigung der umgebenden Schrift nicht positiv ist, resultiert eine ähnliche Tokenkette wie begingroupitshapeH11a11l11l11o11,12/endgroup, wobei sich unter Standardeinstellungen itshape wie fontshape>{i11t11}2selectfont verhält. Das Resultat wäre dasselbe wie das der „prozeduralen Version“ von \textit im Abschnitt #„Prozedural“ und „präsentational“. Im Gegensatz zum Document Object Model, bei dem das Dokument erst übersetzt wird, nachdem es komplett im Speicher repräsentiert ist, verarbeitet die TeX-Engine Datenströme wie den Quellcode, die Tokenketten und weitere interne Listen in möglichst kurzen Abschnitten und entledigt sich nach Ausgabe einer Druckseite weitgehend der dafür benötigten Speicherinhalte (so konnten schon vor Jahrzehnten dicke Bände gesetzt werden).

Im Falle von LaTeX (wie von TeX überhaupt und auch von ConTeXt) wird das Suchen und Ersetzen, das die Formatierung implementiert, durch einen internen Makroprozessor bewerkstelligt. Auch die 1981 von Charles Goldfarb vorgestellte die generische Auszeichnungssprache IBM Generalized Markup Language übersetzte Makros in die prozedurale, troff-ähnliche Sprache SCRIPT.

An den Beispielen sollten auch zwei Vorteile der generischen Auszeichnung gegenüber der prozeduralen erkennbar sein: Generisch ausgezeichneter Quellcode beansprucht weniger Speicherplatz als präsentational ausgezeichneter[40] (sobald die Zahl der entsprechenden Textelemente eine von der Komplexität der Ersetzungsregel abhängige Zahl übersteigt – was im Beispiel noch nicht der Fall ist), und in einem Texteditor ist bei generischer Auszeichnung der darzustellende eigentliche Text leichter wiederzufinden als bei prozeduraler Auszeichnung, er ist intuitiver zu lesen. (Vgl. auch Don’t repeat yourself und Abstraktion (Informatik).)

Dieser Speicherplatzeffekt wird noch verstärkt, wenn die Stildefinitionen (anders als im vorigen Beispiel) nicht im „Kopf“ der Textquelldatei – dem head-Element einer HTML-Datei oder oberhalb \begin{document} in einer LaTeX-Quelldatei (dort „Dokumentenpräambel“ genannt) – stehen, sondern in separaten Stildateien, die von den Textquelldateien eingebunden werden (Transklusion). Auf Websites, die eine Vielzahl separater Dokumente beherbergen, welche einheitlich gestaltet werden, sind das CSS-Dateien mit der Endung .css (Abschnitt in CSS). Im Falle von LaTeX trugen die Stildateien ursprünglich die Endung .sty für style. Heute bestimmen auch Dateien mit der Endung .cls, die von \documentclass eingelesen werden, die Darstellungsweise:

HTML LaTeX
<head>
  <title>Hallo Welt!</title>
  <link rel="stylesheet" type="text/css" href="style.css" />
</head>
<body>

<em>Hallo,</em> Welt!

<em>Hörst</em> du?

</body>
\documentclass{abc-art}
\begin{document}
  \emph{Hallo,} Welt!

  \emph{H\"orst} du?
\end{document}

Die beiden CSS-Zeilen von vorher könnten sich nun in der Datei style.css befinden, die wie folgt aussähe:

body { color: blue; background-color: yellow; }
em   { color: red; }

Darstellungsänderung

[Bearbeiten | Quelltext bearbeiten]

Im vorigen Beispielpaar kann man nun die Darstellung des ausgezeichneten Textquellcodes ändern, indem man jeweils den „Kopf“ ändert:

HTML LaTeX
<head>
  <title>Hallo Welt!</title>
  <style type="text/css">
    em { text-decoration: underline;
         font-style:      normal;    }
  </style>
</head>
<body>

<em>Hallo,</em> Welt!

<em>Hörst</em> du?

</body>
\documentclass{article}
\usepackage{ulem}
\begin{document}
  \emph{Hallo,} Welt!

  \emph{H\"orst} du?
\end{document}

Im Falle von LaTeX wurde hier der Formatierungsstil des fiktiven The ABC-Journal durch eine LaTeX-Standardklasse ersetzt und Transklusion der Datei ulem.sty[41] eingefügt. Diese definiert das aus \emph resultierende Token emph so um (setzt eine andere Makro-Ersetzungsregel in Kraft), dass die Betonung durch Understreichen statt Kursivstellung dargestellt wird. Der veränderte CSS-Code für das em-Element wirkt ebenso. Von der Schriftart abgesehen, sollte das Ergebnis mit HTML wie LaTeX so aussehen:

Hallo, Welt!

Hörst du?

Alternativ könnte der CSS-Code in style.css geändert werden. Für Fachzeitschriftsnummern können die von \begin{document} und \end{document} eingerahmten Teile der von den einzelnen Autoren eingesandten Quelltexte mit der Dokumentenpräambel des Journals zusammengefügt werden, so dass sie alle nach „Art des Hauses“ – gleichartig – formatiert werden.

Bei XML-Dokumenten kann die Darstellung geändert werden, indem man eine andere XSL-Transformation verwendet.

Der generisch ausgezeichnete Text des Dokuments muss zur Änderung der Darstellung also überhaupt nicht geändert werden. Darauf wies das World Wide Web Consortium in der Spezifikation von HTML5 als zweiten Nachteil präsentationaler Auszeichnung hin,[42] und Goldfarb[43] sprach von „Inflexibilität“ in Bezug auf Änderungen der Darstellungsweise als zweitem Nachteil prozeduraler Auszeichnung. – In der Praxis findet aber etwa LaTeX nicht immer die besten Zeilen- oder Seitenumbrüche, so dass die Bearbeiter einer Fachzeitschriftsnummer gelegentlich ein präsentationales \pagebreak o. ä. einfügen müssen.

(Statt \"o kann man mit LaTeX ö verwenden, wenn die Dokumentpräambel etwa \usepackage[utf8]{inputenc} enthält. Die so eingelesene Datei inputenc.sty ist ein Beispiel dafür, dass die Endung .sty leider nicht mehr ausschließlich für „Stil“ steht, solche Pakete bieten vielmehr oft Möglichkeiten, die Arbeit zu erleichtern, meist durch Erweiterung des Befehlssatzes.)

Fazit: Worin besteht die „Trennung von Inhalt und Darstellung“?

[Bearbeiten | Quelltext bearbeiten]

Im Falle von LaTeX und HTML enthält der Quellcode des Dokuments zwar Angaben zur Formatierung, bei rein deskriptiver/generischer Auszeichnung befinden sich die Angaben zur Formatierung jedoch ausschließlich in einem „Kopfteil“ der Quelldatei – im head-Element bzw. in der „Dokumentpräambel“. Der darzustellende Text mit generischem Markup befindet sich in einem anderen Teil des Quelldokuments – body-Element bzw. {document}-Umgebung. Die Trennung von Struktur und Präsentation o. ä. besteht dann darin, dass Quelldokumente zwei Bestandteile haben, von denen einer ausschließlich Formatierungsregeln angibt und der andere ausschließlich den Dokumenttext mit generischer Auszeichnung enthält.

Die Formatierungsregeln müssen sich nicht direkt im Kopfteil befinden, der Kopfteil bindet zumeist den größten Teil der Formatierungsregeln aus anderen Dateien ein (Transklusion). Im Falle von LaTeX muss die Datei mit den Angaben zur Formatierung (die „Steuerdatei“) nicht den gesamten darzustellenden Text enthalten, dieser wird oft auch – gerade im Fall von Büchern – ebenfalls aus anderen (generisch ausgezeichneten) Dateien eingebunden.

In anderen Fällen enthält das Quelldokument überhaupt keine Angaben zur Formatierung (bindet keine Dateien mit Formatierungsregeln ein, z. B. XML/XSL). Die „Trennung von Inhalt und Form“ – bzw. zur Abgrenzung von der Formalen Soziologie: von „Inhalt“ und „Formatierung“ – ist dann – noch deutlicher als schon im vorigen Fall – dadurch verwirklicht, dass der mit logischer Auszeichnung versehene Inhalt sich in anderen Dateien befindet als die Formatierungsregeln. Für die Wahl eines Darstellungsstils ist dann keine Änderung der Dateien erforderlich, die den darzustellenden Text („Inhalt“) enthalten.

Automatische Codeerzeugung und ursprünglicher Quellcode

[Bearbeiten | Quelltext bearbeiten]

Es wurde bereits angesprochen, dass „ausgezeichneter Text“, der der Darstellung eines Dokuments auf Ausgabegeräten (Drucker, Bildschirm) zugrunde liegt, automatisch aus einer anderen Form von „ausgezeichnetem Text“ erzeugt werden kann. Soweit die fixe seitenorientierte Darstellungsform noch als in einer Auszeichnungssprache kodiert angesehen kann (ist PostScript eine Auszeichnungssprache?, PDF?), wird sie praktisch immer durch ein Satzprogramm automatisch aus einer rein physischen (ohne semantisch-strukturelle Information), rein generischen (ohne Hinweise auf die Darstellungsweise, wie in HTML5 ohne das style-Attribut) oder physische und semantisch-strukturelle Angaben mischenden Auszeichnungssprache (wie bei „nicht-puristischer“ Verwendung von LaTeX) erzeugt. Sie kann direkt aus einer rein physisch ausgezeichneten Erscheinungsform des Dokuments erzeugt werden (PDF aus XSL-FO), und eine rein physische, nicht seiten-orientierte Form kann aus einer rein strukturellen Erscheinungsform (XHTML) automatisch erzeugt worden sein (etwa durch XSL-Transformation).

Wenn das Werk publiziert oder an einen Adressaten verschickt worden ist, oder wenn der für ein Archiv gewünschte Ausdruck vorliegt, geraten die zugrunde liegenden Dateien bestimmter Auszeichnungsformate oft in Vergessenheit, von manchen Anwendern werden sie auch gelöscht. Wenn das Dokument aber noch (teilweise) wiederverwendet werden soll, z. B. für eine neue, überarbeitete Buchausgabe, oder wenn ein vor Jahren gedruckter Artikel auch als HTML online publiziert werden soll, ist es gut, wenn die ursprüngliche (teils) semantisch-strukturelle Auszeichnung – der ursprüngliche Quellcode – immer noch verfügbar ist und nicht aus einem rein darstellenden Format „rekonstruiert“ werden muss (z. B. nicht nummerierte Abschnittsüberschriften und Unterabschnittsüberschriften).

Den automatisch erzeugten Code schauen sich Verfasser (oder Typisten) meist nicht an. Bei Verwendung von WYSIWYG-Editoren beachtet man typischerweise nicht einmal den ursprünglichen Quellcode. Ebenso ist es etwa bei LyX, einem Frontend für LaTeX, mit dem man semantisch-strukturell auszeichnen und die erzeugte Struktur auch am Bildschirm erkennen kann, ohne den Quellcode zu sehen.

(In Anbetracht unterschiedlicher Codierungsweisen von Textzeichen – Unicode oder … könnte man auch sagen, dass der ursprüngliche Quellcode in einem Hexdump besteht, den man sich nicht ansieht, der Texteditor präsentiert eine „anwenderfreundliche Version“ davon, die hinsichtlich der am Ausgabegerät zu lesenden Zeichen WYSIWYG-artig ist.)

HTML war einmal Format, in dem der „ursprüngliche Quellcode“ von Dokumenten notiert wurde. Inzwischen ist es auch ein Zielformat, es wird etwa (aus Datenbanken, die in XML notiert sein können) durch Skriptsprachen wie JavaScript und PHP – oder aus anderen Quellformaten mit Pandoc erzeugt. Um einen Text wie einen Wikipedia-Artikel auszuzeichnen, sind das jedoch keine Alternativen: der reine Text (wie er aus Browserfenster durch Copy and Paste extrahiert werden kann) muss getippt und markiert werden. Die < und > sind umständlich zu tippen und werden durch XML-Anforderungen noch vermehrt. Zum Teil müssen Attributnamen getippt werden, was das Verhältnis von in der Ausgabe anzuzeigenden Zeichen zu fürs Markup verwendeten Zeichen verschlechtert. LaTeX ist teilweise einfacher zu tippen und leichter zu lesen, da es (im Fließtext) hauptsächlich Positionsparameter anstelle von Key-Value-Angaben verwendet. Zudem können LaTeX-Anwender für in einem Dokument häufig auftretende Zeichenkombinationen (wie Tags – welche häufig auftreten, ist von Dokument zu Dokument verschieden) Abkürzungsbefehle einführen (in der Dokumentenpräambel oder in .sty-Dateien – dank eingebautem Makroprozessor). – Zur Vereinfachung der Erzeugung von (X)HTML-Dokumenten sind daher noch folgende Möglichkeiten ersonnen worden:

  • HTML-Editoren mit Autovervollständigung;
  • TeX4ht wandelt die DVI-Ausgabe von TeX in HTML oder auch XML um;
  • die Website Meta Language – Werkzeuge für Programmierer, dabei wird Makroprozessor m4 genutzt (vgl. LaTeX);
  • Content-Management-Systeme für Nichtprogrammierer, vgl. Redaktionssystem, das ist allgemeiner insofern, als hierbei auch andere Zielformate als (X)HTML anvisiert werden, und schließt die bereits mehrfach genannten WYSIWYG-Editoren ein;
  • vereinfachte Auszeichnungssprachen – diese werden nachfolgend genauer beschrieben. Sie stellen in Wikis das „ursprüngliche Quellformat“ dar, aus dem hauptsächlich XHTML erzeugt wird – daraus kann dann auch in guter Qualität gedruckt werden (PDF), etwa via XSL.

Vereinfachte Auszeichnungssprachen

[Bearbeiten | Quelltext bearbeiten]

Beiträge in Wikis, Blogs und Internetforen werden typischerweise in Webformularfenstern verfasst. Die Gestaltungsmöglichkeiten können dabei sehr begrenzt sein, was einem gepflegten Erscheinungsbild der sich ergebenden Seiten zugutekommen kann. Obwohl das Zielformat (in dem die Beiträge den Lesern präsentiert werden) HTML oder XHTML ist, wird HTML-Eingabecode im Formular allenfalls begrenzt akzeptiert (sonst weggefiltert). Das Markup verwendet (von den URLs für Hyperlinks abgesehen) oft nur (ungewöhnliche Kombinationen von) Interpunktionszeichen oder jedenfalls Zeichen, die keine Buchstaben sind; oder wenige HTML-Tags werden verkürzt und entsprechende Elemente nicht geschlossen (ähnlich wie in SGML), etwa

Textile Übersetzung in XHTML Beispieldarstellung
h3. Unterabschnitt <h3>Unterabschnitt</h3> Unterabschnitt

(ähnlich Haml). Dadurch stört das Markup den Lesefluss beim Verfassen des Beitrags im Formularfenster minimal. Für die Darstellung der Dokumente wird dieses Markup dann in die dafür erforderliche komplexere Auszeichnungssprache wie HTML oder XHTML serverseitig umgewandelt, etwa durch Pandoc oder, wie im Falle der Wikipedia, durch die MediaWiki-Software.

Markup-Beispiele mit zwei vereinfachten Auszeichnungssprachen
MediaWiki-Wikitext Markdown so … … oder so: ergibt XHTML Darstellungs-
beispiel
== Abschnitt ==
##Abschnitt
<h2>Abschnitt</h2> Abschnitt

* Punkt 1
* Punkt 2
* Punkt 3

- Punkt 1
- Punkt 2
- Punkt 3

* Punkt 1
* Punkt 2
* Punkt 3

<ul>
<li>Punkt 1</li>
<li>Punkt 2</li>
<li>Punkt 3</li>
</ul>

  • Punkt 1
  • Punkt 2
  • Punkt 3
[https://www.w3.org/ W3C] [W3C](https://www.w3.org/) <a href="https://www.w3.org/">W3C</a> W3C
'''fett'''
**fett**
__fett__ <b>fett</b> fett
''kursiv'' *kursiv* _kursiv_ <i>kursiv</i> kursiv

Weiter verzichten vereinfachte Auszeichnungssprachen typischerweise auf Nutzung einfacher Codezeilenumbrüche und des Einrückens von Code allein zu dessen Strukturierung (im Sinne der Lesbarkeit und Verständlichkeit); vielmehr beendet etwa im Falle von MediaWiki ein Codezeilenumbruch einen in der Darstellung eingerückten Absatz („hängender Einzug“) einer Liste oder eines Blockzitats. Ein sofort folgendes Sternchen (*) beginnt einen (neuen) Listenpunkt und wird als typografisches Aufzählungszeichen dargestellt. Nachteil dieser Methode sind mögliche Kollisionen mit einer anderen Funktion der entsprechenden Zeichen, die Fehler verursachen können. In Markdown z. B. beginnt ein kursiv geschriebener Text mit dem Sternchen (ich rufe *laut* um Hilfe), was am Zeilenanfang (*laut* rufe ich um Hilfe) mit der Verwendung für einen Listeneintrag kollidieren kann. Eingerückter Code (d. h. dem Codezeilenumbruch folgt mindestens ein Leerzeichen) wird in Wikitext „verbatim“ als „Code“ (ohne Syntaxhighlighting) dargestellt. Weitere und genauere Beispiel bieten die Artikel Wikitext und Markdown sowie die weiteren Artikel in der Kategorie:Vereinfachte Auszeichnungssprache.

Neben rein logischen („deskriptiven“) Auszeichnungen wie Überschriften und reinen Schriftauszeichnungen wie fett können weitere Funktionen erfüllt werden:

  • Tags zur zusätzlichen Auszeichnung eines Datenbestandes mit zusätzlichen Informationen und zur Kategorisierung;
  • Transklusionen, um Teile anderer Dokumente durch einen Verweis einzuschließen.

Zwar ist das hauptsächliche Zielformat solcher Sprachen HTML oder XHTML, jedoch können viele von ihnen dank Pandoc (in eingeschränkter Weise) sogar als Frontend für LaTeX und ConTeXt verwendet werden und so letztlich PDF als Zielformat haben, oder sie können so in Textverarbeitungsformate, E-Books und Dokumentationsformate (DocBook, Manpages) umgewandelt werden.

Historische Entwicklung

[Bearbeiten | Quelltext bearbeiten]

Vereinfachte Auszeichnungssprachen wurden schon immer in rein textbasierten Systemen (z. B. Readme oder E-Mails) zur Darstellung von Hervorhebungen wie Kursiv oder Fett verwendet, ohne dass diese weiter umgewandelt wurden. Besonders ist die Syntax von Markdown – das mit umgewandelt wird – eng an diese historische Praxis angelehnt.

Die meisten Auszeichnungssprachen haben sich in der Anwendung unterschiedlicher Software gebildet, es gibt kaum standardisierte oder einheitliche Lösungen, obwohl die Funktionen oft ähnlich sind.

Die wohl erste vereinfachte Auszeichnungssprache mit Umwandlung wurde 1994 von Ward Cunninghams entwickelt und 1995 als WikiWikiWeb zusammen mit dem Portland Pattern Repository veröffentlicht, siehe auch Chronologie der Hypertext-Technologien.

YAML und seine Untermenge JavaScript Object Notation (JSON) sind vereinfachte Auszeichnungssprachen für die Datenserialisierung.

Äußere Systematik: Einordnung als Programmiersprache oder Datenformat

[Bearbeiten | Quelltext bearbeiten]
Dateinamenserweiterungen und MIME-Typen
ausgewählter Auszeichnungssprachen
Auszeichnungssprache Dateiendung MIME-Typ
HTML .htm, .html text/html
PostScript .ps application/postscript
Rich Text Format .rtf text/rtf
TeX/LaTeX .tex text/x-tex
XML .xml text/xml

Zur Frage, ob eine Auszeichnungssprache eine Programmiersprache ist oder nicht, oder ob eine bestimmte Auszeichnungssprache wie HTML eine Programmiersprache (eine HTML-Datei ein „Programm“)[44] ist oder nicht,[45] finden sich gegensätzliche Äußerungen. Zu XML erklärte das W3C 2001, es sei keine Programmiersprache, sondern biete Regeln zum Festlegen von Textformaten zur Strukturierung von Daten,[46] also zum Festlegen von Datenformaten (damit steht es nicht allein).[47] Tatsächlich ergab die Entwicklung von SGML zu XML die Möglichkeit, Auszeichnungssprachen zu völlig anderen Zwecken als dem ursprünglichen – der Formatierung von Texten – zu nutzen. Beispielsweise wird die Konfiguration des Linux-Fenstermanagers Openbox in einer XML-Datei abgelegt; statt Zeilen der Gestalt key=value wie in den Konfigurationsdateien anderer Programme findet man hier <key>value</key> (vgl. anderes Beispiel), und übergeordnete Elemente wie mouse werden zur Gliederung der ungefähr 900 Zeilen umfassenden Datei verwendet. Es ist ganz und gar nicht beabsichtigt, diese Konfigurationsdatei als „Dokument“ zu „setzen“. Der Artikel XML nennt weitere Beispiele solcher ursprünglich nicht intendierter Anwendungsweisen von XML. Als Datenformat ist die in einer (Dokument-)Datei verwendete Auszeichnungssprache an den Dateinamenserweiterungen erkennbar (siehe Tabelle). Diejenigen Auszeichnungssprachen, die noch zum Erstellen von Dokumenten gedacht sind (HTML, PostScript, troff, LaTeX, RTF), bilden Dokumentenformate. Binäre Dokumentenformate (.doc, .pdf, das Ausgabeformat DVI von TeX) sind keine Auszeichnungssprachen.

Von den Musterbeispielen prozeduraler Auszeichnungssprachen[32]PostScript, TeX und dem Nachkömmling troff des urzeitlichen RUNOFF (auf das auch Goldfarbs GML aufsetzte) ist bekannt, dass sie Turing-vollständig sind. Insofern können diese beliebig komplexe Algorithmen darstellen und erfüllen so ein wesentliches, allgemein anerkanntes Merkmal von Programmiersprachen. XSLT bildet eine weitere Turing-vollständige Programmiersprache, deren „Befehle“ jedoch wie bei den vorgenannten „Sprachen“ für die Darstellung mit XML „deskriptiv“ ausgezeichneter Dokumente ausgelegt sind und die kurioserweise selbst in einem „XML-Datenformat“ notiert ist.[48] Ebenso ist die in XML notierte Sprache XQuery für XML-Datenbanken Turing-vollständig.

  • James H. Coombs, Allen H. Renear, Steven J. DeRose: Markup Systems and the Future of Scholarly Text Processing. In: Communications of the ACM. Band 30, Nr. 11, November 1987, ISSN 0001-0782, S. 933–947, doi:10.1145/32206.32209 (xml.coverpages.org, fdi.ucm.es [abgerufen am 7. Juli 2015]).
  • Robin Cover: SGML: A Textual Representation for Information Structure. In: Summer Institute of Linguistics, Inc. (Hrsg.): Notes on Computing. Band 16, (September/Oktober), 1997 (sil.org (Memento vom 22. April 2003 im Internet Archive) [abgerufen am 27. Juli 2015]).
  • Michael Downes: TeX and LaTeX 2e. In: Notices of the AMS. Band 49, Nr. 11, Dezember 2002, S. 1384–1391 (ams.org [PDF; 822 kB; abgerufen am 26. Juli 2015]).
  • Richard Furuta: Important papers in the history of document preparation systems: basic sources. In: Electronic Publishing: Origination, Dissemination & Design. Band 5, Nr. 1. John Wiley & Sons, Chichester UK März 1992, S. 19–44 (citeseerx.ist.psu.edu [abgerufen am 7. Juli 2015] Relevante Abschnitte: 4, 5, 6.1, 6.2.).
  • Charles Goldfarb: A Generalized Approach to Document Markup. In: Proceedings of the ACM SIGPLAN SIGOA Symposium on Text Manipulation (= SIGPLAN Notices). Band 16, Nr. 6, Juni 1981, S. 68–73 (citeseerx.ist.psu.edu [PDF; abgerufen am 9. Juli 2015]).
  • Michel Goossens, Frank Mittelbach, Alexander Samarin: Der LaTeX-Begleiter. 1. Auflage. Addison-Wesley, Bonn u. a 1994, ISBN 3-89319-646-3, Abschnitt 1.3 – Generisches Markup – und 1.4 – Die Notwendigkeit des visuellen Markups, S. 7–10 (englisch: The LaTeX Companion. 1994. Übersetzt von Claudia Kraft und Rebecca Stiels, Motivation von LaTeX durch die Beiträge Goldfarbs und Reids, die auch erläutert werden. Abschnitt 1.3.3 trägt den Titel „Die Trennung von Inhalt und Form“. Bemerkenswerterweise findet sich davon in der zweiten Ausgabe (Mittelbach und Goossens 2004f., s. u.) nur noch Bemerkungen zum Verhältnis von LaTeX zu Reids Scribe (S. 2) und ein Satz am Anfang des zweiten Kapitels, beides in völlig anderer Terminologie.).
  • Dmitry Kirsanov: Chapter 3: SGML and HTML DTD. Procedural and Descriptive Markup. In: Rick Darnell et al. (Hrsg.): HTML Unleashed. 1. Auflage. sams.net, Indianapolis 1997, ISBN 1-57521-299-4 (webreference.com (Memento vom 30. Juni 2015 im Internet Archive) [abgerufen am 23. Juli 2015]).
  • Frank Mittelbach und Michel Goossens, mit Johannes Braams, David Carlisle und Chris Rowley sowie Beiträgen von Christine Detig und Joachim Schrod: The LaTeX Companion, Second Edition. 4., überarbeitete Auflage. Addison-Wesley, Boston MA u. a. 2005, ISBN 0-201-36299-6, Abschnitt 1.1: A brief history, S. 1–6.
  • A. L. Oakley, A. C. Norris: Page description languages: development, implementation and standardization. In: Electronic Publishing: Origination, Dissemination & Design. Band 1, Nr. 2. John Wiley & Sons, Chichester UK September 1988, S. 79–96 (cs.nott.ac.uk [PDF; 122 kB; abgerufen am 3. August 2015] Auf S. 79f. werden 8 Definitionen von page description language aus früheren Veröffentlichungen zitiert und zusammengefasst. Der Abschnitt Schemes for the description of printed pages von S. 89 bis S. 92 beschreibt Beziehungen zwischen Seitenbeschreibungssprachen und [anderen] Auszeichnungssprachen.).
  • Eric Steven Raymond: The Art of Unix Programming. Addison-Wesley Professional, Boston 2004, ISBN 0-13-142901-9, Kapitel 8. Minilanguages (catb.org – u. a. zur Turing-Vollständigkeit einzelner Auszeichnungssprachen, Kapitelanfangsseite der HTML-Version vom 23. September 2003).
  • Tim Bray: On Semantics and Markup. 9. April 2003; (englisch, Darstellung von Dokumentauszeichnungsarten in wenigen Zeilen, kritisch zu „semantisch“).
  1. Genauer rahmen die „ASCII-Apostrophe“ in MediaWiki-Wikitext eigentlich nicht Elemente ein, und sie gestatten kein Verschachteln von Elementen, dafür erlauben sie überlappendes Markup: Das erste Tripel von Apostrophen in einem Quelltextabsatz erzeugt ein <b>, das nächste ein </b>, das dritte wieder ein <b> usw. Das erste Paar von Apostrophen, dem kein weiterer Apostroph folgt, erzeugt ein <i>, das nächste ein </i>, das nächste wieder ein <i> usw. Am Ende des Absatzes werden offene Tags automatisch durch schließende ergänzt.
  2. In HTML3.2 vom 14. Januar 1997 war davon noch nichts zu sehen, jedoch war am 17. Dezember 1996 mit CSS1 der Grundstein gelegt worden. Im Arbeitsentwurf für HTML 4.0 vom 8. Juli 1997 wurde dann angekündigt, dass „präsentationale“ Elemente und Attribute nach und nach durch Stylesheets ersetzt werden sollten.
  3. Vgl. das Informationspaket l2tabu.
  4. Das Beispiel ist eine Mischung aus PostScript#Ein Programmbeispiel und en:PostScript#"Hello world" und wurde mit Ghostscript getestet.

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. HTML5 – A vocabulary and associated APIs for HTML and XHTML. W3C Recommendation 28 October 2014. W3C, 28. Oktober 2014, abgerufen am 10. Juni 2015 (englisch): „the core language of the World Wide Web: the Hypertext Markup Language (HTML)“
  2. Meyers enzyklopädisches Lexikon. Mannheim 1971. Band 3, S. 188.
  3. HTML 4.01 Specification – W3C Recommendation. 15.2 Fonts. 24. Dezember 1999, abgerufen am 8. Juli 2015 (englisch).
  4. HTML5 – A vocabulary and associated APIs for HTML and XHTML – W3C Recommendation. 4.5.3 The strong element. 28. Oktober 2014, archiviert vom Original (nicht mehr online verfügbar) am 1. August 2015; abgerufen am 6. Oktober 2018 (englisch).
  5. <strong>: The Strong Importance element. In: MDN Web Docs. Abgerufen am 11. August 2019 (englisch): „Browsers typically render the contents in bold type.
  6. <em>: The Emphasis element. In: MDN Web Docs. Abgerufen am 11. August 2019 (englisch): „Typically this element is displayed in italic type.
  7. LaTeX/Fonts#Emphasizing text in den Wikibooks (englisch)
  8. Mittelbach und Goossens (#Literatur) S. 341ff.
  9. HTML5 – A vocabulary and associated APIs for HTML and XHTML – W3C Recommendation. 4.5.2 The em element. 28. Oktober 2014, archiviert vom Original (nicht mehr online verfügbar) am 1. August 2015; abgerufen am 6. Oktober 2018 (englisch).
  10. Dokumenttypdefinition
  11. a b HTML5 – A vocabulary and associated APIs for HTML and XHTML – W3C Recommendation. 1.10.1 Presentational markup. 28. Oktober 2014, abgerufen am 8. Juli 2015 (englisch).
  12. HTML5 – A vocabulary and associated APIs for HTML and XHTML – W3C Recommendation. 4.5 Text-level semantics. 28. Oktober 2014, abgerufen am 6. Oktober 2018.
  13. a b Markup Technologies ’98 Conference. Agenda and Schedule – Annotated. In: The CoverPages. 11. Januar 1998, abgerufen am 28. Juli 2015 (englisch).
  14. Richard Furuta: Important papers in the history of document preparation systems: basic sources. S. 20.
  15. a b c d e Richard Furuta: Important papers in the history of document preparation systems: basic sources. Abschnitt 4.1
  16. Goldfarb (#Literatur)
  17. a b Coombs, Renear und DeRose (#Literatur)
  18. a b c d Richard Furuta: Important papers in the history of document preparation systems: basic sources. S. 30.
  19. a b Tim Bray: On Semantics and Markup. Taxonomy of Markup. In: www.tbray.org. 9. April 2003, abgerufen am 28. Juli 2015 (englisch).
  20. Richard Furuta: Important papers in the history of document preparation systems: basic sources. bereits 1992 (Abschnitt 4.1).
  21. a b c HTML 4.01 Specification – W3C Recommendation. 15 Alignment, font styles, and horizontal rules. 24. Dezember 1999, abgerufen am 8. Juli 2015 (englisch).
  22. a b c d Robin Cover: SGML: A Textual Representation for Information Structure.
  23. Downes (#Literatur) S. 1368.
  24. Richard Furuta: Important papers in the history of document preparation systems: basic sources.  19.
  25. a b HTML 4.01 Specification – W3C Recommendation. 2.3.5 Style sheets. 24. Dezember 1999, abgerufen am 28. Juli 2015 (englisch).
  26. HTML 4.01 Specification – W3C Recommendation. 2.4.1 Separate structure and presentation. 24. Dezember 1999, abgerufen am 28. Juli 2015 (englisch).
  27. a b c d Goldfarb (#Literatur) S. 68.
  28. Goossens/Mittelbach/Samarin 1994 sowie Mittelbach und Goossens 2004 S. 2 (#Literatur).
  29. Mittelbach und Goossens (#Literatur) S. 2.
  30. Mittelbach und Goossens 2004 (#Literatur) S. 2–4.
  31. Donald E. Knuth: The TeXbook. Illustrations by Duane Bibby. Addison-Wesley, Reading MA u. a 1986, ISBN 0-201-13447-0, S. 267 ff. (Broschur ISBN 0-201-13448-9. Neben Makros gibt es weitere Expansionskonstrukte wie Konditionale und Auslesen von Registerinhalten, siehe Kapitel 20).
  32. a b c Tim Bray: On Semantics and Markup. Procedural Markup. 9. April 2003, abgerufen am 28. Juli 2015 (englisch).
  33. Learn Postscript. gsave … grestore. In: wordpress.com. 19. September 2007, abgerufen am 30. Juli 2015 (englisch, Miniprogramm als Beispiel).
  34. David Maxwell: Postscript Graphics State Commands. gsave. In: UBC Math Computing Lab Documentation. University of British Columbia, archiviert vom Original (nicht mehr online verfügbar) am 8. November 2015; abgerufen am 30. Juli 2015 (englisch).
  35. Goldfarb (#Literatur) S. 69
  36. Goossens/Mittelbach/Samarin 1994 (#Literatur) S. 8
  37. Richard Furuta: Important papers in the history of document preparation systems: basic sources. S. 25
  38. Richard Furuta: Important papers in the history of document preparation systems: basic sources. Abschnitt 6.2: Page description languages. Zitat: „Page description languages describe the positioning of graphical marks on a printed page.“
  39. Oakley/Norris (#Literatur) S. 91f.
  40. HTML5 – A vocabulary and associated APIs for HTML and XHTML – W3C Recommendation. 1.10.1 Presentational markup. 28. Oktober 2014, abgerufen am 12. August 2015 (englisch): „Presentational markup tends to be much more redundant, and thus results in larger document sizes.“
  41. Datei ulem.sty. Abgerufen am 17. Juli 2018.
  42. HTML5 – A vocabulary and associated APIs for HTML and XHTML – W3C Recommendation. 1.10.1 Presentational markup. 28. Oktober 2014, abgerufen am 12. August 2015 (englisch): „It is significantly easier to maintain a site written in such a way that the markup is style-independent. For example, changing the color of a site that uses <font color=""> throughout requires changes across the entire site, whereas a similar change to a site based on CSS can be done by changing a single file.“
  43. Goldfarb (#Literatur) S. 68 f.
  44. Dmitry Kirsanov (#Literatur): HTML Unleashed. SGML and the HTML DTD. Introduction. 16. Juni 1997, archiviert vom Original (nicht mehr online verfügbar) am 30. Juni 2015; abgerufen am 6. Oktober 2018: „SGML […] think of it as a programming language to build working programs (HTML being one of them) […]“
  45. Jukka Korpela (Technische Universität Tampere): Programs vs. markup. or why HTML authoring is not programming. 16. November 2015, archiviert vom Original (nicht mehr online verfügbar) am 22. Januar 2011; abgerufen am 13. Juli 2014 (englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.cs.tut.fi
  46. XML in 10 points. W3C, 22. September 2014, archiviert vom Original (nicht mehr online verfügbar) am 20. Dezember 2016; abgerufen am 6. Oktober 2018 (englisch): „Note: This document is no longer maintained but is left for historical purposes.“
  47. Christoph Prevezanos: Technisches Schreiben: Für Informatiker, Akademiker, Techniker und den Berufsalltag. Abschnitt 2.1.5: XML-Umgebungen. Carl Hanser, München 2013, ISBN 978-3-446-43721-0, S. 13 (eingeschränkte Vorschau in der Google-Buchsuche [abgerufen am 16. Juli 2015] E-Book ISBN 978-3-446-43759-3). Zitat: „XML ist keine Textverarbeitung, keine Programmiersprache und auch kein konkretes Programm. Stattdessen handelt es sich um eine Auszeichnungssprache, mit der sich Texte strukturieren und die Elemente deklarieren lassen.“
  48. Stephan Kepser (Universität Tübingen, SFB 441): A Simple Proof for the Turing-Completeness of XSLT and XQuery. In: Extreme Markup Languages 2004® (Montréal, Québec) (= Proceedings of Extreme Markup Languages). 2004 (HTML-Fassung des Vortragtexts [abgerufen am 19. Juli 2015]). HTML-Fassung des Vortragtexts (Memento des Originals vom 4. Mai 2012 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/conferences.idealliance.org