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

Re: [urn] fragment identifiers

From: Peter Saint-Andre <stpeter@stpeter.im>
Date: Thu, 10 Mar 2011 07:37:12 -0700
Message-ID: <4D78E218.1010903@stpeter.im>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Juha Hakala <juha.hakala@helsinki.fi>, urn@ietf.org, "uri@w3.org" <uri@w3.org>
On 3/10/11 7:12 AM, Julian Reschke wrote:
> 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.
>> ...
> <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5>:
> "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.

Another way to put it is that you can have representations or free-form
semantics, but not both (because along with representations come the
constraints of media types, according to RFC 3986).


Peter Saint-Andre

Received on Thursday, 10 March 2011 14:38:35 UTC

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