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: John Hall <johnhall@evergo.net>
Date: Thu, 14 Jun 2001 11:51:37 -0700
To: <Edgar@EdgarSchwarz.de>, <ietf-dav-versioning@w3.org>
Message-ID: <000001c0f503$0a981560$0400a8c0@xythosjohnhall>
>> My understanding is that a versioning unaware client should NEVER
have the side effect of deleting version resources it doesn't know
about. The server side concerns Lisa raises are another matter I don't
have the time to discuss at the moment.


You mistake where I am coming from, because you have probably eliminated
a key middle ground from consideration.

I'm not fighting for clients/customers/users that are BLIND to the fact
that things are being versioned.

I'm fighting for clients/customers/users that have tacked on the concept
and simple usefulness of versioned content.  The only thing they care
about, or want to care about, is CHECKIN/CHECKOUT/UNCHECKOUT and "oops,
can I see version 5 please?".

So yes, they know about versions.  And they expect them to get blown
away when they issue a DELETE.  But they are profoundly uninterested in
everything else.

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.
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

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.

Consider the following language:

An implementation MAY support properties-mutable as a default within
auto-checkout.  It is DISCOURAGED.  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.
Received on Thursday, 14 June 2001 14:51:39 UTC

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