Die XML Evolution

Erik Wilde

ETH Zürich

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

Kurzfassung

XML begann seine erstaunliche Erfolgsgeschichte als Format, das auf dem Web benutzt werden sollte für die Repräsentation beliebiger (jedoch vornehmlich Dokumenten-orientierter) Daten. In diesem Bereich wird XML heute nur selten eingesetzt, der Haupterfolg lag und liegt im Bereich des B2B-Datenaustauschs. In den Zeiten der Dot.com-Euphorie kam XML gerade zur richtigen Zeit, um mit überwältigendem Erfolg als Basis für heterogene Web-basierte Systeme, die heute als SOA in aller Munde sind, eingesetzt zu werden. XML-Technologien haben aufgrund ihrer Herkunft und Anwendung eine teilweise etwas ungeordnet verlaufende Entwicklung genommen, und auch heute gibt es noch erhebliche weisse Flecken in der Landkarte der XML-Technologien. In diesem Vortrag wird die Entwicklung von XML nachgezeichnet, werden Zusammenhänge und Probleme aufgezeigt, und werden die Bereiche angesprochen, in denen heutige Entwickler noch zu wenig Unterstützung erfahren und die Forschung der kommenden Jahre wichtige und lohnenswerte Aufgaben finden kann. Praktiker werden auf potentielle Gefahrenbereiche hingewiesen, auf die man bei einem konsequent XML-orientierten Ansatz beim Software-Engineering acht geben sollte.

Übersicht

1. Entwicklung
2. Zusammenhänge
3. Probleme
4. Weisse Flecken

1. Entwicklung

Ausgangslage (1997/98)

• XML wurde als SGML on the Web entwickelt
  • XML Dokumente sollten statt HTML auf dem Server liegen
  • jeder Anwender könnte sein eigenes Format benutzen
  • Formatierung im erst im Browser durch CSS oder XSL
• XML wurde zu Zeiten des Dot.com Boom entwickelt
  • jede Technologie aus dem Internet ist cool und profitabel
  • zunehmende Vernetzung verteilter Applikationen
  • die klassischen Middleware-Systeme skalieren nicht
• XML ist einfach zu verstehen und zu implementieren
  • Standard von einer neutralen Organisation (W3C)
  • Standard ohne Festlegung auf ein Betriebssystem
  • XML 1.0 (XML Dokumente und DTDs) ist übersichtlich
• vorherige Ansätze waren gescheitert
  • ASN.1 (OSI), NDR (DCOM), XDR (ONC RPC), CDR (CORBA IIOP)

Resultat

• XML als Datenrepräsentation für verteilte Anwendungen
  • Daten-orientiertes XML (ER in XML) ist die Regel
  • Dokumenten-orientiertes XML ist bis heute die Ausnahme
• Daten-orientiertes XML ist einfach handzuhaben
  • Generierung von XML aus Tabellen ist trivial
  • Abfragen und Einfügungen sind einfach durchzuführen
• Dokumenten-orientiertes XML ist das reichere Format
  • jedes Daten-orientierte XML ist auch Dokumenten-orientiertes XML
  • die Abbildung auf ER-Strukturen ist schwierig und unschön
  • die gängige Technologie (SQL) bietet keine Unterstützung

1.1 XML

• Eine einfache Syntax für strukturierte Daten
• Validierung ist durch Standardsoftware möglich
  • DTDs sind Bestandteil des XML Standards
  • minimale Constraints können kontrolliert werden (Invarianten)
• XML definiert nur den XML Processor, aber kein API
  • was genau der Parser meldet, liegt in der Hand der Implementierung
  • wie man darauf Zugriff hat, liegt in der Hand der Implementierung
• Erste Meinungsunterschiede zum Datenmodell von XML
  • die Frage ist: was ist relevanter Inhalt, was ist Syntax?
  • eine definitorische Frage, keine faktische!

1.2 DOM

