Re: [office-collab] Immutable Change Tracking

[Jos van den Oever <jos@vandenoever.info>]

On Friday 08 January 2016 15:58:49 Patrick Durusau wrote:
> Greetings!
> 
> I have been following discussions of immutable data structures, mostly
> in Clojure for several years and it recently occurred to me that if
> the starting state of an ODF document were immutable and changes are
> expressed against that immutable state, then many of the problems and
> issues that have bedeviled the change tracking TC simply disappear.
> 
> First, since we have an immutable starting state, then changes
> expressed against that state, for example in XPath (there are ways to
> default large parts of path statements), represent changes that can be
> accepted or rejected when producing either a visual, print and/or new
> version of the document.
> 
> A "new" version of the document has a new starting state for change
> tracking and therefore does not reflect the change history of the
> previous version of the document.
> 
> A visual or print version of the document would have, expressed as an
> XPath as well, list of changes that were accepted for that particular
> visual or print version. Which would mean you could create another
> visual or print version with different changes reflected. Which would
> be a separate XPath statement. Enabling you to go back through
> versions and/or any changes.
> 
> Second, an immutable starting state and expressions of changes as
> XPath statements means we can detect when there are conflicting
> changes, without those changes ever stepping on other changes.
> 
> For example, assume that we have three paragraphs in the starting
> state of the document and I delete text:paragraph #2. Since that is
> recorded as an XPath statement and the original state of the document
> does not change, you can record changes to text:paragraph #2 without
> fear of your changes being lost. And you can continue to edit the rest
> of the paragraphs in the document because to you they have (and do
> have) the original paragraph numbering.
> 
> Moreover, if you want to express changes on changes, which are
> themselves stored in an XML document structure, unlike present
> applications you can make changes to changes, which while immutable,
> can have changes specified that point into those changes.
> 
> Third, and this reaches into the future collaboration sphere of
> activity, having immutable documents and changes expressed as XPaths,
> will enable the detection of when branches occur that impact the
> visual, print or new version, enabling the author to make choices
> about which branch in the document to accept for that particular version
> .
> 
> Moreover, immutable change tracking will enable classic collaboration
> around a server but also enable collaboration with specified others or
> within specified groups, such as an authoring group in a highly secure
> environment.
> 
> Permissions could also determine what changes could be seen by
> particular users and where they could suggest changes.
> 
> I realize this is in stark contrast to the minimal document by default
> architecture of present change tracking in ODF. That was a good design
> decision some twenty years ago, facing unreliable networks and a stand
> alone orientation to document authoring.
> 
> But twenty years ago isn't where we are in 2016. There are
> "collaborative" environments already, although I'm not impressed with
> their capabilities when compared to applications based on ODF.
> 
> What I am proposing isn't that different from Svante's original
> proposal except that I propose to solve the problem of coordination
> between systems by making documents and the changes to be applied to
> them immutable. Ultimately, serious conflicts must be solved by an
> author's choice and what I have proposed here will give every author
> exactly that choice.
> 
> On the up side, having immutable change tracking the enables
> applications to have traditional collaboration hubs (think of servers
> with big targets painted on them), to have collaboration between
> individual clients at no extra effort, save for receiving the changes,
> and to have group change tracking for highly secure environments.
> 
> Oh, I know Svante hasn't pushed this very hard but having immutable
> change tracking will also enable a variety of platforms to all work on
> the same ODF document. I may be editing in a desktop application while
> Svante is editing on a smartphone, which doesn't support styles or svg
> graphics. All that means is that Svante won't be submitting changes
> for what his platform doesn't support. He can submit changes for text
> without any difficulty.
> 
> Lest that get lost in all my verbage, the "text" is what we say it is
> when we "accept" changes for the production of a visual, print or new
> edition. Others may choose differently, as may we at some later point
> in time. To capture a particular version, create a new edition with no
> change history. Then it becomes a frozen artifact in time.
> 
> I suspect this will be of interest to a number of security conscious
> entities, just for the varieties of collaboration alone. Add in the
> other capabilities and I think it could be the next jump in
> collaborative word processing.

Could you elaborate on what the XPath would look like? I do not quite follow 
that part of the proposal.

If I understand correctly, the document and the changes stay separate and each 
change has an identifier for the document to which it applies.

Cheers,
Jos