OpenDocument - Adv Document Collab SC

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings! I was thinking about change tracking while working in Carol's garden this morning. ;-) Is there a similarity to the shortest path problem in graphs? That is for some change X, the first question I have to answer is: Is that a valid path expression for the state of the document as I know it? If not, then I have to go backwards through changes until I find a point where the path expression is valid. Thinking of Oliver's case where someone deletes the "third" paragraph while I have made a change to what I know as the "fourth" paragraph. The deletion (assuming only 4 paragraphs) throws off my path expression to the 4th paragraph. But I should already know the other changes, in order. Yes? All of which is to say I think we need some simplifying assumptions about change tracking for collaboration: For collaboration change tracking (asynchronous change tracking), the collaboration attribute (new attribute) is set to true. The state of the document attribute (new attribute) has a hash value for the document that represents its state at the time the collaboration attribute has been set to true. Once set to true, the collaboration attribute cannot be changed to false. That is all changes we track are tracked from that point. Non-collaboration change tracking is also tracked by operations but can be turned on and off. It puts a greater burden on collaboration change tracking applications but then they are asking for a greater feature and should bear the cost of using it. Non-collaboration change tracking uses the same operations mechanism but isn't troubled by coordination with others. Does that help? Hope everyone is having a great week! Patrick - -- Patrick Durusau patrick@durusau.net Technical Advisory Board, OASIS (TAB) Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSFNU+AAoJEAudyeI2QFGo64UQAMEJTfnUpl6E9rMgr8dkbB4F 7G16X/ocNR1tt1ZKUaBB8LGTWFzAT3LjOdQzRw6Lc9pH/ZS9JFF4jR5C77B8Giab KMSe6plBo7bdj/lBplNVnRMniLTi8jQpKXRsgm8h5yXNQT4EFpb+AEyXPXp+7w/t 9zzU2TZ58m0lss9KwFU1yW1k3zqYsC8sAMq+517V+sJ8I8v4YozpEGsAD7PbZcNp oZ/Tv9oRJcMRv8IHTcWRaVUI0cI02+phRYNPPC3nQu/EYE6ZWCcVEBSogyzaxTRv V1kL2GruH+qbDw4+0rI5VDJOT0lpCGkEswN7pi5hORB9Jp09og2XWU8K1GMbWAJb gc3teMpxAtL2V28WV1po6dd1XTb0R2XPGUg3Sv+uKyHAQnV/wdZz0K4QHwLJakQV lMbpYCFHhJXue+UVrRVTvZ9z6hxXmYU8BhNgs+MhG/kgumFnZfo9rFLySBkPJZWV IhsWVIGpScq18kdMCgvI8O30BzUWTSZvYWTdelZwtfYUBKLz2R57/B1j/F+foBpz P6EX65a0Zs0LqM6OpeaO2qtuwhz35NE+bc1I3mEAgjtSY6aZ4xkRpKtSiTUtLEJ6 WYGq18gqPe+tx8q1Z8YEokJ3MH8tZ4lbON+JwNEpxNYdzd13PvrGji2COoQeB9o6 ja2g7I2GyLmE4qJtsGLg =SMQn -----END PGP SIGNATURE-----

Interesting view. I believe you raised some interesting points, although I do have a different view on validation. I would follow the optimistic approach. In the following I will compare the valid/well-formed problem of operations with the one with ODF XML.. Am 21.08.2013 16:57, schrieb Patrick Durusau: Greetings! I was thinking about change tracking while working in Carol's garden this morning. ;-) Is there a similarity to the shortest path problem in graphs? That is for some change X, the first question I have to answer is: Is that a valid path _expression_ for the state of the document as I know it? You might take the optimistic approach and assume it is valid, similar as we assume that XML is valid/well-formed. If not, then I have to go backwards through changes until I find a point where the path _expression_ is valid. I am uncertain if we have a guaranteed way to fix it, similar as we do not have if we have not valid/well-formed XML. We might have heuristics, but not a fool proof way to guarantee to fix every problem that might occur. Thinking of Oliver's case where someone deletes the third paragraph while I have made a change to what I know as the fourth paragraph. The deletion (assuming only 4 paragraphs) throws off my path _expression_ to the 4th paragraph. The position argument of an operation is related to the position at the time the operation was triggered. Imagine you want to add text to the fourth paragraph and afterwards Oliver wants to delete the third paragraph. Olivers operation would be added. If the sequence would be executed as western writing top down, it would read like: 'add text /4/1 hello World ' 'delete paragraph /3' BUT if you now want to change the order of the above two operations. As you want to let the deletion of the paragraph happen before of the text insertion, the parameter would be adapted due to OT. The former 4th paragraph would fill the gap of the deleted third and would itself become the third: 'delete paragraph /3' 'add text /3/1 hello World '   But I should already know the other changes, in order. Yes? Does above the text answer your question? All of which is to say I think we need some simplifying assumptions about change tracking for collaboration: For collaboration change tracking (asynchronous change tracking), the collaboration attribute (new attribute) is set to true. The state of the document attribute (new attribute) has a hash value for the document that represents its state at the time the collaboration attribute has been set to true. Once set to true, the collaboration attribute cannot be changed to false. That is all changes we track are tracked from that point. Non-collaboration change tracking is also tracked by operations but can be turned on and off. It puts a greater burden on collaboration change tracking applications but then they are asking for a greater feature and should bear the cost of using it. Non-collaboration change tracking uses the same operations mechanism but isn't troubled by coordination with others. Does that help? The problem is that if we load and save ODF XML with two applications, we would likely have different XML and different signature. We can have normalized operations as well, like those compressed operations of a document that would be triggered when reading a document (no redundancy, e.g. no delete & in document order). Nevertheless we need to have common starting points that we would identify via signatures. Like we have to be certain that we all started from the same template document. Best regards, Svante Hope everyone is having a great week! 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 >