- Motivation - Kurzübersicht - Anforderungen - Spezifikation - Validierung - Fazit -

Motivation

Das alte Werkzeug

Lange Zeit erstellte und wartete ich meine Website mit Netobjects Fusion, einem Werkzeug, das auf visueller Bearbeitung basiert und aus einer eigenen Datenbasis heraus mäßig brauchbares HTML generiert. Im großen und ganzen war ich damit zufrieden, sah mich aber zum einen mit funktionalen Beschränkungen konfrontiert, und war zunehmend auch mit dem Bedienkonzept von Netobjects Fusion nicht mehr einverstanden. Als reines Windowsprogramm basiert es auf graphischem Editieren mit viel Mausinteraktion und bietet ohne den Erwerb einer dazu passenden Entwicklungsumgebung kaum Möglichkeiten zur Erweiterung der Funktionalität. Nicht zuletzt jedoch wollte ich nicht mehr auf ein proprietäres Werkzeug angewiesen sein. Dies impliziert außerdem den Wunsch, meine Daten nicht mehr in einem Binärformat halten zu müssen, welches ohne das Programm nicht lesbar ist.

XML

Die Lösung liegt nahe und wird von vielen Seiten im Netz genutzt: eXtensible Markup Language (XML) und Transformationen auf dieser Sprachform. XML hat den Vorteil, daß alle Daten in einfachen Textdateien vorliegen (also ASCII), welche sowohl sicher gegen Datenkorruption durch eventuelle Programmabstürze als auch leicht versionierbar sind, z.B. mit CVS. Sicher gegen Datenkorruption heißt nicht, daß es unmöglich ist, daß durch Programmabstürze – so unwahrscheinlich das beim Editor Emacs auch sein mag – mal eine Datei durcheinander gerät. Aber im Gegensatz zu binären Daten, wo in vielen Fällen ein Programmabsturz zu irreparablen Schäden an der Datei führt, ist XML ja nur blanker Text. Auch wenn Teile der Datei defekt sind, können die übrigen problemlos gelesen und repariert werden.

Trennung von Inhalt und Form

Den letzten Anstoß haben mir dann die Seiten meines ehemaligen Dozenten, Mario Jeckle, gegeben, sowie meine zunehmende berufliche Berührung mit XML. Die Klarheit, die dieses Format bietet, als auch die direkte Verwandtschaft mit HTML bieten demjenigen, der auf eine WYSIWYG (What you see is what you get)-Bearbeitung verzichtet, viele Annehmlichkeiten. Da aufgrund unterschiedlicher Browser, Auflösungen und sonstiger Gegebenheiten meiner Besucher der Website ohnehin nicht von WYSIWYG die Rede sein kann, wäre eine Bearbeitung nach diesem Paradigma ein Unsinn; eigentlich müßte man ein What-you-see-is-what-they-get-System haben. Da im WWW ein solches aufgrund der Vielzahl von Browsern und Benutzereinstellungen praktisch unmöglich ist, kann ich mich – ganz nach LaTeX-Art – auch gleich ausschließlich auf den Inhalt konzentrieren und das Aussehen meinem Transformationssystem und dem Browser der Benutzer überlassen.

Kurzübersicht

Artefaktisch

Quelldateien, abgefaßt in einer Obermenge von XHTML
Transformationsanweisungen in XSLT
Struktur der Website in einem selbstdefinierten XML-Format
Buildfile zur automatischen Generierung der Seite
CVS-Repository zur Versionierung

Programmatisch

Folgende Programme finden Einsatz im Projekt, jeweils versehen mit Links zu ihren Homepages.

Apache Xalan-J. XSLT-Prozessor
CVS. Versionsverwaltung
Apache Ant. Steuerung des Generierungsprozesses
Emacs. Editor
Cygwin. Unix-Shell für die Titelbildgenerierung
ImageMagick. Graphikwerkzeuge für die Kommandozeile
The GIMP. Bildbearbeitung
Linklint. Hyperlinkprüfung
Ispell. Rechtschreibprüfung

