Deutsch

Streitpunkt XML-Struktur

Peter Ritthoff stellt sich die Frage: „Brauchen wir überhaupt einen solchen Superstandard?“

CONSULTPROVIDE
Streitpunkt XML-Struktur

Schon seit vielen Jahren diskutieren die Anhänger verschiedener XML-Standards darüber, welcher Standard nun der ultimative, alles umfassende Superstandard ist, der natürlich viel besser ist als alle anderen. Doch gibt es den Superstandard überhaupt? Und brauchen wir überhaupt einen Superstandard? Diesen Fragen möchte ich im folgenden Beitrag nachgehen.

XML damals und heute

Als wir in der Technischen Redaktion mit XML gestartet sind – Militär und Luftfahrt waren hier führend – war viel Pionierarbeit gefragt. Das Ziel der ersten XML-Anwendungen in Militär und Luftfahrt war tatsächlich eine Standardisierung der Quellen. Man plante, die Inhaltspakete der verschiedenen Hersteller von Subsystemen zu einer Anleitung zuammenzubauen.

Dies gelang hier auch vortrefflich. Es gab aber auch ideale Voraussetzungen: Der Markt war von wenigen Anbietern dominiert und diese einigten sich darauf, dass niemand mehr Systeme liefern können sollte, ohne den Standard zu erfüllen. So mussten sich auch kleine Zulieferer dem Druck der großen Hersteller beugen.

In der übrigen Industrie war das anders. Vielfach kauften kleinere Systemanbieter bei größeren Komponentenherstellern. Die Einführung von XML ging recht schleppend über einen Zeitraum von mehr als 10 Jahren vonstatten und dauert immer noch an. Immer wieder wurden und werden Forderungen nach einem einheitlichen Standard nach dem Vorbild von Militär und Luftfahrt laut. Doch geben tut es einen solchen Standard bis heute nicht. Wir haben es mit mehreren, mehr oder weniger erfolgreichen Versuchen zu tun, die in den Standards DocBook, MUMASY, PI-Mod oder DITA mündeten. Daneben hat nahezu jeder Systemhersteller seinen eigenen Standard. Außerdem haben viele Firmen diese Standards entweder modifiziert oder ganz neue eigene Standards entwickelt. Eigentlich finden wir heute weltweit eine Landschaft von XML-Strukturen, die genau das Gegenteil von Standardisierung ist, nämlich: Wildwuchs.

Höchste Effizienz auch bei komplexen Inhalten  Redaktionssysteme für die Technische Dokumentation   Redaktionssysteme sind das Tool der Wahl, wenn es um das professionelle  Erstellen und Verwalten von Technischer Dokumentation geht. Wie gelingt eine  solche Systemlösung in der Praxis? Wir haben die wichtigsten Punkte in unserem  Whitepaper für Sie zusammengefasst.   JETZT WHITEPAPER ANFORDERN

Vielfältige Anforderungen

Warum ist das so? Nun, hierüber gibt es keine wissenschaftliche Studie (wäre sicher spannend), doch mit einigen Überlegungen findet man schnell die Erklärung. Neben dem fehlenden Druck durch wenige große Abnehmer wird der Hauptgrund darin liegen, dass die unterschiedlichen Firmen einfach unterschiedliche Anforderungen an den Erstellprozess in der Redaktion haben. Diese Unterschiede liegen auf der Hand:

  • Massenware vs. Einzelfertigung
  • Kleinteil vs. Großanlage
  • variantenabhängige Konfiguration vs. kundenindividuelle Entwicklung
  • Marketingaffinität vs. technische Bodenständigkeit
  • Branchenspezialisierung vs. generalistische Einsatzmöglichkeiten
  • Software vs. Hardware
  • und vieles mehr

Das Spektrum der Anforderungen ist so breit wie das Produktspektrum aller Hersteller weltweit. Das bedeutet, dass es den für alle gültigen Superstandard vielleicht gar nicht gibt. Und dies spiegelt auch die immer noch andauernde Diskussion über Standards wider. Was der eine als das Nonplusultra empfindet, ist für den nächsten großer Quatsch. Es gibt also nicht „den XML-Standard“, sondern je nach Anforderung einen, der vielleicht etwas besser passt als andere.

Die Grundidee, dass Lieferanten XML-Daten im Erstellformat liefern, die dann von den Herstellern in ihren Dokumenten integriert und weiterverarbeitet werden, rückt bei der aktuellen Entwicklung jedenfalls in immer weitere Ferne. Und vielleicht ist dies ja auch gar nicht das, was wir eigentlich wollen. Denn in der Erstellung wollen wir doch möglichst optimiert arbeiten und uns nicht die unterschiedlichen Ideen vieler Anderer aufschwatzen lassen, sondern was wir (vermutlich) alle wollen, ist, unseren Endkunden eine möglichst informative Nutzerinformation an die Hand zu geben, die keine für den Nutzer erkennbaren Brüche aufweist und in der alle Informationen, egal ob selbst verfasst oder „zugekauft“, gut zugänglich und leicht findbar sind. Jedenfalls sollte die Nutzerinformation meiner Meinung nach deutlich besser sein als eine Sammlung von PDF-Dateien der Lieferanten. 

Doch um dies zu erreichen, müssen wir nicht unbedingt Quellformate austauschen. Eigentlich will sich ja auch niemand das eigene Redaktionssystem mit den Quelldaten sämtlicher Lieferanten zumüllen. Darin würde sich ganz schnell niemand mehr zurechtfinden.

Aktuelle Entwicklungen

Nein, es sind nicht die Quellformate, die wir austauschen sollten. Es würde vollkommen reichen, wenn wir ein einheitliches Format hätten, das zum Austausch von Nutzerinformationen dient. Ein solches Austauschformat wäre eben unabhängig von den individuellen Spezialitäten, die unsere Redaktionsprozesse so effizient machen. Es wäre einzig und allein dazu konzipiert, die Inhalte und deren Metadaten zu transportieren und den Nutzern z. B. über ein Content-Delivery-Portal zugänglich zu machen.

Eine Arbeitsgruppe der tekom beschäftigt sich gerade mit dem Aufbau eines solchen Standards. Der iiRDS hat das Zeug dazu, sich zu einem solchen zu entwickeln. Doch selbst, wenn auch diese Entwicklung eines Standards in der Praxis nicht angenommen wird, besteht die Möglichkeit, Informationen auszutauschen. Denn es ist auch möglich, als Hersteller einen Austauschstandard zu definieren und diesen von seinen Lieferanten einzufordern. Ein Austauschformat aus einer bestehenden XML-Quelle zu exportieren, ist technisch nämlich kein so großer Aufwand.

Wir können uns also freuen, dass wir das Ziel, den Nutzern sämtliche Informationen, die sie benötigen, in einer optimalen Form anzubieten, auf jeden Fall erreichen können, egal ob mit oder ohne einheitlichen XML-Standard.

Peter Ritthoff
Autor:
Blog post Peter Ritthoff