- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Wed, 11 Oct 2000 23:21:56 -0400 (EDT)
- To: ietf-dav-versioning@w3.org
From: "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com> The combination of standard client defined properties like DAV:comment and DAV:creator-displayname, custom client defined properties, and standard server defined properties like DAV:version-name and DAV:getmodificationdate, are sufficient to name and locate versions of interest, and this is demonstrated by the document management systems that do so (without the use of labels). <jra>This does not sound like either an adequate, optimal, or interoperable way of distinguishing revisions of the same versioned resource. Adequate? Certainly (for the vendors that do just that today). Optimal? Well, optimally you'd have activities and baselines as well. Interoperable? Certainly. Display the version properties in your client GUI and let the user select the version they want. Relying on DAV:comment to distinguish revisions would introduce the possibility of parsing comment strings to identify a revision. This doesn't sound convenient or interoperable. What parsing is required? DAV:comment is defined to be a string to be displayed to the user. Your client can just do so. This sounds both convenient and interoperable (can't get much simpler than printing out a string). Your client should certainly provide that functionality anyway (i.e. updating properties, and displaying a list of versions with their properties, so the user can pick one from that list). The only code you need to add to your client to handle a server without labels is to put an "if (labels_supported)" flag in front of the code that displays GUI operations that use labels. (Just like the code that you have wrapped around checkout/checkin to handle a level-1 or level-2 WebDAV server). Cheers, Geoff
Received on Wednesday, 11 October 2000 23:22:28 UTC