Re: Labels and Status

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
        cc: 
        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.

Sincerely,
James J. Hunt
Jürgen Reuter