Next message: Geoffrey M. Clemm: "Re: workspaces as collections"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568F0.0008B7BE.00@d54mta02.raleigh.ibm.com>
Date: Tue, 30 May 2000 21:35:09 -0400
Subject: RE: Locking a workspace
Sounds good to me. We have to define the merge and create baseline
semantics for a workspace that has working resources and unversioned
resources. I suggest merge and create baseline fails if there are working
resources, and unversioned resources are ignored.
The proposal is to extend the notion of a workspace
so that instead of it just being a resource that defines
a versioned-resource to revision mappings, it is now
a collection of versioned and unversioned resources that
defines a versioned-resource to revision mapping for the
versioned resource members of that collection.
This extension provides a mechanism for a workspace to
contain unversioned resources that are local to that workspace
(for derived and temporary resources that are not valid
outside that workspace).
The collection is not structured around a URL namespace,
but it does define a (relative) URL namespace for its members.
Cheers,
Geoff
-----Original Message-----
From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com]
Sent: Tuesday, May 30, 2000 2:15 PM
To: Clemm, Geoff
Cc: ietf-dav-versioning@w3.org
Subject: RE: Locking a workspace
In 05, workspaces can be visualized as a set of versioned resource id to
revision id (or "none") mappings.
I don't see how you can model this with a collection, since collections
are necessarily structured around the URL namespace.
Tim
"Clemm, Geoff" <gclemm@Rational.Com>
Tim: Could you explain this a bit more?
The proposal was to have both versioned resources and
non-versioned resources in a workspace.
A workspace defines the target selection for all
versioned resource members.
When you baseline a workspace, the baseline remembers
both what revision of a versioned resource was selected
as well as what name that versioned resource had
relative to the workspace collection. When you populate
a workspace with a baseline, this will generate any
non-versioned collections needed to recreate the
namespace defined by the baseline.
How does this produce a non-dav-compliant namespace?
Cheers,
Geoff
-----Original Message-----
From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com]
Sent: Tuesday, May 30, 2000 11:02 AM
To: ietf-dav-versioning@w3.org
Subject: Re: Locking a workspace
I did not take from the proposal that the target selection criteria for a
workspace would be manifested as members of the workspace 'collection'.
Rather that the workspace contained resources that were selected in a
'higher priority' to the 'global' resources.
If the target selections are collection members, the workspace collection
would not have a dav-compliant namespace.
Tim
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
Sent by: ietf-dav-versioning-request@w3.org
29-05-00 10:56 PM
To: ietf-dav-versioning@w3.org
cc:
Subject: Re: Locking a workspace
With the proposed "workspace is a collection" semantics, you can
get such a lock by issuing a depth lock against the workspace collection.
I guess this is another benefit of the "workspace as collection" approach.
Cheers,
Geoff
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Date: Mon, 29 May 2000 16:51:51 -0400
Is there any mechanism for preventing others from issuing a set-target
against a workspace (so that it always selects the same thing)?
How about locking the workspace (although the selection criteria are
neither content nor properties)?
Tim