Re: HTTP 1.1 document terminology.

hallam@w3.org:
>
>[Warning... Philosophy flame comming]
>
>Summary of note, this is not the time to open up this can of
>worms. The wording in the spec may appear broken but its best not to
>change it this close to the deadline.

The wording is broken, and I suggest it is mostly _changed back_ to
the wording in the Monday 1.1-02 draft. Specifically:

resource -> a thing identified by an URI, as in 1.1-02

entity  -> defined by Jeff's wording for entity instance

resource entity -> defined by Jeff's wording for entity/the
                   the current wording for resource entity
                   (THESE THINGS DO NOT NEED TO HAVE THEIR OWN URIs!)

(I'd rather have a different word than resource entity.  What about
`entity source'?  The idea is that the entity source can generate both
full and range entities.  Range entities add additional complexity
which is not reflected well in the new terminology definitions.)

generic resource/varying resource ->
    (as in my Vary header section:)

    A resource is currently generic if it currently includes a Vary or
    Alternates header in its 200/206 responses.  

(Note: philosophically speaking, the above is an empirical definition:
generic resources are defined by _the observable things they do_, not
by what they _are_ or _mean_.  This may seem a bit circular to
neo-Platonists, but it is the only way to stay clear of the
philosophical problems Phill has described with so much detail. It is
OK to add some lines to the definition about what genericity would
mean in a Platonic sense, but only to help implementers form a mental
model, not as a way of defining the protocol feature.)

(Note: as I said in my previous message: genericity is a _binary_
predicate in the 1.1 spec.  The words about `successively specific
resources' are confusing and must be deleted.  As Roy also noted,
allowing time as a dimension of genericity makes the terminology
useless for 1.1)

    A generic resource has as set of resource entities associated with
    it, which can change contents though time.  A generic resource can
    at any point in time change into a specific resource.  This change
    will be reflected by the absence of Vary and Alternates headers in
    subsequent responses.

specific resource/plain resource ->

    A resource is currently specific if it not currently generic.
    ....

    A specific resource can at any point in time change into a generic
    resource.  This change will be reflected by the presence of a Vary
    or Alternates headers in subsequent responses.

negotiable resource -> is the same as a generic resource.  Use of this
term is must be avoided everywhere except in the content negotiation
section.

(Note to Larry Masinter: It is true that 1.0 servers manage to provide
`negotiation' by using `dynamic resources' that always generate a
non-cachable response tailored to the request headers on the fly.
Such dynamic resources include an Expires: <yesterday> header (or omit
Last-Modified headers or use access authentication) to avoid caching,
but they do not send a Vary or Alternates header, so they cannot be
called specific/varying resources, and thus cannot be called
negotiated under 1.1.)

variant -> THIS WORD IS NOT NEEDED AND BEST DELETED.
           (a variant can be interpreted as a container which
           successively contains related resource entities.)

My analysis of why we do not need the term variant: we introduced this
term to talk about variant-IDs.  However, the only semantics
associated with variant-IDs is that they can be used for cache
replacement.  Therefore, you can rename `variant-ID' to
`replacement-key', which eliminates the problem of having to talk
about what a variant is.  Rewriting the spec to never use the word
`variant' is not that hard.  Note that I managed not to use it in the
Vary header section.  All 1.1 mechanisms can be described without
referring to the concept of `a container which successively contains
related resource entities'.

Going through the whole spec for the purpose of removing the word
`variant':

      3.14 Variant IDs

      Variant-IDs are used to identify specific entities (variants) of a
      varying resource; see section 13.8.3 for how they are used.

            variant-id = quoted-string

      Variant-IDs are compared using string octet-equality; case is
      significant.

can be renamed to replacement keys:

            replacement-key = quoted-string


      3.16 Variant Sets

      Validator sets are used for doing conditional retrievals on varying
      resources; see section 13.8.3.

            variant-set = 1#variant-set-item
            variant-set-item = opaque-validator ";" variant-id

can be renamed to validator-sets.

      13.7.5 SLUSHY: Scope of Expiration

      HTTP/1.1's expiration model is that as soon as any variant of a URI
      becomes stale, all variants becomes stale as well.  Thus, _freshness_
      applies to all the variants of URI, rather than any particular variant.
      Dates and expires etc. apply to any cached variant that a proxy might
      have with a URI and not just the one particular entity.

EEK!  13.7.5 is plain wrong, and must be deleted.  Why did I not find
this before?

      13.8 Caching and Content Negotiation
      The HTTP content negotiation mechanism interacts with caching in
several
      ways:

        .  A varying resource (one subject to content negotiation) may be
           bound to more than one entity. Each of these entities is called a
           _variant_ of the resource.
            ^^^^^^^ 

replace variant by `resource entity' or whatever term you come up
with.  Replace variant-ID with `Cval header value' most of the time.
Note that only `Cval header values' which include `variant-IDs' can be
sent in `Unless-<something>' headers for requests on varying
resources.

      13.12 SLUSHY: Cache Keys

Delete completely, except for 13.12.4.

      13.20 Cache Replacement for Varying Resources

Use the text I posted on the list recently, with every `variant-ID'
replaced by `replacement-key'.

Koen.

Received on Tuesday, 30 April 1996 04:04:45 UTC