Start

Methodik

Unternehmen

Comelio GmbHBerlin
Fon: +49(0)30-3640339-80
Fax: +49(0)30-3640339-89
info@comelio.com

Comelio GmbHEssen
Fon: +49(0)201-437517-0
Fax: +49(0)201-437517-10
info@comelio.com

Comelio GmbHMünchen
Fon: +49(0)89-38156860-0
Fax: +49(0)89-38156860-9
info@comelio.com

Comelio GmbHWien
Fon: +43-720-2097-97
Fax: +43-720-2097-98
info@comelio.com

Comelio GmbHZürich
info@comelio.com

Comelio-Blog > XML Schema > Bedeutung der Namensgebung

Bedeutung der Namensgebung in XML Schema

Die Modellierung von XML-Daten ist für Software-Projekte genauso wichtig wie die Modellierung von Datenbankstrukturen oder Klassen-Architekturen. Allerdings kommt auch bei sehr XML-basierten Projekten die Modellierung mit Hilfe von XML Schema und DTD viel zu kurz, was zu schlechten Projektergebnissen, fehleranfälliger Entwicklung und ingesamt zu Zeitverlusten führt. Dieser Artikel ist ein Plädoyer für die Modellierung von XML-Daten bzw. ihrer Wichtigkeit.

Kontakt Anrede* Herr Frau Vorname* Nachname* Firma E-Mail* Tel-Nr. Bereich* Comelio-Blog > XML Schema > Bedeutung der Namensgebung Freitext

XMl Schema: Bedeutung der Dokumentmodellierung

Es ist nur logisch, dass keine XML-Anwendung ohne vorhergehende Dokumentmodellierung auskommt, weil irgendein Datenstrom existieren muss, der untersucht oder transformiert werden soll. Dass dieser Datenstrom notwendigerweise irgendein Format haben muss, ist eine reine Selbstverständlichkeit. Es scheint allerdings teilweise in einigen Projekten sich so zu verhalten, als ob die genaue Modellierung von Datenstrukturen in einem Weltausschnitt nicht mit der gleichen Bedeutung bearbeitet wird wie z.B. die Planung der Transformationsanwendung. Sie hängt aber in – wie gerade gezeigt – entscheidender Weise damit zusammen, eine zukunftstaugliche und sichere Anwendung zu gestalten, kostenbewusst zu entwickeln und die noch zu diskutierenden erweiterbaren Schemata zu erstellen.

Dokumentmodellierung als Basis

Gerade wurde erwähnt, dass es Projekte gibt, in denen die Dokumentmodellierung nicht die Bedeutung erhält, die sie eigentlich verdient. Da zum Jahreswechsel 2003/2004 noch nicht alle Entwickler das XML Schema kennen gelernt haben oder bereits gute Erfahrung mit der DTD gemacht haben oder ihre Einschränkungen umgehen konnten, besteht immer wieder Bedarf, auf die Vorteile von XML Schema im Vergleich zur DTD hinzuweisen. Dies gilt ebenso für die anderen Schema-Sprachen wie z.B. RDF und natürlich die XML Topic Maps. Sie sind als relativ neue Standards noch nicht ausreichend diskutiert, was vor allen Dingen bedeutet, dass sie noch nicht in die Trivialliteratur der Informatik Eingang gefunden haben und daher breiten Anwender- und Entwicklergruppen noch nicht geläufig sind.

Hat man allerdings die Einschränkungen der DTD erkannt und sich entschieden, mit dem XML Schema zu arbeiten, gelten vielfach Überlegungen und Rückfragen, welche Datenstrukturen denn nun genau im Regelfall, im Mindestfall und im Maximalfall bzw. Sonderfall vorliegen, oftmals als nicht zweckdienlich. Dies mag gerade in kleinen Organisationen, in denen vielleicht nicht eine Projektstelle mit der Datenmodellierung betraut wird, damit zusammen hängen, dass dies ja in erster Linie Planungs- und Analyseaufgaben sind. Sie werden nicht immer gerne vergütet und als Investition in eine gute und sichere Anwendung wahrgenommen, weil das eigentliche Problem ja durch sie überhaupt nicht gelöst wird, sondern neue Fragen und Herausforderungen sich stellen. Diese neuen Problemstellungen dienen allerdings dazu, sich intensiver mit den tatsächlich vorhandenen Datenstrukturen zu beschäftigen und auch nur sehr selten auftretende, aber nicht auszuschließende Fälle in Augenschein zu nehmen und sie bei der Datenmodellierung zu berücksichtigen. Oftmals kann es sich auch um Widerstände gegenüber allzu langen oder konzentrierten Planungen handeln, da ja durch eine Schema-Datei keine eigentlichen Softwarefunktionalitäten eingerichtet werden, sondern sozusagen nur ein paar Elemente und Attribute einen Namen erhalten.

