Was ist ein guter Standard?

Ein Essay über die Designprinzipien des W3C

Warum enthält HTML keine Tags fürs das Styling? Warum kann man in SMIL keinen Text einfügen? Warum enthält CSS keine Befehle zur Transformation eines Dokuments? Warum, kurz gesagt, modularisiert das W3C seine Spezifikationen und warum auf genau diese Art und Weise? Dieser Essay versucht, zu erläutern, was die Entwickler in den verschiedenen W3C-Arbeitsgruppen meinen, wenn sie von Begriffen wie Effizienz, Wartbarkeit, Zugänglichkeit, Erweiterbarkeit, Erlernbarkeit, Einfachheit oder Langlebigkeit reden.

Anders als es vielleicht scheint, werden W3C-Spezifkationen vor allem für Menschen gestaltet, nicht für Computer. Sie denken vielleicht, dass <h1>, è und </ul> hässlich und unintuitiv wirken, aber was würden Sie denken, wenn wir statt dessen die Bezeichnungen A378, 30C9 und 38F0 gewählt hätten? Viele dieser Bezeichnungen stellen einen Kompromiss zwischen Lesbarkeit für den Menschen und Effizienz für den Computer dar. Einige sind lesbarer als andere, weil wir erwarten, dass mehr Leute sie lesen, wieder andere können eher kryptisch sein, weil wohl »nur« Programmierer sich den Quelltext ansehen werden.

Aber warum möchten wir überhaupt, dass Menschen Spezifikationen lesen? Der Grund ist, dass alle unsere Spezifikationen unvollständig sind. Weil Menschen – für gewöhnlich andere Personen als die ursprünglichen Entwickler – sie ergänzen sollen. Kein Computer der Welt wird eine neue Technologie von selbst erfinden. Jemand wird einen Blick auf HTML werfen, es verstehen und sich über eine »coole« neue Technologie Gedanken machen, die sich mit HTML ergänzt. Auf diesem Weg kommt das Web (und nicht nur das Web) voran.

Aus dem gleichen Grund versuchen wir, Spezifikationen in einem angemessenen Umfang zu verfassen. Sie müssen einen sinnvollen Teilbereich der Technologie beschreiben, aber nicht in derartigem Umfang, dass er für eine einzelne Person zu groß ist, um ihn verstehen zu können. Denn schließlich kommen neue Ideen für gewöhnlich von einzelnen Personen.

Die wohl bekannteste Richtlinie im Web ist die Trennung von Struktur und Styling. Dies hat zu der Trennung von HTML und CSS in zwei seperate Spezifikationen geführt. Und eine gute Idee war es dazu. Hinter diese Regel stecken Aspekte der Wartbarkeit und Implementierbarkeit, sie erleichtert die Suche nach dem richtigen Experten und vieles mehr, wie ich im weiteren Verlauf dieses Essays erläutern werde.

Das Web handelt von der menschlichen Kommunikation, aber dieser Essay macht hoffentlich klar, dass auch das Verfassen von Spezifikationen eine Form der menschlichen Kommunikation darstellt. Ein Wort fasst nahezu alle griffigen Schlagworte dieses Essays zusammen: Usability!

Wartbarkeit

Sowohl Spezifikationen als auch Dateien oder Programme, die ihnen entsprechen, müssen gewartet werden. Es gibt kaum Daten oder Dienste, die niemals aktualisiert oder konvertiert werden müssen. Manchmal kann ein Programm die Änderungen vornehmen, aber irgendwann kommt immer der Punkt, an dem eine größere Änderung vorgenommen werden und ein Mensch einbezogen werden muss. Dann ist es von Vorteil, wenn die Größe eines zu ändernden Projektes überschaubar ist und eine klare Struktur vorliegt. Zudem kann eine lange Zeit vergangen sein, seit das Projekt das letzte Mal bearbeitet worden ist, und womöglich hat der ursprüngliche Autor vor längerer Zeit zu einem besseren Job gewechselt. Es ist vermutlich unvermeidbar, dass zum Beispiel ein XSL-Stylesheet schwieriger zu ändern ist als ein CSS-Stylesheet, aber gerade dann ist es gut, dass die XSL-Entwickler einige Zeit dafür aufgewendet haben, geeignete Schlüsselwörter auszuwählen, eine Syntax für Kommentare bereit zu stellen und Code-Einrückungen zu erlauben.

Natürlich gibt es keine Hilfe für Autoren (oder Programme!), die unlesbaren Code generieren. Falls Sie HTML kennen und mal einen Blick auf den Quelltext der einen oder anderen Website geworfen haben, haben Sie sich wahrscheinlich hin und wieder gewundert, welches Monster in der Lage ist, den HTML-Code einer einfachen Webseite oder E-Mail in einer Art und Weise zu verstümmeln, dass es schwer ist zu glauben, dass HTML als »strukturierte Sprache« bezeichnet wird. Manche Menschen bringen alles durcheinander, wenn man ihnen die Möglichkeit dazu bietet.

CSS zum Beispiel hat viele Funktionen, um Menschen bei der Wartung von Stylesheets zu unterstützen: @import erlaubt es, große Stylesheets in logische Einheiten aufzuteilen; die Gruppierung von Selektoren und Regeln ermöglicht es, Teile gemeinsam zu verwalten und zusammen zu verändern; zusammenfassende Eigenschaften (Shorthand Properties) bieten einen bequemen (und schnellen) Weg, in einer einzigen Regel unterschiedliche Eigenschaften festzulegen, die zusammengehören.

Andererseits geht CSS nicht so weit, dass es mächtige Funktionen anbietet, wie sie in Programmiersprachen verwenden werden können: Makros, Variablen, symbolische Konstanten, Bedingungen, Ausdrücke mit Variablen und so weiter. Diese Dinge gäben Profis eine Menge Möglichkeiten an die Hand, weniger erfahrene Nutzer jedoch könnten sich unwissentlich um Kopf und Kragen programmieren; oder – was wahrscheinlicher ist – sie wären dermaßen abgeschreckt, dass sie mit CSS nichts mehr zu tun haben wollen. Hier gilt es, einen Mittelweg zu finden, und für CSS ist dieser Mittelweg ein anderer als für manch andere Dinge.

Gerade bei CSS ist es Tatsache, dass erfahrenen Usern weitere Möglichkeiten angeboten werden. Es existiert das DOM, das den Zugriff auf CSS durch jede beliebige Programmiersprache ermöglicht. Damit sind wir beim Thema Modularität.

Modularität

Menschen können nur mit einer beschränken Anzahl an Konzepten gleichzeitig arbeiten. Das Kurzzeitgedächtnis, welches bei der Lösung eines Problems auf geistiger Ebene beansprucht wird, kann nur sechs oder sieben unterschiedliche Dinge gleichzeitig behalten. Um ein Problem zu lösen, unterteilen wir es deswegen in höchstens sechs Einheiten und erarbeiten die Gesamtlösung aus den Einzellösungen heraus. Jede Einheit steht für ein Teilproblem, das eines nach dem anderen gelöst werden muss. Man kann jedes Teilproblem selbst lösen, aber man kann es auch von jemand anderem lösen lassen. Wenn die Einheiten klein genug sind, dass man ihnen ansprechende Namen zuweisen kann, nennen wir sie »Module«.

Aber woher weiß man, dass man ein Problem in die richtigen Einheiten unterteilt hat? Vor allem durch Ausprobieren, wenngleich wir einige intuitive Fähigkeiten haben, die hauptsächlich auf unseren Sprachkenntnissen basieren, an denen wir uns orientieren können.

Wenn wir Module definieren, versuchen wir »logische Einheiten« zu finden, also Dinge, die anscheinend zusammengehören. Das hat nichts mit Logik zu tun, sondern mit unserer Fähigkeit, Dinge unter einem gemeinsamen Nenner zu gruppieren. Denn wenn wir eine Gruppe mit einem kurzen Namen bezeichnen können, bedeutet dies vermutlich, dass es sich um ein aus einem anderen Bereich bekannten Problem handelt. Dabei verlassen wir uns hauptsächlich auf Metaphern, indem wir Namen aus anderen Problemfeldern verwenden. Dadurch existieren Begriffe wie »password«, »style sheet«, »firewall«, »protocol« und natürlich »Web« (wobei einige Metaphern besser als andere sind…)

Gelegentlich stellt sich heraus, dass ein Modul möglicherweise ein Teil eines anderen Problems ist. Dadurch fanden die Syntax- und Selektor-Module von CSS 3 in der STTS Document Transformation Language Verwendung, und PNG findet als Format für Mauszeiger und Bitmaps in SVG Anwendung. Einige Dokument-Sprachen verwenden eine Menge HTML, aber es ist umstritten, ob man von einer großen Anzahl von HTML-Modulen oder einfach von HTML-Varianten sprechen soll. Wahrscheinlich letzteres, da ihre Funktion sich so sehr mit der von HTML überlappt, dass es einen Verstoß gegen das Prinzip der minimalen Redundanz bedeuten würde.

Zugänglichkeit

Der Begriff »Zugänglichkeit« beschreibt hauptsächlich das Maß, inwiefern etwas zugänglich für Menschen mit Behinderungen ist, aber im weitesten Sinne bemisst er ebenfalls die Beständigkeit gegenüber externen oder temporären Behinderungen, wie zum Beispiel eine laute Umgebung oder schlechte Beleuchtung.

Die beste Methode, Zugänglichkeit zu gewährleisten, ist, Daten in der höchstmöglichen Abstraktionsstufe zu kodieren, aber darüber hinaus ist es ebenfalls wichtig, auf bereits existierende Zugänglichkeits-Technologien zu setzen.

