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: Optimisation was Re: [office] Inversed MCT

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

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]