Anforderungen

Bei der Strukturierung des Projekts waren mir verschiedene Aspekte wichtig, die ich hier informell aufliste. Informell heißt, daß die üblichen Paradigmen der Anforderungserfassung, inbesondere Atomizität, zu Gunsten besserer Lesbarkeit verletzt werden.

Die Website soll sich als Baum begreifen lassen, jedoch soll eine netzartige Struktur nicht von vornherein ausgeschlossen werden.
Die einzelnen Seiten sollen unabhängig von der Struktur der Website sein. Sie sollen also nicht auf eine bestimmte Position innerhalb des Baumes festgelegt sein und bei einer Relokation nicht verändert werden müssen.
Es soll sich automatisch ein Navigationsmenü generieren lassen, das seinen Inhalt aus einer Strukturbeschreibung bezieht. Das Navigationsmenü soll flexibel eventuelle untergeordnete Seiten miteinbeziehen und so den jeweiligen Ausschnitt des Strukturbaumes anzeigen.
Externe Links sollen zentral gehalten werden können und so die Seiten unabhängig von externen Adreßänderungen machen.
Häufig auftretende Konstrukte, wie z.B. vergrößerbare Photographien mit Bildunterschriften, sollen einfach verwendbar sein und so überall gleiches Aussehen gewährleisten.
Verwendete Bildartefakte sollen unabhängig vom Ablageort der Seite sein, also automatisch richtig verlinkt werden.
Die Website soll trennen zwischen Inhalt und Layout.
Generell soll es möglich sein, unterschiedliche Seiten mit verschiedenen Layouts versehen zu können, wie z.B. „normal“, „minimal“.
Einzelne Seiten sollen mit einer Druckansicht versehen werden können, also auch ohne Hintergrundgraphiken oder Banner darstellbar sein. Mittlerweile ist dies durch entsprechenden Einsatz von CSS für alle Seite möglich.
Die Website soll unabhängig vom Zielverzeichnis sein, so daß sie sich beliebig auf dem Server ablegen läßt.
Mikrotypographische Mittel wie Geviert und Halbgeviert (also Gedankenstriche), sowie Anführungszeichen und verschiedene geschützte Leerräume sollen durch HTML-Entitäten unterstützt werden.
Die Website soll unabhängig vom Browser des Benutzers oder dessen Konfiguration vernünftige Anzeigeergebnisse erzielen. Dies schließt ein Degradationskonzept ein, also eine korrekte Darstellung auch bei deaktivierten Graphiken, deaktiviertem Javascript und fehlendem CSS.
Die Website soll den Anforderungen der Web Content Accessibility Guidelines 1.0 genügen.

Die gelisteten Anforderungen erheben keinen Anspruch auf Vollständigkeit und werden bei Bedarf erweitert bzw. geändert.

Spezifikation

Übersicht

Drei Quellen benötigen wir zum Erzeugen der HTML-Ausgabe, die in den folgenden Abschnitten erläutert werden. Zusammen mit der vierten Quelle findet die Anzeige im Browser statt.

Struktur, XSLT und Quellen werden durch den XSLT-Prozessor nach HTML übersetzt. Zusammen mit CSS erfolgt die Darstellung.

Übersicht über den Generierungsprozeß

Strukturdatei

Die Strukturdatei enthält den Baum der Seitenstruktur. Ein Knoten des Baumes entspricht einer Seite, die Vorfahren, Nachkommen und Nachbarn definieren exakt die Lage der Seite. Außerdem werden Titel, Eintrag in die Navigationsleiste und eventuell vom Identifikator abweichender Dateiname sowohl für Quelldatei als auch für Zieldatei festgelegt.

Globale Variablen können für vielfältige Zwecke eingesetzt werden. So gibt es beispielsweise eine Variable für den Namen der Website, die Verzeichnisnamen für Artefakte und Graphiken, außerdem für meine Adresse.

Linkdatei