• XML-Parser sind eine häfig verwendete Komponente
  • sie sollten einfach austauschbar sein
  • sie sollten Bestandteil einer Programmierumgebung sein
• Netscape's HTML DOM war als generisches Tree-Interface geplant
  • keine Meisterleistung des Interface-Designs
  • aber vorhanden und für viele bereits bekannt
  • wurde als DOM0 Urahn aller XML DOM Versionen
• DOM - von vielen gebraucht, aber sehr unterschiedlich
  • viele Zielkonflikte und verschiedene Schwerpunkte der Entwicklung
  • DOM1 als erste vom W3C standardisierte Version
  • DOM2 unterstützt Namespaces (schlecht, aber immerhin)
  • DOM3 ist die aktuelle Grossbaustelle des W3C

Exkurs Inhalt eines XML Dokuments

• manche an sich triviale Fragen in XML sind trickreich
  • <test a="1" b="2" xmlns:c="tag:3"/>
  • wieviele Attribute hat das Element <test>?
• XML kennt nur Elemente und Attribute
  • es gibt also drei Attribute
• DOM kennt XML Namespaces (ab DOM2)
  • in DOM sind es trotzdem drei Attribute (davon eines mit Nebenwirkungen)
• XPath/XSLT basiert auf einer Abstraktion
  • es gibt zwei Attribute (und eine Namespace-Deklaration)
• für ganz Pedantische
  • ohne Schema-Kenntnis weiss man es ohnehin nicht genau
  • das Schema kann Default-Attribute hinzufügen

Zwischenresultat

• XML ist eine reine Syntax
• Modellieren und Programmieren möchte man eher mit Abstraktionen
• Komplexere Anwendungen brauchen komplexere Abstraktionen

1.3 XPath

• Die erste standardisierte Abstraktion von XML (1999)
• XSLT basiert auf dem separaten Standard XPath
  • XSL wurde geteilt in XPath, XSLT und XSL-FO
  • XPath wurde als wiederverwendbare Sprache designt
• XPath setzt auf einem abstrakten Baummodell auf
  • Infoset als Baummodell eines XML Dokuments
  • XPath Node Tree als Simplifikation dieses Modells
• Spannungen XPath ↔ DOM als Motivation für das Infoset

1.4 XML Infoset

• Die wiederkehrenden Frage beim Standard-Schreiben:
  • was ist der Inhalt eines XML Dokuments? (Kommentare? Character References?)
  • was ist reine Syntax eines XML Dokuments? (Attributreihenfolge?)
  • über welche Aspekte könnte man debattieren?
• Das Infoset als Standard für Standard-Autoren
  • gedacht als interne Klärung der wiederkehrenden Fragen
  • recht lange Entwicklungszeit (05/1999-10/2001)
  • unterschiedliche Ziele verschiedener Interessengruppen
• Das Infoset beinhaltet einige Vorverarbeitung
  • Normalisierung von Zeichen (Character References, CR/LF, Attributwerte)
  • Auflösung von Entities
  • Hinzufügen von Defaultwerten aus dem Schema
• Nicht jedes XML Dokument hat ein Infoset und vice versa!

1.5 XSLT

• Streng genommen kein XML-Standard
  • Eingabe und Ausgabe sind XPath Node Trees
    • minimale Steuerung des Parsing (<xsl:strip-space>)
    • minimale Steuerung der Serialisierung (<xsl:output indent="...">)
    • streng genommen beeinflusst dies nur das Infoset
• Verarbeitungsumgebung mit deutlich sichtbaren Einschränkungen
  • Parsing und Serialisierung liegen (fast) ausserhalb der Sprache
  • je nach XML Benutzung gehen wichtige Informationen verloren (Entities)
• External Entities vs. XInclude
  • External Entities sind XML's Mechanismus für die Filestruktur
  • Im Infoset sind diese Verweise bereits aufgelöst
  • XInclude bietet einen equivalenten Mechanismus auf Infoset-Ebene

