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
> 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
Received on Wednesday, 11 February 2009 09:20:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:00 UTC