Re: 3.7.4. The link element (Spec Review)

Ian Hickson wrote:
>> "The type of link indicated (the relationship) is given by the value of 
>> the rel attribute, which must be present, and must have a value that is 
>> an unordered set of space-separated tokens."
>>
>> This reads funny; how can a single instance of a set be unordered? 
>> Unordered with respect to what ordering? (yes, I understand what it is 
>> intended to say, but then please just state that the ordering doesn't 
>> carry any semantics).
> 
> What should I call the type, if not "unordered set of space-separated 
> tokens"?

You could call it a "set of tokens", and then go on saying that ordering 
is irrelevant. (isn't that always the case for sets, anyway?)

>> "Two categories of links can be created using the link element."
>>
>> I think other reviewers commented on this earlier. The way this 
>> distinction is introduced is a bit confusing and may not be needed at 
>> all.
> 
> Could you elaborate on what exactly is confusing? I'm not sure how to 
> improve it, because I don't really know what is wrong.

I wrote this a long time ago.

Looking at it right now, I guess I was (and still am) confused because 
of the distinction between "links to external resources" and "hyperlink 
links".

What is it good for?

>> "One element can create multiple links (of which some might be external 
>> resource links and some might be hyperlinks). "
>>
>> How?
> 
> I've tried to clarify this; is it clear enough now?

So it's because of multiple rel values?

>> "If the attribute is omitted, then the UA must fetch the resource to 
>> determine its type and thus determine if it supports (and can apply) 
>> that external resource."
>>
>> That reads as if the UA must fetch the resource, which of course it 
>> doesn't have to. It could just ignore it as well, right?
> 
> I've tried to clarify it.

ok.

>> "Some versions of HTTP defined a Link: header, to be processed like a 
>> series of link elements. When processing links, those must be taken into 
>> consideration as well. For the purposes of ordering, links defined by 
>> HTTP headers must be assumed to come before any links in the document, 
>> in the order that they were given in the HTTP entity header. Relative 
>> URIs in these headers must be resolved according to the rules given in 
>> HTTP, not relative to base URIs set by the document (e.g. using a base 
>> element or xml:base attributes). [RFC2616] [RFC2068]"
>>
>> I'm a bit concerned because the spec seems to step into the HTTP WG's 
>> area. So is this implemented in today's user agents? If not, how did it 
>> get in here? (you know, design principles and so on :-)
> 
> Yeah, it's implemented by at least Mozilla, and also, I believe, Opera. 
> The above is actually actively trying to not step on the HTTPWG's toes, 
> I'm just trying to make sure that there are no cracks between the two 
> specs where something (e.g. the processing order) might slip through.

ok.

>> If the HTML WG thinks that support for the "Link" header, defined in 
>> RFC2068 and dropped from RFC2616, should be mandatory in HTML5 UAs, then 
>> I strongly recommend raising this issue on <mailto:ietf-http-wg@w3.org>, 
>> so that the header gets considered for re-inclusion into RFC2616bis.
> 
> Could I ask you to do these honours? It would be great to have someone who 
> can coordinate with the HTTP WG.

I'm much more active in the HTTP WG, so it would probably look a bit 
funny if I would try to make a statement on behalf of the HTML WG over 
there :-).

BR, Julian

Received on Friday, 9 May 2008 08:22:16 UTC