1.6 DOM3/SAX2/JDOM

• angepasst an die schöne neue Welt des Infoset
• APIs müssen auch mit nicht-Infoset XML klarkommen
• Probleme zwischen den alten Interfaces und dem neuen Infoset
  • DOM3 bietet keine Information über Attributtypen
• DOM3 bietet eine DOMConfiguration "infoset"
  • validate-if-schema, entities, datatype-normalization, cdata-sections → false
  • namespace-declarations, well-formed, element-content-whitespace, comments, namespaces → true
• SAX2 kann ebenfalls Infoset-kompatibel deklariert werden

1.7 XML Schema

• Streng genommen kein XML-Standard
  • Definiert als Validierung (Annotierung) von Infosets
  • XML als Syntax für Schema Components
• Entwickelt als Verbesserung der DTDs
  • Kompromiss aus vielen verschiedenen Vorschlägen
  • erster sehr komplexer Standard in der XML-Welt
• Gedacht als Schema-Sprache, nicht als Modellierungssprache
  • Schemas beschreiben, wie XML Dokumente (oder Infosets) aussehen
  • Modelle wären eine mögliche Grundlage für Schemas
  • bisher gibt es keine Modellierungssprache für XML

1.8 XQuery/XPath Data Model (XDM)

• Datenbanken müssen auf getypten Daten arbeiten
  • einzige Möglichkeit für getypte Operationen (z.B. Vergleiche)
  • sehr gute Möglichkeit für Optimierungen
  • gute Möglichkeit für getypte Abfragesprachen (Type Checking)
• XML kennt keine Typen (ausser für Attribute)
  • XML Schema Part 1 definiert komplexe Typen (XML Strukturen)
  • XML Schema Part 2 definiert simple Typen (atomare Typen)
  • XML Schema definiert Validierung als (Typ-)Annotation
  • validiertes XML ist getyptes XML
• Definition des XQuery/XPath Data Model (XDM)
  • Infoset minus einige (wenige) Dinge
  • plus XML Schema Typ-Annotationen (ergo plus XML Schema Typen)
  • plus ein Container mit einem Modell von Sequenzen und atomaren Werten

1.9 XQuery 1.0 und XSLT 2.0

• Erste Sprachen zum Umgang mit getypten XML
  • Eingabe ist ein Schema-validiertes Dokument
  • Programmiert wird in einer getypten Sprache
• Statische und dynamische Typenprüfung
  • statische Typenprüfung basiert auf Programm und Schema
  • dynamische Typenprüfung basiert auf den Eingabedaten
• Typenprüfung und die Ausführungsumgebung
  • XQuery wird oft in der gleichen Umgebung wiederholt ausgeführt
  • XSLT wird oft wie eine Script-Sprache eingesetzt (neu-Kompilierung)
  • statische Typenprüfung ist für XQuery sinnvoller
  • für XSLT Programme eher Debugging als Optimierung

2. Zusammenhänge

XML?

• News Flash: Das Bit löst alle Ihre Interop-Probleme!
• Fast alle XML-Technologien heute sind Infoset-Technologien
  • XML Schema ist eine Schema-Sprache für Infosets
  • XQuery erlaubt Abfragen von Typ-annotierten Infosets
  • SOAP ist ein Protokoll für den Infoset-Austausch
• XML 1.* ist bisher die einzige Syntax für Infosets
  • enthält einige nicht abgebildete Features (z.B. Entities)
  • enthält eine Menge an Syntax-Variationen
  • erzeugt sehr viel Volumen für ein gegebenes Infoset
• Sollten Infosets anders codiert werden können?
  • bilateral schon heute möglich
  • über Web-Standards schon heute möglich (HTTP Content-Encoding)
  • verschiedene Applikationen haben verschiedene Anforderungen
  • eine W3C Working Group bearbeitet das Problem (seit 09/2003)

XML als Mittel zum Zweck

