OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]