Manage XML Schemas in DB2, Part 1: Manage XML schemas and validate XML data

Explore both schema location and a relational ID to manage XML schemas and validate XML data

XML schemas come in various types, including an XML schema with and without a namespace, XML schemas consisting of multiple definitions, and XML schemas consisting of multiple namespaces. This article takes those kinds of XML schemas, and introduces ways to register XML schemas, ways to validate XML data, ways to get the XML schema used for validating XML data, and so on. This article is described based on DB2 9.7 for Linux®, UNIX® and Windows®.

Masahiro Ohkawa (mohkawa@jp.ibm.com), IM, Yamato Software Development Laboratory, WSO2 Inc

Photo of Masahiro OhkawaMasahiro Ohkawa is a member of the database tooling development team in the Yamato Software Development Laboratory (YSL), IBM Japan.



23 February 2010 (First published 02 February 2010)

Also available in Russian Japanese Vietnamese Portuguese Spanish

23 Feb 2010: Added links to Part 2 of this series in Introduction, Conclusion, and Resources sections.

Introduction

Frequently used acronyms

  • SQL: Structured Query Language
  • W3C: World Wide Web Consortium
  • XML: Extensible Markup Language
  • XSD: XML Schema Definition

The XML schema recommended by W3C provides ways to express the location of an XML schema (hereafter called schema location). The schema location is specified to get the XML schema when you validate XML data, and when another XML schema includes or imports it. W3C says that the schema location is only a hint and some processors and applications will have reason to not use it.

Therefore DB2 provides two ways to get the XML schema when you validate XML data. One is to use the schema location defined by W3C. The other is to use a unique ID called a relational ID that is introduced in DB2 (Figure 1).

Figure 1. Manage XML schemas in DB2 (XML Schema Repository)
Validate an XML schema using schema location or relation ID (can import or include schema in another schema)

There are several types of XML schemas. This article takes the following types, and uses examples to introduce how to register XML schemas, to validate XML data, to get the XML schema used for validating XML data, and so on.

  • XML schema without a namespace
  • XML schema without a namespace, which refers to another XML schema without a namespace
  • XML schema with a namespace
  • XML schema with a namespace, which refers to another XML schema with a different namespace

Register the XML schema

The following steps are taken to register an XML schema in DB2.

  1. Register the main XML schema (REGISTER XMLSCHEMA command)

    Note: The DB2 command is not case sensitive. XML data and schema locations are case sensitive. Whether the physical location like '/work/customer1.xsd' is case sensitive depends on the operating system. (Windows is not case sensitive. Linux and UNIX are case sensitive.)

  2. Add XML schemas that are included or imported (ADD XMLSCHEMA command)
    1. Note: You can also add these XML schemas in step 1 by using the command options when you register the main XML schema.
  3. Validate and activate the registered XML schema (COMPLETE XMLSCHEMA command)

To explain the steps above in detail, examples of these types of XML schemas are shown below.

An XML schema without a namespace

customer1.xsd in Listing 1 is an example of an XML schema without a namespace.

Listing 1. customer1.xsd (XML schema)
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="customer">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="name" type="xs:string"/>
                <xs:element name="address" type="xs:string"/>
                <xs:element name="phone" type="xs:string"/>
                <xs:element name="email" type="xs:string"/>
            </xs:sequence>
            <xs:attribute name="type" type="xs:string"/>
        </xs:complexType>
    </xs:element>
</xs:schema>

To register an XML schema in DB2, you need to specify a schema location and a relational ID that are associated with the XML schema. The relational ID has a schema name that is like a table name. The relational ID for the XML schema (in Listing 1) is assumed to be SAMPLE.CUSTOMER1, and the schema location is assumed to be customer1.xsd. Issue the following command to register the XML schema. (It is assumed that the XML schema is defined in the /work/customer1.xsd file. Hereafter, the required files are assumed to be saved under the /work directory.)

REGISTER XMLSCHEMA 'customer1.xsd' FROM '/work/customer1.xsd' AS SAMPLE.CUSTOMER1;

