- From: Francisco Curbera <curbera@us.ibm.com>
- Date: Thu, 2 Dec 2004 12:33:43 -0500
- To: "Mark Peel" <mpeel@novell.com>
- Cc: public-ws-addressing@w3.org
Mark, Even for the hosting system, it is different to say that the EPR is the identifier from saying that it can be used to find out the identifier. I can have many EPRs for the same resource and to check for identity I lookup the actual identifier corresponding to each EPR and then check for equality. That does not make the EPR into an identifier. On the other hand, what the hosting system does internally is not necessarily our focus, just a source of important requirements. The interoperable side of it is what we need to focus on; that is the only perspective that clients (should) have. If we tell them that EPRs can be used as identifiers we are going to get them in trouble sooner or later. Paco "Mark Peel" <mpeel@novell.com To: Francisco Curbera/Watson/IBM@IBMUS > cc: <public-ws-addressing@w3.org> Subject: Re: i0001: EPRs as identifiers - alternative proposal 12/02/2004 11:50 AM 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 17:34:19 UTC