Thomas Böttiger schrieb kürzlich:
[…] [es] heißt nicht umsonst DITA („Darwin Information Typing Architecture“):
»Grundsätzlich wird der Begriff Darwinismus verwendet, um die Evolutionstheorie von Darwin von anderen Evolutionstheorien zu unterscheiden, beispielsweise Lamarcks. Sie basiert auf der Vererbung, der Veränderung (Mutation) und der natürlichen Auslese.« (wikipedia)
[…] Das heißt: DITA lebt von der Anpassung. Sonst würde es ja »LITA«, nach Lamarck, heißen…
Sehr schön, diese Anmerkungen zu Darwin gefallen mir gut. Leider besteht ein guter Teil des »Buzzword«-Potentials von DITA aus der Standardisierung der Struktur, die zwar einerseits eine gute Basis für ein Eco-System rund um den Standard schafft, andererseits aber die Mutation, die Veränderung zum Besseren, zur Steigerung der Passgenauigkeit (Fitness) behindert. Wenn auch nur in den Köpfen vieler Vortrags- etc. Besucher.
- Ich habe erlebt, dass Firmen selbst mit dem überbordenden Reichtum von DocBook nicht zufrieden waren.
- Ich habe erwartet, dass Firmen mit der schlanken Eleganz von DocFrame nicht zufrieden waren, deshalb war die individuelle Anpassung dort von vorneherein vorgesehen.
- Die mir bekannten CMS-Hersteller sind ziemlich stark damit beschäftigt, ihre mit den Produkten gelieferten XML-Strukturen immer wieder kundenspezifisch anzupassen.
Also bin ich überhaupt nicht verwundert, wenn auch jede DITA-Lösung mehr oder weniger vom sogenannten Standard abweicht. Alles andere wäre eine Art Lottogewinn. Es ist auch sehr geschickt, in solchen Fällen von Spezialisierung zu sprechen, das klingt doch richtig positiv!
Wichtig ist:
- Sie arbeiten überhaupt XML-strukturiert.
- Sie wählen eine Struktur, die möglichst gut zu ihren Produkten und Prozessen passt.
Ob das dabei verwendete XML-Vokabular sich nun nach DITA (im Kern also XHTML) richtet, nach DocBook oder präzise auf die eigenen Produkte und Prozesse abgestimmt ist, spielt eine untergeordnete Rolle. Denn mit Hilfe von XSL-Transformationen kann man XML-Dateien in jede andere, logisch machbare Struktur umwandeln. [Oops, ich werde es wieder tun: ein Link zu meinem Schulungsangebot!]
Blickt man ein wenig zurück in der jüngeren Geschichte der (professionellen aber „unstrukturierten“) Dokumenterstellung findet man eine ganz ähnliche Problemstellung – und ich möchte die Frage stellen, ob die daraus gewonnenen Erkenntnisse übertragbar sind.
Selbst in gut organisierten technische Redaktionen, in denen es womöglich sogar ein Redaktionshandbuch mit strengen Formatvorgaben gibt (und Prozessen zur Überwachung/Einhaltung eben dieser – hallo Rohrstock!), lässt sich das Phänomen beobachten, dass Autoren irgendwann in eine Situation kommen, in der ihnen die Vermittlung der gewünschten Information mit den gegebenen Mitteln nicht mehr möglich erscheint. Je nach „Persönlichkeit“ des Autors (und womöglich der Größe des Rohrstocks…) wird dann entweder zum Mittel der „lokalen Formatüberschreibung“ gegriffen. Oder es wird – zumindest „philosophisch“ konsequenter – der vorhandene Absatz-/Zeichenformat-Katalog (bzw. das Template) entsprechend erweitert. Was zu Beginn und im Einzelfall dann auch noch vertretbar erschienen haben mag („diesen Sonderfall konnten wir bei der Template-Entwicklung noch nicht voraussehen, er ist aber wichtig und wird darum umgesetzt“), gerät jedoch mit den Jahren schnell zum kaum noch handbaren Problem: Nicht selten findet man in solchen „historisch gewachsenen Dokumenten“ dann entweder ein wüstes Chaos manueller, lokaler Formatabweichungen oder Formatkataloge mit gigantischem Umfang – Absatzformatkataloge mit Einträgen im deutlich dreistelligen Bereich sind mir durchaus schon untergekommen. Ich möchte es hier bewusst etwas überstrapazieren und diese Erweiterung der im ursprünglichen Template definierten Format-Kataloge als „Spezialisierung“ bezeichnen.
Egal ob es sich nun um ein streng reglementiertes Template oder um eine Strukturapplikation handelt: Das gemeinsame „Problem“ beider Ansätze ist, dass der Autor sämtliche zu erfassende Informationen in ein solches „Framework“ – etwas weniger freundlich könnte man es auch „Korsett“ oder „Zwangsjacke“ nennen – pressen muss, um „templatekonforme“ oder „valide“ Dokumente zu erzeugen. Stößt man an die Grenzen des Frameworks, stellt sich die Frage: Bewusst einen Verstoß gegen die Spezifikation in Kauf nehmen oder eine Erweiterung der Spezifikation anstoßen oder … halt: Vielleicht doch lieber nochmal vorher eine Aufwand-/Nutzen- – Nachteil-/Vorteil-Überlegung anstellen? Empfehlenswert ist meiner Erfahrung nach das Anstellen einer solchen Überlegung vor allem dann, wenn es sich bei der vermeintlich notwendigen Erweiterung vor allem um das Realisieren optisch-ästhetischer Ansprüche stellt. Es ist immer wieder schön zu sehen, wie sehr doch die WYSIWYG-Ära ganze Generationen von Autoren „geprägt“ hat… Es sollte also abgewägt werden, ob man sich z.B. den schönen, schlanken Formatvorlagen-Katalog „kaputt“ machen will, nur weil es ganz unverzichtbar notwendig erscheint, dass der Grafik-Callout nun unbedingt rechtsbündig zu stellen ist. Detailbeispiele könnte man hier einige nennen.
Die gleichen Überlegungen, die man über die klassischen Absatz- und Zeichenformat-Kataloge stellen kann, möchte ich hier also in das XML- und strukturierte FrameMaker-Szenario überführen. Denn die Frage kann man letztlich ebenso an „Elementkataloge“ wie an „Absatzformatkataloge“ stellen. Beidernfalls stellt sich z.B. die Frage, ob eine Adresse ebenfalls mit dem Element „absatz“ ausgezeichnet werden darf, oder ob hier ein zusätzliches Element „adresse“ nötig ist – womöglich gar mit einer Vielzahl von Kindelementen wie name, firma, strasse, hausnummer, postleitzahl, stadt, land.
Wenn es um das Thema Spezialisierung geht, sollte dies letztlich immer von der Frage nach der tatsächlichen Notwendigkeit und eine Aufwand-/Nutzen-Überlegung mit Abwägung der Vor- und Nachteile begleitet sein. Ich persönlich bin in dieser Hinsicht ein Verfechter von „keep it simple“. Denn mit jedem weiteren Format oder Element oder Attribut wird die Architektur komplizierter und allein die Dokumentation der Architektur dicker (als wahrhaft abschreckendes Beispiel sei hier die Dokumentation der Office Open XML-Architektur genannt, bei der allein der Teil 4, „Markup Language Reference“ geschlagene 5.220 Seiten umfasst).
Das macht die Anwendung der Format- bzw. Elementkataloge komplizierter (und führt erfahrungsgemäß zu häufigeren Fehlzuweisungen auch wenn der Autor in einem guten Editor ggf. „geleitet“ werden kann) und erschwert die Wartung ebenso wie die „Außenkommunikation“ des Dokuments – auch z.B. in Hinblick auf das Customizing von CMS oder TMS-Systemen.
Ich möchte fasst behaupten, dass man mit einer Hand voll Block-Level-Elementen wie „topic“, „title“, „body“, „section“, „p“, „list“, „list-item“ und einer Hand voll Inline-Elementen wie „emphasis“ und „term“ + der für Tabellen nötigen Elemente ganze Bücher schreiben kann. Vor allem, wenn die Elemente von einem guten Editor wie FrameMaker mit einem intelligent konstruierten EDD-Regelwerk und kaskadierend und kontextabhängig automatisiert formatiert werden. Quasi „reduced to the Max“.
Soweit die Theorie.
Der Aussage „Wichtig ist: Sie arbeiten überhaupt XML-strukturiert.“ kann ich mich ansonsten natürlich nur anschließen.
Viele Grüße,
Stefan Gentz
»Keep it simple!«
Ja, jederzeit. Es scheint nur so zu sein, dass dieses Prinzip (zumindest habe ich es so erlebt) nur von einigen Einzelkämpfer-Redakteuren auch umgesetzt und beibehalten wird. Gerade größere Firmen, bei denen viele Köche das Formate- oder Elemente-Rezept mitkochen, neigen hier eher zum Perfektionismus. Und verlieren dabei aus den Augen, dass die Aufwände jeder Wartungsmaßnahme, jeder Prozesserweiterung (z.B. jeder hinzukommenden Sprache) zu einem guten Teil proportional sind zur Komplexität der Dokumentstrukturen.
Hoffentlich hören uns ein paar einflussreiche Entscheider zu.