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
