Überlegungen zur Dokumentmodellierung

Für die Gestaltung eines Regel-Dokuments ist nichts so entscheidend wie die Vergabe von Namen und Hierarchiebeziehungen. Eine Schema-Datei lässt sich nachher leicht mit Verschiebungen und einigen Korrekturen im Quelltext so anpassen, dass aus lokalen Elementen globale oder Datentypen für andere Elemente zur Verfügung gestellt werden. Dies ist auch für Attribute möglich, die von lokalen zu globalen avancieren oder wie Elemente in Gruppen zusammengefasst und dann lokal aufgerufen werden können. Es ist auch möglich, solche Änderungen durchzuführen, wenn bereits Instanzdokumente im Umlauf sind und sich reger Beliebtheit erfreuen, weil die Regeln weiterhin gleich bleiben und nur mit einer anderen Syntax verwaltet werden. In diesem Sinne ähnelt die Erstellung einer XML Schema-Datei der Situation im Rahmen eines Softwareentwicklungsprojekts, bei dem irgendwann festgestellt wird, dass ein anderer Programmaufbau oder eine andere Klassenstruktur geeigneter für Leistung oder Wiederverwendbarkeit wäre, sich aber gerade in der Ausführung des Programms nichts ändert. Das Ausgabeergebnis der Software bleibt also genauso erhalten wie das Instanzdokument, sodass der Benutzer von Software und XML Schema-Datei eigentlich gar nicht merkt, dass Änderungen zum Nutzen des Programmierers oder zur Verbesserung der allgemeinen Ausführungsleistung im Hintergrund ausgeführt wurden.

Abhängigkeit von Instanzdokument und Schema-Dokument

Die Bedeutung, die der wohl überlegten Gestaltung von Schema-Dokumenten und damit auch der Möglichkeit, in der Zukunft auf die vorgegebenen Eigenschaften aufzubauen und erweiterbare Schemata zu nutzen, zukommen, lässt sich zum einen in den Abhängigkeitstypen, die zwischen Regeldokumenten und weiteren Dokumenten bestehen, als auch an Typen möglicher Syntax-Änderungen erkennen. In diesem Abschnitt sollen zum einen die beiden unterschiedlichen Abhängigkeiten zwischen den in einer XML-Anwendung beteiligten Dokumenten analysiert werden. Es soll aber auch zum anderen auf die unterschiedliche Bearbeitungsmöglichkeiten im Hinblick auf die Syntax im Schema-Dokument eingegangen werden.

Abhängigkeitstypen

Gerade wurde gesagt, dass besonders die Benennung von Elementen und die Hierarchiebeziehungen von besonderer Bedeutung für die Gestaltung von Schema-Dateien sind. Zwar folgt gleich auch eine Berücksichtigung der anderen Dimensionen, die für die Gestaltung von Schema-Dateien existieren, doch stellen diese beiden Bereiche (in diesem Buch als Existenz und Hierarchiebeziehungen bezeichnet) zwei herausragende Bereiche dar. Dies hängt mit den direkten und indirekten Abhängigkeiten zusammen, die zwischen dem Regeldokument und anderen Dokumenten gelten.

Indirekt

sind diese Beziehungen für sämtliche Dokumente mit Quelltext in XML-Dialekten oder Programmiersprachen, die auf die Instanzdokumente zugreifen. In einer Programmiersprache kann eine direkte Verarbeitung mit dem SAX-Parser oder den DOM-Funktionen erfolgen. In einem XML-Dialekt kann eine Verarbeitung mit Hilfe von XSLT unter Verwendung von XPath erfolgen. Andere XML-Dialekte bzw. Dokumente wie RDF oder XML Topic Maps könnten auf die entsprechenden Instanzdokumente zusätzlich zugreifen und Meta-Informationen zu den gespeicherten Inhalten enthalten, die wiederum von XSLT-Dokumenten oder Programmiersprachen verarbeitet werden. Was die Verarbeitung von zusätzlichen Dokumenten in XTM- oder RDF-Syntax anbetrifft, so könnte man sogar von einer weitergereichten oder vererbten indirekten Abhängigkeit sprechen, da hier ja gerade weitere Dokumente auf die durch die gegegebenen Schema-Dokumente validierten Instanzdokumente zugreifen und sie selbst wiederum mit Hilfe von XSLT oder Programmiersprachen verarbeitet werden.

