Introduction

IBM ® WebSphere® Studio Application Developer is an application development product that supports the building of a large spectrum of applications using different technologies, such as JSPs, servlets, HTML, XML, Web services, databases, and EJBs. In particular, Application Developer provides tight integration between XML and relational data. Application Developer supports all of the databases that WebSphere Application Server supports, including DB2®, Oracle Sybase, and Microsoft® SQL Server^TM.

This is Part 6 of a series of articles focusing on the XML tools provided with WebSphere Studio Application Developer. Part 6 demonstrates how to use the XML Schema Editor and the XML Editor together to develop XML applications that make use of XML namespaces.

We recommend that you read the other articles in this series:

• Part 1 Learn how to use Application Developer to develop XML Schema.
• Part 2 Learn how to create an SQL query using Application Developer's SQL Builder.
• Part 3 Learn about the Application Developer features available to incorporate data access and XML in your application.
• Part 4 Learn how to use the XML Editor, a visual tool for creating and editing XML documents.
• Part 5 Learn how to use the RDB to XML Mapping Editor to create DAD files for use with DB2 XML Extender. make use of XML namespaces.

Back to top

Back to top

Why we need XML namespace

Since everyone is able to create their own XML elements and attributes for use in their problem domain, we need a way to distinguish between elements that have the same name but come from a different problem domain. For example, a PurchaseOrder might be coming from two different companies; in this case, we can use the XML namespace mechanism to distinguish between them.

The XML Namespace specification was published in early 1999 long before the XML Schema specification. At that time, it was not possible to validate a namespace-aware XML document using DTD since there was no standard way of constructing a namespace in DTDs. This situation changed when XML Schema was introduced in May 2001 since XML Schema supports namespaces. A validating parser such as Xerces2 can validate instance documents that use namespaces against the XML Schema document.

Back to top

XML namespaces by examples

The best way to explain all of the namespace concepts is through the use of examples. We will examine the following namespace topics using a series of examples.

• Unqualified local elements versus qualified local elements
• Schema with no target namespace
• Schema whose target namespace is the default namespace
• Multiple schemas and multiple namespaces

Using the XML Schema Editor, you can either create or import the following Course.xsd schema file. The target namespace for this schema is http://www.utoronto.ca. This means that all types defined in this schema belong to the target namespace http://www.utoronto.ca, and they can be referenced using the prefix course in this schema.

<schema xmlns="http://www.w3.org/2001/XMLSchema" 

   targetNamespace="http://www.utoronto.ca" 

   xmlns:course="http://www.utoronto.ca">

   <element name="Schedule">

      <complexType>

         <sequence>

            <element name="course" type="course:CourseInfo"/>

            <element name="location" type="string"/>

         </sequence>

      </complexType>

   </element>

   <complexType name="CourseInfo">

      <sequence>

         <element name="courseId" type="string"/>

         <element name="description" type="string"/>

      </sequence>

   </complexType>

</schema>

Unqualified local elements

To create an instance document that conforms to the Course.xsd schema file, select the Course.xsd file, and then select Generate => XML File to launch the Create XML File wizard. Click Next. On the Select Root Element page, check the Create required and optional content option to create an XML document with the required elements, as shown in Figure 1 below. Notice that the target namespace and prefix from the XML schema file is automatically picked up when creating the instance document. When you click Finish, the Course.xml file (see Listing 2 below) will be automatically created.

<course:Schedule xmlns:course="http://www.utoronto.ca"  
 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
 
   xsi:schemaLocation="http://www.utoronto.ca Course.xsd ">    
 
   <course> 
 
      <courseId>courseId</courseId> 
 
      <description>description</description> 
 
   </course> 
 
   <location>location</location> 
 
</course:Schedule>

Let's review the Course.xml file. First, the root element Schedule is qualified (that is, course:Schedule) to belong to the namespace http://www.utoronto.ca. This allows us to distinguish between the courses that are offered by the University of Toronto and courses offered by other universities. Second, all of the local elements are unqualified. That is, the local elements such as course, courseId, description, and location do not have a prefix. This is because the Course.xsd schema file specifies that local elements should not be qualified. You might be thinking that this can be quite confusing for an instance author to determine what needs to be qualified and what doesn't need to be qualified. The next section shows you how to make every element qualified in an instance document.

Qualified local elements

To qualify all of the local elements in the XML instance document, the XML Schema author must set the elementFormDefault attribute to qualified in the schema element. This can be accomplished by selecting qualified in the Element form default field of the Design view for the Course.xsd schema object, as shown in Figure 2 below.

This will cause the elementFormDefault attribute to be added and set to qualified in the schema tag.

<schema xmlns="http://www.w3.org/2001/XMLSchema"  
 
   targetNamespace="http://www.utoronto.ca"  
 
   xmlns:course="http://www.utoronto.ca" elementFormDefault="qualified">

Now, save the Course.xsd file and invoke the Create XML File wizard again. The Course.xml file, as shown in Listing 3 below, will be generated. Notice that all of the elements (global and locals) are qualified with the prefix course.

