OpenDocument - Adv Document Collab SC

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Hope everyone is at the start of a great weekend! Patrick - -- 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 iQIcBAEBAgAGBQJWkCMJAAoJEFPGsgi3MgycXaUQANCSZZxva/nL6igv6J8vxzY1 Sb3+3WU+fLToiZ7b0qZn+Lq2VkzjZl/kMZ7gKII8TQ6qgSKaUIPdH/2gF2w897Fe fKsluI0n/smqpKwck7M3MrFGBvp+N1eqbgqdpJHOjdOCwKn9Pa5rZ5A3PARxbs8J S9h5/teLQu4TxVIGwwyOpS5W99DrnN6H3CiVM+b1tftplg/d9zih/jslW9wtmHGK ypTCcsNpefLTir9vwgZGBbVoh5VlKBrswrZuLl/Nzv+NlOlCx1pnKqhIcz0L7M0F 4TYpJor90S0oepQLQwzeJ7ZcnLkCvN1CY95RIozLl4h+9PI2twmf+q2N0vE3pgi2 3GoIlMGYlS4eR2SCUQC00gZSD3K1/M58+57/ykfvg3vd85ybTxIREl5R1m/B/euk 8yjLL/doHTYWk6SdZ2PqexDmqf+10jiZ2fBkE0bAIp1MjznAmHxbEyNdXPjYYcHj rh4jB3fR9abE2VXwOtO8ji5p14cVQJX1XUMs9N46FjmKwB0LAEdjdHto/bfPOM2l +qv97x3UNFiGTUy14R4rYrlRXQNUQFgYFT7S6FXIkMPH202vkPjSzRlFNQ0kGKeR YasJslsS2fYuwnO25BgbOms0ewiJJZ8s6VDKsV1r8MHzg0Ah6h5SCWX0za8Xuke4 jNKwwl9FS3zuN3Z73NN4 =R4zb -----END PGP SIGNATURE-----

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

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

The immutable change-tracking is indeed very useful for the scenario of commenting and editing a signed document. In this scenario the XML can not be changed, as otherwise the sign would be broken. Every comment/edit would be saved aside the signed content XML and might be signed again for each author, ensuring the validity of the complete content. That the changes will in the future refer to the position of change into the content instead of embedding it as prior we agree on. XPath is just a possible choice of implementation for referencing. From my observation Patrick's ideas are not based on XPath, he just took it as example. I rather would avoid XPath as ODF application do not require to have an XML model representation at run time, in contrary to the file model related DOM run-time API of browsers. In addition ODF XML has no normalized representation, which make XML references more difficult. Therefore the abstraction from XML to logical identities, which are known to users and referencing to those will be easier to handle by general run-time model related to ODF and works well for applications without ODF XML awareness even at run-time. I have experienced this in my work on a browser based office with Open-XChange in the past years. For example, the reference of the 3rd character within the 2nd paragraph might be written as /2/3 which can be seen as a simplification of XPath and was handled by the browser office I have been working with as simple integer array, making things easy for the office at run-time. Kind regards, Svante On Jan 8, 2016 9:58 PM, "Patrick Durusau" < patrick@durusau.net > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Hope everyone is at the start of a great weekend! Patrick - -- 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 iQIcBAEBAgAGBQJWkCMJAAoJEFPGsgi3MgycXaUQANCSZZxva/nL6igv6J8vxzY1 Sb3+3WU+fLToiZ7b0qZn+Lq2VkzjZl/kMZ7gKII8TQ6qgSKaUIPdH/2gF2w897Fe fKsluI0n/smqpKwck7M3MrFGBvp+N1eqbgqdpJHOjdOCwKn9Pa5rZ5A3PARxbs8J S9h5/teLQu4TxVIGwwyOpS5W99DrnN6H3CiVM+b1tftplg/d9zih/jslW9wtmHGK ypTCcsNpefLTir9vwgZGBbVoh5VlKBrswrZuLl/Nzv+NlOlCx1pnKqhIcz0L7M0F 4TYpJor90S0oepQLQwzeJ7ZcnLkCvN1CY95RIozLl4h+9PI2twmf+q2N0vE3pgi2 3GoIlMGYlS4eR2SCUQC00gZSD3K1/M58+57/ykfvg3vd85ybTxIREl5R1m/B/euk 8yjLL/doHTYWk6SdZ2PqexDmqf+10jiZ2fBkE0bAIp1MjznAmHxbEyNdXPjYYcHj rh4jB3fR9abE2VXwOtO8ji5p14cVQJX1XUMs9N46FjmKwB0LAEdjdHto/bfPOM2l +qv97x3UNFiGTUy14R4rYrlRXQNUQFgYFT7S6FXIkMPH202vkPjSzRlFNQ0kGKeR YasJslsS2fYuwnO25BgbOms0ewiJJZ8s6VDKsV1r8MHzg0Ah6h5SCWX0za8Xuke4 jNKwwl9FS3zuN3Z73NN4 =R4zb -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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

Hi - long time no write   What Svante just said has my 100% backing   But I just realized that say 3 rd character might not be good enough - because what about control characters – I’d say we shouldn’t count those in general, but our spec should probably specify that fact, and maybe even specify if say an inline image is counted as a character (I think it should be), but what about a pagenumber ref (one character or as many as the number takes up when printed – again I’d say one which makes the most sense) – I think we will agree an most if not all of the cases, but for a spec to be foolproof we better specify each and every possible case specifically)   As to never ever change the original (not even on apply) – I am not so sure – we would deprecate the odf spec in that case, as all documents should then better start at an empty document with only changes recorded - on the other hand if we allow changes to be burned into xml then merging documents becomes a bit more problematic.   Best regards Camilla   From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Svante Schubert Sent: 13. januar 2016 12:56 To: Patrick Durusau <patrick@durusau.net> Cc: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Immutable Change Tracking   The immutable change-tracking is indeed very useful for the scenario of commenting and editing a signed document. In this scenario the XML can not be changed, as otherwise the sign would be broken. Every comment/edit would be saved aside the signed content XML and might be signed again for each author, ensuring the validity of the complete content. That the changes will in the future refer to the position of change into the content instead of embedding it as prior we agree on. XPath is just a possible choice of implementation for referencing. From my observation Patrick's ideas are not based on XPath, he just took it as example. I rather would avoid XPath as ODF application do not require to have an XML model representation at run time, in contrary to the file model related DOM run-time API of browsers. In addition ODF XML has no normalized representation, which make XML references more difficult. Therefore the abstraction from XML to logical identities, which are known to users and referencing to those will be easier to handle by general run-time model related to ODF and works well for applications without ODF XML awareness even at run-time. I have experienced this in my work on a browser based office with Open-XChange in the past years. For example, the reference of the 3rd character within the 2nd paragraph might be written as /2/3 which can be seen as a simplification of XPath and was handled by the browser office I have been working with as simple integer array, making things easy for the office at run-time. Kind regards, Svante On Jan 8, 2016 9:58 PM, "Patrick Durusau" < patrick@durusau.net > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Hope everyone is at the start of a great weekend! Patrick - -- 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 iQIcBAEBAgAGBQJWkCMJAAoJEFPGsgi3MgycXaUQANCSZZxva/nL6igv6J8vxzY1 Sb3+3WU+fLToiZ7b0qZn+Lq2VkzjZl/kMZ7gKII8TQ6qgSKaUIPdH/2gF2w897Fe fKsluI0n/smqpKwck7M3MrFGBvp+N1eqbgqdpJHOjdOCwKn9Pa5rZ5A3PARxbs8J S9h5/teLQu4TxVIGwwyOpS5W99DrnN6H3CiVM+b1tftplg/d9zih/jslW9wtmHGK ypTCcsNpefLTir9vwgZGBbVoh5VlKBrswrZuLl/Nzv+NlOlCx1pnKqhIcz0L7M0F 4TYpJor90S0oepQLQwzeJ7ZcnLkCvN1CY95RIozLl4h+9PI2twmf+q2N0vE3pgi2 3GoIlMGYlS4eR2SCUQC00gZSD3K1/M58+57/ykfvg3vd85ybTxIREl5R1m/B/euk 8yjLL/doHTYWk6SdZ2PqexDmqf+10jiZ2fBkE0bAIp1MjznAmHxbEyNdXPjYYcHj rh4jB3fR9abE2VXwOtO8ji5p14cVQJX1XUMs9N46FjmKwB0LAEdjdHto/bfPOM2l +qv97x3UNFiGTUy14R4rYrlRXQNUQFgYFT7S6FXIkMPH202vkPjSzRlFNQ0kGKeR YasJslsS2fYuwnO25BgbOms0ewiJJZ8s6VDKsV1r8MHzg0Ah6h5SCWX0za8Xuke4 jNKwwl9FS3zuN3Z73NN4 =R4zb -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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

On Jan 13, 2016 1:18 PM, "Camilla Boemann" < cbo@boemann.dk > wrote: > > Hi - long time no write > >   Nice to have you back! > > What Svante just said has my 100% backing > >   Always good to read this! ;) > > But I just realized that say 3rd character might not be good enough - because what about control characters – I’d say we shouldn’t count those in general, but our spec should probably specify that fact, The counting of characters is abstracted from the XML, for instance ODF whitespace handling is applied. Counting of characters is rather equivalent to cursor traveling as our need is to open up a span to select the characters we like to modify unambiguously. and maybe even specify if say an inline image is counted as a character (I think it should be), but what about a pagenumber ref (one character or as many as the number takes up when printed – again I’d say one which makes the most sense) – I think we will agree an most if not all of the cases, but for a spec to be foolproof we better specify each and every possible case specifically) > >   > > As to never ever change the original (not even on apply) – I am not so sure – we would deprecate the odf spec in that case, as all documents should then better start at an empty document with only changes recorded - on the other hand if we allow changes to be burned into xml then merging documents becomes a bit more problematic. > >   > > Best regards > > Camilla > >   > > From: office-collab@lists.oasis-open.org [mailto: office-collab@lists.oasis-open.org ] On Behalf Of Svante Schubert > Sent: 13. januar 2016 12:56 > To: Patrick Durusau < patrick@durusau.net > > Cc: office-collab@lists.oasis-open.org > Subject: Re: [office-collab] Immutable Change Tracking > >   > > The immutable change-tracking is indeed very useful for the scenario of commenting and editing a signed document. In this scenario the XML can not be changed, as otherwise the sign would be broken. > Every comment/edit would be saved aside the signed content XML and might be signed again for each author, ensuring the validity of the complete content. > > That the changes will in the future refer to the position of change into the content instead of embedding it as prior we agree on. XPath is just a possible choice of implementation for referencing. From my observation Patrick's ideas are not based on XPath, he just took it as example. I rather would avoid XPath as ODF application do not require to have an XML model representation at run time, in contrary to the file model related DOM run-time API of browsers. > In addition ODF XML has no normalized representation, which make XML references more difficult. > Therefore the abstraction from XML to logical identities, which are known to users and referencing to those will be easier to handle by general run-time model related to ODF and works well for applications without ODF XML awareness even at run-time. > > I have experienced this in my work on a browser based office with Open-XChange in the past years. > For example, the reference of the 3rd character within the 2nd paragraph might be written as /2/3 which can be seen as a simplification of XPath and was handled by the browser office I have been working with as simple integer array, making things easy for the office at run-time. > > Kind regards, > Svante > > On Jan 8, 2016 9:58 PM, "Patrick Durusau" < patrick@durusau.net > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> 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. >> >> Hope everyone is at the start of a great weekend! >> >> Patrick >> >> - -- >> 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 >> >> iQIcBAEBAgAGBQJWkCMJAAoJEFPGsgi3MgycXaUQANCSZZxva/nL6igv6J8vxzY1 >> Sb3+3WU+fLToiZ7b0qZn+Lq2VkzjZl/kMZ7gKII8TQ6qgSKaUIPdH/2gF2w897Fe >> fKsluI0n/smqpKwck7M3MrFGBvp+N1eqbgqdpJHOjdOCwKn9Pa5rZ5A3PARxbs8J >> S9h5/teLQu4TxVIGwwyOpS5W99DrnN6H3CiVM+b1tftplg/d9zih/jslW9wtmHGK >> ypTCcsNpefLTir9vwgZGBbVoh5VlKBrswrZuLl/Nzv+NlOlCx1pnKqhIcz0L7M0F >> 4TYpJor90S0oepQLQwzeJ7ZcnLkCvN1CY95RIozLl4h+9PI2twmf+q2N0vE3pgi2 >> 3GoIlMGYlS4eR2SCUQC00gZSD3K1/M58+57/ykfvg3vd85ybTxIREl5R1m/B/euk >> 8yjLL/doHTYWk6SdZ2PqexDmqf+10jiZ2fBkE0bAIp1MjznAmHxbEyNdXPjYYcHj >> rh4jB3fR9abE2VXwOtO8ji5p14cVQJX1XUMs9N46FjmKwB0LAEdjdHto/bfPOM2l >> +qv97x3UNFiGTUy14R4rYrlRXQNUQFgYFT7S6FXIkMPH202vkPjSzRlFNQ0kGKeR >> YasJslsS2fYuwnO25BgbOms0ewiJJZ8s6VDKsV1r8MHzg0Ah6h5SCWX0za8Xuke4 >> jNKwwl9FS3zuN3Z73NN4 >> =R4zb >> -----END PGP SIGNATURE----- >> >> --------------------------------------------------------------------- >> 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

