- From: Jonathan Rees <jar@creativecommons.org>
- Date: Fri, 8 Oct 2010 12:22:47 -0400
- To: Yves Lafon <ylafon@w3.org>
- Cc: www-tag@w3.org
Can you give me an extant URI for which this makes a difference? I've been repeatedly assured that they exist, but I don't think anyone has exhibited one here. I'm uneasy because your rule contradicts the architecture. Supposedly URIs "identify" resources. The rule makes fragids resolve according to different mechanisms depending on the context of use, a violation of referential transparency (a.k.a. "uniformity"). There is another way to achieve the same effect that doesn't have this problem. You could stipulate that when you try to resolve a fragid relative to an element or other document part (as opposed to the usual case where you're resolving relative to an entire document), you get the whole document part, i.e. the fragid is ignored. Jonathan On Fri, Oct 8, 2010 at 9:51 AM, Yves Lafon <ylafon@w3.org> 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. >> * 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 > > Cheers, > > -- > Baroula que barouleras, au tiƩu toujou t'entourneras. > > ~~Yves > > >
Received on Friday, 8 October 2010 16:23:20 UTC