[Zope-CMF] Refining the disposition of published-document revisions

[Ken Manheimer]

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