Direkt

sind diese Beziehungen natürlich für die Instanzdokumente, da sie die mit Daten gefüllten, quasi kristallisierten Ergebnisse der Schema-Dateien sind. Sie beziehen ihre Eigenschaften, ihren Dokument-Aufbau, die Benennung ihrer Elemente, ihre Reihenfolge, ihre Hierarchiebeziehungen und ihr wiederholtes Auftreten direkt aus den vorgegebenen Eigenschaften im XML Schema-Dokument. Hinzu kommt noch, dass nicht sämtliche Eigenschaften im Dokumentaufbau durch das Schema-Dokument determiniert sind, sondern auch die gespeicherten Daten selbst mit Hilfe von Datentypen und Listen genauestens vorgegeben sein können und sich also die Vorgaben im Schema-Dokument sogar bis auf Datenebene ausweiten.

Vor diesem Hintergrund erkennt man zunächst die Wichtigkeit einer guten Planung und einer ausreichend langen und qualitativ erfolgreichen Analyse- und Designphase. Änderungen sind nachher wie in jedem Software-Projekt stets möglich, aber natürlich auch mit entsprechenden Kosten verbunden. Während viel Zeit auf die Entwicklung des Quelltextes, auf den die XML-Anwendung aufbaut, verwendet wird, kann es passieren, dass bei der Datenmodellierung wenige Ressourcen gebunden werden. Allerdings verhält es sich so, dass die Strukturierung von XML-Datenströmen die gleiche Bedeutung für eine Software hat wie die Datenmodellierung einer Datenbank. Da die Anwendung verarbeitend auf die Daten zugreift, ist es einleuchtend, dass die Abhängigkeit zwischen Anwendung und Daten nur in einer Richtung verläuft. Während die Daten nicht direkt von Anwendung abhängig sind, ist die Anwendung sehr wohl direkt von den eingehenden Daten abhängig, weil die entsprechende Syntax in einer Programmiersprachen in DOM- oder SAX-Funktionen auf bestimmte Elemente, Attribute und Dokumentstrukturen in den genannten vier Dimensionen zurückgreift. Die durch das Regeldokument gegebenen Eigenschaften werden in der Programmiersprache erwartet und sind für die Anwendung daher notwendig, um einen fehlerfreien Betrieb aufrecht zu erhalten. Gleiches gilt für die Transformation unter Einsatz der XSLT-Technologie, weil auch auf Elemente und Attribute innerhalb einer bestimmten Dokumentstruktur zugegriffen wird. Änderungen können teilweise von sehr geschickten Programmiertechniken in XSLT durch Ausnutzen der Verarbeitung entlang des Dokumentsbaums verhindert werden, doch spätestens dann, wenn Elemente oder Attribute nicht vorhanden sind, lassen sich Fehler kaum noch vermeiden.

Daraus lässt sich zum einen ableiten, dass die genannten Abhängigkeiten überhaupt existieren und dass sie zum anderen eine tragende Bedeutung für die Entwicklung einer Software haben. In diesem Zusammenhang entspricht diese Bedeutung genau dem, die allen eingehenden Daten für eine Anwendung zukommen: Wenn die Anwendung Daten in einem bestimmten Format aus Datenbanktabellen und -spalten, speziell aufbereitenden Textdateien wie kommagetrennten Werten oder selbstverständlich in XML-Formaten erwartet, wirken sich Änderungen, die die Datenstruktur selbst betreffen, äußert nachteilig für die Anwendung aus. Schlechtes oder wenig zukunftstaugliches oder sogar falsches Design führt notwendigerweise aufgrund von Anpassungen und Änderungen zu verlängerten Entwicklungszeiten, zu zurzeit der Auslieferung noch unentdeckten Fehlern, die erneut zu Anpassungen und Verzögerungen führen, oder sogar zu Fehlern, die zurzeit des Betriebs weiterhin unentdeckt bleiben und Folgefehler in der Anwendung auslösen. Dies können insbesondere falsche Ausgabedaten sein, die in anderen Anwendungen wie einem Datawarehouse-System oder einem Datamining-Werkzeug zu überaus unerwünschten Fehlinterpretationen führen. Hier bleibt der Fehler zum Beispiel unentdeckt, weil übergebene Daten ein geeignetes Format, aber eine semantische andere Bedeutung haben (typisches Problem bei Zahlen), und dann mit den falsch interpretierten Daten die Verarbeitung in anderen Zusammenhängen fortgesetzt wird. An diesem kurzen Beispiel erkennt man auch, dass durch schlechtes oder fehlerhaftes Design von Datenstrukturen auch sehr spät im Entwicklungszyklus Fehler entdeckt werden können, die als Folgefehler von falschen Interpretationen oder von nur auf Datentypen fixierten Validierungen anzusehen sind.

