Thanks for checking, Yves, it makes sense as the strict interpretation would break the modularity promise of 2.0 I.e. Core only modifiers would be impossible. Also, Felix, Soroush and I met in Prague last week and agreed on a way how to implement the same implementation for the the 2.1 Advanced Validation feature. Soroush should have the Schematrons ready for tomorrow's meeting. Basically the inline ID constraints will be checked separately for descendants of <segment>, <match>, and <revision>. While the constraints should be the same for core and mtc it remains to be seen what kind of constraints will make sense for ctr. Cheers dF By the way, I looked if this example was being read without validation error using Microsoft's Xliff-OM library and it seems to be the case: The duplicated IDs in the two matches seem to be read without trouble. So it looks like all implementations we know of have interpreted the constraint to be for the core only. Cheers, -yves
Original Message----- From: Yves Savourel [mailto: ysavourel@enlaso.com ] Sent: Tuesday, February 2, 2016 10:09 AM To: XLIFF Main List < xliff@lists.oasis-open.org > Subject: Example with inline codes for MTC module test suite Hi, I had an action item to provide an example of XLIFF 2.0 with translation candidate matches with inline codes. The file is attached. (I can't push it to SVN because of some authentication issue, so if someone else can that would be great. It would go to: xliff-20 est-suitemodulesvalid). Cheers, -ys --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php