Date: Thu, 10 Aug 2000 16:07:13 -0400 (EDT) Message-Id: <200008102007.QAA12729@tantalum.atria.com> From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> To: ietf-dav-versioning@w3.org Subject: Re: move/copy/delete/etc in a change set From: Greg Stein <gstein@lyra.org> It is still a teeny bit unclear of the actual form of the HTTP requests to accomplish these items. However, I'll be working on that over the next few days. I think that I'll develop a sequence of req/resp matching my example change set below, and then post it back here for review/comment. Great! Tim has been working on a scenarios document, but currently it just has core versioning scenarios (no workspaces, no activities, no version-controlled collections), so we need to get advanced versioning scenarios added. For example, one of my questions to work through is: what URL do you use for a PUT to place a new resource into a checked out collection? Do you PUT under the working resource? Yes. If your collection was in a workspace, the URL of this working collection MUST be the same URL as you checked out, so life is pretty reasonable, i.e. if you checked out /ws/geoff/src, then you can use /ws/geoff/src to refer to the working collection, so you can create a new member with PUT /ws/geoff/src/foo.html. If /ws/geoff/src is *not* in a workspace, then the server can return any old URL it wants for the working collection (in the Location header), and you'd have to add your members there, i.e. if it returned /dav/wr/x23, then you'd have to create your new member with PUT /dav/wr/x23/foo.html. Do you PUT under the version selector and the server automatically goes to the working resource and alters it? For workspaces, effectively the answer is "yes", but not because you did your PUT to the version selector, but rather that the server replaced your version selector with a working resource. In core versioning, there can be multiple working resources associated with a single version selector, so it would be ambiguous which one to go to. Now I personally would prefer to just say that every version selector is in a workspace, and that you can only have one checkout of a given version selector (and that's what our implementation will do), but that's just me (:-). Cheers, Geoff