Als Schlussfolgerung lässt sich nun also einerseits festhalten, dass die korrekte Modellierung von Daten aus unterschiedlichen Gründen eine hohe Bedeutung hat. Sie stimmen weitestgehend mit den Gründen ein, die auch für andere Zusammenhänge, in denen Daten modelliert werden (insbesondere Datenbanken), gelten. Andererseits ist die Abhängigkeit zwischen Datenstrukturen, Anwendung und Syntax-Änderungen unterschiedlich gravierend.

Diese zweite Schlussfolgerung soll in Abbildung 8.2 noch einmal aufgegriffen werden, ohne allzu sehr in die Details zu gehen. Man erkennt zunächst die drei identifizierten Dokumenttypen, die für eine XML-Anwendung mindestens notwendig sind. Man muss deshalb von einer Minimalkonfiguration ausgehen, weil natürlich auch eine Datenbank von XML-Datenströmen abhängig sein kann, da sie entsprechend transformierte Daten wieder speichern soll und dafür geeignete Strukturen bereit hält. Diese und andere Ausgabeziele (Textdateien, HTML-, PDF-Dateien) sollten sich alle im zentral abgebildeten Dokumentsymbol zusammenfassen lassen, um die Abbildung nicht durch allzu viele Details unübersichtlich zu machen. Diese Dokumente hängen alle indirekt von den modellierten Daten ab, weil eine Prüfung vor der Anwendung für die eingehenden Daten erfolgt und nicht während der eigentlichen Transformation. Für die Instanzdokumente, die rechts abgebildet sind, lässt sich allerdings eine direkte Abhängigkeit erkennen, da bei der Gültigkeitsprüfung im Rahmen der XML-Anwendung exakt die vorhandenen mit den geforderten/erlaubten Eigenschaften gegengeprüft werden. Datenströme, die nicht dem erwarteten Format entsprechen, können gar nicht erst zur Transformation gelangen und werden über eine geeignete Routine aussortiert oder sogar korrigiert, wobei dies eine eigene Transformation erfordern würde, die natürlich ebenfalls indirekt abhängig von den gegebenen modellierten Datenstrukturen wäre.

Neben diesen beiden Abhängigkeitstypen veranschaulicht die Abbildung noch, wie unterschiedlich sich Syntax-Änderungen auf diese abhängigen Dokumenten auswirken können. Auf diesen Umstand geht der folgende Abschnitt noch näher ein. Es lassen sich nämlich Syntax-Änderungen identifizieren, die nur die XML Schema-Datei verändern, aber keine inhaltlichen Änderungen an den geforderten oder erlaubten Eigenschaften des Instanzdokuments zulassen. Dies ist insoweit nicht weiter verwunderlich, als dass es eine Grundidee des objektorientierten Programmierens ist. Solange Ein- und Ausgabedaten gleich sind, muss und soll eine andere Klasse nicht wissen, wie aus den Ein- die Ausgabedaten erzeugt werden. Dieses Prinzip der Kapselung lässt sich natürlich in XML Schema nur sehr begrenzt umsetzen, könnte aber trotzdem mit dem Begriff der Kapselung bezeichnet werden. Eine etwas trivialere Beschreibung desselben Umstandes wäre dagegen die folgende: Die gleiche Eigenschaft eines Instanzdokuments lässt sich mit unterschiedlichen Syntax-Werkzeugen erzeugen, wobei die einzelnen Werkzeuge sehr unterschiedlich sein können. Solche syntaktischen Änderungen betreffen nur die XML Schema-Datei bzw. auch andere XML Schema-Dateien, die allerdings aus Übersichtlichkeitsgründen nicht in die Abbildung aufgenommen wurden. Andere XML Schema-Dateien könnten nämlich per Auslagerung und Wiederverwendung auf die Inhalte anderer Dateien zugreifen und von Änderungen betroffen sein oder (hier wieder das Prinzip der Kapselung) von ihnen unberührt bleiben, da keine Änderungen an den modellierten Eigenschaften (sozusagen Ausgabedaten) vorgenommen werden. Alle Änderungen jedoch, die inhaltliche Änderungen an den Eigenschaften eines Instanzdokuments vornehmen, wirken sich notwendigerweise auf dieses aus, sodass also hier erst durch diese Änderungen Änderungsarbeiten an den Instanzdokumenten unabdingbar sind.

