- From: Peter Ansell <ansell.peter@gmail.com>
- Date: Mon, 23 Nov 2009 16:01:45 +1000
- To: Mark Baker <distobj@acm.org>
- Cc: Linked Data community <public-lod@w3.org>
2009/11/23 Mark Baker <distobj@acm.org>: > On Sun, Nov 22, 2009 at 11:59 PM, Peter Ansell <ansell.peter@gmail.com> wrote: >> It should be up to resource creators to determine when the nature of a >> resource changes across time. A web architecture that requires every >> single edit to have a different identifier is a large hassle and >> likely won't catch on if people find that they can work fine with a >> system that evolves constantly using semi-constant identifiers, rather >> than through a series of mandatory time based checkpoints. > > You seem to have read more into my argument than was there, and > created a strawman; I agree with the above. I did take some Literary privilege. The strawman was intended to be knocked down in the same argument. > My claim is simply that all HTTP requests, no matter the headers, are > requests upon the current state of the resource identified by the > Request-URI, and therefore, a request for a representation of the > state of "Resource X at time T" needs to be directed at the URI for > "Resource X at time T", not "Resource X". The issue with requiring people to direct requests at the URI for the Resource X at time T is that the circular linking issue I described previously comes into play because people need to pre-engineer their URI's to be compatible with a temporal dimension. If the user didn't know exactly what time scales were used by the server they would either need to follow a roughly drawn up convention, such as /YYYY/MM/DD/meaningfulresourcename, or they would have to find an index somewhere, neither of which are as promising for the future of the web as having the ability to add another header to provide the desired behaviour IMO. The documentation of the Vary header [1] seems to leave the situation open as to whether the server needs to be concerned about which or any Headers dictate which resource representation is to be returned. Caching in the context of HTTP/1.1 may have been designed to temporary, but I see no particular reason why a temporal Accept-* header, together with the possibility of its addition to Vary, couldn't be used on the absolute time dimension. It seems much cleaner than adding an extra command to HTTP, or requiring some other non-HTTP mechanism altogether. The extra header would never stop a server from returning the current version if it doesn't recognise the header, or it doesn't keep a version history, so it should be completely backwards compatible. Cheers, Peter [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44
Received on Monday, 23 November 2009 06:02:18 UTC