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] Groups - MCT Challenge #2 (PDF) uploaded

Excuse the cross-posting, I replied to the sub-committee list directly, with CC to office list to show up the follow-up in the archive.

Note: The scenario has similarities to the former given 'Change-Tracking with "show-changes" enabled' show case:

Answering Dennis questions:
  1. When the change is created in MCT, is it tracked as a single action with two consequences, or two separate actions?

    To answer literally: It does not matter. In general every user interaction can be mapped to a single MCT operation. Still some MCT operations can be compressed to a single one, and other MCT operations can be split up to multiple one. For instance, the insertion of multiple following single characters can be seen as the insertion of text consisting of the single characters.
    In addition remember that for change-tracking many changes will be neglected. For example, if an user A let his work being reviewed by an user B, than the user A will only see the final changes of user B. Even if user B had rewritten a paragraph a couple of times only the final result will be viewed.
    Finally, the User A will nowadays be able to see all changes being bundled by components, as you have divided naturally your changes as changes of a heading and a paragraph. Although MCT allows to split up the changes of the paragraph into the most fine granular operation level, from a usability perspective the paragraph changes might be accepted as one (if from the same user), although still the option could exists that the changes can be divided into smaller junks. Still no-one would like to accept/reject every single character. It is up to the application how to show and condense the changes, only overall sum changes have to be equal. From the editing stand-point there is in general no difference between a replace and an equivalent deletion and insertion.

  2. When ODF 1.2 tracked-changes are upward converted, is there any difficulty having these be separate operations at what is essentially the place? That is, can they still be recognized and independently accepted/rejected in a straightforward manner?
    No problem, as two operations would be detected.

Perhaps we are able to continue the discussion in our call in about 80 minutes.


On 27.11.2012 19:46, Dennis Hamilton wrote:
Document Name: MCT Challenge #2 (PDF)

This particular challenge does not expose any implementation bugs. The
persistent documents reflect valid tracked-changes in terms of the ODF
specification. That the producer chose this particular approach to
enacting the changes made by an user is appropriately
implementation-determined. The challenge is around MCT equivalents and
alternatives (if any) for the same cases and up-/down-level

The PDF provides a version of the description that does not require an ODF
consumer to read and evaluate.

The editable forms of the two example documents and this description are in
the Zip version.
Download Latest Revision
Public Download Link

Submitter: Mr. Dennis Hamilton
Group: OASIS Open Document Format for Office Applications (OpenDocument) TC
Folder: Miscellaneous
Date submitted: 2012-11-27 10:46:51
Revision: 1

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