Re: Issue i048 - summary of discussion

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/

Received on Monday, 21 February 2005 22:00:28 UTC