Re: [xliff-comment] XLIFF 2.1 csprd02: Comments on text in section 5.6.1

[David Filip <david.filip@adaptcentre.ie>]

Hello Chase,

great thanks for taking the time and reviewing the csprd02 of XLIFF Vesrion 2.1

On behalf of the XLIFF TC, I created this issue

https://issues.oasis-open.org/browse/XLIFF-22

from your comment.

Please follow the resolution/disposal of your comment on the above address

In case you want to follow up on the comment resolution please continue this conversation that is referenced from the JIRA issue under the following markmail link

http://markmail.org/thread/swfqpdaka455pm44

The TC plans to resolve your comment tomorrow and to implement the solution in a new working draft by 27th February, 2017.

The reported issue is deemed editorial in nature.

Cheers and thanks again

dF

Dr. David Filip

===========

OASIS XLIFF OMOS TC Chair

OASIS XLIFF TC Secretary, Editor, Liaison Officer

Spokes Research Fellow

ADAPT Centre

KDEG, Trinity College Dublin

Mobile: +420-777-218-122

On Fri, Feb 17, 2017 at 7:41 PM, Chase Tingley <chase@spartansoftwareinc.com> wrote:

This comment contains two parts, both regarding 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, here).  (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.