Then issue the following command to validate the XML schema and activate it:

COMPLETE XMLSCHEMA SAMPLE.CUSTOMER1;

For your reference, to drop the XML schema, issue the following command:

DROP XSROBJECT SAMPLE.CUSTOMER1;

An XML schema without a namespace, which refers to another XML schema without a namespace

When neither the referencing XML schema nor the referenced XML schema have a namespace or when both XML schemas have the same namespace, you can specify the schema location of referenced XML schema with the include element in the referencing XML schema. In DB2, both XML schemas are stored in the repository using the schema location and relational ID of the referencing schema. But both XML schemas are identified inside of the XML Schema Repository. To do so, DB2 uses the schema location specified with the include element, which is called the internal schema location in this article. That is to say, DB2 manages the referenced XML schema within the referencing schema location and relational ID by using the internal schema location (Figure 2).

Figure 2. Schema location used inside of the XML Schema Repository
Schema location referenced inside an XML schema (can import or include schema in another schema)

customer2.xsd in Listing 2 is an XML schema without a namespace, which refers to company2.xsd in Listing 3 without a namespace.

Listing 2. customer2.xsd (XML schema)
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:include schemaLocation="company2.xsd"/>
    <xs:element name="customer">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="name" type="xs:string"/>
                <xs:element name="address" type="xs:string"/>
                <xs:element name="phone" type="xs:string"/>
                <xs:element name="email" type="xs:string"/>
                <xs:element ref="company-name"/>
                <xs:element ref="company-address"/>
            </xs:sequence>
            <xs:attribute name="type" type="xs:string"/>
        </xs:complexType>
    </xs:element>
</xs:schema>
Listing 3. company2.xsd (XML schema)
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="company-name" type="xs:string"/>
    <xs:element name="company-address" type="xs:string"/>
</xs:schema>

The relational ID used to store these two XML schemas is assumed to be SAMPLE.CUSTOMER2, and the schema location is assumed to be customer2.xsd.

The first step is to register customer2.xsd, the first XML schema.

REGISTER XMLSCHEMA 'customer2.xsd' FROM '/work/customer2.xsd' AS SAMPLE.CUSTOMER2;

The next step is to add the company2.xsd XML schema. When adding it, specify a schema location that is used to manage the XML schema inside of the XML Schema Repository. The schema location must be identical to the schema location specified in the schemaLocation attribute value of the include element (company2.xsd in this example). DB2 uses the schema location to get the included XML schema when the XML schema is validated.

ADD XMLSCHEMA DOCUMENT TO SAMPLE.CUSTOMER2 ADD 'company2.xsd' FROM '/work/company2.xsd';

Finally, issue the following command to validate the XML schema and activate it:

COMPLETE XMLSCHEMA SAMPLE.CUSTOMER2;

XML schema with namespace

customer3.xsd in Listing 4 is an XML schema with the namespace http://www.sample.com/customer.

Listing 4. customer3.xsd (XML schema)
<?xml version="1.0"?>
<xs:schema targetNamespace="http://www.sample.com/customer"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified">
    <xs:element name="customer">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="name" type="xs:string"/>
                <xs:element name="address" type="xs:string"/>
                <xs:element name="phone" type="xs:string"/>
                <xs:element name="email" type="xs:string"/>
            </xs:sequence>
            <xs:attribute name="type" type="xs:string"/>
        </xs:complexType>
    </xs:element>
</xs:schema>

The way to register the XML schema is the same as one that has no namespace. Assuming the relational ID is SAMPLE.CUSTOMER3, and the schema location is customer3.xsd, issue the following command to register the XML schema:

REGISTER XMLSCHEMA 'customer3.xsd' FROM '/work/customer3.xsd' AS SAMPLE.CUSTOMER3;

Issue the following command to validate the XML schema and activate it:

COMPLETE XMLSCHEMA SAMPLE.CUSTOMER3;

