- From: Hammond, Tony (ELSLON) <T.Hammond@elsevier.com>
- Date: Fri, 30 Jan 2004 14:04:42 -0000
- To: 'Patrick Stickler' <patrick.stickler@nokia.com>
- Cc: www-rdf-interest@w3.org
> The problem is that the first request is at risk of becoming > > GET http://example.com/2004/01/people HTTP/1.0 > > because alot of software think (IMO rightly so) that the > fragment identifier is relevant only within the context > of interpretation of a representation returned by the > base URI. Hi Patrick: Just wanted to point out that 2396bis has a different take on fragment identifiers which is somewhat broader than proposed in 2396 which is more or less restricted to client addressing on a returned representation (see extract below). Note that the INFO URI scheme is aligned with 2396bis and makes use of fragment identifiers to identify secondary resources even though there are /no/ representations returned since INFO URIs are non-dereferenceable (by specification). Sorry to belabour this point on fragment identifiers, but we were hoping to get some (constructive) feedback on the uri list though got no response over last couple months on our posting of the 2nd revision. Regardless of the strengths or merits of the INFO URI scheme there are at least some interesting URI architecture details that could be considered. Tony "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. <snip/> However, if that URI is used in a context that does call for retrieval and is not a same-document reference (section 4.4), the fragment identifier is only valid as a reference if a retrieval action on the primary resource succeeds and results in a representation for which the fragment identifier is meaningful. "
Received on Friday, 30 January 2004 09:06:25 UTC