<course:Schedule xmlns:course="http://www.utoronto.ca"  
 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
 
   xsi:schemaLocation="http://www.utoronto.ca Course.xsd ">     
 
   <course:course> 
 
      <course:courseId>courseId</course:courseId> 
 
      <course:description>description</course:description> 
 
   </course:course> 
 
   <course:location>location</course:location> 
 
</course:Schedule>

Schema with no target namespace

Using the XML Schema Editor, you can either create or import the following Course1.xsd schema file. The Course1.xsd schema does not belong to a namespace as indicated by the absence of the targetNamespace attribute in the schema tag.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
 
   <xsd:element name="Schedule"> 
 
      <xsd:complexType> 
 
         <xsd:sequence> 
 
            <xsd:element name="course" type="CourseInfo"/> 
 
            <xsd:element name="location" type="xsd:string"/> 
 
         </xsd:sequence> 
 
      </xsd:complexType> 
 
   </xsd:element> 
 
 
 
   <xsd:complexType name="CourseInfo"> 
 
      <xsd:sequence> 
 
         <xsd:element name="courseId" type="xsd:string"/> 
 
         <xsd:element name="description" type="xsd:string"/> 
 
      </xsd:sequence> 
 
   </xsd:complexType>     
 
</xsd:schema>

Notice how type definitions from this schema are not referenced with a prefix. For example, the CourseInfo complex type is referenced as CourseInfo in the element course without a prefix. To distinguish XML Schema elements (for example, complexType, string, etc.) from the user-defined elements in schema that does not belong to a namespace, we follow the W3C recommendation to explicitly qualify XML Schema elements with a prefix such as xsd in this case.

To generate the instance document, invoke the Generate XML File wizard on the Course1.xsd file. Notice how the namespace and prefix fields are empty. When you click Finish, the Course1.xml file that is shown in Listing 5 will be generated.

 <Schedule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
 
   xsi:noNamespaceSchemaLocation="Course1.xsd">      
 
   <course> 
 
      <courseId>courseId</courseId> 
 
      <description>description</description> 
 
   </course> 
 
   <location>location</location> 
 
</Schedule>

Let's review the Course1.xml file. First, notice the xsi:noNamespaceSchemaLocation attribute that is added in the root element (as opposed to the xsi:schemaLocation attribute). This attribute is used to provide hints for the location of the schema document that do not have namespace. As a result, this instance document can still be validated against the corresponding schema. Second, notice that all of the elements (global and local) are not qualified. In fact, this document looks more like a traditional XML document that does not use namespace.

In summary, this pattern is useful if you want to make your instance document prefix-free and yet validate it against an XML Schema instead of a DTD. However, this pattern will be quite confusing if you intend to publish your schema for reuse by other schemas as it can result in potential name conflicts from another vocabulary.

Schema whose target namespace is the default namespace

Using the XML Schema Editor, you can either create or import the following Course2.xsd schema file.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"  
 
   targetNamespace="http://www.utoronto.ca"  
 
   xmlns="http://www.utoronto.ca"> 
 
   <xsd:element name="Schedule"> 
 
      <xsd:complexType> 
 
         <xsd:sequence> 
 
            <xsd:element name="course" type="CourseInfo"></xsd:element> 
 
            <xsd:element name="location" type="xsd:string"></xsd:element> 
 
         </xsd:sequence> 
 
      </xsd:complexType> 
 
  </xsd:element> 
 
 
 
  <xsd:complexType name="CourseInfo"> 
 
     <xsd:sequence> 
 
        <xsd:element name="courseId" type="xsd:string"></xsd:element> 
 
        <xsd:element name="description" type="xsd:string"></xsd:element> 
 
     </xsd:sequence> 
 
  </xsd:complexType> 
 
</xsd:schema>

The target namespace for this schema is http://www.utoronto.ca as indicated by the targetNamespace attribute. We make the default namespace for this schema to be the same as the target namespace by not specifying a prefix in the Prefix field for the schema object.

When you click the Apply button, you will notice that the xmlns attribute is added to the schema tag to indicate that the default namespace of this schema is http://www.utoronto.ca. You will also notice that the XML Schema constructs will automatically be qualified with the prefix xsd (this prefix can be changed from the XML Schema Preference page) to distinguish them from the types (for example, Schedule) that are in the default namespace.

By making the target namespace of this schema the default namespace, we do not have to qualify types from this schema when we reference them (for example, CourseInfo does not need to be qualified). Compare Course2.xsd to Course.xsd to make sure you see the differences.

To generate the instance document, invoke the Generate XML File wizard on the Course2.xsd file. Notice how the prefix field is empty and an error message appears to indicate that a prefix is missing. Click the Edit button to launch the New Namespace Information dialog (see Figure 4 below). Enter a prefix such as course. When you click Finish, the Course2.xml file will be generated and it should resemble the Course.xml file in Listing 2.

Multiple schemas and multiple namespaces

