W3C home > Mailing lists > Public > www-tag@w3.org > July 2002

Re: Architecture Document: Terminology: Dereferencable, Retrivable, R esolvable.

From: Tim Berners-Lee <timbl@w3.org>
Date: Mon, 15 Jul 2002 14:47:09 -0400
Message-ID: <02b401c22c30$069314f0$84001d12@w3.org>
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>, <www-tag@w3.org>

I have used "dereference" to mean to "get that identified by" as in
dereferencing a pointer. The meaning here is I think
the same as your "retrieval, except that I prefer "dereference"
as it seems to me to be an abstract function -- the referent
as a function of the identifier, while 'retrieve" indicates motion
of something (as in a Labrador trotting back with a duck).

In a computer system, you can dereference something which
identifies a file or a document.


----- Original Message -----
From: "Williams, Stuart" <skw@hplb.hpl.hp.com>
To: <www-tag@w3.org>
Sent: Friday, July 12, 2002 10:58 AM
Subject: Architecture Document: Terminology: Dereferencable, Retrivable, R

> The retentive in me is coming out...
> In writing about the things folks might do with URI (and URI references)
> speak variously of resolvable, dereferencable and retrievable URI. However
> it's not clear to me whether or not we have consistent notions the
> shades of gray that might be associated with these terms. If there are
> pre-existing definitions for these notions a pointer would be welcome.
> For instance, a TAG finding might say that "All important resources should
> be identified using deferencable URI" (for example). One might take that
> mean that a representation of the resource should be 'retrievable' using
> relevant URI (that's what it says at [1]). But I think one could also
> that any of HTTP PUT, POST, HEAD or DELETE involve "deferencing" the URI.
> programming languages we apply the notion of dereference wrt to an object
> reference or a pointer regardless of whether it is used on the left or
> hand side of an assignment. So... whilst to be 'retrievable' a URI must
> be 'deferencable' the act of 'derefencing' a URI does not necessarily
> a safe 'retrival' operation. Likewise, to be 'dereferencable' a URI must
> also be 'resolvable', the act of 'resolving' a URI being a pre-cursor to
> possibly entailed within the process of dereferencing a URI.
> Does this make any sense or do such fine grain differences not matter in
> architectural writings?
> Anyway, some proto defintions to chew on:
> URI Resolution:
>   The process of determining the access mechanism and
>   appropriate parameters necessary to dereference a
>   URI. e.g. in the case of an HTTP URI, this process
>   resolves the URI into an IP address, a port number,
>   a host name (possibly optional) and a request URI.
>   Resolution may require several iterations.
> URI Dereference:
>   The process of using the access mechanism and
>   parameters generated by URI resolution to create,
>   inspect or modify resource state.
> URI Retrieval:
>   The use of URI dereference to retrieve
>   representations of resource state.
>   [On the Web Retrival is always safe].
> Comments?
> Regards
> Stuart Williams
> [1] http://www.w3.org/2001/tag/2002/0701-intro.html#dereference
Received on Monday, 15 July 2002 14:47:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:32 UTC