Sorry, my phone sent the mail before I was finished, I will add the latter part now: On Thu, Jan 14, 2016 at 8:43 AM, Svante Schubert < svante.schubert@gmail.com > wrote: On Jan 13, 2016 1:18 PM, "Camilla Boemann" < cbo@boemann.dk > wrote: > > Hi - long time no write > >   Nice to have you back! > > What Svante just said has my 100% backing > >   Always good to read this! ;) > > But I just realized that say 3rd character might not be good enough - because what about control characters – I’d say we shouldn’t count those in general, but our spec should probably specify that fact, The counting of characters is abstracted from the XML, for instance ODF whitespace handling is applied. Counting of characters is rather equivalent to cursor traveling as our need is to open up a span to select the characters we like to modify unambiguously. and maybe even specify if say an inline image is counted as a character (I think it should be), It is indeed counted equivalent as an character. Nevertheless even an image floating somewhere, was by Open-XChange referenced by its position in the XML.   but what about a pagenumber ref (one character or as many as the number takes up when printed – again I’d say one which makes the most sense) – I think we will agree an most if not all of the cases, but for a spec to be foolproof we better specify each and every possible case specifically) > There was a lot of discussion if a field is just metadata on the text or a construct for 3rd party content. In the end it ease the handling for the developer, if it is seen as an own component, which contains other components (such as text). >   > > As to never ever change the original (not even on apply) – I am not so sure – we would deprecate the odf spec in that case, as all documents should then better start at an empty document with only changes recorded - on the other hand if we allow changes to be burned into xml then merging documents becomes a bit more problematic. > Only because the content is immutable, does not mean that changes can not be merged in the document view. Like showing the comments on the immutable contract similar to an additional layer. Even all steps of document history can be shown without changing the serialized document model. The immutable change tracking is for all scenarios possible, but I wonder if applications would go so far to do so.. But if there is demand, there is a market.. Best, Svante >   > > Best regards > > Camilla > >   > > From: office-collab@lists.oasis-open.org [mailto: office-collab@lists.oasis-open.org ] On Behalf Of Svante Schubert > Sent: 13. januar 2016 12:56 > To: Patrick Durusau < patrick@durusau.net > > Cc: office-collab@lists.oasis-open.org > Subject: Re: [office-collab] Immutable Change Tracking > >   > > The immutable change-tracking is indeed very useful for the scenario of commenting and editing a signed document. In this scenario the XML can not be changed, as otherwise the sign would be broken. > Every comment/edit would be saved aside the signed content XML and might be signed again for each author, ensuring the validity of the complete content. > > That the changes will in the future refer to the position of change into the content instead of embedding it as prior we agree on. XPath is just a possible choice of implementation for referencing. From my observation Patrick's ideas are not based on XPath, he just took it as example. I rather would avoid XPath as ODF application do not require to have an XML model representation at run time, in contrary to the file model related DOM run-time API of browsers. > In addition ODF XML has no normalized representation, which make XML references more difficult. > Therefore the abstraction from XML to logical identities, which are known to users and referencing to those will be easier to handle by general run-time model related to ODF and works well for applications without ODF XML awareness even at run-time. > > I have experienced this in my work on a browser based office with Open-XChange in the past years. > For example, the reference of the 3rd character within the 2nd paragraph might be written as /2/3 which can be seen as a simplification of XPath and was handled by the browser office I have been working with as simple integer array, making things easy for the office at run-time. > > Kind regards, > Svante > > On Jan 8, 2016 9:58 PM, "Patrick Durusau" < patrick@durusau.net > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> 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. >> >> Hope everyone is at the start of a great weekend! >> >> Patrick >> >> - -- >> 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 >> >> iQIcBAEBAgAGBQJWkCMJAAoJEFPGsgi3MgycXaUQANCSZZxva/nL6igv6J8vxzY1 >> Sb3+3WU+fLToiZ7b0qZn+Lq2VkzjZl/kMZ7gKII8TQ6qgSKaUIPdH/2gF2w897Fe >> fKsluI0n/smqpKwck7M3MrFGBvp+N1eqbgqdpJHOjdOCwKn9Pa5rZ5A3PARxbs8J >> S9h5/teLQu4TxVIGwwyOpS5W99DrnN6H3CiVM+b1tftplg/d9zih/jslW9wtmHGK >> ypTCcsNpefLTir9vwgZGBbVoh5VlKBrswrZuLl/Nzv+NlOlCx1pnKqhIcz0L7M0F >> 4TYpJor90S0oepQLQwzeJ7ZcnLkCvN1CY95RIozLl4h+9PI2twmf+q2N0vE3pgi2 >> 3GoIlMGYlS4eR2SCUQC00gZSD3K1/M58+57/ykfvg3vd85ybTxIREl5R1m/B/euk >> 8yjLL/doHTYWk6SdZ2PqexDmqf+10jiZ2fBkE0bAIp1MjznAmHxbEyNdXPjYYcHj >> rh4jB3fR9abE2VXwOtO8ji5p14cVQJX1XUMs9N46FjmKwB0LAEdjdHto/bfPOM2l >> +qv97x3UNFiGTUy14R4rYrlRXQNUQFgYFT7S6FXIkMPH202vkPjSzRlFNQ0kGKeR >> YasJslsS2fYuwnO25BgbOms0ewiJJZ8s6VDKsV1r8MHzg0Ah6h5SCWX0za8Xuke4 >> jNKwwl9FS3zuN3Z73NN4 >> =R4zb >> -----END PGP SIGNATURE----- >> >> --------------------------------------------------------------------- >> 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

Well for floating images I’d say there is a difference between it being  anchored AT a position of being counted as a character. I say this because in Calligra such anchors were until recently implemented as a non printing character, with the downside of having to press cursor key twice to get past it.   From: Svante Schubert [mailto:svante.schubert@gmail.com] Sent: 15. januar 2016 18:45 To: C. Boemann <cbo@boemann.dk> Cc: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Immutable Change Tracking   Sorry, my phone sent the mail before I was finished, I will add the latter part now:   On Thu, Jan 14, 2016 at 8:43 AM, Svante Schubert < svante.schubert@gmail.com > wrote: On Jan 13, 2016 1:18 PM, "Camilla Boemann" < cbo@boemann.dk > wrote: > > Hi - long time no write > >   Nice to have you back! > > What Svante just said has my 100% backing > >   Always good to read this! ;) > > But I just realized that say 3rd character might not be good enough - because what about control characters – I’d say we shouldn’t count those in general, but our spec should probably specify that fact, The counting of characters is abstracted from the XML, for instance ODF whitespace handling is applied. Counting of characters is rather equivalent to cursor traveling as our need is to open up a span to select the characters we like to modify unambiguously. and maybe even specify if say an inline image is counted as a character (I think it should be),   It is indeed counted equivalent as an character. Nevertheless even an image floating somewhere, was by Open-XChange referenced by its position in the XML.   but what about a pagenumber ref (one character or as many as the number takes up when printed – again I’d say one which makes the most sense) – I think we will agree an most if not all of the cases, but for a spec to be foolproof we better specify each and every possible case specifically) > There was a lot of discussion if a field is just metadata on the text or a construct for 3rd party content. In the end it ease the handling for the developer, if it is seen as an own component, which contains other components (such as text). >   > > As to never ever change the original (not even on apply) – I am not so sure – we would deprecate the odf spec in that case, as all documents should then better start at an empty document with only changes recorded - on the other hand if we allow changes to be burned into xml then merging documents becomes a bit more problematic. > Only because the content is immutable, does not mean that changes can not be merged in the document view. Like showing the comments on the immutable contract similar to an additional layer. Even all steps of document history can be shown without changing the serialized document model.   The immutable change tracking is for all scenarios possible, but I wonder if applications would go so far to do so.. But if there is demand, there is a market..   Best, Svante >   > > Best regards > > Camilla > >   > > From: office-collab@lists.oasis-open.org [mailto: office-collab@lists.oasis-open.org ] On Behalf Of Svante Schubert > Sent: 13. januar 2016 12:56 > To: Patrick Durusau < patrick@durusau.net > > Cc: office-collab@lists.oasis-open.org > Subject: Re: [office-collab] Immutable Change Tracking > >   > > The immutable change-tracking is indeed very useful for the scenario of commenting and editing a signed document. In this scenario the XML can not be changed, as otherwise the sign would be broken. > Every comment/edit would be saved aside the signed content XML and might be signed again for each author, ensuring the validity of the complete content. > > That the changes will in the future refer to the position of change into the content instead of embedding it as prior we agree on. XPath is just a possible choice of implementation for referencing. From my observation Patrick's ideas are not based on XPath, he just took it as example. I rather would avoid XPath as ODF application do not require to have an XML model representation at run time, in contrary to the file model related DOM run-time API of browsers. > In addition ODF XML has no normalized representation, which make XML references more difficult. > Therefore the abstraction from XML to logical identities, which are known to users and referencing to those will be easier to handle by general run-time model related to ODF and works well for applications without ODF XML awareness even at run-time. > > I have experienced this in my work on a browser based office with Open-XChange in the past years. > For example, the reference of the 3rd character within the 2nd paragraph might be written as /2/3 which can be seen as a simplification of XPath and was handled by the browser office I have been working with as simple integer array, making things easy for the office at run-time. > > Kind regards, > Svante > > On Jan 8, 2016 9:58 PM, "Patrick Durusau" < patrick@durusau.net > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> 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. >> >> Hope everyone is at the start of a great weekend! >> >> Patrick >> >> - -- >> 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 >> >> iQIcBAEBAgAGBQJWkCMJAAoJEFPGsgi3MgycXaUQANCSZZxva/nL6igv6J8vxzY1 >> Sb3+3WU+fLToiZ7b0qZn+Lq2VkzjZl/kMZ7gKII8TQ6qgSKaUIPdH/2gF2w897Fe >> fKsluI0n/smqpKwck7M3MrFGBvp+N1eqbgqdpJHOjdOCwKn9Pa5rZ5A3PARxbs8J >> S9h5/teLQu4TxVIGwwyOpS5W99DrnN6H3CiVM+b1tftplg/d9zih/jslW9wtmHGK >> ypTCcsNpefLTir9vwgZGBbVoh5VlKBrswrZuLl/Nzv+NlOlCx1pnKqhIcz0L7M0F >> 4TYpJor90S0oepQLQwzeJ7ZcnLkCvN1CY95RIozLl4h+9PI2twmf+q2N0vE3pgi2 >> 3GoIlMGYlS4eR2SCUQC00gZSD3K1/M58+57/ykfvg3vd85ybTxIREl5R1m/B/euk >> 8yjLL/doHTYWk6SdZ2PqexDmqf+10jiZ2fBkE0bAIp1MjznAmHxbEyNdXPjYYcHj >> rh4jB3fR9abE2VXwOtO8ji5p14cVQJX1XUMs9N46FjmKwB0LAEdjdHto/bfPOM2l >> +qv97x3UNFiGTUy14R4rYrlRXQNUQFgYFT7S6FXIkMPH202vkPjSzRlFNQ0kGKeR >> YasJslsS2fYuwnO25BgbOms0ewiJJZ8s6VDKsV1r8MHzg0Ah6h5SCWX0za8Xuke4 >> jNKwwl9FS3zuN3Z73NN4 >> =R4zb >> -----END PGP SIGNATURE----- >> >> --------------------------------------------------------------------- >> 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  

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Svante, I'm sorry you are missing the call today because I think the XPath / no XML model at run time is an important issue to discuss. Perhaps we can get started today and over time iron it out. I say that because your right, no ODF application is required to have an XML model. ODF applications can have any internal model they care to have, but, they are required to *read* ODF XML and to *write* ODF XML from their purely internal representations. That is to say that the XML file format of ODF *is* the abstraction layer that enables many ODF applications to have varying internal models . So, my choice of XPath was very intentional because it too is an abstract representation of the change, against the abstraction that the ODF application has already read into its internal structure. The same process of reading the ODF document would be applied to reading the change into the internal representation of the ODF application. Likewise, when an ODF application serializes changes, however it stores them internally, it serializes them against the immutable XML ODF file which it read when it loaded the file. The abstraction of XPath to "logical identities" maybe how many ODF applications choose to go from the XPath representation to their internal model but that's an application's choice and I would prefer that we not dictate to applications their abstractions. Using XML for both the file format and changes allows ODF to remain above the choices made by ODF applications. Hope everyone is having a great day! Patrick On 01/13/2016 06:55 AM, Svante Schubert wrote: > The immutable change-tracking is indeed very useful for the > scenario of commenting and editing a signed document. In this > scenario the XML can not be changed, as otherwise the sign would be > broken. Every comment/edit would be saved aside the signed content > XML and might be signed again for each author, ensuring the > validity of the complete content. > > That the changes will in the future refer to the position of change > into the content instead of embedding it as prior we agree on. > XPath is just a possible choice of implementation for referencing. > From my observation Patrick's ideas are not based on XPath, he just > took it as example. I rather would avoid XPath as ODF application > do not require to have an XML model representation at run time, in > contrary to the file model related DOM run-time API of browsers. In > addition ODF XML has no normalized representation, which make XML > references more difficult. Therefore the abstraction from XML to > logical identities, which are known to users and referencing to > those will be easier to handle by general run-time model related to > ODF and works well for applications without ODF XML awareness even > at run-time. > > I have experienced this in my work on a browser based office with > Open-XChange in the past years. For example, the reference of the > 3rd character within the 2nd paragraph might be written as /2/3 > which can be seen as a simplification of XPath and was handled by > the browser office I have been working with as simple integer > array, making things easy for the office at run-time. > > Kind regards, Svante > > On Jan 8, 2016 9:58 PM, "Patrick Durusau" <patrick@durusau.net > < mailto:patrick@durusau.net >> 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. > > Hope everyone is at the start of a great weekend! > > Patrick > > > --------------------------------------------------------------------- > > 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 iQIcBAEBAgAGBQJWlmzmAAoJEFPGsgi3Mgyc8hwQAMUehF9iQ/HKW5Xzl62UsZD6 U2FFKpoc8lFaMKAC/l9I91Y6Q9j6o5383+aEkkWBXj+ff4K05KbEsxVsw+Kjd7v3 VLEmDFpeTiq8ZvPfc3Hr80ETxgNOt9zXxXAiBaTpuAfJqqoQiiau4iPKy62e52mf +mnbSvefg1sU52YxL+AI8Ahla3DN4FJKzC7ogTK9PXu2Je75Zz+eWoiYbw1mHe6H Ko3pujPy4RmCJSirnovi+ag2IktaI23lqJr7zQKX9HaU0psNxtWlO4vlcVKci3+a C/GqgBjmZ6hY60wtoZyIUmFvRsNwd/Tp06iZeV/MfjFq+g7lAXGfh/7IhKl+2fUN ITjTOVprdqMimyPRp94/9DmkEZHcD9ZDL/mnHkiQrBSWNO2JbXmq4CwNPk769NCd ci0rrVPvZHCgj88tq42e4dEwxpodw2u1kw3F7UiXcaXyIDuwdXVAhKnH1cfvtdLy f2DI9xPuggWldNlQfzggOfVktmwiZs7+FWnMrqA4WQLU/hjYWXF4YYyz91kbKU4x WtZOvfSkcn4ZIsxCAzWVarelwwbisDCBOOxN7wGztyn49AHcyBBjTsZ7G/HhQVQJ RTG90KAL2G+2uWznwrCjA8mqIsXigN0gpufT3bl+t73vjvR30nqvEYcsB2xR1AvR dNMvzvjzWSAjsUUSmMDC =0Whb -----END PGP SIGNATURE-----

Patrick, On Wed, Jan 13, 2016 at 4:27 PM, Patrick Durusau < patrick@durusau.net > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Svante, I'm sorry you are missing the call today because I think the XPath / no XML model at run time is an important issue to discuss. Perhaps we can get started today and over time iron it out. I say that because your right, no ODF application is required to have an XML model. ODF applications can have any internal model they care to have, but, they are required to *read* ODF XML and to *write* ODF XML from their purely internal representations. That is to say that the XML file format of ODF *is* the abstraction layer that enables many ODF applications to have varying internal models . ODF is indeed a very good abstraction to exchange serialized XML models. Still there is room for further simplification by doing some further  abstraction upon the ODF XML to logical objects (components). This has advantages, for instance: If I say, I will change the 2nd character of the 3rd paragraph, I might apply the change to ODF or OOXML, as they can be addressed similar for this subset. In the XPath view we are quite lost to see that we are talking of the same logical change and/or the same logical document but in a different XML representation. Not saying that we can map and abstract all ODF & OOXML on this level, but comparison gets easier and how did Einstein said, we should take the easiest solution that works, but nothing easier..   So, my choice of XPath was very intentional because it too is an abstract representation of the change, against the abstraction that the ODF application has already read into its internal structure. The same process of reading the ODF document would be applied to reading the change into the internal representation of the ODF application. XPath is very powerful, but it has many feature we do not need. Also does it depend on an XML that does not exist at run-time, but the positions have to exist and handled during run-time, as whenever something is inserted ahead (or above) the position is increased (or decreased when its being deleted), positions have to be updated. Much harder to evaluate and adopt these with XPath. XML and XPath are wonderful technologies, but these are not the hammers we are looking for...   Likewise, when an ODF application serializes changes, however it stores them internally, it serializes them against the immutable XML ODF file which it read when it loaded the file. The abstraction of XPath to "logical identities" maybe how many ODF applications choose to go from the XPath representation to their internal model but that's an application's choice and I would prefer that we not dictate to applications their abstractions. Using XML for both the file format and changes allows ODF to remain above the choices made by ODF applications. Again, I am curious if any ODF application develop would like to use XPath. At least nobody at Open-XChange was interested in it and was happy on doing an abstraction. Perhaps because they not only imported ODF, but as well OOXML, which is quite common for office applications and they wanted to use the same mechanism for both formats.  Because when the office XML is being abstracted to logical objects - I usually call components - the referencing is are very similar for both formats and a lot can be reused.  Try to map the position of a character within a paragraph of ODF to OOXML..  To me it was a nightmare..  Aside of my love to XPath, I do not see any use here...  I suggest we are not using this hammer, for this time, but wait for a nail instead.. Regards, Svante    Hope everyone is having a great day! Patrick On 01/13/2016 06:55 AM, Svante Schubert wrote: > The immutable change-tracking is indeed very useful for the > scenario of commenting and editing a signed document. In this > scenario the XML can not be changed, as otherwise the sign would be > broken. Every comment/edit would be saved aside the signed content > XML and might be signed again for each author, ensuring the > validity of the complete content. > > That the changes will in the future refer to the position of change > into the content instead of embedding it as prior we agree on. > XPath is just a possible choice of implementation for referencing. > From my observation Patrick's ideas are not based on XPath, he just > took it as example. I rather would avoid XPath as ODF application > do not require to have an XML model representation at run time, in > contrary to the file model related DOM run-time API of browsers. In > addition ODF XML has no normalized representation, which make XML > references more difficult. Therefore the abstraction from XML to > logical identities, which are known to users and referencing to > those will be easier to handle by general run-time model related to > ODF and works well for applications without ODF XML awareness even > at run-time. > > I have experienced this in my work on a browser based office with > Open-XChange in the past years. For example, the reference of the > 3rd character within the 2nd paragraph might be written as /2/3 > which can be seen as a simplification of XPath and was handled by > the browser office I have been working with as simple integer > array, making things easy for the office at run-time. > > Kind regards, Svante > > On Jan 8, 2016 9:58 PM, "Patrick Durusau" < patrick@durusau.net > <mailto: patrick@durusau.net >> 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. > > Hope everyone is at the start of a great weekend! > > Patrick > > > --------------------------------------------------------------------- > > 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 iQIcBAEBAgAGBQJWlmzmAAoJEFPGsgi3Mgyc8hwQAMUehF9iQ/HKW5Xzl62UsZD6 U2FFKpoc8lFaMKAC/l9I91Y6Q9j6o5383+aEkkWBXj+ff4K05KbEsxVsw+Kjd7v3 VLEmDFpeTiq8ZvPfc3Hr80ETxgNOt9zXxXAiBaTpuAfJqqoQiiau4iPKy62e52mf +mnbSvefg1sU52YxL+AI8Ahla3DN4FJKzC7ogTK9PXu2Je75Zz+eWoiYbw1mHe6H Ko3pujPy4RmCJSirnovi+ag2IktaI23lqJr7zQKX9HaU0psNxtWlO4vlcVKci3+a C/GqgBjmZ6hY60wtoZyIUmFvRsNwd/Tp06iZeV/MfjFq+g7lAXGfh/7IhKl+2fUN ITjTOVprdqMimyPRp94/9DmkEZHcD9ZDL/mnHkiQrBSWNO2JbXmq4CwNPk769NCd ci0rrVPvZHCgj88tq42e4dEwxpodw2u1kw3F7UiXcaXyIDuwdXVAhKnH1cfvtdLy f2DI9xPuggWldNlQfzggOfVktmwiZs7+FWnMrqA4WQLU/hjYWXF4YYyz91kbKU4x WtZOvfSkcn4ZIsxCAzWVarelwwbisDCBOOxN7wGztyn49AHcyBBjTsZ7G/HhQVQJ RTG90KAL2G+2uWznwrCjA8mqIsXigN0gpufT3bl+t73vjvR30nqvEYcsB2xR1AvR dNMvzvjzWSAjsUUSmMDC =0Whb -----END PGP SIGNATURE-----

Actually I can safely say that if we go with XPath Calligra will NOT implement changetracking   From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Svante Schubert Sent: 15. januar 2016 20:47 To: Patrick Durusau <patrick@durusau.net> Cc: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Immutable Change Tracking   Patrick,   On Wed, Jan 13, 2016 at 4:27 PM, Patrick Durusau < patrick@durusau.net > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Svante, I'm sorry you are missing the call today because I think the XPath / no XML model at run time is an important issue to discuss. Perhaps we can get started today and over time iron it out. I say that because your right, no ODF application is required to have an XML model. ODF applications can have any internal model they care to have, but, they are required to *read* ODF XML and to *write* ODF XML from their purely internal representations. That is to say that the XML file format of ODF *is* the abstraction layer that enables many ODF applications to have varying internal models . ODF is indeed a very good abstraction to exchange serialized XML models. Still there is room for further simplification by doing some further  abstraction upon the ODF XML to logical objects (components).   This has advantages, for instance: If I say, I will change the 2nd character of the 3rd paragraph, I might apply the change to ODF or OOXML, as they can be addressed similar for this subset. In the XPath view we are quite lost to see that we are talking of the same logical change and/or the same logical document but in a different XML representation.   Not saying that we can map and abstract all ODF & OOXML on this level, but comparison gets easier and how did Einstein said, we should take the easiest solution that works, but nothing easier..     So, my choice of XPath was very intentional because it too is an abstract representation of the change, against the abstraction that the ODF application has already read into its internal structure. The same process of reading the ODF document would be applied to reading the change into the internal representation of the ODF application. XPath is very powerful, but it has many feature we do not need. Also does it depend on an XML that does not exist at run-time, but the positions have to exist and handled during run-time, as whenever something is inserted ahead (or above) the position is increased (or decreased when its being deleted), positions have to be updated. Much harder to evaluate and adopt these with XPath. XML and XPath are wonderful technologies, but these are not the hammers we are looking for...     Likewise, when an ODF application serializes changes, however it stores them internally, it serializes them against the immutable XML ODF file which it read when it loaded the file. The abstraction of XPath to "logical identities" maybe how many ODF applications choose to go from the XPath representation to their internal model but that's an application's choice and I would prefer that we not dictate to applications their abstractions. Using XML for both the file format and changes allows ODF to remain above the choices made by ODF applications. Again, I am curious if any ODF application develop would like to use XPath. At least nobody at Open-XChange was interested in it and was happy on doing an abstraction. Perhaps because they not only imported ODF, but as well OOXML, which is quite common for office applications and they wanted to use the same mechanism for both formats.  Because when the office XML is being abstracted to logical objects - I usually call components - the referencing is are very similar for both formats and a lot can be reused.  Try to map the position of a character within a paragraph of ODF to OOXML..  To me it was a nightmare..    Aside of my love to XPath, I do not see any use here...  I suggest we are not using this hammer, for this time, but wait for a nail instead..   Regards, Svante    Hope everyone is having a great day! Patrick On 01/13/2016 06:55 AM, Svante Schubert wrote: > The immutable change-tracking is indeed very useful for the > scenario of commenting and editing a signed document. In this > scenario the XML can not be changed, as otherwise the sign would be > broken. Every comment/edit would be saved aside the signed content > XML and might be signed again for each author, ensuring the > validity of the complete content. > > That the changes will in the future refer to the position of change > into the content instead of embedding it as prior we agree on. > XPath is just a possible choice of implementation for referencing. > From my observation Patrick's ideas are not based on XPath, he just > took it as example. I rather would avoid XPath as ODF application > do not require to have an XML model representation at run time, in > contrary to the file model related DOM run-time API of browsers. In > addition ODF XML has no normalized representation, which make XML > references more difficult. Therefore the abstraction from XML to > logical identities, which are known to users and referencing to > those will be easier to handle by general run-time model related to > ODF and works well for applications without ODF XML awareness even > at run-time. > > I have experienced this in my work on a browser based office with > Open-XChange in the past years. For example, the reference of the > 3rd character within the 2nd paragraph might be written as /2/3 > which can be seen as a simplification of XPath and was handled by > the browser office I have been working with as simple integer > array, making things easy for the office at run-time. > > Kind regards, Svante > > On Jan 8, 2016 9:58 PM, "Patrick Durusau" < patrick@durusau.net > <mailto: patrick@durusau.net >> 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. > > Hope everyone is at the start of a great weekend! > > Patrick > > > --------------------------------------------------------------------- > > 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 iQIcBAEBAgAGBQJWlmzmAAoJEFPGsgi3Mgyc8hwQAMUehF9iQ/HKW5Xzl62UsZD6 U2FFKpoc8lFaMKAC/l9I91Y6Q9j6o5383+aEkkWBXj+ff4K05KbEsxVsw+Kjd7v3 VLEmDFpeTiq8ZvPfc3Hr80ETxgNOt9zXxXAiBaTpuAfJqqoQiiau4iPKy62e52mf +mnbSvefg1sU52YxL+AI8Ahla3DN4FJKzC7ogTK9PXu2Je75Zz+eWoiYbw1mHe6H Ko3pujPy4RmCJSirnovi+ag2IktaI23lqJr7zQKX9HaU0psNxtWlO4vlcVKci3+a C/GqgBjmZ6hY60wtoZyIUmFvRsNwd/Tp06iZeV/MfjFq+g7lAXGfh/7IhKl+2fUN ITjTOVprdqMimyPRp94/9DmkEZHcD9ZDL/mnHkiQrBSWNO2JbXmq4CwNPk769NCd ci0rrVPvZHCgj88tq42e4dEwxpodw2u1kw3F7UiXcaXyIDuwdXVAhKnH1cfvtdLy f2DI9xPuggWldNlQfzggOfVktmwiZs7+FWnMrqA4WQLU/hjYWXF4YYyz91kbKU4x WtZOvfSkcn4ZIsxCAzWVarelwwbisDCBOOxN7wGztyn49AHcyBBjTsZ7G/HhQVQJ RTG90KAL2G+2uWznwrCjA8mqIsXigN0gpufT3bl+t73vjvR30nqvEYcsB2xR1AvR dNMvzvjzWSAjsUUSmMDC =0Whb -----END PGP SIGNATURE-----  

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Camilla, What I fail to understand is the revulsion against XPath? Doesn't Calligra in fact import the ODF XML format? How is that any different from reading an XPath statement for the location where insertion of a paragraph should occur? That is to say that Calligra is already converting XML into its internal representation, including in-line change tracking if you support that now. Even if implementers prefer a "component" approach, that is nothing more than translating XPath statements into a different vocabulary. If I am correct, that components are the equivalents of steps in an XPath statement, why the opposition to XPath? It may not be as compact as components and so if we derive a compact representation that is called components but is in fact a simplified version of XPath, where the beef? Truly I am failing to recognize why serializing changes in the same format as we use for documents is such an issue? I'm not expecting anyone to process ODF documents as XML, but to use the XML representation as an interchange format. Personally I think that would work for changes as well, whatever applications choose to call them. So, can you help me here? What is the difficulty with XPaths whether they are called XPath and written in XPath syntax or they are called components and we have to invent a syntax. Thanks! Hope you are looking forward to a great weekend! Patrick PS: To be fair, my misgivings about components are because they impose a model for change tracking (as does character offset) to be used by implementers. I would deeply prefer that implementers have the freedom to choose whatever internal models they choose. From trees, to tables, to graphs, it makes no difference to me so long as they serialize to ODF as specified by the standard. On 01/15/2016 02:52 PM, Camilla Boemann wrote: > Actually I can safely say that if we go with XPath Calligra will > NOT implement changetracking > > > > *From:*office-collab@lists.oasis-open.org > [ mailto:office-collab@lists.oasis-open.org ] *On Behalf Of *Svante > Schubert *Sent:* 15. januar 2016 20:47 *To:* Patrick Durusau > <patrick@durusau.net> *Cc:* office-collab@lists.oasis-open.org > *Subject:* Re: [office-collab] Immutable Change Tracking > > > > Patrick, > > > > On Wed, Jan 13, 2016 at 4:27 PM, Patrick Durusau > <patrick@durusau.net < mailto:patrick@durusau.net >> wrote: > > Svante, > > I'm sorry you are missing the call today because I think the XPath > / no XML model at run time is an important issue to discuss. > Perhaps we can get started today and over time iron it out. > > I say that because your right, no ODF application is required to > have an XML model. > > ODF applications can have any internal model they care to have, > but, they are required to *read* ODF XML and to *write* ODF XML > from their purely internal representations. > > That is to say that the XML file format of ODF *is* the > abstraction layer that enables many ODF applications to have > varying internal models . > >> ODF is indeed a very good abstraction to exchange serialized XML >> models. > >> Still there is room for further simplification by doing some >> *further *abstraction upon the ODF XML to logical objects >> (components). > > > >> This has advantages, for instance: > >> If I say, I will change the 2nd character of the 3rd paragraph, I >> might apply the change to ODF or OOXML, as they can be addressed >> similar for this subset. > >> In the XPath view we are quite lost to see that we are talking of >> the same logical change and/or the same logical document but in a >> different XML representation. > > > >> Not saying that we can map and abstract all ODF & OOXML on this >> level, but comparison gets easier and how did Einstein said, we >> should take the easiest solution that works, but nothing >> easier.. > > > > > > So, my choice of XPath was very intentional because it too is an > abstract representation of the change, against the abstraction > that the ODF application has already read into its internal > structure. > > The same process of reading the ODF document would be applied to > reading the change into the internal representation of the ODF > application. > >> XPath is very powerful, but it has many feature we do not need. >> Also does it depend on an XML that does not exist at run-time, >> but the positions have to exist and handled during run-time, as >> whenever something is inserted ahead (or above) the position is >> increased (or decreased when its being deleted), positions have >> to be updated. Much harder to evaluate and adopt these with >> XPath. > >> XML and XPath are wonderful technologies, but these are not the >> hammers we are looking for... > > > > > > Likewise, when an ODF application serializes changes, however it > stores them internally, it serializes them against the immutable > XML ODF file which it read when it loaded the file. > > The abstraction of XPath to "logical identities" maybe how many > ODF applications choose to go from the XPath representation to > their internal model but that's an application's choice and I would > prefer that we not dictate to applications their abstractions. > > Using XML for both the file format and changes allows ODF to > remain above the choices made by ODF applications. > >> Again, I am curious if any ODF application develop would like to >> use XPath. At least nobody at Open-XChange was interested in it >> and was happy on doing an abstraction. Perhaps because they not >> only imported ODF, but as well OOXML, which is quite common for >> office applications and they wanted to use the same mechanism for >> both formats. > >> Because when the office XML is being abstracted to logical >> objects - I usually call components - the referencing is are very >> similar for both formats and a lot can be reused. > >> Try to map the position of a character within a paragraph of ODF >> to OOXML.. To me it was a nightmare.. > > > >> Aside of my love to XPath, I do not see any use here... > >> I suggest we are not using this hammer, for this time, but wait >> for a nail instead.. > > > >> Regards, > >> Svante > > > > Hope everyone is having a great day! > > Patrick > > > > > > On 01/13/2016 06:55 AM, Svante Schubert wrote: >> The immutable change-tracking is indeed very useful for the >> scenario of commenting and editing a signed document. In this >> scenario the XML can not be changed, as otherwise the sign would >> be broken. Every comment/edit would be saved aside the signed >> content XML and might be signed again for each author, ensuring >> the validity of the complete content. > >> That the changes will in the future refer to the position of >> change into the content instead of embedding it as prior we agree >> on. XPath is just a possible choice of implementation for >> referencing. From my observation Patrick's ideas are not based on >> XPath, he just took it as example. I rather would avoid XPath as >> ODF application do not require to have an XML model >> representation at run time, in contrary to the file model related >> DOM run-time API of browsers. In addition ODF XML has no >> normalized representation, which make XML references more >> difficult. Therefore the abstraction from XML to logical >> identities, which are known to users and referencing to those >> will be easier to handle by general run-time model related to ODF >> and works well for applications without ODF XML awareness even at >> run-time. > >> I have experienced this in my work on a browser based office >> with Open-XChange in the past years. For example, the reference >> of the 3rd character within the 2nd paragraph might be written as >> /2/3 which can be seen as a simplification of XPath and was >> handled by the browser office I have been working with as simple >> integer array, making things easy for the office at run-time. > >> Kind regards, Svante > >> On Jan 8, 2016 9:58 PM, "Patrick Durusau" <patrick@durusau.net > < mailto:patrick@durusau.net > > >> < mailto:patrick@durusau.net < mailto:patrick@durusau.net >>> >> 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. > >> Hope everyone is at the start of a great weekend! > >> Patrick > > > >> --------------------------------------------------------------------- > >> > > 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.ph p > >> > > > > - -- 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 iQIcBAEBAgAGBQJWmVTnAAoJEFPGsgi3MgycXrgQAMlnLA1IBfTlulWhoEb64gP7 3+Y0KCK17MW6JjjstlnDJAq74WIWa1K9yr0TjNGNNd7psNPVO3K2GUm7XCsXJCh6 F8zAGsnjHfbSBisQsJ1vTIguG8V7M5npsQAU/CC35VNI/oDszAkTCSvciUA539P9 floJ0IkLV556EfgtO7KDr1N740CPlPo9Prq8gaPQaKMxlp0lVucyptNdxHLvD56j G7YgYCwLz49SWj8T/+3dDus/5hLkNbKUcglk6zaoYMnARbLT+Ly4tXqxXQCOfY6B 3TEe5Z1chjwhJiCdXeXSXhKHax5XB//QimoFY3Rd9BxmOOHpxWSd/Oixe4A953zi xasfdHQixqgwLkGeRzcYI332Wz+RqSRHOXNlqVSiuGCYCm5ZpD9clg+kwjfbsn9d pA/Zpw1Vz9yYw2jcUWuH43Z3FsmmRWmbcZX7vJXFspGWkwxlUdkLgUm0D0wwLwfs 3oerM0FijdOImDHtXwX4XmQ1cDHnF+1o8V4YVPwTmdEm/Qz8F0TECyJrrqAVTBdj uj2Yr2jDsoAmF9CREpV6MxRhTlWojZpfudEKxsuJw+zma+XcsxVlY9BMt1A3Grkb Xl4lGtP/Hgg8iiXxXgBXVPHpIQJjkYe1yVMrFnPN0/IUx4nh1DTcaFqL9yxskhWL X3WGQjTl6qo8RsDLrt9c =F4TB -----END PGP SIGNATURE-----

