Re: [office-collab] Change Tracking and Epochs.

[monkeyiq <monkeyiq@gmail.com>]

On Mon, 2011-05-16 at 11:39 -0400, robert_weir@us.ibm.com wrote:
> I like this idea.  And I'd suggest one additional wrinkle.  Perhaps along 
> with document-level revisioning, there is also more granular revisioning 
> at the level of a section, or a presentation slide.  This is especially 
> interesting for distributed editing tasks where multiple users are editing 
> the same document. 

As an additional plus, this would limit the scope to a subdocument to
consider the old revision 1-10 and revision 11 for. My initial thoughts
were that there might need to be branching considerations here. Though
the case boils down a bit because we are not saying that a section can
be in two section level epochs at once (ala a branch).

There is still the case of how a document epoch would relate to a
section epoch. Perhaps making a document epoch would force all sections
to a new epoch as well. So a single doc-epoch can have many
section-epochs, but no smaller epochs can outlive their container.

> 
> But it isn't clear to me where this information goes:
> 
> A) Keep the document XML simple, a projection of a single revision, a 
> snapshot if you will.  The complexity of the revision history is stored 
> externally, in a database.
> 
> B) Store the revisions in the XMK, or at least in the ZIP container.  Make 
> it self-contained.
> 
> -Rob

I'm not sure which policy decision OASIS prefers there. I lean towards
(a) but for a volatile long life document it would lead to bloat. 

I don't know how zip interacts with large stable text chunks. If small
changes in the contents of the zip are amplified to larger changes in
the ZIP itself, as I suspect, then this would also lead to higher
bandwidth consumption during document checkouts even though much of the
document content might be just the stable epoch history. This assumes
that folks are using git, svn or other to actually maintain a central
repository for the document.

If the information is to be contained in the ODF file, it might make
sense for metadata for where to find the older epochs in there too.
Although RDF might not be the way to go, it would offer applications an
extensible way to unambiguously describe one or more means to acquire
older epoch document versions. On a epoch level if desired. Another
advantage being that it keeps the core <delta:tracked-changes> element
lean.

It also opens up how to describe where to get software resources (be
them source code or document versions) into a wider group. For example,
perhaps using DOAP which already includes information about releases and
repositories;
http://trac.usefulinc.com/doap


> 
> 
> monkeyiq <monkeyiq@gmail.com> wrote on 05/16/2011 08:43:37 AM:
> 
> > 
> >  I'm not sure if this would be desired at the spec level or just left up
> > to implementations to piece together as they wish. But at the spec level
> > it might be nice to at least be able to explicitly indicate that a
> > delta:change-transaction element represents a coalesced revision to
> > avoid confusing applications.
> > 
>