Verarbeitung von HTML: Strenge oder Fehlertoleranz?

Eine leicht technisch angehauchte Antwort und Ergänzung zu Tims Essay Bewegung im W3C.

Die Aufregung ist perfekt: Tim Berners-Lee gibt zu, dass die XML-Revolution gescheitert ist, und Kommentatoren erklären XHTML damit für mausetot, andere verteidigen das Konzept von XHTML und betonen dessen Segnungen.

Als jemand, der die Vorteile von XHTML und »the fruits of well-formed systems« für Webentwickler zu schätzen gelernt hat, kann ich – wenn auch mit vielen Einschränkungen – eher an die letztgenannte Argumentation anknüpfen und möchte inbesondere den Aspekt der maschinellen Verarbeitung weiter ausführen. XHTML ist eine Tür zur »Plattform« XML – ein etabliertes Framework mit breit unterstützten Schnittstellen und zahlreichen Tools. Dass diese Sphäre für die normalsterblichen Webautoren und ‑entwickler bisher unzugänglich blieb, stimmt absolut. Doch es ist noch zu früh, die Gegenbewegung auszurufen: Anfänger sollten meines Erachtens auch weiterhin XHTML lernen und möglichst wohlgeformten und validen Code schreiben.

Eine Entwicklung der letzten Jahre ist klar – Semantisches HTML gewinnt. Nachdem die Präsentation ausgelagert wurde, wendete sich der Fokus auf die sinnvolle und aussagekräftige Textauszeichnung. Es werden durch die Struktur immer mehr Informationen im Code untergebracht. Mit Metadaten, Mikroformaten und RDFa geht HTML den nächsten logischen Schritt in Richtung bedeutungsvolles Datenformat.

Es ist derzeit nicht trivial, diese Fülle an Daten maschinell auszuwerten und zugänglich zu machen, denn die wenigsten Dokumente halten sich an grundlegende syntaktische Regeln der Sprache. Jegliche Software, die HTML-Code verarbeitet, muss daher ultraliberal und infolgedessen ultrakomplex sein. Dieses besonders fehlertolerante Einlesen eines HTML-Dokuments zu einer DOM-Baumstruktur nennt sich »Tag-Soup-Parsing«. Ein solcher Parser sieht ein HTML-Dokument nicht als logische und geordnete Abfolge von zusammengehörigen Tags, Zeichendaten usw., sondern als möglicherweise wirre »Suppe« dieser Einheiten. Fast alle Web-Browser arbeiten standardmäßig so.

XHTML sollte als XML-Anwendung diese technischen Probleme ein für alle Mal lösen. Ein XML-Parser erwartet Wohlgeformtheit von einem Dokument, ansonsten bricht er das Parsen sofort und ohne Versuch einer Rettung ab. Wer XHTML also für gescheitert ansieht, weil dessen Entwickler den Faktor Mensch ignoriert haben, übersieht, dass XHTML als Lösung für ein technisches Problem gedacht war, das nach wie vor akut bleibt.

Mikroformate sind ein gutes Beispiel: Auch wenn sie ständig als Aufsatz auf XHTML und XML dargestellt werden, sind sie faktisch ein Aufsatz auf HTML, das als Tag-Soup geparst wird. Das ist gut so, denn Mikroformate sind momentan deshalb so erfolgreich, weil die tatsächlichen Anwendungen vollkommen auf die ungemein populärere Tag-Soup ausgerichtet sind. Mikroformate stehen also ganz im Trend von HTML 5 (Pragmatismus, Abwärtskompatibilität, Fehlertoleranz, Integration statt Auslagerung) und setzen sich vom XML-Trend der strengen Verarbeitung ab. Mit HTML 5 wird »Tag-Soup« plötzlich von einem Schreckensszenario zu einem eher positiven Begriff.

