Re: requested resource / entity / representation / variant again..

tor 2009-07-23 klockan 10:15 +1000 skrev Mark Nottingham: 
> I had a quick look through the drafts, and found only one place where  
> "requested resource" means anything other than "the resource  
> identified by the target-URI (regardless of conneg)":
> p3 3.2.1:
> > Content-Encoding may be used to indicate any additional content  
> > codings applied to the data, usually for the purpose of data  
> > compression, that are a property of the requested resource. There is  
> > no default encoding.
> Here, conneg does (obviously) need to be taken into account (and I've  
> created <> to  
> track this).
> Did I miss any?

I have not done a full investigation to be honest. Just did a quick
reading and noticed that it is obvious the language used is still quite
inconsistent and ambiguous and want to kick the discussion alive again
at the broader scope. This is an issue that really needs to be solved
top-down by first defining and agreeing on a terminology drawing out the
map we work within and then applying it consistently to the documents
and would even argue that it's one of the more important tasks for
HTTPbis to resolve.

> In other places where "requested resource" is used I think it is  
> appropriate and switching to "requested representation" (or whatever)  
> would be a mistake; e.g., the last-modified time *is* a property of  
> the resource as a whole, not a specific representation. We do have a  
> related open issue here, tangentially: < 

Switching to variant here as the term is still defined for the purpose
and imho describes the thing reasonably well.

Last-Modified, ETag etc is a properties of the variant, not the URI
resource as a whole.  For example changes to the English variant do not
automatically means the Swedish variant change as well. Nor do a
detected change to one variant invalidate the other known variants of
the same URI. Each variant of a URI resource MAY be identified by a
unique URI as indicated by Content-Location if desired (see also below).

The conditionals all operate on the variant, and not the resource as a
whole. This is simply from the fact that the information they are based
on is that from a variant (Last-Modified, ETag) and not from the
resource as a whole where there may be many different such tuples one
for each variant.

Part of the issue here is that some operations operate on the variant,
while some operations operate on the URI resource. For example GET/HEAD
always operate on a variant, while PUT & DELETE operate on the URI
resource. Conditionals however all operate on the requested variant
which complicates life somewhat for the methods operating on URI
resources if applied to a resource having content negotiation.

As one way to resolve this for those methods HTTP provides the option to
use Content-Location to identify a specific variant, enabling DELETE and
friends to operate on that specific variant by switching to the
variant-specific URI as learned from a GET/HEAD operation.

For DELETE I can perfectly well imagine there is different
implementations out there operating either on the resource or the
variant. In fact I would probably expect most to operate on the variant
and not the resource if at all accepted on a negotiated resource.

> The only one where I had to stop and think was in p2 3.2.1 (semantics  
> of 200 for a GET, as H points out); however, that's probably dependent  
> upon the resolution of < 
>  > (which accounts for many of the surviving uses of "variant", BTW).

Indeed, and #109.

We need to settle on one terminology which describes these aspects
reasonably well, and use it consistently.

> I've put a note in #69 to have a look at p2 3.2.1 to revisit this  
> section as part of that issue's resolution. If you can find other  
> places like that, please add them (or send to me).

We should settle on the language/terms first, then look over the
document where [requested] resource / variant / entity /
representation / response etc and their plural forms is used and change
as appropriate. But until we have settled on a language I can only point
out examples of how the existing language is used inconsistently using
the same terms but not really meaning the same thing or where the use
does not match current definitions.

In most cases it will be trivial (editorial) to select the proper term
for the section in question once we have settled on the terms.

Some sections such as Content-MD5 and 206 may need a little more
discussion but such discussions is best done after we have all settled
on the terminology or it will just drain energy from the terminology

wait.. I withdraw that.. 206 is an important parameter to include in the
terminology discussion just as content negotiation is (beware, there is
a a whole can of worms there). But Content-MD5 should wait a bit imho.

> I agree that conneg would benefit if it were mentioned that it's  
> scoped to a requested resource.

I am sorry, but what exactly do you refer to by "requested resource"
when there is content negotiation?

> All of that said, I'd very much like to see us take a systematic  
> approach to determining the scope (server/resource/representation/ 
> response/etc.) of metadata in the spec, because IME it's often been  
> misinterpreted, and sometimes led to interop problems.

Which at the heart is what this is all about.


Received on Thursday, 23 July 2009 10:13:41 UTC