(Original von Sarah O’Keefe)

Eine Standardfrage, die mir und auch sicher Ihnen immer wieder begegnet, lautet: »Welche Software soll ich verwenden?«

Das ist, nicht nur in der Technischen Dokumentation, die falsche Frage! Wenn Sie nach danach fragen, landen Sie sofort im dunklen Rattenloch von Bedienbarkeit der Software, Langlebigkeit des Herstellers, Betriebssystemunterstützung.

Eine bessere Frage wäre: »Wie bringe ich meine Informationen am besten an den Kunden?«

Leider ist auch diese Frage schwer zu beantworten und die Antwort wechselt von Jahr zu Jahr. Mit dem Altern des CHM-Formats wurde Browser-Hilfe immer angesagter, jetzt ist es vielleicht ePUB, nächstes Jahr dann HTML5?

Wenn Sie also nicht einmal genau wissen, welche Ergebnisse benötigt werden, sich zudem die Anforderungen ändern, wie können Sie da eine Software auswählen? Eben, es geht nicht.

Die Frage muss anders gestellt werden:
»Wie können Informationen gespeichert werden, um damit aktuelle und zukünftige Anforderungen zu erfüllen?«

Und die Antwort darauf lautet: XML.

Mit einem XML-basierten Workflow stehen Sie nicht vor der Qual der Wahl des besten Werkzeugs. Wenn ein Werkzeug nicht mehr das richtige sein sollte, nehmen Sie Ihre Daten und ziehen weiter zum nächsten. Sie müssen auch nicht schon heute wissen, welche Ausgabeformate Sie einmal brauchen werden. Egal ob XHTML, Browser-Hilfe, HTML5, PDF, ePUB, oder ein heute noch nicht benanntes Format – aus den XML-Daten können Sie all diese Formate erzeugen.

Dieses Vorgehen steht natürlich im Konflikt mit dem Geschäftsmodell vieler Autorenwerkzeuge. Die Softwarehersteller haben ein großes Interesse daran, Sie möglichst langfristig an sich zu binden. (Und: Berater könnten ein Interesse an komplexen Lösungen haben, die nur mit deren Hilfe implementiert werden können.¹)

Wenn Sie also eine Software mit einem hohen Bindungseffekt wählen (im Original: »lock-in«, siehe Lock-in-Effekt, legen Sie Ihre Publikationsstrategie in die Hände des Softwareherstellers. Ihre Strategie würde in erster Linie bestimmt von den Einschränkungen der Software bzw. von den Ideen des Herstellers.

Meiner Meinung nach müssen Sie anders vorgehen: Erst wählen Sie Ihre Strategie, dann suchen Sie nach dafür geeigneten Werkzeugen.

Dieses Vorgehen ist zwar nicht einfacher als die falsche Frage zu stellen und irgendwie zu beantworten, aber mittelfristig wesentlich Erfolg versprechender.

¹) Das könnte auch mich betreffen…
Foto: Thommy Weiss / pixelio.de

Foto: RainerSturm / pixelio.de

Ich beschäftige mich vor allem mit der Automation lästiger manueller Tätigkeiten. Statt solche manuellen Schritte immer wieder und möglicherweise auch in allen Übersetzungen wiederholt abzuarbeiten, versuche ich mit meinen Kunden, diese Aufgaben oder den damit verbundenen Zeitbedarf möglichst zu reduzieren. Dazu gibt es in der Regel zwei Ansätze:

• Im Vorfeld vermeiden; zum Beispiel durch: ein besseres Template, XML-strukturiertes Arbeiten, Training der Mitarbeiter, …
• Vom Computer erledigen lassen; zum Beispiel durch: bessere Layout-Regeln in der EDD, Finishing-Routinen per FrameScript/ExtendScript, …

