[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Fwd: Data versioning strategy: address semantic, relations

• From: noah_mendelsohn@u...
• To: "Greg Hunt" <greg@f...>
• Date: Thu, 13 Dec 2007 16:49:01 -0500

Greg Hunt writes:

> The real question is how do we identify breaking and non-breaking 
changes?

Exactly.  Furthermore, breaking/non-breaking is a function of at least: a) 
the verison of the specification the author had in mind when authoring a 
document b) the version of the specification the receiver had in mind when 
interpreting the document and crucially c) the particular purpose for 
which the document is being read.  I think about it roughly this way: with 
a document in my left hand and a specification for some version of the 
language, I can draw some conclusions.  Perhaps the document has a single 
character, a "0", "1" or "2", and the specification says "0" means the 
traffic light is green, "1" is for yellow, and "2" is red.  If I now hand 
you the document, and you interpret it using version 2 of the 
specification, and if that version assigns the colors differently "0"=red, 
1="green", 2="yellow" then in this simple case you will clearly conclude 
the traffic light has a different color than I intended.  Presuming you're 
interested in the color of the light at all, that's almost surely a 
breaking change in the spec.

Now lets consider an example I've used often.  You send me a purchase 
order.  There's a large specification which provides for items to be 
purchased, shipping addresses, etc., and also a place for a phone number 
to call you back only if there's trouble with the order.  We assume 
version 1 of the specification provides for the phone number, but leaves 
out a country code.  In early use, it becomes clear that orders are being 
made internationally, so version 2 allows a country code to be prepended 
in a way that's identifiable (perhaps with a <countryCode> xml element, 
but anything that's identifiable will do). 

Question, are you exploiting a breaking change if you send me a purchase 
order with a country code in the phone number, and I have only the v1 
specification?  Well a simple answer would be "yes", I'm going to wind up 
misinterpreting the phone number if, for example, I ignore the country 
code.  So, I shouldn't place the order because we've hit a breaking 
change?  That's not clear at all.  I can imagine many business scenarios 
in which what I'd want to do would be:

* Place the order.
* Store the entire purchase order, including the country code (which I 
really don't understand, but I see it's there) in any database that logs 
the PO
* Pass the entire order with the CC downstream if someone else needs it.
* If someone asks for a printout of the purchase order, print it all, and 
include the information from the country code with the phone number, 
indicating that its significance could not be determined
* If the order fails and I want to dial the phone number, signal a 
breaking change, because I really can't just dial the part of the phone 
number I understand.

So, this second example is an illustration of point (c) above.  Whether 
there's a breaking change is not just a function of the two versions of 
the specifications, and the particular features used in an instance 
document:  it's very particular to the exact purpose for which you're 
processing. In any given use, much of the information from a document may 
be ignored, and if you can isolate the impact of the parts that aren't 
understood, you may be able to (and may for businees reasons need to) 
proceed. 

Systems like XML schema can help you sort out what's truly expected from 
what's tolerated but not completely understood (e.g. the country code) 
from what should be completely rejected (I was expecting a purchase order 
but I got someone's medical record).  I don't think it can or should be 
asked to drive the application-level decision as to what is needed in a 
particular case.   The same document interpreted per the same two versions 
may or may not embody a breaking change depending on the application's 
needs.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

• References:
  • Fwd: Data versioning strategy: address semantic, relationship, and syntactic changes?
    • From: "Greg Hunt" <greg@f...>