Date: Tue, 9 Mar 1999 10:14:31 -0500 Message-Id: <9903091514.AA11819@tantalum> From: "Geoffrey M. Clemm" <email@example.com> To: firstname.lastname@example.org Subject: Notes on the 3/8/99 Dav-Versioning Conference Call Participating: Jim Amsden,Geoff Clemm,David Durand,Chris Kaler,Bradley Sergeant Topic: Administrivia about Minneapolis versioning presentations <no notes taken> Topic: URN's for versioned resources Jim and Geoff presented a few key use cases were presented that required the use of "locatable URN's". In particular: - Reliable Configurations A configuration is an immutable snapshot of a subtree of a website. The concept of a configuration must co-exist with the need to allow clients to modify the binding of a "user URL" to a new resource via a MOVE. This could be achieved by requiring that the server assign a "locatable URN" to each versioned resource, independent of the "user URL" that is subject to a MOVE. A configuration would be defined in terms of a set of "locatable URN"s, - Merging Configurations In order to reliably merge configurations, it is essential to know whether two different revisions of the "same" versioned resource appear in the two configurations, since this implies a "merge" of those revisions is needed. The "user URL"s of the two revisions are not sufficient, because one or more MOVE's could have renamed the revisions. This could be achieved by providing a "VR-URN" property of a revision, containing the "locatable URN" for that revision's versioned resource. The versioned resource must be "locatable" because the revision history must be accessible in order to support the merge process (e.g. finding the nearest common ancestor revision). - Non-local Workspaces Many versioning systems maintain a workspace on a host separate from where the versioning resources are stored (e.g. on the client or on a different web-server). To support this, a server must provide some way of reliably referencing a particular versioned-resource. A locatable URN would support this requirement. Dave pointed out that a "locatable URN" is currently at best a "work-in-progress". Brad pointed out that a URN wrt some identified "repository" resource is feasible, and is what is actually supported today by versioning and document management systems. Geoff agreed with both of these points, and volunteered to write up a proposal that addresses these use cases with a "repository resource" instead of a "locatable URN".