Next message: Geoffrey M. Clemm: "Re: Why do we need working resource ids ?"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568F0.004BC486.00@d54mta02.raleigh.ibm.com>
Date: Wed, 31 May 2000 09:47:33 -0400
Subject: Re: Why do we need working resource ids ?
I think we're getting somewhere. Comments below in <jra> tags.
From: jamsden@us.ibm.com
Here's a couple of compelling use cases:
the server generated URLs are not likely to be in DAV
namespaces. That is, collection semantics won't work. They're only
to access one specific resource. The collection semantics do work
with the versioned resource and Target-Selector.
A revision id and working resource id don't give you any more
collection semantics than a revision URL or working resource URL, so I
don't see your point here. The collection semantics apply to the
human define versioned resource URL's, and that is true whether or not
you use revision URL's or revision id's to identify particular
revisions.
<jra>
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. 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.
The target selector may not pick the right, or any, revision of members,
but that's OK. 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. 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>
I am not yet compelled (:-).
Second, we need Target-Selector anyway for selecting revisions by
label, workspace, activity, perhaps baseline - all of which are
logical target selectors that have human meaningful names.
I agree that we should have a Target-Selector header that specifies
a label. I disagree that it should specify anything else.
We have the ability to select revisions by workspace ... just use
the URL of that workspace extended by whatever member of the workspace
you'd like to refer to (or use a Workspace header and a relative URL).
<jra>
I like this, but it doesn't work for labels, activities, etc. See below.
This is fine, but I think a workspace should be able to appear in a
Target-Selector to select the revision in that workspace too. This lets
users use the versioned resource URL for everything. 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>
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. In other words, having a workspace isn't
enough. A user needs to be able to temporarily override thier workspace to
see other revisions. 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>
We don't
want clients to have to use server generated URLs in some instances
and versioned resource and Target-Selectors in others in order to
use the more meaningful names. Personally, I think Target-Selector
will be used 99% of the time with either a label or workspace. The
server generated URLs will probably be rarely used.
I agree that a Target-Selector should be used to specify a label,
and that we have a Workspace header in which you can specify a workspace.
The question is whether we need revision-id's and working-resource id's.
But your reasoning above, it appears we do not, since 99% of the cases
use labels and workspaces, and the (rarely used) server generated
URL's can be used for the remaining 1% of the cases.
<jra>
Revision ids are necessary to put on the first label. Others are needed to
just view those revisions as described above.
</jra>
Cheers,
Geoff