Re: [office-comment] Change Tracking issue

[Bryce L Nordgren <bnordgren@fs.fed.us>]

Patrick Durusau <patrick@durusau.net> wrote on 12/28/2007 11:59:39 AM:

> Bryce,
>
> Just a quick question about a very interesting proposal:

Not sure I saw a question in there. :)  I think we are in basic agreement.
I'm not necessarily against in-document change tracking as an option.  I
think it is a very poor choice because the TC would be imposing a single
versioning model on the entire office app community.  And then all apps
must implement it.  Then we have to worry about being backwards
compatible--no fresh starts.  I suspect the technical drawbacks, as well as
the work of maintaining a "custom" versioning model which is functionally a
subset of much more mature systems, will obsolete change tracking all by
itself.  As it dies, though, I want the option of using another system;
particularly when managing large assemblages of linked content or when
collaboratively authoring a paper. :)

Is there anyone on the list who would object to making a "live filesystem
document package" part of the official specification?

Conceptually, change-tracking-in-the-document annoys me because it violates
encapsulation in a domain which has already realized great benefit by
embracing encapsulation.  In 20 years, no one has felt the need to add
source code versioning support to "vi", "emacs", "Notepad",
"Eclipse/editor" or compilers for C, Java, Fortran, Python, Perl, etc.
Because the "coin of the realm" is a text file, you can very cleanly
separate concerns: editing and compiling are separate from versioning.
Changing from CVS to Subversion does not have "ripple effects" in your
editors and compilers.  By adding basic versioning to a textfile office
document format, the concerns are not nearly so separate: editors and
processors/renderers must comprehend versioning.  Ripple effects will touch
everything which implements ODF, with every change to the versioning model.

Bryce