Databases Reference
In-Depth Information
complete set of change operations. The set is sound in that each evolution prim-
itive is guaranteed to maintain all validity and integrity properties; post-evolution,
all documents will still be well-formed XML and will still validate against the DTD.
The set is complete in that one can start with any DTD and arrive at any other valid
DTD using only changes from the set. The set of schema changes is as follows:
-
Create a DTD element type (change class 3).
-
Delete a DTD element type (change class 4).
-
Insert DTD element or attribute into an existing element type (change class 1).
-
Remove an element or attribute from an existing element type (change class 2).
-
Change the quantifier on an element in a type (change class 10, limited to the
kinds that DTD is capable of).
-
Nest a set of adjacent elements in a type beneath a new element (change class 7).
-
Flatten a nested element (change class 8).
Each individual change to a DTD induces a change on all valid documents to main-
tain document validity. For instance, if one adds a new required element or changes
the quantifier on an element so that it becomes required, XEM will automatically
add a default element to all instances that lack the element. Note that this evolu-
tion scheme takes a relational approach to evolution in the sense that all instances
must evolve to match the new schema rather than allowing documents to belong to
multiple versions simultaneously.
DTD-Diff
(
Leonardi et al. 2007
) is an algorithm and tool for detecting changes
between versions of a DTD. The algorithm takes as input two DTD instances and
returns a list of changes from the following categories:
-
Adding or deleting element, attribute, or entity declarations (change classes 3
and 4).
-
Change the content of an element type by adding, removing, or reordering nodes
(change classes 1, 2, 11, and 13).
-
Change element cardinality (change class 10, limited to DTD support).
-
Update attribute or entity facets such as changing a default value of an attribute or
updating the replacement text of an entity declaration (change classes 5 and 12).
The set of supported changes explicitly does not include construct renaming, due to
the fully automated nature of the difference engine - one could imagine adding sup-
port for allowing the result of a matching graph as additional input to handle such
renaming, though. The authors claim that applying existing XML document change
detection algorithms to instances of XML Schema (which are themselves XML
documents) does not necessarily yield semantically correct or optimal changes.
Diagram-based evolution
(
Domınguez et al. 2005
) is a way to bypass the absence
of a standard evolution language by allowing the developer to express evolution
intent using a tool. One such effort uses UML diagrams as a front end for an XML
schema; in turn, changes to a diagram translate to changes on the associated schema.
In that framework, a UML diagram is used as a conceptual model for an XML
schema and its corresponding documents. The UML diagrams supported by the
