RE: definition of forward compatible/backward compatible still an open problem [XMLVersioning-41 ISSUE-41]

Marc:

First a caveat:  I'm working disconnected right now, and thus can't follow 
the link to your reformulation.  In your email, you wrote:

> | Can we weaken the definition and effectively say it's language
> | dependent? 
> | 
> | "I1 is compatible with I2 in a language specific manner such 
> | that is not
> | generalizable."
> 
> I don't know if this is a good idea - often language specs do not 
contain
> formalisms to establish compatibility, so wouldn't this leave 
compatibility
> undefined?

Implicit in this is that the only sorts of compatibility that matter are 
those the are defined by formalisms.  Clearly there are advantages when 
relationships can be expressed formally.  There are also sometimes 
disadvantages, such as the need to prepare the formalism.  I would expect 
users of the Web to evolve languages that range from some that are (or 
should be) very rigorously defined, to others that are very informally 
defined.  My intuition is that the finding would ultimately be stronger, 
not weaker, if it could give guidance that would apply to a wide range of 
languages.

I've been toying in my mind with formulations along the lines of:

Let Info = Mapping(Instance, L1)   define represent the Information that 
can be gleaned from a given instance per language L.

"Language L1 is (backward/forward) compatible with L2 for purpose  P iff: 
for each instance in L1, then I1 = Mapping(instance, L1) is sufficiently 
consistent with I2= Mapping(instance,L2) to meet the needs of application 
P."

So, lets say I have a purchase order language with a callback number in 
case of trouble with the order.  The way this would play out is:  for the 
application that's checking whether inventory is in stock, a failure to 
faithfully convey the phone number might be viewed as not inconsistent for 
purposes of the application.  If the application is going to dial the 
phone, then anything other than a faithful rendering of the phone number 
might be viewed as insufficiently consistent.

In short this is delegating to the specifications of particular languages 
and/or applications the choice of whether or not to be very formal in 
defining consistency.  Nothing in the above prohibits one from using very 
formal and rigorous approaches.  Then again, if I'm just defining a 
language to convey soccer scores for an elementary school team, I might 
reason through the issues informally, yet still benefit from the approach 
suggested in the finding.

I'm not sure this is right, which is why I haven't proposed it before, but 
it's been my leaning for awhile, and your note prompted me to go public. 
Thank you!

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

Received on Monday, 17 September 2007 08:26:56 UTC