Modellierung und XML

Erik Wilde (TIK, ETH Zürich)

Institut für Informatik, Universität Rostock, 1.6.2006

http://dret.net/netdret/docs/wilde-rostock06-xml

Kurzfassung

Während sich XML allgemein durchsetzt als Syntax zum Austausch strukturierter Daten, ist die Frage des zugrundeliegenden Modelles noch nicht abschliessend geklärt. In einfachen Fällen kann man XML als selbsterklärende und isolierte Daten betrachten, jedoch gibt es viele Szenarien, in denen die Strukturen komplex sind und in Abhängigkeiten von anderen Strukturen stehen. Welche Arten von Modellen, XML Schemas und Zusammenhängen existieren können, soll in diesem Vortrag beschrieben werden. Es zeigt sich dabei, dass für viele praxisrelevante Szenarien noch keine gute technologische Basis existiert, die es Entwicklern XML-orientierter Dienste und Software einfach machen würde, in diesem Umfeld zu modellieren, zu dokumentieren, und zu programmieren.

Übersicht

1. Vom Format zum Modell
2. Weisse Flecken
3. Stand der Dinge
4. Ausblick

1. Vom Format zum Modell

Vom Format zum Schema

• XML begann seinen Erfolg als reines Austauschformat
  • XML Schemas definieren die Austauschformate (im besten Fall)
  • die internen Datenformate sind unabhängig
  • Export/Import werden individuell und manuell erstellt
• XML durchdringt Applikationen und Anwendungsbereiche
  • Web Services und Prozesse als Interaktionen mit Partnern
  • Validierung gemäss Business-Logik (teils Schema, teils programmiert)
  • Änderungen über XForms (XML in, XML out)
  • Ablage in XML Datenbank
• reine XML-Pipelines sind billiger und robuster
  • Data Binding ist ein grosser Kosten und Risikofaktor
  • immer mehr Komponenten sind XML-basiert
  • Austausch meist durch Schema-Matching

Vom Schema zum Modell

• XML wird immer mehr als Modell benutzt
  • die Anwendung basiert auf einem XML-orientierten Datenmodell
  • gute Unterstützung für Speicherung und Austausch (XQuery, SOAP)
  • zunehmende Unterstützung in verschiedensten Bereichen
• Wie werden XML Modelle beschrieben?
  • im Moment gar nicht (im engeren Sinne)
  • XML Schema für Teile (Dokumente bzw. Fragmente)
  • weiterführende Dokumentation für Zusammenhänge (unstrukturiert)
  • selten: Schema Annotationen für maschinenlesbare Erweiterungen
• Was sind die Probleme fehlender Beschreibungen?
  • Zusammenhänge und Bedeutungen sind nicht dokumentiert
  • Abbildungen zwischen den Modellen sind manuell
  • Integrationskosten sind gross, Änderungen aufwendig

XML Schema als Modellsprache?

• XML Schema ist primär eine Sprache für Markup-Design
  • erweitert um einige einfache Modellierungsfeatures (Simple/Complex Types)
  • aber immer beschränkt auf die Beschreibung von einzelnen Dokumenten
• Modellierung in XML Schema
  • gegenüber DTDs neu eingeführte Beschreibungsebene
  • dient eher dem Modellieren von Markup als dem allgemeinen Modellieren
• Unabhängigkeit von Markup in XML Schema?
  • Typen sind XML Inhalte ohne XML Namen
  • Typen sind wiederverwendbare Teil von XML Inhalt
  • Simple Types sind die einzigen XML-freien Typen

Notwendige Abstraktionen

• Komplexe Datentypen ohne XML Markup
• Elemente oder Attribute
• Hierarchien nur für hierarchische Modelle
  • XML erzwingt hierarchische Strukturen
  • XML Hierarchien sind manchmal Assoziationen, manchmal Container
• Codierung von Assoziationen
  • 1:n über Hierarchien oder Referenzen
  • n:m über verschiedene Hilfskonstruktionen
• Modell-basierte Constraints
  • Identity Constraints sind auf dem Markup definiert (XPaths im Element)
  • Constraints auf Typen und über Dokumentgrenzen hinweg
• Steuerung über Regeln (pauschal oder individuell)

Model Chains

XML verbindet verschiedene Welten

• Individuelle Aushandlung ist aufwendig
• Übergreifende Modelle wären hilfreich (und kostengünstiger)
• erster pragmatischer Ansatz: Micro-Formats
  • definieren ein Modell mit seinem Markup
  • UBL als Sammlung Business-orientierter Micro-Formats
• einheitliche Sicht (Conceptual Model) für alle
  • Abbildung auf ER-orientierte Modelle
  • Abbildung auf hierarchische Modelle
  • logische Modelle (z.B. XML Schemas) werden generiert

2. Weisse Flecken

XML Basistechnologien

• XML Schema Modell nicht zugreifbar
  • Arbeiten auf der XML Syntax ist komplex
  • bisher nur API Vorschlag von IBM
  • XSLT 2.0 Funktionsbibliothek wäre wertvoll

