W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Labels and Status

From: Jim Amsden <jamsden@us.ibm.com>
Date: Fri, 2 Feb 2001 10:26:35 -0500
To: ietf-dav-versioning@w3.org
Message-ID: <OF363971E5.3CD0C94F-ON852569E7.00546C1E@raleigh.ibm.com>
Introducing server-defined status properties is starting down the slippery 
slope of document management. We intentionally kept this out of Delta-V 
because it didn't seem essential for versioning support, and would 
seriously delay its introduction. I suggest we may want to start another 
working group soon that address Delta-V extensions for interoperable 
document management. I would be happy to be involved.

"James J. Hunt" <jjh@ira.uka.de>
Sent by: ietf-dav-versioning-request@w3.org
02/02/2001 09:55 AM
Please respond to jjh

        To:     ietf-dav-versioning@w3.org
        Subject:        Labels and Status


Dear Colleagues,

There seem to be some confusion in the protocol description as to for
what Labels are good.  At least the example is misleading.  A label with
the name released is in general not useful, because released has the
character of status and a file may have only one revision with the label
released.  Over the course of time several versions will be "released".
A better example would be the label release_3.1.

Since there are revision control systems that support a status
property, it would make sense to support it explicitly as an option.
Status can not be implemented as a dead property for two reason:
  1) a versioned resource or working resource that is updated or created
     by a check-out request should NOT inherit the value of the status
     of the version being checked out, instead it should be set to a
     server defined base value or left empty; and
  2) status should be changeable on a version without creating a new
     version, similar to label.
Systems that implement both base-lines and status should provide a status
for base-lines.  The value of status should be an NMTOKEN.

James J. Hunt
Jürgen Reuter
Received on Friday, 2 February 2001 10:26:42 UTC

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