OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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:
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:
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).
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...

As you say below, CT may help to flush some of these out.


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.


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      
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]