OpenDocument - Adv Document Collab SC

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings! While thinking about collaboration/change tracking this morning, it occurred to me that there are several aspects yet to be discussed. For example, what elements do we need to designate who changes will be sent to and how? Thinking such elements could designate a receiver of changes but at the same time, disallow changes from a particular receiver. The use case being that I want to make changes to a document that are reflected in distributed drafts but don't want to accept changes from any of the distributed copies. [A management scenario but management does use word processors. ;-) ] There should also be an element that controls the processing of changes from particular sources, say limiting changes to comments and comments upon comments and not any changes to the base text. The use case being standards drafts for example, where notes on particular parts of the text as well as notes on notes would be quite acceptable. Whereas changes to the base text would not be. Thinking the receiver's list should be separate items (a list?) with attributes to control the aspects of collaboration/change tracking I have listed above. Should we leave communication protocols up to applications? Hope everyone is having a great week! Patrick - -- Patrick Durusau patrick@durusau.net Technical Advisory Board, OASIS (TAB) Co-Chair, OpenDocument Format TC (OASIS) Editor, OpenDocument Format TC, Project Editor ISO/IEC 26300 Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Co-Editor, ISO 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) iQIcBAEBAgAGBQJUEcQhAAoJEAudyeI2QFGoQ50QAN5VE1bmGNzAIu5QCDQMLAK0 xhMoc9vziF2lTQXSieKJ5iI5Y00gSUvnUhNYgY8rg3iD7WbELjY2Mndm3h4GHZpd +rY9GnVoEiM5lTie5bx9XuIkdkPzNVJ/r0z8IQ/HjCw9X8DKrBek23L/nyO3zJ5k UJ/Z6x60YttFp4xNS9cO+y4Wm2T9TjCyxcgsVql5MiWFl/N5+1hIQMLplrwyzkxU SHENHmlKmuAV+KLVBLXsWK3Gjr8Mu+7SqSXy2BmYQw7QcvspkcYlYj+yOzaffKmg B18Fh47AAxgcmNjngpVjxGCKR9ADxgAf3JzOVnZB+h0FA/KlHTZcm0qiIZURq5aZ nF+bk4VZoXuinvZHerR3T0ZeURl602SlotKAhblRFrA226jBBmsRK7JDY4jRF9gI rkIjr/h7hGi7+wpb6Qeh3xM1rBkl95R4xbkT3HeCZ93F4eC0Nrbs8r+PkLYOil/P aqsVRE6DzSFP/SdvDHkcFLXPHHl3C8FJU7sZWfcyvMRZCFmqXiSaUZ7N2+Rc8vJ1 bh+VUBrbvYTRtUoRey7HTpHm+s/Ibu7IfGpkV2uXIPkecmZJYXAyqk/UNxgRj2Qa zCRKNI095kyXOgopbA0NL745JFgCsNHEpEmS9ulbK6thtoOzDj8uoEidNGcJDgBC ZG9Sx31SlGbcsEUQ5Vvu =5Z62 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hej everyone, Am 11/09/14 um 09:47 schrieb Patrick Durusau: > Greetings! > > While thinking about collaboration/change tracking this morning, it > occurred to me that there are several aspects yet to be discussed. > > For example, what elements do we need to designate who changes will be > sent to and how? > As a rule of thumb the XML root element of a subtree that is being inserted upon a common user interaction. Some are already mentioned in our current draft. Might be a good topic to start with on our next SC call. > Thinking such elements could designate a receiver of changes but at > the same time, disallow changes from a particular receiver. > > The use case being that I want to make changes to a document that are > reflected in distributed drafts but don't want to accept changes from > any of the distributed copies. [A management scenario but management > does use word processors. ;-) ] > > There should also be an element that controls the processing of > changes from particular sources, say limiting changes to comments and > comments upon comments and not any changes to the base text. > If the applications are keen to implement such a feature, we might be keen specifying it ;) Got a slight feeling here that this feature is out-of-scope as no additional interoperablilty will be offered. Again some topic we should put on next call agenda. > The use case being standards drafts for example, where notes on > particular parts of the text as well as notes on notes would be quite > acceptable. Whereas changes to the base text would not be. > > Thinking the receiver's list should be separate items (a list?) with > attributes to control the aspects of collaboration/change tracking I > have listed above. Indeed. Still the applications have to implement it first or have to suggest it and of course first the basic features have to be fully covered. One step after the other. > > Should we leave communication protocols up to applications? > We could perhaps in the future, at the moment we might want to focus on the existing change-tracking support to specify via operations. In addition it is even easier to discuss protocols if there are more applications around working on this. We need to get online app vendors into ODF. The application group that should be most interested in collaboration based on dispatching changes. Interesting thoughts you brought up, Patrick. > Hope everyone is having a great week! Same here, greetings from a StarBucks Denver, Co, Svante -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUFaoKAAoJENkVprAHZ0k7pRUIAJfdCpUpVA/Mo3KSVRcnutox pzEeCC7VMMa0YLyptc5c1aHh014BFh7HBHJ8UF0yjpdfEZS7dDlK21vvAvLsunwL Wk9odyzysZ1XvN5KgP6GKIvOM2Z29YPwT68X8dqIrgaepuPswvChwN7bLdHzJZdC KO/bUgXK8vKP06Ty7s3ZO9rKgOHJABV3nyscqg9HvCeMyWzGOm8I9TfAIphdw5cl 4SdIOZE001+M4JLk8sAZ6F2KftsULjojRyNkLlfFE+4HMK6EsUBrh0rMjXwmkIPH s6ip8X1NuNTYgrmTww6z+kvy3UKlAh2OcJHrG/3pTmS50MzhKJTy7GblAmZSi0E= =MZwT -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Svante, Err, I'm not sure how there can be collaboration, even with OT without communicating transformations to other applications editing the same document. Yes? My concern as an editor is what does an application have to write out when it records pending changes and at the same time, what must it communicate to others in a collaboration context. (I am assuming that "accepted" changes are no long available to be changed, at least without editing the same text, again. That may not be a good assumption so please correct if it is wrong.) Hope you are having a great weekend! Patrick On 09/14/2014 10:45 AM, Svante Schubert wrote: > > Hej everyone, > > Am 11/09/14 um 09:47 schrieb Patrick Durusau: >> Greetings! > >> While thinking about collaboration/change tracking this morning, >> it occurred to me that there are several aspects yet to be >> discussed. > >> For example, what elements do we need to designate who changes >> will be sent to and how? > > As a rule of thumb the XML root element of a subtree that is being > inserted upon a common user interaction. Some are already mentioned > in our current draft. Might be a good topic to start with on our > next SC call. >> Thinking such elements could designate a receiver of changes but >> at the same time, disallow changes from a particular receiver. > >> The use case being that I want to make changes to a document that >> are reflected in distributed drafts but don't want to accept >> changes from any of the distributed copies. [A management >> scenario but management does use word processors. ;-) ] > >> There should also be an element that controls the processing of >> changes from particular sources, say limiting changes to comments >> and comments upon comments and not any changes to the base text. > > If the applications are keen to implement such a feature, we might > be keen specifying it ;) Got a slight feeling here that this > feature is out-of-scope as no additional interoperablilty will be > offered. Again some topic we should put on next call agenda. >> The use case being standards drafts for example, where notes on >> particular parts of the text as well as notes on notes would be >> quite acceptable. Whereas changes to the base text would not be. > >> Thinking the receiver's list should be separate items (a list?) >> with attributes to control the aspects of collaboration/change >> tracking I have listed above. > Indeed. Still the applications have to implement it first or have > to suggest it and of course first the basic features have to be > fully covered. One step after the other. > >> Should we leave communication protocols up to applications? > > We could perhaps in the future, at the moment we might want to > focus on the existing change-tracking support to specify via > operations. In addition it is even easier to discuss protocols if > there are more applications around working on this. We need to get > online app vendors into ODF. The application group that should be > most interested in collaboration based on dispatching changes. > > Interesting thoughts you brought up, Patrick. >> Hope everyone is having a great week! > Same here, greetings from a StarBucks Denver, Co, Svante > - -- Patrick Durusau patrick@durusau.net Technical Advisory Board, OASIS (TAB) Co-Chair, OpenDocument Format TC (OASIS) Editor, OpenDocument Format TC, Project Editor ISO/IEC 26300 Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Co-Editor, ISO 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) iQIcBAEBAgAGBQJUFav/AAoJEAudyeI2QFGohYYQAOJBftbb6APiDWv3nKWF2gEB pczoqvKK7CyrX3liKWlD/RenDdotMbE6XVGc9BhiI5ZcUd87Nx+q/jaKkauVM8Wm gJe5l6zKxCfXBcBQvPeZ9dHsoJK8Kvq0FLnIEavD3axUTK+LyUSgp4oKX2Jd6P0g 9NfKQZj0Z2P7iHyd9EcDCPXUKkr2dlOLGEG9nufVxAiOnre+lFNcRJF9JGqd9gY2 Tje3oLlcxr/1pxTnA2ihCnpBMMPbrSgW/a4GuLu9edX4YVnX9JnX6Zl15ImaQgCm cb8XE3Adun0OiubPzSlayxvQqouPvwX4ikJ1hgZ63Bt0yn5cArOwDWwF2qGzAZlN VKhS0KXFrr5j0FjckmFbwQ+Pj7TuoW6nv/13+e6D22/erG/ab0Ha9PyigUwcJ4Zp IAIeNeIKDPG4XPYikYsjd08GNR2QrRW2TYd2gKAsb7b/xpsZHBZY5tB5q08zKZJh Dd8iYc7qDaiRbnKYkoZ6rtgAYFRJpfmJelAVSx6aLSd/cpaLv2K6V3ZG/19lDU73 ihjfSa+Dd2cvQ2/jZZ7NqrYxc+m3Qjv2Pey06TBHwONvZWWU1we9iL7cRWOU9DfF b7kfeX3dPYewPjzCCOgokD7bOa4mfMEheqe6fMOnAOcRK7wm/XOnWIKlVolysQ90 uFmmXs8SRJbfNjk6gmqm =y22j -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Patrick, Am 14/09/14 um 08:53 schrieb Patrick Durusau: > Svante, > > Err, I'm not sure how there can be collaboration, even with OT without > communicating transformations to other applications editing the same > document. > > Yes? The collaboration occurs by exchanging the full document. Within the document is a list of changes, defined by operations undoing the previous actions of users. In analoge to the previous ODF 1.0-1.2 before after XML of a change, such a change is now defined by one or more operations of an user. > > My concern as an editor is what does an application have to write out > when it records pending changes and at the same time, what must it > communicate to others in a collaboration context. > The list of operations listing the tracked changes. A change is defined by one or more operations providing information to undo a change. > (I am assuming that accepted changes are no long available to be > changed, at least without editing the same text, again. That may not > be a good assumption so please correct if it is wrong.) > As previously accepted and rejected changes will no longer be saved in the document. > Hope you are having a great weekend! > I will try my best. Nice weather, a rental car and a full tank. Will do a trip into the Rocky Mountains before the conference. Hope you are having a great week-end as well! Svante > > On 09/14/2014 10:45 AM, Svante Schubert wrote: > > > Hej everyone, > > > Am 11/09/14 um 09:47 schrieb Patrick Durusau: > >> Greetings! > > >> While thinking about collaboration/change tracking this morning, > >> it occurred to me that there are several aspects yet to be > >> discussed. > > >> For example, what elements do we need to designate who changes > >> will be sent to and how? > > > As a rule of thumb the XML root element of a subtree that is being > > inserted upon a common user interaction. Some are already mentioned > > in our current draft. Might be a good topic to start with on our > > next SC call. > >> Thinking such elements could designate a receiver of changes but > >> at the same time, disallow changes from a particular receiver. > > >> The use case being that I want to make changes to a document that > >> are reflected in distributed drafts but don't want to accept > >> changes from any of the distributed copies. [A management > >> scenario but management does use word processors. ;-) ] > > >> There should also be an element that controls the processing of > >> changes from particular sources, say limiting changes to comments > >> and comments upon comments and not any changes to the base text. > > > If the applications are keen to implement such a feature, we might > > be keen specifying it ;) Got a slight feeling here that this > > feature is out-of-scope as no additional interoperablilty will be > > offered. Again some topic we should put on next call agenda. > >> The use case being standards drafts for example, where notes on > >> particular parts of the text as well as notes on notes would be > >> quite acceptable. Whereas changes to the base text would not be. > > >> Thinking the receiver's list should be separate items (a list?) > >> with attributes to control the aspects of collaboration/change > >> tracking I have listed above. > > Indeed. Still the applications have to implement it first or have > > to suggest it and of course first the basic features have to be > > fully covered. One step after the other. > > >> Should we leave communication protocols up to applications? > > > We could perhaps in the future, at the moment we might want to > > focus on the existing change-tracking support to specify via > > operations. In addition it is even easier to discuss protocols if > > there are more applications around working on this. We need to get > > online app vendors into ODF. The application group that should be > > most interested in collaboration based on dispatching changes. > > > Interesting thoughts you brought up, Patrick. > >> Hope everyone is having a great week! > > Same here, greetings from a StarBucks Denver, Co, Svante > > > > --------------------------------------------------------------------- > 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 SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUFcH/AAoJENkVprAHZ0k7tbsH/jE3WD1UdpkLytJAylpQr+oa gmMKMEXGHgqtYxgyK/qK0gVsgDkF8hfX/p9i1REr2UCmi6Q9r7NnhWHkQ8yLRlcR bM8o/Zipc2Rtg6nQ4Hw7LYPE1pa/fT0AtSCQ1IB6JwvA8Y/sldJXNrIby7qfwb6Y ncVFF8r1ayo+xTbvjY6qsX1YhXTAUVrqiBN04JMb+uvzntHGGht2Gb/NSiEalQyM O20jPgdqyi10OSQh1kRtsU35TCRG1cRxXp9darsz2Ry7jcnmZeip4JQerFYVpEjF bcbuPyr53n7QZi0uyOS1AgiBQRDDporKV0ommIPZZsqXUYbtzZDf0+eX4yvTilU= =99Gx -----END PGP SIGNATURE-----

