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

Re: Link: relation registry and 303

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 31 Jan 2009 11:46:49 +1100
Cc: "www-tag@w3.org WG" <www-tag@w3.org>, Anne van Kesteren <annevk@opera.com>, Henri Sivonen <hsivonen@iki.fi>
Message-Id: <D373688C-E203-4B14-8200-763BEC98BA8F@mnot.net>
To: Roy T. Fielding <fielding@gbiv.com>


On 31/01/2009, at 11:00 AM, Roy T. Fielding wrote:

> On Jan 30, 2009, at 2:25 PM, Mark Nottingham wrote:
>> They were concerned that, historically, link relations have been  
>> compared in a case-insensitive fashion, which makes working with  
>> URIs much more complex. Bifurcating it neatly solves this problem.
>
> At the cost of alienating a group more numerous than HTML5?

Without getting into some comparison of the Semantic Web community's  
size with that of HTML5 (which is a ridiculous discussion on so many  
levels), HTML4 also works this way.

> I don't think that's a good idea.  Why not just require that the
> URI be entirely lowercase

That seems like an artificial and constraining requirement, but it  
does have the benefit of simplicity. However, it would still require  
case normalisation to take place for HTML (4 and 5).

> , or that it can (in this context) be
> compared case-insensitive?

That was the original approach taken.

Bifurcation has the benefit of limiting case insensitivity to just  
registered values, instead of all URIs; I imagine that the Semantic  
Web community would take some issue with that (although I'd love to  
hear feedback from them).

>  The probability that two different
> URIs which differ only by case would, when used in a rel attribute,
> actually refer to two different things is ridiculously small.

Agreed. As above, I wonder how the SemWeb folks would feel about case- 
normalising URIs during processing.

> 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, but those who were  
discussing it at the time (this is in the archives, around the  
November/December 2008 timeframe; e.g., <http://www.w3.org/mid/op.ulx1d6cx64w2qv@annevk-t60.oslo.opera.com 
 >) did seem to come to consensus. I've cc:ed a few of those folks to  
draw their attention to this thread (Anne and Henri, see: <http://www.w3.org/mid/906D6F3A-F031-4993-8F53-F48C9E14A622@mnot.net 
 > and the convoluted thread around it).


> What would be more compelling is if deployed Atom software
> failed to implement the algorithm in spite of its specification.
> If that were the case, then I can see going back to short names.

That's always been the wild card, yes. However, the Atom algorithm is  
already specified in terms of URIs; the smallest change to it would be  
to adopt one of the suggestions you make above. A short name / URI  
bifurcation is actually a bigger change for them.

Personally, I'm not attached to one particular approach, but it seems  
like the chances of making everyone happy on this one are diminishing  
rapidly. I'm not so concerned about that, but I am concerned about  
getting it a) through the standards process, and b) implemented.

So -

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?

SemWeb folks, if we were to do the above, and specify that link  
relation URIs pointed to documents describing the relation, would that  
work for you? If not, why? Please state your answer in terms of issues  
that affect actual implementations using those link relations.

Cheers,

--
Mark Nottingham     http://www.mnot.net/
Received on Saturday, 31 January 2009 00:47:31 GMT

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