Schlagwort-Archive: XML

Fluch und Segen von DITA

Eigentlich sollte der Beitrag »Fluch und Segen von Standards« heißen, aber das allgegenwärtige Buzzword DITA wollte ich doch im Titel haben. Es steht hier stellvertretend auch für DocBook und möglicherweise andere Dokumentations-relevante XML-Strukturvorschriften.

XML über Alles

Segen

Im übertragenen Sinn ist XML nur eine generelle Rechtschreibvorschrift für den Aufbau von XML-Dokumenten. Eine DTD oder ein XML-Schema ist ein Wortschatz und eine Grammatik, mit der Sie den erlaubten Satzbau und Wortarten festlegen können. Im Gegensatz zu HTML-Dokumenten, FrameMaker-Dokumenten, Word-Dokumenten sind das reichlich abstrakte Konzepte, und ich werde den Verdacht nicht los, dass sich hier immer noch manch Entscheider mit dem Verständnis schwer tut.

Da ist es natürlich wunderbar – und hier komme ich zum Segen –, wenn es neben den ach so allgemeinen XML-Dokumenten nun auch DITA-Dokumente oder Docbook-Dokumente gibt, die nicht nur XML sind sondern auch noch kompatibel zu weltweiten, offenen Standards.

Kompatibilität und Standard werden zu primären Entscheidungsgründen, XML und die damit verbundenen generellen Möglichkeiten treten in den Hintergrund. Zu diesen Möglichkeiten zählen eine bessere Anpassung der Dokumentstrukturen an die Produktstruktur, effizientere Übersetzungs- und Publikationsprozesse, leichtere Einarbeitung weiterer Mitarbeiter ins Team. Aber diese Ziele treten gegenüber der Kompatibilität mit Standards zurück. »Standard, Standard über alles«, schallt es uns entgegen.

Exkurs: Natürlich kann man als abhängiger Mitarbeiter nichts falsch machen, wenn man einen Standard empfiehlt. Ganz nach dem Motto: »Es ist noch keiner gefeuert worden, weil er IBM gekauft hat.«

Fluch

Wenn ein Standard nicht wegen ganz konkreter Prozesse eingeführt wurde (wie für bestimmte XML-Prozesse zum Beispiel in der Luftfahrt), sondern um eine (durchaus sinnvolle) Lösung möglichst breit aufzustellen, lässt es sich nicht vermeiden, dass die Strukturvorschrift eine gewisses Maß an Beliebigkeit enthält und zahlreiche Elemente vorsieht. Denn eine große Verbreitung kann man schließlich nur erreichen, wenn die Anforderungen möglichst vieler potentieller Anwender berücksichtigt sind, oder?

Meine Erfahrung aus vielen Jahren Prozessoptimierung (Templates, Skripte, Abläufe) haben mich gelehrt: Die Anforderungen an die Dokumentation sind in jeder Firma unterschiedlich und richten sich im Wesentlichen nach der Produktstruktur. Sollte es einmal Übereinstimmung geben, wäre das zufällig. Genauso zufällig wäre es, wenn ein Standard genau auf die Anforderungen Ihrer Firma passte.

Und die Erfahrung mit XML-Projekten (darunter auch DocBook) zeigt mir: Die Aufwände für Arbeiten rund um eine Struktur sind proportional der Anzahl der Elemente und Attribute. Je mehr Elemente erlaubt oder vorgesehen sind, desto mehr Arbeit entsteht bei der Formatierung für jedes Medium und auch bei eventuellen Anpassungen der Struktur. Zudem bedeutet eine Vielzahl von Elementen auch einen erhöhten Schulungsbedarf, damit sich alle Autoren an eine festgelegte Interpretation der Elemente halten (ganz abgesehen davon, dass dies auch dokumentiert werden sollte).

Persönliches Fazit

Was leite ich daraus ab:

  1. Schauen Sie sich Standard-Strukturen genau an, es könnte ja (zufällig) sein, dass Ihre Bedürfnisse zu 100% abgedeckt werden, oder dass die Abweichungen toleriert werden können.
  2. Es gibt in der EDV keine »nahezu 100%«, für den Computer gibt es nur identisch oder nicht identisch, Eins oder Null, nichts dazwischen. Das heißt, schon mit der kleinsten Abweichung vom Standard (gerne »Spezialisierung« genannt) haben Sie die Zusatzaufgabe, diese Abweichung zu implementieren und in allen Prozessen zu berücksichtigen; und bei Aktualisierungen des Standards wiederholt sich der Aufwand.
  3. Ziehen Sie eine an Standards orientierte, aber grundsätzlich individuelle Strukturvorschrift in Betracht. Hier bekommen Sie mit der minimalen Anzahl von Elementen und Attributen eine Lösung mit allen Vorteilen von XML und den denkbar geringsten Folgeaufwänden.

Tipp für DITA-Interessierte

