Re: 200 vs. 303 vs. ??? (was Re: Raw minutes of meeting

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pay Hayes writes:

> HST writes:

>>First, let's be careful about the preconditions for the 200 vs. 303
>>question.
>>
>>1) A client issues an HTTP GET request for a URI *U* which identifies
>>    a resource *T* to a server *S*
>>
>>2) *S* generates one of two responses:
>>
>>    2a)
>>        HTTP/1.1 200 OK
>>        Content-type: xxx
>>        . . .
>>
>>        [a representation *R*]
>>
>>    2b) HTTP/1.1 303 See Other
>>        . . .
>>        Location: [a URI *Uprime*]
>>
>>        A further GET request is issued, for *Uprime*, to which the
>>        response is
>>
>>        HTTP/1.1 200 OK
>>        Content-type: yyy
>>        . . .
>>
>>        [a representation *Rprime*]
>>       
>>
>>  * What can you infer in case (2a)?
>>
>>    *R* is a representation of the resource *C* identified by *U*.
>
> Two questions.
> (1) Why isn't it a representation of *T* ? (See (1) above)

It is, that was a typo on my part.

> (2) You are here, I presume, using "representation" in the REST/TAG
> sense? If so, I would note that this word is used in the wider world
> in a variety of senses, most of which have almost no connection with
> the REST/TAG sense.

Yes I was using the word 'representation' in that sense.  While we're
talking about 2616, I think we can use 2616 terminology.

>>  * What can you infer in case (2b)?
>>
>>    *Rprime* is a representation of *Cprime*, the resource identified
>>    by *Uprime*.  *Rprime* is _not_ a representation of *C*.
>
> Again, why C rather than T?

Again, a typo, sorry.

> But in any case, in several of the broader senses of
> "representation", it might well be a representation of it. It might,
> for example, be an RDF description of it. Or even an English
> description, or a jpeg picture (or all of these). All of these can
> be called "representations" of something (though no, of course, in
> the REST/TAG special sense of "representation").

Right, but focussing on 'representation' per REST/TAG/2616. . .

> I'm assuming here that in this case, the resource "identified" by the
> first URI is a non-information resource, of course. That is, that you
> allow "identifies" to include "denotes" as one kind of
> identification. Is that right? It is of course notoriously hard to
> know what anyone means when they say "identifies", so this assumption
> may be mistaken.

I was trying to avoid the information resource question, and again
using 'identify' in the TAG/REST/2616 sense, but broadly speaking, yes.

>>To get something stronger than the negative conclusion which 303 gives
>>us, I think we should look seriously at asking for a new response code
>>in the new HTTP RFC:  Either a 207, meaning explicitly "The
>>representation returned herewith represents a description of the
>>resource identified by the requested URI (i.e. it is _not_ a
>>representation of the resource itself)"
>
> Please explain it better than this. In the wider world, a description
> IS (one kind of) a representation. In a large part of the wider world,
> a formal description is a canonical example of a representation.

Doing so would require the kind of thorough reconstruction of
TAG/REST/2616 terminology which you and Harry Halpin and . . . are
still engaged in!  Meantime, the intent of the above can I hope be
understood in terms of 2616 terminology . . .

> But apart from griping about terminology, this doesn't solve the
> ambiguity-of-URIs issue that gave rise to this whole business in the
> first place. We shouldnt lose sight of the fact that the whole problem
> arises because we want to know what it is that a **URI** denotes; not
> what a URI+(an http response code) denotes.

Indeed.  One step at a time.  This _just_ tries to clarify/improve the
situation wrt 200/303 given the _status quo_ wrt URIs.  I have argued
for at least three years [1] that we would be better off if we could tell
- From a URI itself whether it denotes something accessible or not
(to use your terminology :-), but I remain unclear what the best way
to achieve that is. . .

ht

[1] http://www.ltg.ed.ac.uk/~ht/webpropernames/
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFHToqVkjnJixAXWBoRAvBhAJ9Dy6XgroaaqqY3XnMgX7IH36kOUACfdbSJ
E8YRwJ8Jmt1jAUQc4i3i09g=
=iTHb
-----END PGP SIGNATURE-----

Received on Thursday, 29 November 2007 09:47:19 UTC