[Zope-CMF] Refining the disposition of published-documentrevisions

seb bacon seb@jamkit.com
Wed, 30 May 2001 10:17:41 +0100


* Chris McDonough <chrism@digicool.com> [010530 08:32]:
> This is a very clear summary.

I agree...

> Another potential implementation avenue is to create revision-aware
> content types.  For instance, a formatted document class which contained
> multiple revisions -- a public revision and a current revision.  An
> instance would always render a version of itself to visitors based on
> the public revision while workflow was pending for the current revision
> (if they differed).  This is actually pretty simple.
> 
> This would have the benefit that no path-munging nor ZODB changes would
> be necessary.  OTOH, all content types would need to be modified to
> support this behavior.

If I understand you correctly, I believe this is what Shane was
proposing.  The important point here is that a document 'knows' what
its default version is.  Should this follow a simple policy (e.g. The
most recent version accessible to the user) or should it be
web-configurable (e.g. the most recent version accessible unless
you're a Manager, in which case you see the most recent non-public
version)? 

I think the idea of an audit trail is too valuable to leave out
of the proposal, since it meshes very closely with it.  Typically,
this would be a detail of the workflow implementation (a new,
'frozen', readonly state), but it's probably worth mentioning at this
stage.  From comments on the list, it's something people regard as
very important wrt document management.

The other issue worth noting is DB bloat, which you only
mentioned with reference to the idea of object revisions, but would
remain a problem (even more of a problem?) whatever the implementation
might be.  The versioning system must cater for scheduled archival /
deletion and be able to do so in interaction with workflows.  Then we
can make sure you can't delete a 'frozen' document, for example.

seb