On 14-09-14 10:27 AM, Svante Schubert wrote: Am 14/09/14 um 08:53 schrieb Patrick Durusau: > Svante, > > Err, I'm not sure how there can be collaboration, even with OT without > communicating transformations to other applications editing the same > document. > > Yes? The collaboration occurs by exchanging the full document. Do you mean that full document will be exchanged between collaborators on every change or just at the beginning of the collaboration? Andreas -- Andreas J. Guelzow Registrar Professor of Mathematical & Computing Sciences Concordia University College of Alberta

Am 14/09/14 um 19:02 schrieb Andreas J. Guelzow: On 14-09-14 10:27 AM, Svante Schubert wrote: Am 14/09/14 um 08:53 schrieb Patrick Durusau: > Svante, > > Err, I'm not sure how there can be collaboration, even with OT without > communicating transformations to other applications editing the same > document. > > Yes? The collaboration occurs by exchanging the full document. Do you mean that full document will be exchanged between collaborators on every change or just at the beginning of the collaboration? The trick is exactly to avoid the exchange of the full document, whenever possible. Our goal is to extend the current ODF interoperability from the file based interoperability (as exchanging documents on floppy discs) to a changed based interoperability, where only the changes of ODF applications collaborating on a document are being dispatched over the net. Sorry for the belated response. Had been on several conferences and took the time off inbetween. Best regards, Svante