W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

RE: i0001: EPRs as identifiers

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Wed, 24 Nov 2004 12:00:03 -0800
Message-ID: <DD35CC66F54D8248B6E04232892B6338040F7AC5@RED-MSG-43.redmond.corp.microsoft.com>
To: "David Booth" <dbooth@w3.org>, "Francisco Curbera" <curbera@us.ibm.com>
Cc: "David Orchard" <dorchard@bea.com>, <public-ws-addressing@w3.org>


> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of David Booth
> Sent: 24 November 2004 19:48
> To: Francisco Curbera
> Cc: David Orchard; public-ws-addressing@w3.org
> Subject: RE: i0001: EPRs as identifiers
> Paco,
> On Mon, 2004-11-22 at 13:31, Francisco Curbera wrote:
> > Just to add one comment to DaveO's answer. Different 
> customerKeys could
> > perfectly be associated with different policies, so I don't 
> think your
> > argument against them appearing as reference properties is valid.
> DaveO's example was supposed to illustrate the need for Reference
> Properties.  
> I agree that it is *possible* for different customerKeys to have
> different policies that would require them to be processed by 
> different
> service endpoints.  But in most cases, it would more natural and usual
> for requests to be processed by the *same* service endpoint even if
> their customerKeys or policies differ (though I suppose that 
> depends on
> your definition of "policy").  

Policy to me covers things like security requirements, quality of
service requirements etc.
> In other words, the use of different customerKeys (or even different
> policies) does not adequately *motivate* the need for Reference
> Properties.  It would be far more instructive to use an example that
> logically requires a different interface.

Why? Reference properties can be used to distinguish between services
that differ by something other than interface/porttype...

Received on Wednesday, 24 November 2004 20:00:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:21 UTC