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

Re: i0001: EPRs as identifiers - alternative proposal

From: David Booth <dbooth@w3.org>
Date: Mon, 13 Dec 2004 02:02:17 -0500
To: tom@coastin.com
Cc: public-ws-addressing@w3.org
Message-Id: <1102921337.3268.1035.camel@nc6000.w3.org>

Tom,

On Thu, 2004-12-09 at 18:35, Tom Rutt wrote:
> . . .
> Let me clarify my point:   I understand that reference Properties 
> distinguish the metadata (i.e., what I like to think of as
> web service "type" information) applying to the endpoint, but it seems 
> that reference Parameters which distinguish the "instance" of
> "thing" behind the web service, which is the subject of communication, 
> are also being used to distinguish "identity".

I'm not sure what you mean by 'distinguish "identity"', but I'll assume
you are talking about the use of RefParams to help identify a Web
resource (as in the RFC 2396 sense of the word "identifier").

It is very clear the Reference Properties are intended to be used as Web
resource identifiers (in the RFC 2396 sense).  It is far less clear that
Reference Parameters are.  I'll try to explain why.

RefParams are analogous to the query string in a URI, so let me
illustrate this using query strings.

There are two ways to think about the query string in a URI.  One way is
view the query string as merely supplying *parameters* to a base
resource.  The other way is to view the entire URI (with query string)
as an identifier of a related resource.  

Suppose http://example.com/temperature is an identfier for a resource
that can return the current temperature at a given airport.  For
example, to ask for the temperature at SFO you could use:
http://example.com/temperature?airport=SFO
and it might return "59F".

You *could* think of http://example.com/temperature?airport=SFO as an
identifier of another (related) resource that returns the current
temperature specifically at San Francisco airport.  Would this be useful
to others as an (opaque) identifier?  Probably.

OTOH, suppose my temperature service also accepts a date parameter, and
will return the average temperature for the given airport on the
specified date.  For example,
http://example.com/temperature?airport=SFO&date=1997-07-16 
might return "68F".

Again, you *could* think of
http://example.com/temperature?airport=SFO&date=1997-07-16 as an
identifier of yet another (related) resource that always returns "68F". 
But would this be useful to others as an (opaque) identifier?  Probably
not.  If the resource always returns the same value, and that value is
shorter and simpler than the URI itself, then there isn't much utility
in using the URI as an (opaque) identifier of that resource, instead of
using the resulting value ("68F") directly.

In short, if there isn't utility in treating something as an identifier
(in the RFC 2396 sense), then there isn't much point in making an issue
of it.  With Reference Properties, it's very clear that there is utility
in treating them as identifiers; with Reference Parameters it isn't
nearly as clear.


-- 

David Booth
W3C Fellow / Hewlett-Packard
Received on Monday, 13 December 2004 07:02:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:00 GMT