DITA-Reifemodell

(Auszug aus "DITA - Der neue Standard für Technische Dokumentation" von Johannes Hentrich)

Wenn ein Umstieg auf DITA in Betracht gezogen wird, stellt sich früher oder später die Frage nach den zu erwartenden Kosten. Eine Antwort ist pauschal nicht zu geben und hängt weitgehend davon ab, mit welcher Konsequenz der Umstieg auf DITA erfolgen soll. In der Praxis bedeutet dies, je mehr Funktionalitäten von DITA genutzt werden sollen, desto höher wird der Aufwand für den Umstieg ausfallen. Was kostet es? geht detailliert auf die Frage ein, inwieweit die Kosten von den genutzen Funktionalitäten abhängen.

Als Richtschnur für die zu erwartenden Investitionen kann auch das DITA-Reifemodell von Michael Priestley und Amber Swope dienen. Hier werden sechs Stufen genannt, die bis zu einem kompletten Umstieg und zur Nutzung von DITA durchlaufen werden müssen:

  • Migration der Inhalte
  • Wiederverwendung und Ausgabe der Inhalte
  • Spezialisierung und Anpassung
  • Automation und Integration
  • Semantik „on demand“
  • Universelles DITA-Ökosystem

DITA-Reifemodell

Abbildung: DITA-Reifemodell.

Migration der Inhalte

Beim Umstieg auf DITA steht am Anfang praktisch immer die Migration der bestehenden Inhalte in die XML-basierte Topicstruktur von DITA. Dabei trifft die Aussage aus dem Dokument Migrating from Unstructured to Structured FrameMaker von Adobe hundertprozentig zu: eine Migration ist sowohl eine Gelegenheit als auch eine Herausforderung.

Vor der Migration können die bestehenden Inhalte (legacy content) entweder unstrukturiert oder strukturiert vorliegen. Zudem können die Inhalte auch in zahlreichen Dateiformaten wie Word, FrameMaker, InDesign vorliegen.

Für eine Migration der bestehenden Inhalte nach DITA spielen weniger die Dateiformate ein Rolle, sondern eher, inwieweit die Inhalte strukturiert sind. Eine Migration von gut strukturierten Inhalten aus einer Word-Datei kann unter Umständen einfacher zu realisieren sein als eine Migration von unstrukturierten Inhalten aus einer FrameMaker-Datei.

Oftmals ist selbst die Migration von strukturierten Inhalten nach DITA nicht ganz einfach. Das kann vor allem dann der Fall sein, wenn die strukturierten Inhalte wenige oder keine Strukturelemente aufweisen, die einer Topicstruktur ähneln. Somit sind Aussagen wie „Je strukturierter die Inhalte, desto einfacher die Migration“ mit Vorsicht zu genießen.

Stellvertretend für die zahlreichen Möglichkeiten, bestehende Inhalte nach DITA zu überführen, sei hier auf die Überführung von Inhalten aus Word zu DITA eingegangen. Word wird häufig nachgesagt, das beste Werkzeug zu sein, um unstrukturierte Dokumente erstellen zu können. Jedoch können in Word Inhalte dadurch strukturiert werden, indem Formatvorlagen definiert werden, die von den Technischen Redakteuren zur Formatierung beziehungsweise Kennzeichnung der Inhalte verwendet werden müssen. Damit lassen sich dann auch sehr gut strukturierte Dokumente erzeugen.

Die Überführung von Word-Dateien nach DITA kann zum Zeitpunkt des Erscheinens dieses Buchs nur indirekt durchgeführt werden. Zwei Wege haben sich inzwischen in der Praxis etabliert:

  • Die Word-Datei wird als HTML abgespeichert. Die HTML-Datei wird mit dem Migrations-Werkzeug h2d, welches Bestandteil des DITA Open Toolkits ist, nach DITA übergeführt.
  • Die Word-Datei wird in FrameMaker importiert. Die FrameMaker-Datei wird mit Mif2Go von Omni Systems nach DITA übergeführt.