Die Aufteilung in Struktur und Styling ist ein gutes Beispiel: statt einfach nur zu beschreiben, dass etwas rot ist, erlauben W3C-Formate einem Autor (und sie legen es ihm auch nahe), zunächst zu beschreiben, warum etwas rot ist. Die Färbung an sich ist der nächste Schritt. In HTML zum Beispiel schreibt ein vorsichtiger Autor eher <em class="warning"> als <font color="red"> und definiert in einem Stylesheet, dass Warnungen rot dargestellt werden sollen. Wenn nun jemand keine Möglichkeit hat, Rot darzustellen (oder zu sehen), hat er zumindest eine Chance, sich auf eine andere Art und Weise warnen zu lassen (zum Beispiel durch ein entsprechendes Geräusch).

In XML-basierten Formaten, vor allem in wohlgeformten, sollte das Problem geringer als bei HTML ausfallen. Im Gegensatz zu einigen HTML-Versionen verfügen die meisten XML-Formate über keine Styling-Elemente. In solchen Formaten sieht man vielleicht Elemente wie <warning>, nicht jedoch <font>, daher ist ein Stylesheet obligatorisch.

Manchmal kann eine gesamte Technologie als Einrichtung zum Zweck der Zugänglichkeit betrachtet werden. SVG hat viele Vorteile gegenüber Rastergrafiken, aber ein besonders wichtiger Punkt ist, dass die Grafik auseinander genommen und als eine Hierarchie von Objekten durchlaufen werden kann, eher als eine Zusammenstellung von farbigen Pixeln. Man kann eine SVG-Grafik lesen, und zwar umso besser, je mehr Beschreibungen zu jedem Objekt der Autor eingefügt hat.

Macht es nicht mehr Arbeit, zugängliche Ressourcen zu erstellen? Werden Menschen nicht faul sein und sich Struktur und Kommentare sparen? Nicht immer. Einige wollen gute Arbeit abliefern. Einige werden dazu verpflichtet (gesetzlich oder durch das öffentliche Image ihres Arbeitgebers). Aber ein weiterer Grund ist, dass korrekt strukturierter und kommentierter Code einfacher zu warten ist; Zugänglichkeit ist manchmal eine Investition mit anfänglich großen Kosten, aber letzten Endes profitiert man davon. In wohldurchdachten Formaten stellen die Funktionalitäten der Zugänglichkeit keine nachträglichen Ergänzungen dar, sondern sind Teil der Funktionen für
die Wartbarkeit und der Struktur des Quelltextes. Eine SVG-Grafik kann analysiert und deren Bestandteile dazu wiederverwendet werden, um eine neue Grafik zu erzeugen. Bei einer PNG-Grafik hingegen ist das Ende der Fahnenstange erreicht.

Die Attribute alt und longdesc des HTML-Elements img waren eine nachträgliche Ergänzung. Deswegen hat man das Gefühl, es bedeutet zusätzliche Arbeit, an ein alt-Attribut (= alternatives Attribut) zu denken. Und wenn man sich ein gutes Attribut überlegt hat, ist es aufgrund der Beschränkungen von HTML-Attributen vielleicht nicht möglich, es umzusetzen: keine Möglichkeit, ein Wort innerhalb des alternativen Attributes zu betonen, keine Möglichkeit, eine Liste oder Tabelle anzugeben und so weiter.

Das img-Element wurde in HTML eingeführt, ohne über Zugänglichkeit (oder, wenn wir schon dabei sind, über Dinge wie zum Beispiel Ausweichlösungen und Bildüberschriften) nachzudenken, und die Alternativen, die vorgeschlagen wurden, fig und object, kamen einfach zu spät und haben sich niemals wirklich durchgesetzt. Funktionalitäten der Zugänglichkeit müssen von Beginn an integriert werden, sowohl in den Spezifikationen als auch in den Werkzeugen, die sie implementieren.

Siehe auch

[ATAG1.0]

Treviranus, Jutta; McCathieNevile, Charles; Jacobs, Ian; Richards, Jan. Authoring tool accessibility guidelines 1.0. 3. Feb 2000. W3C Recommendation. URL: http://www.w3.org/TR/2000/REC-ATAG10-20000203/

[UAAG1.0]

Gunderson, Jon; Jacobs, Ian. User agent accessibility guidelines 1.0. 10 Mar 2000. W3C Proposed Recommendation (draft). URL: http://www.w3.org/TR/2000/PR-UAAG10-20000310/

[WCAG1.0]

Chisholm, Wendy; Vanderheiden, Gregg; Jacobs, Ian. Web content accessibility guidelines 1.0. 5 May 2000. W3C Recommendation. URL: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/

[XMLGL]

Dardailler, Daniel. XML accessibility guidelines. 17 Feb 2000. W3C Note (draft). URL: http://www.w3.org/2000/02/NOTE-xmlgl-20000217.html

Minimale Redundanz

Dieser Abschnitt heißt »minimale Redundanz«, nicht »keine Redundanz«, denn – wie bereits in der Einleitung gesagt – unsere Technologien werden von Menschen verwendet, und Menschen können mit Redundanz umgehen. Sie haben vielmehr Probleme, wenn es keine gibt. Zu viel Redundanz ist jedoch schlecht für Computer (oder Programmierer), denn das bedeutet, dass die gleichen Dinge mehrere Male implementiert werden müssen. Aber es ist zum Beispiel gut, dass HTML verschiedene Möglichkeiten bietet, einen Absatz rot zu färben. Menschen haben unterschiedliche Stile und Denkweisen. Verschiedene Arbeitsweisen können zum gleichen Ergebnis führen, für den Autoren oder Leser allerdings eine andere Bedeutung haben, was oftmals hilfreich ist.

h1 { color: red; }
h2 { color: red; font-style: italic; }

h1, h2 { color: red; }
h2 { font-style: italic; }

Andererseits definiert XML 1.0 eine Baumstruktur mit vier Knotenarten (Zeichenketten, Verarbeitungsanweisungen, leere Elemente und Entities). Vor allem weil es sich um abstrakte Konzepte handelt, ist nicht klar, warum es vier Knotenarten sein müssen. Warum nicht zehn? Oder nur eine?

Was also ist zu wenig und was zu viel? Das ist schwer zu sagen. Die Überschneidung von Funktionalitäten zwischen verschiedenen Spezifikationen kann leicht zu inkompatiblen Modellen führen, deren Implementierung schwierig ist, was wiederum zu Fehlern führt. Daher sollten Überschneidungen möglichst gering gehalten werden. Aus diesem Grund unterstützt SVG keinen Weg, Rastergrafiken zu kodieren, weil es dafür PNG gibt. Andererseits kann es innerhalb einer Spezifikation durchaus mehrere Möglichkeiten geben, zu einem Ergebnis zu gelangen, denn innerhalb einer Spezifikation ist es leichter, Konsistenz beizubehalten.

