Technologie-Beratung > XML > XML-Überblick

Datenmodellierung XML Schema Beratung Softwareentwicklung Programmierung

Diesert Artikel führt in die Grundsätze der Dokumentmodellierung von XML ein, ohne auf spezielle Techniken wie XML Schema oder DTD einzugehen. Vielmehr werden allgemeine Begrifflichkeiten wie Wohlgeformtheit und Gültigkeit erklärt und voneinander abgegrenzt. Zusätzlich werden verschiedenen Hinweise gegeben, welche verschiedenen klassischen Modellierungsansätze bei bereits bearbeiteten Daten existieren.

Kontakt Anrede* Herr Frau Vorname* Nachname* Firma E-Mail* Tel-Nr. Bereich* Technologie-Beratung > XML > XML-Überblick Freitext

Ansätze und Begründung der Dokumentmodellierung

XML ist die Antwort auf ein Hindernis oder eine Herausforderung, auf die jeder trifft, der sich in immer größeren Arbeitsumgebungen mit unterschiedlichen Konzepten der Datenhaltung und -speicherung sowie der Datenausgabe und -formatierung bewegt. Es ist ein Leichtes, eine kleine Internetseite eines Berghotels mit 20 Zimmern zu verwalten und die Daten aus einer Datenbank auf den entsprechenden Seiten zu veröffentlichen. Eine erste kleine Schwierigkeit entsteht, wenn zusätzlich zur Internetseite ein Katalog erstellt werden soll, der ähnliche, aber im günstigsten Fall gleiche Daten enthalten soll. Hier könnte man sich noch mit einfachen Textdateien oder HTML-Dateien behelfen, die dann in einem Textverarbeitungsprogramm weiterverarbeitet werden. Kommt aber eine umfangreiche Formatierung hinzu oder wächst das kleine Berghotel in eine ganze Hotelkette hinein und geraten die Daten in eine größere Datenbank mit vielleicht sogar mehrsprachigem Inhalt, ist eine fundamentale Revision des Vorgehens vonnöten. Die Daten sperren sich einer schnellen Übertragung mittels Textdateien von Datenbank in die Textverarbeitung für die Erstellung von Katalog, Zimmerbelegungsplänen, Tagungslisten oder Faltblättern. Hervorragend wäre eine Möglichkeit, die umfangreichen Daten in eine inhaltliche Gussform zu verschieben, die dann auf in den unterschiedlichen Endprodukten nur noch formatiert zu werden braucht. Alternativ könnte man sich überlegen, ob man die strukturierten Daten auch sofort so strukturiert in der DB speichert oder ob man lediglich die Daten aus der DB zunächst in strukturierten Dokumenten speichert, die dann im Hinblick auf ihre Formate weiter verarbeitet werden. Mit XML ist es nun möglich, wie Ihnen schon bekannt sein wird, Auszeichnungen festzulegen, mit denen sich sowohl eine Dokumentenstruktur als auch Strukturregeln abbilden lassen, die dann nachher über Parsing-Vorgänge in anderen Dokumenten wie Internetseiten oder Druckvorlagen zur Verfügung stehen.

Eine Ihnen vermutlich auch geläufige Auszeichnungssprache ist HTML. Deren Syntax wurde in einem Schema-Dokument festgelegt, das theoretisch in jedem Browser gespeichert und mit Ausgabeformaten versehen ist. Dabei unterscheiden sich zwar in den einzelnen Browsern die tatsächlichen Anzeigeergebnisse, und man steht auch weiterhin bei einigen Tags vor der Hürde, dass sie in unterschiedlichen Browsern auf verschieden Weise angezeigt werden, aber grundsätzlich kann man HTML-Dokumente, die den Regeln im zugehörigen HTML-Regel-Dokument sich unterwerfen, in jedem Browser bzw. in jeder Anwendung, die HTML interpretieren kann, zum Einsatz bringen.

