OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


     [ https://issues.oasis-open.org/browse/XLIFF-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Filip updated XLIFF-22:
-----------------------------

    Fix Version/s: 2.1_csprd03

> 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
>              Labels: Clarification, Practices, editorial, request_tc_discussion, work_required
>             Fix For: 2.1_csprd03
>
>
> 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)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]