RE: Autoversion confusion

Tim,

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.

Lisa


> -----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
> an UNLOCK
> 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