Archiv der Kategorie: XML/XSL
Schlüsselfaktoren
Mahesh Kumar Gupta schrieb im Juli über die »Die Schlüsselfaktoren für Topic-basierte Dokumentation«:
The key drivers for topic based documentation are:
- Distributed Authoring
- Content Reuse
- Multi-channel Publishing
Diese drei Faktoren werden ganz ausdrücklich der Topic-basierten Dokumentation zugerechnet, in der jedes Topic, jeder Sinnzusammenhang, als eigener Baustein betrachtet wird.
Aber welche dieser Punkte treffen auf Ihre Redaktionsumgebung zu? Schauen wir genau hin:
-
Distributed Authoring: Arbeiten bei Ihnen wechselnde Personen gleichzeitig (und möglicherweise von unterschiedlichen Standorten aus) an einem Informationsobjekt (Handbuch, Betriebsanleitung, Onlinehilfe)? Oder ist es nicht eher umgekehrt: Eine Person bearbeitet mehrere Informationsobjekte?
-
Content Reuse: Gibt es in dem Bereich, den Sie überschauen können, tatsächlich echte Wiederverwendung? Wiederverwendung, so wie es ein Computer ermöglichen kann, bedeutet 100%ige Identität von Texten. Gibt es das bei Ihnen in nennenswertem Maß?
-
Multi-channel Publishing: Dies ist am einfachsten, denn dieses Synonym zu Single-Source-Publishing bedeutet in der Regel, dass Sie neben der PDF-Datei auch eine HTML-Fassung der gleichen Informationen erstellen müssen.
Wenn Sie die Punkte Distributed Authoring und Content Reuse bejahen können, dann kommen Sie zwangsläufig nicht um die Anschaffung eines Redaktionssystems herum. Das Steuern verteilt arbeitender Redakteure, das Verwalten tausender Topics und das Beherrschen zwangsläufig komplexer Wiederverwendungs-Szenarios mit Unmengen damit verbundener Meta-Daten können Sie gar nicht anders als mit einem Datenbank-gestützten Redaktionssystem in den Griff bekommen.
Falls aber verteiltes Arbeiten bei Ihnen nicht zutrifft, Wiederverwendung vielleicht nur begrenzt in Frage kommt, Ihr Budget keine sechsstelligen Investitionen erlaubt, Sie aber dennoch Multi-channel Publishing brauchen, dann gilt für Sie dennoch der nächste Satz des oben zitierten Artikels, mit oder ohne topic based authoring:
The best methodology to implement the concept of topic based authoring is through XML and XML based standards. XML provides ways of separating the structure and the content which greatly helps authors and at the same time it maintains consistency among the contributions made by different members of the distributed team.
Und als Editor sowie als Formatierer für XML-Inhalte macht FrameMaker eine immer bessere Figur. Natürlich gibt es einige offenen Wünsche, aber eben auch viele erfolgreiche Lösungen (zum Beispiel dieser Projektbericht). Auch auf Vorträgen im Rahmen der tekom-Tagung werden erfolgreiche FrameMaker-basierte Lösungen vorgestellt werden, dort können Sie mit Mitarbeitern aus »betroffenen« Redaktionen sprechen. Und natürlich mit mir auf meinem Stand, schauen Sie vorbei!
Veröffentlicht unter FrameMaker, XML/XSL
Kommentare deaktiviert für Schlüsselfaktoren
XML & Co. – was bringt die Zukunft?
Unter diesem Titel veröffentlichte Dr. Michael Kay (noch als Mitarbeiter der Software AG) im Januar 2003 einen Artikel in der Computerwoche, der im Kern immer noch gilt. Nur mit der erhofften Verabschiedung von XSLT/XPath 2.0 ist es im Jahr 2003 nichts geworden, das dauerte bis 2007.
XPath ist auch das Thema meines einen Vortrags auf der tekom-Jahrestagung im November… oh, ich muss den Beitrag für den Tagungsband fertig stellen!
Veröffentlicht unter XML/XSL
Kommentare deaktiviert für XML & Co. – was bringt die Zukunft?
Bedingte Trennstriche erhalten
Für XML-Anwender habe ich im Abschnitt Know-how/FrameMaker einmal zusammengestellt, was Sie tun müssen, um den bedingten Trennstrich beim Speichern von XML zu erhalten.
Veröffentlicht unter FrameMaker, XML/XSL
Kommentare deaktiviert für Bedingte Trennstriche erhalten
Systemfragen
Da lese ich doch heute in c’t 18/2009 in der Rubrik »Vorsicht Kunde!« von den Gründen für das Scheitern eines Service-Vorgangs:
[…] in den vergangenen Monaten [habe man] ein neues, SAP-basierendes Reklamationsmanagementsystem eingeführt, das wohl noch nicht in allen Fällen optimal arbeitet.
Die Berichte über aufwändige, langwierige SAP-Einführungen sind Legion. Sie sollten aber auch eine Mahnung sein für jeden, der meint, ein — und hier komme ich zu meinem Thema — Redaktionssystem ließe sich so nebenbei, möglicherweise binnen Wochen auswählen und einführen.
Das Gegenteil ist der Fall und auch gar nicht ungewöhnlich. Bevor man sich zu einer derartigen Investition — ab ca. €100.000 für zehn Arbeitsplätze — samt Folgekosten durchringt, ist es nur vernünftig, vorher sowohl über die angebotenen Systeme als auch über die eigenen Anforderungen möglichst präzise Bescheid zu wissen. Wer die eigenen Vorgaben nicht kennt, dem wird von jedem Systemanbieter natürlich etwas vorgeschlagen, was dessen System entgegen kommt. Und wer die prinzipielle Funktionsweise der Systeme nicht vorher kennt, wird möglicherweise beim ersten Einsatz überrascht den Unterschied zwischen Verkaufsgespräch und Realität feststellen.
Die eigenen Anforderungen
Die eigenen Anforderungen an die Dokument-Strukturierung (ja: XML), die benötigten redaktionellen Prozesse, eventuelle Workflow-Funktionen, die Kenntnis darüber, welche Prozesse häufig vorkommen (und deswegen leicht erreichbar sein sollten) oder welche, weil selten gebraucht, ruhig etwas umständlicher sein dürfen — all dieses sollte ein Interessent kennen, bevor er mit Systemanbietern verhandelt. Dabei kann die Unterstützung durch externe, anbieterunabhängige Fachleute nützlich sein, schließlich zählt die Auswahl eines Redaktionssystems nicht zu den Standardaufgaben einer Redaktion. Und auf jeden Fall sollte eine Teststellung des in die engere Auswahl gekommenen Systems eingeplant werden, selbst wenn das Geld kostet; ein paar Prozent der Investitionssumme sind hier sinnvoll angelegt!
Das geeignete System
Um einen Überblick über einige Systeme zu erhalten, können sie demnächst eine »Vergleichsveranstaltung« in Hamburg besuchen. Vom Verbund Technischer Redaktionen in Norddeutschland (DokuNord) wird am 9.9.2009 ein XML-Forum organisiert, bei dem unter der Moderation von Prof. Dr. Wolfgang Ziegler vier Redaktionssysteme verglichen werden: Schema ST4, FCT TIM-RS, Docufy Cosima, Ovidius TCToolbox.
Wenn Sie also am 9.9.9 9h nicht auf eine Hochzeit eingeladen sind und in Ihrer Firma über die Einführung eines Redaktionssystems nachgedacht wird, dann laden Sie sich bitte die Einladung von Ulrike Parson (Mitglied bei DokuNord und CAP-Studio-Kooperationspartner, http://www.parson-com.com/) und melden Sie sich zu dieser Veranstaltung an.
Nachbemerkung
Falls Sie heute noch nicht XML-strukturiert arbeiten und sich für Redaktionssysteme interessieren, empfehle ich ein zweistufiges Vorgehen: 1. Zunächst umsteigen und XML-strukturiert arbeiten (z.B. mit FrameMaker aber ohne großes System), um herauszufinden, welche XML-Strukturen tatsächlich benötigt werden. Und dann 2. die Einführung eines Redaktionssystems vorantreiben. Die Redaktionssystem-Hersteller empfehlen in der Regel ein einschrittiges Vorgehen… 😉
FrameMaker 9 und XML: deutlich verbessert
Power-User haben es mit der Einführung von FrameMaker 7.2 bemerkt: Beim Öffnen von XML-Dateien wurde Speicher verbraucht und nicht wieder freigegeben, so dass es in bestimmten Szenarien zu Abstürzen kam. Ich musste einmal mit einem Kunden ein Downgrade auf Version 7.1 durchführen, weil anders eine Produktion aus XML-Dateien nicht möglich gewesen wäre.
Dem Speicherverbrauch wurde in Version 8 zwar Einhalt geboten, dafür gab es aber beim Öffnen mehrerer, hinreichend komplexer XML-Dateien wiederholbare Abstürze des Programms. Zusammen mit XSL-Pre/Postprocessing und Structured-Client-Programmierung sind die Rahmenbedingungen sehr vielfältig und von der Komplexität der Dokumente abhängig, so dass sich solche Bugs nur schwer dokumentieren lassen.
Die schlechte Nachricht: In einem von mir in dem Bericht »21 Sprachen, 63 PDF-Dateien, 84 Onlinehilfen« beschriebenen Projekt stürzte FrameMaker 8 einigermaßen zuverlässig beim Öffnen der jeweils dritten XML-Datei ab. Für den dort beschriebenen Projektumfang mit 21 XML-Dateien hätte man FrameMaker also elfmal neu starten müssen… ein Graus und unerträglich.
Die gute Nachricht: Mit genau den gleichen Daten lief das Projekt nach dem Umstieg auf FrameMaker 9.0.2 anstandlos durch!
Da möchte man Adobe doch ein erleichtertes »Endlich!« zurufen!
PS: Habe ich schon auf meinen Projektbericht »21 Sprachen, 63 PDF-Dateien, 84 Onlinehilfen« hingewiesen? Interessante Lektüre…
Veröffentlicht unter FrameMaker, XML/XSL
Kommentare deaktiviert für FrameMaker 9 und XML: deutlich verbessert
Wie steht es um »Strukturiertes Schreiben«?
Die Kollegen von Scriptorium Publishing aus den USA haben Anfang dieses Jahres eine Umfrage zum Thema »The State of Structure« durchgeführt und Teile der Ergebnisse auf der STC-Konferenz präsentiert. Die Bildschirmpräsentation ist frei verfügbar, die Ergebnisse der Studie im Detail sindwaren kostenpflichtig.
Nicht alle Erkenntnisse lassen sich ohne Weiteres auf den europäischen Markt übertragen, aber Einiges ist in meinen Augen erwähnenswert. Zunächst die Begriffsdefinition, die klar macht, worum es bei dem ganzen »XML« eigentlich geht:
Structured authoring
A publishing workflow that lets you define and automatically enforce consistent organization of information; implementations are generally based on Extensible Markup Language (XML)
Sehr interessant die Einschätzung von Teilnehmern, die DITA-basierte Lösungen implementiert haben, dies aktuell tun oder planen hinsichtlich der Aufwände:
Veröffentlicht unter XML/XSL
Ein Kommentar
FrameMaker 9: Weitere technische Bonbons
In einer Reihe von Beiträgen veröffentlicht Nakshatra Bhardwaj vom FrameMaker-Team aus Noida weitere neue Features rund um unser Lieblingsprodukt. Immer handelt es sich um Aspekte, die zu komplex für Breitwandmarketing wären, aber für den einen oder anderen eine Option darstellen, die zu evaluieren wäre:
- Die Erweiterung der EDD um Wertebereichs-Restriktionen hatte ich schon erwähnt.
Jetzt kommen zwei Themen hinzu, die in XML-Umgebungen und mit WebDAV-Redaktionssystemen interessant sind:
- Geben Sie bereits in der XML-Datei sowohl den Speicherort der
structapps.fmund den Namen der Strukturapplikation an. - Beim Zugriff auf WebDAV-Server können XML-Dateien direkt aus Internet Explorer mit dem Menüpunkt
Mit Adobe FrameMaker 9 bearbeitenausgecheckt werden; dies kann ich mangels eines eigenen WebDAV-Servers nicht ohne weiteres testen, finde aber den Menüpunkt!
Die Möglichkeit, die Konfigurationsdatei structapps.fm nicht mehr nur im FrameMaker-Programmpfad anzulegen, wird die Pflege von Strukturapplikationen für Arbeitsgruppen erleichtern. So können alle relevanten Dateien auf einem zentralen Laufwerk abgelegt werden und die Installation an den Arbeitsplätzen vereinfacht sich. Natürlich nur, wenn der Prozess ein echtes XML-Roundtripping enthält, denn für die Zuweisung der Strukturapplikation muss zunächst eine XML-Datei geöffnet werden. Was passiert, wenn ich diese als .fmspeichere und erst später wieder als XML speichere, wird dann noch die nicht-lokale Strukturapplikation gefunden?
Die Links zu den Artikeln:
Veröffentlicht unter FrameMaker, XML/XSL
Kommentare deaktiviert für FrameMaker 9: Weitere technische Bonbons
tekom-Frühjahrstagung 2009: Tutorial
Vom 2.-3.4.2009 findet in Dortmund die tekom-Frühjahrstagung 2009 statt. Diese Veranstaltung besuche ich nicht so regelmäßig wie die Jahrestagung im Herbst. Auch einen Stand werde ich nicht haben, aber quasi zum Auftakt der Tagung (Do, 8:45 Uhr) halte ich ein Tutorial:
XML-Publishing mit Adobe InDesign oder Adobe FrameMaker
Wer es plant oder bereits geschafft hat, die Dokumentation XML-basiert zu erstellen, steht vor der Aufgabe, diese auch für PDF bzw. Druck zu publizieren. Die »natürliche« Lösung wäre die vollautomatische PDF- Erstellung mittels einer XSL-FO-Transformation. Je nach Anspruch an die Optik oder Komplexität des Layouts kann das beliebig aufwändig werden; und natürlich sind auch keine Umbruch-Korrekturen in letzter Minute mehr möglich.
Eine hybride Lösung besteht darin, den eigentlichen Seitenumbruch nach wie vor von einem DTP-Programm machen zu lassen. Dies ermöglicht eine Aufgabenteilung zwischen vorbereitender Programmierung (ganz ohne geht es nicht!) und herkömmlichen Formatkatalogen.
Das Tutorial zeigt für die aktuellen Versionen von Adobe InDesign und Adobe FrameMaker, wie die Applikationen darauf vorbereitet sind, XML-Daten zu publizieren und will Sie dabei unterstützen, diese Fragen beantworten:
- Wie geht man vor?
- Was braucht man dazu?
- Wann ist welches Programm, welche Methode sinnvoll?
Es ist geplant, die verwendeten Beispielfälle nach der Tagung zum Nachvollziehen zur Verfügung zu stellen.
Präsentation und Beispieldaten
- Präsentation XML-Publishing mit InDesign und FrameMaker
- [Beispieldaten] (in Vorbereitung)
Veröffentlicht unter FrameMaker, InDesign, tekom/tcworld, Vorträge, XML/XSL
Verschlagwortet mit Dortmund, FrameMaker, InDesign, tekom 2009, Tutorial, XML-Publishing
2 Kommentare
FrameMaker 9 XML: Wertebereiche für Zahlen vorgeben
Nahezu unbeobachtet hat sich eine Neuerung in die Regeln für EDDs bei FrameMaker 9 eingeschlichen. Im Zuge der Unterstützung für XML Schema zusätzlich zu DTDs wurde oft kritisiert, dass dahinter ja doch nur eine Konvertierung Schema → DTD mit dem Verlust der erweiterten Spezifikationsmöglichkeiten von XML Schema steckte. Und da DTDs sowieso leichter lesbar sind… sind wir auch so zurecht gekommen.
Jetzt unterstützen FrameMaker-EDDs eine (hoffentlich nur erste) Funktion: Sie können für jedes Element festlegen, ob der Textinhalt streng numerisch sein soll und dabei unterscheiden zwischen Ganzzahl oder realen Zahlen sowie optional einen Wertebereich angeben. Bei Verletzung der Regel erscheint der Text rot in der Strukturansicht und bei der Prüfung des Dokuments wird die Fehleingabe auch verständlich gemeldet.
Aber wofür würden Sie das einsetzen? Mir fällt auf die Schnelle keine Anwendung ein…
Veröffentlicht unter FrameMaker, XML/XSL
Kommentare deaktiviert für FrameMaker 9 XML: Wertebereiche für Zahlen vorgeben
Standardstruktur oder besser nicht?
Ich habe bereits verschiedentlich auf den zweifelhaften Nutzen von Standards beim Wechsel zu XML-strukturierter Dokumentation hingewiesen (zum Beispiel
hier
und
hier), aber nun finde ich eine Entscheidungstabelle auch in der Dokumentation zu FrameMaker 9: Im Abschnitt »Implementieren des strukturierten FrameMaker-Formats« findet sich am Ende folgende Tabelle mit »einige[n] Faktoren, von denen es abhängt, ob Sie eine Standardspezifikation übernehmen oder eigene Strukturen erstellen sollten.« (Hervorhebungen von mir)
| Standard | Eigene Struktur |
| Sie müssen [1] Inhalte übermitteln, die einem gebräuchlichen Standard entsprechen. Zum Beispiel müssen viele Auftragnehmer der US Army Unterlagen beibringen, die einem veröffentlichten Standard entsprechen. | Sie möchten eine Struktur erstellen, die Ihrer Inhaltsanalyse genau entspricht. |
| Ihre Anforderungen entsprechen weitgehend einer vorhandenen Struktur. Sie müssen nur wenige Änderungen an der Standardstruktur vornehmen. | Laut Ihrer Inhaltsanalyse stimmen die Informationen mit den vorhandenen Strukturen nicht genau überein. |
| Sie möchten nicht viel Zeit für die Erstellung einer Struktur aufbringen und sind bereit, den Aufbau Ihrer Materialien zu ändern [2], um ihn in die vorhandene Struktur einzupassen. | Die Struktur muss mit dem Inhalt genau übereinstimmen. Eine längere Implementierungsdauer [3] ist ein akzeptabler Preis dafür, dass das Ergebnis genau Ihren Vorstellungen entspricht. |
| Ihnen fehlen das Fachwissen oder die Ressourcen zur Erstellung eigener Strukturen. | Ihnen stehen genügend feste oder freie Mitarbeiter zur Verfügung, die sich um die Strukturerstellung kümmern können. |
[1]: Klar, wenn Sie müssen, dann führt daran kein Weg vorbei, Ende der Diskussion.
[2]: Wenn Sie den Aufbau Ihrer Materialien ändern müssen, bedeutet das konzeptionelle und redaktionelle Arbeit. Das ist lästig, wenn Sie Ihre diesbezüglichen Hausaufgaben schon gemacht haben und mit der Dokumentationsstruktur zufrieden sind. Unterschätzen Sie keinesfalls den dann anfallenden doppelten Paradigmen-Wechsel: XML-strukturiertes Arbeiten und gleichzeitig eine andere Doku-Struktur. Weder ist es sinnvoll Ihre Doku in eine Standardstruktur hineinzupressen, noch werden Sie erfolgreich damit sein eine vorhandene Struktur so lange zu verbiegen, bis es passt. Außer:
[3]: Wenn Sie eine individuelle Struktur auf Basis einer Standardstruktur (mit einer möglicherweise bereits bekannten Nomenklatur = Elementnamen) erstellen, Sie sich aber nicht sklavisch daran halten, minimiert sich der Aspekt der längeren Implementierungsdauer. Daran glaube ich sowieso nicht, denn auch beim Einsatz von DocBook, DITA und Co. müssen Sie vorab festlegen, welche der vielen dort vorgesehenen Elemente Sie verwenden wollen und welche nicht.
Denn: Der Erstellungsaufwand, der Pflegeaufwand, aber auch der Schulungsaufwand steigt bei jeder XML-Struktur mit der Anzahl der vorhandenen Elemente!
Und da sieht eine schlanke, eigene Struktur ganz schnell besser aus als ein standardisierter Moloch. Meine Devise ist hier ganz einfach: So wenig wie möglich, so viel wie nötig. Und das bezieht sich dann auch auf die Kosten.
Veröffentlicht unter XML/XSL
Kommentare deaktiviert für Standardstruktur oder besser nicht?