technische kommunikation | 30.Jahrgang | 2 / 2008 | Seite 12

Kriterien, Perspektiven und Grenzen von Open-Source-Systemen

Offene Anwendungen – ein Modell für die Technischen Dokumentation?

von Ferdinand Soethe

Spricht man mit Technischen Redakteuren über das Thema Single-Source-Publishing (SSP), hat man manchmal den Eindruck, von Utopia zu reden. (Fast) alle kennen es, fast jeder könnte es gut für seine Arbeit brauchen, doch kaum jemand setzt es wirklich ein.

Die Notwendigkeit, Inhalte für verschiedene Zielmedien aufzubereiten, ist weder mit klassischen Textverarbeitungs- oder DTP-Systemen noch mit Webdesign-Tools wirklich befriedigend zu lösen. So fand die zum Ende der 90er geborene XML-Sprachfamilie eine große Resonanz im Bereich der Technischen Dokumentation. Und als dann auch noch große Softwarefirmen wie Lotus, Sun und IBM leistungsfähige Programme zum Lesen und Transformieren von XML als Open-Source-Software veröffentlichten, entstand in kurzer Zeit eine breite Basis für Single-Source-Publishing-Systeme ohne Herstellerbindung. Auch Java spielte in dieser Entwicklung eine wichtige Rolle, erlaubte es doch erstmals mit vergleichsweise geringem Aufwand Anwendungen zu programmieren, die auf allen gängigen Betriebssystemen problemlos liefen.

Inzwischen hat man die Wahl zwischen zahlreichen Systemen unter Open-Source-Lizenz und proprietären Lösungen. Da fällt der Vergleich schwer, zumal der Weg zum Single-Source-Publishing (SSP) doch sehr unterschiedlich ausfallen kann.

Medienunabhängige Formatierung
Funktionale Auszeichnung, also die Auszeichnung von Textstücken mit ihrer Bedeutung, ist Kern des SSP-Konzepts. Anstatt die Darstellung in einem bestimmten Medium hin zu formatieren, zum Beispiel das Setzen von Zitaten in kursiv

er sprach von ganz persönlichen Erfahrungen …

hinterlegt der Autor im Text nur die Bedeutung einer Textstelle

er sprach von <zitat>ganz persönlichen Erfahrungen</zitat> …

und überlässt es der Folgeverarbeitung, wie diese Bedeutung mediengerecht umgesetzt wird. So kann das Zitat für die Druckausgabe kursiv gesetzt, in der Audiowiedergabe dagegen von einer zweiten Stimme gesprochen werden.

Was in der Theorie einfach klingt, ist leider in der Praxis schwer durchzuhalten. Zu sehr steckt in vielen Köpfen noch ein Medienbezug. Daher sollten SSP-Systeme von sich aus klare und sinnvolle Auszeichnungen durchsetzen.

Auszeichnungssprachen auf HMTL-Basis sind dafür wenig geeignet, weil sie nur für einen Bruchteil der benötigten funktionalen Auszeichnungen passende Elemente bieten. Erweitert man sie manuell durch class-Attribute,

<p class=″Anweisungsschritt″>Klicken Sie auf Bearbeiten-Kopieren</p>

ist Wildwuchs wiederum nur schwer im Zaum zu halten. Gleiches gilt übrigens auch für die beliebten Wikis.

Auch XML allein hilft nicht weiter, denn es ist als Dokumentenformat zwar universell und sehr flexibel, kann aber genau wegen dieser Flexibilität kein Garant für sinnvolle Auszeichnungen sein. Darum behebt auch XHTML nicht die Probleme mit HTML. Und aus einer Microsoft Word-Datei wird durch Verwendung von XML noch lange kein brauchbares SSP-Format.

Ein gutes SSP-System setzt stattdessen auf erprobte Auszeichnungssprachen wie Docbook [1] oder DITA [2] und unterstützt idealerweise verschiedene Sprachen. Hier haben XML-basierte Systeme die Nase vorn, weil die ganze Technologie auf Universalität und Austauschbarkeit ausgelegt ist.

Dennoch klaffen Theorie und Praxis oft auseinander. So bringt die Anwendung Apache Forrest [3] alle Voraussetzungen für echtes SSP mit, die Forrest Beispiel-Anwendung aber benutzt fast überall ein HTML-ähnliches XML-Format namens „document-v20“ und muss erst durch mitgelieferte Plug-ins für echtes SSP konfiguriert werden. Das Potenzial des Systems erschließt sich so erst auf den zweiten Blick.

