Details

    • Proposal:
      Hide

      Implement the wordsmithing part as suggested, add a few more sentences of non-normatrive best practice guidance, link to non-normative best practice guidance in attribute descriptions

      Show
      Implement the wordsmithing part as suggested, add a few more sentences of non-normatrive best practice guidance, link to non-normative best practice guidance in attribute descriptions
    • Resolution:
      Hide

      This has been closed without resolution since the module was dropped from XLIFF 2.1

      Show
      This has been closed without resolution since the module was dropped from XLIFF 2.1

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              DavidFilip David Filip
              Reporter:
              ctingley Chase Tingley [X] (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved: