Re: link relationship registration

On 10/12/2008, at 10:11 PM, Anne van Kesteren wrote:
>
> If you have
>
>  http://example.com/foo
>  http://example.com/FOO
>
> they would be the same in HTML, but would not be for the Link HTTP  
> header...

Correct.

Ignoring case when comparing the short-form, registered values makes  
sense, and should be covered by

>    HTML defines link relation values as case-insensitive, while the  
> Link
>    header's syntax does not.  Therefore, it is important to case-
>    normalise relation values in HTML before comparing or converting  
> them
>    to Link headers.

although that could use some tweaking.

However, ignoring case when comparing entire URIs (i.e., non-registry  
values) seems like a pathological case. I would posit that people are  
much more aware of case issues in full URIs, because they have to be  
on the Web today anyway, no matter how many corrections their browser  
makes for them.


> (It's also not really clear to me why relationship values are have  
> to be resolved and why we not just use the same rules as we do for  
> namespaces.)

They don't; I think the clarification that Roy requested earlier will  
help here.


> Also, I definitely do not want to start having to implement support  
> for http://www.iana.org/assignments/relation/stylesheet besides just  
> stylesheet. (Not for the Link HTTP header or for the HTML elements.)  
> That's just additional complexity for no gain and will only lead to  
> bugs and differences among browsers.

Not if it's specified sensibly, clearly and unambiguously. The worst  
possible thing to put in here would be advice -- but not a requirement  
-- to use the short form when available.

The other approach is to require the short form to be used when  
registered. However, that seems more of a special case that's likely  
to cause problems; software producing links that wishes to mix  
registered and non-registered relations will have to remember and test  
for the difference, and serialise accordingly. That has the potential  
for bugs and resulting differences among implementations (not just  
browsers).

The other, other approach is to dispense with the notion that a  
registered value is a URI, while still allowing URIs (and only  
absolute URIs, ever) for non-registered URIs. This would necessitate  
that the registered values MUST conform to sgml-name or similar, to  
allow them to be distinguished from URIs, and would preclude some  
future application from using relative URIs as relations (e.g., if you  
had an XML format and used a lot of locally-defined relations, you  
couldn't use XML base to shorten them, because they'd be potentialy  
ambiguous), but otherwise this might be workable.

This latter approach would also make defining case insensitivity for  
registered values easier.

Thoughts (everyone, not just Anne)?

>>> In HTML5 there is no rev "link-param" because (non-academic)  
>>> studies have shown that people do not really know how to use it.
>>
>> See current discussion about deprecating it.
>
> What does deprecating mean here for the various parties (e.g.  
> implementors and authors)?

It depends on where the discussion goes, but right now it looks like  
it means that authors are cautioned not to use it, as it's confusing,  
and implementers may or may not support it at their peril/pleasure.  
The only requirement is that they not blow up when they see a rev (but  
that goes for any unrecognised extension).


>>> In HTML5 media, hreflang, and sizes (just for <link>) also  
>>> influence the relationship. Your draft does not have these "link- 
>>> param"s.
>>
>> Other extensions are allowed; again, see the appendix about use in  
>> HTML.
>
> It says they are believed to be defunct... media is pretty damn  
> important for style sheets at least.

I'll remove the "defunct" language in the next draft.

I'm hesitant to define media in this draft without a format-neutral  
description of its semantics and possible values, but again it is  
accommodated already.


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 10 December 2008 12:57:35 UTC