- From: <Tim_Ellison@uk.ibm.com>
- Date: Fri, 19 Jan 2001 09:21:36 +0000
- To: ietf-dav-versioning@w3.org
<tim> 2.2.1 DAV:checked-in 'This URL can be used to retrieve this particular state of the version-controlled resource after the version-controlled resource itself has been modified.' Given that this is a property of a checked-in version- controlled resource, I fail to see how the version- controlled resource itself can be modified. </tim> <geoff> ?? By MERGE, by UPDATE, and by CHECKIN/PUT, for example. (The last changes it into a checked-out resource, but it is still the same resource). </geoff> <tim_2> ...but each of these change the DAV:checked-in value, so after the resource has been modified, that property cannot be used to retrieve the previous state of the vcr (i.e., the previous state of the property can be used to retrieve the previous state of the vcr). and <chuck> Section 2.2.1, "DAV:checked-in (protected)", sentence 2: "This URL can be used to retrieve this particular state of the version-controlled resource after the version- controlled resource itself has been modified." This sentence should be moved to Section 2.2.2, "DAV:checked- out ...", because it's true there but incorrect here. </chuck> <geoff> ?? The DAV:checked-in property means that the vcr is checked in (thus the name :-), and the DAV:checked-in version captures the current state of the vcr. This is not true for a checked out vcr. </geoff> <tim_2> Well it seems that Chuck and I were equally confused by this sentence. In Chuck's defense, the sentence he proposed moving *does* equally apply to DAV:checked-out (i.e., when refering to the DAV:checked-out property). However, I think that I understand where you are coming from -- namely that a client can take a copy of that DAV:checked-in URL and use it later to refer to the previous state of vcr when the DAV:checked-in value has been overwritten. </tim_2>
Received on Friday, 19 January 2001 04:22:21 UTC