XML-Schemaevolution : Änderung eines XML-Schemas mit...

XML-Schemaevolutionnderung eines XML-Schemas mit automatisierter

Adaption assoziierter XML-Dokumente

Dissertationvon

Dipl.-Inf. Thomas Nsingerzur

Erlangung des akademischen GradesDoktor-Ingenieur (Dr.-Ing.)

der Fakultt fr Informatik und Elektrotechnikder Universitt Rostock

zef007Schreibmaschinentext














zef007Schreibmaschinentexturn:nbn:de:gbv:28-diss2016-0094-3















Gutachter:Prof. Dr. rer. nat. habil. Andreas Heuer (Universitt Rostock)Prof. Dr. Torsten Grust (Universitt Tbingen)Prof. Dr. rer. nat. habil. Gunter Saake (Universitt Magdeburg)

Datum der Einreichung: 1. Februar 2016Datum der Verteidigung: 7. Juli 2016

2

Kurzfassung

Die eXtensible Markup Language (XML) ist ein etabliertes und standardisiertesHilfsmittel zum Austausch und Speichern strukturierter und semistrukturierterInformationen. Entspricht die Struktur eines XML-Dokuments dem Standard desW3C (World Wide Web Consortium), dann ist ein XML-Dokument wohlgeformt.XML-Schema, abgekrzt XSD (XML Schema Definition), ist eine Schema-

sprache des W3C zur Spezifikation von Anforderungen bezglich der Struktur unddes Inhalts von XML-Dokumenten. Ein wohlgeformtes XML-Dokument ist gltig,wenn ein XML-Schema existiert und dessen Anforderungen realisiert sind.Eine nderung bzw. Evolution eines XML-Schemas (XML-Schemaevolution)

kann unterschiedliche Ursachen haben, zum Beispiel die Korrektur von Fehlern,die Beseitigung von Unklarheiten, die Weiterentwicklung von Anwendungen oderim Allgemeinen die Anpassung der darzustellenden Informationen an aktuelle An-forderungen. Es ergibt sich als eine Konsequenz der XML-Schemaevolution dieFragestellung, ob vormals schemakonforme XML-Dokumente weiterhin gltig be-zglich des neuen, vernderten XML-Schemas sind. Dieses Gltigkeitsproblemund dessen Lsung sind Bestandteile der vorliegenden Dissertation.Die grundlegende These der Dissertation ist, dass durch die Erfassung und Cha-

rakterisierung der nderungen am XML-Schema die zur Wahrung oder Wiederher-stellung der Gltigkeit notwendigen Adaptionen der assoziierten XML-Dokumenteautomatisiert hergeleitet werden knnen. Die nachfolgenden Anstze und Mecha-nismen wurden zur Lsung des Gltigkeitsproblems entwickelt und angewendet.Das konzeptuelle Modell EMX (Entity Model for XML-Schema) wird als Ab-

straktion von XML-Schema vorgestellt. Es entsteht eine Drei-Ebenen-Architekturmit Modell-, Schema- und Dokumentebene. Aufgrund der eindeutigen Korrespon-denz werden Schemanderungen stellvertretend auf dem EMX durchgefhrt.nderungen werden durch die domainspezifische Transformationssprache ELaX

(Evolution Language for XML-Schema) beschrieben und geloggt. Die Optimie-rung des Logs wird durch den regelbasierten Algorithmus ROfEL (Rule-basedOptimizer for ELaX) vollzogen, indem unntige, redundante und ungltige ELaX-Operationen erkannt und beseitigt werden. Das Ziel ist die Minimierung der Ope-rationsanzahl fr die anschlieende, automatisierte Herleitung der Adaptionen.Eine Klassifikation der Operationen ist die Grundlage fr die Analyse der

Auswirkungen von Schemanderungen auf die Dokumentebene. Ist eine Dokument-anpassung notwendig bzw. aufgrund der mehrdeutigen Korrespondenz zwischenSchema- und Dokumentebene mglich, dann werden Transformationsschritte zurAdaption erzeugt. Die Transformation wird auf dem DOM (Document ObjectModel) der mit dem XML-Schema assoziierten XML-Dokumente durchgefhrt.Der ForschungsprototypCodeX (Conceptual design and evolution of XML sche-

mas) dient als Demonstrator, mit welchem die vorgestellten Anstze und Mecha-nismen der vorliegenden Dissertation evaluiert werden knnen.

3

Abstract

The eXtensible Markup Language (XML) is a well-established and standardizedformat for exchanging and storing structured and semi-structured information. Ifthe structure of an XML document complies with the standard of the W3C (WorldWide Web Consortium), the XML document can be seen as well-defined.The XML Schema, abbreviated XSD (XML Schema Definition), is one schema

language of the W3C for specifying requirements for the structure and content ofXML documents. An XML document is called valid, if it fulfills all restrictions andconditions of an associated XML Schema.The modification or evolution of an XML Schema could have different reasons,

for example the error correction, the clearance of obscurities, the further deve-lopment of applications or in general the change of requirements for exchangedinformation. The resulting problem of modifying an XML Schema is that existingXML documents, which were valid against the former XML Schema, could con-sequently lose their validity and have to be adapted as well (co-evolution). Theabove mentioned validity problem and its solution are the main topics of thisdissertation. The following approaches and mechanisms were developed and usedfor the solution of the validity problem.The conceptual model EMX (Entity Model for XML-Schema) is a simplified

representation of an XML Schema. The resulting three-layer architecture consistsof a model, a schema and a document layer. Since a unique mapping between EMXand XSD exists, modifications are applied on the conceptual model.Modifications are formally described by the domain-specific transformation lan-

guage ELaX (Evolution Language for XML-Schema). The applied operations arelogged. The ruled-based algorithm ROfEL (Rule-based Optimizer for ELaX) thenreduces the number of logged ELaX operations by identifying and removing unne-cessary, redundant and invalid operations. This reduction is an essential prerequi-site for the following automatic derivation of transformation steps.The classification of operations is the basis of an impact analysis of schema

modifications to the document layer. If an adaption is necessary, or its possiblebecause of the ambiguous mapping of the schema and the document layer, XMLdocument transformation steps are automatically derived. These steps are used forthe adaption of the DOM (Document Object Model) of XML documents whichare associated with the modified XML Schema.The research prototype CodeX (Conceptual design and evolution of XML sche-

mas) serves as demonstrator, which can be used for the evaluation of the abovementioned approaches and mechanisms presented in this dissertation.

4

Inhaltsverzeichnis

1 Einleitung 91.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1.1 Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . 141.1.2 Schwerpunkte der Arbeit . . . . . . . . . . . . . . . . . . . . 14

1.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Grundlagen 172.1 XML-Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.1 Strukturbeschreibung des XML-Schemas . . . . . . . . . . . . 172.1.2 XML-Schema Version 1.1 . . . . . . . . . . . . . . . . . . . . 262.1.3 Modellierungsstile von XML-Schema . . . . . . . . . . . . . . 29

2.2 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3 Evolution und Versionierung . . . . . . . . . . . . . . . . . . . . . . 31

3 Stand der Technik 333.1 Klassische Anstze der Schemaevolution . . . . . . . . . . . . . . . . 33

3.1.1 Relationenmodell . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.2 Objektorientierte Schemata . . . . . . . . . . . . . . . . . . . 353.1.3 Document Type Description - DTD . . . . . . . . . . . . . . 37

3.2 Aktuelle Anstze der XML-Schemaevolution . . . . . . . . . . . . . 393.2.1 XML-Schema in Datenbanksystemen . . . . . . . . . . . . . . 403.2.2 Altova DiffDog . . . . . . . . . . . . . . . . . . . . . . . . . . 453.2.3 XML-Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . 483.2.4 X-Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.2.5 GEA-Framework . . . . . . . . . . . . . . . . . . . . . . . . . 573.2.6 XCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.2.7 Weitere Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.3 Zusammenfassung der vorgestellten Anstze . . . . . . . . . . . . . . 74

4 Lsungsansatz 774.1 Konzeptuelle Modellierung . . . . . . . . . . . . . . . . . . . . . . . 77

4.1.1 Konzeptuelles Modell . . . . . . . . . . . . . . . . . . . . . . 774.1.2 Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.2 Drei-Ebenen-Architektur . . . . . . . . . . . . . . . . . . . . . . . . 844.2.1 Ebenen-spezifische Operationen . . . . . . . . . . . . . . . . . 85

5

Inhaltsverzeichnis

4.2.2 Anwendung ebenen-spezifischer Operationen . . . . . . . . . . 874.3 Speicherung und Verwaltung von Modellen . . . . . . . . . . . . . . 88

4.3.1 Speicherung des konzeptuellen Modells . . . . . . . . . . . . . 884.3.2 Anwendung der Speicherung des konzeptuellen Modells . . . . 914.3.3 Verwaltung von Modellen . . . . . . . . . . . . . . . . . . . . 92

5 Transformationssprache 955.1 Kriterien der Transformationssprache . . . . . . . . . . . . . . . . . 955.2 Spezifikation und Umsetzung von nderungen . . . . . . . . . . . . 96

5.2.1 Hinzufgen von Elementen . . . . . . . . . . . . . . . . . . . 975.2.2 Lschen von Elementen . . . . . . . . . . . . . . . . . . . . . 995.2.3 ndern von Elementen . . . . . . . . . . . . . . . . . . . . . . 995.2.4 Anwendung der Transformationssprache . . . . . . . . . . . . 100

5.3 Erfassung und Auswertung von nderungen . . . . . . . . . . . . . . 1035.3.1 Speicherung von nderungen . . . . . . . . . . . . . . . . . . 1035.3.2 Anwendung des Loggings . . . . . . . . . . . . . . . . . . . . 104

5.4 Optimierung der Transformationssprache . . . . . . . . . . . . . . . 1055.4.1 Regelbasierter Optimierer . . . . . . . . . . . . . . . . . . . . 1065.4.2 Anwendung des regelbasierten Optimierers . . . . . . . . . . . 1115.4.3 Korrektheit des regelbasierten Optimierers . . . . . . . . . . . 113

6 Adaption der Instanzen 1156.1 Klassifikation der Operationen . . . . . . . . . . . . . . . . . . . . . 115

6.1.1 Kapazitt und Informationsgehalt von ELaX . . . . . . . . . 1176.1.2 Herleitung der Anpassung der Instanzebene . . . . . . . . . . 120

6.2 Analyse der Auswirkungen auf die Instanzen . . . . . . . . . . . . . 1216.2.1 Hinzufgen und Lschen von Komponenten . . . . . . . . . . 1236.2.2 ndern von Komponenten . . . . . . . . . . . . . . . . . . . . 125

6.3 Lokalisierung von Komponenten . . . . . . . . . . . . . . . . . . . . 1276.3.1 Identifizierung von Komponenten . . . . . . . . . . . . . . . . 1286.3.2 Konstruktion von Lokalisierungspfaden . . . . . . . . . . . . . 132

6.4 Generierung von Informationen . . . . . . . . . . . . . . . . . . . . . 1376.4.1 Einfacher Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . 1386.4.2 Komplexer Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . 1406.4.3 Wildcard Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . 1436.4.4 Elementreferenzen . . . . . . . . . . . . . . . . . . . . . . . . 145

6.5 Anwendung der Transformationsschritte . . . . . . . . . . . . . . . . 1516.5.1 Einfhrung eines Beispielszenarios . . . . . . . . . . . . . . . 1526.5.2 Anpassung des Beispielszenarios . . . . . . . . . . . . . . . . 1566.5.3 Adaption der Instanzen des Beispielszenarios . . . . . . . . . 159

6

Inhaltsverzeichnis

7 Prototypische Umsetzung 1697.1 Architektur des Prototypen . . . . . . . . . . . . . . . . . . . . . . . 169

7.1.1 Details der Implementierung . . . . . . . . . . . . . . . . . . 1707.1.2 Einordnung der vorgestellten Anstze . . . . . . . . . . . . . 171

7.2 Forschungsprototyp CodeX 2.0 . . . . . . . . . . . . . . . . . . . . . 1737.2.1 Grafische Benutzeroberflche . . . . . . . . . . . . . . . . . . 1747.2.2 EMX-Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . 1757.2.3 Umsetzung des konzeptuellen Modells . . . . . . . . . . . . . 1787.2.4 Anwendung des EMX-Editors . . . . . . . . . . . . . . . . . . 1887.2.5 Weitere Features von CodeX 2.0 . . . . . . . . . . . . . . . . 195

8 Schlussbetrachtung 1998.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1998.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Literaturverzeichnis 205

Abbildungsverzeichnis 223

Quellcode und Dateien 229

A Anhang 231

B berblick der Sprachspezifikation 305

C Hinweise zum Prototypen 311

Eidesstattliche Versicherung 313

