Next message: Tim Ellison/OTT/OTI: "Revision of a stable-URL versioned resource"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568B3.0069ED42.00@d54mta03.raleigh.ibm.com>
Date: Fri, 31 Mar 2000 03:12:15 -0500
Subject: Re: WebDAV Versioning Scenarios
<geoff>
There are benefits to such a declarative revision selection rule (you have
a high level
description of "what is in your workspace"), but it comes at a cost.
For example, consider newly checked in resources. With a revision
selection rule, we had to introduce mechanisms like the
DAV:current-revision and DAV:current-label so that newly checked in
resources didn't disappear from the workspace (and the user
or client had to make sure to update the revision selection
rule whenever either DAV:current-revision or DAV:current-label
was changed).
So although I agree that it is worth standardizing on the name
of that property, I don't think we should require that it be the
only way of updating the revision selection of a workspace.
</geoff>
<jra>
I think we need to describe checkin as keeping the checked in resource in
the workspace until the next refresh so they don't disappear. It seems that
any technique of refreshing a workspace will have the problem that if the
revisions that you select aren't labeled properly or in the right activity
or configuration, you might not get the revision you wanted. I don't think
this is unique to using a workspace RSR to specify the revisions to select
on refresh although it may require an extra step to update the rule before
the refresh. I think this is a benefit though.
</jra>