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

RE: i0001: EPRs as identifiers (implementation model)

From: David Booth <dbooth@w3.org>
Date: Wed, 24 Nov 2004 11:53:34 -0500
To: Martin Gudgin <mgudgin@microsoft.com>
Cc: David Orchard <dorchard@bea.com>, Jonathan Marsh <jmarsh@microsoft.com>, public-ws-addressing@w3.org
Message-Id: <1101315214.31645.203.camel@nc6000.w3.org>

Gudge,

On Mon, 2004-11-22 at 10:10, Martin Gudgin wrote:
> . . . [URI+RefProps/Params] is no more ( or less ) of
> an implementation choice than using;
> 
>  URIs with more than just a domain name
>  URIs with query params
> . . . .

I disagree and agree.  It depends on the URIs.

I agree that URI+RefParams exposes the implementation model to the same
extent as URI with QueryParams.  (RefParams are equivalent to cookies,
and cookies expose the implementation model to the same extent as
QueryParams, though they differ markedly in other characteristics, such
as Web friendliness.)

I also agree that if URI+RefProps is restricted to have no path in the
URI part, then URI+RefProps exposes the implementation model to the same
extent as a URI with path.  (Though again, they differ markedly in other
characteristics.)

But if URI+RefProps *has* a path in the URI part, then URI+RefProps
clearly expose the implementation model more than just a URI with a
path.  Consider the two examples:

URI with path:
http://example.com/a/b/c/d/e/f/
URI+RefProps:
http://example.com/a/b/c   <RefProps><d /><e /><f /></RefProps>

In the first example the service *might* internally use a two-part
dispatch mechanism, based first on the http://example.com/a/b/c part and
then on the d/e/f part, but it isn't at all clear that it does. It is
far more evident that the second example does.

-- 

David Booth
W3C Fellow / Hewlett-Packard
Received on Wednesday, 24 November 2004 16:53:45 GMT

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