- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 19 Feb 2012 09:55:08 +0100
On 2012-02-18 14:45, Sven Neuhaus wrote: >>> ... >> >> Stop here. That's not what the fragment identifier is for. >> >> Instead, you could specify the hash as a separate attribute on the >> containing element. > > The relevant section from RFC 3986 reads: > > "The fragment identifier component of a URI allows indirect > identification of a secondary resource by reference to a primary > resource and additional identifying information. The identified > secondary resource may be some portion or subset of the primary > resource, some view on representations of the primary resource, or > some other resource defined or described by those representations." ..but it goes on saying: "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." > This description is not contradicting the use of checksum as fragment > identifiers. They are "additional identifying information." It is contradicting the concept of being defined by the media type. > However, if there is a consensus that checksums shouldn't be stored in > the fragment part of the URL, a new attribute would be a good alternative. > > Regards, > -Sven Neuhaus > Best regards, Julian
Received on Sunday, 19 February 2012 00:55:08 UTC