W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2003

RE: targetResource wording

From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
Date: Thu, 19 Jun 2003 19:11:13 -0600
Message-ID: <9A4FC925410C024792B85198DF1E97E405F292AE@usmsg03.sagus.com>
To: www-ws-desc@w3.org


> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org] 
> Sent: Thursday, June 19, 2003 8:47 PM
> To: www-ws-desc@w3.org

> service.  So rather than "a chunk of software in the 
> printer", I get the impression that you're saying that the 
> URI identifies "the printer", and IMO, targetResource has 
> nothing to do with that; there could be many chunks of 
> software implementing those interfaces within (or on behalf 
> of) the printer, different software could be installed, etc.. 
> all the while, the identity and URI of the printer remain the same.

Right, or at least the URI is whatever the service developer decides is the
"resource" whose identity needs to be exposed.  It could be software,
hardware, or an abstract concept, or anything else that the very general
term "resource" covers.
Or it could be not used at all if the application has no need for that
concept.  As David said, it's a *relationship* between a WSDL document and
the fundamental resource that the  service operates on, whatever the
designers conceive that to be

> I strongly disagree.  By that measure, everything which 
> accepts a URI as an argument should be called "resource".

Uhh, if anything identified by a URI is not a resource, there is something
ontologically broken in the term Uniform Resource identifier :-)   I'm just
not following the objection here.  It seems well aligned with the very
abstract way that "resource" is used in the Webarch document to me.
Reasonable people can disagree on whether Best Practice is to expose the
implementation resources to direct manipulation or encapulate them as an
abstract resource and hide the implementation details, but I don't think
that the  WSD folks are using the term "resource" inappropriately here.
Received on Thursday, 19 June 2003 21:11:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:30 UTC