RE: Late last-call comment on AWWW

> There is one more that I will mention.  I'm dashing this off 
> hurriedly 
> following a plane journey, so this may not be very well expressed...
> 
> In section 3.3.1, I feel the terminology concerning 
> "secondary resources" 
> is muddled.  The document text (numbered bullets) actually 
> makes it fairly 
> clear that there is no such thing distinguished as a secondary 
> resource.  This same idea is present in the revised URI spec, 
> and I've been 
> uneasy with it there, but I've only just been able to articulate 
> why.  Basically, I think resources are resources, with no primary or 
> secondary distinction.  However, there are primary resource 
> identifiers 
> (URIs without fragments) and secondary identifiers (URIs with 
> fragments), 
> but the form of identifier doesn't somehow make the resource 
> of a different 
> kind, which I think is a conclusion one might draw from the 
> current wording.

Very well put, Graham. 

I like your terms "primary identifier" (URI) and "secondary
identifier" (URIref with fragid) as they nicely correlate
to the use of primary machinery (HTTP) versus secondary
machinery (MIME specific client side processing) when it
comes to accessing representations of resources.

It would also be nice to see more clearly communicated the
fact that representations of "secondary resources" (or 
"resources denoted by secondary identifiers") -- presuming
that such can exist, since a given resource can be denoted
by both a URI and URIref at the same time -- are not 
directly accessible via those "secondary identifiers"
insofar as the primary web machinery (HTTP) is concerned.

A given web client might be able to retrieve a representation
of the resource denoted by the base URI of a URIref, and
from that (somehow, per the MIME type) extract a (kind of)
representation of the secondary resource, but such a process
is completely out of scope insofar as the core architecture
of the web is concerned.

Thus, users should be made aware that choosing to use a URIref 
with fragment identifier to denote a resource can have a significant 
impact on how one might potentially interact with representations 
of the resource in question; essentially isolating that resource
(insofar as use of that particular URIref is concerned) from
the web at large. 

A useful "best practice" could be: when in doubt, use
a URI, not URIref (though I appreciate that not everyone
would agree with such a policy).

Regards,

Patrick

Received on Wednesday, 6 October 2004 08:45:41 UTC