Hi Patrick Because in order to "translate" what such xpath statements would mean we would have to implement the editing in xml to (if only to understand the xpath) Let me try and illustrate We have a basic document: <a>< c/></a) And two pseudo xpath operations describing accepted changes: Second to last operation) delete <d/> placed left of <e/> Last operation) delete <e/> placed left of <c/> Now in order for me to translate the last operation) into my internal representation I would also have to implement how the second to last operation would produce an xml document (and not just what it does to my internal representation) If those operations were expressed in a more generic way not tied to a specific syntax I would be able to translate it directly into my internal representation. Bottom line is if we go through xpath I would have to implement all operations on xml format as well as on my internal representation Not quite sure if it makes sense to you?
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Patrick Durusau Sent: 15. januar 2016 21:22 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Immutable Change Tracking -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Camilla, What I fail to understand is the revulsion against XPath? Doesn't Calligra in fact import the ODF XML format? How is that any different from reading an XPath statement for the location where insertion of a paragraph should occur? That is to say that Calligra is already converting XML into its internal representation, including in-line change tracking if you support that now. Even if implementers prefer a "component" approach, that is nothing more than translating XPath statements into a different vocabulary. If I am correct, that components are the equivalents of steps in an XPath statement, why the opposition to XPath? It may not be as compact as components and so if we derive a compact representation that is called components but is in fact a simplified version of XPath, where the beef? Truly I am failing to recognize why serializing changes in the same format as we use for documents is such an issue? I'm not expecting anyone to process ODF documents as XML, but to use the XML representation as an interchange format. Personally I think that would work for changes as well, whatever applications choose to call them. So, can you help me here? What is the difficulty with XPaths whether they are called XPath and written in XPath syntax or they are called components and we have to invent a syntax. Thanks! Hope you are looking forward to a great weekend! Patrick PS: To be fair, my misgivings about components are because they impose a model for change tracking (as does character offset) to be used by implementers. I would deeply prefer that implementers have the freedom to choose whatever internal models they choose. From trees, to tables, to graphs, it makes no difference to me so long as they serialize to ODF as specified by the standard. On 01/15/2016 02:52 PM, Camilla Boemann wrote: > Actually I can safely say that if we go with XPath Calligra will NOT > implement changetracking > > > > *From:*office-collab@lists.oasis-open.org > [ mailto:office-collab@lists.oasis-open.org ] *On Behalf Of *Svante > Schubert *Sent:* 15. januar 2016 20:47 *To:* Patrick Durusau > <patrick@durusau.net> *Cc:* office-collab@lists.oasis-open.org > *Subject:* Re: [office-collab] Immutable Change Tracking > > > > Patrick, > > > > On Wed, Jan 13, 2016 at 4:27 PM, Patrick Durusau <patrick@durusau.net > < mailto:patrick@durusau.net >> wrote: > > Svante, > > I'm sorry you are missing the call today because I think the XPath / > no XML model at run time is an important issue to discuss. > Perhaps we can get started today and over time iron it out. > > I say that because your right, no ODF application is required to have > an XML model. > > ODF applications can have any internal model they care to have, but, > they are required to *read* ODF XML and to *write* ODF XML from their > purely internal representations. > > That is to say that the XML file format of ODF *is* the abstraction > layer that enables many ODF applications to have varying internal > models . > >> ODF is indeed a very good abstraction to exchange serialized XML >> models. > >> Still there is room for further simplification by doing some *further >> *abstraction upon the ODF XML to logical objects (components). > > > >> This has advantages, for instance: > >> If I say, I will change the 2nd character of the 3rd paragraph, I >> might apply the change to ODF or OOXML, as they can be addressed >> similar for this subset. > >> In the XPath view we are quite lost to see that we are talking of >> the same logical change and/or the same logical document but in a >> different XML representation. > > > >> Not saying that we can map and abstract all ODF & OOXML on this >> level, but comparison gets easier and how did Einstein said, we >> should take the easiest solution that works, but nothing >> easier.. > > > > > > So, my choice of XPath was very intentional because it too is an > abstract representation of the change, against the abstraction > that the ODF application has already read into its internal > structure. > > The same process of reading the ODF document would be applied to > reading the change into the internal representation of the ODF > application. > >> XPath is very powerful, but it has many feature we do not need. >> Also does it depend on an XML that does not exist at run-time, >> but the positions have to exist and handled during run-time, as >> whenever something is inserted ahead (or above) the position is >> increased (or decreased when its being deleted), positions have >> to be updated. Much harder to evaluate and adopt these with >> XPath. > >> XML and XPath are wonderful technologies, but these are not the >> hammers we are looking for... > > > > > > Likewise, when an ODF application serializes changes, however it > stores them internally, it serializes them against the immutable > XML ODF file which it read when it loaded the file. > > The abstraction of XPath to "logical identities" maybe how many > ODF applications choose to go from the XPath representation to > their internal model but that's an application's choice and I would > prefer that we not dictate to applications their abstractions. > > Using XML for both the file format and changes allows ODF to > remain above the choices made by ODF applications. > >> Again, I am curious if any ODF application develop would like to >> use XPath. At least nobody at Open-XChange was interested in it >> and was happy on doing an abstraction. Perhaps because they not >> only imported ODF, but as well OOXML, which is quite common for >> office applications and they wanted to use the same mechanism for >> both formats. > >> Because when the office XML is being abstracted to logical >> objects - I usually call components - the referencing is are very >> similar for both formats and a lot can be reused. > >> Try to map the position of a character within a paragraph of ODF >> to OOXML.. To me it was a nightmare.. > > > >> Aside of my love to XPath, I do not see any use here... > >> I suggest we are not using this hammer, for this time, but wait >> for a nail instead.. > > > >> Regards, > >> Svante > > > > Hope everyone is having a great day! > > Patrick > > > > > > On 01/13/2016 06:55 AM, Svante Schubert wrote: >> The immutable change-tracking is indeed very useful for the >> scenario of commenting and editing a signed document. In this >> scenario the XML can not be changed, as otherwise the sign would >> be broken. Every comment/edit would be saved aside the signed >> content XML and might be signed again for each author, ensuring >> the validity of the complete content. > >> That the changes will in the future refer to the position of >> change into the content instead of embedding it as prior we agree >> on. XPath is just a possible choice of implementation for >> referencing. From my observation Patrick's ideas are not based on >> XPath, he just took it as example. I rather would avoid XPath as >> ODF application do not require to have an XML model >> representation at run time, in contrary to the file model related >> DOM run-time API of browsers. In addition ODF XML has no >> normalized representation, which make XML references more >> difficult. Therefore the abstraction from XML to logical >> identities, which are known to users and referencing to those >> will be easier to handle by general run-time model related to ODF >> and works well for applications without ODF XML awareness even at >> run-time. > >> I have experienced this in my work on a browser based office >> with Open-XChange in the past years. For example, the reference >> of the 3rd character within the 2nd paragraph might be written as >> /2/3 which can be seen as a simplification of XPath and was >> handled by the browser office I have been working with as simple >> integer array, making things easy for the office at run-time. > >> Kind regards, Svante > >> On Jan 8, 2016 9:58 PM, "Patrick Durusau" <patrick@durusau.net > < mailto:patrick@durusau.net > > >> < mailto:patrick@durusau.net < mailto:patrick@durusau.net >>> >> 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. > >> Hope everyone is at the start of a great weekend! > >> Patrick > > > >> --------------------------------------------------------------------- > >> > > 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.ph p > >> > > > > - -- 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 iQIcBAEBAgAGBQJWmVTnAAoJEFPGsgi3MgycXrgQAMlnLA1IBfTlulWhoEb64gP7 3+Y0KCK17MW6JjjstlnDJAq74WIWa1K9yr0TjNGNNd7psNPVO3K2GUm7XCsXJCh6 F8zAGsnjHfbSBisQsJ1vTIguG8V7M5npsQAU/CC35VNI/oDszAkTCSvciUA539P9 floJ0IkLV556EfgtO7KDr1N740CPlPo9Prq8gaPQaKMxlp0lVucyptNdxHLvD56j G7YgYCwLz49SWj8T/+3dDus/5hLkNbKUcglk6zaoYMnARbLT+Ly4tXqxXQCOfY6B 3TEe5Z1chjwhJiCdXeXSXhKHax5XB//QimoFY3Rd9BxmOOHpxWSd/Oixe4A953zi xasfdHQixqgwLkGeRzcYI332Wz+RqSRHOXNlqVSiuGCYCm5ZpD9clg+kwjfbsn9d pA/Zpw1Vz9yYw2jcUWuH43Z3FsmmRWmbcZX7vJXFspGWkwxlUdkLgUm0D0wwLwfs 3oerM0FijdOImDHtXwX4XmQ1cDHnF+1o8V4YVPwTmdEm/Qz8F0TECyJrrqAVTBdj uj2Yr2jDsoAmF9CREpV6MxRhTlWojZpfudEKxsuJw+zma+XcsxVlY9BMt1A3Grkb Xl4lGtP/Hgg8iiXxXgBXVPHpIQJjkYe1yVMrFnPN0/IUx4nh1DTcaFqL9yxskhWL X3WGQjTl6qo8RsDLrt9c =F4TB -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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