Macht man sich bewusst, wie wenig Struktur eine HTML-Datei im Gegensatz zu einer DITA-XML-Datei aufweist, wird sofort deutlich, wie wenige Strukturinformationen bei der Migration transportiert werden. Bei der Lösung über FrameMaker und Mif2Go verhält es sich kaum anders.

Damit wird deutlich, dass eine Migration nur in beschränktem Maße automatisiert durchgeführt werden kann. Der Grundstein kann damit zwar gelegt werden, aber davon ausgehend sind noch etliche weitere Schritte nötig, um die Inhalte schließlich in DITA-gerechter Form zur Verfügung zu haben. Ein manuelles Eingreifen von Seiten des Technischen Redakteurs ist hier fast immer erforderlich.

Wenn von Migration gesprochen wird, ist vor allem die Überführung von bestehenden Inhalten in DITA Topics gemeint. Damit ist dann die Basis geschaffen, die Inhalte zukünftig topicorientiert bearbeiten zu können. Mit der Migration ist aber auch zu berücksichtigen, dass danach nicht nur die bestehenden Inhalte in einer neuen Struktur vorliegen, sondern dass dies auch meistens bedeutet, dass der Technische Redakteur

  • mit neuen Werkzeugen arbeiten muss, das heißt, beispielsweise mit XML-Editoren,
  • sich mit einem neuen Konzept zur Erstellung von Technischer Dokumentation befassen muss, das heißt: es ist nunmehr ein strukturiertes, topic-orientiertes Arbeiten erforderlich,
  • sich mit neuen Technologien wie beispielsweise XSL befassen muss, um die gewünschten Ausgabemedien erzeugen zu können.

Der erste Schritt bei der Einführung von DITA, das heißt, die Migration, ist daher in der Praxis häufig auch der schwierigste. Erschwert wird der Schritt zum einen durch die häufig unterschätzten Kosten, die bei der Überführung der bestehenden Inhalte in DITA-gerechte Inhalte anfallen. Damit verbunden ist auch, dass die benötigte Zeit für die Migration oftmals als zu optimistisch kalkuliert wird. Zum anderen wird bei einer Migration häufig auch die Tatsache unterschätzt, dass die Technischen Redakteure, die zukünftig mit DITA arbeiten sollen, mit der neuen Arbeitsweise erst vertrautgemacht werden müssen und dass sie auch dann daran festhalten, mit DITA zu arbeiten, wenn Schwierigkeiten auftreten. Um es neudeutsch auszudrücken: das Team der Technischen Redakteurinnen muss sich zu DITA „committen“.

Beachten Sie also nicht nur den technischen Aspekt bei einer Migration, sondern auch alle persönlichen Aspekte, die stets eine Rolle spielen, wenn Veränderungen auftreten.

Ist keine Migration erforderlich, kann sofort mit dem zweiten Schritt begonnen werden, das heißt, der Etablierung einer Arbeitsumgebung, die eine komfortable Wiederverwendung von Topics und die Verarbeitung der Topics zu Ausgabemedien ermöglicht.

Wiederverwendung und Ausgabe der Inhalte

Nach der Migration stehen die Inhalte zunächst einmal als einzelne Topics zur Verfügung. Im zweiten Schritt werden Strategien entwickelt, wie Topics und die Inhalte in den Topics wiederverwendet werden sollen. Zudem stehen Sie im zweiten Schritt vor der Aufgabe, eine Produktionsumgebung zu schaffen, mit der die Topics gemäß dem eigenen Corporate Design für die gewünschten Ausgabemedien produziert werden können.

Die Wiederverwendung von Inhalten gehört zu den zentralen Konzepten in DITA. Wie in Inhalte wiederverwenden mit Maps und conref beschrieben ist, werden in DITA zwei Mechanismen angewandt, um Inhalte wiederverwenden zu können:

  • Über Maps werden die Topics über die Referenzierung in einer Hierarchie organisiert, um beispielsweise das Inhaltsverzeichnis einer Online-Hilfe zu generieren.
  • Mit dem conref-Mechanismus können Inhalte gezielt über deren Elemente ausgezeichnet werden, sodass diese Inhalte über ihre Referenzierung in anderen Topics wiederverwendet werden können.

