Change tracking questions

[Yves Savourel <ysavourel@enlaso.com>]

Hi all,

I'm still quite a bit uncertain about the CTR module.
We have almost no example on how it would be used and no coded implementation at all.

I've tried to manually go through the different steps of changes a unit may go through in the attached example.
(Note that to put everything in a single file each unit is the next version of the previous one, not separate units). I've tried to
make sure there were inline codes, segmentation (but no orphan inline-codes I'm afraid)

The changes recorded are still very basic.
(And BTW I have not validated it).

I assumed the way the module is supposed to be used is as follow:
When a change is made, the version before the change is save as a CTR entry and final result of the change set is the normal content
of the unit.

Is it the expected way to do it?

This led me to several questions:

- How do we represent entries that do not exist yet?
For example if you add a note and there is no notes in the unit: what do we record?

- I'm not sure what the version attribute can be used to do. Is it to link together all entries corresponding to a set of changes
done during the same session? (Within and across units?)

- What do we do when a change is linked to something we don't track? For example an <mrk> is added in the source when adding a
translation candidate. We could track the new <mrk>, but not the match it corresponds to, so how could we restore a previous
version?

It seems to me that we have design the CTR module backward: Looking at the representation first, instead of trying to implement
change tracking (i.e. really coding a tool doing it) and coming up with a representation based on the needs.

Cheers,
-ys

Attachment: CTR_tests.xlf
Description: Binary data