I created a simple example document for an offline discussion with Patrick about XPath I would like to share. While Patrick is quite in favor of XPath, I am opposing XPath for the use of referencing into ODF XML for change-tracking. Do not get me wrong, XPath is a great technique, but it was build for general purpose, arbitrary XML.  The proposed referencing model for change-tracking is only focused on office documents, abstracting from XML and therefore of advantage. One problem of XPath is that its references are not normalized. In other words, there are multiple ways to reference to the same XML element. Implementations have to implement all possible cases and normalize XPath references to become aware that the same XML element is being pointed to.  The same problem applies to ODF XML, which is neither normlized. The semantic identical document can be shown in different ways in XML. Our proposed component model for change-tracking abstracts from those variations. Let me give the ODT document example. In the ODF example document there are two letters "A" and "B". How easy is it for one of you to provide the XPath references to A and B?   Let me give a general description of the example document: The letter "A" has been inserted as part of a paragraph within a list-item of list level 9.  AFAIK for the application models of MS Office and LibreOffice the list level are only properties of the paragraph, so it is for the component. Written in as references of the new change-tracking operations A is located at  /9/12 B is located at /12/2/2/2/2 In detail for A:  The 9th top level component (paragraph) and the 12th character NOTE: List items are just paragraph properties. Similar span are only boilerplate to attach properties to characters. In detail   for B: The 12th top level component (table), 2nd row, 2nd cell, 2nd paragraph and 2nd character Most important we can apply OT easily. By looking only  at the integers we are aware if the operations influence each other. Whenever an insertion/deletion occurs before or above.  This evidence would not be the automatically the case for XPath references. Best thing of all, the same references apply for OOXML, they are again: A is located at  /9/12 B is located at /12/2/2/2/2 Take a look at the DOCX and document.xml created by MS Office 2016.  The mapping from OOXML to component is surely different (so the XPath), but the high level structure is identical. From this example, it seems to me that components imposing far less a  model for change tracking to be used by implementers than XPath would do. What you think? Have a nice week-end, Svante   On Fri, Jan 15, 2016 at 10:00 PM, Camilla Boemann < cbo@boemann.dk > wrote: Hi Patrick Because in order to "translate" what such xpath statements would mean we would have to implement the editing in xml to (if only to understand the xpath) Let me try and illustrate We have a basic document: <a>< c/></a) And two pseudo xpath operations describing accepted changes: Second to last operation)  delete <d/> placed left of <e/> Last operation) delete <e/> placed left of <c/> Now in order for me to translate the last operation) into my internal representation I would also have to implement how the second to last operation would produce an xml document (and not just what it does to my internal representation) If those operations were expressed in a more generic way not tied to a specific syntax I would be able to translate it directly into my internal representation. Bottom line is if we go through xpath I would have to implement all operations on xml format as well as on my internal representation Not quite sure if it makes sense to you?
Original Message----- From: office-collab@lists.oasis-open.org [mailto: office-collab@lists.oasis-open.org ] On Behalf Of Patrick Durusau Sent: 15. januar 2016 21:22 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Immutable Change Tracking -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Camilla, What I fail to understand is the revulsion against XPath? Doesn't Calligra in fact import the ODF XML format? How is that any different from reading an XPath statement for the location where insertion of a paragraph should occur? That is to say that Calligra is already converting XML into its internal representation, including in-line change tracking if you support that now. Even if implementers prefer a "component" approach, that is nothing more than translating XPath statements into a different vocabulary. If I am correct, that components are the equivalents of steps in an XPath statement, why the opposition to XPath? It may not be as compact as components and so if we derive a compact representation that is called components but is in fact a simplified version of XPath, where the beef? Truly I am failing to recognize why serializing changes in the same format as we use for documents is such an issue? I'm not expecting anyone to process ODF documents as XML, but to use the XML representation as an interchange format. Personally I think that would work for changes as well, whatever applications choose to call them. So, can you help me here? What is the difficulty with XPaths whether they are called XPath and written in XPath syntax or they are called components and we have to invent a syntax. Thanks! Hope you are looking forward to a great weekend! Patrick PS: To be fair, my misgivings about components are because they impose a model for change tracking (as does character offset) to be used by implementers. I would deeply prefer that implementers have the freedom to choose whatever internal models they choose. From trees, to tables, to graphs, it makes no difference to me so long as they serialize to ODF as specified by the standard. On 01/15/2016 02:52 PM, Camilla Boemann wrote: > Actually I can safely say that if we go with XPath Calligra will NOT > implement changetracking > > > > *From:* office-collab@lists.oasis-open.org > [mailto: office-collab@lists.oasis-open.org ] *On Behalf Of *Svante > Schubert *Sent:* 15. januar 2016 20:47 *To:* Patrick Durusau > < patrick@durusau.net > *Cc:* office-collab@lists.oasis-open.org > *Subject:* Re: [office-collab] Immutable Change Tracking > > > > Patrick, > > > > On Wed, Jan 13, 2016 at 4:27 PM, Patrick Durusau < patrick@durusau.net > <mailto: patrick@durusau.net >> wrote: > > Svante, > > I'm sorry you are missing the call today because I think the XPath / > no XML model at run time is an important issue to discuss. > Perhaps we can get started today and over time iron it out. > > I say that because your right, no ODF application is required to have > an XML model. > > ODF applications can have any internal model they care to have, but, > they are required to *read* ODF XML and to *write* ODF XML from their > purely internal representations. > > That is to say that the XML file format of ODF *is* the abstraction > layer that enables many ODF applications to have varying internal > models . > >> ODF is indeed a very good abstraction to exchange serialized XML >> models. > >> Still there is room for further simplification by doing some *further >> *abstraction upon the ODF XML to logical objects (components). > > > >> This has advantages, for instance: > >> If I say, I will change the 2nd character of the 3rd paragraph, I >> might apply the change to ODF or OOXML, as they can be addressed >> similar for this subset. > >> In the XPath view we are quite lost to see that we are talking of >> the same logical change and/or the same logical document but in a >> different XML representation. > > > >> Not saying that we can map and abstract all ODF & OOXML on this >> level, but comparison gets easier and how did Einstein said, we >> should take the easiest solution that works, but nothing >> easier.. > > > > > > So, my choice of XPath was very intentional because it too is an > abstract representation of the change, against the abstraction > that the ODF application has already read into its internal > structure. > > The same process of reading the ODF document would be applied to > reading the change into the internal representation of the ODF > application. > >> XPath is very powerful, but it has many feature we do not need. >> Also does it depend on an XML that does not exist at run-time, >> but the positions have to exist and handled during run-time, as >> whenever something is inserted ahead (or above) the position is >> increased (or decreased when its being deleted), positions have >> to be updated. Much harder to evaluate and adopt these with >> XPath. > >> XML and XPath are wonderful technologies, but these are not the >> hammers we are looking for... > > > > > > Likewise, when an ODF application serializes changes, however it > stores them internally, it serializes them against the immutable > XML ODF file which it read when it loaded the file. > > The abstraction of XPath to "logical identities" maybe how many > ODF applications choose to go from the XPath representation to > their internal model but that's an application's choice and I would > prefer that we not dictate to applications their abstractions. > > Using XML for both the file format and changes allows ODF to > remain above the choices made by ODF applications. > >> Again, I am curious if any ODF application develop would like to >> use XPath. At least nobody at Open-XChange was interested in it >> and was happy on doing an abstraction. Perhaps because they not >> only imported ODF, but as well OOXML, which is quite common for >> office applications and they wanted to use the same mechanism for >> both formats. > >> Because when the office XML is being abstracted to logical >> objects - I usually call components - the referencing is are very >> similar for both formats and a lot can be reused. > >> Try to map the position of a character within a paragraph of ODF >> to OOXML..  To me it was a nightmare.. > > > >> Aside of my love to XPath, I do not see any use here... > >> I suggest we are not using this hammer, for this time, but wait >> for a nail instead.. > > > >> Regards, > >> Svante > > > > Hope everyone is having a great day! > > Patrick > > > > > > On 01/13/2016 06:55 AM, Svante Schubert wrote: >> The immutable change-tracking is indeed very useful for the >> scenario of commenting and editing a signed document. In this >> scenario the XML can not be changed, as otherwise the sign would >> be broken. Every comment/edit would be saved aside the signed >> content XML and might be signed again for each author, ensuring >> the validity of the complete content. > >> That the changes will in the future refer to the position of >> change into the content instead of embedding it as prior we agree >> on. XPath is just a possible choice of implementation for >> referencing. From my observation Patrick's ideas are not based on >> XPath, he just took it as example. I rather would avoid XPath as >> ODF application do not require to have an XML model >> representation at run time, in contrary to the file model related >> DOM run-time API of browsers. In addition ODF XML has no >> normalized representation, which make XML references more >> difficult. Therefore the abstraction from XML to logical >> identities, which are known to users and referencing to those >> will be easier to handle by general run-time model related to ODF >> and works well for applications without ODF XML awareness even at >> run-time. > >> I have experienced this in my work on a browser based office >> with Open-XChange in the past years. For example, the reference >> of the 3rd character within the 2nd paragraph might be written as >> /2/3 which can be seen as a simplification of XPath and was >> handled by the browser office I have been working with as simple >> integer array, making things easy for the office at run-time. > >> Kind regards, Svante > >> On Jan 8, 2016 9:58 PM, "Patrick Durusau" < patrick@durusau.net > <mailto: patrick@durusau.net > > >> <mailto: patrick@durusau.net <mailto: patrick@durusau.net >>> >> 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. > >> Hope everyone is at the start of a great weekend! > >> Patrick > > > >> --------------------------------------------------------------------- > >> > > 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.ph p > >> > > > > - -- 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 iQIcBAEBAgAGBQJWmVTnAAoJEFPGsgi3MgycXrgQAMlnLA1IBfTlulWhoEb64gP7 3+Y0KCK17MW6JjjstlnDJAq74WIWa1K9yr0TjNGNNd7psNPVO3K2GUm7XCsXJCh6 F8zAGsnjHfbSBisQsJ1vTIguG8V7M5npsQAU/CC35VNI/oDszAkTCSvciUA539P9 floJ0IkLV556EfgtO7KDr1N740CPlPo9Prq8gaPQaKMxlp0lVucyptNdxHLvD56j G7YgYCwLz49SWj8T/+3dDus/5hLkNbKUcglk6zaoYMnARbLT+Ly4tXqxXQCOfY6B 3TEe5Z1chjwhJiCdXeXSXhKHax5XB//QimoFY3Rd9BxmOOHpxWSd/Oixe4A953zi xasfdHQixqgwLkGeRzcYI332Wz+RqSRHOXNlqVSiuGCYCm5ZpD9clg+kwjfbsn9d pA/Zpw1Vz9yYw2jcUWuH43Z3FsmmRWmbcZX7vJXFspGWkwxlUdkLgUm0D0wwLwfs 3oerM0FijdOImDHtXwX4XmQ1cDHnF+1o8V4YVPwTmdEm/Qz8F0TECyJrrqAVTBdj uj2Yr2jDsoAmF9CREpV6MxRhTlWojZpfudEKxsuJw+zma+XcsxVlY9BMt1A3Grkb Xl4lGtP/Hgg8iiXxXgBXVPHpIQJjkYe1yVMrFnPN0/IUx4nh1DTcaFqL9yxskhWL X3WGQjTl6qo8RsDLrt9c =F4TB -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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 <?xml version="1.0" encoding="UTF-8"?> <office:document-content xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" xmlns:xlink=" http://www.w3.org/1999/xlink" ; xmlns:dc=" http://purl.org/dc/elements/1.1/" ; xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" xmlns:math=" http://www.w3.org/1998/Math/MathML" ; xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" xmlns:ooo=" http://openoffice.org/2004/office" ; xmlns:ooow=" http://openoffice.org/2004/writer" ; xmlns:oooc=" http://openoffice.org/2004/calc" ; xmlns:dom=" http://www.w3.org/2001/xml-events" ; xmlns:xforms=" http://www.w3.org/2002/xforms" ; xmlns:xsd=" http://www.w3.org/2001/XMLSchema" ; xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance" ; xmlns:rpt=" http://openoffice.org/2005/report" ; xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" xmlns:xhtml=" http://www.w3.org/1999/xhtml" ; xmlns:grddl=" http://www.w3.org/2003/g/data-view#" ; xmlns:formx="urn:openoffice:names:experimental:ooxml-odf-interop:xmlns:form:1.0" xmlns:css3t=" http://www.w3.org/TR/css3-text/" ; office:version="1.1"> <office:scripts/> <office:font-face-decls> <style:font-face style:name="Lucida Sans1" svg:font-family="&apos;Lucida Sans&apos;" style:font-family-generic="swiss"/> <style:font-face style:name="Liberation Serif" svg:font-family="&apos;Liberation Serif&apos;" style:font-family-generic="roman" style:font-pitch="variable"/> <style:font-face style:name="Liberation Sans" svg:font-family="&apos;Liberation Sans&apos;" style:font-family-generic="swiss" style:font-pitch="variable"/> <style:font-face style:name="Lucida Sans" svg:font-family="&apos;Lucida Sans&apos;" style:font-family-generic="system" style:font-pitch="variable"/> <style:font-face style:name="Microsoft YaHei" svg:font-family="&apos;Microsoft YaHei&apos;" style:font-family-generic="system" style:font-pitch="variable"/> <style:font-face style:name="SimSun" svg:font-family="SimSun" style:font-family-generic="system" style:font-pitch="variable"/> </office:font-face-decls> <office:automatic-styles> <style:style style:name="Table1" style:family="table"> <style:table-properties style:width="17cm" table:align="margins"/> </style:style> <style:style style:name="Table1.A" style:family="table-column"> <style:table-column-properties style:column-width="5.667cm" style:rel-column-width="21845*"/> </style:style> <style:style style:name="Table1.A1" style:family="table-cell"> <style:table-cell-properties fo:padding="0.097cm" fo:border-left="0.05pt solid #000000" fo:border-right="none" fo:border-top="0.05pt solid #000000" fo:border-bottom="0.05pt solid #000000"/> </style:style> <style:style style:name="Table1.C1" style:family="table-cell"> <style:table-cell-properties fo:padding="0.097cm" fo:border="0.05pt solid #000000"/> </style:style> <style:style style:name="Table1.A2" style:family="table-cell"> <style:table-cell-properties fo:padding="0.097cm" fo:border-left="0.05pt solid #000000" fo:border-right="none" fo:border-top="none" fo:border-bottom="0.05pt solid #000000"/> </style:style> <style:style style:name="Table1.B2" style:family="table-cell"> <style:table-cell-properties fo:padding="0.097cm" fo:border-left="0.05pt solid #000000" fo:border-right="0.05pt solid #000000" fo:border-top="none" fo:border-bottom="0.05pt solid #000000"/> </style:style> <style:style style:name="P1" style:family="paragraph" style:parent-style-name="Standard" style:list-style-name="L1"/> <style:style style:name="T1" style:family="text"> <style:text-properties fo:color="#800000" style:text-underline-style="solid" style:text-underline-width="auto" style:text-underline-color="font-color" fo:font-weight="bold" style:font-weight-asian="bold" style:font-weight-complex="bold"/> </style:style> <text:list-style style:name="L1"> <text:list-level-style-number text:level="1" text:style-name="Numbering_20_Symbols" style:num-suffix="." style:num-format="1"> <style:list-level-properties text:space-before="0.635cm" text:min-label-width="0.635cm"/> </text:list-level-style-number> <text:list-level-style-number text:level="2" text:style-name="Numbering_20_Symbols" style:num-suffix="." style:num-format="1"> <style:list-level-properties text:space-before="1.27cm" text:min-label-width="0.635cm"/> </text:list-level-style-number> <text:list-level-style-number text:level="3" text:style-name="Numbering_20_Symbols" style:num-suffix="." style:num-format="1"> <style:list-level-properties text:space-before="1.905cm" text:min-label-width="0.635cm"/> </text:list-level-style-number> <text:list-level-style-number text:level="4" text:style-name="Numbering_20_Symbols" style:num-suffix="." style:num-format="1"> <style:list-level-properties text:space-before="2.54cm" text:min-label-width="0.635cm"/> </text:list-level-style-number> <text:list-level-style-number text:level="5" text:style-name="Numbering_20_Symbols" style:num-suffix="." style:num-format="1"> <style:list-level-properties text:space-before="3.175cm" text:min-label-width="0.635cm"/> </text:list-level-style-number> <text:list-level-style-number text:level="6" text:style-name="Numbering_20_Symbols" style:num-suffix="." style:num-format="1"> <style:list-level-properties text:space-before="3.81cm" text:min-label-width="0.635cm"/> </text:list-level-style-number> <text:list-level-style-number text:level="7" text:style-name="Numbering_20_Symbols" style:num-suffix="." style:num-format="1"> <style:list-level-properties text:space-before="4.445cm" text:min-label-width="0.635cm"/> </text:list-level-style-number> <text:list-level-style-number text:level="8" text:style-name="Numbering_20_Symbols" style:num-suffix="." style:num-format="1"> <style:list-level-properties text:space-before="5.08cm" text:min-label-width="0.635cm"/> </text:list-level-style-number> <text:list-level-style-number text:level="9" text:style-name="Numbering_20_Symbols" style:num-suffix="." style:num-format="1"> <style:list-level-properties text:space-before="5.715cm" text:min-label-width="0.635cm"/> </text:list-level-style-number> <text:list-level-style-number text:level="10" text:style-name="Numbering_20_Symbols" style:num-suffix="." style:num-format="1"> <style:list-level-properties text:space-before="6.35cm" text:min-label-width="0.635cm"/> </text:list-level-style-number> </text:list-style> </office:automatic-styles> <office:body> <office:text> <office:forms form:automatic-focus="false" form:apply-design-mode="false"/> <text:sequence-decls> <text:sequence-decl text:display-outline-level="0" text:name="Illustration"/> <text:sequence-decl text:display-outline-level="0" text:name="Table"/> <text:sequence-decl text:display-outline-level="0" text:name="Text"/> <text:sequence-decl text:display-outline-level="0" text:name="Drawing"/> </text:sequence-decls> <text:list text:style-name="L1"> <text:list-item> <text:p text:style-name="P1">First level</text:p> <text:list> <text:list-item> <text:p text:style-name="P1">Second Level</text:p> <text:list> <text:list-item> <text:p text:style-name="P1">third level</text:p> <text:list> <text:list-item> <text:p text:style-name="P1">forth level</text:p> <text:list> <text:list-item> <text:p text:style-name="P1">fifth level</text:p> <text:list> <text:list-item> <text:p text:style-name="P1">6th level</text:p> <text:list> <text:list-item> <text:p text:style-name="P1">7th level</text:p> <text:list> <text:list-item> <text:p text:style-name="P1">8th level</text:p> <text:list> <text:list-item> <text:p text:style-name="P1">9th level „<text:span text:style-name="T1">A</text:span>“</text:p> </text:list-item> <text:list-item> <text:p text:style-name="P1">Something new?</text:p> </text:list-item> </text:list> </text:list-item> </text:list> </text:list-item> </text:list> </text:list-item> </text:list> </text:list-item> </text:list> </text:list-item> </text:list> </text:list-item> </text:list> </text:list-item> </text:list> </text:list-item> </text:list> <text:p text:style-name="Standard"/> <table:table table:name="Table1" table:style-name="Table1"> <table:table-column table:style-name="Table1.A" table:number-columns-repeated="3"/> <table:table-header-rows> <table:table-row> <table:table-cell table:style-name="Table1.A1" office:value-type="string"> <text:p text:style-name="Table_20_Heading"/> </table:table-cell> <table:table-cell table:style-name="Table1.A1" office:value-type="string"> <text:p text:style-name="Table_20_Heading"/> </table:table-cell> <table:table-cell table:style-name="Table1.C1" office:value-type="string"> <text:p text:style-name="Table_20_Heading"/> </table:table-cell> </table:table-row> </table:table-header-rows> <table:table-row> <table:table-cell table:style-name="Table1.A2" office:value-type="string"> <text:p text:style-name="Table_20_Contents"/> </table:table-cell> <table:table-cell table:style-name="Table1.B2" table:number-columns-spanned="2" office:value-type="string"> <text:p text:style-name="Table_20_Contents"/> <text:p text:style-name="Table_20_Contents">„<text:span text:style-name="T1">B</text:span>“</text:p> </table:table-cell> <table:covered-table-cell/> </table:table-row> <table:table-row> <table:table-cell table:style-name="Table1.A2" office:value-type="string"> <text:p text:style-name="Table_20_Contents"/> </table:table-cell> <table:table-cell table:style-name="Table1.A2" office:value-type="string"> <text:p text:style-name="Table_20_Contents"/> </table:table-cell> <table:table-cell table:style-name="Table1.B2" office:value-type="string"> <text:p text:style-name="Table_20_Contents"/> </table:table-cell> </table:table-row> </table:table> <text:p text:style-name="Standard"/> </office:text> </office:body> </office:document-content> Attachment: Complexity.odt Description: application/vnd.oasis.opendocument.text <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <w:document xmlns:wpc=" http://schemas.microsoft.com/office/word/2010/wordprocessingCanvas" ; xmlns:cx=" http://schemas.microsoft.com/office/drawing/2014/chartex" ; xmlns:mc=" http://schemas.openxmlformats.org/markup-compatibility/2006" ; xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:r=" http://schemas.openxmlformats.org/officeDocument/2006/relationships" ; xmlns:m=" http://schemas.openxmlformats.org/officeDocument/2006/math" ; xmlns:v="urn:schemas-microsoft-com:vml" xmlns:wp14=" http://schemas.microsoft.com/office/word/2010/wordprocessingDrawing" ; xmlns:wp=" http://schemas.openxmlformats.org/drawingml/2006/wordprocessingDrawing" ; xmlns:w10="urn:schemas-microsoft-com:office:word" xmlns:w=" http://schemas.openxmlformats.org/wordprocessingml/2006/main" ; xmlns:w14=" http://schemas.microsoft.com/office/word/2010/wordml" ; xmlns:w15=" http://schemas.microsoft.com/office/word/2012/wordml" ; xmlns:w16se=" http://schemas.microsoft.com/office/word/2015/wordml/symex" ; xmlns:wpg=" http://schemas.microsoft.com/office/word/2010/wordprocessingGroup" ; xmlns:wpi=" http://schemas.microsoft.com/office/word/2010/wordprocessingInk" ; xmlns:wne=" http://schemas.microsoft.com/office/word/2006/wordml" ; xmlns:wps=" http://schemas.microsoft.com/office/word/2010/wordprocessingShape" ; mc:Ignorable="w14 w15 w16se wp14"> <w:body> <w:p w:rsidR="00F3490C" w:rsidRDefault="00B77273"> <w:pPr> <w:pStyle w:val="Standard"/> <w:numPr> <w:ilvl w:val="0"/> <w:numId w:val="1"/> </w:numPr> </w:pPr> <w:bookmarkStart w:id="0" w:name="_GoBack"/> <w:bookmarkEnd w:id="0"/> <w:r> <w:t>First level</w:t> </w:r> </w:p> <w:p w:rsidR="00F3490C" w:rsidRDefault="00B77273"> <w:pPr> <w:pStyle w:val="Standard"/> <w:numPr> <w:ilvl w:val="1"/> <w:numId w:val="1"/> </w:numPr> </w:pPr> <w:r> <w:t>Second Level</w:t> </w:r> </w:p> <w:p w:rsidR="00F3490C" w:rsidRDefault="00B77273"> <w:pPr> <w:pStyle w:val="Standard"/> <w:numPr> <w:ilvl w:val="2"/> <w:numId w:val="1"/> </w:numPr> </w:pPr> <w:r> <w:t>third level</w:t> </w:r> </w:p> <w:p w:rsidR="00F3490C" w:rsidRDefault="00B77273"> <w:pPr> <w:pStyle w:val="Standard"/> <w:numPr> <w:ilvl w:val="3"/> <w:numId w:val="1"/> </w:numPr> </w:pPr> <w:r> <w:t>forth level</w:t> </w:r> </w:p> <w:p w:rsidR="00F3490C" w:rsidRDefault="00B77273"> <w:pPr> <w:pStyle w:val="Standard"/> <w:numPr> <w:ilvl w:val="4"/> <w:numId w:val="1"/> </w:numPr> </w:pPr> <w:r> <w:t>fifth level</w:t> </w:r> </w:p> <w:p w:rsidR="00F3490C" w:rsidRDefault="00B77273"> <w:pPr> <w:pStyle w:val="Standard"/> <w:numPr> <w:ilvl w:val="5"/> <w:numId w:val="1"/> </w:numPr> </w:pPr> <w:r> <w:t>6th level</w:t> </w:r> </w:p> <w:p w:rsidR="00F3490C" w:rsidRDefault="00B77273"> <w:pPr> <w:pStyle w:val="Standard"/> <w:numPr> <w:ilvl w:val="6"/> <w:numId w:val="1"/> </w:numPr> </w:pPr> <w:r> <w:t>7th level</w:t> </w:r> </w:p> <w:p w:rsidR="00F3490C" w:rsidRDefault="00B77273"> <w:pPr> <w:pStyle w:val="Standard"/> <w:numPr> <w:ilvl w:val="7"/> <w:numId w:val="1"/> </w:numPr> </w:pPr> <w:r> <w:t>8th level</w:t> </w:r> </w:p> <w:p w:rsidR="00F3490C" w:rsidRDefault="00B77273"> <w:pPr> <w:pStyle w:val="Standard"/> <w:numPr> <w:ilvl w:val="8"/> <w:numId w:val="1"/> </w:numPr> </w:pPr> <w:r> <w:t>9th level „</w:t> </w:r> <w:r> <w:rPr> <w:b/> <w:bCs/> <w:color w:val="800000"/> <w:u w:val="single"/> </w:rPr> <w:t>A</w:t> </w:r> <w:r> <w:t>“</w:t> </w:r> </w:p> <w:p w:rsidR="00F3490C" w:rsidRDefault="00B77273"> <w:pPr> <w:pStyle w:val="Standard"/> <w:numPr> <w:ilvl w:val="8"/> <w:numId w:val="1"/> </w:numPr> </w:pPr> <w:r> <w:t>Something new?</w:t> </w:r> </w:p> <w:p w:rsidR="00F3490C" w:rsidRDefault="00F3490C"> <w:pPr> <w:pStyle w:val="Standard"/> </w:pPr> </w:p> <w:tbl> <w:tblPr> <w:tblW w:w="9638" w:type="dxa"/> <w:tblLayout w:type="fixed"/> <w:tblCellMar> <w:left w:w="10" w:type="dxa"/> <w:right w:w="10" w:type="dxa"/> </w:tblCellMar> <w:tblLook w:val="0000" w:firstRow="0" w:lastRow="0" w:firstColumn="0" w:lastColumn="0" w:noHBand="0" w:noVBand="0"/> </w:tblPr> <w:tblGrid> <w:gridCol w:w="3212"/> <w:gridCol w:w="3213"/> <w:gridCol w:w="3213"/> </w:tblGrid> <w:tr w:rsidR="00F3490C"> <w:tblPrEx> <w:tblCellMar> <w:top w:w="0" w:type="dxa"/> <w:bottom w:w="0" w:type="dxa"/> </w:tblCellMar> </w:tblPrEx> <w:trPr> <w:tblHeader/> </w:trPr> <w:tc> <w:tcPr> <w:tcW w:w="3213" w:type="dxa"/> <w:tcBorders> <w:top w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:left w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:bottom w:val="single" w:sz="2" w:space="0" w:color="000000"/> </w:tcBorders> <w:tcMar> <w:top w:w="55" w:type="dxa"/> <w:left w:w="55" w:type="dxa"/> <w:bottom w:w="55" w:type="dxa"/> <w:right w:w="55" w:type="dxa"/> </w:tcMar> </w:tcPr> <w:p w:rsidR="00F3490C" w:rsidRDefault="00F3490C"> <w:pPr> <w:pStyle w:val="TableHeading"/> </w:pPr> </w:p> </w:tc> <w:tc> <w:tcPr> <w:tcW w:w="3213" w:type="dxa"/> <w:tcBorders> <w:top w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:left w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:bottom w:val="single" w:sz="2" w:space="0" w:color="000000"/> </w:tcBorders> <w:tcMar> <w:top w:w="55" w:type="dxa"/> <w:left w:w="55" w:type="dxa"/> <w:bottom w:w="55" w:type="dxa"/> <w:right w:w="55" w:type="dxa"/> </w:tcMar> </w:tcPr> <w:p w:rsidR="00F3490C" w:rsidRDefault="00F3490C"> <w:pPr> <w:pStyle w:val="TableHeading"/> </w:pPr> </w:p> </w:tc> <w:tc> <w:tcPr> <w:tcW w:w="3213" w:type="dxa"/> <w:tcBorders> <w:top w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:left w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:bottom w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:right w:val="single" w:sz="2" w:space="0" w:color="000000"/> </w:tcBorders> <w:tcMar> <w:top w:w="55" w:type="dxa"/> <w:left w:w="55" w:type="dxa"/> <w:bottom w:w="55" w:type="dxa"/> <w:right w:w="55" w:type="dxa"/> </w:tcMar> </w:tcPr> <w:p w:rsidR="00F3490C" w:rsidRDefault="00F3490C"> <w:pPr> <w:pStyle w:val="TableHeading"/> </w:pPr> </w:p> </w:tc> </w:tr> <w:tr w:rsidR="00F3490C"> <w:tblPrEx> <w:tblCellMar> <w:top w:w="0" w:type="dxa"/> <w:bottom w:w="0" w:type="dxa"/> </w:tblCellMar> </w:tblPrEx> <w:tc> <w:tcPr> <w:tcW w:w="3213" w:type="dxa"/> <w:tcBorders> <w:left w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:bottom w:val="single" w:sz="2" w:space="0" w:color="000000"/> </w:tcBorders> <w:tcMar> <w:top w:w="55" w:type="dxa"/> <w:left w:w="55" w:type="dxa"/> <w:bottom w:w="55" w:type="dxa"/> <w:right w:w="55" w:type="dxa"/> </w:tcMar> </w:tcPr> <w:p w:rsidR="00F3490C" w:rsidRDefault="00F3490C"> <w:pPr> <w:pStyle w:val="TableContents"/> </w:pPr> </w:p> </w:tc> <w:tc> <w:tcPr> <w:tcW w:w="6426" w:type="dxa"/> <w:gridSpan w:val="2"/> <w:tcBorders> <w:left w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:bottom w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:right w:val="single" w:sz="2" w:space="0" w:color="000000"/> </w:tcBorders> <w:tcMar> <w:top w:w="55" w:type="dxa"/> <w:left w:w="55" w:type="dxa"/> <w:bottom w:w="55" w:type="dxa"/> <w:right w:w="55" w:type="dxa"/> </w:tcMar> </w:tcPr> <w:p w:rsidR="00F3490C" w:rsidRDefault="00F3490C"> <w:pPr> <w:pStyle w:val="TableContents"/> </w:pPr> </w:p> <w:p w:rsidR="00F3490C" w:rsidRDefault="00B77273"> <w:pPr> <w:pStyle w:val="TableContents"/> </w:pPr> <w:r> <w:t>„</w:t> </w:r> <w:r> <w:rPr> <w:b/> <w:bCs/> <w:color w:val="800000"/> <w:u w:val="single"/> </w:rPr> <w:t>B</w:t> </w:r> <w:r> <w:t>“</w:t> </w:r> </w:p> </w:tc> </w:tr> <w:tr w:rsidR="00F3490C"> <w:tblPrEx> <w:tblCellMar> <w:top w:w="0" w:type="dxa"/> <w:bottom w:w="0" w:type="dxa"/> </w:tblCellMar> </w:tblPrEx> <w:tc> <w:tcPr> <w:tcW w:w="3213" w:type="dxa"/> <w:tcBorders> <w:left w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:bottom w:val="single" w:sz="2" w:space="0" w:color="000000"/> </w:tcBorders> <w:tcMar> <w:top w:w="55" w:type="dxa"/> <w:left w:w="55" w:type="dxa"/> <w:bottom w:w="55" w:type="dxa"/> <w:right w:w="55" w:type="dxa"/> </w:tcMar> </w:tcPr> <w:p w:rsidR="00F3490C" w:rsidRDefault="00F3490C"> <w:pPr> <w:pStyle w:val="TableContents"/> </w:pPr> </w:p> </w:tc> <w:tc> <w:tcPr> <w:tcW w:w="3213" w:type="dxa"/> <w:tcBorders> <w:left w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:bottom w:val="single" w:sz="2" w:space="0" w:color="000000"/> </w:tcBorders> <w:tcMar> <w:top w:w="55" w:type="dxa"/> <w:left w:w="55" w:type="dxa"/> <w:bottom w:w="55" w:type="dxa"/> <w:right w:w="55" w:type="dxa"/> </w:tcMar> </w:tcPr> <w:p w:rsidR="00F3490C" w:rsidRDefault="00F3490C"> <w:pPr> <w:pStyle w:val="TableContents"/> </w:pPr> </w:p> </w:tc> <w:tc> <w:tcPr> <w:tcW w:w="3213" w:type="dxa"/> <w:tcBorders> <w:left w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:bottom w:val="single" w:sz="2" w:space="0" w:color="000000"/> <w:right w:val="single" w:sz="2" w:space="0" w:color="000000"/> </w:tcBorders> <w:tcMar> <w:top w:w="55" w:type="dxa"/> <w:left w:w="55" w:type="dxa"/> <w:bottom w:w="55" w:type="dxa"/> <w:right w:w="55" w:type="dxa"/> </w:tcMar> </w:tcPr> <w:p w:rsidR="00F3490C" w:rsidRDefault="00F3490C"> <w:pPr> <w:pStyle w:val="TableContents"/> </w:pPr> </w:p> </w:tc> </w:tr> </w:tbl> <w:p w:rsidR="00F3490C" w:rsidRDefault="00F3490C"> <w:pPr> <w:pStyle w:val="Standard"/> </w:pPr> </w:p> <w:sectPr w:rsidR="00F3490C"> <w:pgSz w:w="11906" w:h="16838"/> <w:pgMar w:top="1134" w:right="1134" w:bottom="1134" w:left="1134" w:header="720" w:footer="720" w:gutter="0"/> <w:cols w:space="720"/> </w:sectPr> </w:body> </w:document> Attachment: Complexity.docx Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Svante, I'm preparing for the ODF teleconference but I can quickly answer your question about XPath: On 01/22/2016 02:06 PM, Svante Schubert wrote: > I created a simple example document for an offline discussion with > Patrick about XPath I would like to share. While Patrick is quite > in favor of XPath, I am opposing XPath for the use of referencing > into ODF XML for change-tracking. > > Do not get me wrong, XPath is a great technique, but it was build > for general purpose, arbitrary XML. The proposed referencing model > for change-tracking is only focused on office documents, > abstracting from XML and therefore of advantage. > > One problem of XPath is that its references are not normalized. In > other words, there are multiple ways to reference to the same XML > element. Implementations have to implement all possible cases and > normalize XPath references to become aware that the same XML > element is being pointed to. The same problem applies to ODF XML, > which is neither normlized. The semantic identical document can be > shown in different ways in XML. > Err, no. XPath defines a number of ways to access an element is true, but for change tracking purposes, I would suggest we use only the descendant axis. Which is much the same as your "components." Except that XPath descendant axis doesn't make presumptions about: > AFAIK for the application models of MS Office and LibreOffice the > list level are only properties of the paragraph, so it is for the > component. Written in as references of the new change-tracking > operations > You are incorrect in saying: > Most important we can apply OT easily. By looking only at the > integers we are aware if the operations influence each other. > Whenever an insertion/deletion occurs before or above. If and only if the "application models" are in fact the same for all ODF applications and applied the same way, something that has yet to be shown or defined. Any deviation between application models and your change tracking would fail to support OT and change tracking itself. BTW, no marks for failing to realize that OT is meant to minimize the impact of changes so that the greatest number of changes can be applied without user intervention. Think of it as auto-coordination. If the tree/model doesn't change at all, my immutable suggestion, then we lose the overhead of OT and as now, users choose the changes they wish to accept, or not. I am about to extract the OOXML change tracking part of 25900 and will be posting it as a separate document later this week. Runs about 100 pages or so. Hope you are at the start of a great week! Patrick > Our proposed component model for change-tracking abstracts from > those variations. > > Let me give the ODT document example. > > In the ODF example document there are two letters "A" and "B". How > easy is it for one of you to provide the XPath references to A and > B? > > Let me give a general description of the example document: The > letter "A" has been inserted as part of a paragraph within a > list-item of list level 9. AFAIK for the application models of MS > Office and LibreOffice the list level are only properties of the > paragraph, so it is for the component. Written in as references of > the new change-tracking operations > > A is located at /9/12 > > B is located at /12/2/2/2/2 > > In detail for A: The 9th top level component (paragraph) and the > 12th character NOTE: List items are just paragraph properties. > Similar span are only boilerplate to attach properties to > characters. > > In detail for B: The 12th top level component (table), 2nd row, 2nd > cell, 2nd paragraph and 2nd character > > Most important we can apply OT easily. By looking only at the > integers we are aware if the operations influence each other. > Whenever an insertion/deletion occurs before or above. This > evidence would not be the automatically the case for XPath > references. > > Best thing of all, the same references apply for OOXML, they are > again: > > A is located at /9/12 > > B is located at /12/2/2/2/2 > > Take a look at the DOCX and document.xml created by MS Office 2016. > The mapping from OOXML to component is surely different (so the > XPath), but the high level structure is identical. > > From this example, it seems to me that components imposing far > less a model for change tracking to be used by implementers than > XPath would do. > > What you think? > > Have a nice week-end, Svante > > > > On Fri, Jan 15, 2016 at 10:00 PM, Camilla Boemann <cbo@boemann.dk > < mailto:cbo@boemann.dk >> wrote: > > Hi Patrick > > Because in order to "translate" what such xpath statements would > mean we would have to implement the editing in xml to (if only to > understand the xpath) > > Let me try and illustrate > > We have a basic document: > > <a>< c/></a) > > And two pseudo xpath operations describing accepted changes: Second > to last operation) delete <d/> placed left of <e/> Last operation) > delete <e/> placed left of <c/> > > Now in order for me to translate the last operation) into my > internal representation I would also have to implement how the > second to last operation would produce an xml document (and not > just what it does to my internal representation) If those > operations were expressed in a more generic way not tied to a > specific syntax I would be able to translate it directly into my > internal representation. > > Bottom line is if we go through xpath I would have to implement > all operations on xml format as well as on my internal > representation > > Not quite sure if it makes sense to you? > > >
Original Message----- From: > office-collab@lists.oasis-open.org > < mailto:office-collab@lists.oasis-open.org > > [ mailto:office-collab@lists.oasis-open.org > < mailto:office-collab@lists.oasis-open.org >] On Behalf Of Patrick > Durusau Sent: 15. januar 2016 21:22 To: > office-collab@lists.oasis-open.org > < mailto:office-collab@lists.oasis-open.org > Subject: Re: > [office-collab] Immutable Change Tracking > > Camilla, > > What I fail to understand is the revulsion against XPath? > > Doesn't Calligra in fact import the ODF XML format? > > How is that any different from reading an XPath statement for the > location where insertion of a paragraph should occur? > > That is to say that Calligra is already converting XML into its > internal representation, including in-line change tracking if you > support that now. > > Even if implementers prefer a "component" approach, that is > nothing more than translating XPath statements into a different > vocabulary. > > If I am correct, that components are the equivalents of steps in > an XPath statement, why the opposition to XPath? It may not be as > compact as components and so if we derive a compact representation > that is called components but is in fact a simplified version of > XPath, where the beef? > > Truly I am failing to recognize why serializing changes in the > same format as we use for documents is such an issue? I'm not > expecting anyone to process ODF documents as XML, but to use the > XML representation as an interchange format. Personally I think > that would work for changes as well, whatever applications choose > to call them. > > So, can you help me here? What is the difficulty with XPaths > whether they are called XPath and written in XPath syntax or they > are called components and we have to invent a syntax. > > Thanks! > > Hope you are looking forward to a great weekend! > > Patrick > > PS: To be fair, my misgivings about components are because they > impose a model for change tracking (as does character offset) to > be used by implementers. I would deeply prefer that implementers > have the freedom to choose whatever internal models they choose. > From trees, to tables, to graphs, it makes no difference to me so > long as they serialize to ODF as specified by the standard. > > > > > > On 01/15/2016 02:52 PM, Camilla Boemann wrote: >> Actually I can safely say that if we go with XPath Calligra will >> NOT implement changetracking > > > >> *From:*office-collab@lists.oasis-open.org > < mailto:office-collab@lists.oasis-open.org > >> [ mailto:office-collab@lists.oasis-open.org > < mailto:office-collab@lists.oasis-open.org >] *On Behalf Of *Svante >> Schubert *Sent:* 15. januar 2016 20:47 *To:* Patrick Durusau >> <patrick@durusau.net < mailto:patrick@durusau.net >> *Cc:* > office-collab@lists.oasis-open.org > < mailto:office-collab@lists.oasis-open.org > >> *Subject:* Re: [office-collab] Immutable Change Tracking > > > >> Patrick, > > > >> On Wed, Jan 13, 2016 at 4:27 PM, Patrick Durusau > <patrick@durusau.net < mailto:patrick@durusau.net > >> < mailto:patrick@durusau.net < mailto:patrick@durusau.net >>> >> wrote: > >> Svante, > >> I'm sorry you are missing the call today because I think the >> XPath / no XML model at run time is an important issue to >> discuss. Perhaps we can get started today and over time iron it >> out. > >> I say that because your right, no ODF application is required to >> have an XML model. > >> ODF applications can have any internal model they care to have, >> but, they are required to *read* ODF XML and to *write* ODF XML >> from their purely internal representations. > >> That is to say that the XML file format of ODF *is* the >> abstraction layer that enables many ODF applications to have >> varying internal models . > >>> ODF is indeed a very good abstraction to exchange serialized >>> XML models. > >>> Still there is room for further simplification by doing some >>> *further *abstraction upon the ODF XML to logical objects >>> (components). > > > >>> This has advantages, for instance: > >>> If I say, I will change the 2nd character of the 3rd paragraph, >>> I might apply the change to ODF or OOXML, as they can be >>> addressed similar for this subset. > >>> In the XPath view we are quite lost to see that we are talking >>> of the same logical change and/or the same logical document but >>> in a different XML representation. > > > >>> Not saying that we can map and abstract all ODF & OOXML on >>> this level, but comparison gets easier and how did Einstein >>> said, we should take the easiest solution that works, but >>> nothing easier.. > > > > > >> So, my choice of XPath was very intentional because it too is an >> abstract representation of the change, against the abstraction >> that the ODF application has already read into its internal >> structure. > >> The same process of reading the ODF document would be applied to >> reading the change into the internal representation of the ODF >> application. > >>> XPath is very powerful, but it has many feature we do not >>> need. Also does it depend on an XML that does not exist at >>> run-time, but the positions have to exist and handled during >>> run-time, as whenever something is inserted ahead (or above) >>> the position is increased (or decreased when its being >>> deleted), positions have to be updated. Much harder to evaluate >>> and adopt these with XPath. > >>> XML and XPath are wonderful technologies, but these are not >>> the hammers we are looking for... > > > > > >> Likewise, when an ODF application serializes changes, however it >> stores them internally, it serializes them against the immutable >> XML ODF file which it read when it loaded the file. > >> The abstraction of XPath to "logical identities" maybe how many >> ODF applications choose to go from the XPath representation to >> their internal model but that's an application's choice and I >> would prefer that we not dictate to applications their >> abstractions. > >> Using XML for both the file format and changes allows ODF to >> remain above the choices made by ODF applications. > >>> Again, I am curious if any ODF application develop would like >>> to use XPath. At least nobody at Open-XChange was interested in >>> it and was happy on doing an abstraction. Perhaps because they >>> not only imported ODF, but as well OOXML, which is quite common >>> for office applications and they wanted to use the same >>> mechanism for both formats. > >>> Because when the office XML is being abstracted to logical >>> objects - I usually call components - the referencing is are >>> very similar for both formats and a lot can be reused. > >>> Try to map the position of a character within a paragraph of >>> ODF to OOXML.. To me it was a nightmare.. > > > >>> Aside of my love to XPath, I do not see any use here... > >>> I suggest we are not using this hammer, for this time, but >>> wait for a nail instead.. > > > >>> Regards, > >>> Svante > > > >> Hope everyone is having a great day! > >> Patrick > > > > > >> On 01/13/2016 06:55 AM, Svante Schubert wrote: >>> The immutable change-tracking is indeed very useful for the >>> scenario of commenting and editing a signed document. In this >>> scenario the XML can not be changed, as otherwise the sign >>> would be broken. Every comment/edit would be saved aside the >>> signed content XML and might be signed again for each author, >>> ensuring the validity of the complete content. > >>> That the changes will in the future refer to the position of >>> change into the content instead of embedding it as prior we >>> agree on. XPath is just a possible choice of implementation >>> for referencing. From my observation Patrick's ideas are not >>> based on XPath, he just took it as example. I rather would >>> avoid XPath as ODF application do not require to have an XML >>> model representation at run time, in contrary to the file model >>> related DOM run-time API of browsers. In addition ODF XML has >>> no normalized representation, which make XML references more >>> difficult. Therefore the abstraction from XML to logical >>> identities, which are known to users and referencing to those >>> will be easier to handle by general run-time model related to >>> ODF and works well for applications without ODF XML awareness >>> even at run-time. > >>> I have experienced this in my work on a browser based office >>> with Open-XChange in the past years. For example, the >>> reference of the 3rd character within the 2nd paragraph might >>> be written as /2/3 which can be seen as a simplification of >>> XPath and was handled by the browser office I have been working >>> with as simple integer array, making things easy for the office >>> at run-time. > >>> Kind regards, Svante > >>> On Jan 8, 2016 9:58 PM, "Patrick Durusau" <patrick@durusau.net > < mailto:patrick@durusau.net > >> < mailto:patrick@durusau.net < mailto:patrick@durusau.net >> > >>> < mailto:patrick@durusau.net < mailto:patrick@durusau.net > > < mailto:patrick@durusau.net < mailto:patrick@durusau.net >>>> >>> 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. > >>> Hope everyone is at the start of a great weekend! > >>> Patrick > > > >>> -------------------------------------------------------------------- - - > >>> >>> > >> 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.p h > >>> p > < https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.ph > > p> > >>> > > > > > > > --------------------------------------------------------------------- > > 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 > > > > > --------------------------------------------------------------------- > > 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 iQIcBAEBAgAGBQJWpg+jAAoJEFPGsgi3MgycHFwQALD9OFUgnfGMvtvykWC/sAk2 F4lJKAeXJa6x7jsqFosISbWrqyKFNs4c3U5dABdF3WPXKfXsKQDqXnd3zfPVGIYG KYaRABSowtIdhHm4H/aVESYRloQAPVGKLTEvLmHw0331wYldOaPSqAj9Pxc7XfoB ZBXrMyQ5c28tPjDkwr0qGX6O93GgcM53jlyAmauCA9vcj5F9JP4mWsW5XjiE3V0R LWDsJ67g7iCyQt68vRHw7BoTqOAcm8wFVCBcUveaJijqcM6q2e78qnvkU21AyC2h sW6OQGrXd//oZXPeFHYEJS/FPAl6gZnDTPx+wzN5NhBOfidjwIWT0KwQWtriQKuQ ZI3Q9EWVGG4Od1gNcd6XZyJK301y1RU6ekut3siSkM/SgqafXiaknjPr+Xi7U4uE y4JkGUzN7bOL6HGoYyzwAx19x+6wVvG7957KWKDkux2cZ/a3irNmsaOxsm0QOvlX ymunqlJ9MlydXJVh/EsoKnjTstTGtMSrB9ObLrkHwbbmMphbg5SPTD0+RxflNq1w 81c4eFD6V2Nx85DPGDWcfckrxJxlWzC/B+aecOY6r6J2XEqUkgs088jqu6fRn9UM x/huM/rSuk8ZnOLY2fdkYvsgb/sjphFGr1Hqt4n75y2stoO/docAWP31A7Sy5EIY 1i5b0VcWNkPbaV+YF9z7 =MpQ9 -----END PGP SIGNATURE-----