Doch Vorsicht mit allzu schnellen Urteilen. Zuweilen fungieren wie bei Forrest HTML- oder XHTML-Dialekte nur als interne Mittlerformate, mit deren Hilfe zusätzliche Quell- oder Ausgabeformate leichter zu unterstützen sind.

Abb. 1: Mittlerformate vereinfachen die Unterstützung neuer Quell- und Zielformate

Diese Hilfe ist durchaus sinnvoll. Entscheidend ist, wie gut bei diesem Zweisprung die Informationen der Quellformate erhalten bleiben. Für ein gutes Ergebnis müssen aber auch in der Ausgabetransformation noch die vollen Informationen des Quelldokuments zur Verfügung stehen, ein Anspruch, dem bislang kaum ein System gerecht wird.

Grammatik-Fähigkeit
Die beste Auszeichnungssprache nützt wenig, wenn ihre Vorgaben nicht beachtet werden. Daher ist Grammatik-Fähigkeit, also die enge Einbindung von Regelwerken wie DTD, Schema [4] oder Relax NG [5] in jeden Teil des Systems wichtig.

Systeme, die Dokumente nur validieren, verschenken viele praktische Vorteile: Kennt und versteht bereits der Editor die Auszeichnungssprache, kann er dem Autor für einen Textteil ein Menü mit verwendbaren Auszeichnungen anbieten. Mancher fortgeschrittene Editor erläutert, zum Beispiel oXygen [6] in Abbildung 2, bei der Auswahl sogar die Bedeutung und den Einsatzzweck der möglichen Elemente.

Abb. 2: Maximale Unterstützung durch den Editor

Doch auch die XML-Welt hat in diesem Punkt ein paar unschöne Stellen. So wurde als Nachfolger der bekannten DTDs zunächst das mächtigere und komplexe Schema eingeführt. Inzwischen verbreitet sich aufgrund seiner Benutzerfreundlichkeit Relax NG als weitere Grammatiksprache. Eine Entwicklung, die nur wenige Systeme schon komplett nachvollzogen haben.

Visuell unterstützte Textverarbeitung
Auch war lange Zeit die Arbeit mit XML-Editoren ein zweifelhaftes Vergnügen. Zwar ging die Texteingabe angesichts der Grammatik-Unterstützung schnell von der Hand, doch die Korrektur geriet wegen der eingestreuten XML-Tags zur Konzentrationsübung. Wie bequem kommen dagegen OpenOffice [7] oder Microsoft Word daher, wo eine Überschrift groß und fett und eine ungeordnete Liste an ihren punktierten Absätzen auf den ersten Blick zu erkennen ist.

Gute XML-Editoren wie XML Spy [8], oXygen oder XMLmind [9] bieten mittlerweile ähnliche Lösungen: Zusätzlich zum XML-Quelltext gibt es einen augenfreundlichen visuellen Modus für Anzeige und Bearbeitung. Durch Anpassung von Formatvorlagen (meist CSS-Stylesheets [10]) kann der Autor nun selbst festlegen, wie Textelemente dargestellt werden sollen („what-you-see-is-what-you-need“).

Das kann bei einer punktierten Liste identisch mit der späteren Druckausgabe sein, oftmals weicht es aber sinnvollerweise davon ab. Etwa weil man verschiedene Textauszeichnungen am Bildschirm am einfachsten durch unterschiedliche Farben oder Prefixe erkennen kann. Oder auch weil die Schriftart für den Druck am Bildschirm nur schlecht zu lesen ist.

Allerdings gibt es hier beachtliche Unterschiede zwischen den Systemen. Es lohnt sich daher, die Editoren einmal bei der Arbeit an einem längeren Text zu testen.

Aus Sicht des SSP-Systems gilt: Im  Idealfall sollte der Editor

• frei wählbar,
• leicht in das System einzubinden
• und in der Darstellung flexibel konfigurierbar sein.

Das ist bei vielen Server-basierenden CMS-Systemen im Open-Source-Bereich ein Pferdefuß: HTML kann man meist noch visuell bearbeiten, Unterstützung für XML-Dialekte und echte Grammatikfähigkeit sucht man vergebens.

