RE: Label behaviour...

Jim says:

>Your are correct on the distinction between adding and setting a label. 
>Its there to avoid inadvertant reuse of a label. See the precondition for 
>DAV:must-be-new-label. This indicates that for DAV:add, the label MUST NOT 
>currently select a version. The postconditions for add and set are the 
>same.

OK, I am happy that it is clear how DAV:add should behave, but I think the
spec needs more detail on how DAV:set behaves, does it:

a) "move" the label, eg if it is already used by another version of the
resource 
   it will be removed from that version and added to the version indicated
by the 
   LABEL request.

or

b) Allow the same label on multiple versions of the same resource? 

Jim says:

>I don't know what you mean by "the labels that are in use". Do you mean 
>the intersection of all labels on all resources? If so, why would you need 
>this?

I want a pulldown list of currently in use (intersection of all labels on
all resources) so the user can pick a label.  Obviously the user needs the
ability to enter one that does not already exist but seeing the list of
existing ones will help in several use-case scenarios, eg:

Imagine user Fred goes to his WebDAV client to do some work on a set of
source code, his colleague has told him by word of mouth etc that he should 
use a label called "Special Label 1".  When he uses the WebDAV client he 
could put in any old label, eg "Special-Label-1" or "SpecialLabel1" etc, he 
could enter a different label from the one all the other developers have
been 
using.

Another scenario is that you want to create a new label with a similar
naming
scheme from other labels already in the system, for example a project is
under
QA testing and all the versions of source under test have been marked with a
label called "System Test Build 1".  Now a user wants to mark code using a
label
to indicate versions of code for use in the next system test.  Without being
able to see that the label "System Test Build 1" was used previously the
user
might choose to call this new label "QA Build 2".

I guess what I am getting at is that by providing a list of labels already
in use you can cut down on mistakes and the proliferation of similar label
names.

What do other people think, any client writers out there that want to
provide
a list of existing labels?

Regards,
-- 
Peter Raymond - MERANT 
Technical Architect (ADM) 
Tel: +44 (0)1727 813362 
Fax: +44 (0)1727 869804 
mailto:Peter.Raymond@merant.com 
WWW: http://www.merant.com