RE: targetResource wording

On what basis do you make this statement? Whose definition of "service"? 

Indeed, this turns out to be a very interesting problem and nailing down
targetResource is part of defining service. there is interesting debate
as to if a service is the interface to a resource or more than that.


> But if you restrict targetResource to only identifying "an interface
> that encapsulates", 
no one said that. It is the resource that is encapsulated. IMHO, there 
will likely be a potentially different URI for interface. 

The point is one of a "point-of-view". It is up to the developer
who is exposing capability to decide what the resource is.
I may create three interfaces exposing my printer, by I as the
service developer choose to make the printer the resource. 

This also allows you to create an interface and service that
encapsulates access to the printer. If you choose to use the
same target URI, then an end user would be able to tell that
two interfaces manage the same "resource".

daveh

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Sunday, June 15, 2003 12:05 PM
To: www-ws-desc@w3.org
Subject: Re: targetResource wording



On Sun, Jun 15, 2003 at 08:51:07PM +0600, Sanjiva Weerawarana wrote:
> > So why not have the spec mint a URI which identifies a resource
> > which represents *every* other resource (i.e. every resource
> > everywhere, that exists, has existed, or will exist)?  Then
> > you won't need targetResource at all, as it can be assumed
> > that its value will always be this URI.
> 
> Huh? Either I don't understand what you said or you have
> totally misunderstood the purpose of @targetResource.

The former, I believe.

Ok, rather than dig deeper into that admitedly esoteric example, let me
boil this down to a simple position statement ...

The resource(s) that a service uses are part of the implementation of a
service, not its interface.  Please don't conflate the two.

Thanks.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Monday, 16 June 2003 10:48:02 UTC