Thesen 315

7

1. Einleitung

Die strukturierte Speicherung, Analyse und Darstellung von Informationen in Zei-ten immer strker anwachsender Datenmengen stellt eine nicht zu unterschtzendeThematik fr zuknftige Entwicklungen dar. Die hohe Verfgbarkeit von teilweiseun-/strukturiertem Wissen in heterogenen Quellen, sowie der effiziente Zugriff undAustausch von Informationen zum Zwecke der Verarbeitung, machen die Gesamt-problematik noch komplexer.Beispiele in diesem Szenario sind das Internet der Dinge [MF10] mit dessen

technologischen Herausforderungen an die Interoperabilitt und das Datenvolu-men, Online Social Networks [Hei10] mit unterschiedlichsten, nutzergeneriertenInhalten, sowie ganz allgemein Big Data [KTGH13] mit dem steigenden Volumen,der Vielzahl von Daten und deren Zuverlssigkeit.Eine Mglichkeit zum allgemeinen Umgang mit heterogenen Daten sind stan-

dardisierte und preiswerte Massentechnologien [..] der Web- und Internettechno-logie [MF10]. Die offenen Standards des World Wide Web Consortium (W3C)[W3C15a] sind diesbezglich ein wichtiges Werkzeug und Hilfsmittel, allen vorandie diversen XML-Technologien [W3C15b] zum effizienten Austausch, zur formalenBeschreibung, zur Transformation oder zur Anfrage von Informationen.Die eXtensible Markup Language (XML) [BPSM+08] ist ein solches etablier-

tes und standardisiertes Hilfsmittel zum Austausch und Speichern strukturierterund semistrukturierter Daten bzw. Informationen. XML ist eine selbstbeschrei-bende, textbasierte Auszeichnungssprache (Markup-Sprache), das heit, Datenund Informationen ber die Bedeutung der Daten (also Strukturinformationen)treten gemeinsam in einem Dokument auf [KM03]. Ein XML-Dokument wird alswohlgeformt bezeichnet, wenn die im Standard [BPSM+08] definierten Regeln ein-gehalten werden. Dazu zhlen unter anderem die Forderung korrekt geschachtelter,mglicherweise leerer Elementtags, das Vorhandensein eines Wurzelelements, sowieEinschrnkungen bezglich erlaubter Bezeichner von Elementen und Attributen.Das XML-Beispiel 1.1 stellt ein wohlgeformtes, abstraktes XML-Dokument dar.1

Es existiert ein Wurzelelement (root) mit weitergehenden Informationen ber einenNamensraum (xmlns), einen Schemastandort, weitere Attribute (a1 ), Kinderele-mente (e1 ) und zugeordnete Werte (0 ).Die Struktur oder der Aufbau von XML-Dokumenten kann durch ein XML Sche-

ma beschrieben werden, wobei die grundlegenden die Document Type Definition1Abstrakte Beispiele werden genutzt, um Diskussionen ber die Relevanz beschriebener nderungen inder Realitt zu vermeiden und eine mglichst groe Vielfalt von Konzepten darstellen zu knnen.

9

1. Einleitung

00

XML-Beispiel 1.1: Wohlgeformtes XML-Dokument

(DTD) [BPSM+08], Relax-NG [CM01, JTC08], Schematron [JTC06] und XMLSchema Definition (XSD) [FW04] sind. Die primren, vom W3C definierten XMLSchema sind die DTD und XSD [W3C15c], wobei XSD (nachfolgend wie in [BL01]als XML-Schema bezeichnet) als Nachfolger2 der DTD angesehen wird und we-sentlich umfangreichere Darstellungsmglichkeiten bietet. Die DTD ist stark aufdokumentenorientierte Bedrfnisse zugeschnitten [..] Datentypaspekte spielen eineuntergeordnete Rolle [..] [LS04]. XML-Schema behlt die prinzipielle Mchtig-keit einer DTD zur Definition von Inhaltsmodellen bei und ergnzt diese um einereichhaltige Mglichkeit, Datentypen zu definieren. [Lau05] Ein grundlegendesKonzept von XML Schema (XML-Schema, Anm. d. Autors) ist, Typen zu defi-nieren und dann ber Deklarationen Namen zu Typen zuzuordnen, um auf dieseWeise Beschrnkungen fr das Auftreten von Elementen und Attributen in ent-sprechenden XML-Dokumenten zu spezifizieren. [Sch03]Ein wohlgeformtes XML-Dokument wird als gltig oder valide bezeichnet, wenn

ein XML Schema existiert und dessen Einschrnkungen realisiert sind. Das XML-Dokument des XML-Beispiels 1.1 ist valide zum XML-Schema 1.2.

XML-Beispiel 1.2: XML-Schema des XML-Dokuments 1.1

Es existieren ein Schemaelement (xs:schema), verschiedene Element- (root, e1,e2 ) und Attributdeklarationen (a1, a2 ), sowie eine Typdefinition eines komple-xen Typs (roottype). Des Weiteren werden explizit Anforderungen an die Typen2oder auch Erweiterung: [..] XML Schemas can be seen as an extension of DTDs [..] [BNdB04]

10

(type=..), an die Reihenfolge (xs:sequence) und die Hufigkeit des Auftretensvon Elementreferenzen (minOccurs=.., maxOccurs=..) und Attributreferenzen(use=..) definiert.3 Das XML-Dokument des XML-Beispiels 1.1 erfllt alle ge-stellten Einschrnkungen und beinhaltet alle notwendigen Strukturen, es ist somitgltig bezglich XML-Schema 1.2.Das eben vorgestellte XML-Schema wird nun verndert, es wird evolutioniert

(XML-Schemaevolution). nderungen knnen unterschiedliche Ursachen ha-ben, zum Beispiel die Korrektur von Fehlern, die Beseitigung von Unklarheiten,die Weiterentwicklung von Anwendungen oder im Allgemeinen die Anpassung derdarzustellenden Informationen an aktuelle Anforderungen. Als Konsequenz ent-steht das nachfolgende XML-Schema im XML-Beispiel 1.3.

XML-Beispiel 1.3: Verndertes XML-Schema 1.2

Das XML-Schema ist eine Kopie des XML-Beispiels 1.2, allerdings wurden einige,hier rtlich hervorgehobene Details angepasst. Die Anpassungen beziehen sich aufdas Inhaltsmodell (xs:choice), die minimale Anzahl der Durchlufe der Auswahlund der Elementreferenz e1 (jeweils minOccurs=2), sowie Einschrnkungen desAuftritts der Attributreferenzen (use=optional und use=prohibited).Es ergeben sich als Folge der XML-Schemaevolution Probleme. Allen voran muss

das Gltigkeitsproblem thematisiert werden, das heit ob ein vormals schema-konformes XML-Dokument ebenso gltig bezglich des neuen, vernderten XML-Schemas ist. Das XML-Dokument des XML-Beispiels 1.1 ist weiterhin gltig.Des Weiteren ergibt sich die Fragestellung, ob aus den nderungen am XML-

Schema Rckschlsse auf die Gltigkeit gezogen werden knnen. Zum Beispiel,ob die nderungen allgemein instanzverndernde, instanzerhaltende, instanzerwei-ternde oder instanzreduzierende Operationen sind. Als letztes sollte die Gltigkeit,in dem Fall das diese nicht mehr garantiert werden kann, wieder hergestellt, zumindestens aber analysiert und erkannt werden.3Detaillierte Erluterungen ber XML-Schema im Allgemeinen folgen im Kapitel 2.1 (XML-Schema).

11

1. Einleitung

0string0

XML-Beispiel 1.4: Nach Anpassung des XML-Schemas 1.2 ungltiges XML-Dokument

Die hohe Komplexitt der Gesamtproblematik, welche durch die Einfachheit derBeantwortung bezglich des XML-Dokuments des XML-Beispiels 1.1 geschlussfol-gert werden knnte, kann mit einem minimal vernderten XML-Dokument illus-triert werden. Das XML-Dokument des XML-Beispiels 1.4 wurde im Vergleich zuXML-Beispiel 1.1 an den rtlich hervorgehobenen Positionen verndert. Es wurdedas Attribut a2 hinzugefgt, das Element e2 ergnzt sowie ein Element e1 ent-fernt (visualisiert mittels durchgestrichener Komponente). Das XML-Dokumentist gltig bezglich des XML-Schemas 1.2, allerdings ist es ungltig bezglich desvernderten XML-Schemas 1.3.Die angesprochene Komplexitt ergibt sich daraus, dass einerseits XML-Schema

eine hoch komplexe Spezifikation ist, die durch die erlaubte Optionalitt (use=optional und minOccurs=0) und Flexibilitt (z.B. choice) unterschiedlichste,gltige XML-Dokumente ermglicht.Whrend zum Beispiel die Anpassung der Attributreferenz a1 keine gltigkeits-

verletzende Operation ist, erfordert die Attributreferenz a2 eine Lschung desentsprechenden Attributs im XML-Dokument (insofern vorhanden).Andererseits sind die nderungen kontextabhngig, das heit eine nderung

kann nicht nur Auswirkungen auf die entsprechenden Komponenten im XML-Dokument haben (z.B. ein Attribut a2 wird gelscht), sondern ebenso abhngigvom Umfeld (z.B. e1 und e2 sind jeweils voneinander abhngig, s.u.) und weiter-gehenden Randbedingungen sein (z.B. das Wurzelelement ist root).Das ndern des Inhaltsmodells von einer Reihenfolge (sequence) auf eine Aus-

wahl (choice) ist nur dann nicht gltigkeitsverletzend, wenn die Elementreferenzene1 und e2 jeweils maximal zweimal auftreten (beide maxOccurs=2). Pro Durch-lauf des Inhaltsmodells wrde genau eine der Referenzen ausgewhlt werden. Trittaber e1 mindestens dreimal auf, und e2 ist ebenso gegeben, dann ist das XML-Dokument nicht mehr gltig. Es ist des Weiteren denkbar, dass die Elementrefe-renzen abwechselnd im XML-Dokument auftreten (z.B. durch das Ignorieren derStreichung von e1 im XML-Beispiel 1.4). Somit wre eine Sortierung notwendigund zielfhrend, insofern die maximale Hufigkeit des Inhaltsmodells dies im Ver-gleich zu den Hufigkeiten der Elementreferenzen zulsst.Darber hinaus ergeben sich Folgeprobleme. Zum Beispiel muss das XML-Do-

12

1.1. Problemstellung

kument des XML-Beispiels 1.4 erweitert werden, es fehlt ein Element e1. Es musssomit Wissen generiert werden, da der Datentyp xs:decimal keine leeren Elementeermglicht, zeitgleich aber die Deklaration von e1 keine zustzlichen Informationenbeinhaltet (z.B. Defaultwerte). Nullwerte, die aus dem Bereich der Datenbankenbekannt sind, existieren nicht im XML-Schema. Alternativ knnte das vorhandeneElement e1 gelscht und e2 behalten werden, sodass zu mindestens dieser gltig-keitsverletzende Aspekt gelst wre. Lschungen bedeuten allerdings immer auchden Verlust von Informationen, was in diesem Beispiel zur Wiederherstellung derGltigkeit kaum vermeidbar ist (Attribut a2 und u.U. Element e1 ).

1.1. Problemstellung

Ein berblick ber die Problemstellung der XML-Schemaevolution ist in Ab-bildung 1.1 dargestellt. Unter der Annahme, dass ein XML-Schema (XSD) mit

XML-Schema(XSD)

XML-Schema(XSD)

Gltigkeit Gltigkeit

nderungen

Adaption

Bestimmung dernderungen

XML-Dokumente(XML)

XML-Dokumente(XML)

Abbildung 1.1.: berblick der XML-Schemaevolution

wohlgeformten, gltigen XML-Dokumenten (XML) existiert, werden nderun-gen an dem Ausgangsschema durchgefhrt. Es entsteht als Resultat ein vern-dertes Zielschema (XSD), sodass die Gltigkeit der ehemals schemakonformenXML-Dokumente nicht mehr zwingender Weise gewhrleistet werden kann.Es ergibt sich die Fragestellung, ob durch eine Charakterisierung und Erfassung

(d.h. Bestimmung) der durchgefhrten nderungen am XML-Schema, die zurWiederherstellung der Gltigkeit der XML-Dokumente notwendigen Adaptionenautomatisch hergeleitet werden knnen.Somit wrde eine Mglichkeit existieren, sodass durch die nderung eines XML-

Schemas die damit assoziierten XML-Dokumente ebenfalls angepasst werden kn-nen. Die Gltigkeit der transformierten Instanzen (XML) bezglich des vern-derten XML-Schemas (XSD) knnte gewhrleistet werden, dies wrde der Lsungdes Gltigkeitsproblems im dargestellten Szenario entsprechen.

