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

Regarding 'requested resource', would it be better if we used  
'targeted resource' consistently?


On 23/07/2009, at 8:12 PM, Henrik Nordstrom wrote:

> 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 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/183> 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: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/107
>
> 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 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/69
>>> (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
> discussion.
>
> 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.
>
> Regards
> Henrik
>


--
Mark Nottingham     http://www.mnot.net/

Received on Thursday, 23 July 2009 22:34:48 UTC