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 17:48:26 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E248A@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org

   From: John Hall [mailto:johnhall@evergo.net]

   A similar issue arises when I bring up the topic of properties.
   The issue isn't the 'burden on the server' from implementing
   versioned properties.  The issue is customers and users that say
   "but why on earth would anyone want to do that?".  From my personal
   perspective, as someone who has been using code source control for
   a decade, I'm close to that position myself.  Not fully, since I
   understand that you folks want that behavior.  But with the
   exception of narrowly defined sets of properites (which ought to be
   declared) it isn't something I want / need / would use and I'd
   rather not have my server resoruces devoted to it.

From a historical perspective, you only had content (and a few
system defined live properties), not dead properties, so you can't
use that as an indication one way or another that if you had dead
properties, whether you would want them under version control or not.

   And even if I
   have a system that wants to version properties, I would *really*
   object to creating a new version just because a property changed.

Based on what usage of dead properties?  I'm sure one can imagine
some, but they would need to be compelling to complicate the
protocol in this way.

   Surely I'm not the only user in the universe that feels that way.
   Perhaps someone can come up with a way that you don't have to support
   which would make the current-checked-in-properties mutable.  <!ELEMENT
   properties-mutable EMPTY> within auto-checkout would do it.

There are a variety of interesting meta-information that you would
like to say about properties ... mutable version specific dead
properties is just one of them.  But the consensus of
the working group the last time this was discussed was that this
needed to be worked out in the context of a general property metadata
proposal, and not as a special one-off case for this particular
property behavior for the versioning protocol.

   Consider the following language:

   An implementation MAY support properties-mutable as a default within
   auto-checkout.  It is DISCOURAGED.

Usually you deprecate old functionality that turns out not to have
been a good idea, not new functionality (unless you knew from the
beginning wasn't a good idea, but then why add it :-).

   If present, an implementation MUST
   support removing the element so that clients who do not wish any
   properties to be mutable may protect themselves against this server
   option.  An implementation MAY NOT allow the element to be set.
   IF the element is present then the currently checked in versions
   properties are mutable and may be changed by a PROPPATCH without
   creating a new version.  If the VCR is in an unlocked state, a PROPPATCH
   will mutably change properties if unlocked-update AND properties-mutable
   are present.  In the locked state, a PROPPATCH will mutably change
   properties if locked-update AND properties-mutable are present.

The auto-version stuff is bad enough without this ... we don't want to
make it any worse unless there is a really compelling use case for it.

Received on Thursday, 14 June 2001 17:43:00 UTC

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