Next message: jamsden@us.ibm.com: "Re: workspaces as collections"
Date: Wed, 31 May 2000 14:47:10 -0400 (EDT)
Message-Id: <200005311847.OAA25581@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Why do we need working resource ids ?
From: jamsden@us.ibm.com
Perhaps I'm not understanding the role of a revision URL. When we
talked in Seattle, I understood that all these server generated
URLs were basically opaque, and that they would likely not be in
the DAV namespace. So they can't be used to get members of a
collection, depth operations, etc.
Yup.
Given a versioned resource URL
and a Target-Selector, at least the versioned resource URL is in
the DAV namespace and has proper collection semantics.
And given a versioned resource URL without a Target-Selector, the
versioned resource URL is in the DAV namespace and has proper
collection semantics.
The target selector may not pick the right, or any, revision of
members, but that's OK.
Yup (assuming by "target selector", you mean "Target-Selector").
Your statement about revision URL's or revision id's to
identify a revision of a versioned resource in the context of the
versioned resource URL seems to indicate that the revision URL
could be used in a Target-Selector.
Nope. It is used as the request-URL, not in a Target-Selector header.
Is this correct? If not, then I
don't understand how they are being used to access a specific
revision using the versioned resource URL which is what we wanted
to promote. </jra>
If the client is going to have to use a server-defined string
(both revision id and revision URL strings are server defined),
it might as well just use the server defined URL. Combining a
server defined string (the revision id) with a user defined string
(the versioned resource URL) is no easier than just using a
server defined string (the revision URL). In fact, it is
significantly simpler since the client just keeps track of a
single server defined string (the revision URL), rather than having
to keep track of what user defined string needs to be combined
with a server defined string (the revision id) in order to form a request.
<jra> I don't think there should be a separate Workspace
header. Instead I think there should be an Override-Selector when
target selection includes versioned collections and users want a
different revision of the leaf resource. </jra>
If we use the semantics I am proposing, a Workspace header is very
different from a Target-Selector header.
A Workspace header just specifies a prefix that the server should
apply to the request-URL and header URL's. The result can be either
an unversioned or a versioned resource. This is just a (fairly minor)
syntactic convenience for the client. It could just prefix the
Workspace URL to the request URL and header URL's itself. If folks
believe that this syntactic convenience is not worth the price of a
header, I'd say fine and take the Workspace header out of the spec.
A Target-Selector header can be used when the request-URL
is a versioned resource, and selects the revision of the versioned
resource with that label. This header is primarily there to
save the client the cost of requesting the history report from
which it can locate the labelled revision itself.
We have agreed (as recently as last week in Seattle :-) that we
would not allow an activity or a baseline in a Target-Selector header,
but rather require that a client merge that activity or baseline
to a workspace and then use that workspace. The reason is that
the caching opportunities provided by a workspace are required to
allow a server to efficiently perform activity or baseline
target selection.
<jra> But I think these have to be in the Target-Selector. For
example, say you want to do a merge of an activity into your
workspace, but you're not sure what work is involved. First you
would get a conflict report to see what needs to be merged. They
you'd want to look at the revision selected by the activity to see
how it changed and what you need to do to to merge it. This might
use a diff too. Then you'd decide to do the merge or not depending
on how much work there is to do, etc.
The conflict report identifies the revision-URL's of the revisions in
conflict, so there is no need for a second query to identify the
revision in conflict.
In other words, having a
workspace isn't enough. A user needs to be able to temporarily
override thier workspace to see other revisions.
If a user needs to see other revisions that have a human defined name
(i.e. a label), they can use a Target-Selector to do so. If they need
to find a revision that only has a server defined name, they will ask
for a history report, and that report will contain both the properties
needed by the user to select which revision they want, as well as the
revision URL that will enable the client to retrieve a specific
revision once the user has selected the one of interest.
This is where
labels, activities, other workspaces, baselines, etc. need to be in
the Target-Selector, and why target selection should not modify the
versioned resource. </jra>
The ineffiency of doing baseline and activity selection out of the
context of a workspace is strong motivation for only providing this
capability if it is essential. The use cases you have described so
far are all easily handled without the use of activities, baselines,
or resource id's in Target-Selector headers.
Revision ids are necessary to put on the first label. Others are
needed to just view those revisions as described above.
You can apply a label via the versioned resource that selects the
appropriate revision (probably the commonest case), or (since we are
using the LABEL marshalling) via the revision URL. (Which just goes
to show that JimA and Tim were right about the superiority of the
LABEL marshalling :-). But in either case, there is no need for a
revision id.
Cheers,
Geoff