Re: workspaces

It is still not clear to me precisely what you are excluding. I agree
there are some specific scenarios such as a workspace including itself
that probably should be excluded. I would like to see this pinned down
clearly though and not a vague or general precept applied on the basis
of a corner case without careful consideration.

I see no difficulty with workspace members being in more than one 
workspace and no reason to exclude this with a generic rule at the 
moment. This is not quite the terminology you used which means perhaps 
such definitions need to be elaborated a little more clearly, or the 
underlying rationale spelled out.

I don't currently see any fundamental difficulty with nesting 
workspaces, and would like the issues clarified before such flattening 
becomes mandatory. This is a fairly significant restriction.

I agree it is reasonable to leave the mechanics of sharing to a binding 
spec, as long as the delta-v spec treats such issues as orthogonal.

Cheers,
RossW

Tim_Ellison@uk.ibm.com wrote:
> 
> Simply that you shouldn't be allowed to create an overlap by binding a
> member of one workspace to a member of another workspace, or create a
> binding from a member of a workspace to, say, a parent of the workspace
> since the workspace would become a member of itself.
> 
> However, since the delta-v spec cannot refer to the binding spec ("other
> than as work in progress") it should be sufficient to say that workspaces
> cannot be nested, and leave other binding issues for that work group<g>
> 
> Tim
> 
> Ross Wetmore <rwetmore@verticalsky.com> on 2000-11-10 02:24:58 PM
> 
> Please respond to Ross Wetmore <rwetmore@verticalsky.com>
> 
> To:   Tim Ellison/UK/IBM@IBMGB
> cc:   ietf-dav-versioning@w3.org
> Subject:  Re: workspaces
> 
> Tim_Ellison@uk.ibm.com wrote:
> >
> > 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.
> 
>   Can you clarify what is meant by the above? Bindings to/from what for
> instance?
> 
> > Having multiple workpace 'parents' would confuse
> > many things, including current activity, and make workspace semantics for
> > single history selectors very time consuming to enforce.
> >
> > Tim
> 
> Cheers,
> RossW