RE: Late last-call comment on AWWW

In short: "secondary resources", or resources which are solely 
denoted by URIrefs with fragment identifiers ("secondary identifiers"), 
are second class citizens of the web, and users should be made
well aware of that fact.

Regards

Parick


> -----Original Message-----
> From: public-webarch-comments-request@w3.org
> [mailto:public-webarch-comments-request@w3.org]On Behalf Of ext 
> Sent: 06 October, 2004 11:45
> To: gk@ninebynine.org; public-webarch-comments@w3.org
> Subject: 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:51:37 UTC