Einführung in die Erstellung und Publikation von DocBook-Dokumenten
Copyright © 2002, Lars Trieloff
| Versionsgeschichte | ||
|---|---|---|
| Version 1.0 | 14. November 2002 | LT |
|
Erste Vorstellung des Dokuments im Hasso-Plattner-Institut für Softwaresystemtechnik | ||
| Version 1.1 | 05. Juni 2003 | LT |
|
Hinzufügen des Hinweises auf DocMan und Beheben eines Fehlers, auf den ich von Jörg Schnur aufmerksam gemacht wurde. | ||
Zusammenfassung
Dieses Buch behandelt die Erstellung von DocBook-Dokumenten sowie die Umwandlung von DocBook in publikationsfähige Ausgabeformate.
DocBook.
Bei DocBook handelt es sich um eine XML/SGML-Sprache, die besonders geeignet ist, um technische Dokumentationen, aber auch andere Dokumente zu erstellen. DocBook ist frei, plattformunabhängig und leicht zu erlernen. Dokumente, die mit DocBook erstellt wurden, können leicht in viele Ausgabeformate umgewandelt werden.
Inhaltsverzeichnis
- Vorwort
- Hinweis in eigener Sache
- 1. Einführung in strukturierte Daten, XML und DocBook
- 2. Erstellung von DocBook-Dokumenten
- 3. Ausgabe von DocBook-Dokumenten in verschiedene Ausgabeformate
- 4. DocBook für Dokumentationen und Anderes
- Glossar
- Stichwortverzeichnis
- Bibliographie
Abbildungsverzeichnis
- 1.1. Screenshot von jEdit
- 1.2. Screenshot von XXE Standard Edition
- 1.3. Screenshot von Morphon
- 1.4. Screenshot von epcEdit
- 1.5. Screenshot von XMetaL 3.0
- 1.6. Screenshot von XMLSpy
- 1.7. Screenshot von Oxygen
- 1.8. Screenshot vom Collaborative Markup Editor
- 1.9. Screenshot von DocMan
- 2.1. Die Titelseite von DocBook: The Definite Guide
- 3.1. Verarbeitungsmöglichkeiten von DocBook
Tabellenverzeichnis
- 1.1. Übersicht über grundlegende XML-Entitäten
- 1.2. Umlaute in der DocBook-DTD
- 2.1. DNS-Tabelle
- 2.2. DNS-Tabelle
- 2.3. DNS-Tabelle
Beispiele
- 1.1. Ein XML-Element
- 1.2. Ein leeres XML-Element
- 1.3. Hallo Welt als XML-Dokument
- 1.4. Unzulässige Überlappung von Elementen
- 1.5. Zulässige Schachtelung von Elementen
- 1.6. Elemente mit Attributen
- 1.7. XML-Dokumentenkopf mit Verarbeitungsanweisungen
- 1.8. Externe Entities
- 1.9. Kommentare in XML
- 1.10. DTD-Deklaration für XHTML 1.0
- 1.11. Verkürzte DTD-Deklaration
- 1.12. Deklaration externer Entitäten
- 1.13. Namespace-Deklaration bei XHTML 1.0
- 1.14. XHTML 1.0 & MathML mit Namespace-Prefix
- 1.15. Ein modularisiertes XML-Dokument
- 1.16. Registrierung des XInclude-Namespaces
- 1.17. Einbindung externer Dateien
- 1.18. Benutzung von xmlto
- 1.19. Installation von eDE
- 2.1. Ein sehr kurzes Buch
- 2.2. Ein etwas längeres Buch
- 2.3. Ein sehr kurzer Artikel
- 2.4. Eine Sammlung zweier Bücher
- 2.5. Inhaltsverzeichnis für ein Kapitel
- 2.6. Ein explizites Tabellenverzeichnis
- 2.7. Ein Stichwortverzeichnis mit Einleitung
- 2.8. Markieren von Stichworten
- 2.9. Ein Kapitel mit eigenem Inhaltsverzeichnis
- 2.10. Ein Literaturverzeichnis mit rohen Einträgen
- 2.11. Ein Literaturverzeichnis mit vorgekochten Einträgen
- 2.12. explizite Schichtung von Abschnitten
- 2.13. implizite Schichtung von Abschnitten
- 2.14. Ein ganz gewöhnlicher Absatz
- 2.15. formalpara und simpara im Einsatz
- 2.16. Einfache Listen in allen Variationen
- 2.17. Angestrichene Liste
- 2.18. Geordnete Liste
- 2.19. Die Beneluxländer als unterteilte Liste
- 2.20. Variablenliste
- 2.21. Verschiedene Beispiele für Anmerkungen
- 2.22. Ein beispielhaftes Beispiel
- 2.23. Hallo Welt in HTML
- 2.24. Medien in verschiedenen Formaten
- 2.25. Abbildungen in der Praxis
- 2.26. Eine einfache Tabelle
- 2.27. Zeilenübergreifende Verbindung
- 2.28. Spaltenübergreifende Verbindungen
- 2.29. Ein kurzes Philosophisches FAQ
- 2.30. ein kurzes Zitat
- 2.31. Notiz eines Vorgangs
- 2.32. Fußnoten und Referenzen
- 2.33. Referenz auf einen Abschnitt
- 2.34. Verweis auf eine URL
- 2.35. Das Programm Hello World
- 2.36. Ein etwas längeres Programm
- 2.37. Und eine kurze Erklärung
- 2.38. Der Befehl cd
- 2.39. Ein Verzeichnisinhalt anzeigen
- 2.40. Einige GUI-Befehle
- 2.41. Profilierung eines Absatzes
- 3.1. Installation der Docbook-Extensions für Saxon
- 3.2. Auflösung von XInclude mit xmllint
- 3.3. Auflösung von XInclude mit XInclude Engine
- 3.4. Umwandlung von DocBook in HTML mit Saxon
- 3.5. Umwandlung von DocBook in XHTML mit Saxon
- 3.6. Umwandlung von Docbook in Windows Hilfe
- 3.7. Umwandlung von DocBook in Java Hilfe mit Saxon
- 3.8. Generierung von XSL:FO mit Saxon
- 3.9. Erstellung von PDF mit FOP
- 3.10. Erstellung von RTF mit XFC
- 3.11. Profilierung vom Saxon
- 4.1. Ein Simplified DocBook-Dokument
- 4.2. Ein Website-Layout
- 4.3. Eine einzelne Webseite
- 4.4. Erzeugung einer Website
- 4.5. Eine kurze Präsentation
- 4.6. Slides in PDF wandeln
- 4.7. Slides in HTML wandeln
- 4.8. Grafische Formeln in DocBook
- 4.9. XSL-Customization-Layer für XSL:FO
Gleichungen
- 4.1. Fermats Letzter Satz
Dieses Tutorium ist ursprünglich für ein studentisches Tutorium, welches ich im November und Dezember 2002 am Hasso-Plattner-Institut für Softwaresystemtechnik in Potsdam abgehalten habe, entstanden. Inzwischen hat es an Umfang etwas zugenommen und wird noch weitere Vertiefung im Bereich DTD- und XSL-Stylesheet-Anpassung erfahren.
Wenn Sie Fehler oder Unklarheiten berichtigt sehen möchten, so freue ich mich über jeden Hinweis in diese Richtung. Bitte senden Sie mir eine Email an <lars@trieloff.net>. Das gleiche gilt natürlich, wenn Sie Vorschläge haben, was dieses Tutorial inhaltlich noch enthalten soll.
Die jeweils aktuelle Version dieses Dokuments finden Sie auf meiner DocBook-Website neben aktuellen Links und Projekten rund um DocBook.
Andere Formate dieses Dokuments.
Dieses Dokument ist in den folgenden Formaten verfügbar:
Falls Sie in Ihrem Unternehmen DocBook einsetzen möchte, stehe ich Ihnen beratend zur Seite, um einführende Kurse in DocBook zu geben, um Ihnen beim Aufbau einer Verarbeitungskette für DocBook-Dokumente zu helfen und kann Änderungen und Anpassungen an den DocBook-Stylesheets und der DocBook DTD für Sie vornehmen.
Weiterhin kann ich für Sie auch Speziallösungen für DocBook programmieren. Senden Sie mir eine Email an <lars@trieloff.net>, damit ich Ihnen ein Angebot machen kann.
Inhaltsverzeichnis
DocBook existiert als SGML- und als XML-Format.
DocBook ist eine Sprache zur Erstellung technischer Dokumentationen. DocBook basiert auf der Strukturierung des Inhaltes, deshalb basiert DocBook ursprünglich auf SGML, aber es gibt in den neueren DocBook-Versionen auch eine XML-Variante. Dieses Tutorium wird sich ausschließlich mit der XML-Variante beschäftigen.
What you see is what you get vs. What you see is what you mean
DocBook verwendet einen Grundlegend anderen Ansatz zur Erstellung von Dokumenten als er von Textverarbeitungsprogrammen wie Microsoft Word oder OpenOffice.org Writer bekannt ist. Word oder Writer gehen davon aus, dass es nur eine vernünftige Repräsentation des Inhaltes eines Dokuments gibt - nämlich die Form, in der das fertige Dokument ausgedruckt erscheinen wird. Dieser Ansatz kommt genau dann zu kurz, wenn es mehrere Formen gibt, in denen das Dokument publiziert werden kann.
Weitere Gründe finden sich im DocBook Wiki.
Es gibt viele Gründe, DocBook zu nutzen, die wichtigsten seien hier aufgeführt. Diese Auflistung orientiert sich an der Auflistung WhyDocBook aus dem DocBook Wiki /DocBookWiki/.
Mit DocBook kann man verschiedenste Formen von Dokumenten erstellen wie: Hilfesysteme, Webseiten, Bücher, FAQs, Artikel, Studienmitschriften, Bedienungsanleitungen und andere Dokumente.
Mit den DocBook Stylesheets kann man DocBook-Dokumente in eine Vielzahl verschiedener Ausgabeformate wandeln wie HTML Seiten, PDF und PostScript Dokumente, Windows und Java-Hilfe, RTF-Dateien. Für die Umwandlung in diese Formate sind viele kommerzielle und kostenlose Programme verfügbar.
Weiterhin gibt einige freie Hilfsmittel, mit denen man andere Formate wie Unix man-Pages, HTML-Seiten, Javadoc, einfachen Text, OpenOffice.org Writer-Dateien in DocBook wandeln kann.
DocBook ist gut dokumentiert mit DocBook: The Definite Guide /Walsh2002/ in Englisch und Tutorien in sieben Sprachen[1].
DocBook ist weit verbreitet und gut getestet. DocBook wird von Firmen wie Sun, Microsoft, Hewlett-Packard, Novell, Caldera und Red Hat verwendet, sowie von Open-Source-Projekten wobei KDE, Gnome, FreeBSD, Debian, die Linux-Dokumentation und die Darwin-Dokumentation bei Apple nur die wichtigsten sind.
Auf den DocBook-Mailinglisten bekommt man schnell und kostenlos Support zu allen DocBook-verwandten Problemen
Wird seit über zehn Jahren aktiv entwickelt und ständig an die Bedürfnisse der Nutzer angepasst
Von Grund auf mit dem Ziel der Erweiterbarkeit und Anpassbarkeit entwickelt
DocBook hat eine über zehnjährige Geschichte
DocBook ist über zehn Jahre alt. Die Entwicklung begann 1991 als ein gemeinsames Projekt des O'Reilly-Verlages und von HaL Computer Systems. Mitte 1998 wurde es als Technisches Komitee in die Organization for the Advancement of Structured Information Standards (OASIS) aufgenommen.
DocBook wurde vom O'Reilly-Verlag entwickelt.
Die DocBook DTD wurde ursprünglich von HaL Computer Systems und O'Reilly & Associates um 1991 entworfen und implementiert . Es wurde primär entwickelt, um den Austausch von UNIX-Dokumentationen zu verbessern.
Als DocBook 1.1 veröffentlicht wurde, stieg die Verbreitung an und Novell und Digital hatten danach starken Einfluss auf die Gestaltung der Version 1.2.
1994 übernahm die Davenport Group offiziell die Pflege und Weiterentwicklung des Formats.
Erstmal Ausgabe auf Papier.
Unter der Davenport Group wuchs die Verbreitung von DocBook abermals und es wurden neue Felder und Zielgruppen erschlossen. DocBook unterstütze jetzt die direkte Verarbeitung mit SGML-Werkzeugen und erstmals auch die Publikation in gedruckter Form. Novell und Sun hatten als Hauptnutzer den größten Einfluss auf die DTD.
Versionswechsel kann Aufwärtskompatibilität brechen.
Um die Entwicklung zu steuern einigte man sich darauf, dass Versionssprünge „hinter dem Punkt“ zwar Elemente der DTD hinzufügen konnten, aber die Abwärtskompatibliltät nicht brechen dürfen. Versionssprünge „vor dem Punkt“ dürfen die Abwärtskompatibliltät brechen, diese Änderungen müssen aber in der vorhergehenden Version angekündigt worden sein und dürfen nicht häufiger als einmal jährlich auftreten.
DocBook 3.0 wurde 1997 vorgestellt. Zu dieser Zeit begannen de Diskussionen, ob man nicht eine XML-Version von DocBook erstellen sollte. 1998 wurde die Leitung der DocBook-Standardisierung an OASIS übertragen.
Ein Student sollte in der Lage sein, innerhalb von einer Woche einen XML-Parser zu schreiben.
XML-Dokumente sind einfache Text-Dateien, die nach einem bestimmten Schema geschrieben sind. Sie sind für Menschen und Maschinen leicht lesbar und editierbar.
Achtung
Ein XML-Parser darf nie versuchen, invalide Dokumente zu interpretieren.
In der XML-Spezifikation sind die grundlegenden Regeln für die Erstellung von XML-Dokumenten festgelegt. Ein Dokument, welches die dort beschriebenen Regeln erfüllt, bezeichnet man als wohlgeformt oder auch well-formed. Wohlgeformtheit ist die Voraussetzung, dass eine Maschine die Datei verarbeiten kann, in der XML-Spezifikation ist sogar festgehalten, dass ein XML-Parser auf keinen Fall versuchen darf, ein nicht wohlgeformtes Dokument zu reparieren oder die Fehler zu ignorieren.
Ein XML-Dokument besteht im wesentlichen aus Elementen, die Attribute haben können und textuelle Inhalte sowie wiederum Elemente enthalten können.
XML-Elemente bestehen aus einem öffnenden um einem schließenden Tag. Alles was innerhalb dieser Tags steht, wird als der Inhalt des Tags betrachtet. Öffnende Tags bestehen aus dem kleiner-als-Zeichen „<“, dem Namen des Elements und dem größer-als-Zeichen „>“. Schließende Tags bestehen aus dem kleiner-als-Zeichen „<“, einem Schrägstrich „/“, dem Namen des Elements und dem größer-als-Zeichen „>“.
Anmerkung
Elemente bestehen aus ein oder zwei Tags
Kurzschreibweise leerer Elemente
Die Schreibweise von leeren XML-Elementen, also Elementen, die weder Text noch andere Elemente enthalten kann abgekürzt werden, indem man statt öffnendem und schließendem Tag ein leeres Tag in folgenden Art und Weise schreibt: ein kleiner-als-Zeichen „<“, der Name des Elements, ein Schrägstrich „/“ und ein größer-als-Zeichen „>“.
Jedes XML-Dokument hat genau ein Root-Element
Jedes XML-Element hat ein Root- oder Wurzel-Element. Innerhalb dieses Root-Elements steht der gesamte Inhalt des Dokuments. Dokumente mit mehr als einem Root-Element sind nicht wohlgeformt.
Beispiel 1.3. Hallo Welt als XML-Dokument
<?xml version="1.0"?><gruss>Hallo Welt</gruss>
Dieses minimale XML-Dokument enthält außer den schon besprochenen Elementen und deren Inhalt in der ersten Zeile eine Verarbeitungsanweisung.
Elemente dürfen einander nicht überschneiden.
Im Gegensatz zu SGML müssen alle Elemente geschlossen werden und es ist nicht zulässig, dass zwei Elemente sich überlappen.
Beispiel 1.4. Unzulässige Überlappung von Elementen
<dokument>
<wichtig>
wichtig, aber nicht interessant
<interessant>
interessant und wichtig
</wichtig>
interessant, aber nicht wichtig
</interessant>
</dokument>
Im Gegensatz dazu ist eine Schachtelung von Elementen zulässig und zerstört nicht die Wohlgeformtheit des Dokuments.
Elemente können Attribute haben.
Attribute können Elementen zugeordnet werden. Ein Attribut hat einen Namen und einen Wert. Attribute werden in den Start-Tag eines Elements, nach dem Elementnamen und vor dem eventuellem Schrägstrich oder größer-als-Zeichen eingetragen. Sie bestehen aus dem Namen des Attributs einem Gleichheitszeichen „=“ und dem Wert des Attributs in Anführungszeichen. Attribute sind durch Leerzeichen, Tabstopps oder Zeilenumbrüche getrennt.
Beispiel 1.6. Elemente mit Attributen
<dokument>
<element attribute="value" />
<element number="2">
<otherelement attribute1="one" attribute2="two"/>
</element>
</dokument>
Attributnamen dürfen nur alphanumerische Zeichen, den Bindestrich und den Unterstrich enthalten.
Notwendigkeit erweiterter Bestandteile
Im Beispiel Hallo Welt als XML-Dokument wurde bereits eine Verarbeitungsinstruktion in der ersten Zeile verwendet und die Frage „Wie kann ich <, > oder " in XML darstellen, wenn diese Zeichen für Elemente und Attribute reserviert sind?“ führen und zur Erklärung erweiterter XML-Bestandteile.
Processing Instructions sind Anweisungen an den XML-Parser.
Verarbeitungsinstruktionen, englisch Processing Instructions werden genutzt, um direkt an den XML-Parser Anweisungen zu geben. Sie fügen dem Dokument keinen Inhalt im eigentlichen Sinne, sondern eher Anweisungen, wie mit dem Dokument umgegangen werden soll. Allgemein üblich sind Processing Instructions, um XML-Version[2] und Zeichenkodierung festzulegen sowie um CSS-Stylesheets zu verlinken.
Es gibt keine schließenden Processing Instructions
Verarbeitungsanweisungen funktionieren ähnlich wie beginnende Tags, nur dass nach dem kleiner-als-Zeichen und vor dem größer-als-Zeichen Fragezeichen stehen. Es gibt keine schließenden Verarbeitungsinstruktionen und sie beziehen sich auf den gesamten folgenden Inhalt.
Beispiel 1.7. XML-Dokumentenkopf mit Verarbeitungsanweisungen
<?xml version="1.0" encoding="iso8859-1"?>
<?xml-stylesheet href="mystyle.css" type="text/css"?> <html> ... </html>
In diesem Beispiel wird in der ersten Zeile festgelegt, dass das folgende Dokument gemäß der XML-Spezifikation 1.0 behandelt werden soll und dass der verwendete Zeichensatz iso-8859-1 ist. Wenn für ein Dokument kein encoding angegeben ist, so ist für XML UTF-8 der Standard.
In der zweiten Zeile wird das Dokument mit einem Cascading Stylesheet, welches in der Datei mystyle.css liegt verknüpft. Eine Software, die in der Lage ist, das XML-Dokument anzuzeigen, sollte die in dieser Datei festgelegten Formatierungsregeln anwenden.
Entities sind Umschreibungen von Inhalten.
Entities kann man als Makros oder Shortcuts für Inhalte in einem XML-Dokument sehen. Diese etwas abstrakte Erklärung können wir an einem einfachen Beispiel mit Leben füllen: Wie bereits angesprochen kann man die Zeichen <,>und " nicht ohne weiteres in XML-Dokumenten verwenden, da sie für Elemente und Attribute reserviert sind. Aus diesem Grunde wurden in der XML-Spezifikation Umschreibungen für das kleiner-als-Zeichen, das größer-als-Zeichen und einige andere Zeichen eingeführt. Wenn man diese Umschreibungen in seinem Dokument verwendet, behandelt der Parser sie nicht, als ob ein Element beginnen oder enden würde, sondern als ob dort ein echtes, wirkliches kleiner-als-Zeichen stünde.
Tabelle 1.1. Übersicht über grundlegende XML-Entitäten
| Zeichen | Umschreibung |
|---|---|
| Größer-als „>“ | |
| Kleiner-als „<“ | |
| Anführungszeichen „"“ | |
| Apostroph „'“ | |
| Ampersand „&“ | |
Mit Enititäten kann man Dokumente modularisieren.
Weiterhin erlauben Entities auch den Zugriff auf externe Dokumentteile. Wenn ein Fragment ein XML-Dokuments in einer anderen Datei ausgelagert ist, und in dem ursprünglichen Dokument eine Entität als Verweis auf diese Datei definiert ist und verwendet wird, so behandelt der XML-Parser das Dokument, als ob die betreffenden Zeichen wirklich in der Ursprungsdatei stünden.
Beispiel 1.8. Externe Entities
Wir haben eine Datei index.xml, in der definiert ist, dass die Entität &xml; eine Umschreibung für den Inhalt der Datei content.xml ist. Die Datei index.xml sieht folgendermaßen aus:
<?xml version="1.0"?>
<dokument>
&xml;
<gruss>
Hallo Welt
</gruss>
&xml;
</dokument>
Die Datei content.xml enthält folgenden Text:
<gruss>
Hallo mit XML
</gruss>
Der XML-Parser betrachtet das Dokument, welches in der Datei content.xml liegt als folgende textuelle Repräsentation:
<?xml version="1.0"?>
<dokument>
<gruss>
Hallo mit XML
<gruss>
<gruss>
Hallo Welt
</gruss>
<gruss>
Hallo mit XML
</gruss>
</dokument>
Es besteht noch die Möglichkeit, dass externe Entitäten vom XML-Parser nicht geparst werden, doch das spielt in diesem Tutorium erst einmal keine Rolle.
Die deutschen Umlaute können über Entities verwendet werden.
Außerdem können in DTDs auch Entities für beliebige Zeichen definiert werden, was sich anbietet für Zeichen, die unter Umständen nicht auf jeder Tastatur getippt werden können, wie Umlaute oder Kyrillische Buchstaben oder Griechische Buchstaben. In der DocBook-DTD sind hunderte dieser Zeichen als Entities definiert. Dies ist insbesondere dann wichtig, wenn die Zeichenkodierung des Dokuments dieses Zeichen nicht unterstützt.
Kommentare werden vom XML-Parser ignoriert.
Kommentare werden in XML in der folgenden Art und Weise eingegeben: Vor dem Kommentar erscheint ein kleiner-als-Zeichen, ein Ausrufezeichen, dann zwei Bindestriche[3], dann der Inhalt des Kommentars, der sich auch über mehrere Zeilen erstrecken kann. Zum Abschluss des Kommentars erneut zwei Bindestriche und ein größer-als-Zeichen.
XML als Meta-Sprache beschreibt nur die Syntax, nicht die Semantik
Im vorhergegangen Abschnitt haben wir die grundlegenden Eigenschaften von XML-Dokumenten geklärt. Jedoch geben diese noch keine Auskunft darüber, was mit den Element- und Attributnamen gemeint ist und in welcher Anordnung sie welchen Sinn ergeben. XML ist eine Meta-Sprache und deshalb lässt sich aus einem XML-Dokument allein noch keine Bedeutung ableiten.
In dem Moment, in dem man zu XML Dokumenten eine Interpretationsanweisung hinzufügt, spricht man von einer XML-Applikation. Beispiele für XML-Applikationen sind XHTML, WML oder WSDL.
Eine formale Beschreibung der Regeln ist notwendig, um Dokumente auf Richtigkeit zu überprüfen.
Um zu überprüfen, ob ein XML-Dokument gemäß einer Interpretationsanweisung interpretiert werden kann, also ob es den Annahmen genügt, die in der Interpretationsanweisung über das Dokument gemacht werden, besteht die Möglichkeit, XML-Dokumenten eine formale Inhaltsbeschreibung zu zuordnen.
Für XML gibt es mehrere Varianten diese formale Inhaltsbeschreibung zu spezifizieren.
Möglichkeiten zur Spezifikation von XML-Applikationen
DTD bedeutet Doctype Definition und ist eine SGML-Anwendung zur Definition von SGML- und XML-Applikationen. Die XML-Applikation DocBook wird offiziell mit einer DTD beschrieben, wobei inoffiziell aber auch andere Beschreibungen unterhalten werden.
XML-Schema sind eine XML-Applikation zur Definition von XML-Applikationen. Der Vorteil gegenüber DTDs liegt darin, dass sie reine XML-Anwendungen sind und keine SGML-Bestandteile nutzen. XML-Schema sind vom World Wide Web Consortium (W3C) standardisiert, aber noch nicht in dem Maße verbreitet wie DTDs.
Relax-Schema, Trex-Schema, Schematron-Schema.
Diese Schema-Applikationen entstanden etwa zur gleichen Zeit wie XML-Schema mit der gleichen Zielsetzung. Auch von diesen Schemata gibt es Spezifikationen für DocBook, jedoch sind sie noch weniger weit verbreitet als XML-Schema.
Damit die Gültigkeit ihres Dokuments automatisch überprüft werden kann, müssen Sie dem validierenden Parser mitteilen, dass das aktuelle Dokument nach den Regeln einer bestimmten DTD geparst werden soll. Diese Mitteilung erfolgt, indem der Dokumententyp des Dokuments deklariert wird.
Die Deklaration des Dokumententyps erfolgt hinter der XML-Deklaration (XML-Verarbeitungsanweisung). Sie kann in der vollständigen oder in der verkürzten Form erfolgen:
Die vollständige Deklaration.
Die DTD-Deklaration ist wichtig, um die Gültigkeit des Dokuments zu prüfen
besteht aus einer Abfolge des kleiner-als-Zeichens, eines Ausrufezeichens, des in Großbuchstaben geschriebenen Schlüsselwortes DOCTYPE, einem Leerzeichen gefolgt von dem Elementnamen des Root-Elements. Wiederum nach einem Leerzeichen folgt das in Großbuchstaben geschriebene Schlüsselwort PUBLIC und in Anführungszeichen die öffentliche Identifizierung der DTD, die so genannte Public ID. Getrennt durch ein Leerzeichen oder einen Zeilenumbruch folgt die interne Identifizierung der DTD, die so genannte System ID als absolute URL oder als relativer Pfadname der Datei, in der die DTD liegt. Die Deklaration wird abgeschlossen mit den größer-als-Zeichen.
Beispiel 1.10. DTD-Deklaration für XHTML 1.0
<?xml version="1.0 "encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
In diesem Beispiel wurde die DTD über die absolute Adresse angesprochen. Adressen von Dokumenten, die nicht über das Internet, sondern von der Festplatte oder einem Netzwerklaufwerk geladen werden sollen, beginnen mit file://.
Die verkürzte Deklaration.
Warnung
Die Public ID darf in XML weggelassen werden, die System ID jedoch nicht. Für SGML-Dokumente reicht auch die Public ID oder die System ID.
bietet sich immer dann an, wenn einem die Public ID nicht bekannt ist, oder es keinen öffentliche Identifizierung gibt. In diesem Falle ist die Deklaration bis zum Schlüsselwort DOCTYPE identisch, also kleiner-als-Zeichen, Ausrufezeichen, Schlüsselwort DOCTYPE, Leerzeichen. Doch dann folgt das Schlüsselwort SYSTEM, um das Folgen der internen Identifizierung anzukündigen. Dahinter kommt die URL oder der relative Pfad der DTD (in Anführungszeichen) und zum Abschluss das größer-als-Zeichen.
Beispiel 1.11. Verkürzte DTD-Deklaration
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dokument SYSTEM
"../dtds/meinedtd.dtd">
Hier wird die Lage der DTD durch einen relativen Pfad angegeben. Wenn allerdings die XML-Datei verschoben wird, muss die DTD mit verschoben werden oder die Deklaration geändert werden.
Über die DTD-Deklaration kann man externe Entitäten einbinden, um Dokumente zu modularisieren.
Im Abschnitt Externe Entities haben wir bereits besprochen, dass man mit externen Entitäten die Inhalte anderer Dateien in das Dokument einbinden kann. Jetzt soll gezeigt werden, wie man solche externen Entitäten definieren kann, denn dieser Schritt kann uns bei der Modularisierung von großen Dokumenten behilflich sein.
Um externe Entities zu definieren, fügen wir vor dem größer-als-Zeichen der Doctype-Deklaration, also nach der System ID öffnende und schließende eckige Klammern „[]“ ein, in die wir die nötigen Befehle schreiben. Für jede Entity muss dann folgender Code eingegeben werden: kleiner-als-Zeichen und Ausrufezeichen, um das SGML-Schlüsselwort anzukündigen, das Schlüsselwort ENTITY, nach einem Leerzeichen der Name der Entität, also das, was im Dokument zwischen Ampersand und Semikolon verwendet wird. Es folgt wie bei der Dokumententyp-Deklaration das Schlüsselwort SYSTEM und die System ID, also die Adresse der Datei, auf welche die Entity verweisen soll. Am Ende wird das Konstrukt mit dem größer-als-Zeichen abgeschlossen.
Beispiel 1.12. Deklaration externer Entitäten
Damit können wir das Beispiel Externe Entities so vervollständigen, dass die besprochene Entität &xml; wirklich deklariert wird.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dokument SYSTEM
"../dtds/meinedtd.dtd" [
<!ENTITY xml SYSTEM "content.xml">
]>
<dokument>
&xml;
<gruss>
Hallo Welt
</gruss>
&xml;
</dokument>
Namespaces erlauben das gleichzeitige Verwenden zweier XML-Applikationen.
Bei den XML-Namespaces handelt es sich um eine Technologie, mit der man verschiedene XML-Anwendungen in einem XML-Dokument kombinieren kann. Ein gutes Beispiel dafür ist die Kombination von MathML in XHTML. Dann kann ein geeigneter Browser mathematische Formeln auf einer Website anzeigen.
URLs können Ressourcen eindeutig beschreiben
Um dies zu ermöglichen, und um eventuelle Unklarheiten zu beseitigen, wenn in zwei verwendeten XML-Anwendungen die gleichen Elementnamen verwendet werden, wird jedem der XML-Applikationen eine eindeutige Identifikation in Form einer URL zugeordnet. Diese URL nennt man auch den Namespace. Diese URL können, aber müssen nicht Informationen zur jeweiligen XML-Anwendung enthalten, entscheidend ist es, dass die Anwendung eindeutig bestimmt ist.
Mit xmlns wird der Namespace definiert
Einem Element wird ein Namensraum zugeordnet, indem man das reservierte Attribut xmlns einfügt und als Wert den Namespace der XML-Applikation angibt. Alle Elemente unterhalb des Elements mit dem definierten Namespace haben jetzt diesen Namespace, bis ein untergeordnetes Element einen anderen Namespace definiert.
Beispiel 1.13. Namespace-Deklaration bei XHTML 1.0
<?xml version="1.0" encoding="UTF-8"?>
<html
xmlns="http://www.w3.org/1999/xhtml"
lang="en"
xml:lang="en">
<head>
<title>
MathML's Hello Square
</title>
</head>
<body>
<p>
This is a perfect square:
</p>
<math
xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<msup>
<mfenced>
<mrow>
<mi>a</mi>
<mo>+</mo>
<mi>b</mi>
</mrow>
</mfenced>
<mn>2</mn>
</msup>
</mrow>
</math>
</body>
</html>
In diesem Beispiel wird im Root-Element definiert, dass es sich um eine HTML-Datei handelt und im math-Element wird festgelegt, dass alle Elemente unterhalb MathML-Elemente sind.
Wenn nichts weiteres angegeben ist, haben alle Elemente den Default-Namespace
Damit kommt man zum Begriff des Default-Namespace (Standard-Namensraum). Dieser wird im Root-Element des Dokuments festgelegt. Außerdem kann man im Root-Element auch so genannte Namespace-Prefixes definieren. Namespace-Prefixes erlauben es, Elemente aus mehreren Namespaces zu verwenden, ohne jedes mal den Namespace mit den Attribut xmlns anzugeben.
Definition und Einsatz von Namespace-Prefixes.
Die Verwendung von Namespaces wird durch Namespace-Prefixes erleichtert
Ein Namespace-Prefix wird definiert, indem im Root-Element des Dokuments ein Attribut der Form xmlns, Doppelpunkt, Name des Prefixes mit der gewünschten Namespace-URL als Wert des Attributs. Der Namespace-Prefix wird verwendet, indem für jedes Element, welches sich in diesem Namespace befinden soll vor den Elementnamen der Namespace-Prefix, durch einen Doppelpunkt getrennt geschrieben wird.
Beispiel 1.14. XHTML 1.0 & MathML mit Namespace-Prefix
Damit kann ich das vorhergehende Beispiel durch die Verwendung des Namespace-Prefixes mm abkürzen:
<?xml version="1.0" encoding="UTF-8"?>
<html
xmlns="http://www.w3.org/1999/xhtml"
xmlns:mml="http://www.w3.org/1998/Math/MathML"
lang="en"
xml:lang="en">
<head>
<title>MathML's Hello Square</title>
</head>
<body>
<p>
This is a perfect square:
</p>
<mml:math>
<mml:mrow>
<mml:msup>
<mml:mfenced>
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mo>+</mml:mo>
<mml:mi>b</mml:mi>
</mml:mrow>
</mml:mfenced>
<mml:mn>2</mml:mn>
</mml:msup>
</mml:mrow>
</mml:math>
</body>
</html>
XSLT wandelt XML in XML, HTML oder Text
XSLT bedeutet Extensible Stylesheet Language for Transformation, es ist also eine XML-basierende erweiterbare Sprache, mit der man XML umwandeln kann. Mit XSLT kann man eine XML-Datei direkt in eine andere XML-Datei umwandeln, oder in ein HTML-Dokument oder in ein Nur-Text Dokument.
XSL:FO ist eine Sprache zur Formatierung von Druckerzeugnissen
Um die Umwandlung in druckbare Formate wie PDF oder RTF zu ermöglichen, wurde die Sprache XSL:FO eingeführt, das steht für Extensible Stylesheet Language Formating Objects und ist eine Möglichkeit, das genaue Aussehen von druckbaren Dokumenten festzulegen.
An dieser Stelle will ich nicht genauer auf XSLT eingehen, da eine Erläuterung der Funktionsweise und Möglichkeiten den Rahmen dieses Tutoriums sprengen würde. Es bleibt festzuhalten, dass die Umwandlungen von DocBook in andere Formate über XSLT realisiert wird.
Wenn mehrere Personen an einem Dokument arbeiten, sollte man es modularisieren
Insbesondere für umfangreiche, von Menschen geschriebene Dokumente, wie es DocBook-Dokumente sind, bietet es sich an, die Inhalte auf mehrere Dateien aufzuspalten, um dann mit den einzelnen Dateien zu arbeiten. In den kleineren Teildokumenten findet man sich besser zurecht und es ist möglich, dass mehrere Personen an einem Dokument arbeiten.
Um XML-Dokumente zu Modularisieren gibt es im wesentlichen zwei Möglichkeiten. Zum ersten die bereits angesprochenen externen Entitäten und zum zweiten eine neuere Technologie namens XInclude.
Vorgehensweise.
Die einzelnen Module des Dokuments werden als XML-Dateien ohne XML-Deklaration und Dokumententyp-Deklaration erstellt und bearbeitet. In der Hauptdatei werden die einzelnen Teile als externe Entities deklariert und eingebunden. Der XML-Parser behandelt die Hauptdatei wie ein Dokument.
Vorteile von externen Entities
Das Vorgehen ist SGML-kompatibel und wird von jedem XML-Parser unterstützt
Nachteile von externen Entities
die Teildokumente können nicht validiert werden
es ist keine mehrfache Schachtelung von Modulen möglich
Beispiel 1.15. Ein modularisiertes XML-Dokument
Beim folgenden Dokument handelt es sich um ein Buch mit mehreren Kapiteln. Die Kapitel sind in die Dateien kapitel1.xml, kapitel2.xml, kapitel3.xml, nachwort.xml ausgelagert. Die Hauptdatei sieht folgendermaßen aus:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE buch SYSTEM "buch.dtd" [
<!ENTITY einleitung SYSTEM "kapitel1.xml">
<!ENTITY zweiterakt SYSTEM "kapitel2.xml">
<!ENTITY dritterakt SYSTEM "kapitel3.xml">
<!ENTITY nachwort SYSTEM "nachwort.xml">
]>
<buch>
&einleitung;
&zweiterakt;
&dritterakt;
&nachwort;
</buch>
Die Standardisierung von XInlude ist noch nicht abgeschlossen
XInclude ist ein XML-Standard, mit dem man XML-Dokumente oder Teile von XML-Dokumenten in andere Dokumente einbinden kann. In diesem Abschnitt wird nur erklärt, wie man komplette Dokumente einbindet, da man für das Einbinden von Dokumentteilen die Technologien XPath und XPointer erläutern müsste, und da das Einbinden von Dokumentteilen für die Modularisierung von DocBook-Texten nicht unbedingt erforderlich ist.
Vorgehensweise.
XInclude nutzt den Namespace http://www.w3.org/2001/XInclude. Um XInclude in einem Dokument zu nutzen, muss man diesen Namespace entweder für jedes XInclude-Element oder als Namespace-Prefix registrieren.
Beispiel 1.16. Registrierung des XInclude-Namespaces
<?xml version="1.0" encoding="UTF-8"?>
<buch
xmlns:xinclude="http://www.w3.org/2001/XInclude">
</buch>
Danach kann man externe Dateien über das Element include einbinden. Als einziger Parameter ist href interessant, er gibt die URL oder den relativen Pfad der einzufügenden Datei an.
Beispiel 1.17. Einbindung externer Dateien
Damit kann man das Beispiel Ein modularisiertes XML-Dokument wie folgt anpassen:
<?xml version="1.0" encoding="UTF-8"?>
<buch
xmlns:xinclude="http://www.w3.org/2001/XInclude">
<xinclude:include href="kapitel1.xml" />
<xinclude:include href="kapitel2.xml" />
<xinclude:include href="kapitel3.xml" />
<xinclude:include href="nachwort.xml" />
</buch>
Vorteile von XInclude
XML-basierte Anwendung, leichter zugänglich
Dokumente können beliebig tief geschachtelt werden
Teildokumente können einzeln validiert werden
Nachteile von XInclude
Vorgang der Standardisierung ist noch nicht abgeschlossen
Nicht alle Tools unterstützen XInclude
Weitere Informationen zur Verarbeitung von XInclude gibt es später im Abschnitt: Verarbeitung von XInclude.
Für DocBook gibt es viele freie und kommerzielle Hilfsprogramme
Um DocBook zu erstellen, zu bearbeiten und zu veröffentlichen, benötigen Sie eine Reihe von Programmen. In diesem Tutorium werde ich insbesondere auf die Tools eingehen, die frei verfügbar sind und unter den wichtigsten Betriebssystemen laufen. Wenn es spezielle Tools nur für eine bestimmte Plattform gibt, so wird auch nur in dem für sie bestimmten Profil darauf eingegangen.
Aus Benutzersicht sind drei Arten von Programmen von Interesse: Programme, die einem beim Erstellen von DocBook behilflich sind, die DocBook-Editoren, Programme, die einem beim Publizieren von DocBook behilflich sind, also Transformationswerkzeuge und Programme, die den Arbeitsablauf vereinfachen, Workflow-Tools. Weiterhin wichtig sind die verschiedenen XML-Parser, sie spielen aus Benutzerperspektive aber eine untergeordnete Rolle.
Xerces ist der featurereichste Java-XML-Parser
Der Apache Xerces-J ist eine Weiterentwicklung des IBM XML4J-Parsers. Er ist in Java geschrieben und hat einen sehr hohen Funktionsumfang. Er kann nach DTDs und XML-Schema validieren, XSLT-Transformationen durchführen und ist der am weitesten verbreitete und umfangreichste XML-Parser für Java.
Xerces-J kann auf den XML-Seiten der Apache Software Foundation heruntergeladen werden. Da Xerces kein XInclude unterstützt, bietet es sich an, sich von Sourceforge das Zusatzprogramm XIncluder herunterzuladen, um XIncludes verarbeiten zu können.
LibXML2 ist auf fast jedem Linux-System installiert
Bei LibXML handelt es sich um einen sehr schellen, in C geschriebenen XML-Parser, der für Unix, Linux und Cygwin verfügbar ist. LibXML2 kann XIncludes verarbeiten. LibXML2 wurde ursprünglich für das Gnome-Projekt geschrieben, aber bei xmlsoft.org ist eine Einzel-Version erhältlich.
Es gibt verschiedene Versionen von MSXML, der Upgrade auf die letzte Version lohnt sich
Microsoft MSXML ist der schnellste XML-Parser für die Windows-Betriebssysteme. Da mittlerweile vier verschiedene Versionen des MSXML-Parsers verfügbar sind und je nach Betriebssystemversion und Version des installieren Microsoft Internet Explorer eine andere Version auf dem System installiert ist, empfiehlt es sich, von Microsoft die aktuelle Version herunterzuladen.
Für MSXML gibt es von Frank Wessels eine Erweiterung, die XInclude-Support hinzufügt. Diese Erweiterung kann man von codeproject.com herunterladen.
Ich stelle in diesem Abschnitt nur XML-Editoren vor, von denen es eine kostenlose Testversion gibt, oder die man völlig frei nutzen kann. Wer hier ein kommerzielle Produkt vermisst, kann mir gerne eine Testversion verschaffen, damit ich sie hier aufnehmen kann.
Für erfahrene Emacs-Benutzer
Dies ist ein besonderer Modus für den Text-Editor Emacs. Da dieser Text-Editor selbst eine gewisse Eingewöhnungszeit erfordert, habe ich darauf verzichtet, diese Kombination zu testen. Die PSGML-Erweiterung erleichtert die Arbeit mit SGML-Dokumenten. So kann Sie DTDs und Entitäten verwalten, automatisch Zeichen in die entsprechenden Entities umwandeln und Elemente vervollständigen. Wer bereits den Emacs nutzt, wird mit diesem Paket sicher gut bedient sein.
Emacs und PSGML sind GPL-Software und in fast jeder Linux-Distribution enthalten. Wenn nicht, kann man das PSGML-Paket hier herunterladen.
jEdit ist ein Texteditor, der sich über Plugins gut erweitern lässt
JEdit ist ein Java-basierter Text-Editor, der über ein gut konfigurierbares Syntaxhighlighting verfügt. Er lässt sich über Plugins erweitern. Das XML-Plugin erlaubt es, sich einen DOM-Baum des XML-Dokuments anzeigen zu lassen, Zeichen in Entitäten und zurück zu wandeln und Dokumente zu validieren. Auf Wunsch kann jEdit geöffnete Tags wieder schließen und eine Liste der möglichen Elemente und Attribute, die man in ein Element einfügen kann anzeigen.
Mit dem XSLT-Plugin lassen sich XML-Dateien mit XSL-Stylesheets transformieren und das Konsolen-Plugin erlaubt es, von jEdit aus DocBook-Tools auszuführen, die auf der Kommandozeile arbeiten.
JEdit ist ebenfalls freie Software und kann unter der URL http://www.jedit.org heruntergeladen werden. JEdit unterstützt das Herunterladen und Installieren von Plugins über den integrierten Plugin-Manager.
XXE bietet keine Source-Ansicht
XMLmind XXE ist ein reiner WYSIWYG-Editor. Er unterstützt keine Source-Code-Ansicht und erlaubt es auch nicht, direkten Einfluss auf die physische Struktur des Dokuments zu nehmen. Man kann also Elemente einfügen und Attribute bearbeiten und sieht eine mögliche grafische Repräsentation des Inhalts, in der jedoch auch Meta-Daten angezeigt werden.
Wenn man die DocBook-Elemente kennt und die nötigen Tastatur-Shortcuts sich eingeprägt hat, erlaubt XXE ein sehr schnelles Arbeiten, zumal für bestimmte Aufgaben, die schwierigere Elementkonstrukte erfordern bereits Vorlagen eingebaut sind. Die CSS-Regeln zur Formatierung des Inhaltes kann man ändern, der Editor validiert und meldet Fehler und ist sehr gut geeignet, wenn man nicht direkt Einfluss auf die Struktur des Dokuments nehmen möchte.
Unter der URL http://www.xmlmind.com/xmleditor kann man die XMLmind XXE Standard Edition kostenlos herunterladen und für 200 US$ die Professional-Version kaufen. Die Professional-Version kommt mit allen Programmquellen und erlaubt es Anpassungen vorzunehmen. Außerdem werden alle neuen Features nur in der Professional-Version implementiert.
Der Morphon XML-Editor ist in Java geschrieben und funktioniert auf allen Betriebssystemen, für die es eine Java Virtual Machine gibt. Er basiert auch einer CSS-Engine, die das XML-Dokument dem Nutzer präsentiert. So gibt es verschiedene Ansichten: zum ersten die Code-Ansicht, dann eine Ansicht als Nur-Text mit ausgeblendeten Elementen und eine Variante, in der die Schachtelung der Elemente deutlich wird.
In einer Seitenleiste kann der DOM-Baum des Dokumentes angezeigt werden und es ist möglich, XPath-Abfragen abzusetzen. Weiterhin kann man sich eine Vorschau für XSLT-Transformationen anzeigen lassen. Rechtschreibprüfung des XML-Dokuments ist ebenfalls möglich.
Von Morphon gibt es unter http://www.morphon.com eine 30-Tage-Testversion zum Download und man kann für 150 US$ die Ein-Benutzer-Variante und für 75 US$ die Studentenversion kaufen.
Der epcEdit-XML-Editor ist in Tcl/Tk geschrieben und läuft daher auf den meisten Betriebssystemen. Er unterstützt das Bearbeiten eines Dokuments im Source-Code und in einer Ansicht, in der die XML-Elemente durch grafische Pfeile repräsentiert werden.
Die Struktur des XML-Dokuments wird in einer Baumstruktur angezeigt und epcEdit kann XML-Dateien validieren, allerdings nicht direkt von einer DTD aus, sondern es muss für jede DTD erst ein Template erzeugt werden. epcEdit kann mit dem Programm GNU Aspell, welches nicht im Lieferumfang enthalten ist auch die Rechtschreibung des Dokuments überprüfen.
Man kann epcEdit von der Website http://www.epcedit.com herunterladen und 60 Tage testen. Die Vollversion kostet etwa 350 €, für Studenten gibt es eine ermäßigte Version zum Preis von 100 €.
Corel XMetaL ist für die Verarbeitung von DocBook sehr gut geeignet
XMetaL ist eine komplette XML-Entwicklungsumgebung mit Fokus auf die Erstellung von XML-Dokumenten durch Menschen, was sich auch im Preis von fast 500 US$ widerspiegelt. Dafür unterstützt XMetaL aber so jedes Feature, welches man sich vorstellen kann.
Es gibt vier verschiedene Ansichten eines Dokuments. Zuerst die Source-Ansicht mit Syntax-Highlighting, als zweites eine CSS-gestylte Ansicht, die einerseits leicht konfigurierbar ist, und andererseits das Dokument in einer Art What You See Is What You Get-Ansicht darstellt. Zu dieser Ansicht kann man die Tags einblenden lassen wie beim epcEdit und als viertes gibt es eine Vorschau der XSLT-Transformation.
Bei Corel kann das Programm gekauft und für eine 30-Tage-Testversion heruntergeladen werden.
XMLSpy ist ebenfalls eine komplette XML-Entwicklungsumgebung, aber mit dem Fokus auf Maschinen-generierten XML-Code. So enthält das Programm neben dem eigentlichen Editor noch Tools zur Erstellung von XSLT-Stylesheets oder zum Entwickeln von Webservices.
XMLSpy bietet einen Enhanced Grid View
Das Besondere an XMLSpy ist die so genannte Enhanced Grid View-Ansicht. Dabei werden XML-Dokumente als geschachtelte Tabellen dargestellt. Diese Darstellung ist für DocBook nicht ideal. Außerdem gibt es eine Source-Code-Ansicht und eine Authentic View genannte Ansicht, in der die XML-Dateien per XSLT transformiert werden, aber trotzdem editierbar bleiben. XMLSpy validiert Dokumente und kann auf Knopfdruck XSLT-Transformationen starten.
Ein Feature, welches sich als besonders hilfreich beim Arbeiten mit Dateien, die über externe Entitäten modularisiert werden gezeigt hat, soll nicht unerwähnt bleiben. XMLSpy erlaubt es, dass Dateien auch dann validiert werden, wenn ihnen keine DTD zugewiesen wird.
XMLSpy kann bei Altova als 30-Tage-Testversion heruntergeladen werden und gekauft werden. Der Preis variiert je nach Ausstattung zwischen 100 und 1200 €.
Oxygen ist ein kommerzieller Text-Editor
Oxygen ist sicherlich eines der schlankeren XML-Tools. Es besteht im wesentlichen aus einem Quellcode-Editor mit Syntaxhighlighting und der Möglichkeit Dokumente zu validieren und in andere Formate umzuwandeln. Ein Pluspunkt ist der niedrige Preis von 25 US$ für Studenten und 65 US$ für die Professional-Version.
Wenn man denn möchte, kann man unter http://www.oxygenxml.com/ eine 30-Tage-Testversion herunterladen oder das Produkt kaufen.
Der Topology Collaborative Markup Editor legt das Hauptaugenmerk auf die Zusammenarbeit bei großen Dokumenten. Er erlaubt es, Abschnitte des Dokuments verschieden einzufärben, um auf Änderungen oder Wünsche hinzuweisen. Die XML-Features sind nicht besonders weit fortgeschritten, man kann validieren und Konversionen von verschiedenen Kodierungen nach Unicode vornehmen lassen.
Der XML-Editor unterstützt Syntax-Highlighting und hat ein sehr buntes User-Interface. Bei http://www.topologi.com gibt es einen 30-Tage-Testdownload und die Vollversion zum Preis von 62 € kaufen.
MSXML ist sehr schnell, unterstützt aber nicht alle DocBook-Features
Der bereits oben erwähnte (siehe Microsoft MSXML) MSXML-Parser ist auch ein XSL-Transformationswerkzeug. Vorteilhaft ist seine Geschwindigkeit, nachteilig ist, dass er weder das Aufsplitten der Ausgabe in mehrere Dokumente noch die in Java geschriebenen DocBook-Erweiterungen für XSLT unterstützt.
LibXSLT funktioniert auch unter Cygwin
Die zu LibXML2gehörende XSLT-Engine nennt sich LibXSLT und ist ebenfalls für Unix, Linux und Cygwin verfügbar. Sie ist in C geschrieben, weshalb sich die DocBook-Erweiterungen nicht verwenden lassen. Andererseits ist die Umwandlung sehr schnell.
LibXSLT kann ebenfalls von xmlsoft.org heruntergeladen werden. Der zugehörige UNIX-Befehl lautet xsltproc und unterstützt das Aufsplitten der Ausgabe in mehrere Dokumente.
Xalan hat Probleme mit den aktuellen DocBook-XSL-Stylesheets
Die Apache Software Foundation stellt mit Xerces nicht nur einen XML-Parser bereit sondern auch den XSLT-Prozessor Xalan, der auf Xerces aufsetzt. Xalan unterstützt das Aufsplitten der Ausgabe in mehrere Dateien und den Einsatz der DocBook-Erweiterungen. Da das Programm in Java geschrieben ist, ist es auf fast allen Plattformen verfügbar, aber etwas langsamer als in C geschriebene Programme.
Xalan lässt sich ebenfalls von den XML-Seiten der Apache Software Foundation herunterladen, hat aber unter Umständen Probleme bei der Verarbeitung von DocBook-Dokumenten.
Saxon ist für DocBook sehr gut geeignet
Der zuverlässigste Java-basierte XSLT-Prozessor ist Saxon von Michael Kay. Er unterstützt die Ausgabe in mehrere Dateien und lässt sich um die DocBook-Erweiterungen erweitern. Er ist in der Umwandlung von DocBook-Dokumenten wesentlich stabiler als Xalan.
Saxon kann man von Sourceforge in verschiedenen Versionen herunterladen. Zum empfehlen ist die letzte Version mit der Hauptversionsnummer 6, da die Hauptversionsnummer 7 sich mit der experimentellen Umsetzung der Standards XSLT 2.0 und XPath 2.0 beschäftigt.
Formatting Objects-Prozessoren wandeln XSL:FO-Dateien in PDF, PostScript, RTF oder andere Formate, deren Zielausgabe das gedruckte Dokument ist.
PassiveTeX hat Probleme mit den aktuellen DocBook-XSL-Stylesheets
PassiveTeX ist ein Satz von TeX-Makros, die genutzt werden können, um XSL:FO-Dokumente in TeX und dann in die TeX-Ausgabeformate PostScript, DVI und PDF wandeln kann. PassiveTeX ist verhältnismäßig schwierig zu installieren, wenn man keine Erfahrung mit TeX hat, kann allerdings mathematische Formeln hervorragend darstellen. PassiveTeX kann man von Sebastian Rahtz' Website herunterladen.
FOP ist nicht perfekt, aber ein benutzbares, freies Tool
Apache FOP, steht für Formatting Objects Processor und ist eine freie, Java-basierte XSL:FO-Engine. Die derzeitige Version 0.20.4 setzt noch nicht dem gesamten XSL:FO-Standard um, und es wird derzeit an einer kompletten Reimplementierung gearbeitet.
FOP unterstützt die Ausgabeformate PostScript und PDF, aber kein RTF. Das Programm nutzt den Xalan-XSLT-Prozessor, um direkt von DocBook nach PDF zu wandeln, es kann aber auch XSL:FO-Dateien als Eingabe behandeln. Die XML-Seiten der Apache Software Foundation bieten das Programm als Quellcode und in kompilierter Version an.
Das kommerzielle Pendant zu FOP stellt XEP von RenderX dar. Da die Vollversion mit einem Preis von 300 US$ für mich nicht erschwinglich ist, kann ich keine Aussagen über die Qualität der Ausgabe machen. Unabhängigen Quellen zufolge soll XEP jedoch schneller und qualitativ besser sein als FOP.
RenderX stellt auf seinen Seiten neben funktional beschränkten Testversionen von XEP auch ein kurzes, aber gutes XSL:FO-Tutorium bereit.
jFor kann momentan nicht mit den DocBook-XSL-Stylesheets umgehen
Eine Open-Source-Variante, XSL:FO in RTF zu wandeln stellt jFor dar. Es ist geplant, dass jFor in zukünftige Versionen von FOP integriert wird. Im Moment hat jFor allerdings noch Probleme bei der Bearbeitung der DocBook-XSL-Stylesheets.
Quellen und Executables von jFor können bei Sourceforge heruntergeladen werden.
Wie XEP zu FOP verhält sich der XMLmind FO Converter (XFC) zu jFor. Er unterstützt die Ausgabe von RTF, hat aber keine Probleme mit den DocBook-Stylesheets. XFC kann bei XMLmind in einer kostenlosen Standard-Ausgabe heruntergeladen und einer Server-Variante, die auch die Einbindung in andere Programme unterstützt für 550 € gekauft werden.
Workflow-Tools erleichtern die Arbeit mit DocBook, indem Sie ein einheitliches User-Interface für die Schritte der Überprüfung und Umwandlung der Dokumente bieten.
xmlto benötigt PassiveTeX, um PDF zu erstellen
Xmlto von Tim Waugh ist ein keines Unix-Kommandozeilen-Programm, welches die Umwandlung von DocBook in HTML, XHTML, DVI, XSL:FO, Man-Pages, PDF, PostScript und einfachen Text unterstützt. Es ist dabei im wesentlichen ein Frontend für xsltproc und PassiveTeX.
Beispiel 1.18. Benutzung von xmlto
#
xmlto html /home/lars/vortrag.xmlIn diesem Beispiel wird aus einem DocBook-Dokument ein einzelnes HTML-Dokument erzeugt.
Sie können xmlto von Tim Waugh's Homepage herunterladen und auf ihrem System installieren.
Für Windows-Nutzer ist eDE sehr empfehlenswert
Das e-novative DocBook environment (eDE) ist ein freies, leicht zu installierendes und benutzungsfertiges DocBook-System für Windows-Rechner. Es ist ein Download mit allen Komponenten, um Dokumente anzulegen, zu verwalten und die Ausgabe zu erstellen.
Beispiel 1.19. Installation von eDE
e-novative DocBook environment wird von der URL http://docbook.e-novative.de/download.html heruntergeladen und das Archiv wird ins Verzeichnis c:\docbook entpackt. Danach wird auf die Kommandozeile gewechselt, um eDE zu installieren:
C:\Documents and Settings\Lars Trieloff>c:\docbook\bat\docbook_testjava version "1.4.1_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) e-n