If new requirements arise models have to be adapted to them. Additionally, the instances based on these models have to be adapted as well otherwise they might not be valid anymore. The same applies to the XML schema as a model and widely accepted description for XML documents. One solution for solving the occurring validity problem is the here described XML schema evolution. On the basis of a conceptual model the user interaction is analyzed and translated into transformation steps for the adaption of XML instances. The user interaction contains the use of prede ned change operations on the conceptual model, a representation of the corresponding XML schema Die dynamische Anpassung von Modellen an aktuelle Gegebenheiten birgt die Notwendigkeit, vorhandene Instanzen und Anwendungen an die neuen, eventuell veranderten Umstande anzupassen. A ndert sich somit die strukturelle Beschreibung einer Datenbasis, muss zwangslau g auch die Datenbasis angepasst werden, damit die Gultigkeit bezuglich des neuen Modells gewahrleistet wird. Diese Problematik ist Kernpunkt des Gultigkeitsproblems, d.h. sind Instanzen eines Modells nach dessen A nderung noch gultig? Die Veranderung der Struktur eines XML-Schemas bspw. durch das Umsortieren von Inhaltsmodellen, das Erhohen des minimalen Vorkommens eines Elementes, das Einfugen oder auch Umbenennen nicht-optionaler Elemente etc. kann die Gultigkeit bereits vorhandener XML-Dokumente verletzen und macht eine Adaption dieser notwendig (siehe Abbildung 1).
Der erste Ansatz ist die Anwendung einer Evolutionssprache zur XML-Schemaevolution. Dies entspricht im Datenbankbereich dem Alter-Befehl der Data De nition Language SQL. Zur Zeit ist dieser Ansatz aufgrund der fehlenden, standardisierten Evolutionssprache fur XML-Schemata nicht anwendbar. Des Weiteren wird vom Anwender an dieser Stelle ein tiefes Verstandnis bzw. Expertenwissen der moglichen Sprachkonstrukte und deren Anwendung verlangt.
Der zweite Ansatz ist die Versionierung von Modellen. Sind verschiedene Modelle vorhanden, dann konnen Transformationsschritte aus dem Vergleich beider Modelle erzeugt werden. Es mussen an dieser Stelle allerdings unterschiedliche, eventuell nicht vergleichbare Versionen vorgehalten werden. Des Weiteren wird normalerweise bei syntaktischen und /oder semantischen Kon ikten eine automatische Losung basierend auf Heuristiken vorgeschlagen oder aber der Anwender zur Losung benotigt. Dieses Vorgehen erfordert wiederum ein tieferes Verstandnis bzw. Expertenwissen der beteiligten XML-Schemaversionen.
Der dritte Ansatz nutzt die Interaktion eines Anwenders aus, indem von diesem getatigte A nderungen an einer konzeptionellen Reprasentation eines XML-Schemas analysiert werden. Die Nutzeranderungen sind dabei die Anwendung vorde nierter Operationen auf einem konzeptionellen Modell. Das somit erlangte Wissen wird fur eine automatische Erzeugung von Transformationsschritten zur Anpassung der XML-Dokumente und Anwendungen verwendet. Es wird im Vergleich zu den ersten beiden Ansatzen weder vom Nutzer Expertenwissen bezuglich einer Evolutionssprache benotigt, noch mussen unterschiedliche Versionen eines XML-Schemas vorgehalten, ausgewahlt und verwendet werden.
Die XML-Schemaevolution wird sowohl von den gro en
Datenbank- und Softwareherstellern (u.a. Microsoft [
Microsoft unterstutzt den XML-Datentyp, lasst den Nutzer in Collections XML-Schemata sammeln und danach mittels einer Typisierung die Spalten einer Relation einem Schema zuordnen. XML-Instanzen typisierter Spalten konnen bezuglich ihres XML-Schemas auf Gultigkeit gepruft werden, andert sich allerdings ein XML-Schema, muss dieses unter einer neuen Version erneut eingefugt werden. Microsoft unterstutzt die hier angestrebte XML-Schemaevolution nicht, sondern nutzt die Versionierung von XML-Schemata. IBM DB2 ermoglicht die Registrierung von XML-Schemata in einem XML-Schema-Repository (XSR) und eine anschlieende Erweiterung dieser unter Beachtung von zehn strengen Kompatibilitatsanforderungen. In Oracle konnen Schemata ebenfalls registriert und anschlie end mittels der Methoden copyEvolve und inPlaceEvolve evolutioniert werden. Sowohl bei IBM als auch Oracle sind restriktive Anforderungen gestellt, die nur eine Generalisierung des alten Schemas ermoglichen und somit nur teilweise die angestrebte XMLSchemaevolution unterstutzen.
Altova bietet mit Di dog eine Erweiterung ihres Editors an, mit dem zwei Schemata miteinander verglichen werden konnen, um nachfolgend XSLT-Skripte zur Transformation der Instanzen zu erzeugen. Treten bei dem Vergleich Konikte auf, d.h. es kann keine eindeutige Zuordnung zwischen den unterschiedlichen Strukturen der XML-Schemata hergeleitet werden, dann wird vom Anwender eine manuelle Zuordnung verlangt. Eine Automatisierung ist nicht moglich, eine Nutzerinteraktion und somit Expertenwissen bezuglich der XML-Schemata ist erforderlich.
Die Prototypen X-Evolution [
PRISM++ [
In [
XCase [
Eine automatische Erzeugung von Transformationsschritten und die damit verbundene Anpassung von XML-Dokumenten sind in den hier vorgestellten Forschungsprototypen nicht moglich bzw. die umsetzbaren A nderungen sind nicht umfangreich genug. Des Weiteren wird bei keinem der Prototypen der hier vorgestellte Ansatz der XML-Schemaevolution verfolgt, es besteht somit weiterhin Forschungsbedarf in dieser Thematik.
Eine Grundlage der XML-Schemaevolution ist das an der
Universitat Rostock entwickelte, konzeptionelle EMX
Modell (Entity Model for XML-Schema), das zur gra schen
Modellierung von XML-Schemata im Forschungsprototypen
CodeX (Conceptual Design and Evolution for
XML-Schema [
Das konzeptionelle Modell (MM ) ist ein Tripel, das aus Knoten (NM ), gerichteten Kanten zwischen Knoten (EM ) und zusatzlichen Eigenschaften (FM ) besteht.
MM = (NM ; EM ; FM ) (1)
Die Knoten sind Elemente (elementsM ), Attributgruppen (attributegroupsM ), Inhaltsmodelle (groupsM ), Typen (einfache (simple-typesM ), komplexe (complex-typesM )), Module (modulesM , u.a. externe XML-Schemata), Integritatsbedingungen (integrity-constraintsM ) oder Annotationen (annotationsM ). Die Knotenarten werden naher charakterisiert (z.B. elementsM = felementM g, elementM = (ID, name, namespace, geometry, minoccur, maxoccur)), was auf Grund von Platzbeschrankungen an dieser Stelle und bei den folgenden Modellen nicht vertieft werden soll. Die gerichteten Kanten werden jeweils zwischen Knoten de niert, wobei die Richtung die Zugehorigkeit (Enthalten-sein Beziehung) umsetzt und gema der Moglichkeiten von XML-Schema festgelegt wurden.
Die zusatzlich zu de nierenden Eigenschaften ermoglichen die Nutzer-spezi sche Anpassung eines konzeptionellen Modells, insofern dies erwunscht ist. Dazu zahlen u.a. CodeXStandardwerte zur Kon guration des Editors, Angaben zur Pragmatik, Kosten, Namen und zur Version eines EMX Modells. Die Pragmatik (Pragmatik 2 fkapazitatserhaltend, kapazitatserhohend, kapazitatsreduzierendg) ist im Zusammenhang mit den A nderungsoperationen notwendig, um den Informationsverlust durch nicht beabsichtige Modellanpassungen zu verhindern. Die Kosten sollen die Steuerung von A nderungsoperationen ermoglichen, damit zu komplexe und somit eventuell zu teure Transformationen verhindert werden konnen. Kosten werden verwendet, um den Aufwand der A nderungen zu bestimmen und gegebenenfalls eine Versionierung vorzuschlagen. 3.2
XML-Schema (XSD) als strukturelle Beschreibung von
XML-Instanzen ist formal durch das W3C de niert [
MS = (NS; FS)
Knoten sind laut abstraktem Datenmodell De nitionen (type-de nitionsS), Deklarationen (declarationsS), Modellgruppen (model-group-componentsS), Gruppende nitionen (group-de nitionsS), Annotationen (annotationsS) oder Bedingungen (constraintsS). Neben der abstrakten De nition von Knoten existiert die Element-Informationseinheit, die fur jeden Knoten die Realisierung innerhalb eines XMLSchemas de niert, d.h. welche Inhalte und Attribute konnen verwendet werden oder nicht.
XML-Instanzen (MD) sind analog zum XML-Schema Tupel aus Knoten (ND) und zusatzlichen Eigenschaften (FD), wobei die Beziehungen zwischen den Knoten wieder implizit in diesen enthalten sind.
MD = (ND; FD)
Die Knoten einer XML-Instanz sind Dokumente
(documentsD), Attribute (attributesD), Prozessanweisungen
(processing-instructionsD), Namensraume (namespacesD),
Texte (textsD) oder Kommentare (commentsD) [
Zusatzlichen Eigenschaften sind der Name, die Version, A nderungseigenschaften und Signi kanz eines Dokumentes. Die A nderungseigenschaften (changeable 2 ftrue, falseg) sollen bei XML-Instanzen den ungewollten Informationsverlust verhindern (z.B. Entfernen von Elementen). Die Signi kanz (signi cance) ist ein normierter Wert, um bei Auswertungen von Dokumentkollektionen zum Finden von Standardwerten Dokumente priorisieren bzw. gewichten zu konnen. 3.3
Auf dem konzeptionellen Modell (EMX) werden vorde
nierte A nderungsoperationen vom Nutzer durchgefuhrt. Die
anwendbaren Operationen lassen sich gema der
Kategorisierung von A nderungsoperationen herleiten und
charakterisieren (siehe [
Mx
Operation ! M x0; x 2 fM; S; Dg (4)
Operationen sind zum Beispiel: changeElementType (Umsortieren vom Inhaltsmodell), changeElementMinOccur (Erhohen des minimalen Vorkommens eines Elementes), addElementToComplexElement (Einfugen nicht-optionaler Elemente) oder renameElement (Umbenennen eines Elementes).
Eine U bersicht uber die Zusammenhange zwischen den Modellen und den Operationen ist in Abbildung 2 dargestellt. Die renameElement -Operation soll exemplarisch auf den oben de nierten Modellen betrachtet werden. Dies ist eine einfache Operation, kompliziertere Evolutionsoperationen werden analog ausgefuhrt.
Wenn ein Nutzer die gra sche Reprasentation eines Elementes selektiert und das Attribut Name andert, dann wird dieses in CodeX erkannt und als renameElementM Operation geloggt. Regeln garantieren dabei, dass nur sinnvolle Operationen geloggt werden (z.B. Voraussetzung fur renameElement -Operation: oldValue 6= newValue). Die Identikation des selektierten Elements wird im konzeptionellen Modell durch eine eindeutige ID gewahrleistet. Neben der ausgefuhrten Operation, den beteiligten Werten und der ID mussen Informationen zum Kontext gespeichert werden. Dazu zahlen u.a. Angaben zum Gultigkeitsbereich, zu vorhandenen Referenzen und zum direkten Knotenumfeld (Position in einem Inhaltsmodell etc.). Diese Kontextinformationen sollen bei den nachfolgenden Operationen (renameElementS und renameElementD ) die Identi zierung des betro enen Elementes ermoglichen und die Verarbeitung erleichtern.
C: renameElementS (oldValue, newValue, context) 8 n; m; k 2 NS ^ n 6= m ^ n 6= k ^ m 6= k ^ context (n): // Globales Element mit neuem Namen existiert? if n; m 2 elementsS ^ n:scope:variety = 0global 0 ^ m:scope:variety = 0global 0 ^ n:name = oldValue ^ m:name = newValue then newValue := uniqueName(newValue) ^
n:name := newValue if 9 k 2 elementsS ^ k :scope:variety = 0local 0 ^ k :ref = oldValue then 8 k: k :ref := newValue // Lokales Element mit neuem Namen, aber anderem Typ existiert? elseif n; m 2 elementsS ^ n:scope:variety = 0local 0 ^ m:scope:variety = 0local 0 ^ n:name = oldValue ^ m:name = newValue ^ n:type 6= m:type ^ n:parent :name = m:parent :name then newValue := uniqueName(newValue) ^
n:name := newValue // Lokales Element, kein Namen-Typ-Konflikt? elseif n 2 elementsS ^ n:scope:variety = 0local 0 ^ n:name = oldValue
Nachdem der Nutzer das konzeptionelle Modell verandert hat, muss das entsprechende XML-Schema ebenfalls angepasst werden. Dafur wird das Log von CodeX geladen und analysiert. Durch dieses Vorgehen sind die auszufuhrende Operation, die veranderten Werte und der entsprechende Knoten bekannt (Kontextinformationen). Durch die darauffolgende Umbenennung eines Elementes im XML-Schema, mussen je nach Gultigkeitsbereich, umgebenen Knotenumfeld und vorhandenen Referenzen weitere Anpassungen am XML-Schema vorgenommen werden. Zum Beispiel muss gepruft werden, ob eventuell gleich benannte, globale Elemente schon vorhanden sind oder ob Referenzen angepasst werden mussen. Die im konzeptionellen Modell gesammelten und im Log gespeicherten Kontextinformationen erleichtern dies.
E: renameElementD (oldValue, newValue, context) 8 n 2 ND ^ FD :changeable: if n 2 elementsD ^ n:node-name = oldValue ^ context (n) then n:node-name := newValue
Der letzte Schritt in der XML-Schemaevolution ist die automatische Erzeugung von Transformationsschritten aus den A nderungen des Nutzers am konzeptionellen Modell. Nachdem das XML-Schema angepasst wurde, sind vorhandene XML-Instanzen eventuell nicht mehr gultig (Gultigkeitsproblem). Dies kann aus den Charakteristika der Operationen, den gespeicherten Informationen des Logs und den Anpassungen des XML-Schemas hergeleitet werden. Sind Instanzen betro en (der XML-Instanzein uss der Operation) und XML-Instanzen sollen verandert werden konnen (FD :changeable), dann muss ein entsprechendes Transformationsskript erzeugt werden, das die Instanzen anpasst. In CodeX wird aktuell ein XSLT Skript (XML Stylesheet Language Transformation) erzeugt, welches auf XML-Dokumente angewendet werden kann. 3.4
Die Beschreibung der Operationen macht deutlich, dass es Abhangigkeiten sowohl zwischen den Modellen als auch zwischen den Operationen gibt. Zum Beispiel sind die Kontextinformationen des konzeptionellen Modells fur die Identi kation von Knoten im XML-Schema und/oder XML-Instanzen notwendig, zeitgleich lasst die Element-Informationseinheit des XML-Schemas u.a. Aussagen uber notwendige oder nicht notwendige Anpassungen von XML-Instanzen zu (minOccurs, maxOccurs). Diese Zusammenhange wurden in der Abbildung 2 dargestellt und fuhren zu folgenden Theoremen:
Theorem 1. Ein konzeptionelles Modell MM wird durch die Operation A eines Nutzers verandert zu M M0 . Sei B eine Beschreibungsvorschrift zur Abbildung (Korrespondenz) des konzeptionellen Modells MM auf ein XML-Schema MS. C sei die Anderungsoperation zur Uberfuhrung von MS zu M S0. Dann gilt:
A + B ) C Das Theorem 1 besagt: Sind die Operation des Nutzers auf dem EMX Modell und die Korrespondenzen zwischen dem konzeptionellen Modell und dem XML-Schema bekannt, so kann die Operation zum Anpassen des XML-Schemas hergeleitet werden.
Theorem 2. Ein konzeptionelles Modell MM wird durch die Operation A eines Nutzers verandert zu M M0 . Sei B eine Korrespondenz zwischen dem konzeptionellen Modell MM und einem XML-Schema MS und sei D eine Korrespondenz zwischen dem XML-Schema MS und MD. E sei die Anderungsoperation zur Uberfuhrung von XML-Instanzen MD zu XML-Instanzen M D0, die bezuglich M S0 gultig sind. Dann gilt:
A + B + D ) E Das Theorem 2 besagt: Sind die Operation des Nutzers auf dem EMX Modell und die Korrespondenzen zwischen dem konzeptionellen Modell, dem XML-Schema und den XMLInstanzen bekannt, so kann die Operation zum Anpassen der XML-Instanzen hergeleitet werden.
Es konnen somit aus der Auswertung der Nutzerinteraktion mit dem konzeptionellen Modell automatisch entsprechende Transformationsschritte hergeleitet werden. 4.
Die vorgestellte renameElement -Operation wird nachfolgend an einem durchgangigen Beispiel auf den unterschiedlichen Modellen angewendet.
Der Knoten mit dem Namen 'nummer' wird vom Nutzer ausgewahlt und im konzeptionellen Modell verandert (siehe Abbildung 3). Es sind keine Einschrankungen bezuglich der Modellpragmatik oder der nicht zu uberschreitenden Kosten gemacht worden (siehe FM ). CodeX erkennt, dass der ausgewahlte Knoten eine spezi sche ID (hier z.B. '1') hat und entsprechend ein Element ist. Wird nun das Attribut Name verandert, d.h. dieses Attribut bekommt den neuen Wert 'ID' ('nummer' 6= 'ID'), dann wird dies in das Log geschrieben. Im Log steht, dass die Operation renameElement ('1', 'nummer', 'ID') ausgefuhrt wurde. Des Weiteren werden anhand der eindeutigen Knoten-ID Kontextinformationen gespeichert, zum Beispiel die Gultigkeit ('lokal'), eventuelle Referenzen (ist in dem Fall aufgrund der Gultigkeit nicht moglich) und das Knotenumfeld (Vaterknoten ist gema der Kanteninformationen EM 'event', Inhaltsmodell ist eine Sequenz, zweite Position in Sequenz). Abbildung 4 ist das zum obigen EMX Modell gehorende XML-Schema. Die Korrespondenzen zwischen dem konzeptionellem Modell und dem XML-Schema sind de niert, d.h. es ist aufgrund der Abbildungsvorschriften moglich, das eine Modell in das andere zu uberfuhren. Durch das Log ist bekannt, dass die renameElement -Operation ausgefuhrt wurde, diese Operation muss demnach auch auf dem XMLSchema nachvollzogen werden. Es gibt dem Log folgend ein lokales Element ohne Referenzen im XML-Schema, welches den Namen 'nummer' hat, in einer Sequenz an zweiter Stelle steht und den Vater 'event' besitzt. Dieses Element soll umbenannt werden, das Attribut 'name' soll den neuen Wert 'ID' erhalten. In dem uberschaubaren Beispiel ist dies nur ein Knoten, der den entsprechenden Kontext hat und mittels der renameElement -Operation umbenannt wird.
Aufgrund der Anwendung einer Operation auf dem konzeptionellen Modell (Operation und Kontextinformationen werden geloggt) und der bekannten Korrespondenzen, kann demnach die Operation zum Anpassen des XML-Schemas hergeleitet werden (siehe Theorem 1).
Durch die Umbenennung eines Elementes kann die Gultigkeit von XML-Instanzen betro en sein. Es wurde die renameElement -Operation ausgefuhrt, welche laut Operationsspezi kation eine kapazitatserhaltende Operation ist. Des Weiteren kann die Operation je nach Parametern (d.h. die Kontextinformationen) einen Ein uss auf die Gultigkeit von XML-Instanzen haben. Es muss zunachst der entsprechende Elementknoten im XML-Schema durch die Kontextinformationen ermittelt werden. Es ist bekannt, dass das Element 'nummer' laut Korrespondenz zwischen XML-Schema und XML-Instanz ein zwingendes Element in einer Sequenz war (minOccurs = '1'), falls das globale Vaterelement 'event' als Dokumentenwurzel ausgewahlt wurde. Das bedeutet, dass alle XML-Instanzen die gultig bezuglich des alten XML-Schemas waren und die verandert werden sollen (FD :changeable), entsprechend an das neue XML-Schema angepasst werden mussen.
Durch die Anwendung einer Operation auf dem konzeptionellen Modell und der bekannten Korrespondenzen zwischen EMX Modell, XML-Schema und XML-Instanz, kann die Operation zum Anpassen der XML-Instanzen hergeleitet werden (siehe Theorem 2).
Diese Operation bzw. die notwendigen Transformationsschritte sind in einem XSLT-Skript realisiert, welches fur das Beispiel in Abbildung 5 dargestellt ist.
Ergebnis Export
Updateskripte &
Evolutionsergebnisse
Transformation
konzeptionelle Modell bzw. dessen gra sche Reprasentation
von einem Nutzer verandert werden, was entsprechend in
einem Log gespeichert wird. Welche A nderungen bzw. vorde
nierten Operationen anwendbar sind, wird durch
Operationsspezi kationen beschrieben (siehe Kategorisierung in [
Die XML-Schemaevolution behandelt das Gultigkeitsproblem. Wenn sich XML-Schemata andern und somit an neue Gegebenheiten bzw. Anforderungen angepasst werden, mussen deren Instanzen zur Wahrung der Gultigkeit ebenfalls adaptiert werden. Dies sollte weitestgehend automatisch erfolgen. Im prasentierten Ansatz wird ein konzeptionelles Modell verwendet, welches eine vereinfachte, gra sche Reprasentation eines XML-Schemas ist. Wird das konzeptionelle Modell durch vorde nierte Operationen von einem Nutzer verandert, dann wird das damit gewonnene Wissen entsprechend geloggt und danach fur die Anpassung des XML-Schemas und der XML-Instanzen angewendet. In diesem Zusammenhang sind Kontextinformationen und Korrespondenzen zwischen den Modellen entscheidend, denn nur durch diese Informationen konnen automatisiert Transformationsschritte aus der Nutzerinteraktion hergeleitet werden.
Die einzelnen Modelle wurden kurz vorgestellt, bevor die renameElement-Operation formal beschrieben wurden. Die Zusammenhange der einzelnen Modelle und die Anwendung der renameElement-Operation wurde ebenfalls thematisiert. An einem durchgangigen Beispiel wurde daruber hinaus dargestellt, wie diese Operation auf den einzelnen Modellen angewendet wird. Des Weiteren wurde CodeX als Forschungsprototyp prasentiert, der zur Realisierung und Durchfuhrung der XML-Schemaevolution unerlasslich ist.
Ein hier nicht ausfuhrlich, aber dennoch in CodeX bereits vorhandener Aspekt ist die Berucksichtigung von Kostenfunktionen bei der XML-Schemaevolution. Aktuell werden die moglichen Kosten einer Evolution anhand der durchzufuhrenden A nderungsoperation abgeschatzt und mit einem Nutzer-spezi schen Grenzwert verglichen. CodeX kann so kon guriert werden, dass bei U berschreitung dieses Wertes A nderungsoperationen abgelehnt werden und stattdessen eine Versionierung vorgeschlagen wird.
CodeX bietet derzeit Basisfunktionalitaten zur Modellierung von XML-Schema und zur XML-Schemaevolution an. Momentan fehlen allerdings die Behandlung von Integritatsbedingungen, Namensraume, die Beachtung von Dokumentkollektionen und die Auswertung und Speicherung der Kontextinformationen. In Zuge der Anpassung und Erweiterung soll CodeX als Webapplikation freigeschaltet werden, damit der Prototyp von anderen Anwendern zur XML-Schemaevolution verwendet werden kann.
Des Weiteren werden die bisher vorhandenen
Beschreibungen der A nderungsoperationen gema der
Kategorisierung von [