Databases Reference
In-Depth Information
other schema. There is no correctness validation that the specified transformations
actually provide correct instance translation, so in the event that translated doc-
uments do not actually conform to the new schema, an error is thrown mid-
translation.
The second in-place method of evolution is performed using a different pro-
cedure called
DBMS XMLSCHEMA.inPlaceEvolve
. Because the evolution is
performed in place, the procedure does not have any parameters guiding physical
migration, given that there is none. The in-place evolution procedure has much less
expressive power than the copy version - for this procedure, there is a full reverse-
compatibility restriction in place. It is not just the case that all existing instances of
the old schema must also conform to the new schema without alteration; it must be
the case that all
possible
instances of the old schema must conform to the new one
as well. Therefore, the restriction can be statically determined from the schemas
and is not a property of the documents currently residing in the database. So, for
instance, schema elements cannot be reordered, and elements that are currently sin-
gletons cannot be changed to collections and vice versa. The restriction guarantees
that the relational representation of the schema does not change, which ensures that
the in-place migration does not impose relational disk layout changes.
The kinds of changes that in-place migration does support include as follows:
-
Add a new optional element or attribute (a subset of change class 1 from earlier
in the section).
-
Add a new domain value to an enumeration (subset of change class 11).
-
Add a new global element, attribute, or type (change class 3).
-
Change the type of an element from a simple type to a complex type with simple
content (change class 6).
-
Delete a global type, if it does not leave elements orphaned (subset of change
class 4).
-
Decrease the minOccurs for an instance, or increase the maxOccurs (subset of
change class 10).
This list is not comprehensive, but is representative. It is clear from these changes
that any valid instance of the old schema will still be valid after any of these changes.
To specify these incremental changes, Oracle has a proprietary XML difference lan-
guage called
diffXML
that is not specific to schemas but rather describe a diffgram
between two XML document instances (and XML schemas are, of course, XML
documents themselves). Expressions in diffXML loosely resemble expressions in
XML update facility in that they have primitives that append, delete, or insert nodes
in an XML document. However, diffXML expressions are XML documents rather
than XQuery expressions. For instance, one can change the MaxLength restriction
facet to 28 in a type using the following sequence of nodes:
<
xd:delete-node xpath
D
"/schema/complexType
[@name'Foo']//maxLength/
>
<
xd:append-node
parent-xpath
D
"/schema
/complexType[@name
D
'Foo']//restriction"
