Re: Proposed IETF/W3C task force: "Resource meaning" Review of new HTTPbis text for 303 See Other

On Jul 20, 2009, at 1:23 PM, Roy T. Fielding wrote:

> On Jul 19, 2009, at 7:28 AM, Larry Masinter wrote:
>
>> I'd like to ask that we start a separate task force and
>> mailing list on the topic of resolving any remaining issues
>> around the use of the word "resource" and the semantics
>> associated with it, with the task force chartered to come up with
>> satisfactory wording to propose as amendments, errata,
>> or updates to relevant documents. The initial
>> documents to be considered are:
>>
>> (a) the URI specification RFC 3986
>> (b) the HTTP specification being developed in HTTPbis
>> and (1) its definitions of "resource"
>>     (2) its definition of HTTP URI scheme
>> (c) the W3C TAG document AWWW
>> (d) the W3C TAG httpRange-14 finding
>> (e) the W3C RDF recommendation
>>
>> Other documents and uses of the word "resource" may
>> be added to the scope once the task force has agreement
>> on this issues.
>
> For the record, I do not believe there is anything wrong with the way
> resource is defined in RFC 3986.

I would note that it is not in fact **defined** there. But, hasten to  
add, that is fine: the intent of RFC 3986 is perfectly clear. It could  
have been stated more succinctly by simply saying that the word  
"resource" was being used to mean "anything whatever that can be  
referred to and identified", but let us not split hairs. But this  
thread started because HTTPbis explicitly disagrees with RFC 3986 on  
what a resource is. Surely these various documents should at least  
agree on their uses of the basic technical terminology.

>  I have no interest in discussing
> it further because all of these arguments have already been covered
> three times over.
>
> The fact that some people insist that their personal/professional
> ontology doesn't have room for any of the other definitions found
> in a common dictionary

That is silly, and offensive. There is not, and never has been, an  
English dictionary that would give the RFC 3986 meaning for   
"resource", other than by this new use creeping into corpora such as  
Wikipedia. (The Wikipedia article documents this history quite well,  
in fact.)  And the issue (for me, at any rate, and I speak as one of  
the noisy ones on this issue) has never been to impose my personal  
ontologies on anyone, only to gain clarification of the intended  
meanings of the words in the specs as written: which, before RFC 3986,  
were extremely underdefined and indeed internally inconsistent.  
Personally, I find the RFC3986 usage ludicrous, pretentious and  
misleading, but it is the standard, so I am reconciled to using it.  
But then when I do, I expect other uses in other standards  
documentation to at least conform to this usage.

Being told to consult a 'common dictionary' is both unhelpful and  
extremely discourteous: it implies that I do not have an adequate  
grasp of my native language, a language in which I have been speaking,  
teaching and writing technical papers since you, Roy Fielding, were a  
babe in arms. And frankly, if you think that this usage of "resource"  
is found in a common dictionary, then you are the one who needs to  
spend more time with English dictionaries.

> is not, in my opinion, a protocol issue.
> The term is defined in one place (3986) for the sake of documentation
> and consistency, not for the sake of perfection in the minds of
> every observer.  As far as the protocols are concerned, the fact
> that it is a defined term is all that matters: it's definition
> does not matter outside the philosophical realm.

All of which would be fine if it actually had a definition. which is  
(still) does not. Not that it really matters, but just to set the  
record straight.

>
> We already spent six years of 2396 and 3986 development talking about
> these issues.  HTTP (2616bis) is currently under revision and the plan
> is to make it entirely consistent with 3986 (mostly by removing any
> and all overlapping prose).

I trust then that this will be removed (cited from Henrik's recent  
email) :

---------
p1-messaging, C. Terminology

        resource

                A network data object or service that can be identified
                by a URI, as defined in Section 2.1. Resources may be
                available in multiple representations (e.g. multiple
                languages, data formats, size, and resolutions) or vary
                in other ways.

Note: "resource" in 2.1 above refers to the more general RFC3986
meaning, in the rest of the HTTP documents it generally refers to the
HTTP definition of resource.
----------

Apparently the HTTP meaning of "resource" is, currently, explicitly  
different from the RFC3986 sense. So we are left with what might be  
called a comprehension impasse. When the HTTP documents refer to (for  
example) "the requested resource", do they use the word in this  
narrower sense or in the wider RFC3986 sense? If the former, what does  
this say about requested resources? That they **must** be, **by  
definition**, a 'network data object or service'?  (In which case,  
what about the case where an HTTP URI is being used to denote  
something which is not a resource in this narrower sense? Such cases  
exist. Does the HTTP spec simply ignore these cases? Or implicitly  
deny that they can occur, or implicitly prohibit them? Or does it  
imply, without explicitly saying so, that the resource (RFC3986 sense)  
being denoted by the URI may not be the resource (HTTPbis sense) which  
the URI identifies?)  Or, does the HTTP document in fact intend  
"resource" in the phrase "requested resource" to be understood in the  
wider RFC3986 sense? That would make sense, but I would not have any  
confidence that this was in fact what was intended, from the document  
as written or from any of the suggested wordings in this thread.

These are not questions that arise from my private ontology, they are  
critical questions which arise when trying to understand the actual  
words used in the specification documents themselves. The words are  
simply too ambiguous, too under-determined, to allow anyone to extract  
a clear answer to such questions; but they must be answered, and  
different answers will have different consequences for how actual  
software must be written. To make this point more forcibly, it seems  
clear for example that Henrik Nordstrom has an overall view of what  
the HTTP text is saying which is different from that which Richard  
Cyganiak has, at least based on their emails to this thread. For  
Henrik, if I understand him correctly, a "requested resource" must be  
a network object of some kind, located immediately behind the HTTP  
endpoint ('server') interface; for Richard, it is whatever the URI is  
understood to denote, whatever its nature. And it is surely not  
difficult to be more precise here. For example, just a simple sentence  
along the lines of  "A requested resource must be a network data  
object or service." would at least  clear up this misunderstanding,  
although it would not answer the other questions above.

I cannot recommend any text here, by the way, precisely because I do  
not want to impose any interpretations of my own. I want only to  
clarify the authors' intentions. But I cannot discern what those  
intentions are.

Pat Hayes


>  Change-requests to that text are welcome
> on the httpbis lists/trac.  In particular, b1 and b2 on the list above
> are currently waiting on me to get my act together, so expect them
> both to be radically changed in httpbis over the next two weeks so
> that they just point to 3986.
>
> I cannot imagine revising 3986 (STD 66) again, at least not in our
> lifetimes.  If you want to establish an official bike-shed painting
> committee for the purpose of discussing what resource means, then
> I suggest it should be done entirely within W3C, fed to the TAG for
> review, and then (if any changes are warranted) an official errata
> request be placed with the IETF.
>
> ....Roy
>
>
>

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 20 July 2009 20:29:08 UTC