W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Labels and Status

From: James J. Hunt <jjh@allerton.de>
Date: Tue, 06 Feb 2001 01:13:41 +0000
Message-ID: <3A7F4FC5.AC1178F5@allerton.de>
To: lisa <lisa@xythos.com>
CC: Greg Stein <gstein@lyra.org>, ietf-dav-versioning <ietf-dav-versioning@w3.org>
Lisa Dusseault wrote:

> > -----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

Dear Lisa,

Well written!  A first stab at a general mechanism might be a
DAV:mutable-property tag.

<!ELEMENT mutable-property ANY>
<!ATTLIST mutable-property name CDATA #REQUIRED>

Mutable properties are application defined properties on a version resource
or version controlled resource with the following characteristics:

   1. they can be changes at any time by a WebDAV client; and

   2. they are cleared on a target version resource when that resource is
checked out.

This is certainly better than nothing, but three problems remain:

  1. how can one trace who changed this property last;

  2. how can access to such a property be controlled; and

  3. how can standard mutable properties be defined later?

Received on Monday, 5 February 2001 19:14:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC