RE: [office-collab] An Abiword / Calligra developer's view of theChange Tracking events.

[Doug Mahugh <Doug.Mahugh@microsoft.com>]

> The timing of the "extended" proposal seems a little odd to me, as it was mentioned last year in Brussels that projects were looking to implement the generic proposal for ODF change tracking.

This is a strange thing  to say to the members of an OASIS technical committee, Ben. You and others may have  chosen to implement a non-standardized proposal prior to any consideration of it within OASIS's open and transparent standards process, for  whatever reason, but I disagree that such decisions should guide the work of this group. We need to follow the consensus-based OASIS process, regardless of what was said between private parties at a non-OASIS event in Brussels last year.

This committee has agreed upon a timeline that allows for proposals to be submitted through the end of March, and we have respected that process and adhered to it. If an SC member were to submit a proposal tomorrow, which is still prior to the deadline we have agreed upon, I believe this group has an obligation to take such a proposal seriously based on the timeline that we have publicly agreed upon.

> I think perhaps many citations in the extended proposal are to older change tracking rather than the "generic" one.

Correct. The mission of this committee, as covered in the Statement of Purpose, is to "draft enhancements to ODF," so the extended proposal makes reference to the change tracking in the ODF standard and provides suggestions for improving that part of the standard.

Thank you for your comments on the details of the proposal. I'll let John respond to those.

Regards,
Doug

-----Original Message-----
From: monkeyiq [mailto:monkeyiq@gmail.com] 
Sent: Friday, March 25, 2011 7:38 PM
To: office-collab@lists.oasis-open.org
Cc: Ben Martin
Subject: [office-collab] An Abiword / Calligra developer's view of the Change Tracking events.

Hi,
  As I have been a non vocal member of the list, many folks will likely not know me. I have hacked on KOffice/Calligra and Abiword. For the latter I have made a reasonable headway toward implementing the original "generic" change tracking proposal for ODF. I am not particularly affiliated with any company. This includes DeltaXML who proposed the "generic" change tracking and Microsoft who proposed the "extended"
change tracking. 

  I am more in favour of discussing things on the mailing list than conference calls. My timezone tends to make the conference calls harder to make.

  At the very least I should highlight to the group that there is a git branch of Abiword publicly available on github which supports the "generic" change tracking proposal for paragraph split/merge, text addition/deletion, move paragraph, toggle heading style, and growing support for the delta:merge swiss army knife. This will be folded into an upcoming mainstream release of abiword.

  So there are two existing implementations of the "generic" proposal; abiword and the work of Ganesh Paramasivam on KWord/Calligra. The timing of the "extended" proposal seems a little odd to me, as it was mentioned last year in Brussels that projects were looking to implement the generic proposal for ODF change tracking. In the interests of friendly collaboration I would have hoped that alternatives would have been tabled at that time or shortly thereafter. In light of the now existing implementations of the generic proposal, my vote would be to use the generic proposal and cherry pick things from the "extended" proposal as needed.

  How closely does the "extended" proposal mirror what is performed by Microsoft Word for non ODF formats? For me, it would be interesting to see how these things play out, and how the user interface offers such functionality in an existing implementation of the "extended" proposal.
Even if that implementation stores in non ODF currently.

  Over the last few days I have been bringing myself up to speed on the "extended" proposal. I think perhaps many citations in the extended proposal are to older change tracking rather than the "generic" one. As an example, the move content on page 4/19 of the extended proposal mentions that move is currently handled as delete/insert and no link between the two. Clearly in the generic proposal such a link is explicit as mentioned on page 17/23 of the generic proposal.

  The moving of multiple non-contiguous blocks of text as mentioned in the "extended" proposal is quite interesting. Perhaps a more fluid example would be moving a paragraph with D&D and then deciding that other content should subsequently be moved too as part of a single semantic "reorganize" operation. IMHO it would be rare to expect the user to control-select many non contiguous blocks and decide to move them at once.

  The question then becomes does a delta:change-transaction provide fine enough granularity to capture these cases, or should we also have something at a sub revision level, like text:changed-region, to allow markup of these grouped moves. Or alternately, should some RDF be able to reference each delta:insertion-change-idref to allow such relations and others to be captured explicitly.

  It seems to me having sub revision level constructs also runs the risk of being forgotten by the user. For example, I might move a paragraph and then decide to move a non-contiguous one but would really like to emphasise that these moves are very strongly related. And what if I fixed a spelling mistake after the first move but before the second?

  One thing which might be useful at a sub revision level would be time_t values (relative to UTC 1970 or as ISO 8601/dc:date encoding).
This way a second paragraph move would also explicitly let the viewer know that it was moved on the same day 12 minutes after the last paragraph move. And 7 minutes after the text "great stuff" was added.

  I'll split out subsequent comment on the extended proposal to another email as this is getting long already.



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