XML-Workflow

Um ein Publikationsprojekt XML-mäßig verarbeiten zu können, muss vor allem die Struktur des Projekts klar sein. Zur Struktur gehören z. B. die Hierarchie der Überschriften, die verschiedenen Absatztypen für den Haupttext, Kästen, Bilder, Bildunterschriften usw. Auch die Frage der Reihenfolge solcher Elemente ist wichtig: dürfen bestimmte Elemente aufeinander folgen oder auch nicht? Die Struktur wird sinnvollerweise gemeinsam von Lektoren, Herstellern und Programmierern analysiert und festgehalten. Leider passiert das oft ohne Beteiligung von Lektoren. Doch das ist ein anderes Thema.

Grundlagen

DTD, Schema, Dokument- und Formatvorlagen

Angepasst an die Struktur entwickeln die Programmierer dann eine sog. Dokumenttypdefinition (DTD) oder ein Schema. Dabei handelt es sich um ein XML-Programm. Liegt ein solches Schema vor, können die Erzeuger (Autoren) und Bearbeiter (Lektoren) des Inhalts die Struktur der zu dem Projekt gehörenden Dokumente an dieses Schema anpassen. Das heißt, in der Regel sind wir Lektoren nicht für die Entwicklung eines Schemas zuständig, sondern wir wenden es an. Zum Glück müssen wir, um das zu können, nicht unbedingt XML-Experten werden. Die Anpassung eines Dokuments an ein vorgegebenes Schema (oder eine DTD) kann für uns einfach bedeuten, das Dokument in Word konsistent und konsequent auf Basis einer Dokumentvorlage auszuzeichnen, also Formatvorlagen anstelle von manueller („harter“) Formatierung anzuwenden. Eine auf diese Weise vorbereitete Word-Datei kann relativ problemlos in eine XML-Datei überführt werden. Dafür sind üblicherweise wiederum nicht wir, sondern Techniker zuständig. Ein Workflow, bei dem wir die Überführung der Word-Daten in XML schaffen können, selbst ohne tiefgehende XML-Kenntnisse, ist der E-Book-Workflow, auf den unten näher eingegangen wird.

Grundsätzlich muss nicht erst in Word hineingearbeitet werden, damit anschließend XML entstehen kann. Es ist auch möglich, sich als Autor oder Lektor sofort in XML-Daten zu bewegen. Auch dazu wird unten mehr gesagt.

Cascading Style Sheet

Liegt eine XML-Datei vor, kann ihr Inhalt in den unterschiedlichsten Formaten publiziert werden. Diese Variabilität ist einer der großen Vorteile von XML und einer der Hauptgründe, weshalb sich XML in den letzten Jahren in der Verlagswelt durchgesetzt hat.

Damit der Inhalt der XML-Datei publiziert werden kann – in gedruckter oder digitaler Form –, wird noch eine weitere Komponente benötigt: ein sog. Stylesheet, genauer: ein Cascading StyleSheet, abgekürzt CSS. In einem solchen CSS wird beschrieben, wie die Inhalte einer XML-Datei am Bildschirm oder bei der Druckausgabe aussehen sollen. Zur korrekten Umsetzung der CSS-Beschreibungen braucht es darüber hinaus die sog. Extensible Stylesheet Language Transformations (XSLT). Und umgesetzt wird alles in XHTML (das X deutet an, dass es sich um HTML handelt, das aus XML heraus erzeugt wird). Schließlich wird im letzten Schritt aus XHTML normales HTML (zur Anzeige auf einem Rechner) oder EPUB (zur Anzeige auf einem E-Reader; EPUB = electronic publication) oder aber ein Format, das zum Drucken geeignet ist. Das hört sich nicht nur sehr technisch an, es ist genau das. Trotzdem brauchen wir Lektoren davor keine Angst zu haben, denn die meisten dieser Punkte werden uns von den Programmen, die wir verstehen und einsetzen können, abgenommen. Das trifft speziell auf die E-Book-Erzeugung zu – siehe unten.

XML-Workflow gesamt

Am Ende des XML-Workflows stehen also, um das noch einmal zu betonen,  entweder digitale Anzeigedaten – HTML oder bestimmte XML-Varianten wie EPUB – oder druckfähige Daten, deren endgültiges Layout mit einem Layoutprogramm erzeugt wird. Die Konvertierung der XML-Daten in Layoutprogrammdaten ist nicht trivial; sie kann nur von Technikern vorgenommen werden. Die Gestaltung im Layoutprogramm ist dagegen eine Tätigkeit, bei der wir Lektoren durchaus wieder ins Spiel kommen können. Die eigentlichen Druckdaten sind dann meistens PDF-Dateien.