Unabhängig davon, welcher Mechanismus zur Wiederverwendung von Inhalten verwendet wird, ist eine Strategie zu entwickeln, mit der verfolgt und kommuniziert werden kann, wo und welche Topics referenziert, welche Topics neu erstellt und welche Topics gerade aktualisiert wurden. Primäre Aufgabe ist es vor allem, eine Umgebung zu schaffen, in der die Topics und deren Inhalte wiedergefunden werden können. Oft wird die Anzahl der zu verwaltenden Topics unterschätzt, was dafür sorgt, Arbeitsumgebungen zu etablieren, in der das Auffinden von Inhalten sehr erschwert wird.

Wird DITA nur für die Erzeugung einiger weniger Dokumente verwendet, mag unter Umständen ein einfaches Dateisystem ausreichen, um die Dateien zu verwalten. Soll DITA erst einmal an ein oder zwei Dokumenten getestet werden, so ist ein Dateisystem auf alle Fälle ausreichend. Während Sie mit DITA und der Organisation von DITA-Dateien Erfahrung sammeln, können weitere Konzepte entwickelt werden.

Sind mehrere Technische Redakteure an der Produktion von Technischer Dokumentation beteiligt, kann das Dateisystem durch eine Software zur Versionsverwaltung, zum Beispiel Subversion, ersetzt werden. Mit einer solchen Software stehen zahlreiche Möglichkeiten zur Verfügung, wie zum Beispiel das Ein- und Aus-Checken von Dokumenten, das Abspeichern von Meta-Daten oder die Versionierung. Zudem können die Kosten immer noch gering gehalten werden, da Subversion Open Source-Software ist, das heißt, bei deren Nutzung keine Lizenzgebühren anfallen.

Wird eine noch komfortablere Lösung angestrebt, so kommen Content-Management-Systeme in Frage. Wie im Content-Management gezeigt wird, ist es keine einfache Aufgabe, ein passendes Content-Management-System zu den eigenen Anforderungen zu finden. Darüber hinaus eignet sich zum Zeitpunkt des Erscheinens dieses Buchs noch kaum ein Open Source Content-Management-System dafür, im Zusammenhang mit DITA eingesetzt zu werden. Somit ist bei der Einführung eines Content-Management-Systems auf jeden Fall mit Kosten zu rechnen, wobei nicht allein die Lizenzpreise ins Gewicht fallen, sondern auch die Kosten für die Anpassung, zum Beispiel an ein Redaktionssystem oder XML-Editoren, sowie die Kosten für die Schulung der Technischen Redakteure.

Redaktionsumgebungen für DITA und Content-Management geben Ihnen Hinweise, wie Sie eine passende Arbeitsumgebung für Ihre Arbeit mit DITA aufbauen können.

Nicht völlig losgelöst von der Auswahl des entsprechenden Werkzeugs zur Verwaltung der Topics und der Inhalte der Topics, beschäftigt sich die Frage, wie die Topics für die gewünschten Ausgabemedien generiert werden sollen. Denn eine Umgebung zur Verarbeitung der Topics zu Ausgabemedien, zum Beispiel das DITA Open Toolkit, kann mit Ausnahme beim Dateisystem in das entsprechende Werkzeug bereits integriert werden.

So kann Subversion beispielsweise mit Eclipse, einer integrierten Entwicklungsumgebung, verwendet werden, die auch die Integration des DITA Open Toolkits ermöglicht.

Ebenso können XML-Editoren und Content-Management-Systeme oftmals so weit angepasst werden, dass eine Produktion der gewünschten Ausgabe-
medien aus dem System heraus erfolgen kann. Hier hängen die zu erwartenden Kosten primär vom Grad der Integration ab.

