Re: [office-collab] Collaboration/Change Tracking aspects

[Patrick Durusau <patrick@durusau.net>]

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