Der Editor Apache Lenya [11] hebt sich hier positiv vom Rest des Feldes ab und unterstützt online beliebige XML-Dialekte, insofern es dafür eine Relax NG-Grammatik gibt. Der verwendete Bitflux-Editor [12] geht in seinem Ansatz weit über die Möglichkeiten von CSS-Formatierung hinaus, da er die visuelle Aufbereitung durch echte XSL-Transformationen realisiert.

Publikationsunterstützung
Wer lediglich kleine Dokumente in HTML und PDF ausgeben möchte, benötigt dafür kein SSP-System. Die meisten XML-Editoren unterstützen heute Transformationsszenarien, viele liefern sogar Stylesheets für wichtige Transformationen gleich mit.

Doch oft reicht dies nicht aus: Was im Web auf separaten Seiten erscheinen soll, wird man für den Druck zu einem Buch mit Titelseiten, Seitenzahlen und Inhaltsverzeichnis zusammenfassen. Auch müssen sich Web-Seiten nahtlos in eine vorhandene Website einpassen und kommen daher nicht ohne Navigationselemente und ein passendes Rahmenlayout aus.

SSP-Systeme automatisieren den gesamten Publikationsvorgang und binden die transformierten Dokumente in den passenden Publikationskontext ein. Forrest gibt hierfür ein gutes Beispiel: Jedes zu transformierende Dokument wird in den Kontext einer Website eingebunden und mit Kopf- und Fußbereich sowie Navigationselementen versehen. Den PDF-Dokumenten werden stattdessen Inhaltsverzeichnis und projektspezifische Fußzeilen hinzugefügt. Durch Änderungen der Systemkonfiguration können mehrere Dokumente in ein gemeinsames PDF-Dokument transformiert werden.

Noch flexibler arbeiten Daisy [13] und Lenya: Aus einem Repertoire aller Dokumente können beliebige Publikationen zusammengestellt und veröffentlicht werden. Auch das DITA-Toolkit [14] rekombiniert mit MAP-Files einmal vorgehaltene Inhalte frei in beliebige Publikationen.

Content-Management-Funktionen
Content Management, also die systematische Verwaltung von Inhalten, deren Beziehungen und Veränderungshistorie, ist ein wichtiger Aspekt jedes SSP-Systems. Nicht immer müssen diese Funktionen jedoch in das System integriert sein. Apache Forrest oder das DITA-Toolkit zeigen, wie auch komplexe Dokumentationsprojekte allein auf Basis des Dateisystems verwaltet werden können.

Das DITA-Toolkit ist hier konsequent und steckt alle relevanten Daten, auch die Beziehungen zwischen den Dokumenten, einfach und zukunftssicher in XML-Dateien mit standardisiertem Format. Das erleichtert Installation und Administration und macht das System für Laien transparenter.

Hybridsysteme wie Daisy gehen einen Mittelweg: Sie speichern die Daten zwar in einer relationalen Datenbank, bewahren darin jedoch nur klar strukturierte XML-Dokumente auf.

Andere, ebenfalls auf Apache Cocoon [15] aufsetzende Systeme und Wikis, zum Beispiel DokuWiki [16], scheinen zunächst datenbankgestützt zu arbeiten, speichern die Inhalte jedoch in einzelnen Dateien auf dem Dateisystem des Servers ab. Der Anwender muss sich also nicht mit der inneren Organisation des Systems auseinandersetzen, die Dateien können aber jederzeit im Original aus dem System exportiert werden.

Dennoch: Aufgaben wie Datensicherung, Datenexport oder Versionierung gestalten sich deutlich komplizierter, sobald Anwendungsserver und Datenbanken im Spiel sind. Ganz zu schweigen von den Schwierigkeiten, in einer Arbeitsgruppe über das Internet zusammenzuarbeiten oder das System offline mit dem Laptop zu nutzen. Für kleine Arbeitsgruppen oder die Zusammenarbeit im WAN lohnt sich daher der Blick auf dateisystembasierte Lösungen.

Komfortabel ist dagegen der Einsatz von Datenbank-Technologie für die Speicherung von Sekundärdaten wie Schlagwortverzeichnis oder Link-Listen. So kann schon während der Bearbeitung einer Seite auf fehlerhafte Querverweise hingewiesen werden. Systeme wie Daisy machen damit die Anlage von Querverweisen zum Kinderspiel und schneiden damit in den Komfortmerkmalen deutlich besser ab als das DITA-Toolkit oder Forrest.

