Re: workspaces

My earlier point was that the versioning protocol should be mindful of
situations that can arise from advanced collections operations, and we
should not knowlingly screw them over.  However, since advanced collections
is currently a draft we can only refer to it as 'work in progress'.  In the
final analysis, if versioning gets RFC status before advanced collections,
then advanced collections has to address the problems of BIND and
versioning (not that I'm suggesting we adopt that tone).

I did not agree that version selectors could be shared (successfully)
amongst multiple workspaces.

> The use for this was to insure consistent versions
> across several workig teams without requiring either
> each team to poll for changes, or each checkin to poll
> for and update all affected workspaces.

Would it be possible for all teams to share a common workspace containing
resources that must be kept consistent?

Regards,

Tim


Ross Wetmore <rwetmore@verticalsky.com> on 2000-11-20 02:45:57 PM

Please respond to Ross Wetmore <rwetmore@verticalsky.com>

To:   Tim Ellison/UK/IBM@IBMGB
cc:   ietf-dav-versioning@w3.org
Subject:  Re: workspaces




Actually, this was discussed earlier and it was agreed that
version selectors could be shared amongst multiple workspaces
but that this would be done through the binding protocol.

The use for this was to insure consistent versions across
several workig teams without requiring either each team to
poll for changes, or each checkin to poll for and update
all affected workspaces.

Putting such a limitation in the spec would invalidate this.

The spec should either be extended to handle such cases at
the current time, or it should be defined in such a way that
this can be added without violating the current spec when
bind functionality is defined. Defining the spec with a
specific exclusion for this should be considered unacceptable.

Cheers,
RossW
=====

Tim_Ellison@uk.ibm.com wrote:
>
> >   From: Tim_Ellison@uk.ibm.com
>
> >   The spec should say that workspaces cannot 'overlap',
> >   i.e., a workspace cannot be a member of another workspace,
> >   and bindings cannot be made outside the workspace.
> >   Having multiple workpace 'parents' would confuse
> >   many things, including current activity, and make
> >   workspace semantics for single history selectors very
> >   time consuming to enforce.
> >
> > This is a good point, but I think we can address it in a
> > less draconian fashion.
>
> 8-|
>
> > I think it is sufficient to state that a version selector
> > is contained by at most one workspace, namely, the one
> > specified in its DAV:workspace property, and that when a
> > resource is put under version control, its DAV:workspace
> > property is set to be the DAV:workspace of its parent
> > collection.
>
> Ok.
>
> > This does raise another question:
> >
> > Should we require a DAV:workspace property on *non-version-
> > controlled* workspace members?
>
> Yes.
>
> > If not, we need to modify the preceding statement to say:
> >
> > "... the DAV:workspace of its nearest parent collection
> > that has a DAV:workspace property."

Received on Monday, 20 November 2000 10:35:51 UTC