[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:
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.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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]