Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] RE: Caution using XML Schema backward- or forward-c ompatibility as a versioning strategy for data exchange

From: "bryan rasmussen" <rasmussen.bryan@-----.--->
To: "Michael Kay" <mike@--------.--->
Date: 1/3/2008 5:58:00 PM
On Jan 3, 2008 11:26 AM, Michael Kay <mike@s...> wrote:

> Actually, I really liked it because it's the kind of thing that happens all
> the time. Or more likely, in version 1 there's no clear definition of what
> <distance> means, and different parts of the user community start
> interpreting it in different ways; then version 2 clarifies the meaning, and
> some parts of the user community find that their previous interpretation is
> no longer valid.
I agree the more likely one happens all the time, and variations of
that. The problem described also happens all the time but only in my
experience if there is a versioning rule for input data or something
whereby the system can differentiate between the two forms of data and
branch their processing dependent on said rule. I felt this:

"
The client application will be able to validate the version 2 data, but
the calculations will be incorrect."

implied that there isn't a particular versioning strategy applied to
the data, the only thing described in the data exchange is that the
semantics of one element has changed. I don't think that really
happens, that takes things to a whole other level of difficulty - to a
level that would be described as basically impossible to handle. I
suppose of course others felt the versioning of the data was implicit
in the example? But the way I read it was that there was a versioning
strategy for validation but not for input data, that struck me as
weird given the example.


So to sum up: If a change like the described one happened I would
expect some other way of describing in the input data format that this
was a new version or it would be apocalyptic to data purity. If that
is the actual only change to data exchanged on a webservice we would
never be able to tell what the distance element meant.


>
> Have you never experienced a change in procedures for expense claims where
> version 1 allowed you to claim for travel between two company sites based on
> the shortest route, and version 2 allowed you to claim based on the mileage
> of the fastest route, but the data sheets giving the distances between
> company locations weren't actually updated? If you think that's apocalyptic,
> you've worked in very well organised companies.
>
>
Companies aren't quite as loosely connected clients and web services,
and even in situations that this happens there has in my experience
been a way to tell if someone in some far off office has sent in the
wrong expense claim by mistake - that is to say versioning of the
input data.

It is true that different input versions can, if the versioning
strategy for the data or the implementation of that strategy is not
good enough, be misinterpreted as another version but that is a
different kind of problem than it being absolutely impossible to tell
what version is being sent.


Cheers,
Bryan Rasmussen


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent