[Zope-CMF] Refining the disposition of published-document revisions
robert at rocad
robert@rocad.ch
Mon, 28 May 2001 13:04:52 +0200
Hi Ken,
I should be possible to keep old versions of a document which after being
replaced by a newer version become viewable only or copied to become a new
document with new ID.
This is to be able to leagaly prove the status an evolving document had at
a given point in time.
I am thinking of drawings used in a construction process that are kept in a
CMF based structure and downloaded and use as base of some atinional tasks
like construction of ductwork.
Contrary to the proccess used creating software or disscussing a topig where
checkpoints migth be used to revert to or to start a branch such documents
must be "fixed in stone".
Robert
----- Original Message -----
From: "Ken Manheimer" <klm@digicool.com>
To: <zope-cmf@zope.org>
Sent: Friday, May 25, 2001 7:57 PM
Subject: [Zope-CMF] Refining the disposition of published-document revisions
> I'm planning to turn the following into a proposal. It's sorta related to
> the version-checkpoint discussion that's happening, but i think a bit
> different, too. (I've been a bit sketchy following the discussions, so
> let me know if i'm off base.) I'd be interested in people's input.
>
> Ken Manheimer
> klm@digicool.com
>
> Context
>
> In the CMF, the disposition of published document edits is
> problematic. This proposal suggests an approach to correct that. I
> also describe some potential implementation avenues.
>
> Problem
>
> In the CMF currently, the system either needs to prohibit editing of
> published documents, or allow them but wind up with the document in
> an inappropriate state. That is, if edits are allowed and the
> document is left in the published state, the review process is
> defeated. Alternatively, inherently moving edited documents back to
> the private state is awkward - editing a document would then cause
> too much disruption.
>
> This problem grows geometrically when you start to deal with
> composite documents, involving multiple subelements - any of which
> may need editing at some point, thereby invalidating (in one way or
> another) the composite document as a whole.
>
> Forces
>
> One primary component of "content management" is review processes,
> by which release of contributed material is regulated in a
> predictable way. However, awkwardness in the results of editing
> published documents yeilds a system that's good only for the first
> revision of a document, but fatally flawed for management of
> evolving content - the kind of thing you would expect to find common
> in community sites, corporate intranets, public-facing informational
> sites, and so forth.
>
> Solution
>
> The essence of the solution is to treat document publication as
> applying specifically to the particular revision of the document
> being published. Public visits to the document go to that published
> revision, while new revisions created by edits are back in the
> default private state. When a new revision is ready for approval,
> it is put through the publishing process, and once approved the new
> revision replaces the old one. (The workflow could have special
> accommodations for new revisions, eg streamlining the approval
> process - or not.)
>
> Additionally, it may be valuable to associate particular released
> revisions of a document with a collection of document revisions
> across the site - for a checkpoint version of that collection. This
> association could be achieved using a symbolic version label for the
> revision, selected from some set or sets existing across the site.
>
> Possible Implementation Avenues
>
> Obviously, Zope object revisions offer a prime prospect for
> implementing this functionality. Some changes would be needed to
> facilitate the changes.
>
> - Some change would be needed to facilitate pointing the public view
> of a document at the published version, rather than the most
> recent version.
>
> - Currently, access to historic versions of a document is
> expensive - maybe expensive enough to make widespread exposure of
> historic versions prohibitive. This may need to be optimized,
> perhaps just to offer privileged accessibility to the published
> revision, in addition to the frontier version.
>
> - Currently, historic revisions of a document are not exempted
> from packing - if they are older than the limit-date of the
> pack, they are removed. Provisions would be needed to exempt
> the published historic revision. If we aim to have checkpoint
> collection versions, then historic revisions in a retained
> collection would likewise need to be exempt.
>
> Risks
>
> - These changes constitute elaboration of the publishing process,
> and would be surprising to authors unless they are adequately
> explained. The current alternatives are more surprising, though,
> and much less pleasantly so. I think the proposed mode of
> operation is just about what people would want, and would be
> welcomed.
>
> - The sketched implementation would increase ZODBs complexity. This
> may to be an emminently suitable use of historic versions, in
> which case i would expect it to be moderate and warranted
> complexity increase.
>
> - Inherent packing exemption of object revision collections will
> increase database bloat, to some degree. Checkpoint versions, in
> particular, could lead to wholesale increases in the amount of
> retained objects. This may lead to needing some means for site
> administrators to identify space-costly checkpoints, and to be
> able to export and/or delete them. More work, but greater
> discretion.
>
> Resulting Context
>
> With this approach, document editors can revise their documents
> without escaping the review process, and without disrupting access
> to their released versions. This eliminates the rigidity (or
> brittleness) of a managed content site with the current publishing
> mechanisms, particularly when it comes to composite content whose
> publication integrity depends on the publication status of all its
> parts. The addition of being able to assign document revisions to
> symbolic version
>
>
> _______________________________________________
> Zope-CMF maillist - Zope-CMF@zope.org
> http://lists.zope.org/mailman/listinfo/zope-cmf
>
> See http://www.zope.org/Products/PTK/Tracker for bug reports and feature
requests