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

RE: Autoversion confusion

From: Lisa Dusseault <lisa@xythos.com>
Date: Tue, 6 Feb 2001 18:44:58 -0800
To: <Tim_Ellison@uk.ibm.com>, <ietf-dav-versioning@w3.org>

I take your point about the checked-out version only being created when
the PUT is issued.  Still, some confusion remains.

The spec frequently makes statements like: "The resource MUST have a
DAV:checked-in property that identifies the new version.  The content,
dead properties, and DAV:resourcetype of the new version MUST be the
same as those of the resource.  "
Also: "Although the content and dead properties of a checked-in
version-controlled resource are required to be the same as those of its
current DAV:checked-in version..."

OK, so based on my reading of this text and others, I assumed that the
VCR ALWAYS had the body and the content of the last checked-in version,
whether or not the VCR was checked-out.  Nowhere does the draft state
otherwise, e.g. that a checked-out VCR has the body and properties of
the checked-out version.

Clearly, you and perhaps the other authors have a different mental model
of the way this works, but nowhere in the draft is this stated.  I admit
that 2.1.2, on careful viewing, does imply that the checked-out VCR
shows the body and properties of the latest version, but I want a
normative statement.


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of
> Tim_Ellison@uk.ibm.com
> Sent: Tuesday, February 06, 2001 3:22 AM
> To: ietf-dav-versioning@w3.org
> Subject: Re: Autoversion confusion
> > I have a question about DAV:auto-version "when-locked"
> > value.  In my model of the way things work:
> >
> > On a non-versioning server with a non-versioning client:
> >  - client issues LOCK on A
> >  - Lock-owner client issues PUT to A, creating the
> > content A' (A-prime)
> >  - Any client issues GET to A, retrieving the content A'
> Agreed.
> > On a versioning server with a non-versioning client,
> > where resource A is a VCR, which has DAV:auto-version
> > equals "when-locked".
> >  - client issues LOCK on A, creating a checked-out version
> The check-out doesn't occur until a modification request (e.g.,
> PUT/PROPPATCH) is received.  So a LOCK immediately folowed by
> would not create a new version.
> >  - Lock-owner client issues PUT to A, modifying the
> > checked-out version to have the content A'
> Well, modifying the checked out *version-controlled resource* (not
> 'version', a version does not have a DAV:auto-version property).
> >  - Any client issues a GET to A, which retreives the
> > body of the VCR, which is the same as the body of the
> > last checked-in version, which is NOT the content A'.
> No, the body of the version-controlled resource will be the
> target of the
> GET, so it will be the value of A'.
> > So, on a versioning server with DAV:auto-version set
> > to "when-locked", clients cannot GET the latest content
> > PUT by the lock-owner (without specifying the version URL),
> > until UNLOCK occurs and the version is checked in.  This
> > is inconsistent with the way a non-versioning server
> > behaves.
> >
> > I like the functionality this feature is supposed to
> > provide, but is there a way of resolving this discrepancy?
> > The problem may lie in the fact that the VCR is defined
> > to have the same body and contents of the last checked-in
> > version, rather than the currently checked-out version.
> I believe there is no inconsistency.
> There is a difference between a checked-out
> version-controlled resource and
> a checked out version (which is called a working resource).
> Tim
Received on Tuesday, 6 February 2001 21:46:01 UTC

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