 | Level: Intermediate Khurram Faraaz (khfaraaz@in.ibm.com), Systems Software Engineer, IBM
Ronny Bartsch (rbartsc@us.ibm.com ), Software Developer, IBM
Susan Malaika (malaika@us.ibm.com), Senior Technical Staff Member, IBM Silicon Valley Lab
20 Mar 2008 In many systems that use XML, the XML schemas will evolve over time. In this article, you'll learn how to handle those changes using DB2® pureXML Schema Registry (XSR) features, whether they are major or minor, and walk through an example of schema evolution, step-by-step.
Introduction
DB2 pureXML supports the XML data type where a variety of XML instance documents can be stored in a single column – as long as the documents are all well-formed. Stored XML documents can be validated against one or more XML schemas that have been registered in the DB2 XML Schema Repository (XSR).
In many systems, XML schemas change, for example once or twice a year. Sometimes the changes are minor (that is, just a few optional elements or attributes are introduced) and existing documents stored in the database conform to the new schema. Where the schema changes are minor, and comply with the DB2 compatibility rules for evolving an XML schema, the schemas are designated as compatible. In this case, the new schema can replace the old schema in the XSR.
In some cases, the schema changes can be major and the existing documents in the database would no longer validate against the new schema. In these cases the new schema would be added to the XSR without replacing the old schema. New documents being inserted or modified in the database that require validation, would be validated against the new schema, either by referring explicitly in the XMLVALIDATE statement to the new schema, or by referencing the new schema in the schema location uniform resource indentifier (URI) contained in the XML instance.
In all cases, whether the schema changes are major or minor, or whether schema validation is being used or not, the XML instance documents can continue to be stored and accessed in the same XML column in DB2 pureXML.
DB2 XML schema handling overview
Schema registration
You can give a schema two kinds of names at schema registration time using the REGISTER SCHEMA command:
- An SQL name, for example TEST.customer – typically used at validation time where strict control of the validating schema is required in applications, or when the corresponding XML instance documents do not contain schema location hints
- A schema location URI, for example http://www.test.com/customer -- typically used where XML instance documents refer to a schema through a schema location hint
Figure 1. Schema registration
Schema validation
You can use the XMLVALIDATE function to check that instance documents comply with one or more XML schemas registered in an XSR, either by specifying the SQL name, or relying on the schema location URI contained in the instance document.
Schema evolution
Often XML schemas evolve to reflect the changing nature of the business. If you are validating your stored documents against a schema that is about to change, then there are two ways to proceed in DB2 pureXML:
- If the two schemas are sufficiently alike (compatible), you can register the new schema in the XSR, replacing the original schema and continue validating. Both of the schema names (the SQL name and the schema location URI) remain the same across the two compatible schemas.
- In cases where the two XML schemas are not compatible, you register the new schema with a new SQL name and new schema location URI.
After evolving the new compatible schema, when using XMLVALIDATE, you can continue to refer to the new XML schema using the existing SQL name, or you can rely on the schema location URI in the XML instance documents provided that the URI remains unchanged across the existing and new XML instance documents. Typically compatible schema evolution is used when the changes in the schema are minor.
Schema evolution steps
Here are the steps, where the schema changes are minor, to evolve an XML schema in the XSR, replacing the existing schema with the new modified schema:
- Call the XSR_REGISTER stored procedure or run the REGISTER XMLSCHEMA command to register the new XML schema in the XSR. Note that no documents should be validated against the new registered XML schema, if the plan is to replace the existing schema with the new schema as described in step 2.
- Call the XSR_UPDATE stored procedure or run the UPDATE XMLSCHEMA command to update the new XML schema in the XSR, replacing the existing schema.
Successful schema evolution replaces the original XML schema. Once evolved, only the updated XML schema is available.
If the dropnewschema option is used on the XSR_UPDATE stored procedure or on the update XMLSCHEMA command, then the new schema is available under the existing schema name only, and is not available under the name used to register it.
Figure 1. Schema evolution
Compatibility rules in DB2
As described above, DB2 provides stored procedures and commands for updating XML schemas that replace an old XML schema with a new one. Successful replacement requires XML schemas that are compatible. In cases where the two XML schemas are not compatible, the update will fail and an error message is generated.
The following conditions are required to ensure compatibility:
-
Attribute content: Attributes declared or referenced inside of a complex type in the original XML schema must also be present in the new XML schema. Also, required attributes cannot be present in the new XML schema if they are not included in the original XML schema.
-
Element content: Elements declared or referenced inside of a complex type in the original XML schema must be present in the new XML schema. Required elements cannot be present in the new XML schema if they are not included in the original XML schema; only optional elements may be added.
-
Facet conflict: The facet value for a simple type in the new XML schema must be compatible with the range of values for the simple type defined in the original XML schema. For example:
<xs:restriction base="xs:decimal" />
|
as contrasted with:
<xs:restriction base="xs:decimal">
<xs:totalDigits value="7"/>
</xs:restriction>
|
-
Incompatible type: The type of an element or attribute in the new XML schema is not compatible if already inserted XML documents would fail validation against the new schema, or if the schema includes a simple type annotation that differs from that in the original XML schema. For example:
type="xs:string" versus>type="xs:integer".
-
Mixed into not mixed content: If the content model of a complex type is declared as mixed in the original XML schema, it must not be declared as not mixed in the new XML schema. For example,
mixed="true" versus mixed="false".
-
Nillable into not nillable: If the nillable attribute in an element declaration of the original XML schema is turned on, it must also be turned on in the new XML schema.
-
Removed element: Global elements declared in the original XML schema must also be present in the new XML schema, and must not be made abstract. For example,
<xs:element name="b" type="xs:string"/> versus <xs:element name="b" abstract="true"/>.
-
Removed type: If the original XML schema contains a global type that is derived from another type, the global type must also be present in the new XML schema.
-
Simple to complex: A complex type that contains simple content in the original XML schema cannot be redefined to contain complex content in the updated XML schema.
-
Simple content: Simple types defined in the original XML schema and in the new XML schema must share the same base types.
For more details, see Compatibility requirements for evolving an XML Schema.
Schema evolution example
In this example we show a schema customer that is updated with a compatible schema customer1 and then with incompatible schema customer2. The second XSR update fails. In this example, when validating an XML document, the SQL name of the schema is used to refer to the schema, and not the schema location URI in the contained in the XML instance document.
Listing 1. customer.xsd
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.test.com/customer">
<xsd:element name="customerType">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Name" type="xsd:string"/>
<xsd:element name="Address" type="xsd:string"/>
<xsd:element name="Phone" type="xsd:string"/>
<xsd:element name="email" type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="type" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
</xsd:schema> |
Listing 2. customer1.xsd
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.test.com/customer">
<xsd:element name="customerType">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Name" type="xsd:string"/>
<xsd:element name="Address" type="xsd:string"/>
<xsd:element name="Phone" type="xsd:string"/>
<xsd:element name="email" type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="type" type="xsd:string"/>
<xsd:attribute name="optType" type="xsd:string" use="optional"/>
</xsd:complexType>
</xsd:element>
</xsd:schema> |
Listing 3. customer2.xsd
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.test.com/customer">
<xsd:element name="customerType">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Name" type="xsd:string"/>
<xsd:element name="Address" type="xsd:string"/>
<xsd:element name="Phone" type="xsd:string"/>
<xsd:element name="email" type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="type" type="xsd:string"/>
<xsd:attribute name="reqType" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:schema> |
Step 1: Register customer.xsd.
REGISTER XMLSCHEMA http://www.test.com/customer
FROM c:\article\customer.xsd AS TEST.customer;
COMPLETE XMLSCHEMA TEST.customer; |
Note that http://www.test.com/customer is the schema location URI and TEST.customer is the SQL name for the schema.
Step 2:- Register customer1.xsd.
REGISTER XMLSCHEMA http://www.test.com/customer1
FROM c:\article\customer1.xsd AS TEST.customer1;
COMPLETE XMLSCHEMA TEST.customer1; |
Note that http://www.test.com/customer1 is the schema location URI and TEST.customer1 is the SQL name for the schema.
Step 3: Register customer2.xsd.
REGISTER XMLSCHEMA http://www.test.com/customer2
FROM c:\article\customer2.xsd AS TEST.customer2;
COMPLETE XMLSCHEMA TEST.customer2; |
Note that http://www.test.com/customer2 is the schema location URI and TEST.customer2 is the SQL name for the schema.
Step 4: Update schema customer with compatible schema customer1 so applications can continue to refer to TEST.customer schema.
Note: customer1.xsd has an optional attribute named optType.
CALL sysproc.xsr_update('TEST','CUSTOMER','TEST','CUSTOMER1',0);
Step 4 - Result:
Return Status = 0
Step 5: Update schema customer with schema customer2.
Note: customer2.xsd has a required attribute named reqType.
CALL sysproc.xsr_update('TEST','CUSTOMER','TEST','CUSTOMER2',0);
Step 5 - Result:
Return Message: SQL20432N The original XML schema contains "customerType" that is enclosed within or referenced by "" which is not compatible with the updated XML schema. The reason for the incompatibility is: "1" ("ATTRIBUTE CONTENT"). SQLSTATE=22538
Step 6: Validate the instance document against the registered schema.
Listing 4. Validating against the registered schema
<?xml version="1.0" encoding="UTF-8"?>
<n1:customerType type="String"
xsi:schemaLocation="http://www.test.com/customer"
xmlns:n1="http://www.test.com/customer"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Name>Kestle Ferder</Name>
<Address>Ring Road, Bangalore</Address>
<Phone>900400558765</Phone>
<email>m22@ibm.com</email>
</n1:customerType> |
The XML instance above validates successfully against TEST.customer referring to customer.xsd and later to customer1.xsd.
INSERT INTO T1(XMLCOL) VALUES ( XMLVALIDATE ( ? ACCORDING TO
XMLSCHEMA ID TEST.customer ) ) |
Step 7: Validate the instance document against the registered schema.
Listing 5. Validating against the registered schema
<?xml version="1.0" encoding="UTF-8"?>
<n1:customerType type="String" optType="testschemaevol"
xsi:schemaLocation="http://www.test.com/customer1"
xmlns:n1="http://www.test.com/customer1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Name>Kes Sales</Name>
<Address>Ring Road, Bangalore</Address>
<Phone>900400658765</Phone>
<email>m23@ibm.com</email>
</n1:customerType> |
The XML instance above validates successfully against TEST.customer referring to customer1.xsd, that is, after schema evolution of customer.xsd to customer1.xsd.
INSERT INTO T1(XMLCOL) VALUES ( XMLVALIDATE ( ? ACCORDING TO
XMLSCHEMA ID TEST.customer) ) |
Summary and advantages
Using DB2 pureXML schema evolution capabilities, you can evolve schemas without making any changes to your applications that refer to the changing schemas when performing validation.
Where the schema changes are major:
- If you are using the SQL name representing the schema during validation, you need to make small changes to refer to the new schema name in your application in order to start validating against the new schemas.
- If you are using the schema location URI in the XML instance documents during validation, then no changes are required in the application, provided the XML instances refer to the appropriate schemas.
In all cases, there is no requirement to re-validate documents already stored in DB2. Whether schema changes are major or minor, or whether schema validation is being used or not, the XML instance documents can continue to be stored and accessed in the same XML column in DB2 pureXML.
Moreover, with care, you can avoid making significant application changes when you execute queries against XML data based on schemas that evolve.
Resources Learn
Get products and technologies
-
Download a free trial version of DB2 Enterprise 9.
-
Now you can use DB2 for free. Download DB2 Express-C, a no-charge version of DB2 Express Edition for the community that offers the same core data features as DB2 Express Edtion and provides a solid base to build and deploy applications.
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational®, Tivoli®, and
WebSphere®.
Discuss
About the authors | 
| | Khurram Faraaz is a systems software engineer at IBM’s Information Management Group (part of IBM Software Group) in Bangalore, India. He works on functional verification testing of XML in DB2. Khurram also works on pureXML industry bundles.You can reach Khurram at khfaraaz@in.ibm.com |
| 
| | Ronny Bartsch is software developer co-op at IBM's Information Management Group (part of IBM software Group) in Somers, USA.
He works on industry bundles and demos related to industry standards using XML and DB2 pureXML. You can reach Ronny at rbartsc@us.ibm.com
|
| 
| | Susan Malaika works in IBM's Information Management Group. She specializes in XML and Web technologies, including Grid computing. She has published articles and co-edited a book on the Web. She is a member of the IBM Academy of Technology. You can reach Susan at malaika@us.ibm.com. |
Rate this page
| |
