RE: Labels and Status

I'd second what James says, only make it even more general.

Yes, many versioning systems have "status" properties on versions, and
the "status" property should be mutable, i.e. should be writable without
creating a new version.  (Immutable properties never change on old
versions; changing an immutable property creates a new version).

However, there are also publishing or workflow processes which require
their own mutable properties.  For example, "publishing-status" or
"editing-status" or "approval-status" or "invoice-status"...  We can't
be expected to predict all these, however it's a common need, and
defining only 'status' would not solve the general problem.

Thus, versioning needs a general way to allow creation of custom
properties which are mutable, AND custom properties which are immutable.
The server would of course reject requests for mutable properties if it
does not support mutability, but we need a standard way for clients to
ask for this.

Lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of James J. Hunt
> Sent: Friday, February 02, 2001 6:56 AM
> To: ietf-dav-versioning@w3.org
> Subject: Labels and Status
>
>
>
> Dear Colleagues,
>
> There seem to be some confusion in the protocol description as to for
> what Labels are good.  At least the example is misleading.  A
> label with
> the name released is in general not useful, because released has the
> character of status and a file may have only one revision
> with the label
> released.  Over the course of time several versions will be
> "released".
> A better example would be the label release_3.1.
>
> Since there are revision control systems that support a status
> property, it would make sense to support it explicitly as an option.
> Status can not be implemented as a dead property for two reason:
>   1) a versioned resource or working resource that is updated
> or created
>      by a check-out request should NOT inherit the value of the status
>      of the version being checked out, instead it should be set to a
>      server defined base value or left empty; and
>   2) status should be changeable on a version without creating a new
>      version, similar to label.
> Systems that implement both base-lines and status should
> provide a status
> for base-lines.  The value of status should be an NMTOKEN.
>
> Sincerely,
> James J. Hunt
> Jürgen Reuter

Received on Friday, 2 February 2001 13:16:18 UTC