- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Tue, 22 Feb 2005 12:21:35 -0500
- To: Hugo Haas <hugo@w3.org>
- Cc: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, Francisco Curbera <curbera@us.ibm.com>, public-ws-addressing@w3.org
+1 to Hugo's comments and to either sticking with the status quo or going with option 2. BTW, I didn't think anyone was suggesting that EPRs with the same [address] were interchangeable, just that they referred to the same endpoint - the current text doesn't suggest anything about interchangeability to me. Marc. On Feb 21, 2005, at 4:55 PM, Hugo Haas wrote: > > Hi Umit. > > * Yalcinalp, Umit <umit.yalcinalp@sap.com> [2005-02-21 08:14+0100] >> Here is my take on this matter, followed by a proposal. >> >> Issue: >> >> I would like to look at this problem of what we are gaining by >> providing >> a comparison of endpoint references. From a client's perspective, the >> comparison of endpoints may only be useful if the comparison were to >> indicate interchangeability. This means that given two EPRs, a client >> could toss away one of them iff they are determined to be the same, >> meaning indistinguishable for all practical purposes. > > I don't think that the purpose of comparing EPRs is > interchangeability. It has been expressed several times in the context > of issues i001 and i014 — in particular, see discussion at [11] — that > its goal was metadata caching, and section 2.3 does exactly this: it > tells you, if you have an EPR and some metadata for it, what you can > conclude about the metadata when you receive another EPR. > > I will discuss this issue from this angle to avoid the sensitive > I-word. > > [..] >> I can give more examples, but I do hope you get the idea. In all these >> cases above, however, we can safely determine whether two EPRs refer >> to >> the same endpoint by comparing their addresses. > > I believe that this is what section 2.3 does: it points out that > [address] is the cache key. > > [..] >> Proposal: >> >> I believe that the current status quo is really harmful and misleading >> for all purposes. I will be strongly against the status quo and >> closing >> the issue. >> >> There are three different things we can do: >> >> (1) Remove Section 2.3 and clean up the confusion we have created as >> proposed by Paco. >> (2) Change 2.3 to make it consistent with the resolution of Issue 20 >> iv, >> by illustrating that EPRs are not interchangeable and by clarifying >> how >> they refer to the same endpoint that use the same metadata. >> (3) Add capability for endpoints to determine whether two EPRs are the >> indeed interchangeable. >> >> Lets look at the details: >> >> Proposal for (2) >> >> Per [6], a gateway configuration can be considered to be endowed with >> the union of all the metadata of all services that share that address. >> However the following section is misleading for this as it is >> inconsistent with the decision we just made [8]. >> >> {The following rule clarifies the relation between the behaviors of >> the >> endpoints represented by two endpoint references with the same >> [address]; >> - The two endpoints accept the same sets of messages, and follow and >> require the same set of policies. That is, the XML Schema, WSDL, and >> policy and other metadata applicable to the two references are the >> same.} >> >> Instead it should be corrected to say: >> >> {The following rule clarifies the relation between the behaviors of >> the >> endpoints represented by two endpoint references with the same >> [address]; >> - The two endpoint references refer to the same endpoint that accepts >> a >> set of messages, follow and require a set of policies that are defined >> by a (set of) XML Schema(s), WSDL(s), and policies and other metadata >> applicable. Hence, these endpoint references are designed to utilize >> the >> set of messages, policies and descriptions that apply to the specific >> endpoint. >> } > [..] > > I am fine with the status quo, but I think that I am also happy with > your proposal 2 which keeps the spirit of section 2.3. > > I believe that proposal (1) goes against the resolution of i001, and > that proposal (3) brings us back to the area of formal identifiers for > which the WG has decided against already. > > Cheers, > > Hugo > > 11. > http://www.w3.org/2002/ws/addr/4/12/13-ws-addr-minutes.html#item05 > -- > Hugo Haas - W3C > mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ > > --- Marc Hadley <marc.hadley at sun.com> Web Technologies and Standards, Sun Microsystems.
Received on Tuesday, 22 February 2005 17:21:34 UTC