Re: Concern with URI normalization text; proposed change

Hmmm... my concern is that the unqualified claim of "strictly avoiding 
false positives" is also not factually true [1] and, if generic URI 
processing software is developed on this basis, could lead to incorrect 
results.  Is there another way to address this?

#g
--

[1] http://lists.w3.org/Archives/Public/uri/2004Feb/0094.html
     (Look for "Section 6 (concern):")



At 19:20 05/04/04 -0700, Roy T. Fielding wrote:
>On Thursday, February 19, 2004, at 03:36  PM, Graham Klyne wrote:
>>Further to my earlier message [1], I've discussed the issue of URI 
>>normalization with some colleagues and we'd like to propose the following 
>>small change of wording with respect to [2].
>>
>>...
>>
>>Section 6.1, para 2, final sentence:
>>
>>The suggested change is to this sentence:
>>[[
>>Therefore, comparison methods are designed to minimize false negatives 
>>while strictly avoiding false positives.
>>]]
>>
>>To be:
>>[[
>>Therefore, comparison methods are designed to minimize false negatives 
>>while strictly avoiding false positives when used for purposes of retrieval.
>>]]
>>
>>Rationale:
>>
>>This reinforces the earlier comment that "URI comparison is performed in 
>>respect to some particular purpose" [section 6 intro], and I think 
>>provides the necessary get-out for those purposes other than retrieval 
>>for which the normalization processes described can result in false 
>>URI-equivalence (i.e. in circumstances where existing applications may 
>>legitimately deliver differing results).
>
>Umm, no.  Aside from being difficult to understand due to the trailing
>qualifier, it is factually incorrect.  URI comparison has nothing
>to do with retrieval.  False negatives are false regardless of purpose.
>The purpose being discussed before that is the goal for which the
>cost/benefit trade-off is balanced, which could be different for each
>of a hundred different types of retrieval.
>
>....Roy

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Tuesday, 6 April 2004 06:02:46 UTC