Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

Ian Hickson wrote:
>>> I think for the best compatibility with legacy implementations, the 
>>> spec should say that there must only be one occurance of each 
>>> attribute, and that multiple link types in one Link: header should be 
>>> listed in one rel="" attribute. (That is, only allow rel="a b", not 
>>> rel=a;rel=b.)
>> Do you have data to back this up?
> 
> As far as I can tell, Mozilla only supports one of each attribute. Are 
> there UAs that support more?
> ...

I think changing the definition of the header (as compared to the 
definition in RFC 2068) based on a single, known-to-be-incomplete 
implementation is a bad idea.

Does Mozilla support the Link header for any relation besides stylesheet 
anyway?

> Given that HTML and Atom only allow one of each attribute, I think we're 
> far less likely to have bugs if we say that all but the first occurrance 
> of each attribute is just ignored.

I'm not convinced that constraining the header syntax based on other 
languages makes a lot of sense; it's a distinct serialization anyway, 
and needs to be treated that way.

What we need for interop are proper test cases, not dumbed down syntax.

>> I'm concerned that this would disallow internationalisation of title, 
>> for example (e.g., you couldn't express both an english and a spanish 
>> title for a link).
> 
> That sounds like one of those things that looks good on paper but doesn't 
> really ever translate to implementations. Are we really expecting authors 
> to provide multiple titles per link? How would that work in UI?

The UI would select the language best suited for the user.

> ...
> When you mirror a page ("Save As ... Complete" or "Save As ... Archive"), 
> external resource links are those that are fetched and included with the 
> source document, whereas hyperlinks are those that are considered to be 
> separate.
> 
> A style sheet, for instance, is an external resource link. A regular <a 
> href=""> is just a hyperlink.
> ...

It would be great if you could add that explanation to the HTML5 spec 
(last time I checked I didn't understand it).

That being said - this is an interesting proposal; I'm however not sure 
that it's always possible to mandate one or the other.

>>> Similarly, the registry should define whether or not link relations 
>>> are allowed at the document level (<link rel>, Link:) and at the 
>>> phrasing level (<a rel>, <area rel>). Some types in HTML5 only apply 
>>> to one or the other.
>> That's a job for HTML5 as an application of the relations, not the 
>> registry.
> 
> So every time someone adds something to the registry, we have to update 
> HTML5 to say whether that keyword can be used with HTML?

If you are interested in making that decision, yes. It's the same 
situation for other markup languages, and it would be hard to require 
these considerations to be there for every single language relations can 
be used in.

> ...
> Why should HTML5 define how rel=stylesheet of a CSS file applies to an XML 
> document? That doesn't sound right at all.
> ...

Does it apply? I think that still needs to be defined; potentially while 
revising xml-stylesheet PI spec.

> ...
>> In the IETF, IANA is the mechanism for managing registries like this.
> 
> Regardless of who manages the registry, I would like to request that the 
> registration mechanism be made significantly simpler than the one 
> described in the spec.

    Relation types are registered on the advice of a Designated Expert
    (appointed by the IESG or their delegate), with a Specification
    Required (using terminology from [RFC5226]).

Which part do you think is problematic, and how would you like to see it 
relaxed?

 > ...
> On Wed, 19 Aug 2009, Eran Hammer-Lahav wrote:
>> Combining rel values is an awful idea. If someone wants 'up up up' they 
>> should define a rel value of it like up-n (up-1, up-2, etc.). Being able 
>> to indicate multiple relation types for a given link is an important 
>> part of the link architecture and clients should not need to look for 
>> how rel values change the meaning of each other.
> 
> We're past this already with rel="alternate stylesheet", and to be honest, 
> I don't really see what's that wrong with it, except for the overloading 
> of the keyword "alternate".

What's wrong with it is that it it's an exception; it's much simpler to 
think of relations as white-space separated strings that are independent 
of each other.

"alternate stylesheet" is legacy HTML needs to continue to support, but 
that doesn't mean that adding more of these exceptions is a good idea.

> The main advantage of rel="up up up" rather than rel="up3" is that for UAs 
> that only need to know that the link is an "up" and don't care about how 
> far "up" it goes, the keyword automatically works -- you don't have to do 
> rel="up up3". Also, it means that we don't have to register an infinite 
> number of keywords for all possible depths.

Are there UAs that already support "up up" the way you defined it? How 
did that extension make it into the spec anyway?

Also, you don't need an *infinite* number, just a sufficiently big one.

Best regards, Julian

Received on Sunday, 30 August 2009 10:01:40 UTC