W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

Re: VERSION-CONTROL with Location header?

From: <Tim_Ellison@uk.ibm.com>
Date: Fri, 11 May 2001 10:59:15 +0100
To: ietf-dav-versioning@w3.org
Message-ID: <80256A49.0036D0FE.00@d06mta07.portsmouth.uk.ibm.com>

"Stefan Eissing" <stefan.eissing@greenbytes.de> wrote:
> I scanned the archives, but could not find anything about
> this. In case I missed it, my humble excuses for posting
> this again:
> The response to a VERSION-CONTROL request does not carry
> a Location header similar to CHECKIN (Draft 15). Now, I
> would propose that the client receives such a header
> in case the resource changed status from versionable to
> versioned (and is now checked-in).

When VERSION-CONTROL is applied successfully to a versionable resource, the
versionable resource is _replaced_ by a checked-in version-controlled
resource (i.e., the version-controlled resource is identified by the same
URL that previously identified the versionable resource).  No 'Location:'
header is therefore required to identify the version-controlled resource.

The resulting checked-in version-controlled resource has a <DAV:checked-in>
property whose value is the URL of the version with the same content and
dead properties.  This version URL can be used as a 'stable' reference to
the content and dead properties.

The Location: response header is provided with CHECKIN because it gives the
client the URL to the version that was created by the successful check in.
This becomes important when checking in a working resource as the working
resource is deleted upon a successful check in.  (When checking in a
checked-out version-controlled resource the Location: response is the same
as the resulting checked-in version-controlled resource's <DAV:checked-in>
property value.)

> Scenario: with basic versioning a user might have checked
> out a number of resources for editing. Now he adds a couple
> of new resources which are initially not under version control.
> Then he (or rather his client application) tries to check in
> all resources he has created or changed, issuing CHECKIN and

Note that when a client checks out resources for editing, they may be
checking out a (checked-in) version-controlled resource which simply makes
it become a checked-out version-controlled resource (effectively 'marking'
the resource mutable); or they may check out a version which creates a new,
mutable, resource (a working resource).  I'll assume that you are checking
out one/more version-controlled resource(s).

> Outcome 1: all requests succeed and the client application
> can display the version URIs of the checked-in versions to
> the user by using the Location headers of the responses.

The version URLs are typically meaningless to the user.  They will be
unique, server generated URLs.  Unless it is important for users to deal
with the versions directly, it is likely they will deal with the checked-in
version-controlled resources.  As mentioned above, their URLs are more
likely to make sense in the users' application.

> Outcome 2: resources were checked in our put under version
> control by someone else. In this case the client application
> can be aware of the modified resource by
> a) failed CHECKIN requests for already checked in resources

Right.  CHECKIN will fail if the resource is not version-controlled, or is
already checked-in.  VERSION-CONTROL will succeed (200 OK) if the resource
is already under version-control.

> b) missing Location headers for resource already under version
>    control.

Not sure what you mean here.

> Does this make sense to anyone but me?

Where a client expects some isolation from other clients, they would
typically use working resources (client-side workspace scenario) or a
workspace resource on the server (server-side workspaces).
Where there is overlap and clients are 'bumping into each other' in the
manner you discuss, then they have to react to return codes to determine
the state of the resources and PROFIND to probe their current state (i.e.
for UI updating).  This is less than ideal.

Received on Friday, 11 May 2001 06:00:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC