Comments on section 4.9 of the requirements specification

	4.9. Versioning

	In the following discussion, "versioned resource" means a resource that
	has the structure of a directed acyclic graph, each node of which is 
	a version. "Version" means a node in this structure, which is itself 
	a resource. Each version typically stands in a "derived from" 
	relationship to its predecessor(s).

We also need to express the concept that a versioned resource is
immutable, except for deletion. I know this is covered in detail in
section 4.9.1.1. but I still think it is worth including in the
introduction. If only to flag the repository people that we aren't
talking about their type of versioning. I would suggest something like:
Once a resource is versioned it becomes immutable and may only be
retrieved or deleted.

	4.9.1.1. Stableness of versions. Most versioning systems are intended
to
	provide an accurate record of the history of evolution of a document. 
	This accuracy is ensured by the fact that a version eventually becomes 
	"frozen" and immutable. Once a version is frozen, further changes will 
	create new versions rather than modifying the original. In order for 
	caching and persistent references to be properly maintained, a client 
	must be able to determine that a version has been frozen. We require 
	that unlocked resource versions be frozen. This enables the common 
	practice of keeping unfrozen "working versions". Any successful attempt
	to retrieve a frozen version of a resource will always retrieve exactly
	the same content, or return an error if that version (or the resource 
	itself) are no longer available.  Since URLs may be reassigned at a 
	server's discretion this requirement applies only for that period of 
	time during which a URL identifies the same resource. HTTP 1.1's Entity
	tags will need to be integrated into the versioning strategy in order 
	for caching to work properly.

	***Judy - Does the specification support this?

I'm not sure. The sentence "We require that unlocked resource versions
be frozen." sets off a lot of bells. I thought we were going to support
lock free versioning?

	4.9.1.2. Policy-free Versioning. Haake and Hicks [5] have identified 
	the notion of versioning styles (referred to here as versioning 
	policies, to reflect the nature of client/server interaction) as one 
	way to think about the different policies that versioning systems 
	implement. Versioning policies include decisions on the shape of 
	version histories (linear or branched), the granularity of change 
	tracking, locking requirements made by a server, etc. The protocol 
	should not unnecessarily restrict version management policies to any 
	one paradigm. For instance, locking and version number assignment 
	should be inter-operable across servers and clients, even if there are 
	some differences in their preferred models.

I believe this requirement and section 4.9.1.3 are no longer possible.
The logical result of this requirement is non-interoperability. The
current spec is proof of this. If we want interoperability we are going
to have to choose a basic versioning systems w/extremely few axis of
variability in order to allow for interoperability. I move that 4.9.1.3
be deleted and 4.9.1.2 be rewritten to read:
4.9.1.2. Interoperability. In order to meet the previously stated goal
of interoperability between any WebDAV compliant client and server it is
necessary for the working group to identify a versioning style which
will be codified in the final specification. This versioning style may
have several axis of variability to allow for some variation, for
example lock based and lock free versioning, but these axis's must be
kept to an absolute minimum in order to allow for interoperability.

	4.9.2.6. A way to determine whether a given URL points to a version 
	of a versioned resource.

	***Judy - Are we requiring that you be able to tell this just by
	examining the URL?

Absolutely not. This really codifies the ability to use linksearch on a
resource to determine if the resource is versioned or not.

	4.9.2.7. A way to distinguish, given a URL of a version, the part of
	the URL that identifies the version from the part that identifies the
	versioned resource.

	***Judy - Do we really have to (want to) require that you be able to
	find out the URL of the versioned resource by examining the URL of the
	version?  Is the requirement really just that there be some way to find
	out, for any version, the URL of its versioned resource?

I move that either this requirement be removed or this group be moved
out of the HTTP working group to the URL working group.  

	It also supports some comparison operations: It makes it possible to
	determine whether two URLs designate versions of the same versioned 
	resource. However, given the phenomenon of URL aliasing, it 
	is insufficient to determine that they are not versions of the same 
	resource.

This is what entity-tags and history lists are for.

	***Judy - If 4.9.2.8 - 14 are intended to require separate operations
	for each of these functions, they conflict with the approach taken in
	the WEBDAV specification.

This goes under the heading of axis's of variability. If we want
interoperability we must cut down on variability.

	4.9.2.10. A way for a client to declare an intention to modify a 
	resource (Reserve). (See Section 4.4 "Notification of Intent to Edit"
	above.)

	This operation is required before any versioned update. Its effects may
	vary depending on server policy, from locking a resource, to forking a
	new variant, to a NOOP on servers that do not track sessions or
restrict
	updates. If this operation returns a version number, the client is
	required to make sure that it uses a copy of the data associated with
	that version number of the resource for any update operations it
	carries out. Servers that wish to enforce a mandatory GET operation
	before update, should simply use a fresh version identifier on the
	return from this operation.

Any time an action may have any of a number of unrelated results we must
provide discoverability. As we do not wish to provide discoverability
because of the complexity it introduces we must not provide for a
notification of edit that is complex as the above. 

	***Judy - Uncheckout is neither in the requirements nor in the
	specification.  Do we need it?

I would strongly argue that we do. The scenario of a user checking out a
document and then changing their mind and wanting to Uncheckout the
document is so common that just about every single versioning system in
existence supports it.

Received on Wednesday, 12 February 1997 10:17:20 UTC