CTR Usability

https://lists.oasis-open.org/archives/xliff/201612/msg00015.html
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.

https://lists.oasis-open.org/archives/xliff/201612/msg00028.html
– Out of context issues

As we store content in unitItem and contentItem, there is the issue of context that crops up: Some information like xml:space or
translate go across segment, or even across units, and may not have a physical representation in the XLIFF snippet we store.

For example taking a segment content out of the context of its surrounding other segments may hide the fact that it is not
translatable because there are some <mrk id='1' translate='no'> in the previous segment.
That information cannot be stored in <contentItem>. It may be OK, but that may also have side effect when restoring the data in a
different context.

Another illustration of context issue: <mrk type='comment' ref="#n1"> is a comment referring to a note. If we store this in, for
example, an <itemContent> because the translation has changed, there is no guaranty that the note n1 will stay there, or even point
that n1 corresponds to the same note after some other changes. So we can end up with invalid references.

Overall, it seems the content of a <revision> is bound to break the normal content constraint at some points because a) It is stored
in a different context and b) It is not stored with all its 'dependencies'.

– Validation troubles:

We say we do not want orphan <mrk>, but there are other validation issues with the stored content.

For example the id value of a segment may exists twice: in the true content and in one (or more CTR entries). If they do have the
same values, they break the constraint of http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#id where the
specification says that when id is used with segment "...the value MUST be unique among all of the above (segment, etc.) within the
enclosing <unit> element."

I'm running into a lot of problems when trying to read back contentItem and unitItem.

I think most of those questions are still un-answered and relate to the issue
https://issues.oasis-open.org/browse/XLIFF-22: how the
CTR module really works?