Next message: Geoffrey M. Clemm: "Re: DAV:revisions property for a workspace resource"
From: "Jim Doubek" <jdoubek@macromedia.com>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, <ietf-dav-versioning@w3.org>
Date: Fri, 14 Apr 2000 16:00:54 -0700
Message-ID: <NEBBKGCJHMKNLDINHHCEKEHHCAAA.jdoubek@macromedia.com>
Subject: RE: DAV:revisions property for a workspace resource
<jimd>
I agree that you need binding for versionable collections. The point of my
comment is that you don't seem to _really_ need it for anything else.
Therefore, it seems like the binding extensions should only be required by
the Advanced Versioning features (level 2?) rather than by the base spec.
While it sounds sort of abstruse whether the base deltaV spec requires
binding, my concern is more on the implementation side. I expect that the
majority of CMS's used for the first generation of deltaV systems won't
support sym-linking or aliasing within the repository. If so, requiring the
binding extension semantics might be a problem. I'm trying to assure myself
that one can support base-level deltaV in a hierarchically structured cms
at reasonable effort, and without cheating on the compliance levels for
deltaV or other WebDAV extensions.
On the other hand, tying Advanced Versioning options like Versioned
Collections to the Binding extension seems perfectly reasonable.
</jimd>
- jim
> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Geoffrey M.
> Clemm
> Sent: Friday, April 14, 2000 2:50 PM
> 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
>