Der wirtschaftlich interessanteste Teil ist die Phase nach dem Übersetzungsvorgang, denn hier geht es jetzt nur noch darum, die benötigten Ausgabeformate möglichst schmerzfrei (lies: kostengünstig) zu erzeugen. Früher gab es eigens dafür zuständige Mitarbeiter, heute darf sich der Technische Redakteur auch damit beschäftigen – und es lenkt ihn von seiner Hauptaufgabe ab.

Nachdem die Produktionsschritte im Prinzip immer gleich sind (Verzeichnisse aktualisieren, PDF erstellen, …), ist es dann nicht möglich dies vom Computer erledigen zu lassen? Ja, ist es, wenn Ihre Dokumente XML-basiert erstellt und übersetzt werden: Mit XSLT und XSL-FO können Sie zuverlässig alle derzeit üblichen Ausgabemedien nach einmaliger Programmierung in automatischen Prozessen erstellen lassen!

Bei der Erstellung von Online-Medien – also meist HTML in irgendeiner Verpackung – haben wir uns daran gewöhnt, das finale Aussehen vorher nicht zu kennen, da der Anwender sein Browserfenster eben so breit oder schmal machen kann, wie es ihm oder ihr beliebt. Bleibt die Erstellung von PDF-Dokumenten. Im Unterschied zu den Online-Medien kennen wir hier die Seitenbreite genau und auf einmal sind wir alle Experten für den optimalen, den richtigen Seitenumbruch. Wirklich?

Warum also lassen wir auch diese Arbeit nicht einfach komplett vom Computer erledigen? Warum liegt uns diese letzte Eingriffsmöglichkeit mit einem DTP-Programm so am Herzen?

Was meinen Sie?

Wenn Sie sich für das Programm dieser Veranstaltung zum Thema XML interessieren, finden Sie alle Infos auf http://www.markupforum.de/.

Diese neue Veranstaltung hat meiner Meinung gutes Fortsetzungs-Potential. Sicher werden – aufgrund der Ausrichtung der veranstaltenden Hochschule der Medien – auch zukünftig die technischen Voraussetzungen und Rahmenbedingungen für mögliche neue Geschäftsmodelle von Verlagen einen gewissen Vorrang haben, aber selbst beim Austausch von Video-Schnittdaten zwischen Applikationen kommt XML zum Einsatz! In gewisser Weise stehen die Verlage heute dort, wo sich die Technische Redaktion in der Industrie schon vor einiger Zeit war: Unter dem Druck, immer mehr Publikationen in mehreren Varianten und/oder Medien möglichst günstig zu publizieren. Insofern muss auf Seite der Verlage nicht alles neu erfunden werden…

Im folgenden einige Anmerkungen zu einigen Beiträgen, Vortragsfolien wird es auf der o.g. Webseite geben. [Ich musste lernen, dass es nicht einfach ist, zuzuhören und gleichzeitig schriftlich zu kommentieren.]

The Future of XSLT

Dr. Michael Kay spricht gerne über die Zukunft, da ihn keiner schelten kann, wenn er daneben liegt. Nach einem Rückblick auf die Wurzeln von XSLT folgt ein Blick auf die Gegenwart, die Stärken und Schwächen.

Either people love it, or people hate it

If your brain adjusts to the XSLT wavelength…

Nachdem es mit XSLT im Web-Browser seit 2001 nicht weiter gegangen ist, hat sich die Weiterentwicklung auf die Server-seitige Nutzung konzentriert. Dort gibt es unterschiedliche Geschäftsmodelle:

• Do it for fun
• Give it away and hope to make money on something else (Altova)
• Bundle it as part of something expensive (IBM, Intel, MarkLogic)
• Do it cheaply, sell it cheaply (Saxonica)

Die Weiterentwicklung zu XSLT 3.0 liefert im Wesentlichen Verbesserungen für die Top-End-Anwender. Aber welche Möglichkeiten existieren für die Verwendung im Web-Browser? Eine Möglichkeit wäre JavaScript als Virtuelle Maschine (VM) für andere Sprachen zu verwenden. Und daran arbeitet Michael Kay derzeit.

HTML5

