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."