Unabhängig davon, wo das DITA Open Toolkit zur Produktion der Ausgabemedien verwendet oder integriert wird, ist eine Anpassung der Stylesheets notwendig, damit die Ausgabemedien gemäß den Designvorgaben erzeugt werden können. Wie in DITA Open Toolkit gezeigt wird, gibt es etliche Anpassungsmechanismen – wenn auch nicht immer ausreichend dokumentiert – die Stylesheets in der Weise zu modifizieren, damit die Ausgabemedien in dem gewünschten Design produziert werden können.

Berücksichtigen Sie bei der Planung, dass die Stylesheets für jedes gewünschte Ausgabemedium angepasst werden müssen, das heißt beispielsweise die Cascading Stylesheets für die HTML-Dateien und die XSLT-Dateien für die PDF-Dateien.

Die Produktion der Ausgabemedien kann auch ohne das DITA Open Toolkit erfolgen. Wird beispielsweise FrameMaker als XML-Editor für DITA verwendet, so kann die Produktion der PDF-Dateien über FrameMaker erfolgen. Aber auch hier muss das Layout gemäß dem Corporate Design angepasst werden. Kein Formatierungsmechanismus liefert das Corporate Design frei Haus.

Spezialisierung und Anpassung

In den ersten beiden Stufen des DITA-Reifemodells, das heißt, bei der Migration und bei der Wiederverwendung von Inhalten, werden die Elemente von DITA praktisch unverändert übernommen. Die zu migrierenden Inhalte werden in die bestehenden Topictypen übergeführt und mit den Elementen der standardmäßigen vorgegeben Domains ausgezeichnet. Bei der Wiederverwendung der Inhalte werden die vorhandenen Mechanismen von DITA herangezogen.

In der dritten Stufe des DITA-Reifemodells geht man einen Schritt weiter und passt DITA gemäß den eigenen Anforderungen an. Damit werden nicht mehr nur die vorgegebenen Informationsstrukturen von DITA verwendet, sondern es werden neue, den eigenen Bedürfnissen entsprechende Informationsstrukturen erzeugt. Die Generierung der neuen Informationsstrukturen geschieht in DITA über den Mechanismus der Spezialisierung. In folgenden Fällen ist eine Spezialisierung notwendig:

  • Die bestehenden Topictypen müssen um weitere Topictypen ergänzt werden. Mit den Topictypen „Aufgabe“, „Konzept“, „Referenz“ und „Glossar“ stehen standardmäßig sehr allgemeine Topictypen zur Verfügung, die für eine Software-Dokumentation durchaus ausreichen können. Auch für die Technische Dokumentation aus anderen Fachgebieten können die vorgegebenen Topictypen unter Umständen ausreichen. Wie die Praxis zeigt, sind jedoch oft Verfeinerungen der bestehenden Topictypen notwendig.
  • Weitere Domains zur Auszeichnung von Inhalten müssen erzeugt werden. DITA bietet standardmäßig Domains, mit denen Inhalte aus Technischer Dokumentation für Software ausgezeichnet werden können. Wenn DITA nicht für Software-Dokumentation eingesetzt wird, ist eine Spezialisierung der Domains unumgänglich.
  • Die bestehenden Informationsstrukturen müssen für Ausgabemedien angepasst werden. Mit DITA 1.1 wurde beispielsweise die Bookmap eingeführt, eine Spezialisierung der Map, um Topics für das Medium Buch organisieren zu können. Für andere Ausgabemedien, zum Beispiel mobile Endgeräte, können daher ebensolche Spezialisierungen erforderlich sein.

