Re: Making "LABEL" optional

Is this really the case? Or is just the case for older linear documents.
I agree with your arguments if in fact you have standalone objects as in 
your examples. But are these examples a reasonably representative set, 
or just a particular subset?

It seems certainly not the case for a Web document which may consist 
of a hierarchy of pages, images, MM files and maybe even some sort of 
personalization data so Joe's story unfolds differently than Jane's
because of a different set of choices. 

The "document" in this case could be a substantial collection, and some
means of tying together a consistent set across different stages of 
creation and maintenance and maybe even viewing would be mandatory. Note 
time is NOT necessarily a good criterion for selection since edits can 
be undone to restore previous versions as a perfectly valid operation.

It seems to me that versioning of such a document should still be possible
with core/simple versioning systems. If I am a lowly author, I don't want
to have to figure out or administrate a complex versioning tool. What does
seem to be needed though is a way to easily mark and identify a set of 
objects for such an author to keep some sort of handle on his work.

If there is a way to do this with properties, or some existing core
commands, then there is no need to have labelling in core. If the steps
that need to be followed to do this (like ensuring there is only a single
identifier per version history) are just recreating a "label" operation
then either label itself is redundant or one should use at least a simple
form of it in core.

Perhaps it would be useful to outline a few more scenarios which could be
used to decide just what "core" functionality means, and which types of
documents would be applicable to or excluded from "core versioning".

Cheers,
RossW

Lisa Dusseault wrote:
> 
> One of the very differences between a source-management system and a
> [simple] document-management system with versioning is that the simple
> doc-mgmt system does not have any concept of a consistent set of revisions.
> 
> For example, let's say EJW wanted to keep all WebDAV related drafts in a
> WebDAV repository.  Is there any concept of "consistent set" between the ACL
> draft, the versioning draft, and the various advanced collections drafts?
> Only minimally if at all -- and any desire to see what changes were made at
> the same time can be satisfied by looking at the dates of the older
> versions.  Such a repository would be useful, keeping a history of document
> changes around, yet it would have no strong need for labeling.
> 
> In this scenario, comments could serve any need for user-readable info on
> previous versions.  For example version 10 of the versioning draft might
> have a "last call" comment on it.   Note that the "last call" version of the
> versioning draft has nothing to do with the "last call" version of the acls
> draft.  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.
> 
> 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?
> 
> Lisa