Uncheckout, DAV.VersionSpace link, and History
1.1 Problem Definition
The term uncheckout actually means two things.
One definition is that an uncheckout is the removal of a checkout.
The second definition involves transactioning. In this case an
uncheckout results in all changes the user has made to the resource
since they checked the resource out, being rolled back.
With my proposed removal of the CHECKOUT method and its replacement with
the LOCK method, the first definition is satisfied with the UNLOCK
The second definition requires a transactioning system and as such I
believe it is beyond the scope of the DAV draft.
Those who remember my original position paper on atomic methods will see
a contradiction in my view. Indeed, my current view does contradict my
original statements. After having spent the last few days thinking about
versioning I have come to the conclusion that the rollback UNCHECKOUT
requires a transactioning system and that introducing such a system is
completely out of scope for DAV. In addition I do not believe that
rollback UNCHECKOUT is necessary for a basic interoperable system.
2. DAV.VersionSpace Link
2.1 Problem Definition
It is highly probable that a single HTTP server will actually be a front
door to a number of other servers, some will support versioning, some
will not. Some servers will be able to support versioning of a resource
anywhere in their name space and some will only be able to support
versioning in specific parts of their name spaces. A mechanism is needed
to determine if a server supports versioning at all and if it does,
I propose introducing the DAV.VersionSpace link. A DAV versioning
compliant system must have this link available from *. This link will
default to returning a web collection containing a description that
indicates which name spaces support versioning and if versioning is
automatic or must be requested within those namespaces.
3.1 Problem Definition
One of the most powerful features of a versioned system is the ability
to view the entire history of a versioned resource. This information can
be built manually by the client by following all the versioning links
but this is extremely inefficient. Most servers already maintain the
history list, as such it would be good for clients to be able to get
this list in one request.
I propose that a STRUCTURE method executed on a tree handle return a
history. This does not remove the need for the DAV.Versioning.History
link. This link is needed to find the tree handle and for proper
operation of distributed systems which have no tree handle.