W3C home > Mailing lists > Public > public-webarch-comments@w3.org > October 2004

Re: Representation of a secondary resource?

From: Dan Connolly <connolly@w3.org>
Date: Mon, 25 Oct 2004 11:26:44 -0500
To: Jacek Kopecky <jacek.kopecky@deri.org>
Cc: public-webarch-comments@w3.org
Message-Id: <1098721604.14529.786.camel@dirk>
On Wed, 2004-10-20 at 09:50, Jacek Kopecky wrote:
> Dan, 
> thanks for the reply. Most of it satisfies me, with one exception. 
> Section 3.1.1 linked below mentions neither fragment IDs nor secondary
> resources, but in HTTP the fragment ID is not a part of the URI used in
> the HTTP request. Currently, there is no space in the eight points in
> 3.1.1 where fragment ID would be handled. 

Isn't there? Let me look... 
Oh. you're quite right.

> It could be a part of point 8, but it currently says the agent
> interprets the representation, with no apparent room for generating out
> of that a representation of the secondary resource, according to the
> fragment handling described by the media type etc.

I suppose the relevant section is actually
  3.2.1. Representation types and fragment identifier semantics
Is that where we started? No... your original comment
refers only to section 2.6. Perhaps the text in 3.2.1 helps?
It could perhaps be clearer, but we tried hard and this is the
best we came up with. We've considered diagrams and such, but
haven't managed to produce them.

> So currently section 3.1.1 basically implies that secondary resources
> don't have representations, at least in HTTP. Whatever the position of
> the TAG on this, it should be mentioned explicitly in 3.1.1.

You're using "secondary resource" as a class. Were we not sufficiently
clear that it's not a class of resources, but that primary/secondary
is a relationship between resources?

Whether a resource has a representation is orthogonal to whether
it is primary or secondary.

Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Monday, 25 October 2004 16:25:30 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 9 February 2023 11:03:00 UTC