W3C home > Mailing lists > Public > www-archive@w3.org > April 2009

Re: Review Comments for draft-nottingham-http-link-header-05

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 17 Apr 2009 13:45:34 +0200
Message-ID: <49E86BDE.7050604@gmx.de>
To: "Sean B. Palmer" <sean@miscoranda.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>, www-archive <www-archive@w3.org>
Sean B. Palmer wrote:
> On Fri, Apr 17, 2009 at 11:34 AM, Julian Reschke wrote:
> 
>> The disadvantages are: [...]
>>
>> - incompatibility with RDF properties
> 
> If you want compatibility with RDF properties, the specification will
> have to state that all URI extension relations MUST return a 303 See
> Other response when dereferenced, as a consequence of this finding:
> 
> http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039

Why can an XML namespace be an information resource, and a link relation 
can not? (Noting that the www.w3.org serves namespace documents with a 
status of 200).

I'd rather have this specification not go near this whole discussion 
(and yes, previously discussed in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0226.html>).

> Otherwise, you will have the situation where there can be valid URI
> extension relations which aren't compatible with RDF, and that the
> only way to test will be to dereference and place burden on the
> server.

Can you cite a document that states that an RDF property is not an 
Information Resource?

>> and Atom link relations.
> 
> Atom link relations are IRIs, whereas the Link header extension
> relations only cover URIs. So there's a similar incompatibility case
> here, though at least this doesn't require a server dereference to
> test.
> 
> Overall I see the case that you're making for URIs, but it would be
> great if this could be tempered with some prose that mitigates against
> the inherent disadvantage of using URIs which Anne van K. has pointed
> out.

I happen to agree with that, see Point 2 in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0223.html>.

> ...

BR, Julian
Received on Friday, 17 April 2009 11:46:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:21 GMT