- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 10 May 2001 09:15:12 -0400
- To: ietf-dav-versioning@w3.org
We always supported tracking the checkin date, but we never supported tracking the checkout date. Even with working resources, although the DAV:creation-date of the working resource is the checkout date, the working resource is deleted when it is checked in, and the DAV:creation-date of the new version resource indicates when that version resource was created, i.e. the checkin date. The DAV:checkin-date property was removed from the spec when we observed that the DAV:checkin date of a version will always be the DAV:creation-date of that version, so the DAV:checkin-date was redundant. The versioning protocol does not modify the behavior/definition of DAV:getlastmodified, so it just displays its standard behavior, i.e. it MUST change if the content of the resource changes, and it MAY change for other reasons (such as a change to some property value). Cheers, Geoff -----Original Message----- From: Juergen Reuter [mailto:reuter@ira.uka.de] Sent: Thursday, May 10, 2001 6:09 AM To: ietf-dav-versioning@w3.org Cc: reuter@ira.uka.de Subject: Dates Just wondering... In early versions of DeltaV there was a DAV:checkin-date property defined on version resources. Together with DAV:creationdate, one was able to track both, the checkin and the checkout date. According to the current draft, should I use DAV:getlastmodified instead? (Note on issue WRITE_DAV_PROP: This would require the lastmodified date not being affected, when properties on version resources are modified.) Greetings, Juergen
Received on Thursday, 10 May 2001 09:12:47 UTC