- From: James J. Hunt <jjh@allerton.de>
- Date: Tue, 06 Feb 2001 01:13:41 +0000
- 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? Sincerely, James
Received on Monday, 5 February 2001 19:14:02 UTC