- From: Tim Ellison <Tim_Ellison@uk.ibm.com>
- Date: Wed, 11 Jul 2001 10:43:48 +0100
- To: ietf-dav-versioning@w3.org
Peter Raymond <Peter.Raymond@merant.com> wrote: > 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. I have no problem with spelling this out in the spec. > or > > b) Allow the same label on multiple versions of the same resource? I think this is already clear. From Section 8: "A given version label can be assigned to at most one version of a given version history, but client assigned labels can be reassigned to another version at any time. Note that although a given label can be applied to at most one version from the same version history, the same label can be applied to versions from different version histories. " > 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: The question is what do you mean by "all resources"? Since the deltav-compliant resources may be managed by many overlapping servers (with holes created by non-deltav compliant resources), and distributed servers, it is unlikely that "all resources" is very meaningful. > 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. Give Fred a Post-It <g> > 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? I understand your point, but I don't see the value for such an unbounded query. I stand to be corrected. Regards, Tim
Received on Wednesday, 11 July 2001 06:41:05 UTC