[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