RE: Information resources

 

 -----Original Message----- 
 From: ext Dan Connolly [mailto:connolly@w3.org] 
 Sent: Tue 7/29/2003 8:10 PM 
 To: Tim Bray 
 Cc: WWW-Tag 
 Subject: Re: Information resources
 
 Take that URI as an example:
   http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1
 you can't GET a representation of that section of the
 document; you can only GET a representation of
   http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
 and look inside to see what it means by #sec10.2.1 .
 
 

And this is *precisely* why I consider URI references with fragment identifiers to be wholly unacceptable for denoting resources in general -- because one cannot get a representation of the *resource* denoted, but of some other resource denoted by the base URI (which may or may not have any relationship to the first resource) and one must then, outside the scope of HTTP entirely and depending on a myriad of MIME types, extract what might be a representation of the resource as a fragment.
 
No thanks.
 
Fragment identifers are for identifying fragments of representations. Period. If they denote anything, they denote the logical/functional fragment of the representation. And even that is problemmatic since the interpretation of the same fragment identifier may vary substantially between MIME types, and when conneg comes into play, the semantics of the fragment identifier becomes very tricky to nail down. (the RDF interpretation based on positing a special, abstract RDF/XML representation just smells too much like a hack, and I wonder if/how it will stand up over time...)
 
Here's a "best practice" I can strongly recommend:
 
If you want to denote a resource with a URI, and wish to be able to obtain representations of *that* resource *specifically* via that URI using HTTP, then use an http: URI without any fragment identifier. Do so no matter what the nature of the resource is, whether it is abstract, concrete, digitized, whatever.
 
Regards,
 
Patrick

Received on Monday, 4 August 2003 04:46:10 UTC