Message-ID: <4FD6422BE942D111908D00805F3158DF0A757D8A@RED-MSG-52> From: Chris Kaler <email@example.com> To: "'firstname.lastname@example.org'" <email@example.com>, firstname.lastname@example.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.