• Sehr wenige Applikationen werden um XML herum geplant
  • Meist steht ein anders erarbeitetes Modell im Mittelpunkt
  • XML ist lediglich ein Mittel, wie man strukturierte Daten austauscht
  • das XML sollte sich so gut wie möglich am Modell orientieren
• verschiedene Szenarien erfordern verschiedene Ansätze
  • XML als reines Serialisierungsformat ist trivial
  • XML als Offenlegung des Datenmodells ist sehr anspruchsvoll
  • eine offene Architektur sollte wirklich offen sein
• XML ist eine gute Grundlage für Lösungen, aber keine Lösung
  • ohne Schema ist XML oftmals wertlos
  • ohne Semantik ist ein Schema oftmals wertlos
  • ohne Pragmatik ist Semantik oftmals wertlos
  • XML rückt immer weiter in den Kern von Applikationen vor

XML und komplexe Applikationen

Challenges für XML-basierten Austausch

• Wieviel des Applikations-Modells kann und will man abbilden?
  • ein Austauschmodell (Untermenge des Gesamtmodells) muss existieren
  • das Austauschmodell muss Bestands-Information enthalten
  • das Austauschmodell muss Ereignis-Information enthalten
• diese Modelle müssen offengelegt und dokumentiert sein
  • ohne Modell(e) ist die Interpretation unmöglich
  • XML oder Schemas alleine bieten keine ausreichende Information
  • die Abbildung der Modelle auf Schemas sollte gut sein
• Modelle: komplexe Zusammenhänge verschiedener Klassen
  • XML konzentriert sich auf hierarchische Zusammenhänge
  • komplexere Zusammenhänge müssen mit Referenzen gelöst werden
  • XML-Strukturen mit vielen Referenzen sind schwer zu verarbeiten

3. Probleme

Was wird mit XML ausgetauscht?

• Bei einfachen Strukturen ist die Interpretation oft einfach
  • keine komplexen Interpretationen oder Zusammenhänge
  • im Prinzip wäre auch eine nicht-XML Darstellung möglich
• Bei komplexen Strukturen ist die Beschreibung essentiell
  • wie genau dürfen die auzutauschenden Daten strukturiert werden?
  • welche Modell-Constraints sind nicht im Schema erfasst?
  • was ist die Bedeutung der auzutauschenden Daten?
  • ohne Modell-Informationen sind diese Fragen nicht zu beantworten
• XML ist eine Syntax
  • die Bedeutung muss auf andere Arten definiert werden
  • häufig exisitieren bereits Modelle ausserhalb der XML-Welt
  • wie verbindet man das Modell (am besten) mit dem XML?

XML als Abbildung von Konzepten

Arbeiten mit XML Daten

• XML als einfach strukturiertes Format
  • Einlesen und Validieren mit Standard-Software möglich
  • Weiterverarbeitung hängt vom XML Design ab
• letztendlich muss mit den Daten aus Modellsicht gearbeitet werden
  • ein Teil des Encoding/Decoding kann mit XML erledigt werden
  • wieviel muss zusätzlich implementiert werden?
  • dieser Aufwand ist in jeder Applikation notwendig!
• Homogene vs. heterogene Systeme
  • einfaches Mapping, falls das Modell überall gleich implementiert ist
  • individuelle Mappings, falls es verschiedene Implementierungen gibt
  • je mehr XML unterstützt, desto mehr kann wiederverwendet werden

Zugriff auf XML Daten

• XDM erlaubt Zugriff auf Typinformationen
  • verlangt nach einem XML Schema
  • ermöglicht robusteres Programmieren als Namens-basiert
  • Zugriff jedoch auf XML Schema Typen (oft generiert aus einem Modell)
• Zusammenhang zwischen Modell und XML Schema?
  • Modell implizit oder keine automatische Ableitung möglich
  • idealerweise sollten Modell-Annotationen die Ableitung steuern
  • bei unterspezifizierten Annotationen Warnung und Default-Verhalten