Integration in Programmiersprachen

• XSLT benutzt XML als Datenmodell
  • in XSLT 1.0 das XPath 1.0 Datenmodell (Node Sets)
  • in XSLT 2.0 das XQuery/XPath Datenmodell (Sequences)
  • ermöglicht sehr einfachen Umgang mit XML
• Libraries oder Generatoren für das Data Binding
  • DOM ermöglicht Zugriff auf XML
  • JAXB erzeugt Klassen aus Schema-Typen (Parse/Serialize)
  • beide Methoden orientieren sich am Import/Export Ansatz
• XML Integration in Programmiersprachen
  • XML Strukturen als First Class Citizens
  • Datenstrukturen in der Sprache sind XML Strukturen
  • Objekte sind XML Daten mit Methoden

XML jenseits von Baumstrukturen

• nahezu alle Modelle sind nicht-hierarchisch
  • netzartige Strukturen ohne inhärente Hierarchie
  • Hierarchie ist eine Frage der Anwendung
  • Ziel: gleiches Modell, unterschiedliche Hierarchien
• Umgang mit nicht-hierarchischen Strukturen ist aufwendig
  • muss momentan jedesmal neu implementiert werden
  • kein allgemeines Schema für nicht-hierarchische Assoziationen
• allgemeine Funktionen für Modell-orientierte Operationen
  • finde assoziierte Objekte
  • in XSLT 2.0 immerhin über Funktionen kapselbar
  • Funktionen sollten generiert werden oder komplett generisch sein

3. Stand der Dinge

Abbildung Modell → Schema

Übereinstimmungen finden direkte Mappings vom Modell auf das Schema funktionale Mappings vom Modell auf das Schema semantische Probleme erkennen und vermeiden Implementierung der Abbildung fehleranfällige Handarbeit fehlendes übergeordnetes Modell Änderungen der Modelle sind aufwendig (manuelles Nachführen)

Abbildung Schema → Modell

Übereinstimmungen finden direkte Mappings vom Schema auf das Modell funktionale Mappings vom Schema auf das Modell semantische Probleme erkennen und vermeiden unbekannte Schemateile ignorieren (falls erlaubt) Abbildung implementieren fehleranfällige Handarbeit fehlendes übergeordnetes Modell Änderungen der Modelle sind aufwendig (manuelles Nachführen)

Verbesserungsmöglichkeiten

• Gemeinsamkeiten der Systemmodelle ausnützen
  • Austauschmodell als Trennung
  • Micro-Formats als ein Ansatz (nicht generisch)
• Bessere Dokumentation aller Modelle
  • vor allem Austauschmodelle sind oft schlecht definiert

4. Ausblick

Stand der Forschung: XML Modelle

• Ziel: Conceptual Model mit XML Support
• Bisher kein akzeptiertes Modell
• Bisher kein komplettes Modell
  • flexible Abbildung auf XML Schema(s)
  • flexible Abbildung auf ER-orientierte Modelle
  • Unterstützung von Modell-Constraints
  • Unterstützung von Mixed Content
• Verschiedene Vorschläge sind publiziert
• Bisher eher Top-Down als Bottom-Up
  • Web Services basieren auf der Idee des Loose Coupling
  • Modell-Sicht muss optional sein und nicht verpflichtend

Erster Schritt: XML Schema Annotationen

• XML Schema ist teilweise blind
  • sind m*Occurs Sets oder Sequences?
  • sind Hierarchien modellrelevant?
  • Einschränkungen von Mixed Content (typfrei)?
  • all ist kaum zu verwenden
  • Constraints nur in sehr einfacher Form unterstützt
  • dokumentübergreifende Aspekte nicht abgedeckt
• XML Schema unterstützt keine Versionierung oder Profiles
  • viele verschiedene Best Practices, aber keine akzeptierten Regeln
• XML Schema unterstützt Annotationen von Schemas
  • Hinweise, die an allen Komponenten angebracht werden können
  • besser als getrennte Dokumentation
  • maschinenlesbare Annotationen für semantische Ergänzungen

Zweiter Schritt: XML Schema Abstraktionen

• Lösen vom reinen Markup Design
• Reverse Engineering des Modells
  • Abstraktion: Markup-Spezifisches entfernen
  • Modellierung: XML Schema Blinde Flecken ergänzen
  • Modellierung im Idealfall durch Annotationen abgedeckt
• Zusammenhang Markup/Modell über Annotations im XML
  • ähnlich der xsi:type Variante
  • aber ohne deren riskante Semantik
  • naive Applikationen arbeiten auf dem Markup (bzw. Schema)
  • modell-basierte Applikationen arbeiten auf dem Modell
  • Rekonstruktion und API durch Libraries

Danke! Fragen?

• Meine Web-Seite: http://dret.net/netdret/
• Meine Email: erik.wilde@dret.net