13

1. Einleitung

1.1.1. Zielsetzung der Arbeit

In der vorliegenden Arbeit wird die obige Problemstellung gelst, indem nderun-gen am XML-Schema bestimmt und zur Adaption der XML-Dokumente genutztwerden. Der Anspruch ist die XML-Schemaevolution als Ganzes zu behandeln,wodurch folgende Zielsetzungen definiert werden:

Spezifikation und Erfassung von nderungen, die ein Nutzer an einem XML-Schema vornimmt.

Analyse, Optimierung und Bereinigung der erfassten nderungen, sowie dieweitestgehend automatische Erstellung von daraus resultierenden Transfor-mationsschritten zur Adaption der XML-Dokumente.

Untersttzung von Nicht-Experten4 bei der hochkomplexen, fehleranflligenEvolution durch ein geeignetes Tool und sinnvolle Abstraktionen.

1.1.2. Schwerpunkte der Arbeit

Es sind aus der Problemstellung drei Schwerpunkte hergeleitet worden, welcheeinen direkten Einfluss auf den Aufbau der Arbeit hatten. Dazu zhlen:

nderungen (Kapitel 4 - Lsungsansatz) Konzeptuelle Modellierung von XML-Schema Verwaltung und Speicherung von Modellen

Bestimmung (Kapitel 5 - Transformationssprache) Spezifikation/Umsetzung von nderungsoperationen Definition einer Updatesprache und deren Optimierung Logging der Nutzeraktion und deren Auswertung

Adaptionen (Kapitel 6 - Adaption der Instanzen) Automatisierte Erzeugung von Transformationsschritten zur Wahrung

und/oder Wiederherstellung der Gltigkeit einer Datenbasis

Die Schwerpunkte werden hauptschlich in den angegebenen Kapiteln themati-siert und behandeln die in der Problemstellung spezifizierten Fragestellungen. Esexistieren allerdings auch implizite Abhngigkeiten zwischen den Schwerpunkten,sodass eine explizite Trennung, welche mit der obigen Auflistung suggeriert wird,nicht mglich ist. Die Erzeugung der Transformationsschritte ist zum Beispiel nurdurch eine vorherige Bestimmung der angewendeten nderungen mglich.4Dies sind Anwender, die ein gewisses Grundwissen der notwendigen XML-Technologien besitzen, ohnedass jeder Aspekt in Tiefe bekannt sein muss. Eine Affinitt zur Informatik wird vorausgesetzt.

14

1.2. Aufbau der Arbeit

Die ersten beiden Zielsetzungen werden durch die Schwerpunkte vollstndig be-handelt. In der dritten Zielsetzung wird ein geeignetes Tool gefordert, welches dieunterschiedlichen Aspekte der obigen Schwerpunkte umsetzt. In Kapitel 7 wird einentsprechender Prototyp beschrieben. Somit existieren analog zu den Schwerpunk-ten auch Abhngigkeiten zwischen den unterschiedlichen Zielsetzungen.Sowohl die Fragestellungen der Problemstellung, als auch die Zielsetzungen und

Schwerpunkte knnen folgerichtig nur als Ganzes behandelt werden. Dies erfolgtin der vorliegenden Arbeit, welche den nachfolgenden allgemeinen Aufbau hat.

1.2. Aufbau der Arbeit

Es werden Grundlagen bezglich verwendeter Techniken in Kapitel 2 berblicks-artig erlutert, bevor klassische und aktuelle Anstze der Evolution von Schemataallgemein, sowie speziell von XML-Schema in Kapitel 3 vorgestellt werden.Die darauf folgenden Kapitel orientieren sich an der obigen Problemstellung. Es

sollen nderungen an einem XML-Schema spezifiziert und erfasst werden, welcheein Anwender an diesem vornimmt. Dafr mssen Mglichkeiten der Abstraktiongefunden werden, um die Komplexitt von XML-Schema handhaben zu knnen.Ein konzeptuelles Modell wird in Kapitel 4 vorgestellt.Des Weiteren ist eine Erfassung der nderungen notwendig, um diese im An-

schluss analysieren, kontextabhngig optimieren, sowie bei Bedarf bereinigen zuknnen. Ein notwendiger Zwischenschritt hierfr ist eine standardisierte Formu-lierung sowie Speicherung der nderungen. Eine domainspezifische Transformati-onssprache und deren Optimierung wird in Kapitel 5 erlutert. Die vollstndigebersicht der Transformationssprache ist in Anhang B enthalten.Erfasste nderungen werden im Anschluss zur automatisierten Erzeugung von

Transformationsschritten zur Wahrung und/oder Wiederherstellung der Gltigkeiteiner Datenbasis verwendet. Dafr ist eine detaillierte Betrachtung der nderungenbezglich deren Einfluss auf die Adaption von Instanzen notwendig. Die Klassifi-kation der nderungen und deren Einfluss auf die Instanzen sind im Kapitel 6beschrieben. Des Weiteren wird die Adaption der Instanzen unter Anwendung dererzeugten Transformationsschritte in einem ausfhrlichen Beispiel erlutert.Die obigen Erkenntnisse und Anstze wurden in einem eigens entwickelten For-

schungsprototypen weitestgehend umgesetzt und stehen somit Anwendern zur Ver-fgung. Der Prototyp und dessen Mglichkeiten werden in Kapitel 7 prsentiert,zustzliche Informationen sind in Anhang C beschrieben.Die Arbeit schliet mit einer Schlussbetrachtung in Kapitel 8 ab. Dabei wird

die vorliegende Arbeit auf Basis der definierten Problemstellung analysiert undbewertet, bevor auf zuknftige, sinnvolle Erweiterungen eingegangen wird.

15

1. Einleitung

In Anhang A sind bersichten und Abbildungen aus den obigen Kapiteln er-gnzt worden, welche zustzliche Informationen bzw. nur geringfgige Anpassun-gen im Vergleich zum entsprechenden Kapitel enthalten.

Hinweise zu Schriftschnitten, Funoten und Zitaten

In der vorliegenden Arbeit werden unterschiedliche Schriftschnitte verwendet.Ein Begriff wird fett hervorgehoben, wenn dieser erstmalig definiert und fr dieGesamtarbeit notwendig ist. Dieser Begriff wird bei der nachfolgenden Verwendunggegebenenfalls kursiv markiert.Wird ein Akronym eingefhrt, dann wird dessen Langform in Klammern ergnzt,

wobei die Buchstaben unterstrichen werden. Akronyme werden mehrfach in derArbeit wiederholt, zu mindestens aber bei deren erstmaligen Einsatz in einemneuen Kapitel. In diesem Fall werden Akronyme ebenso kursiv hervorgehoben.In der Arbeit werden unterschiedliche Abbildungen integriert und im Anschluss

detailliert beschrieben. Sind Begriffe aus der Abbildung nachfolgend im Text ber-nommen worden, dann werden diese ebenso kursiv dargestellt. Als Ausnahme gel-ten die fr die Gesamtarbeit notwendigen Begriffe, welche nach der obigen Regelfett statt kursiv hervorgehoben werden (z.B. Begriffe der Abbildung 1.1).Es werden in der vorliegenden Arbeit lokale Funoten auf den Seiten ergnzt,

insofern zustzliche Informationen gegeben werden. Dies knnen sowohl der Ver-weis auf ein anderes Kapitel sein (siehe auch: Kapitel [..]), als auch die Markie-rung einer zentralen These (siehe auch: These [..]) oder allgemeine Hinweise zurBedienung (Hinweis: [..]). Die letzte Art der Funoten wird im Kapitel 7 ange-wendet und fungiert dort als best practice fr den Umgang mit dem Prototypen.In Kapitel 3 enthalten die Funoten zustzlich die wrtlichen, zumeist engli-

schen Zitate aus den angegebenen Quellen. Diese wurden ausgelagert, damit derLesefluss nicht zu stark unterbrochen wird. Die inhaltlichen bersetzungen sindim Text selbst enthalten und als Zitate in Hochkommas markiert. Auslassungenin wrtlichen Zitaten werden durch [..] gekennzeichnet.Wird eine grobe Idee aus einer Quelle entnommen, ohne dass dies ein wrtliches

Zitat rechtfertigt, dann wird die Quelle am Anfang oder Ende des Satzes ohneHochkommas im Text integriert. Der Umgang mit Eigenzitaten aus erfolgreichverffentlichten Arbeiten wird zu Beginn der entsprechenden Kapitel thematisiert,in welche Textbausteine bernommen worden sind.Nach der Einleitung und Motivation, sowie der Problemstellung mit der Zielset-

zung und den Schwerpunkten der Arbeit, werden im nchsten Kapitel grundlegen-de XML-Technologien zum verbesserten Verstndnis berblicksartig prsentiert.

16

2. Grundlagen

In diesem Kapitel werden die fr die vorliegende Arbeit notwendigen Grundlagenberblicksartig erlutert. Dies bezieht sich auf das XML-Schema als Ausgangs-punkt der thematisierten XML-Schemaevolution in Abschnitt 2.1, auf XPathals Adressierungssprache zur Ermittlung von XML-Fragmenten inAbschnitt 2.2,sowie einen kurzen Vergleich der Evolution von XML-Schema gegenber der Ver-sionierung von diesen in Abschnitt 2.3.

2.1. XML-Schema

XML Schema ist eine Schemasprache, mit der XML-Dokumente beschrnkt undTypinformationen zu Teilen bereitgestellt werden knnen.1 [Rys09] Die XMLSchema Definition (XSD) [FW04] ist eine Mglichkeit des World Wide Web Con-sortium (W3C) [W3C15a] zur Spezifikation von Anforderungen bezglich gltigerXML-Dokumente. Der innerhalb von zwei Jahren [vdV02] entwickelte Standardbesteht aus zwei normativen Bestandteilen, der Struktur- ([TBMM04]) und derDatentypbeschreibung ([BM04]), sowie einem nicht normativen Teil als Einfh-rung ([FW04]). Ziel war es eine formale Beschreibung der mglichen Strukturin-formationen eines XML-Dokuments zu erhalten, welche nicht nur durch Menschenlesbar, sondern auch durch Maschinen ausfhrbar ist [W3C15c].In [TBMM04] werden die unterschiedlichen Komponenten eines XML-Dokum-

ents spezifiziert. Es kann diesbezglich zwischen dem Abstract Data Model(ADM) und dem Element Information Item (EII) unterschieden werden.Das ADM ist konzeptuell und definiert eine generelle, von Implementierung oderReprsentation unabhngige Beschreibung von Schemakomponenten. Das EII hin-gegen ist die Realisierung von diesen Schemakomponenten im XML-Schema, wobeiEigenschaften, XML Reprsentation, Einschrnkungen und weitergehende Validie-rungsregeln und -hinweise spezifiziert werden.

2.1.1. Strukturbeschreibung des XML-Schemas

Das Abstract Data Model (ADM) unterscheidet zwischen primren und sekun-dren Komponenten, sowie kontextabhngigen Hilfskomponenten. Primr sind ein-fache und komplexe Typdefinitionen, sowie Attribut- und Elementdeklarationen.1XML Schema is a schema language that allows to constrain XML documents and provides typeinformation about parts of the XML document. [Rys09]

17

2. Grundlagen

Sekundr sind die Definitionen von Attributgruppen, Identity-Constraints und Mo-dellgruppen, sowie die Deklarationen von Notationen.Zu den Hilfskomponenten gehren die Annotationen, Modellgruppen2, Parti-

kel, Wildcards und Attributverwendungen (Attribute Uses). Der Zusammenhangzwischen Modellgruppen, Partikeln, Modellgruppendefinitionen und Attributver-wendungen wird nachfolgend kurz erklrt, da dieser nicht sofort ersichtlich ist.Modellgruppen sind Listen von Partikeln mit drei unterschiedlichen Varianten:der Reihenfolgen mit exakter Abfolge, der Konjunktion mit beliebiger, aber eben-so vollstndiger Abfolge und Disjunktion mit einer Auswahl. Partikel entsprechendabei einem Elementinhalt, der eine Elementdeklaration, Wildcard oder Modell-gruppe mit jeweils definierter Hufigkeit ist. Partikel innerhalb einer komplexenTypdefinition charakterisieren als Bestandteil dessen Inhaltsmodell.Modellgruppendefinitionen sind benannte Zusammenfassungen von Elementen

oder Attributen. Attributverwendungen spielen eine hnliche Rolle wie die Par-tikel fr den Elementinhalt, sie definieren innerhalb eines komplexen Typs unteranderem, welche Attributdeklarationen zwingend oder optional sind, bzw. nichtverwendet werden drfen.

Attributdeklarationen