• Abbildung komplexer Modelle auf XML Schema
  • momentan mehr Kunst als Wissenschaft (reine Handarbeit)
  • z.T. von Software-Problemen gesteuert (z.B. Substitution Groups)
  • kann Auswirkungen auf naiven Umgang mit dem XML haben

Beispiel: Generierte Schemas und XML

<GM03Comprehensive.Comprehensive.MD_DataIdentification TID='xDataIdentx501x0'>
  <status>
    <GM03Core.Core.MD_ProgressCode_>
      <value>completed</value>
    </GM03Core.Core.MD_ProgressCode_>
  </status>
  <abstract>
    <GM03Core.Core.PT_FreeText>
      <textGroup>
        <GM03Core.Core.PT_Group>
          <language>DE</language>
          <plainText>...</plainText>
        </GM03Core.Core.PT_Group>
      </textGroup>
    </GM03Core.Core.PT_FreeText>
  </abstract>
  <MD_Metadata REF='xMetadatax501'/>
  <citation REF='xCitationx1601'/>
  ...
</GM03Comprehensive.Comprehensive.MD_DataIdentification>

<GM03Core.Core.descriptiveKeywordsMD_Identification TID='x2533'>
  <descriptiveKeywords REF='xKeywordsx89'/>
  <MD_Identification REF='xDataIdentx501x0'/>
</GM03Core.Core.descriptiveKeywordsMD_Identification>

Probleme bei generierten Schemas

• Keine komplette Modellinformation im Schema
  • Vererbung nicht abgebildet
  • Rolleninformation nicht komplett abgebildet
• Wie kommt eine Applikation an das Modell?
  • Zugriff auf das Originalmodell (u.U. sehr komplexe Umgebung)
  • Zusammenstellung der relevanten Modellinformationen als XML
• Wie arbeitet eine Applikation mit den Daten?
  • identische Modellkonstrukte werden verschieden abgebildet (Assoziationen)
  • robustes Programmieren ist nahezu unmöglich ohne komplettes Wissen
• Re-Implementierung dieses Wissen auf Basis der Daten
  • Modell- und Abbildungsinformationen sind notwendig
  • auf dieser Basis kann dann auf Objekt-Ebene programmiert werden
  • andere Sicht: das Modell kann rekonstruiert werden

XSD und zusätzliche Modellinformation

4. Weisse Flecken

4.1 XML und Modellierung

• XML Schema als Datenmodell?
  • XML Schema ist eher auf der logischen Ebene
  • einige Aspekte fast physisch (Normalisierung von Werten)
  • für konzeptuelle Modellierung fehlen Abstraktionen
• konzeptuelle Modelle für XML sind (noch) rar
  • konzeptuelle Modellierung hat Schwerpunkte in anderen Disziplinen
  • Datenbank-Fraktion erweitert ER um einige XML-Konstrukte
  • Dokumenten-Fraktion betrachtet Bäume und ignoriert Referenzen
• Datenbanken und XML
  • die Welt ist relational (u.U. mit XMLType Attributen, SQL/XML:2003)
  • XML Datenbanken in Arbeit (XMLTable und XMLQuery, SQL/XML:2006)
  • vorerst keine Modellierungssprache für XDBMS
• Software Engineering und XML
  • Klassen mit Assoziationen als wichtigste Konstrukte
  • XML als deren mögliche Serialisierung (Persistierung)

4.2 Schema-Versionierung

• XQuery integriert Typ-Informationen in das Modell
  • Typ-Name kann nach Validierung abgefragt werden
• Was kann man mit dem Typ-Namen machen?
  • auf Gleichheit mit bekannten/erwarteten Typen prüfen
  • Zugriff auf das Schema selber ist nicht möglich
• Versionierung ist in lose gekoppelten Systemen essentiell
  • Änderungen können auf beiden Seiten passieren
  • XML Schema bietet Mechanismen für offene und erweiterbare Schemas
