RE: Label behaviour...

Peter,
We'd be happy to include some clarification on DAV:set vs. DAV:add. 





Peter Raymond <Peter.Raymond@merant.com>
07/10/2001 01:58 PM

 
        To:     Jim Amsden <jamsden@us.ibm.com>
        cc: 
        Subject:        RE: Label behaviour...

 

Hi, 
Jim says: 
>The spec says that a label can only be on one version of a given version 
>history resource at a time, so DAV:set has to move the version. 
Yes, I agree this is the right behaviour for the DAV:set operation, but 
I think the specification should call this out instead of inferring it 
from the pre and post conditions, otherwise you risk server implementers 
incorrectly implementing this and allowing multiple versions to have the 
same label. 
Jim says: 
>Querying a repository for all labels currently in use may be 1) quite 
>expensive for some servers, and 2) provide too much information for most 
>practical uses, including the scenarios you describe below. 
Good point, I suppose you could end up with too much information. 
But then perhaps you would then want the client to have a UI facility to 
"find" or "filter" labels, eg instead of a simple drop down list you could 

have a little dialogue where you can search to find labels (eg all labels 
that start with QA). 
Jim says: 
> Since reusing labels imples there's some relationship between the 
resources 
> versions (all the ones having the same label), it would be better for 
clients 
> to take advantage of these relationships to put up a more reasonable, 
and 
> smaller set of candidate version labels. For example, display the 
> DAV:label-name-set on a collection representing a 'project' or some 
other 
> prominent resource in a set of related resources. 
Yes, I suppose we could maintain a set of the labels in this fashion. 
It's just that I have worked with clients that just provide a simple 
text entry field for label names and I have found that the label 
names get in a mess with a proliferation of similarly named labels. 
This issue isn't a "killer" for me, I can live with DeltaV the way it is 
(using your above workaround).  However, I do think we should define the 
behaviour of DAV:set for the LABEL method more clearly, I asked several 
other developers in our office (who have also read the spec) and they were 

all confused as to the difference between DAV:add and DAV:set. 
Thanks for the response. 
Regards, 
Peter. 

Peter Raymond <Peter.Raymond@merant.com> 
Sent by: ietf-dav-versioning-request@w3.org 
07/10/2001 11:36 AM 
  
        To:     ietf-dav-versioning@w3.org 
        cc: 
        Subject:        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

Received on Tuesday, 10 July 2001 17:06:21 UTC