W3C home > Mailing lists > Public > www-tag@w3.org > February 2009

Re: Link: relation registry and 303

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 11 Feb 2009 11:19:56 +0200
Cc: "Roy T. Fielding" <fielding@gbiv.com>, "www-tag@w3.org WG" <www-tag@w3.org>, Anne van Kesteren <annevk@opera.com>
Message-Id: <044088B1-5A37-4451-A0D7-6EC26A0968C5@iki.fi>
To: Mark Nottingham <mnot@mnot.net>

On Jan 31, 2009, at 02:46, Mark Nottingham wrote:

> On 31/01/2009, at 11:00 AM, Roy T. Fielding wrote:
>
>> HTML5 can just assume they are aliases.
>
> They had a problem with that; i.e., they didn't want to have to  
> consider all of the following as equivalent;
>
> foo
> Foo
> FOO
> http://iana.org/whatever-the-registry-url-is/foo
> http://iana.ORG/whatever-the-registry-url-is/foo
> http://iana.org/whatever-the-registry-url-is/fOO
>
> and so on...
>
> I've always been a bit skeptical of this argument
[...]
> HTML5 folks, if we were to move back to using URIs for all link  
> relations, specifying that they need to be case-normalised before  
> comparison, would that work for you, and if not, why? Is the  
> implementation cost of case normalisation + resolving against a base  
> URI really that high? Is there something I'm missing here?

I'm not speaking for HTML5 folks in general--just for myself.

Requiring colonless rel tokens to expand to URI before comparison  
would not work for me, because allowing "http://iana.org/whatever-the-registry-url-is/stylesheet 
" and "stylesheet" as synonyms in future UAs would be gratuitously  
incompatible with existing UAs that look for "stylesheet" only.

In short, my opinion is what I said at TPAC: If people who want to  
mine HTML documents for data in order to put it into an RDF process  
want to see rel values through URI-tinted glasses, that's fine. They  
can check if the rel value contains a colon and if not prepend a fixed  
string. However, requiring everyone else to process rel values that  
way is not fine.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Wednesday, 11 February 2009 09:20:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:12 GMT