Re: Version issues
Chris Kaler (ckaler@microsoft.com)
Tue, 16 Feb 1999 12:21:30 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757D8A@RED-MSG-52>
From: Chris Kaler <ckaler@microsoft.com>
To: "'jamsden@us.ibm.com'" <jamsden@us.ibm.com>, ietf-dav-versioning@w3.org
Date: Tue, 16 Feb 1999 12:21:30 -0800
Subject: RE: Version issues
[CK] Comments below...
A few issues came up at our last versioning working group meeting:
1. DAV versioning level 1 will still need to be a way of resolving access
to versioned resources given just a URL (and not a label). If workspaces
aren't supported, level 1 servers will have to provide some other way to
resolve URLs to specific revisions, perhaps a default revision for each
versioned resource. For level 2 servers that do support workspaces, this
would result in two, potentially conflicting ways of performing URL
mapping. This is a strong argument for including workspaces in level 1.
What would anyone want to do with versioning level 1 that workspaces
wouldn't support? What would workspaces include that would be considered
too much for level 1? If there are no compelling answers to these
questions, we should include workspaces in level 1, including the default
workspace.
[CK] I suggest we keep the Revision-Id header and the SETDEFAULT method.
2. Deleting a resource must explicitly state that the resource is removed
from its parent collection; that is, the collection with which the resource
is an internal member. Versioning complicates delete semantics. There are
three things we might want to delete: an unversioned or working resource, a
revision (and all its descendents?) of a versioned resource, a versioned
resource and all its revision history. This must be done in the context of
versioned and unversioned collections that contain the resource, or
versioned resource as an internal member. The preferred way to do this
would be to have add and remove methods on collections to create and delete
resources as its the collection that controls the namespace. Unfortunately,
DAV doesn't have those semantics, so we will have to find a work-around for
versioning.
[CK] I expect deleting a working resource to be the same as UNCHECKOUT.
[CK] Deleting a versioned resource is up to the store. Some stores might
[CK] just delete it. Some might create an "delete" version. I don't think
[CK] we want to push a specific model on people. Especially since the
[CK] DELETE method is about a resource and in no way describes the
[CK] underlying repository actions.
Actually, the current WebDAV spec is a little confusing about collections
and their members. The current spec indicates collections contain URLs, not
resources. But, there is the notion of internal members and referential
members, and deleting a collection deletes all its internal members. So the
collection behaves like it contains resources, not URLs. This issue will
likely get more confusing when we add versioned resources, versioned
collections, and multiple revisions.
[CK]Your right -- some clarification here would be could.
3. It is not possible to automatically create workspaces or activities for
either non-versioning clients, or versioning clients that don't specify
them. Default workspaces and/or activities must be used. Creating a new
workspace or activity on each request could cause resources that were
manipulated in the previous request to disappear.
[CK] If we say this is what "logically" happens on a Level 1 server then
[CK] OK. But if the server must in fact do this, then I think the cost
[CK] is too high since Level 1 clients don't care about this information.