Betrachten wir noch einmal das Beispiel der Rotfärbung eines Absatzes: CSS bietet mehrere Arten von Regeln und unterschiedlichen Ausdrücken, die alle »rot« bedeuten. Das erhöht den Implementierungsaufwand ein wenig, aber verbessert die Benutzbarkeit von CSS wesentlich. Andererseits ist das HTML-Attribut, das einen Text rot färbt, offiziell missbilligt (deprecated), denn es verwendet ein gegenüber CSS unterschiedliches Modell (keine Kaskade) und eine etwas abweichende Syntax (red und #FF0000 sind erlaubt, #F00 hingegen nicht).

Aber Vorsicht! Der Aspekt der Zugänglichkeit erfordert oftmals, dass die gleiche Information auf unterschiedliche Arten bereitgestellt wird, zum Beispiel sowohl als Grafik als auch als Text. Beide Formate transportieren gewissermaßen die »gleiche« Information, allerdings auf zwei unterschiedlichen Ebenen. Heutige Webformate können nur die Interpretation einer Information transportieren (zum Beispiel als Sprache, Bild oder Schrift), nicht die Information selbst. Das ist der Grund dafür, dass Computer eine Darstellung nicht selbstständig in einer andere umformen können. Vielleicht wird es eines Tages möglich sein, Dinge so zu beschrieben, dass Computer daraus beliebig Text, Sprache, Bilder oder sogar andere Formen generieren können. Daran arbeiten wir.

Geräteunabhängigkeit

Wenn eine Spezifikation nicht von einem Gerät (oder einer speziellen Art von Gerät) abhängen muss, dann sollte eine solche Abhängigkeit auch vermieden werden. Oder die Spezifikation sollte in einen geräteabhängigen und einen geräteunabhängigen Part aufgeteilt werden. Geräteunabhängigkeit ist in vielen Fällen das gleiche wie Zugänglichkeit, wenngleich für andere Zwecke.

Eine Spezifikation wie CSS ist zum Teil geräteabhängig: Die Spezifizierung einer Schrift ist nur in einem visuellen Medium sinnvoll; es gibt keine Interpretation einer Schrift in einer Sprachausgabe. CSS unterteilt alle Geräte in Klassen und erlaubt eine Gruppierung von Style-Angaben für jede Klasse. Dies ist ein Unterschied gegenüber HTML. Gerade weil CSS (und XSL) den geräteabhängigen Part übernehmen, kann HTML geräteunabhängig sein. Das macht es möglich, HTML für Dinge über die Anzeige auf dem Monitor hinaus einzusetzen (siehe auch Wiederverwendung).

Manchmal wird behauptet, HTML sei nicht geräteunabhängig, denn ein HTML-Autor geht davon aus, dass seine Leser ein geeignetes Medium verwenden, um Text zu lesen, zum Beispiel ein Buch, ein Magazin, einen Laserdrucker oder einen einigermaßen großen Bildschirm. Einen 5-seitigen Artikel auf dem Bildschirm der meisten Mobiltelefone zu lesen, ist nicht wirklich angenehm. Aber ist das ein Fehler von HTML oder ist es eher der Fall, dass gewisse Inhalte einfach für gewisse Umgebungen geeigneter sind? HTML ist für Wettervorhersagen genauso geeignet wie für Romane. Was HTML vielleicht vorgeworfen werden kann, sind die Mängel in den aktuellen CSS-Implementierungen.

Es ist nicht nur erstrebenswert, die gleiche Ressource auf verschiedenen Geräten gleichzeitig verwenden zu können, eine nützliche Ressource sollte ebenfalls so gestaltet werden, dass sie zukünftige technologische Änderungen übersteht. Wenn Technologien sich weiterhin so stark verändern wie zurzeit, kann es passieren, dass ein vier Jahre altes, damals auf einem aktuellen System erstelltes Dokument bald nicht mehr lesbar sein wird, weil die notwendige Hardware nicht mehr hergestellt werden oder ein bestimmter Softwarehersteller in Konkurs gegangen sein wird. Nicht alle HTML-Dokumente sind es wert, 50 Jahre lang aufbewahrt zu werden, aber HTML sollte es zumindest ermöglichen, dass Dokumente auch für zukünftige Generationen lesbar bleiben. Gutenbergs Bibel ist auch nach 500 Jahren noch lesbar, warum sollten Ihre Publikationen weniger wert sein? (Siehe auch Langlebigkeit.)

Siehe auch

[Rothenberg95]

Rothenberg, Jeff. „Ensuring the Longevity of Digital Documents“ in: Scientific American.
Vol. 272. pp. 42-47.
Jan 1995.

[TFADI96]

Preserving Digital Information. 1 May 1996. The Commission on Preservation and Access and The Research Libraries Group, Inc.. URL: http://www.rlg.org/ArchTF/tfadi.index.htm

Internationalisierung

Um wirklich »World Wide« zu sein, muss das Web benutzbar für Menschen sein, die nicht die Sprache der Entwickler sprechen. Im Allgemeinen ist es wenig sinnvoll, ein Format zum Informationsaustausch zu entwickeln, das nur für ein oder zwei Menschen benutzbar ist. Wenn eine Spezifikation an irgendeiner Stelle von Menschen lesbaren Text erlaubt, muss sie Text in jeder beliebigen Sprache erlauben. Der Text muss jedes Zeichen aus dem Unicode-Zeichensatz beinhalten dürfen, und es sollten am besten auch mehrere unterschiedliche Wege angeboten werden, sie zu kodieren, mindestens UTF-8. ASCII ist nicht verboten, kann aber nicht die einzige Kodierung bleiben.

Setzen Sie nicht voraus, dass Text immer horizontal von links nach rechts fließt und dass Wörter durch Leerzeichen getrennt werden. 7/1/92 bedeutet nicht überall 07. Januar 1992, und in vielen Sprachen, wird Pi durch 3,141 angenähert, während 3.141 eine um den Faktor 1000 größere Zahl darstellt.

Wenn Sie also eine Spezifikation für das W3C entwickeln, bedenken Sie, dass W3C-Spezifikationen zwar in Englisch verfasst sind, aber hauptsächlich von Menschen gelesen werden, deren Muttersprache nicht Englisch ist.

Erweiterbarkeit

Es wäre wirklich schön, wenn eine Technologie bereits beim ersten Entwurf ausgereift wäre. Es gäbe keine unterschiedlichen Versionen, keine Unterschiede zwischen Applikationen, kein Bedarf zum Upgrade. Aber in der Praxis wird immer eine zweite, oftmals auch eine dritte Version benötigt. Das sollte man am besten bereits beim Entwurf der ersten Version berücksichtigen.

Natürlich kann man nicht wissen, welche Erweiterungen es in der zweiten Version, und schon gar nicht, welche es in der dritten Version geben wird, aber es gibt dennoch einige Dinge, die man tun kann, um zukünftige Erweiterungen zu erleichtern, speziell dadurch, dass man bestimmte Syntaxausdrücke in der Hinterhand behält, denen man in Zukunft neue Funktionen zuweisen kann. Man kann eine Sprache dadurch zu einem gewissen Grad vorwärtskompatibel machen.

Ein einfacher Trick ist es, eine »magische Nummer« zu Beginn der Datei einzufügen, typischerweise eine Versionsnummer, sodass Applikationen, die für die erste Version geschrieben worden sind, erkennen können, wenn eine Datei nicht dieser Version entspricht. Das vermeidet zwar Missinterpretation von Daten, führt allerdings oftmals dazu, dass eine Applikation Daten, die zu neu sind, überhaupt nicht verarbeitet.

Einige Arten von Information sind zugänglich für reibungslosen Funktionsverlust. Applikationen der ersten Version beispielsweise können so entwickelt werden, dass sie sich einem gewünschten, erst in der zweiten Version implementierten Effekt im Rahmen ihrer Möglichkeiten annähern, während aktuellere Applikationen den vollständigen Effekt umsetzen.

HTML zum Beispiel verfügt über eine einfache Regel, die für Textdokumente einigermaßen gut funktioniert: Alle Texte in unbekannten Elementen werden so behandelt, als ob es einfacher Inline-Text wäre, unbekannte Attribute werden ignoriert. Entwickler neuer HTML-Versionen haben dadurch zwei Möglichkeiten, neue Entwicklungen zu integrieren. Abhängig davon, ob die beste Ausweichlösung für eine neue Funktion das Auslassen von Text oder das Darstellen als Inline-Text ist, können sie ein Element oder ein Attribut wählen. HTML hat ebenfalls eine magische Nummer am Anfang des Dokuments, und diese Methode wirkt gut genug, dass Browser nicht aufgeben müssen, wenn sie ein Dokument einer neueren Version anzeigen sollen.

CSS verfügt über eine etwas ausgereiftere Methode, denn es erlaubt Autoren in vielen Fällen, Alternativen für ältere Implementierungenen bereit zu stellen. Alte Programme lesen nur das, was sie verstehen, und übergehen den Rest, während aktuellere alles lesen, und wenn der Autor es richtig gemacht hat, überschreiben die neuen Funktionalitäten die veralteten.

#ifndef FEATURE
#error
#endif

<EXTENSION optional="no">
  <FEATURE.../>
</EXTENSION>

Eine noch besser durchdachte Methode ist, dem Autor eine Methode anzubieten, von Fall zu Fall angeben zu können, ob eine Annäherung akzeptabel ist oder nicht. Die Sprache C beispielsweise bietet ein Schlüsselwort #error, welches ein Programmierer dafür verwenden kann, dem Compiler zu signalisieren, dass eine bestimmte Funktion obligatorisch ist und dass ohne diese Funktion ein Fortführen nutzlos ist. SOAP (ein Satz von Konventionen für die Entwicklung von beschränkten XML-basierten Formaten, siehe [SOAP1.1]) bietet eine ähnliche Funktion, ebenso P3P [P3P1.0].

Siehe auch:

[P3P1.0]

Cranor, Lorrie; Langheinrich, Marc; Marchiori, Massimo; Presler-Marshall, Martin; Reagle, Joseph. The Platform for Privacy Preferences 1.0 (P3P1.0) Specification. 10 May 2000. W3C Working Draft. URL: http://www.w3.org/TR/2000/WD-P3P-20000510/

[SOAP1.1]

Box, Don, et al. Simple Object Access Protocol (SOAP) 1.1. 8 May 2000. W3C Submission. URL: http://www.w3.org/Submission/2000/05/

Erlernbarkeit

Hin und wieder hört man Menschen sagen, Syntax sei nicht wichtig. Das stimmt nicht: Syntax ist eine der wichtigsten Dinge. (Was sie womöglich wirklich meinen, ist dass ihre Syntax besser ist als zum Beispiel die von Ihnen…) Vielleicht beziehen sie sich auf die Tatsache, dass es mehrere Wege gibt, das gleiche Muster auszuführen. Das ist richtig, aber daraus folgt nicht, dass alle Wege äquivalent sind. Es ist eine philosophische Frage, ob die Sprache einer Person ihr mentales Modell der Welt ausdrückt, oder ob die Sprache lediglich die Oberflächenstruktur eines tiefer liegenden Modells beschreibt, das im Wesentlichen für jeden gleich ist. Über menschliche Sprachen lassen wir andere debattieren, aber für unsere formalen, beschränkten Sprachen sollten wie einen Ratschlag aus der Mathematik befolgen: es gibt nichts Besseres als eine sinnvolle Notation, um ein Modell zu verstehen.

Das Standard-Beispiel aus der Mathematik ist dt/dx, was so aussieht (und von Physikern auch so betrachtet wird) wie eine unendlich kleine Änderung von t geteilt durch eine unendlich kleine Änderung von x. Mathematiker können Ihnen genau erklären, in welchen Fällen sich dieser Ausdruck wie eine Division verhält und in welchen Fällen nicht, aber Tatsache ist, dass er sich für nahezu alle Formeln, die in der Physik vorkommen, wie eine Division verhält. Und es macht das Leben für Physiker leichter, dass sie (dx/dt)(dt/dy) zu dx/dy vereinfachen können. Es ist einfach, weil es genauso aussieht wie die Vereinfachung von (2/3)(3/7) zu 2/7. Mathematiker haben Differentialgleichungen nicht immer als dt/dx geschrieben, aber es hat schon seinen Grund, dass die anderen Notationen mittlerweise vergessen sind.

Erlernbarkeit hat folglich eine Menge mit Lesbarkeit zu tun.

Siehe auch

[Wittgenstein86]

Wittgenstein, Ludwig. Tractatus logico-philosophicus. Amsterdam.
Dec 1986. Athenaeum-Polak & Van Gennep. In German, with Dutch text on right-hand pages, translated by W.F. Hermans

Lesbarkeit

Eine Notation kann zu kurz sein. Wenn der Name einer selten verwendeten Funktion nur aus einem Buchstaben besteht (»t«), dann muss man sie womöglich die wenigen Male, die man sie sieht, nachschlagen, wenn man alle Buchstaben nicht auswendig komplett überblickt. Ein komplettes Wort (»translate«) ist da die bessere Lösung.

Eine Notation kann auch zu lang sein. Wenn ein Schlüsselwort, das man sehr oft verwendet, 20 Zeichen lang ist (»shapeoutlinedata«), dann sollte es womöglich besser abgekürzt werden (»d«). Diese Beispiele habe ich aus SVG (das die richtigen Bezeichnungen gewählt hat) entnommen, aber man kann ähnliche Fälle in den meisten Sprachen finden.

Bedauerlicherweise stellen sich die besten Vermutungen als falsch heraus. Die Designer von XML dachten, es wäre hilfreich, ein Element mit dem vollen Elementnamen zu öffnen und zu schließen (<heading>...</heading>), und für die Verwendung, die sie voraussahen, war das in der Tat vollkommen angemessen: in langen Texten mit wenig Markup ist die geringe Menge an Redundanz, die hinzukommt, gegenüber der Möglichkeit, zu sehen, welches Element geschlossen wird, zu vernachlässigen [XMLgoals]. Sie dachten, eine kürzere Form (etwa </> oder <>) zu erlauben, würde die Komplexität der Sprache erhöhen. Heute wird XML allerdings häufiger für Daten benutzt, deren Markup den eingeschlossene Inhalt übersteigt, und die vielen Start-Tags, die direkt End-Tags des gleichen Elementtyps folgen, verstecken die wesentliche Information durch ihre Redundanz. XML ist dadurch nicht kaputt, aber im Nachhinein betrachtet, hätte es so gestaltet werden können, dass dessen Verwendung nicht mit solchen Problemen verbunden ist.

Natürlich kann man immer eine andere Technik als XML verwenden. Und wenn die Lesbarkeit des Quelltextes wichtig ist, dann sollte man das vielleicht auch. Aber das bringt vielleicht Kosten mit sich: Man wird sich dann über einige Dinge Gedanken machen müssen, die XML von sich aus mit sich bringt (wie man Unicode-Zeichen umschreibt, wie man die Eindeutigkeit der Syntax sicherstellt, welche Begrenzer man für verschachtelte Strukturen verwendet, wie man Leerraum analysiert und vieles mehr).

Eine Möglichkeit, beides zu verwenden, sowohl XML als auch ein lesbares Format, ist die Verwendung eines Konverters. Für MathML beispielsweise gibt es mehrere Tools, die es erlauben, Mathematik in einer gewohnten Notation zu schreiben. Sobald es solche Tools gibt, ist die Lesbarkeit von Quelltexten weniger wichtig. Nicht allerdings unwichtig, siehe Langlebigkeit.

CSS hat seine eigene Syntax, denn Lesbarkeit ist sehr wichtig für eine Sprache, die bei nahezu genauso vielen Menschen verwendet wird wie HTML selbst. Es hätte auf SGML basieren können, und es gibt in der Tat einige Vorschläge für eine SGML-basierte Syntax (siehe [Lie99]), und es existiert auch noch der US-Militär-Standard ([FOSI], aber es wurde niemals bezweifelt, dass die heutige CSS-Syntax besser ist. (XML gab es zu dieser Zeit nicht, aber es hätte auch nicht weitergeholfen, weil es wortreicher als SGML ist und weniger Zeichen und Zeichensetzung erlaubt.)

Viele andere Sprachen wählen eine Mischung aus XML und einer anderen Syntax. XML selbst verwendet spitze Klammern als Begrenzer, alles andere muss mit Schlüsselwörtern erledigt werden. Menschen fühlen sich für gewöhnlich wohler, wenn andere Zeichen, zum Beispiel der Doppelpunkt (:), das Semikolon (;), geschweifte Klammern { } und runde Klammern ( ) ebenfalls eine Bedeutung haben. SMIL zum Beispiel drückt Zeit und Zeitintervalle mit einer Notation wie 3:25.5 und nicht <time><min>3</min><sec>25.5</sec></time> aus. Ebenso nutzt SVG eine kompakte Notation für Pfade, die wesentlich lesbarer ist als alles, was mit XML-Tags ausgedrückt werden könnte. Aber sowohl SMIL als auch SVG verwenden XML für die Teile, wo Wortfülle weniger das Problem ist, so wird die Arbeit des Entwicklers der Spezifikation leichter gemacht, ohne dass Probleme mit der Lesbarkeit auftreten.

Und es gibt Sprachen, bei denen Lesbarkeit im Vergleich zur Effizienz weniger wichtig ist. PNG ist ein Beispiel dafür. Es ist ein Binärformat.

Siehe auch

[FOSI]

. [Where is this thing?]

[Lie99]

Lie, Håkon Wium; Bos, Bert. Historical style sheet proposals. 1997-1999. W3C. URL: http://www.w3.org/Style/History

[XMLgoals]

Tim Bray; Jean Paoli; C. M. Sperberg-McQueen (eds). Extensible Markup Language (XML) 1.0. 10 Feb 1998. W3C Recommendation. Section 1.1 URL: http://www.w3.org/TR/REC-xml#sec-origin-goals

Effizienz

Laut Jakob Nielsen sind Menschen am produktivsten, wenn die Reaktionszeit des Rechners auf ihren Mausklick weniger als eine Sekunde beträgt. Menschen verlieren ihre Konzentration, wenn eine Webseite länger als zehn Sekunden braucht, um zu erscheinen.

Natürlich werden Computer immer mächtiger, und die Bandbreiten steigen kontinuierlich, zumindest im Durchschnitt. Aber zur gleichen Zeit werden neue Geräte an das Web angeschlossen, zum Beispiel Mobiltelefone und Fernseher, und diese sind wesentlich langsamer als Computer. Auch sie werden sich vielleicht verbessern, allerdings werden sie von der Leistung her immer hinter Desktop-Rechnern zurückbleiben. Aber dann wird es zweifellos wieder neue Geräte (und Applikationen) geben. Entwickler von Web-Technologien werden somit immer auf Effizienz achten müssen.

Geschwindigkeitseinbußen können beim Server auftreten, wenn die Generierung einer Antwort auf eine Frage zu komplex gerät; im Netzwerk, wenn der Datenfluss zu groß ist; beim Benutzer, wenn die Darstellung der Daten zu schwierig ist.

Beim Entwurf von formalen Sprachen, die Ressourcen speichern, sollten Entwickler sicherstellen, dass die Sprachen leicht zu parsen und einigermaßen kompakt sind. »Schrittweise Darstellung« (Progressive rendering, das heißt die Darstellung einer Antwort beginnt bereits dann, wenn noch nicht alle Daten angekommen sind) kann auch helfen. CSS beispielsweise wurde so gestaltet, dass jede Zeile eines Dokuments dargestellt wird, sobald sie übertragen worden ist (Außer für Text innerhalb von Tabellen, wofür etwas Mehrarbeit des Stylesheet-Autoren benötigt wird). Zwischenspeicher helfen ebenso, daher ist die Aufteilung eines Dokuments in zwischenspeicherbare und nicht zwischenspeicherbare Teile eine gute Sache. HTML und XLink zum Beispiel erlauben, dass Dokumente aus Teilen zusammengesetzt werden, wovon sich einige auf verschiedene Dokumente aufteilen können. Manchmal sind Einrichtungen zur Kompression oder Umwandlung in ein Binärformat notwendig.

Für gewöhnlich ist es eine gute Idee, in einer Sprache Methoden zur Entfernung von Redundanz bereitzustellen (auch wenn sie gegen ein Mehr an Komplexität der Sprache abgewogen werden müssen). Deswegen haben HTML und SVG einen Mechanismus, einem Element eine »Klasse« zuzuweisen und ein Styling für alle Elemente der gleichen Klassen an einer Stelle zu definieren. SVG erlaubt darüber hinaus die Wiederverwendung von Grafikobjekten an verschiedenen Stellen: Um einen Stern zu zeichnen, der aus 12 Punkten besteht, reicht ein einziger Punkt aus, der 12 Mal an unterschiedlichen Stellen dargestellt wird. CSS verfügt über mehrere Mechanismen, um Regeln zu gruppieren.

Wie auch immer, Intuition ist beim Abschätzen von Effizienz oftmals kein guter Ratgeber. Die Durchlaufleistung eines Netzwerkes zum Beispiel verläuft nicht linear: Eine Nachricht, die aus einem einzigen TCP-Paket besteht, ist wesentlich schneller als eine, die aus zwei Paketen besteht, aber vier Pakete brauchen für gewöhnlich weniger Zeit als zwei unterschiedliche Nachrichten aus zwei Paketen (siehe [Frystyk97]). Java wird oftmals als sehr langsam wahrgenommen, aber Jigsaw (ein in Java geschriebener HTTP-Server) kann normalerweise gegen Apache (ein HTTP-Server in C) bestehen, denn ein Großteil der wahrgenommenen Langsamkeit kommt durch das Starten der Java Virtuel Machine; wenn diese einmal läuft, ist Java ausreichend schnell (siehe [JigPerf]). Und vor einiger Zeit zeigte eine W3C-Studie, dass der größte Gewinn aus radikalen Veränderungen resultiert: Es half viel, GIF durch PNG und HTTP/1.0 durch HTTP/1.1 zu ersetzen, aber nicht annähernd so viel wie das Ersetzen eines Bildes durch Text in einem StyleSheet. Mit SVG werden die Möglichkeiten sich wesentlich erhöhen.

Siehe auch

[Frystyk97]

Frystyk Nielsen, Henrik; Gettys Jim; Baird-Smith, Anselm; Prud’hommeaux, Eric; Lie, Håkon Wium; Lilley Chris. Network performance effects of HTTP/1.1, CSS 1, and PNG. 24 Jun 1997. W3C Note. URL: http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html

[JigPerf]

Jigsaw performance evaluation. 27 May 1998. W3C. (Part of the Jigsaw documentation, updated with each version.)
URL: http://www.w3.org/Jigsaw/User/Introduction/performance.html

[Khare99]

Khare, Rohit; Jacobs, Ian. W3C Recommendations Reduce ‚World Wide Wait‘. 1999. W3C. A summary of [Frystyk97]
URL: http://www.w3.org/Protocols/NL-PerfNote.html

[Nielsen97]

Nielsen, Jakob. The need for speed. 1 Mar 1997. Alertbox column. URL: http://www.useit.com/alertbox/9703a.html

Binär- oder Textformat

Die meisten W3C-Spezifikationen definieren eine formale Sprache zur Beschreibung einer Art von Ressource: HTML beschreibt einfache Text-Dokumente, SVG beschreibt Vektorgrafiken, PNG beschreibt Rastergrafiken, HTTP beschreibt den Dialog zwischen einem Client und einem Server und URLs beschreiben den Pfad zu einer bestimmten Ressource. Es gibt Ausnahmen wie die verschiedenen WAI-Richtlinien, die Meta-Regeln beschreiben, wie Programme und Spezifikationen entworfen werden sollten (ein wenig wie dieser Essay, allerdings präziser…). Aber die meisten Menschen, die an W3C-Spezifikationen arbeiten, stehen am Anfang vor der Frage: Sollen wir ein Binär- oder ein Textformat entwerfen?

In den meisten Fällen wird die Antwort »Textformat« lauten, denn Textformate sind einfacher zu laden, und Fehler lassen sich leichter finden und beseitigen: man kann Dateien mit einem Texteditor erzeugen, sodass der Entwurf eines geeigneten Editors oder Konverters auf einen späteren Zeitpunkt verschoben werden kann; man kann eine Datei überprüfen, um zu sehen, was passiert ist, wenn ein Programm nicht das macht, was man erwartet hat; und nicht zuletzt: wenn die Spezifikation in etwa 50 Jahren versehentlich verloren gegangen ist, gibt es eine Chance, allein durch das Analysieren einiger Dateien ausreichend viel von der Spezifikation zu rekonstruieren, um die essentiellen Informationen zurückzugewinnen. (Das wird manchmal, wohl eher optimistisch, »selbstbeschreibend« genannt. Das Format würde nur dann wirklich selbstbeschreibend sein, wenn jede Datei den Text der Spezifikation mit einbände…)

Textformate erlauben oftmals, unvorhergesehene Erweiterungen vorzunehmen, denn sie haben typischerweise ziemlich hohe Redundanz. Viele Programmiersprachen haben daher Konventionen erlangt, um Dinge in strukturierte Kommentare zu packen oder haben in späteren Versionen neue Schlagwörter erhalten. Ebenso haben Binärformate normalerweise einige eingebaute Erweiterungsmechanismen, aber sie sind beschränkter (zum Beispiel die Extension Chunks bei GIF und PNG).

Aber vielleicht entscheidet man sich für Textformate, einfach weil das IETF sie befürwortet, oder weil jemand aus dem Management HTML verlangt…

Eigentlich sind Binärformate nicht böse. Sie sind oftmals wesentlich effizienter zu verarbeiten und zu transportieren. Sie sind für gewöhnlich kleiner: Das Ziel von ZIP, MPEG und JPEG – um nur ein paar zu nennen – ist, so wenig Bits zu umfassen wie möglich. Sie sind normalerweise schneller zu verarbeiten, weil sie einfachere Parser erfordern.

Parser für eine wohlgestaltete, textbasierte Sprache müssen nicht uneffizient sein, wenngleich Konverter von Text- zu Binärformat sie typischerweise um einen bestimmten Faktor langsamer machen. Ein wichtigerer Punkt ist, dass ihre größere Komplexität oftmals zu weiteren Fehlern führt.

Und ist der Mangel an Erweiterung von Binärformaten so schlecht? Möglicherweise nicht. Selbst wenn ein Textformat theoretisch erweiterbar ist, muss das in der Praxis nicht der Fall sein. Wenn die Erweiterung nicht auf eine sinnvolle Art und Weise rückwärtskompatibel ist, ist es besser, ein komplett neues Format zu entwickeln. HTML wurde durch drei Versionen erweitert: 2.0, 3.2 und 4.0, aber es kann nicht weiterentwickelt werden, ohne dass es zu ernsthaften Problemen für Implementierer führt. XHTML ist der Nachfolger von HTML, aber es ist ein neues Format, keine Erweiterung.

Zusammenfassend gesagt: Die meisten W3C-Formate sind Textformate, und das wird wahrscheinlich so bleiben, aber gehen Sie nicht davon aus, dass Binärformate verboten wären. Beide Formate bringen Nachteile mit sich, die gegeneinander abgewogen werden müssen.

Implementierbarkeit

Je einfacher eine Spezifikation zu implementieren ist, desto mehr Implementierungen wird es geben und desto mehr Kompatibilität wird es geben. Mit einfacher Implementierung ist ebenfalls gemeint, dass Implementierer Zeit haben, kreativ zu sein und neuartige Wege zu entwickeln, eine Technologie zu verwenden. Implementierungen werden günstiger sein; sie werden vielleicht sogar fast kostenlos sein, wenn sie von Einzelpersonen in ihrer Freizeit vorgenommen werden können. Fehler zu beheben, gehört zu den kostspieligsten Vorgängen, die Entwicklern bekannt sind, vor allem wenn es Menschen gibt, die sich unwissentlich auf die Fehler verlassen. Fehler zu verhindern, ist daher von höchster Wichtigkeit. Implementierbarkeit kann von Einfachheit kommen oder daher, dass man auf bekannten, bereits bestehenden Komponenten aufbaut.

Auf bereits bestehenden Komponenten aufzubauen, bedeutet, Technologien zu verwenden, mit denen Programmierer vertraut sind, wie zum Beispiel kontextfreie Grammatiken (in der EBNF oder Varianten ausgedrückt) oder XML 1.0.

Es bedeutet nicht, Abhängigkeiten zu neuen oder nicht ganz verstandenen Technologien zu schaffen. XSLT zum Beispiel hätte XML Namespaces womöglich nicht verwenden sollen. Es hätte statt dessen auf konventionellere Art zwischen Kommandos und Daten unterscheiden können. XSLT ist nun gefährdet, die gleiche Entwicklung in Richtung inkompatibler und nur teilweiser Implementierungen durchzumachen wie HTML, welches auf SGML basiert, einer anderen Technologie, die von Entwicklern nicht verstanden wurde.

Wie Jakob Nielsen sagt, ist es sehr unsicher, eine Spezifikation zu verwenden, solange sie noch nicht mindestens ein Jahr lang offiziell ist ([Nielsen00], Seite 34).

W3C-Spezifikationen sind bisher nicht sehr komplex, zumindest nicht im Vergleich zu denen anderer Organisationen, aber sie werden immer komplizierter. Das W3C muss sich vielleicht wieder am IETF orientieren, wenn es darum geht, Spezifikationen möglichst einfach zu halten. Denn eine der Beschwerden, die wir mittlerweise am häufigsten hören, ist die, dass es schwierig werde, mit der Anzahl an gegenseitigen Abhängigkeiten umzugehen, vor allem bezüglich Spezifikationen der XML-Familie und vor allem für Entwickler, die ihr erstes XML-basiertes Programm erstellen (und wenn wir wollen, dass das Web sich entwickelt, werden wir viele Anfänger benötigen).

In der Tat ist XML 1.0 selbst bereits zu kompliziert für einige der Applikationen, für die es entworfen wurde, wie an einem Projekt zu sehen, das gestartet worden ist, um eine vereinfachte Version zu definieren (siehe [Park00]).

Die Existenz von zwei Implementierungen einer Spezifikation ist keine Garantie dafür, dass es noch weitere geben wird, aber es ist ein Hinweis darauf. Es ist daher eine gute Idee, dass viele XML-Arbeitsgruppen zwei oder mehr Implementierungen abwarten, bevor sie ihre Arbeit als »Empfehlungsvorschlag« (Proposed Recommendation) vorlegen.

Siehe auch

[Nielsen00]

Nielsen, Jakob. Designing Web usability. Indianapolis, IN.
Dec 1999. New Riders.

[Park00]

Park, Don (ed). Minimal XML 1.0. 11 Apr 2000. Draft developed on the SML-DEV [SMLDEV] mailing list.
URL: http://www.docuverse.com/smldev/minxmlspec.html

[SMLDEV]

sml-dev mailing list. 29 Nov 1999. Simple Markup Languages Developer group mailing-list.
URL: http://www.egroups.com/group/sml-dev/

Einfachheit

Die Abbildung basiert auf einer Grafik von Donald Norman und zeigt sieben Schritte, die eine Person durchführen muss, um eine Handlung zu vollenden. Wenn wir ganz oben bei den Zielen (Goals) einer Person starten, dann formt sie eine Menge an Vorsätzen, um gewisse Dinge in der Welt zu verändern. Sie übersetzt ihre Vorsätze in eine Handlungssequenz und führt diese aus. Danach nimmt sie die Welt in einem anderen Zustand wahr, interpretiert, was sie sieht, und vergleicht erneut mit dem, was sie sich zu ändern vorgenommen hat. Sie kann den Kreis erneut durchlaufen, wenn sie ihre Ziele nicht erreicht hat.

Wenn irgendwelche Werkzeuge einbezogen sind, wie es im Web der Fall ist, dann müssen die Vorsätze in Aktionen übersetzt werden, welche die Werkzeuge ausführen können. Wenn die Art, wie eine Person über ein Problem denkt, sich von der Art, wie es der Entwickler eines Werkzeugs tut, unterscheidet, dann kann diese Übersetzung schwierig sein: Das lässt sich mit dem Versuch vergleichen, von einem Feld eines Schachbretts zu einem angrenzenden zu springen, wenn Sie nur mit dem Springer ziehen können. Norman nennt diesen Schritt Kluft der Ausführung (gulf of execution).

Die Werkzeuge in unserem Fall sind Software und formale Sprachen. Gute Programme können schlechte Sprachen einigermaßen kaschieren, aber wenn das Sprachmodell schwer zu verstehen oder komplex ist, sind solche Programme schwierig zu entwerfen. Und manchmal wissen die Leute nicht, welches Werkzeug das richtige ist.

Nehmen Sie ein Beispiel: Grafikdesigner möchten visuelle Effekte auf Webseiten erstellen, die (in ihrer Vorstellung) aus teilweise überlappenden Grafiken bestehen. Bevor es CSS 2 gab, waren HTML-Tabellen das einzige Werkzeug, das ihnen zur Verfügung stand, um Elemente visuell anzuordnen. Aber Tabellenzellen überlappen sich nicht. Wie auch immer, einige kluge Software-Entwickler konnten eine Schnittstelle präsentieren, womit Designer Grafiken wie gewünscht positionieren konnten, und im Hintergrund schnitt das Programm die Grafiken in winzige Stücke. Die Stücke, die nicht überlappten, belegten jeweils eine Zelle einer riesigen Tabelle. Das funktionierte, zumindest meistens, aber wenn jemand anderes, der nicht das Werkzeug des Autoren besaß, herauszufinden versuchte, was da vor sich ging, oder gar versuchte, die Darstellung zu ändern, war er dazu nicht in der Lage, weil er den Quelltext nicht verstand. Was uns zu einer anderen Kluft führt.

Die Kluft der Auswertung (gulf of evaluation) auf der rechten Seite des Diagramms steht für die Schwierigkeiten, die ein Nutzer hat, wenn er Darstellung und Meldungen eines Systems auf sein eigenes geistiges Modell abbilden möchte. Das Problem dabei kann sein, dass das System unvollständige oder mehrdeutige Informationen präsentiert (»Syntaxfehler in Datei«) oder es verwendet Metaphern, die nicht denen des Nutzers entsprechen (»grün steht für Fehler«). In dem oberen Beispiel sind Tabellen eine falsche Metapher für überlappende Grafiken.

Siehe auch:

[Norman86]

Norman, Donald A; Draper, Stephen W.. User centered system design: new perspectives on human-computer interaction. Hillsdale, NJ.
1986. Lawrence Erlbaum Associates.

[Norman88]

Norman, Donald A. The psychology of everyday things. New York.
1988. Basic Books.

Langlebigkeit

Webdokumente werden im Grunde für die Ewigkeit geschrieben. Wenn etwas wertvoll genug ist, niedergeschrieben zu werden, dann ist es auch wertvoll genug, bewahrt zu werden. Man weiß nie, wann etwas nicht mehr von Nutzen ist oder was alles davon abhängig ist. Als Konsequenz daraus sollte man URLs niemals »sterben« lassen. Das ist mittlerweile allgemein bekannt.

Sie sollten darüber hinaus Inhalte so verfassen, dass sie technologische Änderungen mit hoher Wahrscheinlichkeit überleben, denn es kann irgendwann sehr teuer werden, veraltete Dokumente in ein anderes Format zu konvertieren. Wie erreicht man das? Sofern man nicht die Zukunft voraussagen kann, ist die beste Faustregel, die Standards einzuhalten, unter anderem die W3C-Spezifikationen und -Richtlinien.

Allerdings ist es trotz Tims Bitten (siehe [TBL98]) sehr unwahrscheinlich, dass viele aktuelle URLs noch in 50 Jahren existieren werden, aber die Dokumente, die heute auf diese Ressourcen verweisen, werden wahrscheinlich noch existieren, und wenn sie in HTML geschrieben worden sind, werden sie auch weiterhin lesbar sein.

Das bringt eine Verantwortung für die Entwickler von Spezifikationen mit sich. Sie müssen sich immer fragen, ob die Spezifikation fördert, oder zumindest erlaubt, dass Webressourcen so erstellt werden, dass sie noch in 50 Jahren zu entziffern sind. Weil Entwickler die Zukunft genauso wenig voraussehen können wie jeder andere auch, folgen sie folgenden Faustregeln:

• Füge keine Funktionen ein, von denen du jetzt schon weißt, dass sie in der nächsten Version missbillig (deprecated) sein werden.
• Verwende einfache Formate, die decodiert werden können, wenn die Spezifikation verloren geht. Verwende vielleicht ein Textformat.
• Sei geräteunabhängig, wann immer es möglich ist, oder setze geräteabhängige Teile in separate Module.
• Et ceterea, siehe das Inhaltsverzeichnis dieses Essays.

Und was ist nun mit toten URLs? Der traditionelle Weg, Information davor zu schützen, in Vergessenheit zu geraten, ist, redundante Metadaten innerhalb einer Ressource anzubieten: Eine Bibliothek kann ein verloren gegangenes Buch durch die Information auf der Titelseite wiederfinden. Im Web können wir das zurzeit ein wenig besser machen, weil wir Metadaten (zum Teil) maschinenlesbar gestalten können. Daher ist es eine gute Idee, in jedes Datenformat Standardfelder für Informationen einzufügen, die helfen, die Ressource zu identifizieren: meta und link in HTML, eingebettetes RDF in SVG, @author/@version in Java und so weiter.

Siehe auch

[Kahle97]

Kahle, Brewster. Preserving the Internet in: Scientific American.
Mar 1997. URL: http://www.sciam.com/0397issue/0397kahle.html

[Nielsen98]

Nielsen, Jakob. Fighting linkrot. 14 Jun 1998. Alertbox column. URL: http://www.useit.com/alertbox/980614.html

[TBL98]

Berners-Lee, Tim. Cool URIs don’t change. 1998. W3C. URL: http://www.w3.org/Provider/Style/URI

Rückwärtskompatibilität

Es gibt zwei Arten von Rückwärtskompatibilität: die einer aktuellen Version einer Spezifikation zu einer vorangehenden Version und die einer neuen Technologie zu einer älteren Technologie, welche sie ersetzt.

Niemand vergisst die vorherige Version, denn es gibt nichts, was Entwickler einer neuen Spezifikation so gut kennen, wie die vorherige Version, die sie zu ersetzen gedenken. Rückwärtskompatiblität wird dabei immer heiß diskutiert.

Letzteres ist allerdings weniger offensichtlich. Es ist in gewisser Hinsicht das Gegenteil zu Erweiterbarkeit und Modularität. Während diese beiden Aspekte hervorheben, dass eine Technologie auf eine Art und Weise entwickelt werden sollte, dass sie auch in Zukunft mit neuen Technologien zusammenarbeiten wird, betont Rückwärtskompatibiltät, dass es wichtig ist, gut mit dem zusammenzuarbeiten, was aktuell da ist. Keine neue Technologie wird ins Nichts hinein entworfen.

Eine neue Technologie hat normalerweise nicht nur in Bezug auf technische Gesichtspunkte mit einer früheren Version kompatibel zu sein, sondern auch mit den Wörtern und Metaphern, die Nutzer gebrauchen, um die alte Technologie zu beschreiben. Neue Paradigmen einzuführen, bringt immer Probleme mit sich, die gegen zukünftige Vorteile aufgewogen werden müssen.

Nehmen Sie CSS als Beispiel: Leute, die HTML verwenden, und gewiss auch die meisten Leute, die Textverarbeitungsprogramme benutzen, sind gewohnt, Style-Informationen direkt den betreffenden Elementen hinzuzufügen. Um zu gewährleisten, dass Stylesheets sofort akzeptiert werden, muss CSS Leuten erlauben, ihre Arbeit in genau dieser Weise fortzuführen und zusätzlich ihre Möglichkeiten zu erweitern.

Als gegenteiliges Beispiel ist XSL zu nennen. Diese Sprache basiert auf einem anderen Ansatz als Stylesprachen: die Leute erstellen zunächst das Styling in Form eines Templates, danach werden darin die Elemente eingefügt. Diese Vorgehensweise erfordert mehr Motivation vom Nutzer, aber dafür eröffnet sie neue Möglichkeiten. Das Zielpublikum sind Benutzer, die die neue Funktionalität brauchen und die Möglichkeit haben, das neue Paradigma zu lernen. Sie müssen sich dafür aneignen, wie man Rekursion und Iteration anwendet und wie man ein Dokument beschreibt, das erst in Zukunft existieren wird, wie zum Beispiel einen Report, der aus einer Datenbank generiert wird.

Manchmal ersetzt eine neue Technologie eine vorherige, allerdings ist es selten, dass die alte vollständig von der Bildfläche verschwindet. PNG ist prinzipiell in der Lage, GIF komplett zu ersetzen, und XHTML kann HTML vollständig ersetzen. Aber selbst in solchen Fällen ist eine Form der Rückwärtskompatibilität in Form von Technologien zur automatischen Konvertierung von Ressourcen in das neue Format notwendig.

»Automatisch« bedeutet hierbei, dass die erforderliche Menge an Intelligenz notwendigerweise begrenzt sein sollte. SVG ersetzt PNG teilweise, nämlich dann, wenn PNG dazu verwendet wird, Diagramme oder Graphen darzustellen. Das lässt sich in SVG besser lösen, aber es gibt keine Rückwärtskompatibilität von SVG zu PNG. In diesem Fall ist der Nutzen von SVG für Bilder dieser Art natürlich so groß, dass sich niemand über den Mangel an Kompatibilität beschwert (aber selbst wenn, SVG unterstützt eine einfache Konvertierungs-Methode: die PNG-Grafik lässt sich in einem SVG-Objekt ohne jegliche Interpretation verpacken).

Das Web als solches ist rückwärtskompatibel entworfen. Die URLs, die den Ort einer Ressource angeben, erlauben den Zugriff über FTP und andere Protokolle, nicht nur über HTTP, und HTTP wiederum ist für beliebige Datei-Typen vorgesehen, nicht nur HTML. Und als letztes Beispiel: HTML erlaubt, jeden beliebigen Dateityp zu verlinken (über das Element a) oder einzubinden (durch die Elemente img oder object), nicht nur HTML-Dokumente und PNG-Grafiken.

Interoperabilität

Dieses neumodische Wort ist eine Variante eines anderen, wesentlich bekannteren neumodischen Wortes, Kompatibilität, und es bedeutet einfach, dass etwas (ein Dokument, ein Programm) in Übereinstimmung mit unseren Spezifikationen geschrieben wurde und in verschiedenen Applikationen und Computern identisch ablaufen sollte. »Identisch« meint dabei folgendes: Man kann ein Dokument nicht im Bildschirm eines Handhelds und in einem 19 Zoll Farbbildschirm exakt gleich darstellen, aber man kann mit beiden Geräten die gleichen Erfahrungen und Informationen aus dem Dokument ziehen.

Der Sachverhalt wird wesentlich klarer, wenn Sie typische Browser miteinander vergleichen: Sicher, jeder Browser bietet unterschiedliche Funktionen, aus diesem Grund bevorzugen die Leute den einen oder anderen Browser, aber sie erwarten sicher nicht, dass eine Seite in dem einen Browser blau und in dem anderen Browser rot aussieht oder (was manchmal passiert) lesbar in einem einen, nicht aber in dem anderen Browser ist.

Die Entwickler einer Spezifikation haben folglich sicherzustellen, dass das, was sie spezifizieren, von allen unterschiedlichen Implementierern auch implementiert werden kann: es sollte nicht von einer bestimmten Plattform abhängig sein, es sollte nicht mehrdeutig sein, und es sollte überprüfbar sein.

Wenn es innerhalb einer Spezifikation Teile gibt, die interoperabel sind und andere nicht (oder in nur in einer beschränkten Weise), kann es oftmals sinnvoll sein, die Spezifikation in zwei separate Teile aufzusplitten, jeder Teil mit seinen eigenen Interoperabilitäts-Bedingungen.

Wir erwarten zum Beispiel nicht, dass jedes Programm, das statische Textdokumente darstellen kann (HTML), auch dynamische Präsentationen (SMIL) darstellen kann oder umgekehrt, daher sind HTML und SMIL zwei unabhängige Module.

Wiederverwendung von Inhalten

Der große Kreis in dem Diagramm repräsentiert menschliche Kommunikation mit dem Web als Zwischenmedium: jemand hat eine Idee (oben); er repräsentiert sie in einer maschinenlesbaren Art und Weise und stellt sie ins Web (in dem roten Bereich); das Web transportiert sie und stellt sie dar; jemand schaut sich die Idee an, interpretiert, was er sieht (unten), und kann wiederum Ausgangspunkt neuer Ideen sein.

Es gibt verschiedene kleinere Kreise in dem Diagramm, von denen jeder eine Änderung der Information darstellt, hoffentlich Erweiterungen, möglicherweise aber Beschneidungen. Der oberste Kreis, Reflexion, ist ein Prozess unter Kontrolle des Autors; der untere Kreis, unterschiedliche Sichten, wird durch den Leser kontrolliert; aber die Kreise dazwischen können Aktionen von beiden, von anderen Leuten oder automatische Aktionen von Programmen wie zum Beispiel Web-Spidern sein.

Es sind diese kleinen Kreise, die den Mehrwert darstellen, den das Web menschlicher Kommunikation bieten kann. Aber damit sie gut arbeiten können, muss die ursprüngliche Repräsentation für Änderungen durch Software geeignet sein.

Die gemeinsame Bezeichnung für die Manipulationen, die in diesen kleinen Kreisen vorgenommen werden, ist Wiederverwendung, zum Beispiel die Anpassung eines Datenteils für einen neuen Verwendungszweck.

Aktualität

Damit eine neue Technologie erfolgreich ist, muss sie zur richtigen Zeit kommen. Wenn mit der Entwicklung eines neuen Moduls zu lange gewartet wird, werden in der Zwischenzeit zumeist Schnellschuss-Lösungen angewandt, welche zu Problemen mit der Rückwärtskompatibilität führen und denjenigen Schwierigkeiten bereiten, die diese Dinge in neue Standards konvertieren müssen, wenn sie nun schon mal da sind. Wenn etwas zu früh entwickelt worden ist, kann es passieren, dass es dann vergessen sein wird, wenn es gebraucht wird, oder schlimmer, dass es nicht benutzt werden kann, weil die Entwicklungen in der Zwischenzeit in eine andere Richtung gegangen sind, als erwartet worden ist.

Aber wann ist der richtige Zeitpunkt? Schwer zu sagen. Wenn die Leute nach etwas verlangen (auch wenn es fast eine Kunst ist, zu erkennen, wonach genau sie verlangen), dann ist das ein Anzeichen dafür, dass der richtige Zeitpunkt gekommen ist. Ein weiteres Zeichen ist, wenn es Leute mit Ideen gibt, deren Lösungen selbstverständlich erscheinen.

Verwende, was bereits da ist

Wenn man auf die ersten zehn Jahre des Webs zurückblickt, sieht es zweifellos so aus, als hätte es eine Revolution gegeben. Das Web läuft nun mit HTML, HTTP und URLs, nicht mit dem, was es vor den 1990ern gegeben hat. Es liegt allerdings nicht nur an der Qualität dieser Formate und Protokolle, dass das Web abgehoben hat. In der Tat war das ursprüngliche HTTP bezogen auf seine Fähigkeiten ein schlechteres Protokoll als zum Beispiel Gopher oder FTP, und HTML war damals nicht das, was es jetzt ist: es verfügte nicht über eingebettete Bilder, Tabellen, Farben…

In den frühen Tagen luden viele Leute ihre Homepages eher auf FTP-Server als auf HTTP-Server. Und diese Tatsache zeigt deutlich, was das Web überhaupt möglich gemacht hat: es hat nicht versucht, Dinge, die bereits funktionierten, zu ersetzen, es hat lediglich neue Module hinzugefügt, die in die bestehende Infrastruktur passten. HTML kann von FTP– oder Gopher-Servern ausgeliefert werden; Browser können reinen Text oder FTP-Verzeichnislistings darstellen; URLs sind für jede Art von Protokoll geeignet und so weiter.

Und zurzeit (im Jahre 2000) mag es so aussehen, als ob alles auf XML und HTTP basiert, aber dieser Eindruck besteht nur deshalb, weil die »alten« Techniken so gut integriert sind, dass man sie vergisst: es gibt keinen Ersatz für E-Mail oder das Usenet, für JPEG oder MPEG und viele andere wichtige Bestandteile des Web.

Im Laufe der Zeit kann eine Technologie natürlich durch eine bessere ersetzt werden. GIF wird langsam durch PNG ersetzt, SMIL ersetzt diverse andere Formate, das gleiche gilt für SVG. Das Web ist eine konstante Entwicklung. Es gibt keinen »Tag 0«, an dem alles ganz von vorne beginnt. Zu jeder Zeit gibt es alte und neue Technologien, die zusammenarbeiten.

So soll es sein! Technologien verbessern sich unterschiedlich schnell. Zu versuchen, drei oder vier neue Spezifikationen gleichzeitig zu veröffentlichen, füllt unsere Kapazitäten bereits aus. Und Software wegzuwerfen, die funktioniert, wenn auch nicht perfekt, und jedem etwas Neues beizubringen, wäre eine große Verschwendung von Ressourcen.

Leider gibt es in jeder Organisation, die Standards entwickelt (das W3C nicht ausgeschlossen), die Tendenz, alles, was andere Organisationen entwickelt haben, durch eigene Dinge zu ersetzen. Das ist das »nicht-hier-erfunden-Syndrom«, ein Gefühl, dass Dinge, die nicht für das »Web« entwickelt worden sind, irgendwie minderwertig seien. Und dass »wir« es besser machen können als »die«. Aber auch wenn das wahr sein sollte, kann es der Fall sein, dass die zu erwartende Verbesserung es noch immer nicht wert ist, die Ressourcen einer kompletten Arbeitsgruppe dafür aufzuwenden.

Und vor allem: Entwickle keine Technologie, die nur mit Technologien zusammenarbeitet, die sich noch überhaupt nicht durchgesetzt haben, ganz gleich wie vielversprechend sie sich anhören! Das Risiko ist zu groß. Ein Beispiel: Im Moment (2000) verspricht XLink eine mächtige Technologie zu werden, neuen XML-Formaten Hyperlinks hinzuzufügen, aber CSS 3, was zurzeit entwickelt wird und was Hyperlinks in XML-Dokumenten stylen soll, kann sich nicht auf XLink stützen. Es muss ebenso mit nicht-XLink-Hyperlinks umgehen können.

Siehe auch

[Nielsen98a]

Nielsen, Jakob. Does Internet = Web?. 20 Sep 1998. Alertbox column. URL: http://www.useit.com/alertbox/980920.html

Entwurf durch einen Ausschuss

Nahezu alle Spezifikationen werden eher durch einen Ausschuss als durch eine Einzelperson erstellt. Die W3C-Arbeitsgruppen bestehen typischerweise aus etwa 10 bis 20 Personen, die ein Jahr oder länger zusammen an einer neuen Technologie arbeiten.

»Entwurf durch einen Ausschuss« hat keinen guten Ruf (Spezifikationen sind ein Flickwerk an inkonsistenten Lösungen, oftmals redundant, und deswegen zu groß und zu schwer zu erlernen), aber in Wirklichkeit entstehen nicht automatisch schlechte Ergebnisse. Denken wir an das Sprichwort »Vier Augen sehen mehr als zwei«, und genau aus diesem Grund gibt es Arbeitsgruppen: mehrere Augenpaare können genauer nach Fehlern suchen, bringen mehr Kreativität beim Finden von Problemlösungen und mehr Erfahrung mit, sie wissen, was in der Vergangenheit funktionierte und was nicht.

Aber der »Entwurf durch einen Ausschuss« bringt auch Probleme mit sich, die vermieden werden müssen. Etwa 15 Mitglieder sollten die Grenze sein, denn größere Gruppen tendieren dazu, lockere Untergruppen zu formieren und verlieren zu viel Zeit mit Kommunikation untereinander, anstatt zu entwickeln.

Kleinere Gruppen produzieren konsistentere und leichter verwendbare Spezifikationen, aber sie können einige Dinge weglassen, von denen sie nicht wussten, dass jemand sie benötigen könnte. Eine Lösung könnte sein, eine größeren Kreis an interessierten Personen in Form einer öffentlichen Mailing-Liste um sie herum zu schaffen.

Auf diese Weise entwickelt das W3C seine Technologien: Eine Arbeitsgruppe bestehend aus Experten und eine Mailingliste für andere interessierte Personen. Darunter kann es welche geben, die sich nur für ein Detail interessieren oder nur gelegentlich Zeit haben, über die Entwicklung zu diskutieren. In der Arbeitsgruppe würden sie den Entwicklungsprozess behindern, aber in der Mailingsliste können sie wertvolle Beiträge leisten.

Das IETF zeigt, dass es möglich ist, Technologien mit einer einzigen, offenen Gruppe von Personen zu entwickeln, ohne zwischen Leuten, die sich zu einer bestimmten Menge an Arbeitsaufwand verpflichtet haben, und Leuten, die das nicht getan haben, zu unterscheiden. Aber IETF-Gruppen tendieren dazu, systemnahe, sehr technische Spezifikationen zu verfassen, wohingegen W3C-Spezifikationen näher am Durchschnitts-User sind (wenigstens werden sie so wahrgenommen) und daher mehr interessierte Personen anziehen. Es kann auch sein, dass das Umfeld sich geändert hat: Das Publikum des Internets heute unterscheidet sich von dem vor den Zeiten des Webs.

Natürlich setzt das Zwei-Stufen-System den Willen des Ausschusses voraus, die Meinungen »von außen« zu beachten. Es braucht einige Zeit, die Mailing-Liste nach wichtigen Nachrichten zu durchsuchen und diese, falls nötig, zu beantworten. Aber vor allem anderen benötigt es eine Offenheit des Ausschusses, seine Gründe für die eine oder andere Entwicklung der Öffentlichkeit gegenüber zu kommunizieren, auch wenn er es manchmal nur mit dem kurzfristen Belang eines einzelnen Unternehmens zu tun hat. Und es erfordert eine entsprechende Offenheit der Öffentlichkeit, diese Gründe als stichhaltig zu akzeptieren.

Fachkompetenz

Wenn eine Spezifikation so groß ist, dass es Experten für einzelne Teile davon gibt, aber niemand als Experte für das Ganze bezeichnet werden möchte, dann ist die Spezifikation definitiv zu groß. Sie in zwei Teile aufzusplitten und jeweils eine eigene Arbeitsgruppe einzusetzen, wird letztendlich nahezu immer zu einem besseren Ergebnis führen.

Keine Menge an formalen Methoden kann einen Experten ersetzen, der kompetent genug ist, die gesamte Spezifikation im Kopf zu haben, um Inkonsistenzen und Redundanzen aufzufinden.

Kürze

Ich gehe in diesem Essay zumeist davon aus, dass die meisten Spezifikationen für Programmierer geschrieben sind. Das muss nicht immer der Fall sein. Eine wichtige Aufgabe ist es, die Zielgruppe zu identifizieren und konsistent für diese Zielgruppe zu schreiben. Wenn man die »falsche« Zielgruppe auswählt, führt das vielleicht noch immer zu einer lesbareren Spezifikation als wenn man »für jeden« zu schreiben versucht.

Vergessen Sie nicht, dass die meisten Leute wenig Zeit haben: Eine Spezifikation mit einem Umfang von 50 Seiten zu lesen, ist sicherlich möglich, auch wenn 15 besser sind, aber wer liest 385 Seiten? Der typische Programmierer wird die ersten 20 Seiten lesen, sich einige weitere Beispiele anschauen und dann sofort anfangen, zu programmieren. Er wird das, was er nicht gelesen hat, durch das ersetzen, wovon er glaubt, es wäre die logische Erweiterung … Bedauerlicherweise sind Spezifikationen nicht immer logisch; allzu oft sind sie Ergebnis von Kompromissen zwischen den Mitgliedern des Ausschusses. Vermutlich sollte das nicht der Fall sein, aber so ist es in der Praxis nunmal.

Manchmal ist es tatsächlich sinnvoll, eine Spezifikation dadurch zu verkürzen, dass man Erläuterungen entfernt, denn das kann dazu führen, dass mehr Leute sie bis zum Ende lesen werden.

Es gibt auch noch einen weiteren Grund, weshalb das Entfernen von Erklärungen eine gute Sache sein kann: Je mehr Erklärungen es gibt, desto höher die Wahrscheinlichkeit, dass sie sich gegenseitig widersprechen. Es ist besser, Erklärungen und Anmerkungen in ein separates, nicht normatives Dokument auszulagern, oder vielleicht in ein Buch.

Aber entfernen sie nicht die Beispiele! Ein gut gewähltes Beispiel kann oftmals mehrere Absätze an Erklärungen ersetzen. Und darüber hinaus können sie als grober Testfall für neue Implementierungen verwendet werden.

Programmierer finden typischerweise gern heraus, wie Dinge funktionieren, während sie programmieren, eher als englischen Text zu lesen. Das ist ein Paradoxon: Weniger Erläuterungen führen zu besserem Verständnis. Ich glaube, Programmierer mögen Puzzles…

P.S. Stylesheets erlauben alternative Sichten des gleichen Dokuments, zum Beispiel eine mit und eine ohne Beispiele.

Siehe auch

[Lesch00]

Eriksson, Jan Roland; Lesch, Susan; et al.. Friendly Specs. 8 Apr 2000. E-mail thread on www-html [WWWHTML].
URL: http://lists.w3.org/Archives/Public/www-html/2000Apr/0062.html

[WWWHTML]

www-html mailing list. May 1994. Mailing list for discussion of HTML.
URL: http://lists.w3.org/Archives/Public/www-html/

Beständigkeit

Technologie ändert sich, die Zukunft kann nicht vorausgesagt werden, und oftmals müssen Autoren etwas veröffentlichen, von dem sie erwarten, dass es sich in Zukunft ändert, einfach deshalb, weil es einen dringenden Bedarf für einen Standard gibt. Hoffentlich haben sie für Erweiterbarkeit gesorgt…

Für gewöhnlich ist die Stabilität einer Spezifikation ein erstrebenswertes Merkmal. Wenn man zum wiederholten Mal lernen muss, dass es teuer ist, etwas zu ändern, und dass die Konvertierung eines bestehenden Dokuments und anderer Ressourcen in unterschiedliche Formate ebenfalls teuer ist, dann sollten Änderungen, die wenig oder keinen Nutzen bringen, vermieden werden.

Das Web ist eine Revolution. Aber lassen sie es nicht so weit kommen, dass etablierte Technologien zu schnell von neuen Entwicklungen überrannt werden! Trotz all seiner Mängel ist HTML noch immer ein nützliches kleines Format. Es gibt bisher absolut keinen Grund, es zu ersetzen.

Robustheit

Netzverbindungen können fehlschlagen, Menschen können Fehler machen, Dateien können verloren gehen, Software kann Fehler haben, die neue Version mag nicht so rückwärtskompatibel sein, wie man geglaubt hat … und genau dann, wenn man dringend eine bestimmte Information benötigt, kann man sie nicht finden, oder sie kommt beschädigt an.

Redundanz (aber nicht zu viel) kann helfen. Das beinhaltet die Verwendung von Textdateien oder das Einfügen eines einzigartigen Identifikationsmerkmals in ein Dokument, so dass es unabhängig von seinem URL wiedererkannt werden kann. Und auch das Vorhandensein einer Druckversion eines Dokuments mit genügend Information, sodass die Beziehung zwischen Dokumenten von Hand anstatt mit einem Computer nachvollzogen werden kann.

Dinge einfach zu halten und nicht von zu vielen anderen Technologien abhängig zu machen, ist eine gute Idee. Auf Technologien aufzubauen, von denen bekannt ist, dass sie stabil sind, ebenso.

Nicht nur die Technologie sollte robust sein, auch ihre Verwendung. Beim Publizieren von Information, kann es helfen, Information in kleinere Einheiten aufzuteilen, um Fehler zu vermeiden. Wenn etwas notwendig für das Verständnis von etwas anderem ist, sollten beide Teile am gleichen Ort oder sogar in der gleichen Datei vorkommen, ohne eine Netzwerkverbindung dazwischen, die unterbrochen werden könnte.

In der Praxis gilt das oben gesagte auch für den Entwurf eines Dokuments: Wenn ein Dokument eine hübsche Abbildung enthält, die jedoch nicht wichtig für das Textverständnis ist, sollte die Abbildung eine separate Datei sein, denn das macht die Textdatei kürzer, senkt die Wahrscheinlichkeit, dass sie Fehler enthält und erhöht die Wahrscheinlichkeit, dass sie intakt ankommt. Aber wenn der Text mathematische Formeln enthält, sollten sie in dem Dokument eingebunden sein, denn da darf man nicht riskieren, dass sie verloren gehen.

Es gibt zurzeit (im Jahre 2002, als dieser Essay verfasst worden ist) kaum Studien, wie man das Web robust machen kann. Aber das ist ein wichtiger Punkt, denn das Web ist Teil der Infrastruktur der modernen Wirtschaft.