-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 29/11/14 um 05:48 schrieb jonathon: > On 27/11/14 23:30, Svante Schubert wrote: > >> Basically the paper states: To improve document revision systems we >> should stop use file comparison for change detection. Instead the >> changes should be kept during editing and exchanged. Even being standardize. > > This looks like a supplement to Git-Hub, rather than a replacement. The idea is to see a document as a sequence of changes. The exchange of changes is only required to merge easily and therefore to use documents easily in distributed revision control, such as using GIT with the front-end of GitHub, but other scenarios are thinkable. > > That said, I see a couple of potential issues with a "document change > markup protocol": > > * Bloated size. > Taking a real world example. I have a document that currently is 80 MB > in size. As recently as four days ago, it was 140 MB in size, whilst > three months ago, it was 60 MB in size. Were all of the document > changes to be included, today's document would be at least 150 MB in size. Efficient size handling is possible although additional information (history) might be stored. For instance, information can be compressed like the addition and deletion of the same content does not change the final document and can be removed (if changed during the creation of revision). In addition the user might only want to receive the latest state and not the whole history being submitted and history function is an optional feature similar to change-tracking. History might be on a centralized server (your NAS backup server at home) and not necessary in your document you like to view on your mobile. > > > * Scrubbing: > The only way to ensure that document scrubbers strip all of the changes, > is if there are either prefixes, or suffixes that are reserved > exclusively for "document change markup protocol" words, styles, and > other things that end up being used for tracking the document changes. > Of necessity, these functions will have to be exclusive. Perhaps we misunderstand us here, but the history is not within the content/styles XML. Although it still might be in the same ZIP. In our current design it is a folder named "changes" at document root level. > > > * Comprehensiveness: > At the risk of being pedantic, at what point does an edit go into the > "document change markup protocol": > # If I type "tyep" rather than "type", and immediately correct the > error, does that become a part of the "permanent record"? > Perhaps one needs to provide justification for: > ## Why the altered content becomes part of the "permanent record"; > ## Why the altered content does not become part of the "permanent record"; > > FWIW, the "tyep"/"type" example is from using tools that save glyphs as > soon as they are the individual keys are pressed. (IOW, the glyphs are > saved in "real time".) > > The current state of predictive word selection is such, that it is not > uncommon for software to automatically insert the predicted word, rather > than the desired word, with the user having to either leave the wrong > word in, or completely rewrite the sentence, to retain the same meaning, > but with different vocabulary, or terminate the message just before the > word, send that message, then send the problem word, then send the > message until the next non-predicted, and unfixable word." I am not certain if I understand you correct here - English is not my mother language, I give it a try: It is implementation dependent how the changes are being created by the application (predictive word selection, arbitrary user input, auto correction). During real-time collaboration the changes might want to be instantly dispatched to the other coworkers. Just like opening Google Docs in several browser windows and see the changes being transmitted instantly. If you enable change control in Google Docs you might notice that not everything is being saved, but only the changes from the start and the end of your session. Information was compressed. Similar to a "save" button the user might want to add some mile stones (commit or even a new branch - the details of theses techniques should be obfuscated from the end user), like a reviewed version or a state before he tested something exotic and might want to roll-back later.
Thanks for your challenging comment, Jonathon > > > ### > > I am assuming that tools will exist that will completely scrub all > "document changes", and markup relating to them, and that other tools > will be able to compare "document changes" between different documents > with the same basic content. You might want to play around with the mapping by using the implementation I have worked the past two years for Open-Xchange (OX). git clone --branch release-7.6.2 https://git.open-xchange.com/git/office and open in Netbeans (or your IDE of choice) the Maven project located at office/com.openexchange.office.odf/odfdom PS: Still working to convince OX to recontribute the sources back to this project. ;) Best regards, Svante > > jonathon > > > > * English - detected > * English > > * English > > <javascript:void(0);> > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUfC2MAAoJENkVprAHZ0k7Vv0IAMCIDHQKfVUPkBXj8kKjzQl6 TtWCpG6H1q6gEQkL4/iGvGrUu7WpuQ10xrkkWh84uskLm0XprdvD6g6u4UQ2iC9Y wkJtzlCmoqsi22Mz11JXf3fZ2Fdwx06CLXrZexwARO6ubBzSLgleaQ3TwNHlvpnh SXnm+rar1WS+BPeXY0ZC7NP62pAxP3L+tGonAA0O1p2c42oWZjhSYtZK07Yvf637 fWbu+v07Rt0vIZDFNzo5i7CEJz+9HK2D1iZdgCaqEhF8NUdI1VP4R50RRwIg1vrm w+0WLqXW0f2hIE3lKs904oD5V0PE6XvDkGRSsTDhm4KTeiuhN7Ye5oaaL3hL6DE= =zpwR -----END PGP SIGNATURE-----
