- From: Paul Prescod <paul@prescod.net>
- Date: Mon, 15 Jul 2002 15:30:35 -0700
- To: Tim Berners-Lee <timbl@w3.org>, www-tag@w3.org
- CC: "Williams, Stuart" <skw@hplb.hpl.hp.com>
Tim Berners-Lee wrote: > I have used "dereference" to mean to "get that identified by" as in > dereferencing a pointer. > .... > In a computer system, you can dereference something which > identifies a file or a document. I understand that there is one point of view which says that URIs *either* denote things that are retrievable (that can be "got") *or* things that are not (e.g. persons, cars). (view 1) Then there is another point of view that says that URIs *always* denote things that are not retrievable. You can never get the thing they describe, only a representation of the thing. Doing a GET on a URI is not dereferencing in the normal sense but the meaning is usually close enough to make the distinction not worth making. (view 2) Above, you seem to say that you believe that some URIs are dereferencable and some are not (view 1). Do you have separate terminology for GET-ting a concrete resource like a file or document and for GET-ting a representation of an abstract resource like a namespace? Or do you use the word dereference in both cases but with separate meanings? Proponents of view 1 seem to argue that namespaces should not use HTTP URIs because namespaces are abstract and cannot be "got". Doing a GET on such a URI cannot be interpreted as "dereferencing" because the thing you get back is different than the identified object. Proponents of view 2 seem to say that namespaces are no more or less dereferencable than home pages. Both are abstractions which are not retrievable in the usual English-language sense. Therefore HTTP URIs make just as much sense as in any other context. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Received on Monday, 15 July 2002 18:31:47 UTC