Die Linkdatei enthält die externen Links, also Verknüpfungen, die auf andere Seiten im Netz verweisen. Diese werden über einen textuellen Identifikator referenziert, der Inhalte von den Verlinkungen unabhängig macht. Die textuelle ID entspricht der Kurzbeschreibung für den Link. Beispiel: Der Identifikator Dante bezeichnet den Link auf die Homepage der Deutschen Anwendervereinigung TeX e.V., kurz Dante.

Transformationsanweisungen

Die Transformationsanweisungen in der Sprache XSL Transformations (XSLT) verfaßt, einem Standard des World Wide Web Consortium (W3C). Die XSLT-Anweisungen dienen dazu, die Inhalte aus den Quelldateien in das Grundgerüst des Seitenlayouts einzubetten. Das Seitenlayout umfaßt den Hintergrund, die Titelei sowie die Navigationsleiste. Außerdem werden die referenzierten Identifikatoren für interne und externe Verweise in URL umgesetzt. Als zusätzliche Vereinfachung werden sonstige proprietäre Auszeichnungen in HTML-Konstrukte übersetzt.

Über ein Attribut im entsprechenden Eintrag in der Strukturdatei können verschiedene Seitenlayouts gewählt werden. Da die Realisierung der Layouts inzwischen vollständig auf CSS basiert, wird dieses Attribut nicht genutzt. Die entsprechenden Teile des XSLT-Codes, die dem Standardlayout ein Minimallayout, eine Druckansicht sowie eine Aufteilung des Standardlayouts in ein Frameset realisierten, habe ich wieder entfernt, nachdem die CSS-Lösung ausgereift war.

Die Navigationsleisten sind unabhängig von der Tiefe des Strukturbaumes, sie stellen die Wurzel und die erste Ebene stets vollständig dar, dazu kontextabhängig die Kindebene des aktuellen Knotens, sowie den Kontext der Vorfahrenknoten. Sie beziehen ihre Informationen aus der Strukturdatei, einschließlich Einstellungen, die beispielsweise eine Indizierung einzelner Zweige unterbinden.

Proprietäre Auszeichnungen sind z.B. Photographien mit Bildunterschriften, vergrößerbare Bilder, eine in ihrer Funktionsweise veränderte Beschreibungsliste, und einige andere. Wichtig ist die proprietäre Auszeichnung für Schlüsselwörter. Diese werden während der Transformation gesammelt und in die Kopfdaten der HTML-Seite als META-Tag geschrieben.

Quelldateien

Die Quelldateien für die einzelnen Seiten enthalten weder Titel noch Navigationsleisteneintrag, lediglich optional den Identifikator für die Seite. Da üblicherweise jedoch die Quelldateien im Dateinamen dem Identifikator entsprechen, ist auch dies nicht notwendig. Selbstverständlich ist auch möglich, abweichende Dateinamen zu vergeben. Dazu kommt eine Kurzbeschreibung der Seite, die dann in ein Metatag nach dem Dublin Core umgewandelt wird.

Die Quelldateien verwenden die normalen Entitätsdefinitionen von XHTML, die ja auch Namen für typographische Zeichen wie Anführungszeichen und (Halb-)Geviert beinhalten.

Prinzipiell können die Quelldateien im Browser angezeigt werden, um eine Voransicht für Texte zu erhalten. Dabei bleiben Graphiken natürlich unberücksichtigt, da diese nicht das normale src-Attribut verwenden, sondern mit Hilfe eines proprietären Attributs isrc automatisch auf das Bilderverzeichnis verwiesen werden. Aus ähnlichem Grund sind auch interne und externe Verweise nicht funktionsfähig. Wie oben erwähnt, werden diese erst während des Übersetzungsvorgangs aufgelöst. Proprietäre Auszeichnungen werden natürlich überhaupt nicht vom Browser verarbeitet. Während der Erstellung dieser Website habe ich jedoch nie das Bedürfnis der Voransicht verspürt. Und wenn doch, hilft einem der schnelle und einfache Generierungsprozeß.