Scriptorium Publishing hat aktuell ein Dokument »FrameMaker 8 and DITA Technical Reference« veröffentlicht, in dem detailliert geschildert wird, wie man mit FrameMaker 8 und der mitgelieferten DITA-Applikation arbeitet. Das 55-seitige Dokument ist für nur $10 in deren Onlineshop erhältlich, das Inhaltsverzeichnis können Sie vorab einsehen.

Siehe auch »DITA und kein Ende«.

Veröffentlicht unter XML/XSL | Verschlagwortet mit , , , | Ein Kommentar

In Aalen: Neuerungen in FrameMaker 8

tekom-Logo

Am 21.10.2008 findet eines der regelmäßigen Treffen der tekom-Regionalgruppe Alb-Donau statt. Diesmal an der Hochschule in Aalen von 18:30 bis 21:30. Ich bin eingeladen, über die Neuerungen in FrameMaker 8 zu sprechen und freue mich auf eine vielseitige Diskussion. Mein Beitrag wird neben möglichst präzisen Antworten auf die Fragen der Teilnehmer unter anderem folgende Punkte umfassen:

  • Abgrenzung gegenüber InDesign (aus aktuellem Anlass)
  • Neues für DTP-Anwender (Template-basiertes Publishing)
  • Neues für XML-Anwender (Strukturiertes Publishing)
  • Neues für alle Anwender
  • Ursachen der teilweise zurückhaltenden Akzeptanz
  • Gründe für einen Umstieg

Die Teilnahme ist (wie immer) kostenfrei, eine Anmeldung bei Frau Dr. Grünwied (Gertrud.Gruenwied@stw.de, oder Tel. 0731–7130858) ist erwünscht.

Veröffentlicht unter FrameMaker, Vorträge | Verschlagwortet mit , , , | Kommentare deaktiviert für In Aalen: Neuerungen in FrameMaker 8

Sweet Suites?

Kombizange

Sarah O’Keefe (von Scriptorium Publishing, auf der tekom-Tagung mit einem Stand gegenüber meinem Stand 833 vertreten) nutzt ihr Blog Palimpsest zu einem Überblick über die von verschiedenen Seiten angebotenen Programmsammlungen (zum Original).

Angesichts der von allen Seiten angebotenen »integrierten Programmpakete« (MadCap MadPak, Adobe Technical Communication Suite, Author-it) fragt sie sich, welches denn nun ihre persönlichen Top-3-Anforderungen an zeitgemäße Autorensoftware erfüllt?

Veröffentlicht unter FrameMaker, XML/XSL | Verschlagwortet mit , , , , | Kommentare deaktiviert für Sweet Suites?

Grenzen von XSL-FO

Die automatische Erzeugung von PDF-Dateien aus XML-Daten mittels XSL-FO und einem FO-Prozessor ist der natürliche Konkurrent für XML-Publishing-Prozesse, die FrameMaker als Formatierer verwenden.

Aber wie weit können XSL-FO-Prozesse gehen oder, besser gefragt, was leisten diese Prozesse derzeit nicht. Auskunft darüber gab eine aktuelle Diskussion in der XSL-Mailing-Liste, die ich kurz zusammenfassen möchte (Link zum ersten Beitrag der Diskussion).

Generell muss man unterscheiden zwischen inhaltsbestimmten (content driven) und layoutbestimmten (layout driven) Publikationen.

Veröffentlicht unter FrameMaker, XML/XSL | Verschlagwortet mit , , | Kommentare deaktiviert für Grenzen von XSL-FO

Gründe für XML-strukturierte Doku-Erstellung

Neulich in der FrameMaker-Mailing-Liste: Da fragt doch jemand, ob überhaupt jemand mit strukturierten Dokumenten in FrameMaker arbeite? Es folgen einige Zitate aus den Antworten:

[…] aber FM unstrukturiert ist wie Essen mit nur einem Stäbchen: es geht, aber es nutzt das Potenzial nicht. (Thomas Böttiger)

[…] „Wenn man’s gewöhnt ist, ist es auch in der Hölle schön.“ [bezogen auf unstrukturierte Dokumente] (Thomas Reuter)

[…] Ich bin auch kein ausgesprochener Freund der ganzen XML/YML/ZML-Schiene (siehe auch http://www.readit-dtp.de/subpage.php?artnum=92), aber wenn ich schreibe, will ich nicht formatieren. Das lenkt mich ab. (Thomas Böttiger)

Selbstverständlich ist das XML-strukturierte Schreiben kein Selbstzweck (genauso wenig wie das Verwenden der DITA-Struktur) und die Diskussion motivierte mich, die Gründe zu sammeln, die für die Verwendung von XML-Strukturen sprechen:

Veröffentlicht unter FrameMaker | Verschlagwortet mit , , , | Kommentare deaktiviert für Gründe für XML-strukturierte Doku-Erstellung