Meeting minutes

Dear all,

Please find below a summary of todayâs discussion.

Best,

LucÃa

Attendance: Rodolfo, LucÃa, Yoshito, Manuel, Bryan. We have quorum.

I. Administration
R: I move to approve 16 August meeting minutes.
https://lists.oasis-open.org/archives/xliff/202208/msg00005.html

Y: I second.

R: Meeting minutes approved.

II. Technical work

A. ISO template. https://github.com/oasis-tcs/xliff-xliff-22/issues/3
David.

(David is not on the call).

B. Discussed and approved changes in the spec. Rodolfo. You can download updated versions of the specification fromâhttps://github.com/oasis-tcs/xliff-xliff-22/tree/master/xliff-22â

(Rodolfo shares his screen and shows the changes in the spec).

Old XLIFF 2.0/2.1 files will be still be valid XLIFF 2.2, because the schema is backwards compatible.

C. Test suite correction. Schematron (update). Confidence vote. See point
I in the 7th June meeting when this was discussed
https://lists.oasis-open.org/archives/xliff/202206/msg00003.html

We do not have any feature requirements. So before starting reviewing this draft, we need to know what to do with the schematron, NVDL and the test suite. My proposal is that we remove them from the spec, leave those files in the github repository so they can still be found and might be updated/changed in the future. But we will remove them from the spec so we can move on to the reviewing phase.

B: I recall having this conversation with David on the call and he does not seem to object.

R: I just say that we should keep them in github.

B: I support the idea of having a ballot to make a decision on this.

L: I second.

Y: Can we keep an informative note mentioning them?

R: Sure, we can keep the information in the changes section.

Y: Do we keep it in the appendix as a note?

R: Appendix C is where the changes are mentioned, and that is where we can include that information.

Y: It sounds good to me.

L: It sounds good to me too.

(The wording of the ballot is agreed between the members), it will be opened for two weeks, it will be closed after the next official meeting:

https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=3727

D. New feature requirements?

Y: We wanted to use context references in translation. Resource Data Module. I realise that resource item can be associated with file level. Is it possible to have them at file level? Semantics is not clear in the spec. We wanted to share some context such as screenshots of UI. We wanted to provide a linkage, defined at the file level. But at some points we want to point at unit level. But sometimes we want to provide complicate resource to the entire file. For our use case. It is not clear what it means the resource item in a file. Where do we put the resource item in file?

R: you can put it in the item or reference.

Y: I probably should explain myself better in an email. In the current spec, both examples are at file level. Does it make sense?

R: we need to check the definition of it. It is fine, it is valid. It is a useless resource.

Y: We have a screenshot giving a context, in this case I just want to attach the screenshot at the file level, but not everytime we have a unit.

R: I do not think you need to have the reference everywhere. If you put it in the file level, it applies to everything that is below.

Y: The problem is that resource item is valid, what does it mean?

R: I do not know, but I do not think it is wrong to have it.

Y: I might send an email explaining it better. But anyway, I do not think this will impact the schema. Some clarification would be enough in this case.

R: Yes, if it is just a clarification, it will not have any big impact on the spec. I need examples, if you have any please send them and I can improve the support.

Y: I will make a proposal on github.

III. Promotion and Liaison
A. (News from the module from the Message format working group?)

Y: I am not part of the message format working group. A technical preview based on their specification will be included on next ICU release in 3 or 4 weeks.

xliff message