• XML Schema bietet keine Unterstützung für Versionierung
  • der Sorgfalt und dem Wissen des Designers überlassen
  • Robustheit ist schwerer zu erreichen ohne einen Rahmen
  • Versionierungsrichtlinien sind ein wichtige Komponente

4.3 Schema-Design

• was ist ein gutes XML Schema?
  • verschiedene Mechanismen für Ähnliches oder Gleiches
  • Auswahl schwer und nicht einfach zu begründen
  • Schemas werden oft generiert mit wenig Parametrisierungsmöglichkeiten
• Type Substitution als Fallgrube für Designer und Nutzer
  • Instanz enthält andere Typen als das Content Model
  • naiv programmierte Applikationen scheitern
  • bei xsi:type am Typ des Elements
  • bei Substitution Groups am Namen des Elements
  • einzig sichere Variante: xsi:type und restriction
• XML Schema ist komplex, XML wird als einfach verkauft
  • ist ein gutes Schema eines, das alle Möglichkeiten nutzt? (WWW2005 Paper)
  • ist ein gutes Schema eines, mit dem einfach zu arbeiten ist?
  • wie kann man die Distanz zum Modell bewerten?

4.4 Zugriff auf Schema-Informationen

• Getyptes XML wird immer wichtiger werden
  • XDM beruht auf XML Schema
  • XML Datenbanken werden oft getypte Daten enthalten
• Was ist ein Typ eines Elements oder Attributes?
  • ein QName (Namespace Name + Local Name)
• XML Schema basiert auf einem abstrakten Modell
  • XML Schema ist definiert auf der Basis von Schema Components
  • XML Schema definiert eine XML Notation für Components
  • der interessante Aspekt ist die Struktur der Components
• Es gibt kein standardisiertes Interface für Components
  • Arbeiten auf dem XML ist sehr aufwendig (Syntax-Variationen)
  • IBM hat ein solches API veröffentlicht (W3C Submission)
  • beim W3C wird dieses Thema momentan nicht aktiv verfolgt

4.5 XML-orientierte Software-Entwicklung

• Momentan ein Wunsch und keine Realität
  • Modellierung und Programmierung sind erst auf dem Weg
  • momentan ist sehr viel Handarbeit erforderlich (teuer & unsicher)
• Integration von XML-Features in bestehende Modelle
  • Mixed Content: Essentiell für XML (Text mit eingebetteter Struktur)
  • Sequenzen: XML ist ein geordneter Baum (<xs:all>, maxOccurs > 1)
  • Alternativen in Inhalten (<xs:choice>, Union Types)
  • Anzeichen für prinzipielle Probleme XML → ER
• Abstraktionslevels sind noch unklar
  • Beziehungen können auf Hierarchien oder Referenzen abgebildet werden
  • Hierarchien können in verschiedenen Schemas verschieden aufgebaut sein
  • die Abbildung Modell → Schema muss flexibel sein

JAXB für das Binding Schema ↔ Klasse?

• Java Architecture for XML Binding (JAXB), JSR 222
• sehr einfacher Weg von einem Schema zu Klassendefinitionen
  • unterstützt werden DTDs und XML Schema
  • vor allem bei guten XML Schemas nützlich
  • (unterstützt auch die andere Richtung: Klasse ↔ Schema)
• durch Annotationen kann die Abbildung beeinflusst werden
  • ist das Schema generiert oder Handarbeit?
  • in der Praxis handgeschrieben für schönere Klassen
  • im Idealfall aus dem Modell generierte Annotationen
• Vereinfachung des Parsing und Generierens von XML
  • Klassendefinitionen entsprechen der XML Schema Struktur
  • je nach Applikation passend oder zu tiefe Abstraktionsebene
  • Modell-Objekte müssen u.U. von Hand konstruiert werden

JAXB für Parsing und Serialisierung

Danke! Fragen?

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