Next message: jamsden@us.ibm.com: "RE: Why do we need working resource ids ?"
Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D8DA@chef.lex.rational.com>
From: "Clemm, Geoff" <gclemm@Rational.Com>
To: ietf-dav-versioning@w3.org
Date: Tue, 30 May 2000 18:05:55 -0400
Subject: RE: Locking a workspace
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