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

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



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