Re: [office-collab] Immutable Change Tracking

[Patrick Durusau <patrick@durusau.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jos,

- From below:

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

The syntax used for the XQuery Update Facility is a good example of
the XPaths, subject to defaulting and other means to shorten the
recorded paths.

To insert a new paragraph:

insert node <text:p>a new paragraph</text:p>
after doc("content.xml")//text:p[1]

Unlike the XQuery Update Facility, I'm not proposing that the original
document ever change.

Which means another user, Svante for example, could say:

insert node <text:p>a new paragraph</text:p>
after doc("content.xml")//text:p[1]

And when changes are to be accepted, the author would have to choose
which new paragraph, perhaps both, that they wish to accept.

Noting that "acceptance" doesn't change the document either.
Acceptance results in yet another XPath statement, this one addressing
the change log, indicating which changes are to be displayed/printed
as "the" document.

Insertion, at least in XQuery, is always after the node that is
addressed in the XPath expression.

BTW, after receiving the proposed changes, either Svante or I could
address those changes, again by XPath statements, enabling us to edit
edits, while tracking those changes.

We will need a wrapper element to go around the XPath statements to
give them positions in the change.xml file.

The graphic display or printing of the document is a projection of the
original document plus the changes. If you want to conceal all those
changes, save to a new document, which has a new starting state.

One thing I find very interesting is that this sort of solution has
long been available for very high-end applications and it seems
possible that it could become available to individuals, small firms
and governments.

Hope you are at the start of a great day!

Patrick

PS: Given the complexity of some of the hierarchy in ODF XML, we may
want to define defaults that eliminate most if not all of the default
paths.



On 01/12/2016 05:31 PM, Jos van den Oever wrote:
> 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
> 
> 
> 
> 
> ---------------------------------------------------------------------
>
> 
To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS
> at: 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> 

- -- 
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJWlanKAAoJEFPGsgi3Mgyc6IMQAKxfLgTeF2G95bn0Rc/FMJ1k
PICRjxwkMIQRUyjy0h9TltC9s2RUpq2Cc57x18v+BaZoDb9LqgVylO3OZVokCbcI
Ay+i9Zyhi1KnMNmFT0NStRwTa5esQUD6sbTLDYee1I+WGpiU7ek8gaWFs/Q//9XI
ZqVuDnoQlFTzwYVL7IMxLx2mXgJIQtoNfVh3jcGLVNlXomCXtYZ4AycjAOHyBg8I
xYuAaNL2mMlFvbzJsBmKV0axJ+IYeKuEtvYi+ATwWUzQyFjAKsUVH8gmQWoXwUt6
If4dYvh6gBRhOCu+OE2uvDLh0sGrubLkB81DgtkUCHUu0tMpF9IrSLzW4eTxQ3HE
6NQt1A5i4PUX7fIfdAGDPWk+IvcAb+LRDiACwusIhPtbvtO6BesO7/8b0JIccWCw
CQSxFQZFEdU0Um7MKOVeZUqag09RX6+f+KbMankYvc6hiGN2HlUeqAjE63ogRodg
PW7/+B2RraD+ldok7zDla2bFx09OzsLprd5atyJ1jg1Y+JrxlyQbZrLjUoKVOdzN
I93J8v8S9fPzBsptPqZP9VtRT6AxsReFJkJCTLqCSq5dxTww7Twc45UxUKoaRFRM
G6hhk7X5Pr9yFavxAIaLNGAcuqBzyHJt38sRcuUwd4yFkWFuhe2tdOXXvXNO2NqX
7GVtP6ZSIg++qFPT/wIQ
=y43b
-----END PGP SIGNATURE-----