Re: i0001: EPRs as identifiers - alternative proposal

  Could someone please explain the context in which it matters if an
EPR is an identifier?  It seems an EPR identifies little to a client
system, which cannot compare 2 EPRs with much hope of determining
whether or not they refer to the same web service.  At the same time, an
EPR *perfectly* identifies a web service to the system that hosts it: we
don't send SOAP messages to http://someserver.somehost.com/occupant and
hope that a web service on the target system will respond to our
request.  It seems to me that answering "who wants to use the EPR as an
identifier?" would clarify this issue.

Best wishes,

Mark Peel
Web Services Infrastructure
Novell, Inc.

>>> Francisco Curbera <curbera@us.ibm.com> 12/02/04 10:08 AM >>>

Mark,

I think that the argument (in your referenced mail below) that
addresses
are some form of identifiers is rather weak. Alternatively, it is a
strong
argument claiming that addresses are very weak identifiers :-)
Architecting
systems on the assumption that you may identify resources with an
address
is a recipe for disaster. The idea that network endpoints can be
provided
URI identifiers is a different matter; my opinion is only that runtime
service endpoint addresses should not be constrained to be URIs
(although
some may want to do just that).

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:
i0001: EPRs as identifiers - alternative proposal                       
  
                      uest@w3.org                                      
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                      12/02/2004 12:05 AM                              
                                                                       
                                                                       
                                                                       





Hey,

On Wed, Dec 01, 2004 at 01:00:27PM -0500, Francisco Curbera wrote:
> Rationale
> =======
>
> EPRs are not identifiers, only addresses. Let me explain.

FWIW, after the RefProps/RefParams discussion, I now agree that EPRs
are not necessarily identifiers.  But I don't see them as addresses
either, since addresses are identifiers[1].

IMO, the best way to think of this is with the EPR as a 2-tuple with
an
identifier and some contextual state, in exactly the same way we think
of http URIs and cookies.  So, I believe that an EPR is an identifier
iff it contains no contextual state, i.e. no RefParams.

> One remaining question is whether EPR (as addresses) should be URIs
but I
> think this should be opened as a separate issue.

I disagree.  I think it's part and parcel.  But no biggie, as long as
it
gets its day in court. 8-)

So unfortunately, I'm -1 on the proposal.  And I'd consider writing up
my own proposal, but it involves removing RefProps (to provide a
single
identifying data element), and I don't see that flying just yet.  But
we'll see where DavidB and Hugo get on that front ...

 [1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0588.html


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

Received on Thursday, 2 December 2004 16:51:12 UTC