OpenDocument - Adv Document Collab SC

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.

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. 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 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. >

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. > > >