Hi Everyone! As some of you already know our company is working on an implementation of the MCT change tracking proposal. Now we have a question to ask, and maybe also discuss it during the next SC call. According to Svante's original proposal, the changes are exported as a list of UNDO operations that can be easily undone in the document if an author decides so. However, as our experiences with the implementation showed, the UNDO operations are not very helpful when it comes to merge documents or to collaborative document editing. Let me explain this by a simple example. Lets say a collaborator adds a sentence "Hello world!" in the first paragraph of a document. Then the undo operation reads as: <del type=”text” s="/1/1" e="/1/11" /> The problem is that when merging this change to our document, we would not know what was inserted between positions "s" and "e", unless we open his/her version of the edited document. Thus, it might be more useful to export not the UNDO operations, but the DO (or REDO) operations instead. What do you think Svante? best regards, Peter MultiRáció Kft. Tel: (+36-1) 372-2500 / 6517 E-mail: rakyta.peter@multiracio.hu Web: itl88.elte.hu/~rakytap On 01/15/2016 08:47 PM, Svante Schubert wrote: > Patrick, > > On Wed, Jan 13, 2016 at 4:27 PM, Patrick Durusau <patrick@durusau.net < mailto:patrick@durusau.net >> wrote: > > Svante, > > I'm sorry you are missing the call today because I think the XPath / > no XML model at run time is an important issue to discuss. Perhaps we > can get started today and over time iron it out. > > I say that because your right, no ODF application is required to have > an XML model. > > ODF applications can have any internal model they care to have, but, > they are required to *read* ODF XML and to *write* ODF XML from their > purely internal representations. > > That is to say that the XML file format of ODF *is* the abstraction > layer that enables many ODF applications to have varying internal models > . > >> ODF is indeed a very good abstraction to exchange serialized XML models. >> Still there is room for further simplification by doing some *further *abstraction upon the ODF XML to logical objects (components). > >> This has advantages, for instance: >> If I say, I will change the 2nd character of the 3rd paragraph, I might apply the change to ODF or OOXML, as they can be addressed similar for this >> subset. >> In the XPath view we are quite lost to see that we are talking of the same logical change and/or the same logical document but in a different XML >> representation. > >> Not saying that we can map and abstract all ODF & OOXML on this level, but comparison gets easier and how did Einstein said, we should take the >> easiest solution that works, but nothing easier.. > > > > So, my choice of XPath was very intentional because it too is an > abstract representation of the change, against the abstraction that > the ODF application has already read into its internal structure. > > The same process of reading the ODF document would be applied to > reading the change into the internal representation of the ODF > application. > >> XPath is very powerful, but it has many feature we do not need. Also does it depend on an XML that does not exist at run-time, but the positions have >> to exist and handled during run-time, as whenever something is inserted ahead (or above) the position is increased (or decreased when its being >> deleted), positions have to be updated. Much harder to evaluate and adopt these with XPath. >> XML and XPath are wonderful technologies, but these are not the hammers we are looking for... > > > > Likewise, when an ODF application serializes changes, however it > stores them internally, it serializes them against the immutable XML > ODF file which it read when it loaded the file. > > The abstraction of XPath to "logical identities" maybe how many ODF > applications choose to go from the XPath representation to their > internal model but that's an application's choice and I would prefer > that we not dictate to applications their abstractions. > > Using XML for both the file format and changes allows ODF to remain > above the choices made by ODF applications. > >> Again, I am curious if any ODF application develop would like to use XPath. At least nobody at Open-XChange was interested in it and was happy on >> doing an abstraction. Perhaps because they not only imported ODF, but as well OOXML, which is quite common for office applications and they wanted to >> use the same mechanism for both formats. >> Because when the office XML is being abstracted to logical objects - I usually call components - the referencing is are very similar for both formats >> and a lot can be reused. >> Try to map the position of a character within a paragraph of ODF to OOXML.. To me it was a nightmare.. > >> Aside of my love to XPath, I do not see any use here... >> I suggest we are not using this hammer, for this time, but wait for a nail instead.. > >> Regards, >> Svante > > > Hope everyone is having a great day! > > Patrick > > > > > On 01/13/2016 06:55 AM, Svante Schubert wrote: >> The immutable change-tracking is indeed very useful for the >> scenario of commenting and editing a signed document. In this >> scenario the XML can not be changed, as otherwise the sign would be >> broken. Every comment/edit would be saved aside the signed content >> XML and might be signed again for each author, ensuring the >> validity of the complete content. > >> That the changes will in the future refer to the position of change >> into the content instead of embedding it as prior we agree on. >> XPath is just a possible choice of implementation for referencing. >> From my observation Patrick's ideas are not based on XPath, he just >> took it as example. I rather would avoid XPath as ODF application >> do not require to have an XML model representation at run time, in >> contrary to the file model related DOM run-time API of browsers. In >> addition ODF XML has no normalized representation, which make XML >> references more difficult. Therefore the abstraction from XML to >> logical identities, which are known to users and referencing to >> those will be easier to handle by general run-time model related to >> ODF and works well for applications without ODF XML awareness even >> at run-time. > >> I have experienced this in my work on a browser based office with >> Open-XChange in the past years. For example, the reference of the >> 3rd character within the 2nd paragraph might be written as /2/3 >> which can be seen as a simplification of XPath and was handled by >> the browser office I have been working with as simple integer >> array, making things easy for the office at run-time. > >> Kind regards, Svante > >> On Jan 8, 2016 9:58 PM, "Patrick Durusau" <patrick@durusau.net < mailto:patrick@durusau.net > >> < mailto:patrick@durusau.net < mailto:patrick@durusau.net >>> 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. > >> Hope everyone is at the start of a great weekend! > >> Patrick > > >> --------------------------------------------------------------------- > > > 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 > > > >

