Re: Link Header draft

To revive a thread after letting it sit for a while;

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

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

Later we found that HTML defines their syntax as CDATA (space- 
separated list of link types), unlike 2068, so there may be wiggle  
room here. The real question, I think, is if we allow URIs in there,  
will it break software?

Putting a URI in a link element's rel value seems to be OK with the  
validator;
   <http://validator.w3.org/check?uri=http://www.mnot.net/test/rel.html>

Firefox shows the link in its "page info" listing also. What other  
software consumes link headers in HTML? Does anyone know of any  
software today that consumes link headers in HTTP?

Another difference in their syntax is that Atom links do not allow  
multiple relations per link, while HTML links do. I think this is  
just a serialisation problem; in Atom, if a link has multiple  
relations, you'll just have to repeat the link in the document, once  
for each rel type.

I'd very much like to hear people's thoughts about whether it's OK to  
be changing the syntax of a HTTP header that's defined in 2068's  
"additional features", but not anywhere in 2616.

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

I don't think this is an issue; we can disallow defaulting in the  
header serialisation.

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

This is probably OK; it's pretty declarative.

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

Again, all pretty declarative, although putting a rev on an Atom  
document might be a bit strange. One does start to wonder, however,  
if we'll need a registry for link attributes...

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

If we can get through the syntax issue, this is probably the next big  
question.  HTML defines the profile attribute as its means of  
extensibility/namespacing for link relations. This isn't used much  
AFAIK, except by microformats, where using a profile is optional (and  
AIUI, not very commonly practised). Profile has been dropped from  
HTML5, but it still exists in HTML4.

That said, If we really want link relations to be viable across  
formats, it seems like Profiles need to be deprecated in the long  
term. I.e., you could use them inside HTML documents, but if you  
wanted to surface the links in HTTP headers, you'd need to use URIs  
(or just use registered relations).

Thoughts?

--
Mark Nottingham       mnot@yahoo-inc.com

Received on Monday, 15 October 2007 06:09:54 UTC