W3C home > Mailing lists > Public > www-tag@w3.org > October 2010

Re: ACTION-462: URI Fragments and HTTP redirects

From: Tim Berners-Lee <timbl@w3.org>
Date: Fri, 8 Oct 2010 16:15:38 -0400
Cc: Yves Lafon <ylafon@w3.org>, TAG List <www-tag@w3.org>
Message-Id: <042F0106-8F1D-47C8-A54C-5B577E8193B4@w3.org>
To: nathan@webr3.org

On 2010-10 -08, at 10:17, Nathan wrote:

> Yves Lafon wrote:
>> On Mon, 4 Oct 2010, Yves Lafon wrote:
>>> My position on this is that:
>>> * Fragments in redirects have a real value and are already used.

In that case, can you tell me what it means
(a) for hypertext?
(b) for linked data?

Just because something is done out there doesn't mean it has any well-defined meaning or is useful.

Can you give a pointer?

For example the only example I know of (b) is the bibo ontology e.g. <http://purl.org/ontology/bibo/Journal>
which is in my opinion simply and completely broken.

Tim

>>> * Fragment recombination can be hard and impossible in the general case
>>> * We need to define a good story for applying a fragment to a redirected URI
>>> with a different fragment.
>> And the proposal is:
>> << When retrieving a resource A leads to a redirect to an URI B containing a fragment, any existing fragment on A MUST be dropped in favor of B's Fragment >>
>> Original URI: A#Frag1
>> -> GET A
>> -> 3xx Location: B#frag2
>> Final URI -> B#frag2
> 
> If I request A#Frag1 then in english I would say it as "get me A, whatever that is, then tell me what #Frag1 is" - what happens at HTTP level appears to be of no concern to a client / agent.
> 
> It appears to suggest that a server must understand the semantics and contents of the media type of the message - does Apache HTTP server know the fragments within static XML/HTML documents it may serve?
> 
> But then I've often been confused as to why HTTP allows fragments in the Location but not in the request line.
> 
> Best,
> 
> Nathan
> 
> 
Received on Friday, 8 October 2010 20:15:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:28 GMT