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

I'm not sure why we have to introduce application and purpose P.  What
you are proposing is that it's up to each "application".  This
introduces the problem of what is the application.  It could be any
given software performing a consumption event, or it could be all the
consumption events for a particular production, or it could be all the
agents that may produce or consume L1 or L2 (the "space"? Of agents).  

If you want to say it's up to each consumer, why not say

"I1 is compatible with I2 in a language specific manner such that is not
generalizable for the language, and compatibility is determined by each
consumer."

Cheers,
Dave
> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
> Sent: Monday, September 17, 2007 1:26 AM
> To: Marc de Graauw
> Cc: 'Dan Connolly'; David Orchard; 'www-tag'
> Subject: 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 12:55:58 UTC