Rathole4: Time variance

On 2011-06 -24, at 16:45, Alan Ruttenberg wrote:

> On Wed, Jun 22, 2011 at 10:44 PM, Tim Berners-Lee <timbl@w3.org> wrote:
>> 
>> If the client can gather nothing from the 200 code at all, the there is not
>> much point  in doing the operation.  In the web architecture, it is the 200 that allows
>> the client to in future point others too the web page using the same URI
>> and expect them to get the same document. (not any document about the same
>> thing, or any document by the same author or any document of the same length)
>> (You can nit-pick about the definitions, but it is not very constructive).
> 
> Hi Tim,
> 
> I think this is a nice idea in theory and might have been true at some
> point, but it doesn't seem to be true anymore. And even the example in
> the AWWW seem to contradict this. If a server responds with a 200 for
> the weather report for Oaxaca, on subsequent days it is not returning
> the "same" document in any sense that "same" is used in English. In
> such cases it is returning a document about the same thing (the
> weather in Oaxaca). In the case of http://news.google.com/ what they
> get each time isn't even about the same thing - it is about the same
> *sort* of thing (events that have happened recently).


Absolutely.  Web pages change with time. A web page which is
the current front page on The Times  is "same" in this sense 
as the current front page of The Times.  It changes with time.
See the ontology and discussion in http://www.w3.org/DesignIssues/GenericResources
which also deals with variation within a generic resource, by language,
encoding, etc.


> Anyways, perhaps how I interpret what you say will help you debug why
> I am not understanding the sense of 200 you are trying to convey, and
> I'd appreciate any insight about it. I'd really like to at a minimum
> to understand what the idea you have is.

The discussion which you forked this off was about whether
you could use the URL of a web page to ref to (a) the web page
or (b) the subject of the web page, or (c) none of the above.
That was driving some people crazy, those people who want
to use it to refer to the web page.


> My best interpretation is that what you are saying is true for a
> subset of URIs substantially smaller than the 200 responders (without
> even having too strict a definition of document).

It depends if you want to split hairs and not allow
documents to be things which change. If you do, you depart from the web.


> I don't think one has to nail down exactly what the definition of
> document is for the purposes of webarch, but it would be good to get
> into the ballpark. Right now I have two points of reference for what a
> 200 response means, neither of which seem to be close.
> 
> 1) Something like "the server responded with a representation that
> answers the GET according to its intended design" (usually seems to be
> true, and a statement about the server, not the resource)

> 2) Something like "you are getting (mostly) a complete encoding of a
> document-like thing - something authored with a purpose, and which is
> relatively stable in (interpreted) content but which may change over
> time due to the normal process of author revision". (true for an
> important class of things on the web, but only a subset of 200
> responses)

3) Something like "you are getting (mostly) a complete encoding of a
document-like thing - something authored or generated with a purpose, and which is
relatively stable in (interpreted) content but which may change over
time due to the normal process of author revision, or the change
of state of things described document, or the release of new things of which the document represents the latest".  (true for an important class of things on the web, most 200 responses)

This discussion, as to how you define the front page of The Times
to be a document you can go into much depth on --
but it is not very constructive.

The original message was to convince Xioshu Wang that it  was important to be able to use the URI for the document,  not its subject.


> -Alan
>

Received on Saturday, 25 June 2011 01:59:00 UTC