Das Element Information Item (EII) ist wie bereits angesprochen die Reprsenta-tion der Schemakomponenten des ADM im XML-Schema, sodass fr jede Kom-ponente jeweils eine detaillierte Beschreibung vorliegt. Die Reprsentation vonAttributdeklarationen3 ist in EII-Beispiel 2.1 dargestellt.

Content: (annotation?, simpleType ?)

EII-Beispiel 2.1: XML-Reprsentation eines Attributs nach [TBMM04]

Eine Attributdeklaration besitzt unterschiedliche, teilweise voneinander abhngen-de Eigenschaften (bzw. Attribute [vdV02]), welche eine Deklaration innerhalb einesXML-Schemas charakterisieren. Diese sind lexikografisch sortiert und enthalten imdargestellten Beispiel unter anderem default-, fixed-, name-, ref-, type- und use-Attribute. Den Eigenschaften knnen Datentypen gem [BM04] zugeordnet sein2Hier sind nicht die Modellgruppendefinitionen der sekundren Komponenten gemeint.3siehe auch: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#declare-attribute

18

2.1. XML-Schema

(z.B. string, ID, NCName, QName), alternative, festgelegte Wertbelegungen (z.B.use = optional, use = prohibited oder use = required), sowie Defaultwerte, insoferneine Eigenschaft nicht im XML-Schema spezifiziert wurde (use = [..] : optional).Des Weiteren wird spezifiziert, welche weitergehenden Komponenten innerhalb ei-ner Attributdeklaration erlaubt sind. Dieser Inhalt (content) kann eine Annotationund einfache Typdefinition enthalten (beide jeweils optional).

Gltigkeitsbereiche in XML-Schema

In Abhngigkeit des Gltigkeitsbereichs, wird zwischen globalen und lokalen Attri-butdeklarationen unterschieden. Das XML-Beispiel 2.2 illustriert die Gltigkeits-bereiche von Schemakomponenten.

XML-Beispiel 2.2: XML-Schema mit globalen und lokalen Attributen

Ein globaler Gltigkeitsbereich bedeutet, dass eine Schemakomponente als direkten Vorgnger hat. Dies sind im XML-Beispiel die erste Attribut-deklaration a1, der komplexe Typ ct1, sowie die Attributgruppe ag1. Globale De-klarationen knnen innerhalb des gesamten XML-Schemas referenziert werden,genauso wie es die Attributreferenz a1 in ct1 macht. Dabei gilt allerdings, dasslokale Deklarationen die globalen berdecken.Ein lokaler Gltigkeitsbereich bedeutet im Gegensatz zum globalen, dass

eine Komponente nicht als direkten Vorgnger hat, sondern wie imXML-Beispiel 2.2 ersichtlich zum Beispiel den komplexen Typen oder die Attribut-gruppe. Die lokale Attributdeklaration a1 der Attributgruppe berdeckt die globa-le Deklaration a1. Lokale Deklarationen knnen nicht im gesamten XML-Schemareferenziert werden, sondern nur von Kinderkomponenten des eigenen Gltigkeits-bereichs.Es existieren weiterhin unterschiedliche Einschrnkungen bezglich der definier-

ten Eigenschaften von Attributdeklarationen. Im Bezug auf die obige Aufzhlung(default, fixed, name, ref, type und use) ergeben sich unter anderem folgende Bedin-gungen: Globale Attributdeklarationen knnen kein use angeben, whrend lokaledies hingegen ermglichen bzw. den Defaultwert optional verwenden. Die Attribu-te ref und name, ref und type, sowie default und fixed knnen nicht zeitgleich ineiner Attributkomponente auftreten. Ist ein ref angegeben, dann ist der type im-plizit von der referenzierten Deklaration bernommen. Dies gilt auch fr default-

19

2. Grundlagen

oder fixed-Angaben. Die lokale berdeckung gilt in diesem Fall allerdings nicht,das heit wenn eine globale Attributdeklaration einen fixed-Wert definiert, dannist dies lokal nicht mehr durch eine Referenz nderbar.

Elementdeklarationen

Elementdeklarationen sind eine weitere primre Schemakomponente, deren Ele-ment Information Item in EII-Beispiel 2.3 dargestellt wird.

Content: (annotation?, (( simpleType | complexType )?,

(unique | key | keyref )*))

EII-Beispiel 2.3: XML-Reprsentation eines Elements nach [TBMM04]

Elementdeklarationen4 besitzen hnlich zu den Attributdeklarationen Eigenschaf-ten wie default, fixed, name, ref und type. Die Abhngigkeiten zwischen diesen At-tributen gelten ebenso fr Elemente, das heit, dass zum Beispiel fixed und defaultnicht zeitgleich definiert sein knnen. Der Gltigkeitsbereich von Elementdeklara-tionen ist lokal oder global, wobei auch an dieser Stelle die gleichen Mechanismenbezglich der Sichtbarkeit und Referenzierbarkeit gelten.Die Attribute minOccurs und maxOccurs ermglichen eine detaillierte Aus-

drucksmglichkeit der Hufigkeit eines Elements innerhalb eines XML-Dokuments.Es kann Optionalitt (minOccurs = 0 ) und unbeschrnkte Hufigkeit (maxOccurs= unbounded) spezifiziert werden. Dabei gilt, dass minOccurs maxOccurs seinmuss, entsprechende Defaultwerte sind gegeben (jeweils 1 ). Beide Attribute knnennur bei lokalen Elementdeklarationen oder Elementreferenzen verwendet werden.Die Nullwertfhigkeit (nillable = true) bedeutet, dass ein Elementinhalt dem

Datentyp zuwider leer sein kann. Es wird angezeigt, dass fr ein Element imXML-Dokument kein Wert vorliegt5 [Cos02]. Das XML-Beispiel 2.4 zeigt dies.4siehe auch: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#declare-element5nil: an instance document element may indicate no value is available [Cos02]

20

2.1. XML-Schema

0

XML-Beispiel 2.4: XML-Schema eines nullwertfhigen Elements mit XML-Dokument

Die Elementreferenz e1 ist nullwertfhig, da deren Deklaration das Attribut nil-lable=true besitzt. Dadurch kann im XML-Dokument das erste Element von e1trotz des Datentyps xs:decimal einen leeren Elementinhalt besitzen. Dass dies an-sonsten nicht mglich ist, wird durch das zweite Element e1 ausgedrckt. Diesesist zwar ebenso nullwertfhig, gibt dies aber nicht explizit an. Es muss das Attributxsi:nil=true angegeben werden, damit die in der Deklaration des XML-Schemasspezifizierte Nullwertfhigkeit greift. Somit wird ein Elementinhalt fr e1 gemDatentyp bentigt.Die Eigenschaften abstract, block, final und substitutionGroup ermglichen die

Definition von Stellvertretern von Elementen, sowie die Einschrnkung von diesen.Zum Beispiel knnten eine Elementdeklaration e1 und zwei weitere Elemente e2und e3 spezifiziert werden, wobei die beiden letzten das Attribut substitutionGroup= e1 und den gleichen Typen wie e1 enthalten. Insofern nun eine Elementre-ferenz bezglich e1 existieren wrde, knnte an dieser Stelle ebenso e2 oder e3verwendet werden. Dabei sind unterschiedliche Randbedingungen bezglich derSubstitutionen zu beachten, die aufgrund der besonders unscharfen Spezifikationvon Erweiterungen und Einschrnkungen6 [vdV02] von Substitutionsgruppen vonAnwendungsempfehlungen abgelehnt werden (DO NOT use substitution groups[KAW01]). In [Oba03a] wird ebenso auf die Schwierigkeiten dieses Konzepts hinge-wiesen7, besonders im Zusammenhang mit ungewollten, durch Einbindung weitererXML-Schema verbundener Substitutionsmglichkeiten.

6Substitution groups can be seen as extensible element groups [..] the Recommendation is especiallyfuzzy on the extensibility of element groups and the restriction of substitution groups [..] [vdV02]

7Substitution groups [..] allow extensibility in directions the schema author may not have anticipated[..] it makes it harder to process documents based on such schemas. [Oba03a]

21

2. Grundlagen

Einfache Datentypen

Die bereits angesprochenen Datentypen des zweiten, normativen Teils der Spezi-fikation sind in [BM04] dargestellt. Diese beschreiben den Inhalt von Elementen(speziell von Textknoten im XML-Dokument) oder Attributen, und sind komplettunabhngig von anderen Knoten und somit vom Markup8 [vdV02]. Bei einfa-chen Typdefinitionen werden grundstzlich drei Varianten unterschieden: atomareTypen (atomic), Listen- (list) und Vereinigungstypen (union).Atomare Typen knnen entweder primitive oder abgeleitete Datentypen sein.

Dazu gehren unter anderem die built-in-Typen, die in Abbildung 2.1 darge-stellt sind. Primitive Datentypen sind unter anderem string und decimal, whrend

Abbildung 2.1.: XML-Schema built-in-Datentypen aus [BM04]

abgeleitete built-in-Typen integer, long etc. sind. Die Ableitung kann mittels Ein-schrnkung und/oder Erweiterung oder Listenbildung geschehen, wobei Typhie-rarchien aufgebaut werden.Ein Listentyp ist ein abgeleiteter Typ, wobei dieser als endlich langer, jeweils

durch Leerrume separierter, atomarer Typ angesehen wird. Dieser atomare Typeines Listentyps wird als itemType bezeichnet.8[..] describe the content of a text node or an attribute value. They are completely independent of theother nodes and, therefor, independent of the markup. [vdV02]

22

2.1. XML-Schema

Die Vereinigungstypen sind ebenso abgeleitet, wobei der Wertebereich ausden unterschiedlichen, als Teilnehmer (memberTypes) spezifizierten Typen besteht.Aktuell existieren keine built-in-Vereinigungstypen.Zustzlich zu den bereits erwhnten, abgeleiteten Typen knnen einschrnken-

de Typen (Restriktionstypen) definiert werden. Eine Restriktion besitzt einenBasistypen (baseType), der wiederum ein Listentyp, Vereinigungstyp, built-in-Typoder sogar ein weiterer Restriktionstyp sein kann.Die Einschrnkung wird mittels Facetten gettigt, das heit der Wertebereich

des Basistyps wird zum Beispiel durch die explizite Angabe einer minimalen Ln-ge (minLength) eingeschrnkt. Die jeweils gltigen Facetten sind vom Datentypendes Basistypen abhngig, zum Beispiel kann die Lnge (length), aber nicht derminimale, inklusive Wert (minInclusive) eines string Typs definiert werden. Da-hingegen ist dies umgekehrt fr den decimal Typ mglich (gltig: minInclusive,ungltig: length). Eine Zusammenfassung aller built-in-Datentypen mit deren gl-tigen Facetten ist im Anhang A Abbildung A.1 aufgelistet.Das Element Information Item das Datentyps9 wird in EII-Beispiel 2.5 gezeigt.

Content: (annotation?, (restriction | list | union))

EII-Beispiel 2.5: XML-Reprsentation eines einfachen Typs nach [BM04]

Der Inhalt (content) von einfachen, nutzerdefinierten Typen kann demzufolge eineRestriktion (restriction), ein Listentyp (list) oder ein Vereinigungstyp (union) sein.Die vordefinierten built-in-Typen sind nicht explizit aufgefhrt, da diese im XML-Schema selber spezifiziert und somit direkt verwendbar sind.Einfache Typdefinitionen knnen wie Deklarationen einen lokalen und globa-

len Gltigkeitsbereich besitzen. Built-in Datentypen sind global und im gesamtenXML-Schema sichtbar, wobei eine Definition per qualifiziertem Namen (QName)referenziert wird. Ein solcher QName ist dabei ebenso ein primitiver built-in-Datentyp, der eine Zeichenkette darstellt. Diese besteht aus einem Prfix (b-licherweise xs), einer Schemaadresse (http://www.w3.org/2001/XMLSchema), ei-nem Doppelpunkt und dem NCNamen des Datentyps (z.B. string). Der qualifizier-te Name von string lautet demnach xs:string. Lokale Definitionen knnen inner-halb von Attribut- und Elementdeklarationen, sowie komplexen Typdefinitionenmit einfachem, einschrnkendem Inhaltsmodell spezifiziert werden. Diese sind nurinnerhalb deren Gltigkeitsbereiches sichtbar und somit referenzierbar.

9siehe auch: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#xr-defn

23

2. Grundlagen

Komplexe Datentypen

Die noch verbleibende, primre Schemakomponente der komplexen Typen wirdnachfolgend erlutert. Im Gegensatz zu einfachen Datentypen, welche sowohl inAttribut- als auch bei Elementdeklarationen genutzt werden drfen, knnen nurElementdeklarationen einen komplexen Typ annehmen. Das Element InformationItem ist in EII-Beispiel 2.6 dargestellt.

Content: (annotation?, (simpleContent | complexContent |

((group | all | choice | sequence)?,(( attribute | attributeGroup )*, anyAttribute ?))))

EII-Beispiel 2.6: XML-Reprsentation eines komplexen Typs nach [TBMM04]

Komplexe Typen10 beschreiben das Markup, das heit abhngig von deren con-tent und der Eigenschaft mixed wird ein XML-Dokument strukturell spezifiziert.Das Attribut mixed = true bedeutet, dass zustzlich zum Markup auch Textkno-ten zwischen dem Markup mglich sind, sodass schwer zu analysierende XML-Dokumente entstehen knnen11 [Liq14]. Das XML-Beispiel 2.7 illustriert dies.

Text dank mixed erlaubt0 Text dank mixed erlaubt0 Text dank mixed erlaubt0 Text dank mixed erlaubt

XML-Beispiel 2.7: XML-Schema eines komplexen Typs mit XML-Dokument

10siehe auch: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#declare-type11Mixed content is something you should try to avoid when creating your XML schema. [..] However,

it is difficult to parse and it can lead to unforeseen complexity in the XML documents data. [Liq14]

24

2.1. XML-Schema

Es wird in dem Beispiel der mixedContent erlaubt, das heit zwischen dem Markupder Elemente (0) stehen Textknoten, die passender Weise den InhaltText dank mixed erlaubt haben.Es wird unterschieden zwischen einfachem (simpleContent) und komplexem In-

halt (complexContent). Ist weder simpleContent noch complexContent angegeben,so ist dies eine abkrzende Schreibweise eines komplexen Typs mit komplexen In-halt als Einschrnkung des anyType (siehe Abbildung 2.1). In diesem Fall wird eineModellgruppe12 des Abstract Data Model verwendet. Somit ist das Inhaltsmodellentweder eine Reihenfolge (sequence), eine Menge (all, als Konjunktion) oder eineAuswahl (choice, als Disjunktion). Dabei spielen die Partikel erneut eine wichtigeRolle, da diese die Anzahl der Durchlufe des Inhaltsmodells durch Angabe vonminOccurs und maxOccurs festlegen. Eine Gruppe (group) als vierte Alternativeist an dieser Stelle eine Referenz auf eine globale Elementgruppe, die wiederumeine Zusammenfassung von Elementdeklarationen in einer Modellgruppe darstellt.Im XML-Beispiel 2.7 ist das Inhaltsmodell des komplexen Typs (roottype) eineSequenz, die genau dreimal durchlaufen wird. Da die Elementreferenz innerhalbder Modellgruppe genau einmal auftreten kann, ergibt sich als Konsequenz, dasse1 genau dreimal im XML-Dokument auftritt.Neben dem Inhaltsmodell knnen in einem komplexen Typen wie bereits an-

gesprochen Attributdeklarationen, sowie Referenzen auf globale Attributgruppenund eine Attributwildcard definiert werden.Der simpleContent und complexContent ermglicht die Einschrnkung bzw. Er-

weiterung nutzerdefinierter komplexer Typen. Die Ableitung von komplexen Typenist dabei hnlich kompliziert wie die der Substitutionsgruppen von Elementdekla-rationen und fhrt zu mehr Problemen, als damit gelst werden13 [Oba03c]. Diesgilt besonders fr Einschrnkungen, welche nur mit Vorsicht zu benutzen sind14[Oba03a].Der simpleContent erweitert einfache Typen um Attribute, bzw. schrnkt be-

reits vorhandene (einfache Typen mit Attributen) mittels Facetten und Einschrn-kungen von definierten Attributen ein. Das Ergebnis ist ein komplexer Typ miteinfachem Inhalt, allerdings erweitert um Attribute (insofern dies vollzogen wur-de). Einschrnkungen sind fr lokale und globale Typen, Erweiterungen nur frglobale Typen mglich.Beim complexContent sind Einschrnkungen bzw. Erweiterungen vom Inhalts-

modell und den Attributen mglich. Erweiterungen enthalten implizit das Inhalts-modell und die Attribute des Basistypen, neue Komponenten werden jeweils amEnde der entsprechenden Modellgruppe mittels Sequenz angehngt. Einschrnkun-gen sind beim komplexen Inhalt nur bei globalen Typen mglich. Dabei wird dasInhaltsmodell von diesem komplett wiederholt (explizit) und anschlieend dessen12siehe auch: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#declare-contentModel13[..] complex type derivation features [..] may add more problems than they solves [..] [Oba03c]14DO use restriction of complex types carefully. [Oba03a]

25

2. Grundlagen

Partikel eingeschrnkt. Attribute werden allerdings anders behandelt, diese sindimplizit enthalten und mssen bei einer Wiederholung eingeschrnkt werden.

Weitere Schemakomponenten

Es wurden die primren Schemakomponenten des Abstract Data Model erlutert.Dies ist ein kleiner Ausschnitt der Mglichkeiten eines XML-Schemas, der aller-dings einen groen Einfluss auf die Struktur der XML-Dokumente besitzt. ElementInformation Items existieren jedoch fr alle erwhnten Schemakomponenten desADM, dies ist neben den Einschrnkungen und kontextabhngigen Eigenschaftender unterschiedlichen Attribute unter anderem ein Grund fr die hohe Komplexittvon XML-Schema.Nicht ohne Grund wird in Anwendungsempfehlungen ([KAW01], [Oba03a]) dar-

auf hingewiesen DO NOT try to be a master of XML Schema. [..] [KAW01].Es werden in der vorliegenden Arbeit weitere EIIs anderer Schemakomponentenbentigt, an entsprechender Stelle wird auf die Spezifikation [TBMM04] verwiesen.

2.1.2. XML-Schema Version 1.1

Die XML-Schema 1.1 Spezifikation wurde am 5. April 2012 als Recommendationdes W3C verffentlicht [Cos09]. Damit wurden unterschiedliche, neue Konzepteaufgenommen bzw. alte berarbeitet, da XML-Schema 1.0 einige Lcken aufwies[Bor11] bzw. Einschrnkungen existierten15 [DGGN09], die zu nicht intuitivenSchemadesigns16 [DGGN08] fhrten.Der neue Standard besteht aus zwei Teilen, der Struktur- ([GSMT12]) und

Datentypbeschreibung ([PGM+12]), wobei XML-Schema 1.1 als Obermenge vonXML-Schema 1.0 zu verstehen ist [Cos09]. Abbildung 2.2 illustriert diesen Aspekt.Somit wurde sichergestellt, dass ein XSD 1.0 konformes XML-Dokument mit ei-

XML Schema 1.0

XML Schema 1.1 XML Schema 1.1is a superset of XML Schema 1.0

Abbildung 2.2.: Zusammenhang XSD 1.0 und XSD 1.1 aus [Cos09]

15[..] XML Schema 1.0 has certain limitations. [DGGN09]16Schema authors often face certain challenges [..] resulting in counter-intuitive schema designs [..]

[DGGN08]

26

2.1. XML-Schema

nem XSD 1.1 Validator geprft werden kann, aber nicht anders herum17 [Cos09].Fr die Gegenrichtung (XSD 1.0 Validator, XSD 1.1 konformes XML-Dokument)werden Hinweise fr die Anpassung des alten Validators in [Orc07] gegeben.18Die sekundren Komponenten des Abstract Data Model wurde um Zusicherun-

gen (Assertions) und Typalternativen erweitert. Des Weiteren wurden ElementInformation Items fr diese Komponenten mit in die Spezifikation [GSMT12] auf-genommen, sowie bereits vorhandene angepasst. Im Bezug auf die oben vorgestell-ten primren Schemakomponenten ergeben sich die in EII-Beispiel 2.8 dargestelltennderungen.

+ targetNamespace = anyURI

+/- substitutionGroup = List of QName+ targetNamespace = anyURI

Content: (annotation?, (( simpleType | complexType )?,+ alternative*,

(unique | key | keyref )*))

+ defaultAttributesApply = boolean : true

Content: (annotation?, (simpleContent | complexContent |+ (openContent?,

(group | all | choice | sequence)?,(( attribute | attributeGroup )*, anyAttribute ?),

+ assert *)))

EII-Beispiel 2.8: Erweiterungen der primren Schemakomponenten nach [GSMT12]

In Beispiel 2.8 werden die Deltas im Bezug zu obigen Reprsentationen erfasst.Erweiterungen des EII werden mittels vorangestelltem +, nderungen bereits vor-handener Eigenschaften mit +/- illustriert. Somit werden Attribut- und Element-deklarationen jeweils um die direkte Mglichkeit zur Angabe des Zielnamensraums(targetNamespace) erweitert. Substitutionsgruppen von Elementen sind als Listequalifizierter Namen spezifizierbar. Die Typalternative19 des ADM wurde in denInhalt (content) mit aufgenommen, das heit eine bedingte Typisierung in Abhn-gigkeit von Attributwerten ist mglich [Bor11].Komplexe Typen werden um Assertions und flexiblere Inhalte erweitert (eine

gewisse Flexibilitt ist bereits in XSD 1.0 mglich, siehe [Oba03b]). Durch die17An instance document conforming to a 1.0 schema can be validated using a 1.1 validator, but an

instance document conforming to a 1.1 schema may not validate using a 1.0 validator. [Cos09]18The majority of this guide focuses on [XML Schema 1.1 Part 1] ([GSMT12], Anm. d. Autors) exten-

sibility techniques that enable forwards-compatible versioning. [Orc07]19siehe auch: http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/#element-alternative

27

2. Grundlagen

Angabe von defaultAttributesApply kann die im Schema20 definierte Defaultattri-butgruppe (defaultAttributes = QName) referenziert werden, das heit es werdenin einen komplexen Typen automatisch alle in der Attributgruppe spezifiziertenAttributdeklarationen bernommen. Dieses muss explizit abgewhlt werden, dader Defaultwert true ist. Des Weiteren ist es mglich durch die Angabe von open-Content Typen mit komplexem Inhalt (complexContent) zu erweitern. Es wirddiesbezglich definiert, an welcher Position im Inhaltsmodell welche zustzlichenElementdeklarationen (z.B. auch Wildcards) erlaubt sind. hnlich wie bei denDefaultattributgruppen existiert nun auch die Mglichkeit das gesamte Schemaals offen fr beliebige andere Elemente [Bor11] zu kennzeichnen, indem im Inhaltdes Schemas die defaultOpenContent Komponente entsprechend definiert wird.

Das Element Information Item eines einfachen Typs wurde nicht erweitert undwurde daher im EII-Beispiel 2.8 nicht mit aufgenommen. Dennoch sind neue built-

Abbildung 2.3.: XML-Schema built-in-Datentypen aus [PGM+12]

in-Typen mit in die Spezifikation aufgenommen worden, um die Typsysteme mitanderen Spezifikationen des W3C abzustimmen. Dies sind anyAtomicType, day-TimeDuration und yearMonthDuration21 [DGGN08]. Die im Vergleich zu Abbil-20siehe auch: http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/#declare-schema21To align the type systems of XML Schema and these specifications (Alignment with XQuery 1.0

and XPath 2.0 data model types, Anm. d. Autors), the XML Schema 1.1 data types specificationintroduced [..] namely: anyAtomicType, dayTimeDuration, and yearMonthDuration. [DGGN08]

28

2.1. XML-Schema

dung 2.1 angepasste Typhierarchie der built-in-Typen von XML-Schema 1.1 wirdin Abbildung 2.3 dargestellt. Die oben erwhnte Zusammenfassung der built-in-Datentypen mit deren gltigen Facetten im Anhang A Abbildung A.1 bezieht sichauf selbige.Die aufgezhlten nderungen betreffen nur die primren Schemakomponenten

des Abstract Data Model. Es existieren allerdings weitere Anpassungen, die beiBedarf an entsprechender Stelle in der vorliegenden Arbeit erwhnt werden.

2.1.3. Modellierungsstile von XML-Schema

Aus den Mglichkeiten Deklarationen und Definitionen global oder lokal zu definie-ren, ergeben sich unterschiedliche Modellierungsstile, die einen groen Einflussauf die Struktur und die Eigenschaften eines XML-Schemas haben.In [xml01]22 wurden drei Stile eingefhrt: Russian Doll, Salami Slice und Veneti-

an Blind. Der vierte Stil Garden of Eden wurde mit Verweis auf [xml01] in [Mal02]ergnzt. Abbildung 2.4 illustriert die Modellierungsstile von XML-Schema.

Gltigkeits-

bereich

Russian

Doll

Salami

Slice

Venetian

Blind

Garden of

Eden

lokal x x

global x x

lokal x x

global x x

Element- und

Attributdeklaration

Typdefinition

Abbildung 2.4.: Modellierungsstile von XML-Schema nach [Mal02]