Sehr unterhaltsam… ein Beitrag, mit dem uns Michael Jendryschik ermuntern will, es mit HTML5 zu probieren.

Der DITA-Hype

Bildschirmpräsentation meines Beitrags

Warum Verlage XML sprechen sollten

Stell dir vor, es geht und keiner bekommt’s hin (Wolfgang Neuss)

Wie kommen wir an die Metadaten, die die „semantische Lücke“ zwischen Inhalten und der Suche danach schließen?

Metadaten sollen verständnisrelevante Informationen transportieren: Identifikation, Entdeckung, Auswertung, Management.

Eine willkommene Brandrede von Helmut von Berg für die semantische Auszeichnung von Inhalten. Was nicht gefunden wird, wird auch nicht gekauft!

Macht XML selig?

Wenn in der technischen Dokumentation das XML-strukturierte Vorgehen manchmal schlicht einen Notwendigkeit ist, so lassen sich im Verlagsbereich noch neue Geschäftsmodelle entwickeln. Spannend!

Looking behind ePub

Ein E-Book ist das, was ein Leser bereit ist auf einem elektronischen Medium zu lesen.

Der Standard ePUB 2.0 besteht aus den drei Sub-Standards OCF + OPF + OPS.

Durch den »Reflow« der Inhalte muss für bestimmte Layouts eine neue Lösung gefunden werden.

Dr. Victor Wang gibt einen Überblick über den Stand und die aktuellen Bemühungen zur Weiterentwicklung zu ePUB 3.0.

XML-Dokumente mit Schematron besser prüfen

