Re: [xml-dev] RE: Caution using XML Schema backward- or forward-c ompati

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

On Jan 3, 2008 11:26 AM, Michael Kay <mike@saxonica.com> 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