Der Garden-of-Eden-Stil zeichnet sich durch die Eigenschaft aus, dass sowohl dieAttribut- und Elementdeklarationen als auch die einfachen und komplexen Typ-definitionen global spezifiziert werden (x). Dadurch ist die Wiederverwendbarkeitaller Komponenten schemaintern und -bergreifend mglich23 [JW10], allerdingssind solche Schemata schwieriger von Menschen lesbar und im Vergleich zu ande-ren weniger kompakt. Des Weiteren mssen globale Deklarationen einen eindeuti-gen Namen besitzen, ein praktischer Nebeneffekt24 [Mar03]. Diese Einschrnkungbzw. Regel gilt zeitgleich fr Typdefinitionen im selben Gltigkeitsbereich.Ist die Wiederverwendbarkeit nicht zwingend erforderlich, die Kompaktheit al-

lerdings schon25 [JW10], wird zum Beispiel der Russian-Doll-Stil empfohlen. Indiesem Stil sind alle Deklarationen und Definitionen lokal spezifiziert, sodass ent-koppelte, zusammenhngende Schemata26 [JW10] entstehen.22siehe speziell: http://www.xfront.com/GlobalVersusLocal.html23By making every possible element, attribute, and type global, you create a scenario that maximizes

reuse, both internally and between schemas [..] [JW10]24[..] global declarations must be unique: No two global declarations can use the same [..] name. [Mar03]25If schema reuse is not imperative and minimizing size is, use the Russian doll style [..] [JW10]26Russian doll style schemas [..] are also considered highly decoupled [..] and cohesive [..] [JW10]

29

2. Grundlagen

2.2. XPath

XPath ist eine auf Pfadausdrcken basierende Sprache, die die Auswahl vonTeilen eines gegebenen XML-Dokuments ermglicht27 [HP09]. Seit 1999 exis-tiert die Recommendation des W3C bezglich der XML Path Language (XPath)[CD99]. XPath 1.0 ist eine Grundlage von XSD 1.0.28 XPath 2.0 ([BBC+10]) wurde2010 als Recommendation verabschiedet, eine Grundlage von XML-Schema 1.1.29XPath modelliert XML-Dokumente als Baumstruktur mit Knotentypen. Die

Typen sind gem des Datenmodells Elemente, Attribute, Texte, sowie Wurzel-,Namensraum-, Verarbeitungs- und Kommentarknoten. Das grundlegende syntak-tische Konstrukt von XPath ist ein Ausdruck30 [CD99]. Ausdrcke werden vonlinks nach rechts induktiv ausgewertet [Lau05] und mit / miteinander verknpft,wobei das Ergebnis eines Ausdrucks ein atomarer Wert oder eine gegebenenfallsleere Knotenmenge ist.Die verwendete Recommendation spielt eine entscheidende Rolle, denn XPath

1.0 verwendet duplikatfreie Knotenmengen, whrend XPath 2.0 diese zu Knoten-sequenzen mit Duplikaten generalisiert31 [BFM+10]. Sofern nicht explizit an-ders definiert sind die Elemente einer Sequenz in Dokumentordnung. [Lau05]Des Weiteren nutzt XPath 2.0 das Typsystem von XML Schema, beinhaltet einewesentlich umfangreichere Funktionsbibliothek, untersttzt Referenzen und kenntDokumentkollektionen, sowie weitergehende Ausdrucksarten und Vergleiche, dienicht nur auf Werten basieren [KM03].

Lokationspfad

Pfadausdrcke (engl. Location Path) lassen sich absolut oder relativ angeben. Einabsoluter Pfad wird von der Wurzel ausgehend ausgewertet. Er beginnt stets miteinem Schrgstrich / . [KM03] Relative Pfade werden hingegen vom aktuellenKontextknoten aus analysiert, wobei dieser durch die einzelnen Werte reprsen-tiert wird, die durch den vorangehenden XPath-Ausdruck gebildet werden [KM03].Ein Lokationsschritt (engl. Location Step, Anm. d. Autors) besteht aus einer

Achse, einem Knotentest und, optional, aus einem oder mehreren Prdikaten.[Lau05] Ein Schritt hat den folgenden syntaktischen Aufbau:

Achse :: Knotentest [Prdikat]

27XPath is a language based on path expressions that allows the selection of parts of a given XMLdocument. [HP09]

28XML Schema: Structures depends on the following specifications: [..] XPath [..] [TBMM04]29XML Schema [..]: Structures depends on the following specifications: [..] XPath 2.0 [..] [GSMT12]30The primary syntactic construct in XPath is the expression. [CD99]31Sequences replace node-sets from XPath 1.0. In XPath 1.0, node-sets do not contain duplicates. In

generalizing node-sets to sequences in XPath 2.0, duplicate removal is provided by functions on nodesequences. [BFM+10]

30

2.3. Evolution und Versionierung

Die Achse stellt die Beziehung zwischen den Kontextknoten und den zu selektie-renden Knoten her [KM03]. Eine Achse kann zum Beispiel den Vorgnger (pa-rent), Nachfolger (descendant), den Knoten selbst (self ) oder Kinderknoten (child)adressieren. Es existieren aktuell insgesamt 13 mgliche Varianten von Achsen.Jede Achse hat einen speziellen Typen, der durch den Knotentest analysiert

werden kann. Somit kann die ausgewhlte Knotenmenge eingeschrnkt bzw. dasVorhandensein eines bestimmten Typs verlangt werden. Zum Beispiel knnen unteranderem Textknoten (text()), Elementknoten (node()) oder beliebige Typen (*)ausgewhlt werden. Die Angabe eines qualifizierten Namens ist ebenso mglich.Mit Hilfe von Prdikaten knnen weitere Bedingungen an Knotenmengen formu-

liert werden. Die Prdikate mssen neben dem Knotentest erfllt sein, damit einentsprechender Knoten in die Knotenmenge bernommen wird. Prdikate knnenebenso Kontextpositionen sein, die mit 1 beginnend die relative Position einesKnotens innerhalb einer Knotenmenge angeben. Die Mchtigkeit der vorliegendenMenge (Kontextgre), sowie die Dokumentordnung sind dabei entscheidend.Da die vollstndige Achsenangabe sehr gesprchig ist, gibt es eine verkrzende

Schreibweise der Pfadangabe [..] [KM03], sodass zum Beispiel statt self::node()., parent::node() .. oder attribute:: @ verwendet werden kann.32 Es existierenweitere quivalenzen, die unter anderem in [OMFB02] thematisiert werden.

2.3. Evolution und Versionierung

Die Schemaversionierung ist ein alternativer Ansatz zur Schemaevolution. DieVersionierung beschftigt sich mit der Anforderung aktuelle Daten zu bewahren,und der Fhigkeit diese abzufragen und zu aktualisieren.33 [Rod09b]Fr die Versionierung ist charakteristisch, dass zu einem Zeitpunkt mehrere, ver-

schiedene Ausprgungen einer Strukturbeschreibung existieren knnen. Zeitgleichsind vorhandene Instanzen (d.h. Dokumente) immer gltig bezglich einer odermehrerer Versionen. ndert sich ein Schema aufgrund von korrigierender, adapti-ver oder perfektionierender Wartung, wird eine neue Version erzeugt. ZuknftigeDokumente knnen dieses neue oder alternativ ein lteres Schema referenzieren.Ein Vorteil aus Sicht der Daten ist, dass gltige Instanzen keine Anpassungen

bentigen, ein Verlust von jenen ist ausgeschlossen. Allerdings knnen schnell ei-ne Vielzahl von redundanten Schemata entstehen, deren Verwaltung komplex undaufwendig sein kann. Redundante Schemata sind unter anderem durch die Weiter-entwicklung ausgehend von unterschiedlichen Versionen, sowie durch instanzerhal-tende Schemanderungen mglich. Ein weiterer, nicht zu unterschtzender Nach-teil ist, dass korrigierende Anpassungen nicht zwingender Weise in allen Versionen32siehe auch: http://www.w3.org/TR/1999/REC-xpath-19991116/#path-abbrev33Schema versioning deals with the need to retain current data, and the ability to query and update

it, through alternate database structures. [Rod09b]

31

2. Grundlagen

umgesetzt werden. Es knnen demnach fehlerhafte Schemaversionen vorliegen, dieweiterhin referenziert werden knnen.Die Evolution im Kontext der vorliegenden Arbeit34 hat im Vergleich zur Versio-

nierung das Ziel, nur eine gltige Version eines Schemas zu besitzen35 [Rod09a].Schemanderungen knnen somit die Gltigkeit vorhandener Instanzen beeintrch-tigen, eine Anpassung dieser kann bei instanzverndernden, instanzerweiterndenoder instanzreduzierenden Operationen notwendig werden. Die Instanzanpassungkann zum Verlust von Daten fhren, allerdings knnen somit alle Instanzen gl-tig bezglich des neusten, korrigierten, adaptierten und perfektionierten Schemassein. Des Weiteren ist eine Versionsverwaltung im Allgemeinen nicht notwendig.

Abschlieende Betrachtung

In diesem Kapitel wurden XML-Schema und XPath vorgestellt. Dabei sind dieprimren Schemakomponenten und unterschiedlichen Modellierungsstile erlutertworden. Die Deklarationen und Definitionen sind in diesem Zusammenhang vonBedeutung. Anschlieend wurde der allgemeine Aufbau von XPath vorgestellt.Mit dessen Lokalisierungspfaden werden Komponenten sowohl in XML-Schemaals auch wohlgeformten XML-Dokumenten im Allgemeinen adressiert.Zum Abschluss wurde eine Abgrenzung zur Versionierung als alternativer An-

satz der Evolution gettigt. Nachdem grundlegende Technologien berblicksartigprsentiert wurden, werden im folgenden Kapitel verwandte Arbeiten vorgestellt.

34siehe auch: Kapitel 1.1 (Problemstellung) und Abbildung 1.1 (berblick der XML-Schemaevolution)35In all cases only one schema remained [..] [Rod09a]

32

3. Stand der Technik

Die Schemaevolution ist nicht nur im Kontext von XML-Schema interessant. Esexistieren ebenso Anstze in relationalen bzw. objektorientierten Schemata, so-wie in XML Schema allgemein. Daher werden in diesem Kapitel klassische, teilsXML-Schema-fremde und aktuelle, XML-Schema-spezifische Anstze in den Ab-schnitten 3.1 und 3.2 thematisiert.In diesem Zusammenhang wird ebenfalls in Hinblick auf die folgenden Kapitel

dargelegt, welche Anforderungen, Konzepte und/oder Strategien gegebenenfallsbernommen und XML-Schema-spezifisch adaptiert werden. In Abschnitt 3.3werden die vorgestellten Anstze abschlieend kurz zusammengefasst.

3.1. Klassische Anstze der Schemaevolution

Zu den klassischen Anstzen wird die Mglichkeit der Schemaevolution im Um-feld des Relationenmodells und objektorientierter Schemata gezhlt. Diese XML-Schema-fremden Modelle werden in denAbschnitten 3.1.1 und 3.1.2 untersucht.In Abschnitt 3.1.3 wird die Evolution der Document Type Definition (DTD)

[BPSM+08] thematisiert. Diese in Kapitel 1 bereits erwhnte Spezifikation desW3C [W3C15a] gilt als eingeschrnkter Vorgnger von XML-Schema.

3.1.1. Relationenmodell

Das von Codd 1970 eingefhrte Relationenmodell [Cod70] ist das mittlerweileam weitesten verbreitete Datenbankmodell. [SSH13] Eine Veranschaulichung desStrukturteils ist in Abbildung 3.1 dargestellt. Eine Relation kann anschaulich

Attribut

R A1 An Relationenschema

Tupel Relation

Relationenname

Abbildung 3.1.: Veranschaulichung eines Relationenschemas mit Relation nach [SSH13]

33


als Tabelle verstanden werden: Die Attribute des Relationenschemas bilden dieSpaltenberschriften der Tabelle, die Tupel sind die verschiedenen Zeilen, unddie Eintrge in den verschiedenen Tabellenpositionen gehren zu den jeweiligenWertebereichen. [SSH13]SQL (Structured Query Language) ist die Datenbanksprache fr relationale

Systeme [..] und stellt als Datendefinitionssprache (engl. Data Definition Lan-guage, kurz DDL) eine ganze Reihe von Anweisungen zur Datendefinition zurVerfgung. [SSH13] Die minimalen Anforderungen von SQL sind in ISO/IEC9075-1 ([ISO11a]), ISO/IEC 9075-2 und ISO/IEC 9075-11 spezifiziert.1 [ISO11d]Besonders die in [ISO11b]2 spezifizierten Mglichkeiten zur Schemadefinition undManipulation sind im Kontext der Schemaevolution interessant, denn SQL un-tersttzt mit der alter-Anweisung auch eine einfache Form der Schemaevolution[SSH11]. Die alter-table-Anweisung ist in SQL-Beispiel 3.1 dargestellt.

: :=ALTER TABLE

::=

| | | | | | | |

SQL-Beispiel 3.1: alter-table-Anweisung nach [ISO11b]

Mit der alter-Anweisung knnen Spalten, Constraints und Versionierungsklau-seln hinzugefgt, verndert oder gelscht werden. Im Allgemeinen gilt, dass vonden nderungen betroffene Tabellen nicht referenzierbar sein drfen und dieszum aktuellen Zeitpunkt auch nicht sind.3 Diese starke Einschrnkung ist not-wendig, damit die Konsistenz einer Datenbank erhalten bleibt. Allerdings knntenkaskadierend referenzierende Strukturen angepasst werden (was zum Teil auchmglich ist), dies sollte bei der XML-Schemaevolution bernommen werden.Es existieren weitergehende Einschrnkungen, die exemplarisch fr jede Variante

(d.h. drop, alter und add) der Spaltennderung dargestellt werden soll. Eine Spaltedarf nur gelscht werden, wenn diese nicht die einzige der Tabelle ist.4 Datentypen1ISO/IEC 9075-1, ISO/IEC 9075-2 and ISO/IEC 9075-11 encompass the minimum requirements ofthe language. Other parts define extensions. [ISO11d]

2Mit Ausnahme von [ISO11a] werden die Final Drafts des Standards referenziert, da die Beschaffungdes Originalstandards mit nicht unerheblichen, finanziellen Aufwand verbunden ist.

3T shall not be a referenceable table or a system-versioned table. [ISO11b]4C shall be a column of T and C shall not be the only column of T. [ISO11b]

34


von Spalten drfen nur dahingehend gendert werden, dass der neue Typ demaktuellen in Hinblick auf Lnge, Genauigkeit, Mastab etc. entspricht oder diesenerweitert.5 Werden Spalten hinzugefgt, muss die Namenseindeutigkeit beachtetwerden.6 Weitere syntaktische, allgemeine, sowie Zugriffs- und Konformittsregelnexistieren fr jede Klausel der alter-Anweisung.Ein weiterer Aspekt der Schemaevolution sind Defaultwerte, die vorhandene

Tupel beim Hinzufgen von Spalten anpassen. Es existiert generell die Mglich-keit, Nullwerte zu verwenden, allerdings knnen auch beliebige Zeichenketten, Ka-talogdaten, Nutzer-, Sitzungs- oder Systeminformationen, sowie Datentypspezifi-sche Werte verwendet werden. Dieser Aspekt sollte bei der XML-Schemaevolutionbernommen und XML-Schema-spezifisch angepasst werden.In [HH06] wird das Problem der Datenbankschemaevolution und dessen Fol-

gen im Kontext aktuell verwendeter Informationssysteme (i.A. relationale Daten-banken) aus Sicht von Entwicklern thematisiert. Die bereits vorgestellte alter-table-Anweisung aus SQL-Beispiel 3.1 wird unter anderem angewendet. Es werdenTransformationen in drei Ebenen (d.h. konzeptuell, logisch und physisch) in einemnicht temporalen Ansatz betrachtet, in welchem alle Komponenten (d.h. Sche-mata, Daten und Programme) durch eine neue Version ersetzt werden7 [HH06].Besonders die Forderung der vollstndigen History von Transformationen, sowiedie konsekutive Analyse, Bereinigung und Normalisierung von dieser, sind Anst-ze, die bernommen werden sollen. In diesem Zusammenhang wird die eindeu-tige Identifikation von sich ndernden Objekten gefordert. Ein abstrakter, ein-deutiger Zeitstempel wird diesbezglich eingefhrt. Eine Identifikation von trans-formierten Schemakomponenten spielt ebenso in der XML-Schemaevolution einewichtige Rolle und knnte mit Hilfe von Surrogatschlsseln realisiert werden.

3.1.2. Objektorientierte Schemata

Bei Datenbanken bewirkt die Einfhrung der Objekt-Orientierung eine Abkehrvon zahlreichen Beschrnkungen, die dem Anwender durch die vorher verfgbare(insbesondere die relationale) Technologie auferlegt wurden [..]. [LV96]Neben einfachen Tabellen sind somit komplexe Strukturen und Attributwerte,

sowie eine variable Semantik durch die Spezifikation von Methoden mglich. DieInterpretation und Anzahl der objektorientierten Konzepte ist in den OODMs (ob-jektorientierte Datenbankmodelle, Anm. d. Autors) sehr unterschiedlich. [Heu97]Grundanforderungen eines objektorientierten Datenbankmodells werden allerdingsim Manifesto in [ABD+89] festgelegt, dazu zhlen zwingende (z.B. komplexe Ob-jekte, Objektidentitt, Kapselung, Typen- und Klassenhierarchien, u.a.) und optio-nale Features (z.B. Mehrfachvererbung, Typprfungen und -ableitungen, u.a.). Die5New type shall be greater than or equal to declared type of C [ISO11b]6The in the shall not be equivalent to the ofany other column of T. [ISO11b]

7non-temporal approach [..] all the application components [..] are replaced by new versions [HH06]

35


Schemaevolution ist interessanterweise eines der Features, welches nicht eindeutigals zwingend oder optional eingestuft wurde. Die Anforderung der Objektiden-titt ist wiederum zur Identifikation von sich ndernden Objekten sehr hilfreich.Die Beschreibung der Struktur und das Verhalten einer Objektdatenbank wird

alsObjektdatenbankschema bezeichnet. Zu einem Objektdatenbankschema ge-hren demnach: Klassen- und Typdefinitionen, Spezialisierungshierarchien, Me-thoden(-implementierungen), Funktionen und Trigger (ECA-Regeln), Integritts-bedingungen, sowie Sichtdefinitionen. [SST97]Die langfristige Verwaltung von Daten impliziert, dass das DBMS (Datenbank-

managementsystem, Anm. d. Autors) mit sich ndernden Gegebenheiten umge-hen kann. Es muss deshalb mglich sein, nderungen der betrachteten Miniweltoder der Anforderungen der Benutzer durch Schemaevolution nachzuvollziehenund existierende Daten an neue Schemata anzupassen. [Gep02]Ein berblick der Schemaevolution in objektorientierten Datenbanken mit deren

zentralen Fragestellungen und Anforderungen wird in [Li99] gegeben. Eine Frage-stellung bezieht sich auf die Mglichkeit der Anpassung mit Hilfe von Operationen.Diese Schemaoperationen knnen gem [Heu97] die Klasse bzw. Klassenin-tension (d.h. die Attributmenge oder Methoden), die Klassenhierarchie oder dieMenge der Klassen ndern. In [SST97] wird eine hnliche Auflistung gemacht, dieentsprechende Liste der Operationen ist in Abbildung 3.2 dargestellt. Die Klas-

Evolutionsebene nderungsoperationenneue Klasse einfgenbestehende Klasse lschenbestehende Klasse umbenennenneue Superklasse einfgenbestehende Superklasse entfernenSuperklassenreihenfolge ndernneues Attribut hinzufgenbestehendes Attribut lschenbestehendes Attribut umbenennenSichtbarkeit eines Attributs ndernTyp/Wertebereich eines Attributs ndernDefaultwert eines Attributs ndernneue Methode hinzufgenbestehende Methode lschenSichtbarkeit einer Methode ndernSignatur einer Methode ndernImplementierung einer Methode ndern

Datenbankschema

Klassenintension

Abbildung 3.2.: Auflistung relevanter Operationen der Schemaevolution nach [SST97]

sifikation von Operationen ist in der XML-Schemaevolution ebenso notwendig,besonders gilt dies fr die Betrachtung und Adaption von Hierarchien und Attri-butmengen.Es existieren unterschiedliche Schema-Evolutionsmechanismen, die Grundlage

36


von den spter verbreitetsten kommerziell vertriebenen Objekt-Datenbanksyste-men [Tre95] sind. Dazu zhlen zum Beispiel ORION [Kim88] oder O2 [FMZ+95].In ORION wurde der erste systematische Ansatz, Schemaevolution durch Kon-vertierung zu realisieren, vorgestellt [Kol99]. Die Schemanderungen von O2 ent-sprechen denen von ORION, wobei der Schwerpunkt auf die strukturelle undverhaltensmige Konsistenz gelegt wird [Kol99]. Bei der nderung, Einfgungoder Lschung von Methoden (d.h. verhaltensmige Konsistenz, Anm. d. Au-tors) luft diese Forderung auf eine inkrementelle Typberprfung hinaus. [Heu97]Eine inkrementelle Typberprfung, sowie ein interaktives Dialogsystem(Interactive Consistency Checker - ICC), das bei der Anwendung von Scheman-derungen in O2 ausgefhrt wird, sind Konzepte, die bei der XML-Schemaevolutionverwendet werden knnen.Ein fr die automatisierte nderung von Instanzen interessanter Ansatz ist der

Mechanismus von COCOON [Tre95], bei dem nderungen am Schema auf die Da-tenebene propagiert werden. Die nderungstaxonomie hnelt wiederum der vonORION. [Kol99] Ein weiterer Aspekt ist die Einteilung der Operationen gemderen Informationskapazitt. Eine Schemaevolution ist entweder kapazitts-erhaltend, -erweiternd, -reduzierend oder -ndernd. Durch diese ebenso fr dieXML-Schemaevolution interessante Einteilung kann bereits frhzeitig entschiedenwerden, ob vorhandene Instanzen (d.h. die Datenbasis) angepasst werden mssenoder nicht. Des Weiteren wird mit COOL-SML (Schema Manipulation Language)eine Schemaevolutionssprache eingefhrt, die die deklarative Beschreibung derEvolution, die berprfung von Strukturregeln, die bersetzung in Elementarope-rationen, sowie die Reoptimierung von impliziten Hierarchien ermglicht.Eine beliebige Restrukturierung von Typen ist in den meisten Schema-Evo-

lutionsmechanismen nicht vorgesehen. [Heu97] Darber hinaus werden die so-wieso nur rudimentren Schemanderungsoperationen teilweise abgelehnt, wennInstanzen vorliegen. Eine Typnderung in O2 kann zum Beispiel nur dann sinn-voll untersttzt werden, wenn alle Objekte der betroffenen Klasse vorher gelschtwerden [SST97]. Der damit verbundene, manuelle Aufwand zur Zwischenspeiche-rung und erneuten Zuordnung der Datenbasis kann nicht verlangt werden. DesWeiteren werden im Allgemeinen nicht alle Konzepte eines Objektdatenbanksche-mas bercksichtigt, dazu gehren unter anderem die Integrittsbedingungen oderSichtdefinitionen. Zum Beispiel werden im weitreichenden Ansatz bzw. Mechanis-mus in [Tre95] schon einfache Constraints wie Kardinalitten weggelassen, damitkeine Widersprche oder Zyklen in der Anwendung entstehen.

3.1.3. Document Type Description - DTD

Die Evolution der Document Type Definition (DTD) [BPSM+08] wird in [SKC+01]thematisiert. Ausgehend von den Schemaoperationen, die in ORION [Kim88] ein-gefhrt wurden, werden DTD Change Primitives und XML Data Operati-

37


ons vorgestellt. Diese sind in demXML Evolution Manager (XEM) umgesetztund sollen die Konsistenz von XML-Dokumenten bei strukturellen oder Constraintbetreffenden nderungen erhalten, sowie gltige DTDs erzeugen.Die DTD Change Primitives werden unterteilt in nderungen bezglich der De-

finition des Dokuments bzw. der Element- und Attributtypen. Eine solche Ope-rationsunterteilung von Schemakomponenten sollte ebenso in der XML-Schemaevolution bernommen werden. Die Operationen sind hier allerdings sehreingeschrnkt, was durch die Definition von Vorbedingungen bestimmt wird. Sodrfen keine beliebigen Elemente gelscht werden8, neue bzw. zwingende Elemen-te oder Attribute bentigen generell Defaultwerte9 und komplexe Elemente (d.h.Gruppen) knnen nicht auf zwingend gesetzt werden10.Die XML Data Operations dienen der Anpassung von XML-Dokumenten und re-

sultieren aus den obigen Primitiven. Diese werden in [SKC+01] nur kurz angefhrt,sind allerdings in [Kra01] bzw. [SKR02] ausfhrlicher charakterisiert.11 Es gibt laut[SKC+01] Einfge-, Lsch- und nderungsoperationen fr Elemente und Attribu-te eines XML-Dokuments. Die Identifizierung von den entsprechenden Positioneninnerhalb einer Instanz geschieht unter Anwendung von XPath-Ausdrcken.Lokationspfade werden im Abschnitt 2.2 vorgestellt und gleichfalls in der XML-Schemaevolution angewendet.Die XML Data Operations werden in Exemplar, der Prototyp-Implementation

