Re: Link Header draft

Oh - and there's also already an Atom link relations IANA registry,  
so it would require a certain amount of coordination.

What do others think? Should there be a single, flat link relation  
registry?


On 2007/02/11, at 10:34 AM, Mark Nottingham wrote:

>
>
> 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/
>
>


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

Received on Monday, 12 February 2007 08:58:48 UTC