Next message: Jim Doubek: "RE: DAV:revisions property for a workspace resource"
Date: Fri, 14 Apr 2000 17:49:39 -0400 (EDT)
Message-Id: <200004142149.RAA15484@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: DAV:revisions property for a workspace resource
From: "Jim Doubek" <jdoubek@macromedia.com>
After reading the _04.2 spec and following this list for a while, I have a
couple of questions.
Welcome aboard Jim! Due to the popularity of the name "Jim" amoung
versioning enthusiasts (:-), I'll try to remember to use JimD in any
context where it might be ambiguous.
According to this thread, workspaces ought not be collections, nor are
activities. It seems the only place the spec requires binding as opposed to
containment is in versionable collections. It seems to me that all other
semantics and namespace navigation can be handled without the binding
extensions, or am I missing something?
Yes and no (i.e. yes, binding extensions are only used for versioned
collections, and no, you are not missing something :-).
Is there another reason for requiring
the Bind extension, beyond the greater flexibility it gives? It seems to be
orthogonal to this spec except for versioned collections.
The key issue is that new revisions of a versioned collection have to
be able to have bindings to the same versioned resources as other
revisions of that versioned resource. For example, suppose you have a
versioned collection identified as /x/y in the default workspace, and
suppose that revision 5 of this versioned collection has members named
A and B bound to versioned resources /repo/vr/id23 and /repo/vr/id72,
respectively.
/x/y:
A -> /repo/vr/id23
B -> /repo/vr/id72
Now suppose you want to restore some versioned resource (say,
/repo/vr/id84) that was present in an earlier revision of that
versioned collection. How would you do that?
First you'd of course have to checkout /x/y
With the binding protocol, you would then say:
BIND /x/y
Source: /repo/vr/id84
Binding-Name: C
/x/y:
A -> /repo/vr/id23
B -> /repo/vr/id72
C -> /repo/vr/id84
The result is that the resource /repo/vr/id84 is now bound into the
working collection /x/y under the name "C", in addition to being bound
in the collection /repo/vr under the name "id84", and in addition to
all the earlier collection revision that had a binding to
/repo/vr/id84.
How would you do this without the BIND call (and without defining
a new method that has the same semantics as BIND)?
Second, why should a workspace not give a binding name to its set of working
resources and selected revisions?
The names of the revisions of versioned resources exposed in a workspace
are provided by the collections that contain those versioned resources,
not the workspace. The workspace just says what revision of that resource
is selected.
Cheers,
Geoff