Der gesamte XML-Workflow mit seinen wichtigen  Komponenten und Stationen wird in Bild 1 wiedergegeben.

xml_workflow
Bild 1: XML-Workflow, der alle prinzipiell nötigen Komponenten zeigt.

XML-Workflow für Lektoren: E-Book-Erzeugung

Ein XML-Workflow, in dem wir Lektoren an fast allen Stationen beteiligt sein können, ist der, der zu E-Books führt.

Der harte Weg

Wir könnten z. B. eine Word-Datei, die wir bearbeitet haben, einfach als XML-Datei abspeichern. Beim Speichervorgang wendet Word von ganz allein (und bei OpenOffice geht es analog) die Transformation auf Basis eines (von Microsoft) eingebauten Schemas an. Auch ein CSS wird automatisch in die XML-Daten eingebaut. Doch trotz all dieser Hilfen, die Microsoft vorgesehen hat, wären die meisten von uns überfordert, aus diesen Word-XML-Daten E-Book-Daten, letztlich also EPUB, zu erzeugen. Wir können Word-XML zwar grundsätzlich verstehen, die Weiterverarbeitung sollten wir aber lieber Technikern überlassen.

Der einfache Weg

Textverarbeitungsprogramme, nicht nur Word, sondern auch z. B. OpenOffice, bieten zum Glück noch andere, einfachere Wege (zumindest für uns Lektoren einfachere) hin zum EPUB-Format. Die wichtigste Möglichkeit besteht darin, die Word-Datei nicht als XML-Datei, sondern im HTML-Format abzuspeichern und daraus im nächsten Schritt dasjenige XML zu machen, das für die weitere Verarbeitung benötigt wird. Bei der E-Book-Erzeugung wird oft genau dieser Weg – von Word über HTML zu XML – gegangen. Der XML-Workflow für E-Books, den Lektoren beschreiten können, sieht grundsätzlich wie folgt aus:

xml_workflow_lektoren_01

Bild 2: E-Book-XML-Workflow in der Hand von Lektoren. Ausgangspunkt ist eine Word- oder InDesign-Datei, die zunächst in HTML und dann z.B. in EPUB umgewandelt wird. Bei InDesign und einigen Textverarbeitungsprogrammen (wie OpenOffice oder Papyrus Autor) ist auch eine direkte Umwandlung in EPUB möglich. Im Bild wird zusätzlich der Print-Zweig (über PDF) gezeigt.

Bei diesem vereinfachten Workflow haben wir erst einmal nichts mit DTDs, Schemas, CSS, XSLT, ja nicht einmal direkt mit XML-Codierung zu tun. Und trotzdem erzeugen wir XML, denn eine EPUB-Datei ist eine XML-Datei (genauer: besteht aus [mehreren] XML-Dateien).

HTML aus Word erhalten wir durch den einfachen Befehl  „Speichern unter“ HTML:

xml_workflow_lektoren_01_html

Bild 3: Abspeichern einer Word-Datei im HTML-Format. Wählen sollte man „Webseite, gefiltert“, weil Word dann gleich überflüssigen Code entfernt.

Die so erzeugte HTML-Datei können wir mit einem einfachen HTML-Programm (wie NVU) nachbearbeiten (dann müssten wir uns natürlich etwas mit den HTML-Codierungen befassen) oder aber direkt in ein Programm wie das leicht zu handhabende Calibre einladen, das die weitere Umwandlung in EPUB mehr oder weniger automatisch übernimmt. Ist die Word-Datei gut vorbereitet (also konsequent und konsistent mit Formatvorlagen ausgezeichnet) liefert dieser XML-Workflow sofort brauchbare Ergebnisse. Der Grund dafür, dass das funktioniert, besteht u. a. darin, dass Word beim Abspeichern als HTML-Datei automatisch sowohl ein bestimmtes vorgegebenes Schema anwendet als auch ein brauchbares CSS erzeugt.

