RE: Link: relation registry and 303

Hello Mark,

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Mark Nottingham
> Sent: 31 January 2009 00:47
> To: Roy T.Fielding
> Cc: www-tag@w3.org WG; Anne van Kesteren; Henri Sivonen
> Subject: Re: Link: relation registry and 303
> 
> 
> 
> 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 didn't read Roy as referring to the Semantic Web community (tho' he might have been).

> > 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.

'original' as in the current round of recent drafts, or original as in when the field was described as an sgml-name?

Anyway, case-insensitive comparison, at least of the final path segment if not the full URI would seem a reasonable pragmatic step.

> 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).

Speaking of "Bifurcation" seems a bit melodramtic - and promulgates a notion of spliting which you earlier said was not your intent.

I suspect that the comparison case your most interested is when registered relationship name are given in the shortened form. Or are you speaking of case-insensitive comparison if given as full URI in rel values. I think I'd discourage the latter - and I'd have to give some thought to whether such case should be regarded as errors, or an unrecognised relation. 


> > 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.

I guess I more of a sem web person, but I don't specially speak for the community. Personnally, (and probably preversely) I'd still take the view that the rel values are URI names for the relations - I'd not be inclined to give up on that view.

Pragmatically, I'd probably (personnally) attribute no particular significance to a 200 or 303 returned by dereferencing the relations full URI name (might special case it for shortnamed rel values anyway) and hope that whatever I got back directly or after redirection had something to say about the relation I'm interested in that I was prepared to believe. ie. I'd probably only believe that the relation was a document if the description I'd obtained explicitly said that it was. I'd ty to be robust to folks not doing the 303 step, even though as things stand at the moment - I'd prefer that they did.

> Cheers,
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 

BR

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 2 February 2009 18:20:48 UTC