Buildfile

Mittels eines separaten XSLT wird die Strukturdatei in ein Buildfile für das Werkzeug Apache Ant übersetzt. Dies hat den Vorteil, daß eine Änderung der Struktur, wie beispielsweise eines Dateinamens, einer Position einer Seite im Baum, oder beim Hinzufügen einer Seite, nur an einer Stelle vorgenommen werden muß, alles andere geht dann automatisch.

Ant ist ein Apache Projekt, das ein Generierungswerkzeug ähnlich dem weit verbreiteten GNU Make realisiert. Ant ist vollständig Java- und XML basiert und arbeitet speziell bei Übersetzern, die in Java vorliegen, sehr schnell.

Da der Einarbeitungsaufwand nicht unerheblich war, habe ich anfangs auch bei diesem Projekt mit herkömmliche Makefiles gearbeitet und erst zu Apache Ant migriert, als der Rest halbwegs lief. Jedoch gestaltet sich im Nachhinein betrachtet das XSLT für Ant viel einfacher als das für Make, weil die – Programmierern wohlbekannten – Einrückungen entfallen und man keine Rücksicht auf irgendwelche Kommandozeilenumgebungen nehmen muß.

Versionierung

Selbstverständlich muß sichergestellt sein, daß Änderungen an der Website verfolgbar sind, ich also im Falle des Falles auf eine frühere Version zurückgreifen kann. Dafür gibt es das bei vielen Softwareprojekten verwendete CVS.

CVS erlaubt zudem, Versionsinformationen direkt in den archivierten Dateien abzuspeichern, wie auf jeder Seite ganz unten im Datum zu sehen ist. Dieses Datum wird beim Checkout automatisch von CVS durch das Datum des letzten Checkin gesetzt. So sieht man jederzeit, wann das Dokument zuletzt geändert wurde.

Formatierung und Metainformationen

Wie bei mittlerweile der Mehrheit der Seiten im Internet üblich, erfolgt auch bei mir die Formatierung mit Hilfe von Cascading Style Sheets, kurz CSS. Für die gesamte Site wird dieselbe CSS-Definition verwendet, die auch viele eigene Klassen definiert. Diese Klassen dienen einmal mehr dazu, den Inhalt von der Form zu trennen, und damit einfach das Aussehen verändern zu können, sogar ohne erneutes Generieren der Seiten. Damit wurde auch die Druckansicht realisiert, der Wechsel zwischen beiden wurde realisiert durch ein Skript von Paul Sowden. Der Link für den Wechsel zur Druckansicht ist die einzige Funktion, die JavaScript erfordert. Zwar läßt sich die Umschaltung auch problemlos serverseitig per PHP realisieren, lädt aber dann bei jedem Umschalten die Seite neu vom Server. Moderne Browser wie Mozilla oder Opera erlauben jedoch auch ohne JavaScript die Auswahl der Stylesheets.

Laut Anforderungen soll die Seite degradationsfunktional sein, also auch bei Browsern, die nicht mit CSS umgehen können, eine vernünftige Darstellung erzielen. Dies erreicht man, indem man erstens darauf achtet, Formatierungen ausschließlich mit CSS vorzunehmen, so daß ohne CSS kein Unsinn entsteht. Zweitens muß man aber auch auf die gröbsten Schwächen der Browser achten, um zu gewährleisten, daß keine CSS-Anweisungen verwendet werden, die den Browser durcheinander bringen und im schlimmsten Fall sogar die Darstellung völlig zerstören. Letzteres ist der aufwendige Teil der Arbeit und erfordert das Testen mit verschiedenen Browsern.