Wird eine Spezialisierung durchgeführt, so sind für die Abschätzung des Aufwands zwei Aspekte zu berücksichtigen:

  • Für die Spezialisierung müssen die bestehenden DTDs und Moduldateien modifiziert, beziehungsweise es müssen neue DTDs und Moduldateien erstellt werden. Bei der Neuerstellung kann auf die bestehenden DTDs und Moduldateien als eine Art Kopiervorlage zurückgegriffen werden. Wie Spezialisierung zeigt, ist der technische Prozess der Spezialisierung, das heißt die Erstellung der DTDs und der Moduldateien, relativ einfach zu realisieren. Weitaus aufwändiger gestaltet sich in der Praxis der Abstimmungsprozess darüber, was spezialisiert werden soll und in welcher Weise.
  • Die Stylesheets, seien es die Cascading Stylesheets zur Generierung von HTML-Dateien oder die XSLT-Stylesheets zur Erzeugung von PDF-Dateien, erfordern unter Umständen eine Anpassung. Wenn Topics, Domains oder andere Informationsstrukturen spezialisiert werden, ist eine Anpassung der Stylesheets des Open Toolkits nicht zwingend notwendig. Die Stylesheets können die neuen Elemente ebenso verarbeiten wie die bereits vorhandenen. Dabei werden die neuen Elemente in der gleichen Weise verarbeitet wie die Elemente, von denen sie spezialisiert wurden. Sollen die neuen Elemente in den Ausgabemedien in einer anderen Weise verarbeitet werden als die Elemente, von denen sie spezialisiert wurden, müssen die Stylesheets angepasst werden. Diese Anpassungen sind technisch oft aufwändiger als die Spezialisierung einer DTD. Denn es gilt hier viele Dinge zu berücksichtigen, wie zum Beispiel den Grad der Integration des Verarbeitungsmechanismus für die Ausgabemedien, wie dem DITA Open Toolkit, oder den Grad der Unterstützung der Editoren für das WYSIWYG.

Zusammengefasst lässt sich feststellen, dass der erforderliche Aufwand bei der Spezialisierung einer DTD oder einer Moduldatei eher in der Ausarbeitung der passenden Strategie als in der technischen Realisierung besteht. Bei der Umsetzung der Spezialisierung für die Verarbeitungsmechanismen zur Produktion der Ausgabemedien stehen die technischen Aspekte im Vordergrund.

Automation und Integration

Mit der Anpassung von DITA auf die eigenen Bedürfnisse mittels der Spezialisierung von Informationsstrukturen können die Inhalte in der gewünschten Form erfasst und verarbeitet werden. In einem nächsten Schritt kann darüber nachgedacht werden, wie Publikationsprozesse automatisiert werden können.

Insbesondere können in diesem Stadium Überlegungen angestellt werden, wie die erfassten Informationen nicht nur für die Technische Dokumentation genutzt werden können, sondern beispielsweise auch für Marketing-Dokumente oder Trainingsunterlagen. Es gilt also, DITA in die gesamte Unternehmenskommunikation zu integrieren und nicht nur als Anwendung für die Technische Dokumentation zu verstehen. Der Grad der Wiederverwendung der Informationen wird über das ganze Unternehmen ausgedehnt.

Häufig stehen Überlegungen zur Automation von Publikationsprozessen und der Integration anderer Prozesse, zum Beispiel des Übersetzungsprozesses, schon vor der Einführung von DITA an. Dabei werden primär Fragen erörtert, wie Technische Dokumentation billiger produziert werden kann und die erfassten Informationen in den Prozess der Unternehmenskommunikation integriert werden können. Und auch Überlegungen, wie der Lebenszyklus von Dokumenten optimiert, beziehungsweise wie ein Lebenszyklus aktiv gestaltet werden kann, stehen oftmals noch vor der Einführung von DITA.

In der Praxis jedoch kann die Automation und Integration von Produktionsprozessen erst realisiert werden, wenn die ersten drei Stufen des DITA-Reifemodells durchlaufen sind.

In der vierten Stufe wird sich dann auch nicht mehr die Verwendung eines Content-Management-Systems vermeiden lassen. Sollen Publikationsprozesse und deren Workflow in einem Unternehmen effektiv gesteuert werden, ist dies kaum ohne ein zentrales System möglich.

