W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: workspaces

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Fri, 17 Nov 2000 13:27:55 -0500 (EST)
Message-Id: <200011171827.NAA15660@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: Tim_Ellison@uk.ibm.com

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

I agree, but I think that it is better to say that a resource is in
at most one workspace, but that the workspace of a child does not have
to be the workspace of its parent (such as when the child itself is
a workspace, or when the child is a binding to a resource that is in
another workspace.  This then avoids all the complications that Tim
(correctly) indicates below.

   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.

This last complication is one a server already must deal with,
since the VERSION-CONTROL request can be used to create a version selector
whose DAV:target refers to a version in an existing version history.

Received on Friday, 17 November 2000 13:28:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:45 UTC