|
|
|
|
|
Comelio GmbH
|
Comelio-Blog > XML Schema > Dokumentmodellierung Dokumentmodellierung mit XML Schema
Überlegungen zur DokumentmodellierungFü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-DokumentDie 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ängigkeitstypenGerade 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.
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 behebenWenn 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:
Typen von Syntax-ÄnderungenDer 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
Reformulierung ohne Eigenschaftsänderung
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. 
Seminare
|
Dieser Artikel gibt einen Überblick zu allgemeinen Überlegungen der Dokumentmodellierung mit XML Schema. Dabei behandelt er auch die Möglichkeiten, XML Schema-Dokumente zu ändern, wobei zwischen Änderungen, die nur das Regeldokument als auch solchen, die die XML-Daten betreffen, unterschieden wird. 