Am einfachsten läßt sich die Degradation am Beispiel des Internet Explorer zeigen. Dieser unterstützt nicht den vollen Umfang der CSS-Eigenschaften, was sich leicht sehen läßt, indem man den ersten Textabsatz nach einer Überschrift betrachtet. Laut CSS sollte die erste Zeile des ersten Absatzes nicht eingerückt sein, was der Internet Explorer nicht versteht. Doch außer dem von mir unerwünschten Einrücken passiert nichts. Das beste Beispiel für die Degradation ist der Netscape Communicator 4.7x. Dieser verfügt über noch wesentlich weniger Möglichkeiten zur CSS-Formatierung. Deswegen verliert die Seite ihr gewohntes Layout, bleibt aber vollständig bedienbar.

Die Metainformationen, also das, was derzeit von Suchmaschinen und zukünftig wohl auch von anderen Indexsystemen bei Websites ausgewertet wird, sind bei mir nach dem Standard der Dublin Core Metadata Initiative abgefaßt. Dieser bietet wesentlich differenzierte Möglichkeiten als die herkömmlichen, einfachen Metatags wie generator oder author.

Rechtschreibprüfung

Ein wesentlicher Vorteil von Emacs gegenüber anderen Editoren ist, daß sich das Rechtschreibprogramm International Spell, kurz Ispell, nahtlos integrieren läßt. Damit kann ich beim Editieren alle Quelldateien prüfen, bevor sie ihren Weg durch den XSLT Prozessor nehmen.

Validierung

Ich versuche, die Seite soweit als möglich konform sowohl zum CSS Standard als auch zum XHTML Standard zu halten. Während des Generierungsprozesses werden die erzeugten Dokumente mit Hilfe des Ant XMLvalidate Tasks automatisch gegen die jeweilige Dokumentdefinition (DTD) validiert.

Selbstverständlich kann diese Validierung auch online im Internet durchführen. Dabei helfen die Webservices des W3C.

Neben XHTML und CSS unterstütze ich noch weitere Standards und Webinitiativen.

Fazit

Meine Implementierung erlaubt mir, die Website ohne großen Aufwand zu erweitern und zu pflegen. Änderungen an der Struktur können einfach vorgenommen werden. Alle Daten des Inhalts, des Layouts und der Struktur liegen in UTF-8-Dateien vor, die versioniert werden können. Die Bearbeitung und Umsetzung erfolgt zu 100 Prozent mit freier Software (Frei im Sinne von „freie Rede“, nicht „Freibier“) und nutzt offene Standards. Ich bin unabhängig vom Betriebssystem und von konkreten Anwendungen. Die Seiten sind unabhängig vom späteren Aussehen der Seite, ich kann problemlos die Form der gesamten Website ändern, ohne auch nur eine Seitenquelldatei oder die Transformationsanweisungen anzufassen. Nicht zuletzt werden die Zieldateien automatisch generiert, wildes Herumklicken ist sowohl dafür als auch zum Editieren überflüssig.

Für mich bietet die Arbeit mit meiner Infrastruktur also wesentliche Vorteile gegenüber dem alten Konzept mit Netobjects Fusion, bei dem ich auch die völlige Kontrolle über den HTML-Code vermißt habe. Abschließend bleibt festzustellen, daß das neue System alle Möglichkeiten bietet, die ich für ein Projekt dieser Größenordnung brauche. Selbstverständlich kann und will ich damit kein Content-Management-System ersetzen, sondern wirklich nur relativ statische Websites mit „begrenztem“ Umfang realisieren (im Moment umfaßt diese Website gut 60 Seiten).

Warum kein Content Management System?

Warum verwende ich noch kein Content Management System (CMS)?

Nun, zum einen ändern sich meine Seiten nicht so häufig, daß dafür unbedingt ein CMS notwendig wäre. Zum anderen würde ich gerne, habe jedoch noch keines gefunden, welches mir auf einfache Weise die Möglichkeiten bietet, welche ich jetzt schon habe. Und ich möchte nicht erst aufwendig Module schreiben müssen, um wieder die gleiche Funktionalität zu erhalten, wie ich sie jetzt habe. Und im Prinzip habe ich ja eine Art Offline-CMS.

Die Generierung dieser Seiten