Die Einführung eines Content-Management-Systems bedeutet neben dem oft erheblichen finanziellen Aufwand auch einen nicht zu unterschätzenden Aufwand, der für die Einführung des Systems notwendig ist. Dabei gilt es beispielsweise zu klären,

  • welche Informationen von wem wiederverwendet werden sollen,
  • wer welche Ausgabemedien produzieren darf,
  • wie die Übersetzungsprozesse integriert werden sollen,
  • welche Workflows für Technische Redakteure und Arbeitsgruppen erforderlich sind,
  • welche Meta-Daten bei der Erfassung und Bearbeitung von Informationen erfasst werden müssen.

Organisatorische Fragen stehen also bei der Automation und Integration von Produktionsprozessen im Vordergrund. Da DITA keinen eigenen Mechanismus zur Versionsverwaltung und zur Steuerung eines Workflows hat, müssen diese Steuerungskomponenten extern umgesetzt werden. Dies erfordert die Entwicklung eines passenden Konzepts, das in einem Content-Management-System umgesetzt werden kann.

Gleiches ist in Bezug auf die Übersetzung zu sagen. Auch hier bietet DITA bisher keine eigenen Strukturen und Konzepte für ein Übersetzungsmanagement. Notwendige Strukturen müssen daher in ein externes System implementiert werden. Das bedeutet, dass auch hier viel konzeptionelle Arbeit zu leisten ist.

Semantik „on demand“

Wenn über den Einsatz von DITA nachgedacht wird, so steht zunächst die Frage im Vordergrund, wie die Informationen im eigenen Unternehmen mit DITA am besten erfasst und verwaltet werden können. Jedoch existiert kein Unternehmen im Universum allein, sondern praktisch jedes Unternehmen erhält Inhalte von externen Quellen. Und ebenso wird ein Unternehmen Informationen für andere Unternehmen bereitstellen müssen.

Die von extern Quellen erhaltenen Inhalte können als DITA-Dokumente geliefert werden, oder aber, was wesentlich häufiger der Fall ist, als strukturierte und weniger strukturierte Dokumente, die in keinerlei Zusammenhang mit DITA stehen.

Wenn in einem Unternehmen ein System aufgebaut ist, mit dem Informationen DITA-konform erfasst und verwaltet werden, stellt sich die Frage, wie mit externen Informationen umgegangen werden soll. Gerade wenn Daten regelmäßig und eventuell auch in großen Mengen angeliefert werden, ist zu untersuchen, inwieweit externe Inhalte in das bestehende DITA-Ökosystem integriert werden sollen.

Für die Integration externer Inhalte sind folgende Möglichkeiten denkbar:

  • In DITA werden Elemente spezialisiert, deren Zweck es ist, Inhalte strukturierter Dokumente aufzunehmen. DITA stellt dazu beispielsweise ein <data>-Element zur Verfügung. Über eine Domain-Spezialisierung kann dann noch eine Semantik nach Bedarf, das heißt eine Semantik „on demand“, bereitgestellt werden.
  • Für unstrukturierte Dokumente werden in DITA „Hüllen“ zur Verfügung gestellt, in denen die unstrukturierten Dokumente erfasst werden. Beispielsweise könnte man für ein unstrukturiertes Word-Dokument eine Map als Hülle verwenden. In der Map werden der Titel, Meta-Daten und die Referenz zum Word-Dokument hinterlegt. Damit wäre das unstrukturierte Word-Dokument auch in einem Content-Management-System suchbar, das strukturierte Daten verwaltet.
  • Externe DITA-Dokumente können über den Prozess der Generalisierung und über die Bereitstellung einer Semantik integriert werden.

Ein zweites Problem ist die Bereitstellung von Informationen für externe Unternehmen. Häufig sind das die Ausgabemedien, die aus den DITA-XML-Dateien erzeugt werden. Häufig aber sind nicht das Endprodukt gefragt, sondern die originalen XML-Dateien, die dann im externen Unternehmen weiterverarbeitet werden.