Auswirkungen von Syntax-Änderungen beheben

Wenn die Modellierung der Daten sich ändert, dann müssen gezwungenermaßen die Instanzdokumente so angepasst werden, dass sie den neuen Änderungen genügen. Sie genügen damit indirekt den neu oder erst jetzt gefundenen Anforderungen der abzubildenden Datenstruktur in der Umgebung. Hier lassen sich folgende Fälle unterscheiden, die alle nicht mit den Mitteln der Dokumentmodellierung zu lösen sind, sodass hier auch keine weiteren Überlegungen anzustellen sind:

Automatische Transformation mit XSLT

Sofern die Änderungen an den Daten begrenzt bleiben bzw. die Änderungen direkt durch XSLT vorgenommen werden können und nicht z.B. aus einer Datenbank weitere Daten benötigt werden, kann man sukzessive mit Hilfe einer geeigneten Routine alle vorhandenen Instanzdokumente den neuen Gegebenheiten anpassen. Dazu gehören vor allen Dingen solche Änderungen wie die Veränderung von Hierarchien, die Umbenennung von Elementen und Attributen, die Umwandlung von Elementen zu Attributen und umgekehrt sowie die allgemeine Restrukturierung von Dokumenten. Wichtig ist dabei, dass die möglichen Änderungen über XSLT einrichtbar sein müssen, was insbesondere dann gegeben ist, wenn aus einem ehemals gültigen Instanzdokument ein neues gültiges Instanzdokument erzeugt werden soll, ohne dass zusätzliche Daten benötigt werden.

Umwandlung mit einer Programmiersprache

Fast alle Programmiersprachen bieten Funktionen für die Manipulation von XML-Daten an, sodass dies entweder mit dem SAX-Parser oder dem DOM gelöst werden kann. Wenngleich auch hier eine Lösung außerhalb des XML-Umfelds – zumindest, was den Quelltext anbetrifft – gewählt wird, so hat man bei dieser Strategie zusätzlich die Möglichkeit, zusätzliche externe Daten in die neuen Instanzdokument einzubinden, da die passenden Funktionalitäten wie DB-Zugriff etc. aus der jeweiligen Programmiersprache genutzt werden können.

Manuelle Anpassung

Wenn in den meisten Fällen wohl eigentlich die automatische Umwandlung mit Hilfe von XSLT möglich sein sollte, so kann doch natürlich in besonderen Situationen der Fall eintreten, dass detailreiche Änderungen nur manuell durchgeführt werden können.

Typen von Syntax-Änderungen

Der vorherige Abschnitt beschäftigte sich mit den unterschiedlichen Abhängigkeiten zwischen den in einer XML-Anwendung beteiligten Dokumenten. Sie entsprachen in vielen Punkten den allgemeinen Abhängigkeiten zwischen den Eingabedaten und der sie verarbeitenden Anwendung, die ja auf eine bestimmte Datenstruktur angewiesen ist. Darüber hinaus war davon die Rede, dass es unterschiedliche Syntax-Änderungen gibt, die in diesem Zusammenspiel der Dokumente ganz unterschiedliche Auswirkungen haben. Bei diesen Änderungen lassen sich generell zwei Typen voneinander unterscheiden, die natürlich auch in Kombinationen auftreten können. In der Abbildung soll dies durch die Verbindungslinie zwischen den beiden Typen angedeutet werden.

