Re: anchor parameter, was: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

It seems to me that we could go in a few directions regarding anchor;

1) get rid of it completely; any app that wants to use it can define  
it as an extension (as they would for HTML and Atom, which don't have  
dynamic scopes).

2) restrict it to ONLY fragment identifiers, and make them advisory  
(i.e., a UA can choose to ignore them when displaying a link).

3) specify that it only has meaning when a particular application /  
relation invokes its use (none to date).

So far I'm hearing that #1 or #2 is probably the right approach. I  
don't see how we can mandate it.

Thoughts?


On 02/08/2009, at 8:47 PM, Julian Reschke wrote:

> Ian Hickson wrote:
>> ...
>>> Could you please elaborate what the "right" effect is, and how  
>>> current implementations fail for that?
>> Well unless I'm mistaken, if we have a resource A that has:
>>   Link: <B>; rel=stylesheet; anchor=C
>> ...then that means we have a link:
>>   C - stylesheet - B
>> ...which means that applying the style sheet to A would be wrong.  
>> Yet that is what UAs that support Link: would presumably do.
>
> Of the five UAs I checked, two seem to implement the Link header.  
> Both fail to consider the anchor.
>
> To make Link headers useful in processing by HTML user agents, lots  
> of additional implementation work is needed anyway; so I don't see  
> this as a big problem.
>
> That being said, it probably would be good if the spec gave an  
> example that anchor can be more than a fragment identifier, and thus  
> recipients need to handle it -- it's not optional.
>
>>> It appears to me that anchor is not relevant for every single link  
>>> relation, but that doesn't mean it's not useful at all.
>> I don't see how it can't be relevant... if the link relation is  
>> between two resources, then acting as if it was a relationship  
>> between others seems wrong.
>
> Right; it *is* relevant if it's more than a fragment identifier, and  
> it would be good if the spec stated that clearly.
>
> BR, Julian
>
>
>
>


--
Mark Nottingham     http://www.mnot.net/

Received on Thursday, 20 August 2009 02:13:57 UTC