Re: Representation of a secondary resource?

Dan, I think I get your point about secondary resources not constituting
a class of resources. It would be helpful IMO if the document mentioned
how (of if), given a URI with a fragID, one can get to a representation
of the resource. 

I believe a reference from 3.1 (or 3.1.1) to "details of handling URIs
with fragment identifiers, IOW getting representation for secondary
resources" pointing to 3.2.1 could solve this, in case that's the way of
getting to a representation of a resource via its secondary resource
identifier (URI with fragID).

If such a link is added, my issue can be closed successfully, and Stuart
will not need to call me. 8-)

Best regards,

Jacek

On Mon, 2004-10-25 at 18:26, Dan Connolly wrote:
> 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... 
>  http://www.w3.org/2001/tag/2004/webarch-20041021/#dereference-details
> 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
>   http://www.w3.org/2001/tag/2004/webarch-20041021/#media-type-fragid
> 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.
> 
>

Received on Wednesday, 27 October 2004 09:36:22 UTC