Soweit die Überlegungen der vorherigen Abschnitte allerdings nicht nur XML Schema betrafen, sondern auch Bezug zu den verschiedenen Möglichkeiten nahmen, dass ja die Schema-Dateien die Eingabedatenströme normiert, dürfte bereits deutlich gemacht worden sein, dass eine sorgfältige Dokumentmodellierung unabdingbar ist. Dies liegt ganz einfach daran, dass die Transformation in den meisten Fällen verändert werden muss, wenn sich die Eingabedatenstruktur ändert. Dies provoziert natürlich sofort Projektkomplikationen, Verzögerungen und verursacht erhöhte Kosten. Ohne sich in detailreichen Beispielen zu verlieren, soll es an dieser Stelle genügen, darauf zu verweisen, dass die Bedeutung der Modellierung selbst gar nicht überschätzt werden kann.

Wechselspiel mit erweiterbaren Schemata

Ein anderes übergeordnetes Thema, das mit der Syntax vom XML Schema enger verbunden ist, ist die Perspektive, so genannte „erweiterbare Schemata“ zu erstellen. Dies sind Schemata, die in anderen Zusammenhängen Teile ihrer Modellierung an weitere Dokumente übergeben können und so eine modulare Entwicklung von Datenstrukturen zulassen. Dies kann z.B. genutzt werden, um neu entdeckte und trotz vorheriger Analyse noch nicht berücksichtigte Sonderfälle in neuen Dokumenten zu modellieren, die sich syntaktisch über die gezeigten Möglichkeiten wie Inklusion, Import mit Ableitung durch Erweiterung/Einschränkung auf diese bereits vorhandenen Strukturen berufen. Eine solche Vorgehensweise macht allerdings wiederum eine Planung der Schema-Datei erforderlich, die nachher als Ausgangsbasis für neue Dokumente gelten soll. Dies wäre im Übrigen auch eine Planung für den Fall, dass die aktuelle Planung und Analyse fehlerhaft ist, wovon natürlich stets auszugehen ist. In diesem Sinne bedeuten die Überlegungen, Schemata zu erzeugen, die tatsächlich erweiterbar sind, auch eine Qualitätsabsicherung für die Zukunft. Ein Verständnis vom Prinzip der erweiterbaren Schemata und natürlich der in diesem Abschnitt beschriebenen Grundproblematik der Dokumentmodellierung, Syntax-Änderungstypen und Abhängigkeiten zwischen Ein- und Ausgabedaten kann dazu führen, dass Schema-Dateien bereits so vorbereitet sind, dass Sonderfälle oder neue Entwicklungen in anderen Dateien modelliert werden können, die sich durch die erläuterten Syntaxregeln in neuen Dokumenten abbilden lassen. Dazu gehört natürlich auch, die Perspektive noch einmal komplett zu wechseln und sich zu fragen, wie unerwünschte Erweiterungen oder Einschränkungen von gegebenen Datenstrukturen z.B. mit Hilfe der Ableitungskontrolle verhindert werden können. Dies führt dazu, dass auch die ungeplante Änderung vorher geplant wird, um unübersichtliche Dokumentbeziehungen, babylonische Türme mit ineinander verschachtelten zusätzlichen Dokumentabhängigkeiten, die durch Inklusion, Import und Ableitung ausgelöst werden, zu verhindern bzw. immerhin a priori zu bedenken.

Fehlte diese neuerliche Planungsaufgabe auf der Agenda, kann man sich immer noch mit den Syntax-Änderungen ohne Eigenschaftsänderungen behelfen und die vorhandenen Dokumente so schonend verändern, dass sie für die Wiederverwendung und damit als erweiterbares Schema geeignet sind. Soweit solche Syntax-Änderungen möglich sind, kann eine vorher nicht erfolgte Planung des ungeplanten Falls noch behoben werden. Sind allerdings Änderungen an den Eigenschaften notwendig, treten die oben erwähnten Nachteile durch die direkten und indirekten Abhängigkeiten der Transformations- und Datenströme auf.