Bei der Reformulierung ohne Eigenschaftsänderung wirken sich die Änderungen im Regeldokument gerade nicht auf das Instanzdokument aus. Die gleichen Inhalte bzw. die gleichen Eigenschaften im Instanzdokument werden mit Hilfe einer anderen Syntax beschrieben. Inhaltlich drücken sie hingegen dasselbe aus. Dies entspricht Programmänderungen bei der Verwendung von Programmiersprachen, bei denen die Funktionalität der Software erhalten bleibt, d.h., es sind Ein- und Ausgabedatenstrukturen nach wie vor gleich, aber die Routine wurde anders formuliert. Bei der Reformulierung mit Eigenschaftsänderung wirken sich die Änderungen im Regeldokument unbedingt auf das Instanzdokument aus. Sie verändern die Eigenschaften der modellierten Elemente und Attribute direkt und führen nicht nur Änderungen an ihrer inhaltlich gleich bleibenden Beschreibung durch. Detailliert haben sie jeweils folgende Eigenschaften:

Reformulierung mit Eigenschaftsänderung

Existenz

Ändern Elemente oder Attribute ihre Namen sowie ihr gesamtes Auftreten, müssen sie in einem Instanzdokument entweder überall umbenannt oder in ihrer Benutzung verändert werden. Änderungen in diesem Bereich müssen sich also gerade nicht auf die Benennung beschränken, sondern können auch soweit gehen, dass Informationsstrukturen auseinander genommen werden wie eine Trennung des Straßennamens von der Hausnummer in zwei Elemente oder in ein Element und ein Attribut. Eventuell fallen sogar Elemente oder Attribute weg, sind also in der Benutzung nicht einmal mehr optional, sondern in einem Instanzdokument vollständig unbekannt.

Kardinalität

Bei umfangreichen Strukturänderungen kann es vorkommen, dass zusammengehörige Bereiche wegen besserer Lesbarkeit und Zugriffsmöglichkeit durch XPath in ihrer Häufigkeit verändert werden. Dies kann gleichzeitig mit Änderungen in den Hierarchiebeziehungen auftreten, sodass in einer Datei überhaupt erst die Möglichkeit eingerichtet wird, mehrere gleichartige Datenstrukturen in mehreren, wiederholt auftretenden Eltern-Elementen unterzubringen. Dies wäre z.B. der Fall, wenn in eine Umsatzübersicht für einen Tarif eine komplette Umsatzübersicht für alle bzw. mehrere Tarife zu einem bestimmten Zeitpunkt oder im Zeitverlauf untergebracht werden sollen. Dies kann gleichermaßen ein neues Dokument für eine ganz andere Abbildung von Daten erforderlich machen, könnte allerdings für eine die Instanzdokumente verarbeitende Anwendung auch darin bestehen, aus einem gegebenen Dokument ein solches zu gestalten, in dem auch mehrere gleichartige Elemente auftreten können.

Hierarchiebeziehungen

Überlegungen zur Benennung und zur Kardinalität hängen in vielfacher Hinsicht mit Veränderungen in den Hierarchiebeziehungen zusammen. Sobald man mehrere gleichartige Datenstrukturen, die aus verschiedenen Kind-Elementen bestehen sollen, in einem Dokument speichern möchte, benötigt man entsprechende Eltern-Elemente, die wiederholt auftreten dürfen. Dies erfordert natürlich auch eine Veränderung der Hierarchiebeziehungen bzw. die Einrichtung einer weiteren Hierarchieebene, die die ehemals einmalig auftretenden Elemente umgibt und sie nun zu Kind-Elementen der wiederholt auftretenden Eltern-Elemente macht. Änderungen in der Hierarchiestruktur können auch dann notwendig werden, wenn zusätzliche Informationseinheiten auftreten, die Ähnlichkeiten mit bereits bestehenden Informationseinheiten haben. Hier wäre es lohnenswert, sie einem gemeinsamen Eltern-Element unterzuordnen, um diese ähnlichen Informationseinheiten über einen einfachen XPath-Ausdruck auszuwerten. Insgesamt erfordern solche Arbeiten ein komplett neues Instanzdokument, in das neue Elemente eingesetzt werden, die bestehende oder neue Elemente enthalten.

Reihenfolge

