From: Ross Wetmore <rwetmore@verticalsky.com>
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.
We should distinguish two different concepts.
The first concept is the standard 2518 concept
of collection membership. Since a workspace is
a collection, it has members, like any other collection.
The second concept is that each resource can identify
a single workspace in its DAV:workspace property.
Let's call the first concept "member of a workspace"
and the second concept "owned by a workspace".
I think that Tim and I would be willing for a resource
to be a member of more than one workspace (e.g. from
nesting a workspace inside another workspace), but
not for a resource to be owned by more than one workspace.
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.
For reasons like access control and locking, it is important
to identify a single "owner", but I think shared membership
is all that you need for the purposes you describe above.
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.
If we may it clear in the protocol that multiple membership is
acceptable, but that multiple ownership is not, does that satisfy
your requirements?
Tim: Am I correct in assuming that this would be OK with you?
Cheers,
Geoff