[OASIS Issue Tracker] (XLIFF-22) CTR Warning and Best Practice Guidance improvements

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

David Filip created XLIFF-22:
--------------------------------

             Summary: CTR Warning and Best Practice Guidance improvements
                 Key: XLIFF-22
                 URL: https://issues.oasis-open.org/browse/XLIFF-22
             Project: OASIS XML Localisation Interchange File Format (XLIFF) TC
          Issue Type: Improvement
          Components: Change Tracking Module
    Affects Versions: 2.1_csprd02
         Environment: http://markmail.org/thread/swfqpdaka455pm44
            Reporter: David Filip
            Assignee: David Filip
             Fix For: 2.1_csprd02


Comments on text in section 5.6.1

1.  Several suggested text corrections to the Warning paragraph

This is the current text of the "Warning" in 5.6.1, emphasis mine:

Because the *Change Tracking Feature is an optional module that* can be
legally ignored by Core only Modifiers, the only safe way *how* to record
a version of content that can be *reintroduced as result* of a *roll back*
is to store the whole unit data within the *Change track* item element.
Contrary to generic change tracking or versioning approaches, it's not
enough to store just your changes. Alternatively, you can store the whole
unit content as a revision before you start making your own changes and
store just your changes as the most recent revision.

I suggest the following corrections (in order, corresponding to the bolded
sections):

   - Use "Module" instead of "Feature", so change this passage to "Because
   the Change Tracking Module is optional and.."
   - Remove the unnecessary word "how"
   - Change "reintroduced as result" to "reintroduced as the result"
   - Change "roll back" to "rollback", which is the more common form for
   usage as a noun (see here
   <https://en.wikipedia.org/wiki/Rollback_(data_management)>, here
   <https://www.merriam-webster.com/dictionary/rollback>).  (If this change
   is accepted, it should also be applied to the use of "roll back" in section
   5.6.7.7 for consistency)
   - Change "Change track" to "Change Track"

Incorporating these changes, the suggested text of this paragraph would be:

Because the Change Tracking Module is optional and can be legally ignored
by Core only Modifiers, the only safe way to record a version of content
that can be reintroduced as the result of a rollback is to store the whole
unit data within the Change Track item element. Contrary to generic change
tracking or versioning approaches, it's not enough to store just your
changes. Alternatively, you can store the whole unit content as a revision
before you start making your own changes and store just your changes as the
most recent revision.

2. Additional guidance on best practice usage of CTR

The final sentence of the Warning in 5.6.1 is an important one:

Alternatively, you can store the whole unit content as a revision before
you start making your own changes and store just your changes as the most
recent revision.

The way I would assume to use the Change Tracking module is that any
previous versions of the content would be stored in CTR revisions, while
the latest content would be stored in non-CTR data.

However, the use of "Alternatively" here is confusing to me, because it
makes it sound like this pattern of use is an alternative to some other
method.  In particular, it sounds like the assumed "default" pattern of
using CTR is to keep the original data outside of CTR, and then store any
subsequent versions in CTR revisions.

Implementations that disagree about the interpretation of this will not
produce data that is mutually intelligible, so I think this section needs
to go further in, at a minimum, recommending a best practice for
implementations.





--
This message was sent by Atlassian JIRA
(v6.2.2#6258)