XML Schema evolution in SQL Server 2005 (Yukon)
Klaus has asked an important question: How do we evolve XML Schemas in SQL Server 2005?
As he correctly points out, the namespace based approach of Beta1 made this very difficult. The XML Schema collections introduced in SQL Server 2005 Beta2 improves support for these types of scenarios tremendeously.
There are a couple of ways on how schemata may evolve. Let's look at some of them (please let me know if you have a scenario that I do not cover):
- Evolution by giving the schema a new version in the target namespace
This is the least problematic assuming that the old data preserves its old namespace and schema. You either define a new schema collection and add a new column referring to the new schema collection, or - if you want to evolve the data in one column - just add the new schema to the existing schema collection (subject to scenario 2 below).
If you also want to change the old data's format and namespace, you need to write an XQuery expression or (probably in the SQL Server 2005 timeframe) an XSLT transform that will transform your data to the new structure and namespace and insert it into a new column (or untype the column first, see point 3 below).
- Evolution by extending the existing schema without forcing revalidation
XML Schema collections allow evolution of existing schemata by adding new type, element, or attribute declarations, as long as the added components do not make the existing schema more restrictive and would require revalidation. Note that any sections in an already loaded schema may trigger this rule even if you just add a new top-level element. The DDL should raise the appropriate error automatically when you try to change the schema.
- Evolution by changing the existing schema
If you want to change your existing schema in a way that requires revalidation, e.g., by changing an existing type to be more restrictive, you will have to perform the following steps. Note that in the future, we may do this automatically, but currently, we feel that making the users go through these steps explicitly, he or she may be better understand the involved cost of revalidation.
- Create a new schema collection with the changed schemata.
- Use ALTER TABLE to untype the existing XML column that you want to change.
- Optionally run a transform to change the data into the new shape, if you change it too much.
- Use ALTER TABLE to retype the changed data
- If you do not need the old schema collection anymore, you can drop it.
As you can see, some form of evolution is easily done, while others are more complex and may involve data transformations and/or revalidation of data. If you want to evolve your schemata, the cost of evolving the data is one of the aspects to consider.