[Zope-CMF] Versioned Documents (was: Workflow first cut is ready)

seb bacon seb@jamkit.com
Mon, 28 May 2001 12:02:00 +0100


* Shane Hathaway <shane@digicool.com> [010525 03:46]:
> On Thu, 24 May 2001, Loren Stafford wrote:
> 
> > We haven't defined our requirements on cataloging former versions, because
> > no one ever thought about it. Of course the documents have to be accessible
> > thru the catalog in some way. But I can see arguments in favor
> > (completeness) and against (redundancy) cataloging of entire contents.
> > Perhaps there should be some simple way to override the searchable_text (or
> > whatever it's called) method for former versions.
> 
> Actually, we should discuss the rationale for putting information about
> older versions in the catalog.  Is it necessary?  Is it enough if you can
> just get to the older versions via URL?

I can't think of any reasons to catalog all past versions, for the
reasons of redundancy listed above.  At least not in any applications
I personally envisage.

> > > When an object is copied to a
> > > version, does the copy participate in a different workflow than the
> > > original?
> >
> > From a requirements view: Yes. In our environment, former versions should
> > not be modified unless there is some powerful overriding need. That implies
> > a different workflow. Also the decision to delete, would probably be part of
> > a different workflow. Whether that's a different Workflow object or a
> > different branch of the parent Workflow object is an implementation call, I
> > suppose.
> 
> If the object copy is to be in a different workflow then the set of
> workflows an object participates in depends on more than just the type of
> the object, which the current workflow tool doesn't support.  But I think
> we can get it to support it.
> 
> (Aside: I was recently pondering workflow and realized that maybe an
> object can move in and out of workflows regardless of its type.  Take, for
> example, UPS and FedEx, which temporarily put arbitrary packages in their
> own workflow.  The person who makes the package does not need to do
> anything special to make it possible for UPS/FedEx to tack on their own
> workflow.)

I think this is the point - although selecting workflow by type should
cover 95% of requirements, it is not a necessary connection, and
should probably be abstracted out a level.  

> 
> > > Everyone, does this informal proposal serve your needs?
> >
> > Looking good!
> 
> Great.  From your feedback, though, I think we need to understand the
> requirements better.

Ken's post seems to interlock with this fledgling proposal quite a
bit.  some of the risk factor he has identified are important,
particularly the concern about database bloat - an archiving /
redundancy mechanism should really be built in from the start to
counter this tendency.  I'm not quite sure what Ken's proposing with
'Zope object versions', though - hopefully this will get explained on
that thread.

I think your proposed solution sounds mostly there, though.  I'll
have more input when I've read ken's proposal all the way through.

seb