Allerdings sind die Ergebnisse noch nicht optimal. Man könnte eine solche Datei zwar veröffentlichen, aber man würde ihr das „Quick-and-Dirty-Verfahren“ ansehen. Um eine halbwegs professionell wirkende EPUB-Datei zu erhalten, sollte sie mit einem EPUB-Programm nachbearbeitet werden. Optimal dazu geeignet ist das kostenlos einsetzbare Programm Sigil. Man kann auch Calibre umgehen und die HTML-Datei direkt mit Sigil öffnen; die dabei halb- oder vollautomatisch entstehende EPUB-Datei kann mit Sigil weiterbearbeitet, geprüft und fertiggestellt werden.

Im Bild der verwendeten Programme könnte ein typischer XML-Workflow für Lektoren also wie folgt aussehen:

xml_workflow_lektoren_01_programme

Bild 4: Eingesetzte Programme von Word zur EPUB-Datei

Natürlich gibt es zu den einzelnen Schrittten einiges zu sagen. Die Details werden in anderen Beiträgen beschrieben.

XML-Workflow für Lektoren: weitere Möglichkeiten

Als Lektoren können wir aber auch in andere XML-Workflows eingebunden sein. Der oben beschriebene Workflow von Word zum E-Book (im EPUB-Format) weist aus technischer Sicht zwei Merkmale auf:

  1. Begonnen wird in einem anderen Format als XML (nämlich in Word).
  2. Der Workflow hat eine vorgegebene Richtung, er endet mit XML (in einer speziellen Form, nämlich EPUB) und kann nicht ohne Weiteres in umgekehrter Richtung durchlaufen werden.

Denkbar sind auch andere Varianten.

XML-First und Content-Management-Systeme

So kann z. B. gleich im XML-Format begonnen werden. Das nennt sich dann XML-First. In der Praxis heißt das, dass man als Lektor direkt in einem XML-Editor arbeitet, und nicht in Word. Typische XML-Editoren sind der PTC Arbortext Editor, XMLSpy oder Oxygen, um die großen und teuren zu nennen. Ein kleinerer Editor ist editix. Prinzipiell kann jeder „normale“ ASCII-Editor (z. B. Notepad++) zur Eingabe und zum Bearbeiten von XML-Code verwendet werden, allerdings stehen dann keine Komfortfunktionen wie das Ein- und Ausblenden von Elementen oder Attributen zur Verfügung, sondern man muss im rohen Code arbeiten. Bei den Projekten, die uns üblicherweise angeboten werden, arbeiten wir in einem der genannten großen XML-Editoren. Sie sind oft noch in ein Content-Management-System (CMS) integriert.

Kurz ausgedrückt: Die Arbeit in einem CMS bedeutet nichts anderes als XML-First!

Aus einem CMS heraus können verschiedene Ausgaberichtungen angefahren werden: Word, PDF, Layoutprogramm (wie InDesign oder FrameMaker) und auch EPUB.

Ein CMS zeichnet sich gegenüber einem puren XML-Editor u. a. dadurch aus, dass mehrere spezielle DTDs (verlags- oder projektspezifisch) hinterlegt sind und verschiedene Cascading Style Sheets (CSS) angesprochen werden können. Sowohl die DTDs als auch die CSS sind von Programmierern angelegt worden – als Lektoren brauchen wir uns dazu keine Gedanken zu machen. Wir bekommen von der Existenz dieser XML-Basis-Bestandteile oft gar nichts mit.

Dass eine DTD „wirkt“, spürt man allerdings u. a. daran, dass bestimmte Formatierungen, die man vielleicht vornehmen möchte, nicht funktionieren, weil sie in der DTD, die die Strukturregeln für die Dokumente vorgibt, als verboten deklariert wurden. Ein Verbot könnte z. B. lauten: Innerhalb eines Einleitungstextes kann keine Zwischenüberschrift eingebaut werden. Blinkt der Cursor also gerade in einem Absatz, der als Einleitungstext formatiert wurde, so haben wir keinen Zugriff auf das Überschriftformat „Zwischenüberschrift“ (das in einem Projekt natürlich auch einen anderen Namen haben kann, z.B. „ubzw“ oder wie auch immer). Nur zum Vergleich: in Word könnte an jeder beliebigen Stelle eines Textes jede beliebige Überschrift eingebaut werden.

