Re: [office-comment] Change Tracking issue

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

At the risk of being unpopular, how about taking exactly the opposite
approach?  Namely, transfer the responsibility for version control to an
application specifically designed for it, possibly deprecating and retiring
support for change-tracking-in-the-office-document?  If users wish, they
can have much more comprehensive "change tracking" than currently offered
by any office suite, and it doesn't leave a record in the file itself.  As
a bonus, most dedicated "change tracking" software (read: software
configuration management software) also supports distributed editing and
collaborative authorship in ways that no file format specification can.
Office document change tracking lags textfile change tracking by 20 years!
(Did MS word offer change tracking in 1988?  VMS had file versioning back
then, and I also believe "ci myPaper.tex" would work.  So would "co -r 1589
myPaper.tex".)

Here's the beauty part: if you need to have access to the document history,
you're going to need to authenticate yourself to the repository.  Put
another way, employees get "working copies" containing only the current
version, but the sensitive IP surrounding how the "current version" evolves
is in a centralized repository which can be hardened.  Again, _not_ the job
of a file format or an office application!  Alternatively: give an IT
security officer the option of collecting sensitive information in one spot
or distributing it to everyone who gets a copy of a document which once
held something they shouldn't see (even if "responsible individuals" have
the option of encrypting it), what's he going to choose?  Can you imagine
asking "vi" to handle authentication and private/public key encryption?
Let the office apps concentrate on formatting content, don't require them
to "safeguard" content!  They just won't be very good at it.

I'd like to see OpenDocument 1.2 define a "format" much like the packaged
JAR format, but implemented live on the filesystem.  Under this format, a
directory of documents would be a directory of directories.  Each document
directory would/should work exactly like the packaged Jarfile format (i.e.,
if you send the entire directory to someone else, they can open your
document.)  By no means should the Jar format be deprecated!  But this live
filesystem alternative should be officially described by the standard (and
probably given a name).

In short, ODF is a file format specification.  Change tracking and
collaborative editing is not something that any file format specification
can really do well.  Expose the component files, leverage the fact that
your document content is plain text, and any versioning system (many of
which have a decade or more of hard use under their belt) can start
tracking changes.  Far from hamstringing office applications, they could
concentrate on supporting mature, capable, popular versioning systems,
graphically displaying "diffs", and managing "working directories".  A
clever app could even hide the fact that the "Save" button also performs a
"commit" if a network interface is active.  The only support required from
the file format is the definition of the "live filesystem document
package."

W.r.t. encrypting document fragments: It is really the responsibility of
the server, the filesystem, and the operators thereof to control access.
If you have access to the file, you should be able to read whatever's in
the file.  If it contains something you shouldn't see, you shouldn't have
access to it.  (Or the entire file can be encrypted and unrecognizable to
the office app, to "unzip", and to "jar -x".)  If partial access needs to
be given, OpenDocument already includes support for "linked" content: the
master document can link to an assortment of files and you "automatically"
can only see those which the server lets you see.

Thx,
Bryce