An XML schema with a namespace, which refers to another XML schema with a different namespace

When an XML schema with a namespace refers to another XML schema with a different namespace, the import element is used with the imported namespace and schema location. As for the schema location, if the processor doesn't use it, you can omit it. DB2 doesn't refer to the schema location, but uses the namespace to get the XML schema. So you can omit the schema location.

customer4.xsd in Listing 5 is an XML schema with the namespace http://www.sample.com/customer, and refers to another XML schema with the namespace http://www.sample.com/company (in Listing 6). The schemaLocation attribute of the import element in customer4.xsd can be omitted.

Listing 5. customer4.xsd (XML schema)
<?xml version="1.0"?>
<xs:schema targetNamespace="http://www.sample.com/customer"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xmlns:com="http://www.sample.com/company"
        elementFormDefault="qualified">
    <xs:import namespace="http://www.sample.com/company" schemaLocation="company4.xsd"/>
    <xs:element name="customer">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="name" type="xs:string"/>
                <xs:element name="address" type="xs:string"/>
                <xs:element name="phone" type="xs:string"/>
                <xs:element name="email" type="xs:string"/>
                <xs:element ref="com:name"/>
                <xs:element ref="com:address"/>
            </xs:sequence>
            <xs:attribute name="type" type="xs:string"/>
        </xs:complexType>
    </xs:element>
</xs:schema>
Listing 6. company4.xsd (XML schema)
<?xml version="1.0"?>
<xs:schema targetNamespace="http://www.sample.com/company"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified">
    <xs:element name="name" type="xs:string"/>
    <xs:element name="address" type="xs:string"/>
</xs:schema>

The relational ID for storing these two XML schemas is assumed to be SAMPLE.CUSTOMER4, and the schema location is assumed to be customer4.xsd.

The first step is to issue the following command to register the first XML schema, customer4.xsd:

REGISTER XMLSCHEMA 'customer4.xsd' FROM '/work/customer4.xsd' AS SAMPLE.CUSTOMER4;

The next step is to add the company4.xsd XML schema. When adding it, specify the schema location that is used to manage the XML schema inside of the XML Schema Repository. When you import an XML schema with different namespace, the namespace is used to get the XML schema. So any schema location can be used because the schema location is not used. In this example, the schemaLocation attribute of the import element is not omitted, but the same name is used for the schema location when you add the XML schema. By doing this, you know where the imported XML schema is stored from the schemaLocation in the import element.

ADD XMLSCHEMA DOCUMENT TO SAMPLE.CUSTOMER4 ADD 'company4.xsd' FROM '/work/company4.xsd';

Finally, issue the following command to validate the XML schema and activate it:

COMPLETE XMLSCHEMA SAMPLE.CUSTOMER4;

Insert and validate the XML data

Using examples, this section explains how to validate XML data by using the XML schemas in Register the XML schema, and insert the XML data into an XMLDATA column. First, create table T1:

CREATE TABLE T1 (ID INT NOT NULL PRIMARY KEY, XMLDATA XML NOT NULL);

When you validate XML data in SQL, use the XMLVALIDATE function. When you validate XML data in the IMPORT command, use the XMLVALIDATE option.

An XML schema without a namespace

customer1.xml in Listing 7 is an example XML data that fits the customer1.xsd XML schema. When you refer to an XML schema without a namespace, use the noNamespaceSchemaLocation attribute of the "http://www.w3.org/2001/XMLSchema-instance" namespace.

Listing 7. customer1.xml
<?xml version="1.0"?>
<customer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="customer1.xsd"
  type="1">
    <name>cust1</name>
    <address>address1</address>
    <phone>11-2222-3333</phone>
    <email>cust1@sample.com</email>
</customer>

The XMLVALIDATE function has several options. When the options are omitted as in the following INSERT statement example, the XML schema whose schema location is the same as the schema location specified in the XML data (in the example in Listing 7, the value of the xsi:noNamespaceSchemaLocation attribute, customer1.xsd) is used to validate the XML data.

