Java Hair

This is Part 3 of a 3 part series on XML Schema Design.  Check out Part 1 or Part 2.

I recently helped complete a project for a large enterprise and this series was inspired by that work and some of the questions that were raised during that process. This last part of the series covers some ways to make your schema design more flexible.

Reasons to make it more flexible were covered in Part 1, but the basic idea is adopted from evolution. If your solution is extendable and adaptable, it will encourage more people in your organization to use it., ensuring its survival. Ideally different applications within the enterprise will be able to make use of the schema without requiring an updated release of the XSD to adapt to the application’s specific needs.

Extendability

In order to achieve expandability within a single version of the schema it becomes necessary to have the types and elements within the schema allow the addition of different elements and even different attributes. This would allow a user of the schema to add their own elements to the schema without violating the schema definition and would therefore promote the schema’s use within the organization.

To provide extensibility to the schema, named complex types could have the following elements added to their definition:

<xsd:any namespace="##targetNamespace" processContents="strict" minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" />

These element definitions will render the schema invalid if there are options elements appearing before their declaration. To prevent this from being an error, add a new element to encompass those generic elements. Your final definition would look like:

   <xsd:complexType name="ExtraData">
       <xsd:sequence>

           <xsd:any namespace="##targetNamespace" processContents="strict" minOccurs="0" maxOccurs="unbounded" />
           <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
   </xsd:complexType>

The addition of these two element definitions allow for any other elements of the target namespace to be added to the type as well as any other elements from any other namespace to be added to the type. Finally to allow for any other attributes to be added the following attribute definition could be added to named complex types:

<xsd:anyAttribute namespace="##any" processContents="skip" />

A Better Approach?

This method of expandibility works but does so by allowing for almost any XML constructs to be added to XML files in that ExtraData element. This may not always be what you want. Instead, by being careful to abstract out just enough to make the schema flexible, you may be able to achieve the same thing.

For instance, consider an XML Schema that contains many different discreet data points. Let take a simple user profile type definition for instance:

   <xsd:complexType name="UserProfileType">
       <xsd:sequence>
           <xsd:element name="FirstName" type="xsd:string"></xsd:element>
           <xsd:element name="LastName" type="xsd:string"></xsd:element>
           <xsd:element name="AccountCreated" type="xsd:dateTime"></xsd:element>
       </xsd:sequence>
       <xsd:attribute name="userId" type="xsd:string"/>
   </xsd:complexType>

An example of an instance of an XML document that is validates against this schema definition might be:

  <Profile userid="rjava">
     <FirstName>Rob</FirstName>
     <LastName>Java</LastName>
     <AccountCreated>2009-05-26T09:00:00</AccountCreated>
  </Profile>

This might work fine for a while, but what happens when you want to keep track of the last time the user accessed the site? You would have to change the schema definition. The solution discussed above would work, but what if we create a generic data type:

   <xsd:complexType name="DataType">
       <xsd:sequence>
           <xsd:element name="Description" type="xsd:string" minOccurs="0"/>
           <xsd:element name="StringValue" type="xsd:string" minOccurs="0"/>
           <xsd:element name="DateValue" type="xsd:dateTime" minOccurs="0"/>
       </xsd:sequence>
       <xsd:attribute name="name" type="xsd:string" />
   </xsd:complexType>

We could use this generic data type inside our UserProfileType:

   <xsd:complexType name="UserProfileType">
       <xsd:sequence>
           <xsd:element name="Data" type="tns:DataType" minOccurs="0" maxOccurs="unbounded"></xsd:element>
       </xsd:sequence>
       <xsd:attribute name="userId" type="xsd:string"/>
   </xsd:complexType>

We could now represent the same data using an XML document like this:

  <Profile userid="rjava">
     <Data name="FirstName">
        <StringValue>Rob</StringValue>
     </Data>
     <Data name="LastName">
        <StringValue>Java</StringValue>
     </Data>
     <Data name="AccountCreated">
        <DateValue>2009-05-26T09:00:00</DateValue>
     </Data>
     <Data name="Email">
        <StringValue>rob@java-hair.com</StringValue>
     </Data>
  </Profile>

So now we have made the UserProfileType very fluid, maybe too fluid depending on what you want to accomplish.  It is exapandable simply by adding whatever instances of Data into the UserProfileType element in your XML Document, but it doesn’t require any fields or even suggest any.  A better use may be to combine the first two examples.  That way you could enforce the required fields and make optional some of the more common fields, but still leave room for other elements that new applications may require.

Conclusion

It is very important that the Canonical XML Schema be as easy as possible to understand while still maintaining re usability and flexibility.  A Canonical XML Schema is only going to be as good as it’s user-base is large.  There isn’t much point in investing in one if the organization as a whole is not going to adopt it.

Hopefully this series of articles has given you some ideas on how to design an XML Schema that your organization can make use of.  Getting the business as a whole to adopt something like this isn’t going to be easy, especially if you don’t have an immediate need for one.  My suggestion would be to start small, start with new applications that requires an XML Schema.  Prove the value in a proper enterprise-wide design by showing how the time and effort for enhancements and changes can be reduced and you will go a long way it getting it adopted.

Related posts:

1. XML Schema Design: Part 2 Now that we’ve gotten the whats and whys out of...
2. XML Schema Design: Part 1 Introduction This post and the posts that follow are to...
3. NetBeans - Working with XML Schemas Lately I have been doing a lot of work with...
4. Inserting Text into an Oracle Database Schema: ORA-01461 Today I ran into an interesting problem. A portion of...

You must be logged in to post a comment.