RE: Deleting versions

"Lisa Dusseault" <lisa@xythos.com> wrote:

> Geoff said:
> >
> > I agree with Tim's responses.  To make sure that nobody misunderstands
> > the semantics of the method preconditions and postconditions, I propose
> > to modify section 1.6 to read as follows:
> >
> ...
> >
> > Lisa: Does this address your concern?
>
>
> It's an improvement in the definition of post/pre-conditions, certainly.
> There are still a couple of issues remaining:
>
> 1.  By having (DAV:must-be-root-version) as a postcondition, you're
> preventing an implementation from deleting the last remaining version
> from a version history.  I assume this is your intent?  Like so many
> other things, it must be inferred rather than finding it stated in
> the text.  *sigh*

The entire postcondition statement is:
     (DAV:must-be-root-version): If the root version of a version
     history is deleted, there MUST be another version that is the
     new root version, i.e. that is the ancestor of all other versions
     in the version history.

I think it is easily implied that you cannot therefore delete *all*
versions of a version history and satisfy this postcondition; but I have no
objection to adding to this statement if you really think it needs it.

> 2.  I don't think the issue of a version-controlled-resource with zero
> versions is sufficiently addressed.  For your convenience, here's the
> section from 2518:
>
>    A write locked null resource, referred to as a lock-null resource,
>    MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to
>    any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND,
>    LOCK, and UNLOCK.  A lock-null resource MUST appear as a member of
>    its parent collection.  Additionally the lock-null resource MUST have
>    defined on it all mandatory DAV properties.  Most of these
>    properties, such as all the get* properties, will have no value as a
>    lock-null resource does not support the GET method.  Lock-Null
>    resources MUST have defined values for lockdiscovery and
>    supportedlock properties.
>
>    Until a method such as PUT or MKCOL is successfully executed on the
>    lock-null resource the resource MUST stay in the lock-null state.
>    However, once a PUT or MKCOL is successfully executed on a lock-null
>    resource the resource ceases to be in the lock-null state.
>
> A direct read of this paragraph combined with deltaV draft 15 (and your
> implication) would indicate that you can't issue a VERSION-CONTROL method
> on a lock-null resource.  That's bogus.

No, that's great!<g>  The lock null resource is a nonce concept that is not
required by Delta-V.
Reading the quoted paragraph with Delta-V gives (IMHO) the correct
impression that versioning operations are not allowed on lock null
resources.

> A "write locked null resource"
> is there so that the creator can do all the write operations and state
> changes they need before making the resource visible to everybody.

This isn't true since you cannot PROPPATCH a lock null resource, and as
soon as the first PUT/MKCOL succeeds it is no longer in the lock-null state
-- so there really is no set of state changes that can be applied to a lock
null resource.

I'm not sure what you mean by "before making the resource visible to
everybody".  The resource name is a member of the parent collection, so
that is 'visible'.  It has visible mandatory DAV properties (including
those defined by Delta-V for all DAV resources).  But until the initial
PUT/MKCOL there is no content/are no members.

Are you are suggesting that the lock null resource should be a versionable
resource?
Are you suggesting that the lock null resource can be brought under version
control before the initial PUT/MKCOL?  Delta-V allows for the resource to
be brought under version control as part of the initial PUT/MKCOL; and if
it is brought under version control _after_ the initial PUT/MKCOL then the
resource is no longer a lock null resource.

> So, I suggest that VERSION-CONTROL (and perhaps other methods like
CHECKOUT,
> MKWORKSPACE...) should be explicitly allowed by DeltaV to be done on
write
> locked null resources, and that the spec define a precondition that can
be
> returned if the server decides not to allow operations on write-lock
> resources.

I see no argument for VERSION-CONTROL or CHECKOUT, but MKWORKSPACE is a
more likely candidate since it is akin to MKCOL.  This would obviously
require a modification to RFC2518's statement that the lock null resource
MUST fail methods that are not in the named list.

Tim

Received on Friday, 1 June 2001 05:49:58 UTC