W3C home > Mailing lists > Public > uri@w3.org > March 2011

Re: [urn] fragment identifiers

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 10 Mar 2011 15:12:50 +0100
Message-ID: <4D78DC62.2080003@gmx.de>
To: Juha Hakala <juha.hakala@helsinki.fi>
CC: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, "uri@w3.org" <uri@w3.org>, urn@ietf.org
On 10.03.2011 15:04, Juha Hakala wrote:
> Hello,
> Julian Reschke wrote:
>> On 10.03.2011 13:28, Juha Hakala wrote:
>>> ...
>>> Persistent identifiers will be used for multiple purposes, and by the
>>> time we assign e.g. a URN to a resource, we have no idea which
>>> resolution services will be needed in the (distant) future. Lifetime of
>>> a PID may be centuries; applications and the functionality they offer
>>> will change many times during such a period. And eventually even the
>>> copyright protection of a document will expire ;-).
>>> ...
>> I think that statement in itself rules out use of fragment
>> identifiers. At least if you want to stay in sync with the URI spec
>> (RFC 3986).
> Can you explain why this would be the case? Please see below why I find
> it difficult to agree.
> ...


"The semantics of a fragment identifier are defined by the set of 
representations that might result from a retrieval action on the primary 
resource. The fragment's format and resolution is therefore dependent on 
the media type [RFC2046] of a potentially retrieved representation, even 
though such a retrieval is only performed if the URI is dereferenced. If 
no such representation exists, then the semantics of the fragment are 
considered unknown and are effectively unconstrained. Fragment 
identifier semantics are independent of the URI scheme and thus cannot 
be redefined by scheme specifications."

I think this is pretty clear -- if you *can* have representations, 
you're constrained by the media types that are used as representations. 
There's no way avoiding that if you want to stay aligned with the URI spec.

Best regards, Julian
Received on Thursday, 10 March 2011 14:13:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:14 UTC