Re: ISSUE-81 (resource vs representation)

On Sep 28, 2009, at 11:53 AM, Nikunj R. Mehta wrote:

>
> On Sep 27, 2009, at 4:18 AM, Maciej Stachowiak wrote:
>>
>> It seems like it would be more painstakingly accurate to say "A URL  
>> is a string used to retrieve a resource"
>
> completely wrong because you may not bring back any resource at all.  
> Think of the tel: or mailto: URIs which are perfectly legal to use  
> in HTML.

I meant when using "resource" in the sense of the octet sequence  
actually retrieved. tel: and mailto: URLs cannot be stored in the  
Application Cache (the original context of the discussion).

>
>> or "A URL is a string that provides the address of a resource."
>
> This is the standard definition of URL and I don't see why a new one  
> is required. It is about as painstaking as spelling A, B, C, D.
>
>> But even that is not quite accurate, because in the case of HTTP,  
>> it's the full HTTP request (including method and headers) that  
>> determines what resource you get, if you take resource to be the  
>> concrete octet sequence you get back.
>
> Again this is misleading since without the URL, which provides the  
> address, the rest of the HTTP request is meaningless. Besides, you  
> are unnecessarily limiting yourself to HTTP, when URLs are beyond  
> just HTTP.

I don't see how it's misleading. You can't issue an HTTP request  
without the URL, but you also can't issue it without the method. And  
while you can issue it without any request headers, or body (for a  
POST), you probably won't get the answer you were expecting. It's true  
that for most other URL schemes, the URL alone is sufficient, but most  
URLs you deal with in a Web context will be http: or https:. It's also  
true that we often simplify and assume the URL alone tells you what to  
get.

>> In any case, I don't think this kind of wording discussion is best  
>> handled through the issue tracker.
>>
>
> What is then the best way to handle this? We already ruled out bug  
> tracker, now issue tracker. What are we left with then? LC comments?

I think pedantic nitpicking of word choices is not a good way for the  
Working Group as a whole to spend its time. I would not want to end up  
holding polls about individual word choices. Thus, I would prefer we  
focus less on word choices and more on issues that materially affect  
the technical content of the spec.

Regards,
Maciej