Re: Versioning spec review - 02.3

Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Mon, 25 Oct 1999 23:10:23 -0400 

Date: Mon, 25 Oct 1999 23:10:23 -0400
Message-Id: <9910260310.AA25070@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <F3B2A0DB2FC1D211A511006097FFDDF53438BF@BEAVMAIL> (message from
Subject: Re: Versioning spec review - 02.3

   From: Bradley Sergeant <Bradley.Sergeant@merant.com>

   <sarge2>
   So you're saying we can use advanced collections to restructure a versioned
   resource tree and achieve the same thing.  Perhaps this will work, but I
   don't think so.  My concern is that it means you have to have one primary
   structure for your versioned resources which you can never delete or
   restructure because you've got bindings that reference it.

I think I see one possible cause for disconnect.  In the old "direct
reference" approach, a direct reference was a resource that specified
another URL.  In the new "binding" approach, a binding is just a reliable
way of getting to a particular resource.  You can "MOVE" a binding
with the guarantee that all other bindings to that resource will continue
to be valid (or the MOVE must fail).

   It's one thing
   to say that the history resource URI (which the server generates) must not
   change, but saying that a publicly used versioned resource URI (that the
   user invents) can't change I see as a big problem.  My experience in this
   area tells me that we need an invariant URI or ID of some sort that allows
   you to always get at the same revision graph.  I don't think the versioned
   resource itself can play this role because the client needs/wants to be able
   to move and delete these items for specific project needs, without affecting
   other structures used for other purposes that reference the same revision
   graphs.  See the point?

I believe this all works fine, with the semantics of BIND.

   As I've posted in earlier mail on this topic, I'd rather see:
   *	the revision reference the working resources,

That I'd want us to be careful about, to allow
the working resources to be on different servers from the revisions.
But as long as they are URL's, and not bindings, we're OK.

   *	the working resources reference the workspace (which they do) and
   also the associated versioned resource (which they don't),

A working resource references the revision, which in turn references
the versioned resource, but we could provide the versioned resource reference
in the working resource as well (at least, I'd be happy to add it).

   *	the workspace reference the working resource (which they don't).

Done (unless someone objects).

	   I don't want:
   *	the revision referencing the versioned resource (which it currently
   does),

Why not?  If you've got a handle on a revision, it's very useful to
find out what versioned resource it is for (where the versioned resource
gives you a handle on all the other revisions of that versioned resource).

   *	the workspace referencing the versioned resource (which it currently
   does). I'd rather let the client go to the working resource to get this
   information if required.

That's gone.

   That is the model I think works best, but it requires a history resource, or
   a two level lookup on a repository resource.  We had the history resource
   before, but it suddenly vanished.

We probably have to draw this all out on a whiteboard to make sure, but
I believe bindings to versioned resources addresses the use cases you
describe here.  If not, I'm happy to bring back the history resource concept.

Cheers,
Geoff