Details

    • Proposal:
      Hide
      • XLIFF 2.1 will restate the CTR 2.0 as an extension, i.e. not as a module and non-normative [so people will be free to continue using their CTR 2.0 implementations until a new CTR module will become available with XLIFF 2.2][Work on CTR 2.2 won't be limited by the need to comply with CTR 2.0 as it won't have a module status]
      • All development made on CTR 2.1 will be rolled back in 2.1 a copied to a 2.2 branch [TC members can continue work on it w/o affecting the XLIFF 2.1 timeline]
      • XLIFF 2.1 will proceed towards csprd03 without the CTR update [The will be no way to reintroduce the CTR update as an XLIFF 2.1 feature once csprd03 published]
      Show
      XLIFF 2.1 will restate the CTR 2.0 as an extension, i.e. not as a module and non-normative [so people will be free to continue using their CTR 2.0 implementations until a new CTR module will become available with XLIFF 2.2] [Work on CTR 2.2 won't be limited by the need to comply with CTR 2.0 as it won't have a module status] All development made on CTR 2.1 will be rolled back in 2.1 a copied to a 2.2 branch [TC members can continue work on it w/o affecting the XLIFF 2.1 timeline] XLIFF 2.1 will proceed towards csprd03 without the CTR update [The will be no way to reintroduce the CTR update as an XLIFF 2.1 feature once csprd03 published]
    • Resolution:
      Hide
      • XLIFF 2.1 will restate the CTR 2.0 as an extension, i.e. not as a module and non-normative [so people will be free to continue using their CTR 2.0 implementations until a new CTR module will become available with XLIFF 2.2][Work on CTR 2.2 won't be limited by the need to comply with CTR 2.0 as it won't have a module status]
      • All development made on CTR 2.1 will be rolled back in 2.1 a copied to a 2.2 branch [TC members can continue work on it w/o affecting the XLIFF 2.1 timeline]
      • XLIFF 2.1 will proceed towards csprd03 without the CTR update [The will be no way to reintroduce the CTR update as an XLIFF 2.1 feature once csprd03 published]
      Show
      XLIFF 2.1 will restate the CTR 2.0 as an extension, i.e. not as a module and non-normative [so people will be free to continue using their CTR 2.0 implementations until a new CTR module will become available with XLIFF 2.2] [Work on CTR 2.2 won't be limited by the need to comply with CTR 2.0 as it won't have a module status] All development made on CTR 2.1 will be rolled back in 2.1 a copied to a 2.2 branch [TC members can continue work on it w/o affecting the XLIFF 2.1 timeline] XLIFF 2.1 will proceed towards csprd03 without the CTR update [The will be no way to reintroduce the CTR update as an XLIFF 2.1 feature once csprd03 published]

      Description

      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?

        Attachments

        There are no Sub-Tasks for this issue.

          Activity

            People

            • Assignee:
              soroush.saadatfar Soroush Saadatfar [X] (Inactive)
              Reporter:
              ysavourel Yves Savourel [X] (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved: