Re: MKRESOURCE results
jamsden@us.ibm.com
Tue, 21 Dec 1999 12:51:27 -0500
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525684E.00679764.00@d54mta03.raleigh.ibm.com>
Date: Tue, 21 Dec 1999 12:51:27 -0500
Subject: RE: MKRESOURCE results
b) is like a special case of d). I prefer d). It seems to me that
versioning a segment of the namespace (i.e., a collection) and versioning
the contents of a resource referred to by one of the members of that
namespace are independent things. Why do we need to couple them together? I
understand that it would not be possible to create a baseline of a
collection that contained unversioned members, nor could such a collection
be added to a configuration. But that's OK. It just gets us out of the
initial state problem.
Tim_Ellison@oti.com (Tim Ellison OTT)@w3.org on 12/21/99 10:21:14 AM
Sent by: ietf-dav-versioning-request@w3.org
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
cc:
Subject: RE: MKRESOURCE results
<geoff>
I prefer a third alternative: one revision (with default values for all
properties and an empty body) and one working resource (checked out from
that revision. It is the working resource that the PUT or MKRESOURCE is
applied to.
</geoff>
This is going to leave lots of clutter in the version history.
Essentially,
every versionable type that was created in a versioned collection will have
a phantom revision that was never intended to be part of the development
ancestry. I can imagine clients trying to hide that revision when giving
users the option to rollback to an earlier state.
Summary of options thus far,
(a) one revision, no working resource,
(b) one working resource, no revisions,
(c) one revision, one working resource,
(d) change the rules for members of versioned collections, (i.e., no longer
have to be versions.)
I don't like any of them! but I like the spirit of (b).
Tim