Modularität von Inhalten
Im engen Zusammenhang mit dem internen Aufbau der Datenspeicherung steht die Modularität von Inhalten, insbesondere die Frage, auf welcher Ebene Inhalte (einfach) als Bausteine gespeichert und wiederverwendet werden können.
Bei Daisy ist das vorbildlich gelöst, jeder Inhalt kann wiederverwendet werden. Auch das DITA-Toolkit kennt Funktionen dafür. Oft jedoch bedarf es einiger Recherche, um herauszufinden, ob und wie die gewünschte Funktion in einem System genutzt werden kann.

Versionierung
Für die Arbeit an fortlaufenden Projekten ist die Versionierung zwingend, zumal „handgestrickte“ Lösungen für Arbeitsgruppen kaum noch sinnvoll einsetzbar sind. Daher sollte ein SSP-System grundsätzliche versionierbar sein, auch wenn es dazu nicht unbedingt selbst eine Lösung mitbringen muss. Hierfür bietet sich bei dateibasierten Systemen die Anwendung Subversion [17] an, ein vorzügliches Versionskontrollsystem aus der Softwareentwicklung. Es lässt sich für den Anfang rein lokal und ohne großen Aufwand installieren, bietet aber bei Bedarf die sichere und problemlose Zusammenarbeit von Gruppen über das Internet. Vor allem auch mit Teilnehmern, die nicht ständig online sind. Darüber hinaus ist es aufgrund seiner viel größeren Verbreitung deutlich zuverlässiger als so manches selbst gestrickte Versionierungssystem und deutlich einfacher als etwa CVS.

Flexibilität in den Arbeitsmodi
Integrierte Systeme wie Daisy bieten das Bearbeiten von Dokumenten oftmals nur online an. Das Dokument wird vom Server abgerufen, im Browser bearbeitet und dann an den Server zurückgeschickt. Das Ergebnis kann man gleich am Bildschirm betrachten. Wunderbar einfach, wenn man ständig Zugriff auf den Server hat. Aber wenig hilfreich, um etwa in der Bahn an einer Dokumentation zu arbeiten.

Das DITA-Toolkit geht den entgegengesetzten Weg. Alle Dokumente lassen sich als Dateien mit einem beliebigen Editor bearbeiten, die Transformation erfolgt durch einen Verarbeitungslauf (Stapelverarbeitung). Je nach Größe der Publikation dauert es eine Weile, bevor man das Ergebnis sichten kann. Für kleine Korrekturen ein lästiges Verfahren.

Dagegen profiliert sich Forrest mit einem eleganten Mittelweg: In seinem dynamischen Modus kann man ein geändertes Dokument in Sekundenschnelle erneut transformieren und im Kontext anzeigen lassen, zusätzlich kann mit dem statischen Modus, einer Stapelverarbeitung, jederzeit auch die ganze Publikation neu generiert werden.

Publikationswege
Ganz andere Fragen stellen sich bei Veröffentlichung der Publikation. Zwar können fast alle Systeme ein PDF-Dokument erzeugen, für die Online-Veröffentlichung im Web stellen sie jedoch oft besondere Anforderungen an den Server.

Viele Wikis erwarten einen Server mit Unterstützung von PHP und mySQL. Cocoon-basierende Systeme setzen im Hosting teure Anwendungsserver wie Apache Tomcat voraus.

Forrest, Lenya, Daisy und das DITA-Toolkit können dagegen eine Publikation auch als statische HTML-Seiten exportieren, die man auf jeden Webserver kostengünstig und mit hoher Performanz veröffentlichen kann. Die Veröffentlichung auf CD ist ohne Mehraufwand möglich.

Freigabe und Workflows
Ist Workflow-Unterstützung gefordert, etwa für die Prüfung von Dokumenten vor Veröffentlichung, ist dies mit Forrest oder dem DITA-Toolkit nur noch sehr eingeschränkt zu erreichen. Lenya und Daisy warten hier mit ausgefeilten Funktionalitäten auf.

Strategische Aspekte
Die Einführung eines neuen SSP-Systems ist immer mit erheblichen Kosten und Investitionen für Konfiguration des Systems sowie Ausbildung und Einarbeitung der Mitarbeiter verbunden. Die Zukunftssicherheit dieser Investitionen ist deshalb ein wichtiger Auswahlfaktor.

