W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Re (2): Removing a resource: A compromise that satisfies?

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 14 Jun 2001 15:50:49 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2485@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: Edgar@EdgarSchwarz.de [mailto:Edgar@EdgarSchwarz.de]

   Clemm, Geoff wrote:

   > How about an alternative approach:
   > Add a new postcondition to DELETE that says:
   > "If a server does not support the version-history feature,
   > then it MAY automatically delete a version resource if that
   > version no longer appears in the DAV:version-tree report
   > of any version-controlled resource."

   Here you draw a fine line between explicitly having a version
   history ('support the version-history feature') or implicitly
   having it ('appears in the DAV:version-tree report') because the
   version tree is the fundamental data of a version history.  Or
   isn't it ?  To me it seems that VERSION-CONTROL is providing a
   version-history light in the form of the version-tree report. Does
   that make sense ?

Yes, there is always a version history for a version-controlled
resource, but the version history is only exposed in the URL namespace
if the server supports the version-history feature.

The reason why I worded the postcondition this way is that if
there is no version history resource, then the versions are
scattered randomly around the URL namespace, and there is no
standard way for a client to find them again.

In contrast, if a server supports the version-history feature,
a client can use OPTION to request the version-history-collection-set,
and then find old version histories in that collection.

With all that said, we are still damaging interoperability for
versioning aware clients, because URL's to versions can be stored in a
variety of places, and allowing a server to blow away a version just
because the version-controlled resource was deleted makes it hard to
write a versioning-aware client with predictable behavior (blowing
away data has too much of an impact on the user to have it be
unpredictable from server to server).  So if anyone wants to reject
this compromise on the grounds that we should *never* allow a 
server to blow away versions because of a VCR deletion, please
do so (:-).

Received on Thursday, 14 June 2001 15:51:24 UTC

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