- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 18 Jun 2001 11:16:34 -0400
- To: ietf-dav-versioning@w3.org
From: John Hall [mailto:johnhall@evergo.net] My 'MAY' values are only trying to keep the client from getting into an impossible state. Namely, no UPDATE/MERGE available but the CHECKIN 'apply-to-version' isn't specified. That is not an impossible state. A server may wish to allow versions to be created that will never be used to update the state of a VCR. Or a server may have some other non-standard method of using a version to update the state of a VCR. Now, I thought 'apply-to-version' was a flag on the working resource, but you are putting it in the CHECKIN body. OK. The DAV:apply-to-version flag is already defined in the protocol (in the CHECKOUT body). So can you just let me fail the CHECKIN if 'apply-to-version' isn't specified and neither is UPDATE/MERGE? A server is of course free to do so, but an interoperable client will not expect that behavior. An interoperable client will expect that you do support UPDATE, since that is part of the client workspace package. And another reason for 'MAY' is that different companies might wish to configure a given server in different ways. Although my server will allow versions to be deleted, I'll also provide an admin flag (proprietary) to prohibit it. Every MAY is an interoperability problem, only added as a last resort. The "MAY" for version deletion represents an inherent tension between the desire of a user to preserve history, and the desire of a user to preserve space. Any other "MAY" needs a correspondingly compelling argument. ====================== SO: CHECKOUT (of working copy) postcondition: <!ELEMENT checked-out-VCR (href)> MAY be set on the working copy with the href of the VCR when the current version is checked out. This is set when the server supports apply-to-version. A server that supports the working-resource option MUST support the DAV:apply-to-version, and if we add this protocol element, it similarly MUST add DAV:checked-out-VCR when DAV:apply-to-version is used. Otherwise clients would have to inspect the working resource to determine if DAV:checked-out-VCR was inserted, and then have separate code paths for if it does, or if it doesn't. CHECKIN (of working copy) marshalling: If <!ELEMENT apply-to-version EMPTY> is present and <!ELEMENT checked-out-VCR (href)> exists the server performs a CHECKIN (of working copy) and then automatically updates the VCR to reflect the content and dead properties of this version. DAV:apply-to-version only appears in CHECKOUT, not CHECKIN. [I need an error condition here if the UPDATE wasn't successful. That could happen if checked-out-VCR was invalid.] Good point! That raises two issues: - why did I propose that a client be able to modify the DAV:checked-out-VCR? A client could have checked out a particular version if it didn't want a DAV:checked-out-VCR to be set. - should a server be required to update the DAV:checked-out-VCR property of a working resource if the VCR is moved? I think the answer is yes (only the server can do this correctly). This goes along with the previous constraint that the DAV:checked-out-VCR property is protected. So the modified proposal is: ----------------- Add a protected DAV:checked-out-vcr property for a working resource. Set this property on the working resource created when a CHECKOUT with the DAV:apply-to-version flag is applied to a VCR. Add a postcondition to "CHECKIN" of a working resource that says that if there is a DAV:checked-out-VCR on the working resource, the specified VCR will automatically be updated to reflect the content and dead properties of the new version. Add a postcondition to "MOVE" of a VCR that says that if there is a DAV:checked-out-VCR that identifies that VCR, that property is updated to reflect the new location of the VCR. ------------------ Cheers, Geoff
Received on Monday, 18 June 2001 11:13:01 UTC