OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Change Tracking and Epochs.


Hi,
  When I mention change tracking to some folks it has been mentioned a
few times the interplay between revision control systems like git and
the proposals. This got me thinking a bit and it strikes me that using
git for ODF change tracking is somewhat like widening the ECT "buckets"
to a whole document granularity.

  Thinking further, long life documents might call for the intermixing
of both technologies -- revision control and change tracking in
content.xml. Consider a document which lives in one version or another
for 10-20 years and undergoes changes fairly frequently. In this case
one might wish to be able to use both a revision control system like git
and content.xml change tracking together.

  As a concrete example, one might want to have say, 20 revisions, and
then at some point there have an acceptance stage for the document. This
document might be checked into git first, then accepted and revisions
set to number 21 with all changes coalesced into a single version (21).
From there new changes would continue at 22.

  It would however be nice for the delta:tracked-changes to retain the
revision 1-20 information and some link to where to get that epoch of
the document. So if, in 10 years time I want to see what happened now I
can grab the document with those changes in it and open it up for
inspection. This document epoch might perhaps include revisions 6540 to
6630. Conversely, when dealing with adding new changes to that document
in 10 years time, the application only deals with say the last 20-50
revisions, keeping complexity manageable for long life mutable
documents.

  Retaining the delta:tracked-changes block should allow applications to
compare documents from multiple epochs. Though this sort of thing calls
for the merging of two document scope "buckets" and is likely a rather
complex thing that a specialised application would have to handle.
Having a constraint that a start of a new epoch MUST be a coalesce only
operation would help because you would know that collectively the epoch
with revision 1-20 in it should be isomorphic at revision 20 to revision
21 in the next epoch. ie, no changes should be performed between 20 and
21.

  Another nice feature of retaining the delta:tracked-changes for
coalesced version numbers is that analysis could reveal the time frames
that various users contributed to a document. So they can pull up the
last changes that John Doe made 3 years back. Though a system like git
would also allow this sort of enquiry, though this falls outside the
shell of the ODF file itself. 

 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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]