W3C home > Mailing lists > Public > www-tag@w3.org > August 2003

RE: Information resources

From: <Patrick.Stickler@nokia.com>
Date: Mon, 4 Aug 2003 11:46:05 +0300
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B5FBC18@trebe006.europe.nokia.com>
To: <connolly@w3.org>, <tbray@textuality.com>
Cc: <www-tag@w3.org>


	-----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:
	you can't GET a representation of that section of the
	document; you can only GET a representation of
	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.
Received on Monday, 4 August 2003 04:46:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:00 UTC