Resolution of your public review comments: 019, 020, 021, 022, 061

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Jörg,

There have been some very fruitful discussions between you and TC members around the valuable feedback you provided during our first XLIFF 2.0 public review period.

I've scanned the comment list to be sure we've properly communicated our conclusions and actions to you. In some cases I could not find adequate communications - or the communications seemed not complete.

So in the interest of clarity and closed loops, I’m adding a few details around the issues I thought were not completely covered. Please forgive the redundancy if I’m repeating points that have already been made.

I will use the comment numbers we've documented in our wiki tracker https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker#preview

019: You proposed that we reduce our inline elements to 2. We spent a good deal of time discussing this. While the idea received some support, we took a ballot and decided to keep the inline elements that were prescribed by the inline text subcommittee (https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00090.html).


020: You proposed we maintain consistency between abbreviations used for target (language and directionality). This was also suggested by Yves (logged as 012 in the wiki). The TC agreed and Fredrik updated the Specification (https://lists.oasis-open.org/archives/xliff/201307/msg00105.html ).


021: You suggested “The attributes 'state' (no customization) and 'subState' (for customization) could be collapsed into one state attribute with pre-defined ('xlf:' namespace) and customized values.” The TC discussed this. The consensus was that in general, attributes that have a sub-property should be maintained, and that we should add explicit processing requirements to make them consistent (https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00014.html ).

022: You noted if the TC agreed to limit inline elements to just 2 (re: comment 019), the attributes 'canCopy', 'canDelete', 'canOverlap', and 'canReorder' used in conjunction with inline code are helpful, and should be retained. Since the TC chose to keep the original set of inline elements as prescribed by the Inline Text Subcommittee, this good suggestion is no longer relevant.

061: You noted that the Validation module the module should provide additional clarification and justification around the rules. The TC agreed, and implemented your suggestion (https://lists.oasis-open.org/archives/xliff/201307/msg00099.html ).

I think this brings us up to date. If you feel that we’ve missed any communications about any of your comments, please let me know.

Again, we are very grateful for your help, and look forward to a very good XLIFF 2.0 as a result.

Thanks,

Bryan