Re: [office-collab] Thoughts and Comments on extended-change-tracking-proposal

[Ganesh Paramasivam <ganesh@crystalfab.com>]

John,

Please find below my comments on the supplement.

Thanks,
Ganesh

1. The supplement seems to introduce a new way to handle delete
changes ( it is called as the Insert/Delete style and is conceptually
different from the ODF 1.2 delete change handling mechanism ). So, the
new mechanism should be applied to the <p> to <p> and <p> to <h>
merges too ( The two use-cases that are explicitly handled in the
current ODF 1.2 specification ) . Right ?

2. Doesn't the introduction of the new mechanism break backward
compatibility to the old ODF 1.2 change tracking format.

3. There are some problems/bugs in the way paragraph-list merges are
handled by the ODF 1.2 mechanism ( called as Paragraph Style )
examples  in the document. For sake of brevity, I will not list out
the problems here ( as you have mentioned in the document that this is
not a recommended approach ).

4. This opinion is subjective, but I do have some issues with the way
paragraph/list-item and list-item merges are handled by the new
mechanism. Some concerns that I have are
- The change mark-up does not accurately capture user-intent because
it converts a delete user-intent into a combination of
insertion-deletion user-intent.
- Two roles being assigned to insert changes ( actual insert change,
side-effect insert-change ). So insert-change handling code at all
places ( loading, saving, displaying etc ) needs to have logic to
differentiate between the two roles.

5. The table splits and merges examples seems to ignore the
number-rows-spanned and number-columns-spanned attributes of
table-cell and instead depends only on covered-cell. The covered-cell
should always be handled in conjunction with the other two attributes
to accurately determine to which table-cell the covered-cell belongs
to. Some side effects of this are

- A horizontal merge of a cell and a vertical merge of a
upper-right-diagonal cell would result in the removal of the same
covered-cell and the insertion of a a new cell in the same location.
The resultant change-markup for these two completely different
use-cases would be exactly the same.
- If a cell-split or a cell-merge change is rejected, it would not be
possible to know the previous merge/split state of these cells because
the values of these two attributes are not stored as a part of the
change-markup.

I think all table-cell split and merge examples might need re-work to
address this issue. Am I missing something here ?



On Thu, Mar 31, 2011 at 5:12 AM, John Haug
<johnhaug@exchange.microsoft.com> wrote:
> Sorry for the delay on this.  It took some time, plus other commitments.
> The examples in this doc are fairly straightforward extrapolations of the
> patterns established in the main proposal doc and in line with the general
> flavor of existing ODF change tracking.
>
>
>
> http://www.oasis-open.org/committees/document.php?document_id=41677
>
>
>
> I hope it helps further everyone’s understanding and the discussion.
>
>
>
> John
>
>
>
> From: John Haug [mailto:johnhaug@exchange.microsoft.com]
> Sent: Tuesday, March 22, 2011 6:02 PM
>
> To: office-collab@lists.oasis-open.org
> Subject: RE: [office-collab] Thoughts and Comments on
> extended-change-tracking-proposal
>
>
>
> By the way, while I look into this, I’d like to solicit input from others on
> how some of these cases should look.  Again, we intended this document to be
> a starting point of discussion, a catalyst for the subcommittee to create an
> inclusive design, not a specification of how I think every detail of a
> design must look.  I’d love to hear from others who have expertise in this
> area as they likely have some insights I may not.
>
>
>
> John
>
>
>
> From: John Haug [mailto:johnhaug@exchange.microsoft.com]
> Sent: Monday, March 21, 2011 5:45 PM
> To: office-collab@lists.oasis-open.org
> Subject: RE: [office-collab] Thoughts and Comments on
> extended-change-tracking-proposal
>
>
>
> Hi Ganesh –
>
> Yes, as general text edits, we would certainly intend for #1 and #3 to be
> supported in an extension to the current change tracking model.  Same for #2
> as a basic table edit.
>
>
>
> I can start looking at building example markup snippets, though that will
> take some time given the number of specific cases called out.  Until then,
> some general guidance that might help: While working on the proposal it came
> out that each category of change essentially established a basic pattern.
> So while each of the specific items listed below as example cases would be a
> separate markup snippet, they follow common patterns and you should be able
> to get a quick sense of the markup/implementation complexity by looking at
> similar examples in the proposal document.
>
>
>
> John
>
>
>
>
>
> -----Original Message-----
> From: Ganesh Paramasivam [mailto:ganesh@crystalfab.com]
> Sent: Sunday, March 20, 2011 11:45 PM
> To: office-collab@lists.oasis-open.org
> Subject: [office-collab] Thoughts and Comments on
> extended-change-tracking-proposal
>
>
>
> Hi,
>
>
>
> I have had a change to go through the new change-tracking proposal and
> please find below my initial thoughts and comments.
>
>
>
> I'm aware of the fact that this specification is intended as a "general
> vision document" than a full specification, but it would be nice to know the
> over-all approach that the proposal intends to take to support the below
> mentioned use-cases because that would a criteria ( implementation
> complexity and feasibility to support not-so-simple scenarios ) in comparing
> multiple approaches.
>
>
>
> Thanks,
>
> Ganesh
>
>
>
> 1. Missing support for certain types of delete merges.
>
> The use-cases that come under this category are
>
> - Paragraph merge with a list-item
>
> - A list-item merge with paragraph.
>
> - List-item merge with another list-item
>
> - List merge with another list.
>
> These use-cases are illustrated under the category "Other" ( I.1 through
> I.7) at http://wiki.oasis-open.org/office/ChangeTrackingUseCases
>
>
>
> 2. Missing support for table cell splits and merges ( Single as well as
> multiples and combinations. example:- two consecutive horizontal merges
> followed by a vertical merge ) These use-cases are illustrated under the
> category "Tables" ( C.7 through C.10) at
> http://wiki.oasis-open.org/office/ChangeTrackingUseCases
>
>
>
> 3. Clarification needed for multiple and over-lapping change use-cases. It
> is not entirely clear whether these use-cases are supported or not. Would be
> great to see this specifically addressed in the proposal.
>
> Some examples ( non-exhaustive ) of this category are
>
> - A paragraph addition followed by a merge of the paragraph with a preceding
> paragraph.
>
> - Text addition followed by format-change followed by deletion of the text
>
> - Paragraph addition followed by style-change followed by deletion of the
> paragraph.
>
> - Text-deletion followed by deletion of the paragraph
>
> - Text-addition followed by deletion of the paragraph.
>
> - List-item addition followed by a merge with a succeeding paragraph.
>
> Some of these use-cases are illustrated under the category "Multiple
> Changes" (F.1 through F.11) at
> http://wiki.oasis-open.org/office/ChangeTrackingUseCases
>
>
>
> ---------------------------------------------------------------------
>
> 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
>
>
>
>