Re: [office-comment] Change Tracking issue

[Patrick Durusau <patrick@durusau.net>]

Bryce,

Just a quick question about a very interesting proposal:

I think change tracking is important when specifying a document format. 
True, change tracking may be implemented by a variety of means but 
having a common format that links those changes (however managed at the 
application level) to a document seems to me to be essential to a 
document format.

And for most office applications, I suspect that "in document" models 
for change tracking probably hit the sweet spot for the average user.

Having said that, I don't think that one size necessarily fits all and 
for enterprise authoring environments, I would like to see discussion of 
alternative proposals for management of change tracking. It could well 
be that the ODF format should have "in document" default change tracking 
and allow a declaration of another location/application for tracking of 
changes but using an ODF defined format.

Hope you are having a great day!

Patrick

Bryce L Nordgren wrote:
> 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
>
>
> This publicly archived list offers a means to provide input to the
> OASIS Open Document Format for Office Applications (OpenDocument) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: office-comment-subscribe@lists.oasis-open.org
> Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
> List help: office-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/office-comment/
> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
>
>
>
>   

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)