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
-----Original Message-----
From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Robin LaFontaine
Sent: Monday, October 24, 2011 4:22 AM
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Some thoughts on Change Tracking
Comment at end - I have been re-reading as part of consensus report editing.
On 16/09/2011 01:49, 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).
Andreas
I would not expect an application (an editing application or any other) to show a change to an image just because the name of the image file has changed.
Although GCT can represent any change to the XML content it does not mean that an application has to show changes that are not 'real'
changes. I would hope that an application can be clever enough to determine that these are only changes to pointers - it takes some work but is not difficult. The same applies to changes to automatic styles and other areas - some intelligence can be applied to avoid showing changes that are not 'real'. Of course what is a 'real' change should be defined by ODF, but is not: different representations of automatic styles, different representations of spans etc. An editing application would surely handle this in its internal data structure before it writes out the changes.
The intention of GCT is to be able to show a change at the lowest level to avoid the need to diff sections of the XML. It does not of course address binary data.
Robin
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Change control for XML"
T: +44 1684 592 144 E:robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
---------------------------------------------------------------------
To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-collab-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-collab-help@lists.oasis-open.org
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Change control for XML"
T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com
http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
|