RE: Labels and Status

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Greg Stein
>
> I think the point here is to have mutable properties (e.g.
> "status") on
> immutable resources (e.g. version resources). That doesn't
> make sense to me
> at all.

I hope to make it make sense, then.  I think many processes, both in the
source-control world (building, testing) and the document-publishing
world (reviewing, approving), require mutable properties on immutable
resources.

Example 1 -- build process

The build process involves a nightly build with a build ID.
Testers/coders want to be able to look at a version of a file, and see
if it ever was successfully part of a build.  You would want to define a
property like "successful-build-set".  If a particular version of a
particular resource is successfully built into build 1527, you add that
value to the "successful-build-set" property of that version.  The next
night, the version doesn't change, but the build number is 1528, so now
the "successful-build-set" property should have two build IDs in its
value, without having the version itself ever change.  The third night,
code is changed in that file, so a new version is created.  It
successfully builds into build #1529, so now on the _new_ version, the
"successful-build-set" property has the value "1529".  The _old_ version
still has a value of "1527, 1528", for the same property.

Example 2 -- document publishing

In a document publishing house, you want to keep track of which versions
have been reviewed and approved for publishing.  (You can't use LABEL
because more than one version of a document may have been reviewed, and
more than one version may have been approved, and LABEL doesn't allow
the same value on different versions).  So you want to define a set of
properties:  "reviewed-by", "reviewed-date", "review-status",
"approved-by" and "approved-date".  Each of these properties needs to be
changed, without creating new versions.  For example, the publishing
policy might change, and the reviewer needs to go back to a version that
had previously been marked "review-status" = "NOT_APPROVED" and change
the value to "APPROVED".  Or in a completlely normal process, the
reviewer might want to mark "reviewed-by" as "Joe Blow", and
"review-status" as "RECOMMEND_APPROVAL".  Then Joe's manager can go in
and change "review-status" to "APPROVED" and also set the "approved-by"
and "approved-date" properties accordingly.  All of these properties
refer to a specific version of the document, not to the document as a
whole.  None of these properties should ever force a new version to be
created.

So my question is, where else, besides the versions themselves, are you
going to set these properties?  I believe it does make sense to have
mutable properties on immutable resources.  It is a matter of
administrator policy, more often than a matter of implementor policy.

I can certainly understand the existence of systems where the model and
processes are defined so that mutable properties are forbidden.
However, that is an implementor choice which restricts administrator
policy.  In my implementation, we do not wish to restrict administrator
policy in that way.

Lisa

Received on Monday, 5 February 2001 17:59:47 UTC