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

["Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca>]

On Wed, 2011-10-26 at 08:37 -0600, Robin LaFontaine wrote:
> Yes, some confusion here I think, we have drifted off the original
> topic which was to do with the need to diff data to find out what has
> changed. Ben asserted that in ECT this diffing of draw:frame was
> needed to establish that only the ct:id attribute had changed, but in
> GCT the change to that specific attribute was explicit.
> 
> Ben's assertion is true: he says that it is necessary with the ECT
> representation to compare the old cached draw:frame with the current
> one to work out if the ct:id has changed or perhaps the caption, it
> could be either or both (or something else, perhaps the svg:width
> attribute etc). The point is that with a cached element you do not
> know which bit has changed, you need to work it out.
> 
> Andreas points out that the attribute change may not be a 'real'
> change, which is a fair point and the (producing) application would
> need to work that out and not indicate a false change. (I don't think
> we have ever discussed how to show a change in the situation where
> the .jpg file (in your example) has been edited but has the same name
> and size, i.e. the draw:frame XML has not changed at all. I think that
> is outside the scope of what either ECT or GCT is trying to achieve.)

But this really should not be outside the scope! The first image in a
Gnumeric generated ODS file is always Image1.xxx. So replacing a jpg
with another jpg will always retain the image name in the package. In
ECT this would be marked as a draw:frame change I would think. What
would be happening under GCT?

Andreas


-- 
Andreas J. Guelzow, PhD, FTICA
Concordia University College of Alberta