Viele Unternehmen, die sich mit dem Gedanken tragen, ihre herkömmliche Dokumentenerstellung auf XML-Basis umzustellen, sind sich oft nicht der Auswirkungen eines solchen Schrittes bewusst. Die Zuständigen überlegen zwar häufig, wie man innerhalb einer relativ autonomen Abteilung ein solches System einführen könnte. Vorhandene Legacy-Daten werden dann meist kostspielig und unvollständig manuell in das neue System übernommen.
Im laufenden Betrieb stellt sich aber heraus, dass nicht alle Daten, die in den XML-Dokumenten verwendet werden, auch tatsächlich in der betreffenden Abteilung entstehen. Als Beispiele hierfür dienen der Softwareentwickler, der seine Dokumentation in Standard-Tools wie Microsoft Word oder Rational Rose erstellt, der Marketing-Mitarbeiter, der einen Teil seiner Powerpoint-Präsentation gerne als Einführung des Handbuchs sehen würde, oder der Zulieferer, der noch kein XML-System einsetzt.
Eine teure und wenig praktikable Lösung wäre es, alle Mitarbeiter mit geeigneten Werkzeugen auszustatten und entsprechend zu schulen sowie alle externen Quellen (wie Zulieferer) auf XML-Kurs zu trimmen. Alternativ empfiehlt sich, XML-Gesamtprozess zu etablieren, in dem die bestehende Infrastruktur effizient eingebunden werden kann. Ein solches Unterfangen muss die Herausforderungen, die speziell bei der Übernahme von statischen Legacy-Daten und der Integration von Legacy-Applikationen (dynamische Legacy-Daten) entstehen, bewältigen können.
Hauptmotivation für eine solche Umstellung auf XML-Publishing ist meist die Aussicht auf strukturierte Dokumente, die sich effizient auswerten und wiederverwenden lassen. Dafür entwickelt man eine für den jeweiligen Anwendungsfall passende Document Type Definition (DTD). Alle künftigen Dokumente müssen konform zu dieser DTD sein. XML-Editoren wie "Xmetal" oder "Adept" ermöglichen dies.
Bei der Übernahme von statischen Legacy-Daten kommt es jedoch häufig vor, dass bestimmte, von der DTD zwingend geforderte Elemente oder Attributwerte gar nicht vorhanden oder, noch schlimmer, falsch sind. Andere Informationen wiederum sind redundant (beispielsweise der Name des Autors) vorhanden und müssen, damit sich der spätere Wartungsaufwand verringern lässt, erkannt und entsprechend umgesetzt werden. Es kommt auch vor, dass Informationen nicht eindeutig codiert wurden, also ein und derselbe Sachverhalt auf unterschiedliche Arten zum Ausdruck kommt.
Bei der Integration vorhandener Applikationen (Textverarbeitungen, CAD, Übersetzungssoftware etc.) trifft man prinzipiell auf dieselben Probleme wie bei statischen Legacy-Daten - nur mit dem Unterschied, dass diese Applikationen laufend Legacy-Daten erzeugen oder verändern. Neben der technischen Integration muss hier auch das Problem der Dokumentenkonsistenz gelöst werden, da dieselbe Information sowohl in unstrukturierter als auch in strukturierter Form vorliegt und sich jeweils an einem der beiden Orte ändern ließe.
Die meisten Importe von Legacy-Daten (statische und dynamische) in ein bestehendes XML-System erfolgen im Moment manuell mit Hilfe von stark spezialisierten Tools für ganz bestimmte Datenformate. Der große Anteil an manueller Tätigkeit macht den gesamten Prozess langsam, fehleranfällig und teuer, so dass eine vollständige Neuerstellung dieser Daten schneller und billiger ausfällt. Besonders, wenn die zu importierenden Daten sich nur durch einen teueren Domain-Experten zu den passenden Elementen der DTD zuordnen lassen, ist es notwendig, dieses Wissen zu konservieren und immer wieder zu verwenden, so dass dieser Experte möglichst schnell wieder zur Erfüllung seiner eigentlichen Aufgabe zur Verfügung steht.
Wenn ein Importfehler entdeckt wird (Elemente falsch zugeordnet), liegen im Allgemeinen keinerlei Informationen über die Ursachen oder den Kontext des Fehlers vor - welcher Teil (Software oder Person) hat aus welchen Gründen den fehlerhaften Abschnitt auf diese Art konvertiert. Nur durch zusätzliche Informationen wäre eine schnelle Anpassung eines Systems an variierende Legacy-Daten möglich.
Damit sich der Import von Legacy-Daten und Applikationen weitestgehend automatisieren lässt und eine überprüfbare Qualität erreicht, muss man eine Anwendungs-unabhängige Komponente definieren, die mindestens folgende Eigenschaften aufweist:
Frei definierbares Importregelwerk,
transparente Darstellung aller Aktionen während des Imports,
Schnittstelle zur Verifikation des Imports durch Domaine-Experten,
leichte Anpassbarkeit an variierende Legacy-Daten,
abstrakte Schnittstelle für Datenim- und -export,
Einbindung von bestehenden Importmodulen sowie
Wiederverwendung erfolgreich angewandter Regeln.
Die Münchener Firma SPX Valley Forge (http://www.vftis.com), die Authoring-Systeme auf XML-Basis vor allem für die Automobilindustrie entwickelt, hat ein Framework zum Import von Legacy-Daten implementiert, das alle oben genannten Eigenschaften aufweist.
Die Entwicklung des so genannten "Smartening-up"-Frameworks wurde begonnen, weil für jedes Authoring-System auch ein Prozess zum Import von Legacy-Daten eingerichtet werden musste. Aufbauend auf den Erfahrungen aus umfangreichen halbautomatischen Importierungen von Kraftfahrzeughandbüchern wurde versucht, ein Tool zu schaffen, das sich bereits in einer frühen Entwicklungsphase eines Authoring-Systems einsetzen lässt. Da bei der Entwicklung eines Authoring-Systems gleich zu Anfang eine DTD erstellt wird und sie fast immer eine Analyse der Legacy-Daten (hier Kfz-Handbücher) voraussetzt, war es naheliegend, eine Art Repository zur Analyse der Legacy-Daten einzurichten. Alle hierin gespeicherten Daten lassen sich sowohl während der Entwicklung der DTD als auch während des Importprozesses nutzen.
Das Repository erlaubt dem XML-Experten, bestimmte Regeln zu hinterlegen, die mit so genannten Keyword-Sets arbeiten können. Diese Regeln können sowohl semantische als auch Layout-Informationen betreffen. Wenn der XML-Experte beispielsweise bei der Analyse von Altdaten feststellt, dass beim gehäuften Auftreten von Wörtern wie "Experte", "anspruchsvoll" oder "schwierig" Dokumente für Experten vorliegen, dann definiert er ein Keyword-Set "Expert". Es enthält die dafür relevanten Wörter sowie eine Regel, die besagt, dass jedes Dokument, in dem mehr als 75 Prozent der Wörter aus dem Keyword-Set "Expert" vorkommen, den Wert "Expert" für das Attribut "Level" im Element "Manual" erhält. Analog würde er eine Layout-Regel definieren, dass der Text, der nach einer waagerechten Linie kommt, immer der Titel des aktuellen Kapitels ist.
Importregeln lassen sich laufend anpassenDas gesamte Smartening-up-Framework besteht aus sechs Komponenten (siehe Kasten) und dem Algorithmus Risa (Rulebased Iterative Smartening-up Algorithm). Jede Komponente kommuniziert mit der anderen über definierte Schnittstellen. Dadurch ist es relativ einfach, weitere Komponenten hinzuzufügen, ohne den internen Aufbau zu verändern.
Jede Iteration beginnt damit, alle noch nicht korrekt importierten Dokumente auszuwählen und sie der Rules Engine zur Verfügung zu stellen. Sie versucht nun, alle assoziierten Regeln anzuwenden und entsprechende Einträge für die Verification Engine zu erstellen. Der Domain Expert hat nun die Möglichkeit, mit Hilfe der Verification Engine korrigierend in den Importprozess einzugreifen, indem er neue Regeln definiert beziehungsweise andere Regeln assoziiert oder den Import für erfolgreich erklärt. Falls der Import noch nicht funktioniert hat, beginnt die nächste Iteration, und das Spiel wird solange fortgesetzt, bis alles importiert oder vom Importprozess ausgenommen ist. Zuletzt werden die importierten Dokumente zurück in die XML-Datenbank des Autorensystems geschrieben.
Die Komponenten-orientierte Implementierung dieses Frameworks erlaubt die transparente Integration in eine bestehende Infrastruktur. Aus der Sicht des Frameworks sind alle externen Datenquellen (Legacy-Daten oder Legacy-Applikationen) nur Datenströme, die es gemäß Regelwerk vollautomatisch konvertiert.
Alles Wissen, das ein Domain Expert während des Verification-Schritts in Form von Regeln und Assoziationen eingibt, bleibt für alle nachfolgenden Importvorgänge bestehen. Die Qualität des Frameworks steigt nicht nur durch die Informationen, die der Domain Expert eingibt, sondern auch durch die Übernahme von neu erstellten XML-Dokumenten. Aus ihnen lassen sich einfach Keyword-Sets und Rules extrahieren - sie liegen ja bereits in strukturierter Form vor und werden den Vorgaben viel eher entsprechen als die konvertierten Altdaten (sie wurden nicht erst via Import erzeugt, sondern mittels geeigneter Werkzeuge im Rahmen neuer Prozesse).
Der Vorteil eines solches Verfahrens besteht darin, dass es zum einen den vollautomatischen Import erreichen kann, gleichzeitig aber manuelle Eingriffe zulässt. Die Art der Legacy-Daten oder des Zielsystems spielt eine untergeordnete Rolle. Jede Verbesserung innerhalb eines Importvorgangs kommt allen nachfolgenden zugute. Bereits bestehende Importfilter lassen sich einfach durch geeignete Wrapper-Funktionalität in den Prozess einbinden. Fehlende Information kann mit einem passenden weiteren Stream verbunden und so hinzugefügt werden. Durch die interne Protokollierung aller Aktionen lassen sich Aussagen über die Qualität der importierten Dokumente machen.
Der Einsatz eines Smartening-up-Frameworks ist nur eine Möglichkeit, um einen Prozess zum Import von Legacy-Daten zu etablieren. Andere Verfahren müssen aber jeden wesentlichen Schritt auf eine ähnliche Weise abdecken, damit sie die entstehenden Anforderungen erfüllen können.
*Jürgen Lumera ist Mitarbeiter der SPX Valley Forge T.I.S. GmbH in München.
Die Komponenten des Smartening-up-FrameworksKeyword-Set: Eine Menge von Wörtern, die bezüglich eines bestimmten Aspekts zusammengehören. Solche Wortsammlungen können von Regeln benutzt werden.
Rules: Regeln, die beschreiben, wie sich eine bestimmte Eigenschaft erkennen lässt. Man formuliert alle Regeln abstrakt, um erst durch entsprechende Parameter eine konkrete Ausprägung einer Eigenschaft festzustellen. Zu jeder Regel wird eine Aktion definiert, die bei erfolgreicher Erfüllung stattfinden soll. Im einfachsten Fall wird der Textabschnitt, der die Regel erfüllt, durch ein Start- und ein Ende-Tag geklammert. Durch die Boolesche Verknüpfung von einfachen Regeln lassen sich komplexe Ausdrücke formulieren.
Rules Engine: Die Rules Engine ist ein Mechanismus, der jedem Element in der Ziel-DTD eine oder mehrere Regeln zuordnet und sie entsprechend anwendet. Trifft eine solche Regel zu, führt sie die damit verknüpfte Aktion aus. Die Reihenfolge (beispielsweise zuerst komplexe Elemente wie Kapitel und dann Titel oder umgekehrt), in der Regeln angewendet werden, lässt sich ebenfalls anpassen. Für jede erfolgreich ausgeführte Aktion erfolgt ein Eintrag zur späteren Verifikation durch einen Experten. Das Gleiche gilt für jeden Konflikt (verschiedene Regeln mit unterschiedlichen Aktionen sind erfüllt). Jeder Eintrag enthält Informationen über den Kontext (Streams, Position etc.), die angewandten Regeln und die ausgeführten Aktionen. Die Rules Engine kann auch mit teilweise importierten Dokumenten umgehen.
Verification Engine: Mit Hilfe dieser Komponente kann ein Domain-Experte eventuell aufgetretene Konflikte lösen, indem er neue Regeln und Keyword-Sets definiert und entsprechend zuweist. In der nächsten Iteration werden diese neuen oder modifizierten Regeln dann angewandt. Der Experte hat hier auch die Möglichkeit, bestimmte Abschnitte gänzlich vom Import auszuschließen und sie per Hand mit Tags auszuzeichnen. Solange nicht alle Dokumente als "Imported" markiert sind, laufen weitere Iterationen. Durch geschickte Wahl von repräsentativen Legacy-Daten lassen sich kurze Lernzyklen erreichen.
User Interface Layer: Die grafische Bedienungsschnittstelle eröffnet einen einheitlichen Zugang zu allen Haupt- und Sub-Komponenten. Auch alle durch Wrapper integrierten Importmodule sind über dieses Interface erreichbar.
Data I/O Layer: Diese Komponente abstrahiert jede Art von Datenquelle oder Datensenke. Innerhalb des Frameworks sind nur abstrakte Streams bekannt, die sowohl parallel gelesen als auch geschrieben werden können.
Abb.: Sowohl das Importregelwerk als auch die Sammlung von Schlüsselwörtern können bei jedem Durchlauf durch manuellen Eingriff verbessert werden. Erst der erfolgreiche Import aller Dokumente beendet die Iteration. Quelle: SPX Valley Forge T.I.S