Re: [office-collab] Suggestions for moving forward to resolveissues

[monkeyiq <monkeyiq@gmail.com>]

On Thu, 2011-04-21 at 17:36 +0100, Robin LaFontaine wrote:
...

DETAILED NOTES ON ISSUES

1. Implementation: is the GCT impossible/difficult/expensive to implement?

Rob describes the implementation issue as something like this:

"Change tracking is recorded and accepted or rejected in the runtime of the  editor.  At this point, the original ODF document has been read into memory structures that are optimized for that editor's runtime, but which bear no direct 1-to-1 correspondence with the ODF markup model.  Although each application will need to be able to load and save documents consistently in ODF, at runtime they are dealing with an entirely different abstraction.  This makes it tricky to process change tracking that is described as operations on the markup.  The ability to translate an entire document in memory to ODF at save time does not mean that apps can easily process an XML diff at runtime, after the document has already been loaded."

Abiword is one such application. It has its own native file format and its internal data models closely relate to that rather than ODF. While some elements in the native abw format are close to ODF there are others which are not. In particular the elements which are different from ODF in the memory structure/internal data model are also change tracked using that internal model of abiword.

The ECT proposal seems to require the xml diff at runtime more than the GCT. In ECT either at load time or in a lazy evaluation, the application will need to xml diff the current XML element to a recent "bucket" in order to actually tell the user that the caption is the only change between two revisions.

This inference of changes using buckets gets stickier when one considers captions. The below was generated by OpenOffice for a document where I inserted a small image and gave it a caption "captext". If one considers changes to style and then more intricate changes inside the text:p, the runtime xml diff of ECT buckets becomes somewhat complex just so an application can show the user the changes to a caption.

      <text:p text:style-name="Standard">
        <draw:frame draw:style-name="fr1" draw:name="Frame1" text:anchor-type="paragraph" svg:width="2.709cm" draw:z-index="0">
          <draw:text-box fo:min-height="4.817cm">
            <text:p text:style-name="Illustration"><draw:frame draw:style-name="fr2" draw:name="graphics1" text:anchor-type="paragraph" svg:x="0.004cm" svg:y="0.002cm" svg:width="2.709cm" style:rel-width="100%" svg:height="4.817cm" style:rel-height="scale" draw:z-index="1"><draw:image xlink:href=""Pictures/10000000000001400000023953C5B569.jpg"" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/></draw:frame>Illustration <text:sequence text:ref-name="refIllustration0" text:name="Illustration" text:formula="ooow:Illustration+1" style:num-format="1">1</text:sequence>: captext</text:p>
          </draw:text-box>
        </draw:frame>
      </text:p>

On the other hand, the text:p here and in other places of and ODF file could all be tracked the same way in the GCT. The application gets to be able to show the changes to a caption just as it does an edit to a table cell, just as it does an edit to the first paragraph in the body of the document.