RE: Deprecate Content-Location? (was RE: "Variant" language in Content-Location (Issue 109))

Brian Smith wrote:
> Julian Reschke wrote:
> > Although Content-Location identifies an entity, that 
> > doesn't mean that that entity can't change over time.
...
> That is why I think it is clearer to say "variant" instead of 
> "entity" when describing things that potentially change over 
> time, and say "entity"
> instead of "verssion/instance/value of an entity" to describe 
> particular values of such things. That would allow the 
> removal of the terms "representation," and "entity value", 
> "versions of an entity", and "instances of that entity". 
> (Incidentally, "document" is another term that should be removed.) 

I would like to take this suggestion one step further:

* Keep "entity" as I described it above; a fixed set of header values with a
fixed body.

* Replace all of the following terms with "entity": "entity value,"
"version(s) of an entity," "instances of that entity," "representation",
"variant," and "document".

* Don't define any term for what we usually think of when we say "variant".
In other words, remove the whole *concept* of mutable representations of
resources. Instead, operations that change resources would modify the set of
(immutable) entities that represent that resource.

Here is my alternate proposal for the definition of Content-Location
(completely replacing 14.14):

   6.7.  Content-Location

       The value of Content-Location defines the base URI for
       an entity. 

           Content-Location = "Content-Location" ":"
                             ( absoluteURI | relativeURI )

       Servers MAY ignore the Content-Location header of
       any PUT or POST request entity. Otherwise,
       applications SHOULD use an entity's Content-Location
       value as the base URI when resolving URI references
       in the entity. However, in practice, most applications
       ignore this requirement. To maximize interoperability,
       entities SHOULD NOT have a Content-Location header
       if the Content-Location header would have any effect
       on the resolution of any URI references in the entity.

       The Content-Location value of a response entity is not
       a replacement for the original request-URI.

       Previous versions of this specification recommended
       the use of Content-Location to identify the individual
       "variants" of a resource. Applications MAY continue
       to do so, but the details of this usage are undefined
       by this specification (just as they were left 
       undefined in previous versions). 
       
And then move the following statement to the 
Content-Location paragraph of part 6, section 8:

       A cache cannot assume that an entity with a
       Content-Location different from the URI used to retrieve
       it can be used to respond to later requests on that
       Content-Location URI. 

Thoughts?

- Brian

Received on Wednesday, 6 August 2008 21:12:22 UTC