von XEM, abschlieend abgendert. Aufgrund der Implementierung von Attribu-ten als Membervariablen in Java wird das Lschen dem Nullsetzen und das Einf-gen dem modifiziertem ndern gleichgesetzt. Somit verbleibt neben den Element-operationen explizit nur die nderung von Attributen als XML Data Operation.In [LHBM06] wird ein alternativer Ansatz zur Ermittlung von DTD nderungen

vorgestellt, dies ist der AlgorithmusDTD-Diff. Ausgehend von zwei DTDs werdendurch ein Matching bereinstimmende Paare von Elementtyp- (ETD), Attribut-(AD) und Entittsdeklarationen (ED) im DTD Data Model ermittelt. Die dabeianwendbaren Operationen werden in [LHBM05] erlutert und sind in Abbildung3.3 dargestellt. Es ist mglich, Kardinalitten (cardinality), komplexe Inhalte alsTeilbume12(leaf node und subtree), die Sortierung (order), sowie spezielle exter-ne Entitten (external ED) zu ndern. Des Weiteren wird die Verschiebung vonganzen Teilkomponenten durch die Move-Operation ermglicht. Die eingefhrtenOperationen sind ebenso in der XML-Schemaevolution notwendig.DTD-Diff erzeugt aus dem Matching ein nderungsskript zur berfhrung

der einen DTD in die andere. Die dazu notwendigen Operationen werden in fol-gender Reihenfolge analysiert: Verschieben (move), Lschen (delete), Einfgen (in-

8Element E must be a non-nested element with empty or PCDATA content model. [SKC+01]9The default value must not be null. [SKC+01]10We not allow the new quantifier to represent a required constraint if the old did not. [SKC+01]11Die Operationen unterscheiden sich im Vergleich, die ausfhrlichste Liste befindet sich in [SKC+01].12Die Autoren in [LHBM05] reprsentieren den Inhalt von Elementtypen als Bume.

38

3.2. Aktuelle Anstze der XML-Schemaevolution

Element Type Decl. (ETD) Attribute Declaration (AD)Insertion of a new ETD Insertion of a new ADDeletion of an ETD Deletion of an ADInsertion of a leaf node Insertion of a new attributeDeletion of a leaf node Deletion of an attributeInsertion of a subtree Update of attribute typeDeletion of a subtree Update of default valueMove a leaf node Entity Declaration (ED)Move a subtree Insertion of a new EDUpdate of order Deletion of an EDInsertion of cardinality Update of replacement text of internal EDDeletion of cardinality Update of location of external EDUpdate of cardinality Update of content notation of external ED

Abbildung 3.3.: Typen von nderungen des DTD Data Models nach [LHBM05]

sert), Kardinalittsnderung (cardinality update), Umsortieren (local order move),Attributlistennderung (attribute list change), sowie Entittsnderung (entity de-claration change). Diese Reihenfolge wird nicht weitergehend erlutert, allerdingsist diese notwendig, da ansonsten zum Beispiel eine Verschiebung durch ein L-schen und Einfgen realisiert werden knnte und somit berflssig wre.In [LHBM06] wird das mglichst effiziente Erkennen von nderungen thema-

tisiert. Allerdings wird explizit darauf hingewiesen, dass die erkannten nderun-gen als Grundlage fr die Anpassung von XML-Dokumenten, zur inkrementellenAnpassung von relationalen Schemata und/oder zur XML Schema Integration ge-nutzt werden knnen. Die Herleitung von Anpassungen von XML-Dokumenten ausSchemanderungen ist ein wesentlicher Bestandteil der XML-Schemaevolution.


Zu den aktuellen Anstzen gehren die Mglichkeiten der XML-Schema-spezi-fischen Systeme. Es werden in Abschnitt 3.2.1 die XML Funktionalitten dergroen Datenbankhersteller untersucht, bevor in 3.2.2 das XML-Tool DiffDog vonAltova bezglich der XML-Schemaevolution analysiert wird. Die spezialisiertenXML-Datenbanken werden in 3.2.3 erlutert.Anschlieend werden die Anstze und Prototypen anderer Forschungsgruppen

beschrieben. Dies sind X-Evolution in Abschnitt 3.2.4, das GEA-Frameworkin 3.2.5 und XCase in 3.2.6. Es werden die entsprechenden Publikationen desUmfelds der zugehrigen Gruppen unter den Aspekten der in Kapitel 1.1 thema-tisierten Problemstellung betrachtet. Dies beinhaltet gem Abbildung 1.1 haupt-schlich die Art und Weise der Erfassung von Schemanderungen (nderungen),deren Analyse und Charakterisierung (Bestimmung der nderungen), sowie dieAnpassung der XML-Dokumente (Adaption).In Abschnitt 3.2.7 werden weitere Arbeiten vorgestellt, die so nicht in die

Struktur der Arbeit passen, aber interessante Anstze und Strategien beinhalten.

39


3.2.1. XML-Schema in Datenbanksystemen

Die Datenbanken von Oracle (12c Release 1 [Ada14]), IBM (DB2 LUW v10.5[IBM13]) und Microsoft (SQL Server 2014 [Mic14]) bieten jeweils eine sehr groeVielfalt an Funktionalitten. Diese beinhalten nicht nur das klassische Relationen-modell oder objektrelationale Aspekte, es werden auch XML spezifische Inhalteangeboten. Dies ist unter anderem dem Standard ISO/IEC 9075-14 [ISO11c] ge-schuldet, in welchem Wege definiert werden wie die Datenbanksprache SQL inVerbindung mit XML genutzt werden kann13 [ISO11c].In [Sch03] wurden die Versionen Oracle 9i Release 2 14 , IBM UDB mit XML

Extender 7 15 und Microsoft SQL Server 2000 16 bezglich deren Mglichkeiten zurSchemaevolution untersucht. IBM und Microsoft ermglichten diese Eigenschaft.In bereinstimmung mit dem vorgestellten Umfang von Oracle in [CSK01] wurdevermerkt, dass diese Funktionalitt nicht vorgesehen sei.In aktuelleren Versionen dieser Datenbanken ist dies allerdings verndert, so

wird zum Beispiel in [Ora09] im direkten Vergleich von Oracle 11g und IBM LUWv9.5 der Oracle-Datenbank die Evolutionsmglichkeit zugesprochen.17

Oracle Database

Oracle XML DB untersttzt zwei Mglichkeiten zur Durchfhrung einer XML-Schemaevolution. Dazu wurden jeweils PL/SQL (Procedural Language/StructuredQuery Language) Prozeduren umgesetzt, welche in [Ada14] nebst entsprechenderEinschrnkungen und Leitfden erlutert werden.18Die Copy-Based Schema Evolution wird durch die Prozedur DBMS_XML-

SCHEMA.copyEvolve ermglicht, durch die alle Instanzdokumente, die zum altenXML-Schema gltig sind, in einen temporren Bereich kopiert werden. Das alteSchema wird gelscht und das modifizierte XML-Schema wird registriert, bevordie Instanzdokumente aus dem temporren Bereich an die entsprechende Stellezurck geschrieben werden.19 [Ada14]Der Nachteil dieser Methode ist, dass alle XML-Schemas sowie zugeordnete

XML-Dokumente whrend der Evolution kopiert und gelscht werden. Dies istdeaktivierbar, dennoch wird explizit auf die Erzeugung eines Backups vor Anwen-dung der Prozedur hingewiesen.20 Trotz Backups gehen allerdings weitergehende13defines ways in which Database Language SQL can be used in conjunction with XML [ISO11c]14Oracle 9i Release 2: Eigenschaft Schema-Evolution - Grad der Erfllung nicht vorgesehen [Sch03]15IBM UDB mit XML Extender 7.2: Schema-Evolution - Grad der Erfllung nicht mglich [Sch03]16Microsoft SQL Server 2000: Eigenschaft Schema-Evolution - Grad der Erfllung mglich [Sch03]17Support for Schema Extension, Versioning and Evolution - Oracle Yes / IBM Limited [Ora09]18In [Def12] werden die Oracle PL/SQL Prozeduren zustzlich mit einem komplexeren Beispiel getestet.19Copy-based schema evolution, in which all instance documents that conform to the schema are copied

to a temporary location in the database, the old schema is deleted, the modified schema is registered,and the instance documents are inserted into their new locations from the temporary area. [Ada14]

20Before executing procedure DBMS_XMLSCHEMA.copyEvolve, always back up all registered XML

40


Datenbankstrukturen mit Bezug zum Schema wie Indizes, Triggers, Constraints,Metadaten vom XML Typtabellen, usw. generell verloren.Neben diesen Problemen existieren Einschrnkungen bezglich der Scheman-

derungen, so sind Umbenennungen oder Lschungen von globalen Elementen nichtvorgesehen und verlangen einen manuellen Eingriff.21 Dies ist besonders bei globaldominierten Modellierungsstilen22 problematisch. Wird die Gltigkeit von XML-Dokumenten nach dem Einfgen aus dem temporren Bereich verletzt, wird einXSL-Dokument (Extensible Stylesheet L

XML-Schemaevolution : Änderung eines XML-Schemas mit...

Documents

Transcript of XML-Schemaevolution : Änderung eines XML-Schemas mit...

Dateimanagement in · PDF file• Microsoft Excel 2003 XML (.xml)

XML-Schema - blog.ag-nbi.deblog.ag-nbi.de/wp-content/uploads/2012/04/04_Schema.pdf · 6 Ziel-Namensraum • als XML-Schema für XML-Schema • Ziel-Namensraum für im XML-Schema definiertes

1 Verwaltung semistrukturierter Daten - was ist das? Datenverwaltung für XML-Dokumente - Daten in XML-Gewand - eigentlich XML-Dokumente - Abbildung auf.

XSL-FO - data2type GmbH: Ihre Spezialisten für XML ... · XML. XSLT. XPath. XHTML. Aufbau und Arbeitsweise von XSL Beispiel XML zu HTML. XML XSLT HTML. Manuel Montero Pineda ‒

XML Schema. © Prof. T. Kudraß, HTWK Leipzig Die 3 Strömungen von XML XML Schema Dokumenten- verarbeitung Datenbanken und Datenaustausch Semistrukturierte.

Bachelorarbeit XML-Schema-Evolution: Kategorisierung und … · 2019. 10. 28. · 1. Stufe: für Bewertung wichtig, ob die Änderung(en) Keine Auswirkung auf Instanzen Möglicherweise

XML - Schnelleinstieg

XML-Datenmodellierung und Web-Services · XML-Datenmodellierung und Web-Services XML Datenmodell Schemabeschreibungssprachen Anfragesprachen: XPath und XQuery Web-Services Überblick

Elektrisch Project Elektrische Schemas Inleiding

XML - BFHamrhein/Skripten/XML/XML.pdf · 2017. 1. 30. · XML-Dokument heisst wohlgeformt, wenn es die syntaktischen Regeln der Spezifikation einhält, bzw. wenn ein XML-Parser das

XML-Serverpages Vortrag im Rahmen des Seminars XML-Technologien Tobias Faessler.

XML-Werte in SQL/XML

DATENBANKEN Normalisierungsprozess. Normalisierung des DB-Schemas Ziel der Normalisierung des relationalen Datenbankschemas: Anomalien verhindern Redundanzen.

XML Framework: Cocoon Seminar: XML für Fortgeschrittene Referent: Katrin Apel.

XML-Schema - web-inspiration.de · Einführung in die Thematik XML und XML-Schema Kennenlernen der technischen Grundlagen von XML-Schema Wie wird ein XML-Schema Schritt für Schritt

Seminar: XML und intelligente Systeme - Technische Fakultätswrede/xml-isy/talks/xpath-e... · Seminar: XML und intelligente Systeme XML-Navigation: XPath, E4X Christoph Weitkamp

XML xhtml - publishingX · InDesign Export XSLT DTD Import Workflow xhtml XML XML und InDesign Kontakt: [email protected]

Datenorientiertes XML mit XML-Schema · M. Jeckle – Datenorientiertes XML mit XML -Schema 2002-03-11 3 Research and Technology Gliederung I Motivation •Verändertes Einsatzszenario

GAEB–Datenaustausch XML (GAEB DA XML) · PDF fileGemeinsamer Ausschuss Elektronik im Bauwesen GAEB–Datenaustausch XML (GAEB DA XML) Organisation des Austauschs von Informationen

ISYBau-XML (IsyXml) Reader/Writer - oebvi-schroeder.de · aber auch nach der Ausgabe mit einem externen XML-Validator gegen das IsyBau-XML-Schema geprüft werden, zB.: mit XSV (XML