HTML ist sehr einfach zu lernen, bringt allerdings auch beim Einsatz im Internet allerhand Nachteile mit sich, da Formatierungsmöglichkeiten direkt in HTML sehr umständlich zu realisieren sind, eine Silbentrennung unmöglich ist und Layoutstrukturen ohne den raffinierten Einsatz von Blindgifs und natürlich blinden Tabellen kaum geschaffen werden können. Das führt dazu, dass Auszeichnungen, die eine Darstellung (Schriftschnitt) vorgeben, mit anderen Auszeichnungen, die eine Struktur (Überschrifttypen) beschreiben, mit solchen Auszeichnungen, die das Layout betreffen (blinde Tabellen), ineinander übergehen und zu einem Ergebnis führen, das allem zuwiderläuft, was man gemeinhin unter guten Programmierstil versteht. Dies sind aber Auswirkungen der Regelungen im HTML-Regeldokument, das gerade die Verwendung von HTML vereinfachen sollte. Bei der Einführung von HTML war dies eine verständliche und logische Vorgehensweise, konnte zum damaligen Zeitpunkt doch niemand ahnen, welche Bedeutung HTML gewinnen würde und was findige Webdesigner mit HTML alles umsetzten würden. HTML könnte man in diesem Sinne also als eine sehr erfolgreiche Syntax ansehen – in diesem Sinne viel erfolgreicher als manch andere –, die aber gleichzeitig zu flexibel bzw. zu wenig durchdacht ist – ganz im Gegensatz zu manchen anderen.

Prüfungsschema von XML-Dokumenten

XML nun erlaubt die Definition eigener Auszeichnungsbefehle, die ausschließlich für die Textstruktur (und gerade nicht für Layout oder Darstellung) eingesetzt werden sollten. Zwar gibt es einige Praxisfälle, in denen auch Layoutregeln in XML umgesetzt werden. Man sollte diesem Beispiel unter keinen Umständen folgen, sondern diese Regelungen ausschließlich in die verwendeten XSL-Dokumente auslagern. Es ist nicht immer leicht, Kunden, die Layout in XML unterbringen, vom Gegenteil zu überzeugen, können sie doch wunderbar mit XSL auf die Layoutregeln zugreifen, wodurch am Ende weiterhin wunderschöne PDF- und HTML-Dokumente entstehen. Aber für die Zukunftstauglichkeit und die langfristige Datenstrukturierung und -speicherung lohnt eine vollständige Trennung von Layout und Inhalt bzw. der Semantik mit Hilfe der XML-Dokumente und der XSL-Dokumente.

Hier muss sprachlich noch einmal deutlich gesagt werden, dass es sich bei den XML-Dokumenten stets um Instanzdokumente handelt, die korrekt auf bereits existierenden Regeldokumenten beruhen. In Wirklichkeit gibt es ja nicht „das“ XML-Dokument, weil XML ja ausschließlich ein Konzept oder eine Technologie für die Verwendung und Entwicklung von eigenen Auszeichnungssprachen ist. Tatsächlich bezeichnet man ein XML-Dokument als ein solches, weil Textstücke mit Hilfe von Elementbezeichnungen in spitzen Klammern ausgezeichnet worden sind. Diese Syntax, also die Definition der verschiedenen Elementnamen etc., wiederum ist letztendlich immer in einem Regeldokument abgelegt, sodass vor der Verwendung eines Instanzdokumentes oder dem, was bis jetzt immer als XML-Dokument bezeichnet wurde, regelmäßig die Entwicklung eines Regeldokuments liegt.

Die Abbildung soll die verschiedenen Dokumenttypen und deren jeweilige Aufgaben bei der Verwendung von XML kennzeichnen. Wie man sich leicht vorstellen kann, benötigt man in einer kompletten Anwendung noch mindestens ein Dokument mit entsprechendem Quelltext, das die Transformation startet oder mit den benötigten Parametern versorgt. Zusätzlich lassen sich weitere Dokumente und Strukturen aus dem XML-Umfeld denken wie z.B. solche mit semantischen Informationen oder solche, die zur semantischen Untersuchung und Abfrage von existierenden Instanzdokumenten dienen. Daher handelt es sich bei der Schemadarstellung um das Grundprinzip oder auch um die Minimalanforderungen einer XML-Anwendung mit den folgenden Dokumenttypen:

XML-Instanzdokument

Es basiert auf einem Regeldokument und befolgt die dort genannten Strukturregeln in Hinblick auf das Vorkommen, die Häufigkeit und die Reihenfolge sowie die Benennung von Elementen sowie entsprechende Datentypen.

XSD-Regeldokument