As schemas become larger, it is often desirable to divide the schema up into smaller schemas so that it is easier to maintain and reuse. It is also quite common to borrow schemas that are developed by standard bodies such as the W3C. In this section, we will look at how to use constructs from multiple schemas when creating a schema in the XML Schema Editor. We will also examine the implications on multiple namespaces in the instance document.

Before you begin, make sure you download the namespace.zip file provided below, and extract the Calendar/Course.xsd and Calendar/Job.xsd into your current project.

Step 1. Create the Calendar.xsd file

Create the Calendar.xsd schema file in your current project using the Create XML Schema wizard. You should be very familiar with this step by now.

Step 2. Import the Course.xsd and Job.xsd schema files

In the Outline view, click on the Calendar file object and select Add Import from the pop-up menu. This will create a new import element object in the outline view.

Click on the import object. In the Design view of the Schedule.xsd schema object, use the Select button to invoke the Select XML Schema file wizard. Choose the Select schema from Workbench projects option. Click Next and choose the Course.xsd schema file. This will import the definitions from the Course.xsd file so that we can use them later. In addition, it will also retrieve the namespace and the namespace prefix for Course.xsd. The result is shown in Figure 5 below.

Switch over to the Source view to review the source. You will notice that an xmlns:course attribute is automatically generated for you in the schema element in addition to the import element for Course.xsd.

<schema xmlns="http://www.w3.org/2001/XMLSchema"  
 
   targetNamespace="http://www.ibm.com"  
 
   xmlns:Calendar="http://www.ibm.com"  
 
   xmlns:course="http://www.utoronto.ca">

Now, repeat the steps above to add an import element for the Job.xsd file.

Step 3. Add an appointment

We will create an appointment in the Calendar schema. The appointment will contain the list of courses and jobs that make up our daily routine.

1. In the Outline view, add a global element appointment, and specify its type to be an anonymous complex type.
2. Click on the anonymous type, and select Add Content Model. Change the content model from sequence to choice in the Design View. Also, set the Minimum field to 0, and the Maximum field to unbounded.
3. Select the choice element and choose Add Element Ref to add an element reference. In the Reference name field, notice how course:Schedule is available as a choice. This is because we have imported the definitions from the Course.xsd file in Step 2. Select course:Schedule as the element we want to reference.
4. Select the choice element again and choose Add Element Ref to add an element reference. In the Reference name field, notice how Job:JobInfo is available as a choice. This is because we have imported the definitions from the Job.xsd file in Step 2. Select Job:JobInfo as the element we want to reference.
5. Add two attributes, startTime and endTime, to this complex type.

The completed Calendar.xsd schema is shown in Figure 6 below.

Step 4. Generate the Calendar.xml file

To generate an instance document that conforms to Calendar.xsd, once again, invoke the Generate XML File wizard on the Calendar.xsd file. This instance document will be using three schemas from three different namespaces. Notice how this is automatically detected for you in the Select Root Element page. When you click Finish, a valid Calendar.xml file will be generated for you.

Step 5. Edit the Calendar.xml file using the XML Editor

Open the Calendar.xml file in the XML Editor. In the Design view, you can quickly visualize the namespace attribute values (for example, xmlns:Calendar, xmlns:Job, xmlns:course) under the root element Calendar:appointment. For validation to work, the xsi:schemaLocation attribute must include hints to point to the corresponding schemas, as indicated in Figure 8 below.

In Part 4 of this series, we discussed how the XML Editor provides guided editing using an XML Schema or a DTD. Such guided editing is also sensitive to namespaces. For example, when you bring up the pop-up menu on the Calendar:appointment element, you will notice that Add Child will let you select either course:Schedule or Job:JobInfo to add to the appointment element. This is shown in Figure 9 below.

Back to top

Summary

This article provides an overview of common XML namespace patterns and demonstrates how you can use WebSphere Studio Application Developer's XML tools to design your XML Schema and XML instance document. As discussed in this article, the XML Schema author's choice of namespace and qualifications for the schema document has a number of implications to the structure in the instance document. The generation capability in the XML tools lets you quickly change your XML Schema and generate your instance document to ensure that you have the right schema design.

Back to top

Download

Name	Size	Download method
namespace.zip	8 KB	FTP|HTTP

Information about download methods

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Why we need XML namespace
• XML namespaces by examples
• Summary
• Download
• About the author
• Comments

Next steps from IBM

With the no-charge DB2 Express-C, pureXML and evolving your XML schemas you can easily increase development and application performance.

---

• Try: Download a free trial version of DB2 Express-C, which includes pureXML technology that is ideally suited for managing XML schema and relational data.
• Article: See how to use DB2's pureXML schema evolution capabilities, that evolve schemas without making any changes to your applications.
• Tutorial: This tutorial shows you how using a native DB2 XML database enables changes in an existing XML schema to also appear in your application code.
• Demo: This demo shows you how easy it is to create a DB2 database for storing XML data.
• Buy: DB2 9 for Linux, UNIX and Windows

My developerWorks community

Dig deeper into WebSphere on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers