Databases Reference
In-Depth Information
node-type
D
"element"
>
<
xd:content
>
<
xs:maxLength value
D
"28"/
>
<
/xd:content
>
<=
xd:append-node
>
Note that the expression language used to navigate an XML schema is vanilla XPath.
The
xd
namespace is the namespace for the diffXML language, and
xd:content
nodes contain fragments of XML schema using the
xs
namespace.
One can specify a diffXML document manually, or one can generate it from the
XMLDiff function, available both in Oracle's SQL dialect and Java. As mentioned
earlier, XMLDiff operates on any XML documents, not just XML schemas, so the
in-place evolution is essentially migrating schema by incrementally modifying the
schema documents as instances under a guarantee that there will be no cascading
effects of the migration.
Microsoft SQL Server
, like Oracle, supports storing a collection of homogeneous
XML documents in a relation column (
Pal et al. 2006
). Whereas instances in an
XML-typed column or table in Oracle must conform to a specific schema with a
specific global element as root, an XML-typed column in SQL Server validates
against any schema in a collection of schemas and allows any global element as root.
One specifies an XML Schema Collection in SQL server using a DDL statement:
CREATE XML SCHEMA COLLECTION [
<
relational schema
>
.]
sql identifier AS Expression
Once a schema collection has been created, it can be assigned to be the schema
for any column whose type is XML. Also, once the collection is created, there are
only two operations that can be done on it - drop it or alter it by adding new con-
structs. The ALTER statement is the only form of schema evolution that SQL Server
allows without manually dropping the schema, manually translating instances, and
reestablishing the schema. The ALTER statement has only one form:
ALTER XML SCHEMA COLLECTION [relational schema.]
sql identifier ADD Expression
For both the CREATE and ALTER statements, the expression must be a forest of
valid XML schema documents. The ALTER statement can add schema elements to
namespaces that already exist in the collection or to new namespaces.
The monotonic nature of alterations to a schema collection X means that, for the
most part, documents that conform to collection X will continue to validate against
the collection after alteration (maintaining the same reverse-compatibility restriction
of the in-place evolution in Oracle). The one exception is if the collection contains a
lax validation wildcard or any element whose type is xs:anyType. In such a case, the
addition of new global elements to the schema collection could cause documents
to fail validation. So, if any existing schema elements include such a construct,
revalidation of existing documents will happen any time new global elements are
added, and if the revalidation fails, the action is aborted.
