[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Optimisation was Re: [office] Inversed MCT
On 25/07/2012 13:16, André Rebentisch wrote:
This is an important point - Rob has made the point elsewhere that it is important to define what 'equality' means and this is particularly difficult in ODF. Two documents that a user might consider to be 'equal' may not contain the same XML. 'Optimization' is one aspect of this and this is done when changes are made to text formatting for example - and some of the SC examples showed that this can simplify the representation of change tracking, though it may add the complication that one change can actually alter a previous change due to this optimization. A canonical form might help but would not be easy to define, e.g. no two automatic styles that are the same, spans not nested...Am 25.07.2012 09:53, schrieb Robin LaFontaine:A gap may occur because change tracking is turned off or because a change cannot be represented in the change tracking serialization.The SC document mentioned use cases where no tracking occurs, based on the GCT feature matrix.Does this imply that a change tracking format that does not track all types of change would produce unpredictable results?Two questions: 1. Do ODF producers "optimize" the XML syntax output? A recent LibO bug with test cases appears to confirm it for this implementation: https://bugs.freedesktop.org/show_bug.cgi?id=52028 The background here is that ODF is not optimized in LibO >3.6a and "autostyle spam" is added to the odf file which leads to kerning issues. 2. Does "optimization" pose a challenge for "inversed" change tracking ("B to A")? Would XML syntax optimization also be tracked? In short CT boils down to: A to B B to A' A != A'? It is easy to see why A' would possibly be never identical to A, this is the "untracked changes" difference. We can still satisfy it by narrowing down the scope, the "tracked window", ignore CT-irrelevant aspects (e.g. timestamp meta data). As you say below, CT may help to flush some of these out. Robin ODF implementations produce different ODF syntax compliant output! Thus in a cross-application or cross-version roundtrip environment the CT necessitates further efforts for interoperability plug testing. I would expect issues to emerge from implementation imperfection/differences, not the CT as such. Specifying CT would help to tackle the differences. Best, André --------------------------------------------------------------------- To unsubscribe, e-mail: office-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-help@lists.oasis-open.org -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd "Experts in information change" 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]