RE: Making "LABEL" optional

(In reply to Lisa's posting...)

<jra>Lisa, I appreciate you concern for minimizing the requirements for DMS
systems. They play an important role in Web authoring. Perhaps we have a
different view of labels though. See if the comments below address your
issues.</jra>

There is very little to be gained from supporting labeling when
there is no concept of a consistent set of revisions, and I argue that this
is the case in many simple doc-mgmt systems which support versioning.

<jra>Support for labels isn't intended to be used to create and/or manage a
consistent set of revisions. Labels in WebDAV aren't "sticky". You can't
lock a label on a revision. So you could use a label to name a consistent
set of revisions, but you can't be sure you'd always get the same
revisions. That's what baselines are for, and this is clearly an advanced
concept. Clients might move the label anytime.</jra>

Is there a justification for supporting labelling that does not require
advanced source-related concepts like "consistent set of revisions", or
that
cannot be satisfied by using the version's comment or date properties?

<jra>Sure. Labels are just a way of distinguishing one revision from
another using an identifier that has some meaning to the user making the
distinction. So in your example, I find lots of meaning in document
revisions labeled as "last call" even though there is no relationship
between them(manifest as links or references) that needs to be captured as
a consistent set in a baseline. The label just helps identify which version
of the document is in the last call state. Its just easier than saying "go
look at revision 1AB2795" or some other equally meaningful server generated
id. This seems pretty useful, and its pretty simple.

Are you thinking that label support implies baseline support, or that there
is even a relationship between them? Baselines have nothing to do with
labels. They are not related in the protocol. Labels are just added and
removed from revisions. The only requirement is that the same label can't
be on more than one revision of the same versioned resource at the same
time. This, and the ability to use them in a Target-Selector header or
SET-TARGET method is about the only thing that distinguishes them from
properties.<?jra>

Received on Wednesday, 11 October 2000 17:35:11 UTC