Hello Peter, Not an easy question, please find my comments below.. On Mon, Jan 18, 2016 at 1:38 PM, Dr. Peter Rakyta < rakyta.peter@multiracio.hu > wrote: Hi Everyone! As some of you already know our company is working on an implementation of the MCT change tracking proposal. Now we have a question to ask, and maybe also discuss it during the next SC call. According to Svante's original proposal, the changes are exported as a list of UNDO operations that can be easily undone in the document if an author decides so.   However, as our experiences with the implementation showed, the UNDO operations are not very helpful when it comes to merge documents or to collaborative document editing. Let me explain this by a simple example. Lets say a collaborator adds a sentence "Hello world!" in the first paragraph of a document. Then the undo operation reads as: <del type=”text” s="/1/1" e="/1/11" /> The problem is that when merging this change to our document, we would not know what was inserted between positions "s" and "e", unless we open his/her version of the edited document. Thus, it might be more useful to export not the UNDO operations, but the DO (or REDO) operations instead. What do you think Svante? We should be aware that we are talking of two different use cases, with two different requirements. (Real-time) Collaboration requires the new changes made to the document Change-Tracking requires the changes to be able to restore the document to its previous state For example, if someone changes the background color of a paragraph from green to red, it is sufficient for  (Real-time) Collaboration to dispatch the change to red Change-tracking to save the change back to green In addition we should keep in mind, that most office software are about two decades old and its not easy for their developers to adopt new concepts. We should be humble with our suggestions. Changing the before XML state within the ODF XML to an ODF operation being able to restore the previous state might be all we can hope for. For similar reasons we need to keep a certain compatibility to past applications. Current ODF applications are loading the final state of document as XML. Even ODF applications without the change-tracking feature are therefor able to load the latest document state.  I doubt that we should change this behavior. Still we might want to suggest the forward change-tracking for the special case of high value signed documents. Currently it is possible that some "evil user" is disabling the change-tracking part time during the editing. With the new approach having a signed original and the user changes are being stored separated (forward not backward changes) this problem will no longer exist. The downside an application without this feature would not be able to show the changes, but there is always a price to pay.. Still it is up to the implementors to offer such features to their customers, we can not demand it.   This might not fully answer your question, but might narrow the answer. Best regards, Svante best regards, Peter MultiRáció Kft. Tel: (+36-1) 372-2500 / 6517 E-mail: rakyta.peter@multiracio.hu Web: itl88.elte.hu/~rakytap On 01/15/2016 08:47 PM, Svante Schubert wrote: > Patrick, > > On Wed, Jan 13, 2016 at 4:27 PM, Patrick Durusau < patrick@durusau.net <mailto: patrick@durusau.net >> wrote: > > Svante, > > I'm sorry you are missing the call today because I think the XPath / > no XML model at run time is an important issue to discuss. Perhaps we > can get started today and over time iron it out. > > I say that because your right, no ODF application is required to have > an XML model. > > ODF applications can have any internal model they care to have, but, > they are required to *read* ODF XML and to *write* ODF XML from their > purely internal representations. > > That is to say that the XML file format of ODF *is* the abstraction > layer that enables many ODF applications to have varying internal models > . > >> ODF is indeed a very good abstraction to exchange serialized XML models. >> Still there is room for further simplification by doing some *further *abstraction upon the ODF XML to logical objects (components). > >> This has advantages, for instance: >> If I say, I will change the 2nd character of the 3rd paragraph, I might apply the change to ODF or OOXML, as they can be addressed similar for this >> subset. >> In the XPath view we are quite lost to see that we are talking of the same logical change and/or the same logical document but in a different XML >> representation. > >> Not saying that we can map and abstract all ODF & OOXML on this level, but comparison gets easier and how did Einstein said, we should take the >> easiest solution that works, but nothing easier.. > > > > So, my choice of XPath was very intentional because it too is an > abstract representation of the change, against the abstraction that > the ODF application has already read into its internal structure. > > The same process of reading the ODF document would be applied to > reading the change into the internal representation of the ODF > application. > >> XPath is very powerful, but it has many feature we do not need. Also does it depend on an XML that does not exist at run-time, but the positions have >> to exist and handled during run-time, as whenever something is inserted ahead (or above) the position is increased (or decreased when its being >> deleted), positions have to be updated. Much harder to evaluate and adopt these with XPath. >> XML and XPath are wonderful technologies, but these are not the hammers we are looking for... > > > > Likewise, when an ODF application serializes changes, however it > stores them internally, it serializes them against the immutable XML > ODF file which it read when it loaded the file. > > The abstraction of XPath to "logical identities" maybe how many ODF > applications choose to go from the XPath representation to their > internal model but that's an application's choice and I would prefer > that we not dictate to applications their abstractions. > > Using XML for both the file format and changes allows ODF to remain > above the choices made by ODF applications. > >> Again, I am curious if any ODF application develop would like to use XPath. At least nobody at Open-XChange was interested in it and was happy on >> doing an abstraction. Perhaps because they not only imported ODF, but as well OOXML, which is quite common for office applications and they wanted to >> use the same mechanism for both formats. >> Because when the office XML is being abstracted to logical objects - I usually call components - the referencing is are very similar for both formats >> and a lot can be reused. >> Try to map the position of a character within a paragraph of ODF to OOXML..  To me it was a nightmare.. > >> Aside of my love to XPath, I do not see any use here... >> I suggest we are not using this hammer, for this time, but wait for a nail instead.. > >> Regards, >> Svante > > > Hope everyone is having a great day! > > Patrick > > > > > On 01/13/2016 06:55 AM, Svante Schubert wrote: >> The immutable change-tracking is indeed very useful for the >> scenario of commenting and editing a signed document. In this >> scenario the XML can not be changed, as otherwise the sign would be >> broken. Every comment/edit would be saved aside the signed content >> XML and might be signed again for each author, ensuring the >> validity of the complete content. > >> That the changes will in the future refer to the position of change >> into the content instead of embedding it as prior we agree on. >> XPath is just a possible choice of implementation for referencing. >> From my observation Patrick's ideas are not based on XPath, he just >> took it as example. I rather would avoid XPath as ODF application >> do not require to have an XML model representation at run time, in >> contrary to the file model related DOM run-time API of browsers. In >> addition ODF XML has no normalized representation, which make XML >> references more difficult. Therefore the abstraction from XML to >> logical identities, which are known to users and referencing to >> those will be easier to handle by general run-time model related to >> ODF and works well for applications without ODF XML awareness even >> at run-time. > >> I have experienced this in my work on a browser based office with >> Open-XChange in the past years. For example, the reference of the >> 3rd character within the 2nd paragraph might be written as /2/3 >> which can be seen as a simplification of XPath and was handled by >> the browser office I have been working with as simple integer >> array, making things easy for the office at run-time. > >> Kind regards, Svante > >> On Jan 8, 2016 9:58 PM, "Patrick Durusau" < patrick@durusau.net <mailto: patrick@durusau.net > >> <mailto: patrick@durusau.net <mailto: patrick@durusau.net >>> 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. > >> Hope everyone is at the start of a great weekend! > >> Patrick > > >> --------------------------------------------------------------------- > > > 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 > > > > --------------------------------------------------------------------- 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