HTML war die erste wirklich populäre Auszeichnungssprache
Vor der Hypertext Markup Language HTML waren Auszeichnungs- oder Markup-Sprachen auf einige spezialisierte Nischen beschränkt. Die Popularität von HTML verdankt sich der Tatsache, dass es erlaubt sehr schnell einfach strukturierte Hypertext-Dokumente für die Veröffentlichung im Web zu erstellen. Bei allem, was über Texte mit ein paar Überschriften, Bildern und Hervorhebungen hinausgeht, stößt HTML aber schnell an Grenzen. Daran haben auch die meisten der seit der Version 2.0 hinzugekommenen Erweiterungen nicht viel geändert, da sie oft dem Gedanken des generischen oder strukturierten Markup widersprachen und statt der Struktur das gewünschte Erscheinungsbild eines Dokuments beschrieben.
Schon das für viele Texte wichtige strukturelle Element einer Fußnote kann in HTML nicht vernünftig ausgezeichnet werden. Im nie verabschiedeten Entwurf HTML 3.0 war dafür ein Tag vorgesehen:
Irgendein Text.<fn>Dies ist eine Fußnote</fn>
Dadurch konnte klar gesagt werden, dass "Dies ist eine Fußnote" eine Fußnote zu "Irgendein Text" ist. Dieses Tag hat es aber nicht in das von den großen Browserherstellern verschlimmbesserte HTML 3.2 geschafft, und heute findet man satt dessen oft Konstruktionen, bei denen im Text etwas wie
Irgendein Text.<a name="fn3ref" href="#fn3"><sup>4</sup></a>
steht und sich der Text aller Fußnoten dann irgendwo am Ende des Dokuments in
einer Liste vom Typ dl befindet:
<dt><a name="fn3" href="#fn3ref">4</a><dt> <dd>Dies ist eine Fußnote</dd>
Das hat natürlich verschiedene Nachteile: Man muss schon bei der Erstellung des Dokuments die Fußnoten durchnummerieren (und es gibt wirklich Programme, die die im Text erscheinenden Fußnoten mit Eins und die Label mit Null beginnend zählen). Auch nimmt man dem Leser die Möglichkeit, die Fußnoten seinen Vorlieben entsprechend anzeigen zu lassen. Sie erscheinenen immer am Ende des Textes, selbst wenn er sie viel lieber in einem Popup-Fenster oder in einer eigenen Spalte am Rand hätte. Schließlich ist es sehr schwer, die Zuordnung zwischen den Fußnoten und den Textstellen, zu denen sie gehören, automatisch zu erkennen, was man zum Beispiel benötigen könnte, wenn man den Text für die Druckerausgabe formatieren will.
Derartige Probleme werden um so schwieriger, je weniger die dargestellte Information einem einfach strukturierten Text entspricht. Einen Katalog von Ersatzteilen, der für jedes Originalteil auch verzeichnet, welche Teile von anderen Herstellern statt dessen verwendet werden können und was diese kosten, kann man mit einer HTML-Tabelle ansprechend gestaltet anzeigen. Ein Programm bei einem Einzelhändler, das sich diese Liste aus dem Web holt und dann das jeweils günstigste passende Ersatzteil suchen soll, dürfte aber einige Schwierigkeiten haben, diese Informationen aus dem HTML der Seite wieder herauszufischen. Um solche Anwendungen effektiv umsetzen zu können, braucht man keine Hypertext Markup Language, sondern eine Ersatzteil Markup Language.
SGML ist flexibel, aber komplex
Eine solche Ersatzteil Markup Language zu definieren ist kein grundsätzliches Problem (es gibt sie tatsächlich), und die dafür nötige Technik existiert immerhin schon seit der Mitte der 80er Jahre als ein ISO-Standard: Die Standard Generalized Markup Language SGML. SGML ist eine Metasprache, die die Definition (fast) beliebiger Markup-Sprachen erlaubt. Auch HTML ist seit der Version 2.0 als eine SGML-Anwendung definiert.
Das Problem mit SGML ist, dass die große Flexibilität mit einer erheblichen Komplexität erkauft wird. Dies macht es relativ schwierig, Programme zu schreiben, die korrekt mit allen Facetten von SGML umgehen können. Außerdem muss für die korrekte Interpretation eines SGML-Dokuments schon auf der syntaktischen Ebene meist die gewählte Anwendung in allen Details bekannt sein. (Das ist das gleiche Problem wie ich es einleitend bei LaTeX diskutiert habe.) SGML erlaubt z. B. viele Formen von Abkürzungen, bei denen bestimmte, aus der Struktur der Anwendung heraus "offensichtliche" Elemente weggelassen werden können, da sie das verarbeitende Programm aus dem Zusammenhang rekonstruieren kann. Eine etwas böse Umschreibung dieses Sachverhalts besagt, dass jede Schreibkraft ein korrektes SGML-Dokument erstellen kann, dass man aber einen Consultant braucht, um die Informationen wieder aus dem Dokument herauszuholen.
Dass das Web funktioniert, liegt daran, dass es nur eine
SGML-Anwendung benutzt, eben HTML, und die Eigenschaften dieser einen
Anwendung in alle Browser eingebaut sind.
Aber schon in der Definition von HTML schlagen einige Subtilitäten von
SGML durch, die viele Autoren verblüffen dürften und teilweise sogar
alle verbreiteten Browser (amaya habe ich nicht
getestet) scheitern lassen.
Ein Beispiel sind die folgenden beiden kurzen HTML-Dokumente, die
nicht nur syntaktisch korrekt, sondern auch (im sog. Element
Structure Information Set ESIS) absolut identisch sind:
|
|
||||||||||||||||||||||||||||||||||||||||
![[Ext. Link]](../../icons/ext.png "[Ext. Link]"){kind=icon} gültig! |
gültig! |
Die ersten drei Zeilen sind bei beiden gleich und legen den
Dokumententyp jeweils auf die strikte Variante der letzten
veröffentlichten Definition von HTML fest.
Im rechten Dokument folgen in den Zeilen vier und fünf die Tags
<html> und <head>, die den Beginn der
gleichnamigen Elemente anzeigen.
Diese beiden Elemente müssen aber in einem HTML-Dokument immer an
dieser Stelle kommen, weshalb die Tags optional sind und weggelassen
werden können.
Dies ist im linken Dokument geschehen, jeder Browser kann den Beginn
der Elemente erschließen.
Das gleiche gilt für das body-Element, das immer auf das
head-Element folgen muss, und auch das Ende von
html, head und body kann aus
dem Zusammenhang erschlossen werden.
Auch diese ganzen Tags sind optional, weshalb die Zeilen sieben, acht,
zwölf und dreizehn des rechten Dokuments problemlos weggelassen werden
können.
Das title-Element in Zeile vier bzw. sechs muss genau
ein mal in dem head-Element vorkommen, und anders als bei
den bisher diskutierten Elementen müssen das Start- und Endtag immer
angegeben werden.
Beim p-Element (Zeilen fünf bzw. neun), das einen Absatz
markiert, ist nur das Starttag vorgeschrieben, das Endtag kann
weggelassen werden.
Ein Absatz endet, wenn der nächste anfängt oder bei dem nächsten
Element, das nicht Teil eines Absatzes sein kann.
Bis hierhin kommen die üblichen Browser noch mit, die letzten beiden
Zeilen des linken Dokuments nutzen aber SGML-"Features", die sie nicht
beherrschen.
In Zeile sechs befindet sich ein leeres Starttag, das nach den für
HTML gültigen Regeln von SGML an dieser Stelle zu einen
<p>-Tag ergänzt werden muss.
Alle von mir getesteten Browser ignorieren dieses Tag entweder, oder
stellen es als <> dar, beides ist falsch.
Zeile sieben nutzt zwei Abkürzungen:
Die Konvention, dass man die Anführungszeichen um den Wert eines
Attributs weglassen kann, wenn er nur aus Buchstaben und Zahlen
besteht, und ein minimiertes Endtag nach der Regel, dass
<tag>Inhalt</tag> und <tag/Inhalt/
gleichwertig sind.
Auch diese Abkürzung beherrscht kein Browser.
Es wäre vermutlich auch verheerend, wenn sich ein Browser in dieser
Hinsicht standardkonform verhalten würde.
Zu viele Webseiten enthalten Links wie
die damit zuverlässig nicht funktionieren würden. (Dies ist übrigens die Erkärung für die auf den ersten Blick verwirrende Fehlermeldung, die der<a href=irgend/ein/pfad.html>zum Ziel</a>
Validator des W3C bei derartigen Konstruktionen liefert:
Er beschwert sich darüber, dass er ein schließendes
</a>-Tag findet, zu dem es kein öffnendes Tag gibt.
Für einen SGML-Parser ist das <a> Tag bereits bei dem
Schrägstrich nach dem "ein" zu Ende, den alle Browser und
wahrscheinlich auch der Autor das Dokuments für einen Teil einer
relativen URL halten.)
Gesucht: Eine Sprache, die einfach und flexibel ist
Für HTML spricht seine Einfachheit, aber die mangelnde Flexibilität behindert viele eigentlich sinnvolle verteilte Anwendungen im Web. SGML dagegen hätte die nötige Flexibilität. Auf eine umfassene Unterstützung durch die Browserhersteller zu hoffen, erscheint aber sehr optimistisch, da sie nicht einmal eine einzelne SGML-Anwendung korrekt implementieren können. Außerdem bliebe auch dann noch das Problem, dass zu jedem Dokument auch immer die Definition des Dokumententyps mit übertragen werden muss, da sonst sicht einmal die Struktur, ganz zu schweigen von der Bedeutung des Dokuments, rekonstruiert werden kann.
In dieser Situation setzte sich das
W3C
die Aufgabe, eine
Auszeichungssprache zu entwickeln, die einen großen Teil der
Flexibilität von SGML bietet, aber ähnlich einfach (und vor allem
einfach zu implementieren) ist wie HTML.
Die Lösung, zu der man kam, ist die Extensible Markup Language XML.