Re: Are EPRs identifiers?

Hi Mark,

It is a pity you missed the discussion we had yesterday at the f2f in
Redmond. The case was made (by Jeff M.) that to have identifier semantics
you need to provide a mechanism that will allow you to decide if two such
identifiers identify the same entity or not; that is a Boolean valued
function essentially which will return true or false given a pair of those
identifiers. This is old news for those familiar with distributed system
design of course. The spec does not have such a thing because it follows
the semantics you agreed with below: it allows you to return "true" (in
fact, only wrt the metadata that applies to the interaction, but let's not
get into that one now) if you get a byte per byte match of selected fields,
but you can never get a false answer. This is why EPRs do not have
identifier semantics.

Paco



                                                                                                                                               
                      Mark Baker                                                                                                               
                      <distobj@acm.org>               To:       Francisco Curbera/Watson/IBM@IBMUS                                             
                      Sent by:                        cc:       public-ws-addressing@w3.org                                                    
                      public-ws-addressing-req        Subject:  Re: Are EPRs identifiers?                                                      
                      uest@w3.org                                                                                                              
                                                                                                                                               
                                                                                                                                               
                      12/09/2004 04:31 PM                                                                                                      
                                                                                                                                               





Paco,

On Thu, Dec 09, 2004 at 10:01:30AM -0500, Francisco Curbera wrote:
> So I think by now everyone agrees on this: when the address or reference
> props. are different then:
>
> - the metadata may or may not be different,
>
> - they EPRs may or may not "point to/reference" different
> entities/endpoints/resources/thingies/whatever.
>
> That is, out of a negative byte by byte comparison you cannot infer
> anything at all (so you may be better off retrieving fresh copy of the
> metadata, for example.) I think we should at least make this crystal
clear
> in the spec, since it has taken a bunch of smart guys like us a while to
> figure it out.

+1

> If after this realization the group still wants to call EPRs identifiers
> then need to understand we will be endorsing a very ad-hoc notion of
> "identifier". This would be a gross mistake IMO: attaching new meaning to
> concepts already in use, can only result in confusion - of the general
> public as well much as the TAG itself.

Whoa, really?  How does the above justify such a conclusion?  I can't
see it.  If you're assuming that identifiers don't demonstrate those
characteristics you describe, I think you're mistaken, as the evidence
shows otherwise.  Phone numbers - nope, as a business or household can
have multiple numbers, even multiple numbers in different area codes.
URIs; nope, clearly.  CORBA IORs, nope (I still remember those
discussions circa 1994).  I don't doubt that examples exist, but I think
they're few and far between, and it seems to me that the larger the
system, the less chance there is of being able to enforce such a rigid
rule.

FWIW, I think EPRs with RefParams are *not* identifiers, but those
without them are.

Mark.
--
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Thursday, 9 December 2004 21:46:18 UTC