Subject: Re: Link Header draft

From: Mark Nottingham <[email-masked]>
Date: Mon, 15 Oct 2007 16:07:43 +1000

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       [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Mon, 15 Oct 2007 09:33:15 +0200

Mark Nottingham wrote:
>> 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?
> 
> software consumes link headers in HTML? Does anyone know of any software 
> today that consumes link headers in HTTP?

There are multiple FF extensions for that, one is "Link Widgets" 
(<https://addons.mozilla.org/en-US/firefox/addon/2933>).

It displays the link, and picks the full URI as link name. It probably 
should use the title when available, but it doesn't... (reported as 
enhancement request).

> 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 

<http://tools.ietf.org/html/rfc2068#section-19.6.2.4>.

This seems to be dependent on the issue whether we want to use a flat 
namespace, or allow URIs as relations. If we use URIs, then we'll have 
to introduce them either in the link header itself

> ...
 > ...

The current editor's copy of HTML5 does not define "rel" and "charset" 
anymore.... (<http://www.w3.org/html/wg/html5/#the-link>).

>> 5) Atom defines "title" and "length" parameters for links, while HTML 
>> does not.
> 
> document might be a bit strange. One does start to wonder, however, if 
> we'll need a registry for link attributes...

HTML defines "title" for *all* elements, see 
<http://www.w3.org/TR/html4/sgml/dtd.html#coreattrs>).

>>> 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
>> over. I also think there needs to be some room for experimentation, a 
>> la Atom's use of IRIs.
> 
> AIUI, not very commonly practised). Profile has been dropped from HTML5, 
> but it still exists in HTML4.

Please keep in mind that it's inaccurate to assume that *anything* has 
been decided in the context of HTML5. The WG is still working on Design 
Principles :-).

That being said, the current state of "profile" (not being included in 
the editor's current draft) is an open issue and no decision has been 
made about it. I node that the MF people recommend using it, and that 
GRDDL (a recent W3C rec) needs it.

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

As far as I understand, the main issue with profiles is scoping. So it 
allows disambiguating two terms, but only as long as you don't need to 
use them both on the same resource.

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 15 Oct 2007 10:39:36 +0200

> anymore.... (<http://www.w3.org/html/wg/html5/#the-link>).

You mean "rev".

(And yes, nothing has been decided yet about HTML 5. This will probably  
remain so until it hits CR in 2012 or something...)

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

---

From: Ian Hickson <[email-masked]>
Date: Mon, 15 Oct 2007 08:40:04 +0000 (UTC)

On Mon, 15 Oct 2007, Julian Reschke wrote:
> >
> > > 4) HTML defines "rev", "media" and "charset" parameters for links, while
> > > Atom does not.
> 

It does define "rel" -- but it doesn't define "rev"; we haven't included 
it because typos are too common between rel and rev. As shown here. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Julian Reschke <[email-masked]>
Date: Mon, 15 Oct 2007 12:26:09 +0200

Anne van Kesteren wrote:
> 
> On Mon, 15 Oct 2007 09:33:15 +0200, Julian Reschke 
> <[email-masked]> wrote:

Right,

> remain so until it hits CR in 2012 or something...)

Well, right *now* it's not even a Working Draft.

BR, Julian

---

From: Ian Hickson <[email-masked]>
Date: Mon, 15 Oct 2007 19:31:04 +0000 (UTC)

On Mon, 15 Oct 2007, Julian Reschke wrote:
> >
> > (And yes, nothing has been decided yet about HTML 5. This will 
> > probably remain so until it hits CR in 2012 or something...)
> 

It's not a _W3C_ working draft, indeed. (It is, however, a WHATWG working 
draft, and has been for some time.)