Re: Link Header draft

Mark Nottingham wrote:
> 
> 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?

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

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

<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

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

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

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

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

Received on Monday, 15 October 2007 07:33:42 UTC