Vom Vorhandensein eines Cascading Style Sheets spüren wir tatsächlich nichts. Man kann nur indirekt auf die Existenz schließen: Meist sind im Content-Managament-System Ausgabebefehle einprogrammiert: Auf Knopfdruck lässt sich PDF erzeugen oder man kann Daten im InDesign-Format ausgeben usw. Das alles klappt nur, weil ein entsprechendes Cascading Style Sheet vorhanden ist.

Aber auch, wenn man nicht in einem CMS, sondern in einem reinen XML-Editor arbeitet, können DTDs und Cascading Style Sheets hinzugeschaltet werden (und haben dann im Grunde den gleichen Effekt wie in einem CMS).

Von XML zurück ins Layout

Wenn man von irgendwoher zu XML kommt, sollte es doch auch möglich sein, den umgekehrten Weg zu beschreiten, oder? Ja, prinzipiell geht auch das.

Folgende zwei Gründe (wahrscheinlich gibt es noch mehr) können für eine sinnvolle Rückkonvertierung von XML z. B. zu Word oder InDesign ins Feld geführt werden:

  1. Selbst wenn eine EPUB-Datei ihren Ursprung z. B. in Word hatte, so ist vielleicht erst in der EPUB-Phase mit einem Programm wie Sigil richtig Arbeit in ein schönes Aussehen der Daten, also letztlich in das Cascading Style Sheet, gesteckt worden. Nun wäre es gut, wenn von dieser Arbeit so viel wie möglich zurückgerettet werden könnte mit dem Ziel, dann eine bessere Word-Datei zu haben als vorher. In einer solchen Word-Datei könnten der Autor oder der Lektor später die inhaltliche Aktualisierung für eine Neuauflage vornehmen (um dann im nächsten Schritt erneut EPUB, also XML zu erzeugen).
  2. Nicht selten verwenden Verlage das XML-Format zum Archivieren. Der Charme von XML ist ja u. a., dass es sich um eine generische Markierungssprache handelt. Das heißt nichts anderes, als dass man jederzeit – heute oder auch erst in 20 Jahren – beliebige Ausgaberichtungen „bedienen“ kann. Das Format veraltet so gut wie nicht – ganz anders als die sog. binären Textverarbeitungs- oder Layoutprogrammformate, die höchstens ein paar Jahre lang problemlos gelesen und verarbeitet werden können. XML-First-Daten können, wie sie sind, gleich archiviert werden, andere XML-Daten in der Form, die sie als Endprodukt des XML-Workflows haben. Auch bei archivierten XML-Daten will ein Verlag vielleicht dem Autor eines Werks zwecks Aktualisierung eine Word-Datei zur Verfügung stellen.

Die Rückkonvertierung ist eine komplexe Angelegenheit, die nur von Experten (Satzunternehmen und Programmierern) vorgenommen werden sollte. Aber es gibt etliche Unternehmen, die diese Dienstleistung anbieten.

Wir Lektoren haben mit dem rein technischen Prozess der Rückkonvertierung wieder nichts zu tun, aber uns wird vielleicht ein Word-Dokument vorgelegt, das auf diesem Weg entstanden ist. In der Regel gibt es dann eine Dokumentvorlage, mit der das Dokument zu verbinden ist. Die Dokumentvorlage spiegelt die DTD und das Cascading Style Sheet wider, auf deren Basis die XML-Daten abgelegt waren oder aber – und das ist ja gerade der große Vorteil – auf deren Basis die zukünftige Ausgabe des Buches erzeugt werden soll. Aus der Word-Datei könnte dann wieder das neue XML entstehen, das sowohl zum Publizieren als auch zum erneuten Archivieren verwendet wird.

9 Gedanken zu „XML-Workflow

  1. You can definitely see your expertise in the work you write.
    The world hopes for even more passionate writers such as you
    who aren’t afraid to mention how they believe.
    Always follow your heart.

  2. Hello there! This article could not be written any better!
    Going through this post reminds me of my previous roommate!
    He always kept preaching about this. I most certainly will forward this article to
    him. Fairly certain he will have a great read. Thanks for sharing!

  3. I’ve been surfing online more than 4 hours today, yet I never found any interesting
    article like yours. It is pretty worth enough for me.
    In my view, if all web owners and bloggers made good content as you did,
    the net will be a lot more useful than ever before.

  4. We are a group of volunteers and opening a new scheme
    in our community. Your web site provided us with valuable
    information to work on. You have done a formidable job and
    our entire community will be thankful to you.

Schreibe einen Kommentar


*