Statt einer reinen Strukturprüfung wie bei DTD oder XML Schema wird hier regelbasiert geprüft, und ermöglicht so viel mächtigere Tests (Roger Costello, http://www.xfront.com/):

• Co-constraints
• Cardinality checking
• Algorithmic checking

Ich persönlich finde die hier sehr anschaulich von Prof. Hedler vorgestellte Prüftechnik äußerst interessant. Wenn wir ähnliches in bescheidenem Umfang mit kontextabhängigen Formatierregeln in FrameMaker umsetzen, wäre eine weiter gehende Unterstützung doch noch nützlicher.

InDesign und XML – wie geht es weiter?

Ein Überblick von Gregor Fellenz über die diversen XML-Features und Probleme von InDesign: Whitespace-Problem, IDML, ICML, XHTML-Export (z.B. für die ePUB-Erstellung).

InDesign als Datenzentrale? Eher nicht, insbesondere da Adobe die XML-Features seit InDesign CS4 nicht weiterentwickelt hat.

Also: InDesign als Rendering Engine, klassische DTP-Anwendung.

Proof of Concept: WordPress via XSLT nach ICML, in InDesign verknüpft.

Anfang 2009 führte Scriptorium Publishing eine Umfrage unter dem Titel »The State of Structure« zu den Erwartungen an und Erfahrungen mit XML-strukturierten Autorenumgebungen und Prozessen durch. Über deren Ergebnisse habe ich im Mai 2009 kurz berichtet. Nicht zu schweigen davon, dass ich einige Erkenntnisse auch in einigen Vorträgen und Präsentationen berücksichtigen konnte.

Jetzt, Anfang 2011, zwei Jahre später ist es Zeit für ein Update dieser Umfrage, und Sarah O’Keefe, die größtenteils in Deutschland aufgewachsene Gründerin von Scriptorium Publishing, würde sich freuen, wenn diese Neuauflage eine stärkere internationale Beteiligung erfahren würde.

The State of Structure, 2011

Wenn Sie bereits XML-strukturiert arbeiten oder dies bei Ihnen geplant ist, nehmen Sie sich bitte ca. 15 Minuten Zeit und bis Ende Februar an der Studie teil. Als Teilnehmer bekommen Sie die Ergebnisse kostenlos; es werden auch zwei Amazon-Geschenkgutscheine verlost…

• Offizielle Ankündigung
• An der Studie teilnehmen

• Blog-Beiträge zur XML Prague

Nicht zuletzt von dieser Veranstaltung, sondern auch von einem gewissen Mangel an Veranstaltungen hierzulande, ließen sich die Organisatoren aus dem Umfeld der Hochschule der Medien in Stuttgart inspirieren, eine deutschsprachige Konferenz zu diesem Thema zu initiieren:

Unter dem Titel MarkupForum geht es zunächst an einem Tag, dem (leicht zu merkenden) 1.3.2011 in Stuttgart um Publishing mit XML.

Aktuell können Sie sich unter http://www.markupforum.de/ über das Programm informieren.

PS: Ich hätte nie im Leben angenommen, einmal mit Dr. Michael Kay auf einer Referenten-Liste zu stehen

Die vom VOI in Zusammenarbeit mit der Beratungsgesellschaft Zöller & Partner herausgegebene »Marktübersicht Dokumenten-Management-Systeme« umfasst 956 Seiten und ist das Ergebnis einer effizienten Nutzung aktueller Technologien:

• Web-Frontend mit Datenbank zur Erhebung der Daten
• XML-Export aller Fragen und Antworten
• XSL-Preprocessing zur publikationsgerechten Aufbereitung mit
• Adobe FrameMaker

Dass Vorwort und Titel dabei herkömmlich formatbasiert umgesetzt sind, stört den Prozess ganz und gar nicht, bietet doch diese hybride Vorgehensweise den schnellsten Weg zu einer effizienten Lösung.

Weitere Details finden Sie in meinem Projektbericht »Database Publishing für Marktübersichten«.

Jetzt erschien als zunächst experimentelles Update für Adobe Illustrator CS5 in den Adobe Labs eine Erweiterung namens Adobe Illustrator CS5 HTML5 Pack, welches erweiterte Features beim Speichern von Grafiken als SVG anbietet.

Aber woher kommt das Interesse? Es zeigt sich, dass Flash eben doch nicht überall vorausgesetzt werden kann und zum noch in Entwicklung befindlichen Web-Standard HTML5 gehört neben CSS3 eben auch die Unterstützung für SVG-Grafiken. Da sich Adobe primär als Werkzeug-Lieferant für die Inhaltsschöpfer sieht, will man natürlich überall dabei sein, in der Flash-Welt wie in Umgebungen, in denen Grafiken und Animationen ausschließlich mit HTML, CSS und JavaScript erstellt werden.

Zur Erinnerung: Im April 2010 sorgte Steve Jobs für Aufsehen mit seinen »Thoughts on Flash«, die von Adobe gekontert wurden mit »Freedom of Choice«.

Wenn jetzt in SVG nur noch eine vernünftige Unterstützung für Textblöcke dazu käme…

PS: Die HTML5-Beispiele auf http://www.apple.com/html5/ sind schon recht beeindruckend (Achtung: Mit Internet Explorer wird’s nix…)

Michael Kay, XSLT-Mastermind, hat einen Blog-Eintrag zu The ten most common XSLT programming mistakes verfasst. Der aus meiner Sicht eindrücklichste Hinweis ist Punkt 7:

Don’t use disable-output-escaping. […] 95% of the time, if you see disable-output-escaping in a stylesheet, it tells you that the author was a novice who didn’t know what s/he was doing.

In den Punkten 4 und 10 weist er indirekt darauf hin, dass für gute Ergebnisse eine gewisse Kenntnis der Arbeitsweise bzw. Programmiersprache nötig ist. Das erinnert mich an There is no free lunch! Wer aber die Basishürden überwindet, wird mit einer mächtigen Programmiersprache belohnt, die beliebige Modifikationen an XML-Daten zulässt.

• WERBUNG: Ich biete Training on-the-job für XSLT an; hier gibt’s Informationen zu Schulungen.

So, und jetzt beginnt die Fußball-WM, wer hat da noch Zeit für Doku?

Diff, Change Tracking, Änderungsverfolgung… you name it…

Es gibt mehrere Gründe warum jemand gerne sehen möchte, wo in einem Dokument welche Änderungen gemacht wurden:

• Der Leser möchte bei einem Update die Stellen mit Änderungen gegenüber seiner letzten Version des Dokuments sofort erkennen
• Der Korrektur-Leser möchte die Stellen mit Änderungen seit dem letzten Korrekturlauf erkennen
• In den Übersetzungsprozess sollen nur Abschnitte mit Änderungen geleitet werden

Den letzten Fall möchte ich hier einmal ausklammern, auch wenn dessen wirtschaftliche Relevanz nicht unterschätzt werden darf. Aber hierfür sind eine Vielzahl weiterer Prozessfragen zu klären.

Die ersten beiden Punkte bieten Raum genug. Zum Beispiel, wenn wir Versionssprünge für bestimmte Sprachen oder Produktvarianten unterstellen. Wenn also nicht in allen Sprachen oder Produktvarianten die gleichen Änderungen angezeigt werden sollen (Äa = Änderungsanzeige):

Wenn Sie dies noch kombinieren mit gesonderter Änderungsanzeige für verschiedene Korrekturleser… dann ist es kein Wunder, dass dies heute nicht oder nur selten stattfindet. Und wenn, dann mit recht hohem Zeitaufwand.

Aber es geht! Mit FrameMaker!

In einem aktuellen Projekt habe ich folgendes umgesetzt:

• zwei beliebige XML-Fassungen eines Handbuchs werden mit Hilfe eines XML-Tools verglichen
• das XML-Ergebnis mit Änderungsmarkierungen wird für FrameMaker aufbereitet
• es entsteht ein FrameMaker-Buch mit FrameMaker-Änderungsmarkierungen, die auf Wunsch noch nachbearbeitet werden können

Im Detail:

Es gibt viele Werkzeuge, mit denen Textdateien oder sogar XML-Dateien vergleichen werden können. Aber erst 2009 fand auch eines, dass Änderungsmarkierungen auch in einem XML-Dokument speichern kann. Dies erfolgt mit Hilfe von Processing Instructions, so dass die XML-Datei nicht durch neue Elemente oder Attribute von vornherein ungültig wird. Dem Werkzeug fehlten noch einige Funktionen, die wir für den Vergleich von Dokumenten benötigen, zum Beispiel den Vergleich auf Textebene. Mittlerweile gibt es eine Version 2.0 von XML Tree Compare zum Testen auf http://www.xmldifftool.com/.

Eine Aufbereitung des Outputs von XTC ist nötig, da FrameMaker Änderungsmarkierungen auf ganz bestimmte Art und Weise erwartet. Zudem bietet die Aufbereitung auch die Möglichkeit, bestimmte technisch motivierte Änderungen zu ignorieren. Da es sich um eine XML-Datei handelt, erfolgt diese Anpassung per XSLT.

Integriert wird das Ganze mit einem Skript, so dass der Vorgang für den Anwender problemlos ist. FrameMakers Einschränkungen im Zusammenhang mit der Änderungsverfolgung werden dabei weitgehend behoben.

Und das Dokument mit Änderungsanzeige kann anschließend mit der Symbolleiste Textänderungen nachverfolgen nach Änderungen durchsucht werden. Wenn gewünscht können auf diese Weise banale Änderungen noch akzeptiert werden. Abgebildet sind hier das alte, das neue und das Dokument mit Änderungsanzeige.
(Für große Darstellung bitte anklicken und mit Pfeiltasten zwischen den Bildern wechseln)

Wenden Sie sich an mich, wenn Sie dies auch für Ihre FrameMaker-Publikationen einsetzen wollen!

Stéphane Sire von der École Polytechnique Fédérale de Lausanne brachte es im Vortrag »Authoring XML all the Time, Everywhere and by Everyone« ganz gut auf einen Nenner: Es gibt mehrere Ansätze, wie XML-Editoren aufgebaut sind, an welche Zielgruppe sie sich wenden:

• Markup-zentriert (wie z.B. OxygenXML und alle anderen Entwickler-Editoren)
• Daten-zentriert (wie z.B. XSLTForms, Orbeon Forms)
• Dokument-zentriert (wie z.B. Xopus)

Recht oft höre im Zusammenhang mit XML-Editoren den Wunsch nach Einfachheit, oft ausgedrückt durch die Beschreibung »So einfach wie Word« — wer sich schon einmal mit der Datenübernahme aus MS Word beschäftigt hat, für den ist der Widerspruch offensichtlich. In der Regel gemeint ist mit dieser Forderung, dass man dem Anwender keine XML-Tags zumuten möchte, aber dennoch korrektes XML erwartet.

Lightweight Markup Language

Die einfachste Form eines XML-Editors ohne Tags verwende ich in diesem Blog: Ich schreibe wie in einer reinen Text-E-Mail und verwende einige Konventionen. Leerzeilen bedeuten Absatztrennung, * plus Leerzeichen ist Listenanfang, ein oder mehrere # markieren Überschriften. Das ganze nennt sich Markdown und ist eine einfache Auszeichnungssprache (Lightweight Markup Language), wie sie zum Beispiel auch in Wikis verwendet werden. Hierbei wird reiner Text durch einen festgelegten Regelsatz in gültiges XHTML umgesetzt, die Freiheitsgrade sind durch die Regeln bestimmt. Aber natürlich setzt dies eine Verarbeitung der Dateien voraus, irgendeine aktive Komponente, die die Umsetzung vornimmt und visualisiert — und schon wird es manchem wieder zu kompliziert.

Web CMS

Eine andere Form einfacher XML-Editoren findet sich in Web-Content-Management-Systemen. Hier werden den Schreibenden oft Formulare angeboten, die eben nur die erlaubten Felder enthalten. Das ist dann Daten-zentriertes Bearbeiten, auch wenn es sich bei den Daten um Absätze eines Beitrags für die Webseite handelt. Natürlich steht auch hier eine aktive Komponente im Mittelpunkt, primär der Web-Server.

XTiger XML & AXEL

Ohne aktive Komponente geht es auch nicht bei der von Stéphane Sire vorgestellten pragmatischen Lösung namens XTiger XML & AXEL; hier in erster Linie JavaScript im Browser. Diese versucht nicht Entwickler-nah zu sein, sondern das Erfassen von Daten und Texten per Browser für möglichst viele Zielgruppen möglichst einfach zu ermöglichen. Die Lösung ist weniger mächtig als Xopus und nicht an die XForms-Technologie gebunden wie XSLTForms, sondern kennt bewusst einige Einschränkungen, die dem XML-Puristen nicht gefallen. Deswegen nenne ich es auch eine pragmatische Lösung.

Der Anwender sieht in seinem Browser eine Vorschau seines Dokuments und kann jederzeit jeden dafür vorgesehenen Textabschnitt anklicken und bearbeiten. Aber probieren Sie das doch einfach selbst einmal aus (ich empfehle für den Einstieg die Demos »Carte« und »Article«):

• XTiger XML editing with AXEL demos
• Präsentation zum Vortrag

Ich persönlich finde den Ansatz recht gelungen und durch die Template-Orientierung ist auch die Anpassung an unterschiedliche Anwendungsfälle möglich. Natürlich nicht so einfach wie der Wechsel einer DTD oder eines Schema in einem reinrassigen XML-Editor, aber den wollen ja viele nicht…

PS1: Bei Markup-zentrierten Editoren gibt es eine große Auswahl auch kostenloser Produkte.

PS2: Ach ja, wer von MS Word nicht lassen will oder kann, für den habe ich die Lösung »Aspect« von Le-Tex in Leipzig entdeckt, die eine standardisierte Verarbeitung von Word-Dokumenten anbietet, nach PDF, ePub oder auch XML. Natürlich auch Server-basiert…

• le-tex aspect. simplified publishing.