Re: workspaces

I believe that the spec would have to be updated to deal with multiple
workspaces for a given resource.

For example,

- a version selector has a DAV:workspace property.  What would its value be
for a resource in a 'nested' workspace?  The resource would be a member of
multiple workspaces so this would have to be changed to a set.

- a workspace is expected to be able to report its checkout set
(DAV:workspace-checkout-set).  When performing a checkout a server would
have to nominally find all references to the resource and update all
workspaces with the additional checked out resource.

- same for current activity set of a workspace.  The server would
presumably be expected to make checkouts in the union of all current
activity sets of all workspaces that the resource is a member.  Servers
that restrict to single activities would have to be aware of enclosing
workspaces and disallow additional DAV:current-activity-set values for
nested workspaces, and disallow binding to reachable workspaces that
already have a current activity set defined.

- "In order to ensure unambiguous merging and baselining semantics, a
workspace may contain at most one version selector for a given version
history."  A bind to an existing resource in another workspace would
require the server to determine if there are any version selectors in each
workspace that fail this precondition.

I'd be interested to hear if anyone is planning on implementing nested
workspaces.

Tim


Ross Wetmore <rwetmore@verticalsky.com> on 2000-11-10 05:32:17 PM

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

To:   Tim Ellison/UK/IBM@IBMGB, ietf-dav-versioning@w3.org
cc:
Subject:  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

Received on Friday, 10 November 2000 16:23:51 UTC