- From: Yaron Goland <yarong@microsoft.com>
- Date: Tue, 11 Feb 1997 17:36:12 -0800
- To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
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