Es definiert die Strukturregeln im Hinblick auf das Vorkommen, die Häufigkeit und die Reihenfolge sowie die Benennung von Elementen sowie von entsprechenden Datentypen. Seine Inhalte sind bei der Prüfung wichtig, ob die Instanzdokumente sich an die getroffenen Regelungen halten, wobei die Prüfung für das XSL-Transformationsdokument sicherstellt, dass die Transformation durch den Zugriff auf die vorhandenen Elemente mit ihren sonstigen Eigenschaften erfolgreich verläuft.

XSL-Transformationsdokument

In ihm sind die Transformationsregeln für die Umwandlung der XML-Datenströme in andere Formate enthalten. Es ist darauf angewiesen, dass die Regelungen im XSD-Regeldokument exakt eingehalten werden, da es selbst auf diese Regelungen zurückgreift, um Elemente zunächst zu identifizieren und dann auch zu verarbeiten.

Für die Überprüfung gibt es zwei Dimensionen, in denen unterschiedliche Ergebnisse erreicht werden können:

• Wohlgeformt: Ein XML-Dokument ist wohlgeformt, wenn die Syntax korrekt eingesetzt wird, d.h., Attribute in Anführungszeichen gesetzt, leere Elemente extra ausgezeichnet und die allgemeinen Regeln der Namenskonvention beachtet werden:
  • Das erste Zeichen eines Namens muss ein Buchstabe, ein Unterstrich oder ein Doppelpunkt sein.
  • Gültige Zeichen sind Buchstaben, Unterstriche, Ziffern, Bindestriche sowie Punkte und Doppelpunkte.
  • Streng verboten ist die Verwendung des Wortes XML in all seinen Varianten als Namensbeginn, da geschützt ist.
• Gültig : Ein XML-Dokument ist gültig, wenn die benutzte Tag-Struktur der Anwendungslogik oder dem inhärenten Sinn des Dokuments genügt, d.h. soweit die Regelungen des Entwicklers erfüllt sind. Diese Regeln befinden sich in einem XML Schema-Dokument.

Ziel sollte also stets ein wohlgeformtes – da sonst ein allgemeiner Fehler auftritt – und gleichzeitig gültiges Dokument sein – da sonst ein spezieller Fehler in der Anwendungslogik auftritt.

Im Ergebnis hat man also zwei Prüfungsschritte: zum einen die Prüfung auf Wohlgeformtheit (Syntaxprüfung) und zum anderen die Gültigkeitsprüfung (Verwendungsprüfung). Letztere muss nicht unbedingt erfolgen, da sie von der Existenz eines entsprechenden Schema-Dokuments mit Verwendungsangaben abhängt. Der Einsatz eines solchen Schema-Dokuments führt entweder zur Erkenntnis, dass das Instanzdokument gültig im Sinne des Schema-Dokuments ist oder nicht. Gültig und wohlgeformt ist also zur gleichen Zeit erstrebte Ziele, da sie zum einen nachweisen, dass die Regelungen des XML-Standards erfüllt sind und zum anderen die Regelungen des Schema-Dokuments befolgt wurden.

Ansätze der Dokumentmodellierung

Die Erstellung eines einfachen Regeldokuments für eine Visitenkarte, eine Adressliste etc. ist natürlich keine wirklich schwere Aufgabe. Allerdings kann man auch bei der Verwaltung von Adressen bemerken, dass in verschiedenen Standardanwendungen im Office- oder Buchhaltungsbereich für die Erfassung der Adressdatenstruktur nicht nur fünf bis 10 Spalten wie in einem handelsüblichen Notizbuch bereit stehen, sondern teilweise mehr als 30. Teilweise sind diese dann auch nicht wirklich normalisiert, sondern im Hinblick auf wiederholende Einträge (alternative Email-Adressen oder Telefonnummern) auf eine bestimmte Anzahl von ähnlichen Einträgen begrenzt. Dies reicht zwar für 95% aller Eintragungen, aber bereits der Arbeitskollege mit Zweitwohnsitz im Ausland lässt sich mit seiner jeweiligen Mobil- und Festnetznummer nicht komplett erfassen. Dennoch kann man davon ausgehen, dass man für Datenstrukturen, die man sehr gut kennt, was natürlich bei solchen Alltags-Datenstrukturen wie Telefon- und Adressbuch der Fall sein dürfte, spontan und iterativ die korrekten Elemente und Strukturen entwickelt.

