RE: i0001: EPRs as identifiers

DaveO,

First of all: Ouch!  Rest assured, I have read your posts and I know how
to use google.   Now that that's out of the way, let me summarize my
points.

1. Your comparison asserts that cookies are comparable to Reference
Properties.  They are not.  They are comparable to Reference
*Parameters*.  (Yes, cookies *could* be used like RefProps, but that is
not how they are *usually* used.)

2. RefProps and RefParams are qualitatively different, and the
difference is important.  We cannot have an informed discussion of the
technical issues if the difference is obscured.

3. URIs+RefParams are comparable to URIs+cookies.  A cookie is analogous
to param1 in Omri Gazitt's analogy[1]:
[[
. . . in the URL http://foo/bar?param1=value1, http://foo is
the wsa:Address, "bar" is the RefProp, and "param1" is the RefParam.
]]

Reasonable people would disagree about whether the 
"?param1=value1" part of http://foo/bar?param1=value1 is really 
identifying a different Web resource, versus merely supplying a
parameter (or input data) to the Web resource that is identified 
by http://foo/bar, just as a POST to http://foo/bar may specify 
input data or parameters.  

Some would argue that cookies "break the Web" (at least when used in
conjunction with a safe operation such as HTTP GET, in which the data
passed in a cookie could just has well have been part of the URI), and
therefore RefParams should not be adopted.  Others would argue that
RefParams don't "break the Web" any more than it is already "broken",
because cookies have been around for a while and the Web still works
fine, and therefore RefParams should be permitted.  

Thus, the issue of EPRs as identifiers is far less clear when discussing
Reference *Parameters* than when discussing Reference *Properties*.

4. URIs+RefProps clearly provides a different way to identify Web
resources than URIs alone.  Following Omri's analogy above, suppose we
have two different Reference *Property* values, bar and buz, and that
they are used to identify and interact with two "things" that have
different interfaces, metadata, policies, etc.  In Omri's analogy, they
would correspond to http://foo/bar and http://foo/buz .

Very few reasonable people would argue that http://foo/bar and
http://foo/buz are not identifying two different Web resources, *even*
if they are *also* related to a third resource identified by http://foo.
For goodness sake, they have different interfaces, metadata and
policies!  It would be disingenuous at best for anyone to argue that
they are not, in reality, identifying different Web resources, as you
correctly (and very nicely) alluded in the introduction of your
comparison[2].

5. The comparative analysis that you offered[2] purports to analyze
the trade-offs between URIs+RefProps versus URIs alone as Web resource
identifiers.  But in fact, as I pointed out, it represents a comparison
of URIs+RefParams versus URIs alone, which from a Web Architecture
perspective is not fundamentally different from URIs+Cookies.  Thus, the
comparison is completely inadequate for addressing the issue of EPRs
versus URIs.

6. The use of Reference Properties to identify Web resources clearly
violates the single most fundamental principle of the Web: the universal
use of URIs to identify Web resources.  Given that we have over 10 years
of experience and millions of implementations that demonstrate the
success and effectiveness of URIs for identifying Web resources, asking
for a few realistic use cases that demonstrate the need for something
else seems to me like an extremely modest request.

7. You argued that Reference Props/Params permit decoupling.  I pointed
out that such decoupling is *already* available by partitioning URIs. 
Thus, the decoupling argument provides no evidence whatsoever that URIs
alone are insufficient.  

> . . . .
> The choice of partitioning the URI space or into
> the message body via Reference Props/Params is in the developers hands.
> I've described the trade-offs between the two. . . .

No, as I carefully pointed out, your comparison discussed the trade-offs
between URIs alone versus URIs + Reference *Parameters*.  

8. You asserted[4] that
[[
The issue is that applications may want identifier information
that is protocol independent . . . .
]]
and I pointed out that this is explicitly contradicted by the
WS-Addressing spec[4] itself:
[[
The interpretation of these properties (as the use of the endpoint 
reference in general) is dependent upon the protocol binding and 
data encoding used to interact with the endpoint.
]]
Perhaps you wish to use RefProps in a protocol independent way, but I
don't believe it is reasonable for the WG to make an argument in support
of RefProps that is in direct contradiction to the spec itself.

9. I'm not "moving the goalposts", and I'm not asking the WG to adopt
new deliverables.  I'm asking the WG to provide solid technical
justification for its decisions, which is already the responsibility of
every WG.  

I have very clearly and patiently pointed out that the justifications
that have been offered thus far do not withstand scrutiny.  A few
realistic use cases that demonstrate the inadequacy of URIs for
identifying Web resources would go a long way.

P.S.  Please, no more insults about my ability to read your posts or use
Google.  I'm still recovering from your *last* message!

References
1. Omri's analogy:
http://www.gazitt.com/OhmBlog/permalink.aspx/deea5866-4da7-4774-b7c6-4daa7aabaec9
2. DaveO's proposed comparison of EPRs to URIs:
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0351.html
3. DaveO's argument about protocol independence
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0403.html
4. WS-Addressing
http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/#_Toc77464318

-- 

David Booth
W3C Fellow / Hewlett-Packard

Received on Friday, 19 November 2004 22:52:02 UTC