W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

RE: Issues, Issues, ???

From: <Tim_Ellison@uk.ibm.com>
Date: Thu, 21 Dec 2000 11:39:55 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569BC.0040155B.00@d06mta07.portsmouth.uk.ibm.com>

> My plea is to let us manage our own namespaces.  Although
> it is not technically difficult to add a GUID to a URL,
> we consider that to be really ugly in a URL that we expect
> will be visible.
> What if this requirement is dropped from the spec? Reuse
> may happen, but it will not be frequent.  The client can
> use ETags.  Interoperability is not threatened.

Mutable versions aside, the defining characteristic of a version is that
its content and dead properties do not change.  This stability is relied
upon in a number of cases in order to reconstruct previous states.  In
addition there are a number of cases where the only usable reference to
these stable states is a URL.

> A client must deal with versions the way it deals with any
> resource:

Disagree.  Versions are special, that's why we are here.  They MAY be dealt
with like any other resource, but they have specific characteristics that
can be relied upon.

>  - if it has never before retrieved the body, it has NO WAY
> of knowing whether the body has changed, and has NO REFERENCE
> POINT against which to compare that anyway!  It's meaningless
> to say that the content "shouldn't have changed" since a client
> which has never before seen the content can't tell the difference.


>  - When it does retrieve the body, it should retrieve the ETag.
>  - When it wants to see if the body has changed, it should
> compare the ETag.

Disagree.  In compound documents, server-side includes, HTML anchors,
editors, etc. there is no provision for storing a URL-ETag tuple.  To
preserve those specific characteristics of a version in these situations
requires a URL whose defining characteristic is that the contents and dead
properties (of the resource) do not change.

Received on Thursday, 21 December 2000 06:41:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC