Re: Documents, Cars, Hills, and Valleys

On 2002-04-10 05:22 PM, "Tim Berners-Lee" <timbl@w3.org> wrote:

> Because if you adopt the notion that
> <http;//www.mnot.net/> a :Person.
> 
> I would be forced to conclude that you, Mark, will expire
> alas too soon: [1]
> 
> Expires: Thu, 11 Apr 2002 09:14:08 GMT
> 
> <http://www.mnot.net/> a :Person;
>        http:expires "20020411T091408".
> 
> which gives you only a few hours. Sad.

Nonsense! You are confusing HTTP Entity headers with Resource headers. The
Expires: header refers to the set of bits which you get back from the
server, not the Resource that they are Representations of. If that were so I
would be forced to conclude that the W3C's website, www.w3.org, would expire
too soon:

Expires: Wed, 10 Apr 2002 23:02:07 GMT

which would make a mockery of the persistence policy. Sad.

> ("Off with her HEAD!" cried the Queen. "Oh, surely
> you mean off with the HEAD of the HTTP reply
> which returned a representation of a picture of me?"
> protested Alice. "Same thing! GET me her HEAD!"
> cried the Queen)

("Let the Jury consider the Resource headers," said the King, for about the
twentieth time that day. "No, no!" said the Queen. "Entity headers first -
Resource headers afterwards." "Stuff and nonsense!" cried Alice loudly. "The
idea of having the Resource headers first...")

> My point, which I  have made again and again, is that HTTP GET
> is a protocol for talking about generic documents.

No matter how many times you say it, it does not necessarily become true. I
would appreciate something more along the lines of specification citations,
rationale and things that break when HTTP Resources identify cars and the
like.

> You could imagine a protocol (say SWTP) which directly
> responds to requests about things. [...]
> But that protocol is not HTTP.

I think it is. 

> HTTP has a lot of sophisticated design for the rendering of
> generic documents.   To try and force it into swtp: functionality
> is a kludge which would ruin it.

Can you give an example? It seems to work pretty well for me.
 
> We just invent a new language, not a new protocol. This cost is
> much smaller.

We don't even need a new language, we can just add a new HTTP header, like
Resource-Type (just to make things perfectly clear)

See:
http://www.ietf.org/internet-drafts/draft-palmer-resrep-type-00
Archive: http://infomesh.net/2002/draft-palmer-resrep-type.txt

> Given that the # allows us to be free of any restriction, we avoid forcing
> HTTP to be what it ain't and still get all we need.

I don't believe so. RFC 2396 seems full of restrictions on them:
"""
   When a URI reference is used to perform a retrieval action on the
   identified resource, the optional fragment identifier, separated from
   the URI by a crosshatch ("#") character, consists of additional
   reference information to be interpreted by the user agent after the
   retrieval action has been successfully completed.  As such, it is not
   part of a URI, but is often used in conjunction with a URI.
   [...]
   The semantics of a fragment identifier is a property of the data
   resulting from a retrieval action, regardless of the type of URI used
   in the reference.  Therefore, the format and interpretation of
   fragment identifiers is dependent on the media type [RFC2046] of the
   retrieval result.
"""
 - RFC 2396
   Uniform Resource Identifiers (URI): Generic Syntax
   Berners-Lee et. al.

-- 
[ "Aaron Swartz" ; <mailto:me@aaronsw.com> ; <http://www.aaronsw.com/> ]

Received on Wednesday, 10 April 2002 19:12:29 UTC