Die Reihenfolgenbeziehung zwischen Elementen regelt die Abfolge von erwarteten oder erwartbaren Elementen in einem Instanzdokument. Änderungen in diesem Bereich machen es erforderlich, dass in einem Instanzdokument bestimmte Elemente an einer bestimmten Stelle auftreten müssen oder auftreten können. In diesem Sinne kann man dies auch mit der Kardinalitätseigenschaft verknüpfen, d.h., wenn ein Element optional ist, muss es an einer bestimmten Stelle erscheinen, wenn es denn im Instanzdokument benutzt wird. Typischerweise sind Änderungen an der Reihenfolge vorzunehmen, sobald Elemente mit Existenz- und Kardinalitätseigenschaften neu erstellt werden oder andere, bereits bestehende Elemente aufgrund der Einführung neuer Elemente an anderer Stelle ihren angestammten Platz verlieren und daher in einer anderen Reihenfolge eingeordnet werden müssen.

Reformulierung ohne Eigenschaftsänderung

Auslagerung/Wiederverwendung

Inhalte aus einer XML Schema-Datei werden in eine andere Datei ausgelagert und über Inklusion oder Import in die ursprüngliche sowie in weitere Dateien eingebunden. Dies lässt sich jeweils individuell mit den folgenden drei Typen durchführen, was diese Technik zu einer allgemeinen Reformulierungstechnik macht.

Globale komplexe/einfache Typen

Aus einfachen lokalen Datentypangaben und komplexen Inhaltsmodellen, nämlich solchen mit Kind-Elementen, erstellt man benannte globale einfache oder komplexe Typen. Sie lassen sich zentral im gleichen oder einem eigenen Dokument pflegen und dann als Typ für Elemente und Attribute (nur einfache Typen) aufrufen. Dort stellen sie dann ihre Eigenschaften zur Verfügung.

Globale Elemente/Attribute

Aus lokal deklarierten Elementen und Attributen erstellt man globale Pendants, die als Referenz dann lokal wieder aufgerufen werden können. Alternativ lassen sich diese Strukturen auch in andere Dateien auslagern und dann in mehreren Dateien nutzen.

Gruppierungen

Elemente und Attribute lassen sich in Kombinationen in Form von Element- und Attributgruppen sowie auch in Form von Element-Ersetzungsgruppen global in der gleichen oder einer eigenen Datei anlegen. Sie stellen dann bei Aufruf per Referenz bzw. Ersetzung ihre Eigenschaften an der Stelle, wo der Aufruf formuliert wurde, zur Verfügung. Dies lässt sich auch in Kombination mit den globalen komplexen Typen nutzen, in dem Kind- oder Geschwister-Elemente mit Hilfe von Gruppen erstellt werden. Ableitung: Globale komplexe und einfache Typen sowie Elemente lassen sich ableiten und stellen dann lokal ähnliche, aber nicht gleiche Eigenschaften zur Verfügung. Dies wird durch die Techniken Ableitung durch Erweiterung und durch Einschränkung bewerkstelligt.

Die Abbildung fasst nun diese unterschiedlichen Typen von Syntax-Änderungen zusammen und weist sie den unterschiedlichen Abhängigkeitstypen zu, die zuvor ermittelt wurden. Jetzt erkennt man, dass die Änderungen, die nur das Schema-Dokument selbst betreffen und damit eine direkte Abhängigkeit für das Dokument bedeuten, genau die gerade definierten Syntax-Änderungen ohne Eigenschaftsänderungen darstellen. Anders verhält es sich dagegen mit den Syntax-Änderungen mit Eigenschaftsänderungen. Sie wirken sich auf die direkten und indirekten Abhängigkeiten aus, die zu den Quelltextdokumenten der Transformation (entweder XSLT oder in einer Programmiersprache) und natürlich zu den Instanzdokumenten führen, die dann in die entsprechende Transformation eingehen. Diese Aufteilung bedeutet für die Planung von Schema-Dokumenten und damit für eine erfolgreiche Abbildung von Datenstrukturen, dass nur die Syntax-Änderungen ohne Eigenschaftsänderungen ohne Änderungszwang für die Instanzdokumente und die Transformationsdokumente durchgeführt werden können. Dies entspricht dem bereits mehrfach erwähnten Prinzip der Kapselung, weil auch hier Ein- und Ausgabedatenstrukturen gleich bleiben und sogar die genaue Verarbeitung unbekannt ist und sein soll. Änderungen können also ständig ausgeführt werden, solange die Ein- und Ausgabedatenstruktur erhalten bleibt.