W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: optional labeling

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Wed, 11 Oct 2000 23:21:56 -0400 (EDT)
Message-Id: <200010120321.XAA19486@tantalum.atria.com>
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

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).

Received on Wednesday, 11 October 2000 23:22:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:45 UTC