Re: [office-collab] Some thoughts on Change Tracking

[monkeyiq <monkeyiq@gmail.com>]

On Thu, 2011-09-15 at 18:49 -0600, Andreas J. Guelzow wrote:
> On Thu, 2011-09-15 at 18:42 -0600, monkeyiq wrote:
> > On Thu, 2011-09-15 at 18:22 -0600, Andreas J. Guelzow wrote:
> > > On Thu, 2011-09-15 at 18:12 -0600, monkeyiq wrote:
> > > > On Thu, 2011-09-15 at 23:53 +0200, Thorsten Behrens wrote:
> > > > > monkeyiq wrote about ECT:
> > > > > >   I find this an extremely critical issue has it means that users of
> > > > > > change tracking are relying on various applications to imply changes
> > > > > > rather than being told directly and explicitly what has changed. 
> > > > > > 
> > > > > Hi Ben,
> > > > > 
> > > > > well the same applies to GCT. The very fact that it needs
> > > > > annotations is testament to this issue. I maintain that GCT markup,
> > > > > while being a nice idea on the xml level, fails my requirements as
> > > > > an implementer of a non-xml internal data model application.
> > > > > 
> > > > > Cheers,
> > > > 
> > > > Perhaps we are looking at different aspects here. I am referring to
> > > > example like the "Edit Image/Shape/Chart" from the ECT (pp17). In order
> > > > for an application to tell you that the image file name changed from
> > > > Image1.jpg to Image2.jpg it will have to do a diff on the 
> > > > 
> > > > text:tracked-changes/
> > > >   text:changed-region@text:id="1"/
> > > >     text:deletion ct:id="1"/
> > > >        draw:frame
> > > > And the inline draw:frame for
> > > > text:change-start text:change-id="1" ct:sub-id="2"
> > > > 
> > > > In the GCT this would be explicit in an ac:change attribute. No need to
> > > > perform any analysis to see that the xlink:href was Image1.jpg in the
> > > > last revision.
> > > 
> > > But changing the name of the image file in the zip package is _not_ a
> > > change to the document. The image file names are just internal
> > > references to find the appropriate image or chart description. 
> > 
> > Well, this is just the example from the ECT proposal document. It is my
> > understanding that any semantic change in the draw:frame is handled the
> > same way. So for example, editing the caption will want to be change
> > tracked and will produce the above need to perform a diff analysis.
> > 
> And in GCT while you know that the image file name has changed you also
> still have to perform a diff analysis to determine whether there has
> indeed been a change to the image (or chart or...). So in both cases you
> need to determine whether there was change and if there was a change
> what it in consisted of (assuming that your implementation wants to be
> more specific then saying that there may have been a change).
> 

I think this also depends on what the implementation wants to do. For
pixmap images one is dealing with compressed binary formats so perhaps
the simplest brute force of comparing the RGB pixmaps would be
effective. For SVG images the option is at least available to use GCT on
the SVG XML file itself.

Assuming that government, publication, or whatever companies want GCT on
SVG then perhaps implementations will offer it there too.

Otherwise, you are indeed forced to do complex comparisons for the image
or chart, etc data. Borders on those, caption text:p, and other inline
content would not mandate such a diff in the GCT though.