Some thoughts on Change Tracking

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 Andrea's point does not invalidate Ben's assertion.
Therefore in the consensus report, 8.2, states  'Bucket' approach
means readers need to do comparison work to work out detail of
changes  is correct, though we could perhaps give some more prose
around that in the discussion of different approaches. Perhaps
'readers' should be 'consumers'.
Robin
On 24/10/2011 19:38, John Haug wrote:
A change to the name of the image referenced in the markup means that an entirely different picture is being used.  I'd certainly expect an application that supports showing change tracking to show that as a change.  As an example, the only thing that changed when I tested deleting an image and replacing it with a different one (with the same dimensions) in OO.o 3.3 was the last 4 characters in the file name.  <draw:frame draw:style-name= fr1  draw:name= graphics1  text:anchor-type= paragraph  svg:width= 6.9252in  svg:height= 4.328in  draw:z-index= 0 >
<draw:image xlink:href=
xlink:type= simple  xlink:show= embed  xlink:actuate= onLoad /> </draw:frame>  <draw:frame draw:style-name= fr1  draw:name= graphics1  text:anchor-type= paragraph  svg:width= 6.9252in  svg:height= 4.328in  draw:z-index= 0 >
<draw:image xlink:href=
xlink:type= simple  xlink:show= embed  xlink:actuate= onLoad /> </draw:frame>
Re-reading the back-and-forth between Ben and Andreas, perhaps some read a bit of confusion into the example?  The ECT example was not about changing the name of an existing file in the package and what would happen to references to that file in the ODF markup.  I agree that's not worth tracking and I can't imagine off the top of my head why that would be useful.  Recall ECT is about tracking user actions, so that example was about the user replacing one image with another.  Which changes the filename in the draw:image markup.  John