RE: i0001: EPRs as identifiers

Gudge,

I'm merely saying that the use case should demonstrate the superiority
(or "need") for the proposed solution over other potential solutions. 
Otherwise, what's the point of the proposed solution?  Thus it would be
helpful if proponents of Reference Properties would explain: (a) what
problem they solve (i.e., what use cases need them); and (b) why other
potential solutions are inadequate for these use cases.  

Use cases that require different service *interfaces* would be much more
compelling than use cases that merely require different *policies*,
because it's much clearer that something should be externally viewed as
a different service (and thus should be idenfied by different Reference
*Properties*) if the thing has a completely different interface.

Sorry if I was unclear before.  I hope that's clearer.


On Thu, 2004-11-25 at 08:37, Martin Gudgin wrote:
>  
> > -----Original Message-----
> > From: David Booth [mailto:dbooth@w3.org] 
> > Sent: 25 November 2004 01:50
> > To: Martin Gudgin
> > Cc: Francisco Curbera; David Orchard; public-ws-addressing@w3.org
> > Subject: RE: i0001: EPRs as identifiers
> > 
> > On Wed, 2004-11-24 at 15:00, Martin Gudgin wrote:
> > . . .
> > > > 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...
> > 
> > Of course they *can*.  But the point of a motivating example 
> > is to show
> > that the proposed solution is *necessary* -- not that it is
> > *possible*.   If the problem could just as well be solved using other
> > approaches (such as Reference *Parameters* or merely URIs) 
> > then the need
> > for the proposed solution has not been demonstrated.
> 
> I don't believe I have ever claimed that endpoints with different
> porttypes/security requirements/etc. could not be distinguished by URI.
> Obviously they can. However, I will repeat that we think that, in SOAP
> based systems, being able to distinguish between such endpoints using
> SOAP headers is also useful. I am not trying to force people that wants
> to use URIs to distinguish between such services to use SOAP headers
> instead. I'm happy for them to use URIs. But I equally don't want to
> force someone who DOES want to distinguish between such endpoints using
> SOAP headers from doing so.
> 
> Regarding necessity, one could argue that XML is not *necessary* as we
> could just agree on ad-hoc formats for every exchange. High-level
> programming languages are not *necessary* as we could all program in
> assembly language or raw hex (perhaps some on this list still do... ).
> 
> Gudge
> 
> > 
> > It's far more compelling to say that S1 and S2 should be externally
> > viewed as different services (and thus should have different Web
> > resource identifiers) if they have different *interfaces* than if they
> > merely differ in the value of some policy or other input parameter.
> > 
> > -- 
> > 
> > David Booth
> > W3C Fellow / Hewlett-Packard
> > 
> > 
-- 

David Booth
W3C Fellow / Hewlett-Packard

Received on Tuesday, 30 November 2004 22:43:19 UTC