Java Hair

If you haven’t heard William Elliott Whitmore before, you really ought to give his new album, Animals in the Dark, a listen to.  He’s an old soul in a not-so-old body with a voice that makes him sound decades older than he is.  He’s been compared to Tom Waits many a time.  His style has been described as Folk, Country, Alt-Country, Punk, and Soul.  He definitely sings with a lot of soul, has a punk attitude, and musically sounds a lot like folk, playing a lone acoustic guitar or banjo.

I just started listening to him recently, but he has been around for a while.  I haven’t had the chance to see him live yet, but hopefully sometime after he gets back from his tour in Europe I’ll be able to catch him somewhere.

Animals in the Dark is a politically charged album which is pretty self evident on tracks like “Mutiny”, “Old Devils” and “Johnny Law”.  If that isn’t your thing, don’t let that deter you, there really is some great music on this album.  If you like this one, be sure to check out “Songs of the Blackbird”, I’m not sure if I like it more than “Animals”, but it certainly has grown on me since I snagged it from the iTunes store.  That purchase, btw, marks my first purchase of music from the iTunes store, now that it isn’t DRM’d and I can use play it anywhere, I no longer have a good reason to not buy my music there.  I still am a little annoyed by the lack of mp3 support, but being able to purchase and download directly on my iPhone really seems to make up for that.

As Whitmore syas, “I don’t want to be set, I just want to be free.”

More about William Elliott Whitmore:

The Official Site

MySpace

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>[email protected]</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.