WebServices dot org

How Much Do I ‘Ignore’ Thee? Let Me Count the Ways...

We here at BEA have been evangelizing a model of versioning called the "Must Ignore Unknown" rule for a while now - as described in our versioning article . It roughly means that any extra content that isn't known is ignored, and specifically no error is generated. This works very well in the Web model because the browser ignores any extra markup. The human reader won't ever see the extra content.

This works very well when the software doing the 'ignoring' is the last piece of software looking at the data. However, in many applications, the software that gets an extension isn't the last piece looking at the data. What does it mean for it to ignore the extra content? Should it throw it away? Should it keep it but not fault?

I'll call these two models the "Ignore and Discard" and "Ignore but Retain" models. The application designer must choose which of the Ignore models to implement, and there are pros and cons to each. The Discard model has the advantage that it may be simpler to implement and gives at least a simple versioning story. But the Retain model enables the XML application to be evolved in further interesting ways.

Let's explore the Retain model with the much-used name example. An XML application receives names with given and family names. A client extends the name structure and adds a middle name. The decision about discarding versus retaining depends on what the application does. If it forwards the message, it may be as simple as just keeping the extra content in the message.

One flavor of this extension is adding the extension at the end, if the schema allows:

<name xmlns="http://www.openuri.org/name/1">

   <given>Dave</given>

   <family>Orchard</family>

   <middle>Bryce</middle>

</name>

Alternatively, using the "extension element mechanism" outlined in the earlier article,

<name xmlns="http://www.openuri.org/name/1">

   <given>Dave</given>

   <family>Orchard</family>

   <extension>

      <middle>Bryce</middle>

   </extension>

</name>

If the model stores the data and possibly returns the data for different requests, then there are some interesting designs that are available for retaining the data. Imagine that the family and given names are columns in a table. The middle name extension could be stored in an extra "extensions" column in the table. That way, whenever the name is returned it can create a name with the family, given and middle name in it:

Family   Given    Extension

Orchard  David    <middle>Bryce</middle>

By retaining the data, then the XML application can be evolved in further interesting ways. If it is versioned to "understand" middle names including adding a middle column, then it is possible to move all the middle names out of the extensions column and into the middle column.

Family   Given    Middle     Extension

Orchard  David    Bryce

There are a few tricky parts in this architecture. Multiple extensions are possible, each of them needing to be stored. Order in returning the XML when it is still unknown might be important, so retaining some notion of the order of the extensions may be required. This could be accomplished by specifying an order for the extension. Another option is to retain the entire document in raw form, such as

Family   Given     raw

Orchard  David   <given>David<given> <family>Orchard</family>

                 <middle>Bryce</middle>

There are obvious downsides such as space, duplication and complexity in this model, but it does safely preserve all extensions and their order.

Language designers that have designed their systems for extensibility and versioning will usually have a flavor of the Must Ignore Unknown rule. It's simply a question of what flavor of 'Ignoring' to use.