Wenn XHTML also nicht die Basis von Mikroformaten ist, ergibt sich die Herausforderung, auf einfache Weise Mikroformate aus potenziell fehlerhaften HTML-Dokumenten zu extrahieren. Ich sehe das (gegenwärtig) als praktischen Nachteil von Mikroformaten – leider stieß diese Äußerung auf wenig Verständnis. Dabei hatte ich mir nur Gedanken darüber gemacht, wie ich konkret die Auszeichnungen in meinen Dokumenten wieder extrahieren und weiterverwenden kann. Da scheint mir noch eine Lücke zu klaffen, für die Praxislösungen entwickelt werden müssen.

Auch wenn die traditionellen Techniken des »Semantic Webs«, z.B. RDF mit Vokabularen wie Dublin Core und FOAF, mittlerweile zu Gunsten von Mikroformaten als »uncool« und wirklichkeitsfremd abgetan werden, haben sie einen Vorteil: Ihre automatisierte Erzeugung und Verarbeitung ist recht einfach, da es sich um von HTML klar getrennte, zwangsweise wohlgeformte XML-Formate handelt – selbst wenn das sicher ein Grund ist, warum sie sich nicht durchsetzen konnten. Es gibt Standardbibliotheken, mit denen sich die gewünschten Informationen leicht abfragen lassen.

Mikroformate und sonstige bedeutungsvolle Strukturen in HTML-Dokumenten können nur sinnvoll über die DOM-Schnittstelle extrahiert werden. Gegenwärtig gibt es aber keine Standardlösungen, Tag-Soup einfach zu parsen. Auch wenn HTML 5 momentan die Syntax von HTML jenseits von XML neu definiert und auch die Parser-Logik spezifiziert, stehen solche Parser noch nicht in der Webentwicklung zur Verfügung. Es gibt zwar diverse spezielle Tag-Soup-Parser, aber ihre Einsatzfähigkeit steht in keinem Vergleich zu den üblichen XML-Bibliotheken. Auch wenn z.B. libxml2 über einen Tag-Soup-Parsingmodus verfügt, arbeitet dieser momentan noch genauso willkürlich wie jeder andere fehlertolerante Parser z.B. im Browser.

Was heißt das nun? Ian Hickson hat mit seinen Untersuchungen zum Tag-Soup-Parsing der verbreiteten Browser gezeigt, wie absurd die jetzige, nicht regulierte Praxis ist. Ob XHTML (Strenge) oder HTML 5 (Toleranz), ohne genaue Parsing-Regeln geht es nicht. Gerade die wild gewachsene Fehlertoleranz der verbreiteten Parser bedarf einer Spezifizierung und Vereinheitlichung. Erst wenn diese gerade entstehende Theorie wieder in der Praxis angekommen ist, lassen sich schmerzfrei Anwendungen entwickeln.

Tomas Caspers kommentiert:

Das Web ist aber gerade erst durch diese Fehlertoleranz zu dem Massenmedium geworden, in dem jeder mit minimalen Vorkenntnissen seine Meinung kundtun kann. … Um für die Zukunft gerüstet zu sein brauchen wir also keine noch strikteren Regeln, sondern eindeutige Regeln zur Fehlertoleranz, an die sich die maßgeblichen Browserhersteller halten können.

Die Forderung von Websurfern und Webautoren nach einem fehlertoleranten System, das jeden teilhaben lässt, spiegelt nur einen Teil des Webs wieder. Aus der Sicht von Programmierern sind angereicherte HTML-Dokumente momentan noch der Horror. Im Web‑2.0‑Kontext haben Web Services, Mashups und Syndication schon längst gezeigt, dass es nicht ohne definierte, teilweise sehr strenge Formate geht. Auch die Mikroformate-Community, die sich derzeit vornehmlich auf die Auszeichnung mit Mikroformaten stürzt, wird sich mit dieser Frage beschäftigen müssen, sobald kleine und große Web-Dienste und schließlich jeder Entwickler von diesem Mehrwert Gebrauch machen wollen. Die Nützlichkeit des neuen Semantischen Webs wird von der Klärung dieser Grundfrage abhängen.