INSERT INTO T1(ID, XMLDATA) VALUES (1, 
XMLVALIDATE(XMLPARSE(DOCUMENT 
'<?xml version="1.0"?>
<customer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="customer1.xsd"
  type="1">
    <name>cust1</name>
    <address>address1</address>
    <phone>11-2222-3333</phone>
    <email>cust1@sample.com</email>
</customer>'))
);

When you add ACCORDING TO XMLSCHEMA ID Relational ID, the schema location specified in the XML data is ignored, and the XML schema whose relational ID is the same as this relational ID is used to validate the XML data.

The above XML data conforms to SAMPLE.CUSTOMER1. But issue the following SQL to validate the XML data with the SAMPLE.CUSTOMER2 XML schema.

INSERT INTO T1(ID, XMLDATA) VALUES (11, 
XMLVALIDATE(XMLPARSE(DOCUMENT 
'<?xml version="1.0"?>
<customer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="customer1.xsd"
  type="1">
    <name>cust1</name>
    <address>address1</address>
    <phone>11-2222-3333</phone>
    <email>cust1@sample.com</email>
</customer>') ACCORDING TO XMLSCHEMA ID SAMPLE.CUSTOMER2)
);

Because this XML data conforms to SAMPLE.CUSTOMER1, but doesn't conform to SAMPLE.CUSTOMER2, the following error occurs:

SQL16205N  XML document contains too few elements to match content model
"((name,address,phone,email,company-name),company-address)".  SQLSTATE=2200M

As this example shows, by using the relational ID, you can validate XML data with several XML schemas without modifying the XML data.

The IMPORT command has several XMLVALIDATE options. Specifying XML VALIDATE USING SCHEMALOCATION HINTS uses the schema location in the XML data, while specifying XMLVALIDATE USING SCHEMA Relational ID uses the relational ID.

Create the following customer1.del file to import a record in the T1 table, which has 111 in the ID column, and the content of the customer1.xml file in the XMLDATA column.

Listing 8. customer1.del
111, "<XDS FIL='customer1.xml'/>"

Issue the following IMPORT command to validate the XML data with the XML schema obtained by the schema location in the XML data:

Listing 9. Validating XML data in an XML schema obtained by the schema location
 IMPORT FROM /work/customer1.del of del XML FROM /work
 XMLVALIDATE USING SCHEMALOCATION HINTS INSERT INTO T1;

Delete the above imported record by issuing "DELETE FROM T1 WHERE ID=111" SQL statement, and issue the following IMPORT command to validate the XML data with the XML schema obtained by the relational ID in the XML data:

Listing 10. Validating XML data in an XML schema obtained by the relational ID
IMPORT FROM /work/customer1.del of del XML FROM /work
XMLVALIDATE USING SCHEMA SAMPLE.CUSTOMER1 INSERT INTO T1;

An XML schema without a namespace, which refers to another XML schema without a namespace

customer2.xml in Listing 11 is sample XML data that conforms to customer2.xsd.

You can validate the XML data the same way as in Listings 9 and 10.

Listing 11. customer2.xml
<?xml version="1.0"?>
<customer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="customer2.xsd"
  type="2">
    <name>cust2</name>
    <address>address2</address>
    <phone>11-2222-3333</phone>
    <email>cust2@sample.com</email>
    <company-name>company1</company-name>
    <company-address>company-address1</company-address>
</customer>

An XML schema with a namespace

customer3.xml in Listing 12 is sample XML data that conforms to the customer3.xsd. When referring to an XML schema with a namespace, specify the namespace and the schema location in the schemaLocation attribute of the http://www.w3.org/2001/XMLSchema-instance namespace.

You can validate the XML data the same way as in Listings 9 and 10.

Listing 12. customer3.xml
<?xml version="1.0"?>
<customer xmlns="http://www.sample.com/customer"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.sample.com/customer customer3.xsd"
  type="3">
    <name>cust3</name>
    <address>address3</address>
    <phone>11-2222-3333</phone>
    <email>cust3@sample.com</email>
</customer>

An XML schema with namespace, which refers to another XML schema with a different namespace

customer4.xml in Listing 13 is sample XML data that conforms to customer4.xsd. In this example, the namespaces of all elements are explicitly specified. When you refer to multiple XML schemas with multiple namespaces, specify the multiple pairs of the namespace and the schema location in the schemaLocation attribute of the http://www.w3.org/2001/XMLSchema-instance namespace.

When you validate XML data by using schema location, DB2 obtains the XML schema by checking the schema location in turns from the first pair. In this example, namespace http://www.sample.com/customer and schema location cusotmer4.xsd are specified in the first pair. This XML schema imports namespace http://www.sample.com/company so that the imported XML schema is also obtained. In the next pair, the schema location of the namespace is http://www.sample.com/company, but its XML schema is already obtained. So this information is ignored. Therefore the value of the xsi:schemaLocation attribute below is sufficient using only the first pair, http://www.sample.com/customer and customer4.xsd.

You can validate the XML data the same way as in Listings 9 and 10.

Listing 13. customer4.xml
<?xml version="1.0"?>
<cust:customer xmlns:cust="http://www.sample.com/customer"
  xmlns:com="http://www.sample.com/company"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.sample.com/customer customer4.xsd
                      http://www.sample.com/company company4.xsd"
  type="4">
    <cust:name>cust4</cust:name>
    <cust:address>address4</cust:address>
    <cust:phone>11-2222-3333</cust:phone>
    <cust:email>cust4@sample.com</cust:email>
    <com:name>company4</com:name>
    <com:address>company-address4</com:address>
</cust:customer>

Refer to XML Schema Repository information and XML data validation information

Issue the following SQL to get the object ID, the relational ID, the schema location, and the status of registered XML schemas.

SELECT OBJECTID,OBJECTSCHEMA,OBJECTNAME,SCHEMALOCATION,STATUS FROM SYSCAT.XSROBJECTS;

The object ID in the SYSCAT.XSROBJECTS table is assigned with a new ID every time an XML schema is registered. A 'C' in the status column means complete, available to use.

When all the above XML schemas are registered, you can get the following results.

db2 => SELECT OBJECTID,
       SUBSTR(OBJECTSCHEMA,1,16) OBJECTSCHEMA,
       SUBSTR(OBJECTNAME,1,16) OBJECTNAME,
       SUBSTR(SCHEMALOCATION,1,16) SCHEMALOCATION,
       STATUS
   FROM SYSCAT.XSROBJECTS;
OBJECTID             OBJECTSCHEMA     OBJECTNAME       SCHEMALOCATION   STATUS
-------------------- ---------------- ---------------- ---------------- ------
    4785074604091136 SAMPLE           CUSTOMER1        customer1.xsd    C
    6755399441065728 SAMPLE           CUSTOMER2        customer2.xsd    C
    7881299347908352 SAMPLE           CUSTOMER3        customer3.xsd    C
    8725724278040320 SAMPLE           CUSTOMER4        customer4.xsd    C

As for a related table, there is the SYSCAT.XSROBJECTCOMPONENTS table. The table has one or multiple XML schemas associated with a relational ID. Each XML schema has its own schema location that is used for managing XML schemas inside the XML Schema Repository. It also has an object ID that is the same as one in the SYSCAT.XSROBJECTS table.

Issue the following SQL to get the object ID, the relational ID, the schema location used inside of XML Schema Repository, and the content of XML schema.

SELECT OBJECTID,OBJECTSCHEMA,OBJECTNAME,SCHEMALOCATION,
       XMLPARSE(DOCUMENT COMPONENT)
   FROM SYSCAT.XSROBJECTCOMPONENTS;

Due to width limits on this page, the following example shows all of the above information except the content of XML schema.

db2 => SELECT OBJECTID,
       SUBSTR(OBJECTSCHEMA,1,16) OBJECTSCHEMA,
       SUBSTR(OBJECTNAME,1,16) OBJECTNAME,
       SUBSTR(SCHEMALOCATION,1,16) SCHEMALOCATION
   FROM SYSCAT.XSROBJECTCOMPONENTS;

OBJECTID             OBJECTSCHEMA     OBJECTNAME       SCHEMALOCATION
-------------------- ---------------- ---------------- ----------------
    4785074604091136 SAMPLE           CUSTOMER1        customer1.xsd
    6755399441065728 SAMPLE           CUSTOMER2        customer2.xsd
    6755399441065728 SAMPLE           CUSTOMER2        company2.xsd
    7881299347908352 SAMPLE           CUSTOMER3        customer3.xsd
    8725724278040320 SAMPLE           CUSTOMER4        customer4.xsd
    8725724278040320 SAMPLE           CUSTOMER4        company4.xsd

To get the object ID of the XML schema used to validate XML data, the XMLXSROBJECTID function is used. When it is used against non-validated XML data, 0 is returned.

SELECT XMLXSROBJECTID(XMLDATA) FROM T1;

To just check whether XML data is validated or not, the IS VALIDATED predicate is used. To add options in the predicate, you can get XML data that is validated with a certain XML schema.

SELECT * FROM T1 WHERE XMLDATA IS VALIDATED;

If you want to get TRUE against validated XML data and FALSE against non-validated XML data, issue the following SQL.

SELECT ID,CASE WHEN XMLDATA IS VALIDATED THEN 'TRUE' ELSE 'FALSE' END FROM T1;

Update and validate XML data

When updating XML data, even if the updated XML data fits the XML schema, previously validated information is invalidated. If you want validation information, you need to re-validate XML data with the XMLVALIDATE function.

UPDATE T1
SET XMLDATA=XMLQUERY(
 'declare namespace cust="http://www.sample.com/customer";
  copy $new := $XMLDATA
  modify do replace value of $new/cust:customer/cust:address with "address4-2"
  return  $new')
WHERE ID = 4

The following example shows how to add an element when you update XML data. As a result, it doesn't fit to the previously validated XML schema. But the update is successful because the XML data is not validated.

UPDATE T1
SET XMLDATA=XMLQUERY(
 'declare namespace cust="http://www.sample.com/customer";
  copy $new := $XMLDATA
  modify do insert <cust:zip>1234567</cust:zip> into $new/cust:customer
  return  $new')
WHERE ID = 4

To validate the XML data, use the XMLVALIDATE function as shown below.

UPDATE T1
SET XMLDATA=XMLVALIDATE(XMLQUERY(
 'declare namespace cust="http://www.sample.com/customer";
  copy $new := $XMLDATA
  modify do insert <cust:zip>1234567</cust:zip> into $new/cust:customer
  return  $new'))
WHERE ID = 4

In this example, the validation fails. As a result, the XML data is not updated, and the following error occurs.

SQL16196N  XML document contains an element "cust:zip" that is not correctly 
specified. Reason code = "37"  SQLSTATE=2200M

Conclusion

DB2 manages XML schemas with the schema location recommended by W3C, and the relational ID introduced by DB2. W3C allows processors to decide if the schema location is used. So DB2 provides two ways to get XML schema. One is to use the schema location, the other is to ignore the schema location and use the relational ID instead. DB2 ensures uniqueness of the relational ID, and provides features to validate XML data with several XML schemas without modifying the schema location specified in the XML data.

Since DB2 also provides a way to use the schema location recommended by W3C, you can choose one according to your preference. But DB2 doesn't ensure uniqueness of the schema location. You need to manage it when you use the schema location.

In either way, you can see whether XML data is validated or not, and with which XML schema the XML data is validated.

When you update XML data, previously validated information is invalidated. You can validate XML data with the XMLVALIDATE function when you update it as well.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into XML on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=XML, Information Management
ArticleID=465603
ArticleTitle=Manage XML Schemas in DB2, Part 1: Manage XML schemas and validate XML data
publish-date=02232010