Problem with Version #s

| | Comments (0)

There are some fundamental problems with version numbers. In this entry, I'll examine the problem that introducing a vocabulary specific version number means that general XML tools can稚 be used with the vocabulary.

Let痴 take a look at comparing a vocabulary that has 2 different innovations. One extension is an incompatible change, and another is a compatible change.

V1 of a name language has a first name, ie

<first>dave</first>

A required last name is added and made into V2:

<first>dave</first>
<last>orchard</last>

An optional middle name is added to both to form a .1 version for each,
V1.1

<first>dave</first>
<middle>bryce</middle>

V2.1

<first>dave</first>
<middle>bryce</middle>
<last>orchard</last>

Now imagine that the vocabulary uses version numbers without changing the namespace name. The V 1.1 and V 2.1 instances will look like:

<ns1:name ns1:version=�1.1� xmlns:ns1=杷oo/v1�>
<ns1:first>dave</ns1:first>
<ns1:middle>bryce</ns1:middle>
</ns1:name>

<ns1:name ns1:version=�2.1� xmlns:ns1=杷oo/v1�>
<ns1:first>dave</ns1:first>
<ns1:middle>bryce</ns1:middle>
<ns1:last>orchard</ns1:last>
</ns1:name>

If I知 generating some Java code based upon the related schemas. I値l have 2 schemas for the same namespace name. Somehow, I値l have to look at the version number to figure out whether it痴 a v1.1 or v2.1 name Java class. Maybe the version number will be a fixed string and the code will have to look for the ns1:version and then use that in the java package name or class name, ie com.pacificspirit.name.v21. When my Java code is binding the instance of name to Java, I have to figure out at run time which version it is, and then look up the Java version based upon the version number.

The generation of the Java code and the binding into Java has to be Name specific and generic tools can稚 work correctly with the type information.

Now compare that with using namespaces for these, and following the rules that say that compatible extensions (in this case the addition of the middle name) don't require a new namespace name.

<ns1:name xmlns:ns1=杷oo/v1�>
<ns1:first>dave</ns1:first>
<ns1:middle>bryce</ns1:middle>
</ns1:name>

<ns2:name xmlns:ns2=杷oo/v2�>
<ns2:first>dave</ns2:first>
<ns2:middle>bryce</ns2:middle>
<ns2:last>orchard</ns2:last>
</ns2:name>

Now the code to associate the schema for ns1 and ns2 and the binding of data between the generated Java code either ns1 or ns2 is generic to XML namespaces. No special name specific version attribute and triggering off of that.

It would be different if we had an "xml:version" attribute that was usable across all vocabularies. But we don't. And experience trying to get xml:id or xml:mustUnderstand say that we won't ever get it either.

Developers should use the standardized versioning tool that xml brings to the table, that is namespace names and names.

Leave a comment

About this Entry

This page contains a single entry by Dave Orchard published on September 2, 2004 11:02 AM.

Dave's guide to MP3s was the previous entry in this blog.

Profiling Schema in WS-I is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Categories