Next message: Geoffrey M. Clemm: "Re: draft-ietf-deltav-versioning-08 now available"
Date: Fri, 15 Sep 2000 09:51:04 -0400 (EDT)
Message-Id: <200009151351.JAA09747@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Working resource locations
From: Tim_Ellison@uk.ibm.com
<tim>
I'm puzzled by the language used in the 10.2 CHECKOUT postconditions, which
states that "...the server MAY locate the working resource at the
request-URL, effectively replacing the version selector...".
</tim>
<geoff/>That language is there to make sure that clients are prepared to
deal with workspace behavior.
<tim_2>
I'm sure that there will be clients that are happy with core and don't
appreciate being prepared for an advanced feature that they have no
intention of using.
This is not a feature that a client can control ... some servers will
only support version selectors in workspaces. When a client issues a
CHECKOUT against such a server, they will see the "replace" behavior.
It seems to me that whether the server overwrites the target selector or
not is a fundamental issue for the client, and they are unlikely to be able
to cope with 'MAY'.
A simple client can cope with "MAY" quite easily. They just want to
change a versioned resource, but that resource does not have
DAV:auto-version set. They issue a CHECKOUT, update the resulting
working resource, issue a CHECKIN, and then a SET-TARGET (i.e. just
what DAV:auto-version would have done).
The result is the same whether or not the server does the checkout
in place.
Consider that if the server does overwite the version selector, the
original request URL now exposes the working resource, and thereby the work
in progress -- other clients will see the updates taking place on the live
server. However, if the server doesn't overwite the target selector the
updates are done 'on the side' and released/published/... to the server
upon checkin. IMHO clients will program to one of these paradigms and fall
into one camp or the other.
Yes, Boris made this point in his review of -08, and I agree with both
of you. I've added a DAV:here and DAV:not-here flag to CHECKOUT for clients
that care which behavior they get (e.g. the server MUST fail the
CHECKOUT if it cannot satisfy the DAV:here or DAV:not-here semantics).
Cheers,
Geoff