- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 11 Feb 2009 11:19:56 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, "www-tag@w3.org WG" <www-tag@w3.org>, Anne van Kesteren <annevk@opera.com>
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 UTC