Re: Link Header draft

On 2007/01/29, at 3:11 PM, Roy T. Fielding wrote:
> On Jan 28, 2007, at 3:39 PM, Mark Nottingham wrote:
>> The use cases I've heard of so far are with things like OpenID,  
>> GRDDL, etc.; there may also be use cases with Atom. I do have some  
>> concern about collisions between link relations identifiers in  
>> different formats (because <link> in Atom and HTML, for example,  
>> are slightly different things).
>
> Umm, what makes them slightly different?

1) The syntax of HTML relations are sgml-names (e.g., foo.bar-baz);  
Atom allows an IRI's isegment-nz-nc (in the spec; in the schema it's  
an NCName) *or* an IRI.

2) Atom defaults to "alternate"; HTML has no default.

3) Both Atom and HTML define "alternate", but HTML has additional  
semantics when "lang" or "media" are present.

4) HTML defines "rev", "media" and "charset" parameters for links,  
while Atom does not.

5) Atom defines "title" and "length" parameters for links, while HTML  
does not.


>> While Profile acts as a name space for the link relations, I'm not  
>> certain it'll be respected. Other approaches that come to mind  
>> include;
>>
>> 1) Specifying that the name space of the link relations is media  
>> type-specific, and have a registry for each.
>
> But, they aren't media type specific -- they are just relations.

In a perfect world, I'd agree. In practice, people sometimes want to  
trigger very precise behaviour from a link, and that often is tied to  
a particular representation of the data at the other end.


>> 2) Specifying a whole new header *instead* of Link that allows a  
>> URI for the link relation; establish a registry that the relation  
>> URI is relative to, independent of media type (still allowing them  
>> to use absolute URIs if they like).
>>
>> #1 seems workable, but it does require people to register their  
>> relations.
>>
>> #2 feels OK, *except* that somebody using an Atom link relation,  
>> for example, would have to do something like
>>    New-Link: <http://example.org/>; rel="atom/self"
>> rather than
>>    Link: <http://example.org/>; rel="self"
>> even though in both cases their content would contain
>>   <atom:link href="http://example.org/" rel="self"/>
>
> How about #0:  Specifying the name space as flat, first-come first- 
> served,
> and standards-track.  I would still deprecate the rev attribute, but I
> don't see any real demand for extensible relationship identifiers.

Works for me, as long as the divergence noted above can be papered  
over. I also think there needs to be some room for experimentation, a  
la Atom's use of IRIs.


> I honestly don't care if two technologies choose the same link  
> relation
> name for two different purposes -- that is far less harmful in  
> practice
> than two technologies using different names for the same purpose.
> Groups that want to ensure some degree of uniqueness can always add
> a prefix, like "dc.subject".
>
> Link relations are more like method names than identifiers. We really
> don't want people to think that having unique relations is a good  
> thing.

Generally agreed, although I think there'll be more relations than  
methods pretty quickly. Maybe more like media types *should* be...

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

Received on Saturday, 10 February 2007 23:34:42 UTC