Vermeiden Sie die Festlegung auf ein Betriebssystem. Selbst wenn Ihre Welt heute nur aus Windows-Rechnern besteht, gibt es gute Gründe, auf einem plattformunabhängigen System zu bestehen. Das mussten unlängst viele Nutzer von Spezialsoftware feststellen. Die Anwendungen wollten auf dem neuen Windows Vista nicht mehr funktionieren.

Mit der Entscheidung für Open-Source-Software lösen Sie sich darüber hinaus auch aus der Herstellerbindung. Wichtiger aber ist es, Inhalte und Metadaten konsequent und durchgehend in herstellerunabhängigen XML-Formaten wie DocBook oder DITA aufzubereiten.

XML-Insellösungen wie Microsofts „Office Open XML“, deren Nutzung faktisch doch nur mit Microsoft Word möglich ist, sind keine Alternative. Hier spielt Offenheit nur eine untergeordnete Rolle, wenn es schlichtweg zu teuer ist, eine kompatible Software zu erstellen. Dagegen wird sich für praxiserprobte öffentliche Standards immer und zu vernünftigen Kosten eine Software finden, mit der Ihre Dokumente weiter genutzt werden können.

Open-Source-Besonderheiten
In einigen Punkten unterscheidet sich Open-Source-Software ganz grundlegend von proprietärer Software, und zwar durch die Community. Der Gemeinschaft von Entwicklern und Nutzern kommt in Open-Source-Projekten große Bedeutung zu. Als Nutzer von Open-Source-Software können Sie Einfluss auf die Entwicklung Ihrer Software nehmen oder diese durch Beauftragung von Weiterentwicklungen selbst vorantreiben.

Wer Open-Source-Projekte nur als Lieferanten billiger Software sieht und alle Verbesserungen für sich behält, wird allerdings in der Community auf wenig Unterstützung hoffen können. Und er verzichtet zudem auf die Unterstützung einer erfahrenen Entwicklergemeinde.

In fast allen Communities ist Englisch Standard. Anwender-Support wie auch Diskussionen zur Entwicklung eines Projektes setzen also ein Minimum an englischen Sprachkenntnissen voraus und natürlich die Bereitschaft, sie zu benutzen. Wen das abschreckt, der tut gut daran, Support-Vereinbarungen mit deutschsprachigen Mitgliedern einer Gemeinschaft zu schließen.

Auch ist es durchaus kein Tabu, Open-Source- und kommerzielle Systeme zu mischen. Denn nicht immer gibt es eine brauchbare Open-Source-Lösung für ein Problem. So macht zum Beispiel Forrest erst richtig Spaß, wenn der Anwender zur Textverarbeitung einen (kommerziellen) visuellen XML-Editor heranzieht.

Fazit
Das perfekte SSP-System, das alle Anwendungsfälle abdeckt, existiert auch im Open-Source-Bereich nicht. Dennoch bieten offene Systeme zu attraktiven Konditionen erweiterbare und zukunftssichere Lösungen, die sich für viele Anwendungsfälle in der Technischen Dokumentation eignen.

Links
[1] http://de.wikipedia.org/wiki/DocBook
[2] http://de.wikipedia.org/wiki/DITA
[3] http://forrest.apache.org/
[4] http://de.wikipedia.org/wiki/XML-Schema
[5] http://de.wikipedia.org/wiki/RELAX_NG
[6] www.oxygenxml.com/
[7] www.openoffice.org/
[8] www.altova.com/products/xmlspy/xml_editor.html
[9] www.xmlmind.com/xmleditor/
[10] http://de.wikipedia.org/wiki/Cascading_Style_Sheets
[11] http://lenya.apache.org/
[12] http://cvsdemo.bitfluxeditor.org/examples/inlineXHTML/index.html
[13] http://cocoondev.org/daisy/index.html
[14] http://dita-ot.sourceforge.net/
[15] http://cocoon.apache.org/
[16] http://wiki.splitbrain.org/wiki:dokuwiki
[17] http://subversion.tigris.org/

Autorenanschrift
Ferdinand Soethe
mail@soethe.net
www.soethe.net

Ferdinand Soethe berät als Software-Architekt bei Auswahl, Anpassung und Einführung komplexer Software-Systeme. Seit 1996 ist der Einsatz von SSP-Systemen für die Technische Dokumentation ein wichtiger Schwerpunkt seiner Arbeit. Der Autor ist Mitglied des Projektmanagement-Kommitees von Apache Forrest und hat es auf zahlreichen Vorträgen im In- und Ausland vorgestellt.