Mmmm, the first post using Performancing did not go as well as I hoped. The title of the blog entry did not make it to the blog. This time I selected the MetaWeblog API as the API to be used to submit new entries to the blog (used blogger API in previous post), let's see if the title shows up now...

Till now I've been using the standard web based interface of Pebble to post entries to my Blog. Wilfred mentioned Performancing as a blog client that runs in Firefox 1.5 and can can work offline. I must say, the first impression is good... if this post ends on on my blog of course... I'll hit the publish button now!

After doing a couple of architect and design projects in which the OSS/J Service Activation API played a role, this week we had to actually define a couple of extensions to the OSS/J Service Activation XML Schema's. You learn something new everytime you do something for the first time...

The core of the problem was that we had to define and use subtypes of the abstract orderValue type which is defined in the OSS/J SA spec. Defining the sub types was not the problem, that was done in a breeze. Using them in an XML document appeared to be a challenge. This was mainly caused by the fact that the abstract orderValue is used as a element in for example createOrderByValueRequest. Some snippets might clarify the issue:

The definition of the createOrderByValueRequest is as follows:

<element name="createOrderByValueRequest">
  <complexType>
    <sequence>
      <element name="orderValue" type="sa:OrderValue"/>
    </sequence>
  </complexType>
</element>
orderValue is defined as:
<complexType name="OrderValue" abstract="true">
  <complexContent>
    <extension base="co:ManagedEntityValue">
      <sequence>
        <!-- SNIP -->
      </sequence>
    </extension>
  </complexContent>
</complexType>

Our extension to orderValue is:
<complexType name="CustomOrderValue">
  <complexContent>
    <extension base="sa:OrderValue">
      <sequence>
        <element name="somefield" type="string"/>
      </sequence>
    </extension>
  </complexContent>
</complexType>

Our initial attempt to use CustomOrder as part of createOrderByValueRequest was as follows:

<?xml version="1.0" encoding="UTF-8"?>
<sa:createOrderByValueRequest 
  xmlns="http://xyz.com/ServiceActivation"
  xmlns:co="http://java.sun.com/products/oss/xml/Common"
  xmlns:sa="http://java.sun.com/products/oss/xml/ServiceActivation"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  xsi:schemaLocation="http://xyz.com/ServiceActivation XmlXYZServiceActivation.xsd"
  >
  <CustomOrderValue>
    <co:lastUpdateVersionNumber>1</co:lastUpdateVersionNumber>  
    <!-- SNIP -->
    <someField>bla</someField>
  </CreateVASOrderValue>
</sa:createOrderByValueRequest>
This did not work since the definition of createOrderbyValueRequest dictates that a orderValue is expected as the only subelement. Aside from that, the validator is also not able to resolve the sa:createOrderByValueRequest. We assumed this would be resolved by the xsi:schemaLocation attribute that points to the XmlXYZServiceActivation.xsd schema file which includes the imports the XmlServiceActivationSchema.xsd file containing the OSS/J SA schema.

Mmm, now what... I'll leave all the failed attempts out, but this is what worked. The changes we had to make are:

  • The xsi:schemaLocation attribute of the sa:createOrderByValueRequest now points to the OSS/J SA schema instead of our custom schema. Now the sa:createOrderByValueRequest is resolved.
  • The sub element of sa:createOrderByValueRequest now is a sa:orderValue, but using the xsi:type attribute the validator is hinted that the actual element is the CustomOrderValue sub type of the abstract OrderValue.
  • The previous point was not enough to actually resolve the CustomOrder type. In order to get that resolved an xsi:schemaLocation attribute that points to our custom schema file.
<?xml version="1.0" encoding="UTF-8"?>
<sa:createOrderByValueRequest 
  xmlns="http://xyz.com/ServiceActivation"
  xmlns:co="http://java.sun.com/products/oss/xml/Common"
  xmlns:sa="http://java.sun.com/products/oss/xml/ServiceActivation"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  xsi:schemaLocation="http://java.sun.com/products/oss/xml/ServiceActivation XmlServiceActivationSchema.xsd"
  >
  <sa:orderValue xsi:type="CustomOrderValue" xsi:schemaLocation="http://xyz.com/ServiceActivation XmlXYZServiceActivation.xsd">
    <co:lastUpdateVersionNumber>1</co:lastUpdateVersionNumber>  
    <!-- SNIP -->
    <someField>bla</someField>
  </sa:orderValue>
</sa:createOrderByValueRequest>

Sound fine, problem resolved... however, is this The Way to tackle this problem? XML Schema seems to provide various options to tackle this problem and I'm not sure yet if this is the best way. One alternative we considered was to redefine the createOrderByValueRequest element in our custom schema, but that would in practice imply that we would be redefining the whole OSS/J SA schema in order to extend it. That's definitily not how it's intended to be. Any other options?