[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]