Dabei würde man zunächst die unmittelbar und damit intuitiv einleuchtenden Elemente in einer vorläufigen hierarchischen Struktur und mit einer ebenso vorläufigen Häufigkeitsangabe erfassen. Durch einen iterativen Prozess aus der Validierung mittels Testdaten bzw. Verarbeitungsnotwendigkeiten oder Verarbeitungswünschen würde man danach in mehreren Schritten, die mit dem endgültigen XML Schema-Dokument terminierten, die weiteren Elemente der zu modellierenden Datenstruktur erfassen. Dieses Vorgehen scheint grundsätzliche Überlegungen, wie Datenstrukturen zu modellieren sind, vollkommen überflüssig zu machen bzw. nur darauf zu beschränken, eine bestimmten Syntax, wie in diesem Fall jene vom XML Schema, für die Beschreibung der Strukturen einzusetzen. Tatsächlich aber gelingt und terminiert dieser spontane Ansatz nur deswegen erfolgreich mit einem XML Schema-Dokument, weil die Analysephase durch die Erfahrung im Umgang mit der zu modellierenden Datenstruktur überflüssig wird.

Sowohl der Blockdiagramm- als auch der Baumdiagramm-Ansatz stellen grafische Kodierungen bereit, mit denen Datenstrukturen, ihre Beziehungen untereinander, ihre Benennung und ihr Vorkommen und Auftreten symbolisiert werden können. Durch die Verwendung einer grafischen Notation erleichtert man auch den Mitarbeitern das Verständnis und stärkt ihre Integration in den Analyseprozess. In der Analysephase ist diese Integration alle Anstrengung wert, weil man auf den Erfahrungsschatz der Mitarbeiter stets zurückgreifen können sollte, um die zuvor erwähnten Vorteile durch die spontan-intuitive Methode der Dokumentmodellierung zu nutzen. Zwar muss hier der Analytiker, der auch als interner Mitarbeiter für ein entsprechendes, fachfremdes Projekt ein externer Berater ist, durch geeignete Moderation diese Erfahrungen freilegen und den Erkenntnis- und Validierungsprozess anleiten, aber durch eine ordentliche Integration der mit den Daten täglich umgehenden Organisationseinheiten (ganze Abteilungen, aber auch deren einzelne Mitarbeiter) erleichtert man die Entwicklung von komplexen Regeldokumenten, senkt die Fehlerquote und damit die Notwendigkeit, durch viele Rückkopplungen aus der Validierungsphase die fehlenden oder fehlerhaften Datenstrukturen zu erfassen.

Nicht jede grafische Notation ist zwangsläufig einfach, so wie Schaltpläne auch nicht für jedermann ohne Anleitung und Vorwissen lesbar sind. Bei den im Folgenden vorgestellten Ansätzen jedoch ist die Wahrscheinlichkeit sehr hoch, dass nach einer kurzen Einarbeitungsphase in die Notationstechnik die gerade erwähnten positiven Effekte auch tatsächlich freigesetzt werden.

Der Blockdiagramm-Ansatz

Das Blockdiagramm bietet die Möglichkeit, sehr einfach und anschaulich von einem vorhandenem Dokument wie z.B. einem beliebigen Erfassungsbogen auszugehen und in ihm die einzelnen Einheiten und Abschnitte zu umrahmen, die ein Oberelement bzw. einen Auszeichnungsbefehl bilden könnten. Andersherum könnte bei der Erstellung eines Blockdiagramms ohne eine solche Vorlage vor dem inneren Auge des Betrachters ein entsprechendes Formblatt entstehen und wegen dieser Anschaulichkeit entsprechend assoziative Kräfte frei werden lassen, welche Texteinheiten noch mit diesem Dokument erfasst werden sollten. Man erhält also in beiden Bereichen eine mögliche Dokumentenstruktur mit einfachen grafischen Mitteln, die jeder unmittelbar oder höchstens nach einer sehr kurzen Einarbeitungszeit versteht.

Bei der Datenmodellierung in einem ohnehin schon durch Formulare, Formblätter und Dokumentvorlagen gekennzeichneten Organisationsumfeld ist dies ein Ansatz, der bei einfachen oder flachen Datenbeziehungen ausreicht. In jedem Fall kann er in diesen Projekten aber auch als erster Schritt für eine Übertragung der vorhandenen Dokumente dienen, wobei die vorhandenen Vorlagen von den Datenstrukturen, die sie abbilden, getrennt werden. Dadurch können in Gesprächen, die während der gemeinsamen Erstellung des Diagramms stattfinden, auch Schwierigkeiten mit den vorhandenen Formularen berücksichtigt werden. Zu den klassischen Schwierigkeiten gehören hierbei fehlende Felder oder Daten, die handschriftlich immer zusätzlich eingetragen werden, Abkürzungen oder Textblöcke, die schematisiert einzutragen, aber nicht auszuwählen sind, oder auch Komplikationen bei der Verarbeitung von weichen Daten, die häufig auftreten, aber nicht in eines der vorgegeben harten Rasterfelder eingegeben werden können. Im Rahmen der Analyse sollte auch hier darauf geachtet werden, solche bestehenden Schwierigkeiten aufzudecken, die nicht mit der realen Datenstruktur unmittelbar, sondern eigentlich nur mit der bereits vorliegenden Ableitung aus der realen Datenstruktur zu tun haben, und verbessernd im XML-Projekt zu berücksichtigen.

Durch den Blockdiagramm-Ansatz bzw. die Ähnlichkeit mit einem tatsächlichen Formular können auch leicht Validierungen vorgenommen werden. Das kann entweder mit Test- oder Realdaten geschehen oder durch die Nachbildung eines typischen Verarbeitungsprozesses. Hier ist insbesondere wichtig zu ermitteln, wie verständlich und gut die Daten für nachfolgende Organisationsstellen und Verarbeitungseinheiten aufbereitet sind. Gerade für Mitarbeiter, die nur mit erfassten, nicht aber mit den real beobachteten Daten zu tun haben, ist dies ein entscheidender Faktor beim Umgang mit den vorliegenden Daten. Beide Dimensionen dürften dann neue Abhängigkeiten, Hierarchien oder Beziehungen und evtl. sogar benötigte Elemente offenbaren, die bisher noch keine Berücksichtigung fanden.

Baumdiagramm-Ansatz

Eine Alternative zu diesem Vorgehen, das für sehr umfangreiche Dokumente mit vielen hierarchischen Beziehungen, die teilweise auch noch ungleichmäßig verteilt sind, besser geeignet ist, ist das Baumdiagramm. Hier hat man die Möglichkeit, sich von größeren Bereichen zu kleineren Einheiten durch die Anwendung zu arbeiten. Zudem kann man sehr einfach ganze Bereiche abdecken bzw. in Powerpoint ausblenden lassen, um einen speziellen Abschnitt des Baums ins Blickzentrum zu rücken. Dies ist im Blockdiagramm nicht möglich, da dann der entsprechende Bereich eine leere Fläche bildet und weiterhin stark auffällt.

Um ein Dokument auf Gültigkeit hin zu prüfen, d.h., daraufhin zu testen, ob keine falsch überlappenden Abschnitte wie im folgenden Beispiel entstehen, genügt es beim Blockdiagramm, darauf zu achten, dass sich keine Blöcke überlagern. Beim Baumdiagramm hingegen dürfen sich keine Linien schneiden.

Erweitertes Baumdiagramm

Wir verwenden für die Darstellung eines realistischen Dokuments nun ausschließlich das Baumdiagramm, da es die Abhängigkeiten und Strukturen bei umfangreicheren Dokumenten doch etwas besser als ein Blockdiagramm versinnbildlicht. In einem erweiterten Schema wurden nun in die ursprüngliche Zeichnung folgende weiteren Elemente zur Planung eingebettet:

• Alle XML-Befehle werden in einem Rechteck dargestellt.
• Übergeordnete Tags, d.h., solche mit weiteren Untertags, erhalten eine graue Färbung, wobei allerdings keine weitere Unterscheidung über den Rang getroffen wird.
• Attribute werden direkt mit dem Tag verknüpft, zu dem sie gehören. Zusätzlich erhalten Sie einen gestrichelten Rahmen.
• Sich wiederholende Gruppen werden umrahmt. Dafür verzichtet man auf die explizite Nennung der Wiederholung durch mehrmalige Verwendung im Schema. Die Anzahl der Wiederholungen kann dann durch einen Zahlwert oder durch eine nach oben offene Schranke in Form eines Plus-Zeichens dargestellt werden.