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