Wenn die Daten nicht direkt übernommen werden können, bietet es sich an, die DITA-Daten in die erforderliche Semantik zu überführen. Auch hier kann dann wieder von einer Semantik „on demand“ gesprochen werden.

Darüberhinaus können die Inhalte aus den DITA XML-Dateien dazu verwendet werden, beispielsweise RSS-Feeds zu produzieren. Ein RSS-Feed ist ein Service, der ähnlich einem Nachrichtenticker die Überschriften mit einem kurzen Textanriss und einem Link zum originalen Topic enthält. RSS-Feeds selbst sind XML-Dateien.

Unabhängig davon, ob externe Dateien in das bestehende DITA-Ökosystem integriert werden sollen oder aus den bestehenden DITA XML-Dateien neue XML-Dateien produziert werden müssen, bedeutet dies, dass das bereits eingesetzte Content-Management-System an die neuen Anforderungen angepasst werden muss. Die rein technische Seite der Anpassung stellt erfahrungsgemäß in der Praxis die geringsten Probleme dar. Wie so häufig muss eher dafür Sorge getragen werden, dass Organisationsstrukturen geschaffen werden, damit den Technischen Redakteuren an den Schnittstellen die notwendige Unterstützung zukommt.

Universelles DITA-Ökosystem

Als letzte Stufe sehen Michael Priestley und Amber Swope im DITA-Reifemodell ein universelles DITA-Ökosystem. Mit ihrer Vision schwebt ihnen ein auf DITA basierendes semantisches Ökosystem vor, mit dem Daten über Unternehmen und Standards hinweg ausgetauscht werden können. Und bei den Unternehmen beziehen sich Priestley und Swope explizit auf Unternehmen, deren Informationsprodukte nicht primär aus Technischer Dokumentation bestehen, sondern auf Unternehmen wie beispielsweise Verlage oder Regierungsbehörden.

Damit DITA diesen Anforderungen gerecht wird, ist es zweifellos erforderlich, dass die bestehenden Möglichkeiten von DITA deutlich erweitert werden müssen. DITA hat seinen Ursprung in der Software-Dokumentation, was dem Standard auch allzu deutlich anzumerken ist. Bestrebungen, DITA in andere Richtungen zu erweitern, sind zwar vorhanden, aber der Weg hin zu einem universellen Austauschstandard ist noch sehr weit.

Neben der Bereitstellung der XML-basierten Infrastruktur besteht die weitaus größere Herausforderung darin, XML überhaupt als Datenaustauschformat in Bereichen zu etablieren, in denen Technische Dokumentation nicht die Hauptrolle spielt. Selbst im Bereich der Technischen Dokumentation, in dem sich die Verwendung von strukturierten Dokumenten und XML als Datenaustauschformat geradezu anbietet, ist die Anwendung von XML alles Andere als eine Selbstverständlichkeit. Häufig führt erst eine zwingende Notwendigkeit dazu, sich mit diesem Thema zu beschäftigen.

Dennoch ist die Vision von Priestley und Swope nicht so ohne Weiteres vom Tisch zu wischen. Denn je mehr Unternehmen ihre Daten über einen universellen Standard austauschen können, umso vervoller sind die Daten des einzelnen Unternehmens. Der aus vielen anderen Bereichen bekannte Netzwerkeffekt spielt auch hier eine wichtige Rolle.

Für ein Unternehmen, das DITA einsetzen will, bedeutet dies, dass sich ein Blick über die eigenen Grenzen hinweg auf jeden Fall lohnt. Zum einen können Mitstreiter gefunden werden, die Hilfestellung leisten können, und zum anderen kann der Nutzen von DITA deutlich erhöht werden.

  

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema DITA bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

Copyright © 2008 XLcontent Verlag
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "DITA - Der neue Standard für Technische Dokumentation" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

XLcontent Verlag, Pflegerstraße 40, 81247 München