Meeting minutes

Dear all,

Please find below a summary of today’s discussion.

Attendance: Bryan, DavidF, Yoshito, Lucía

Regrets: Rodolfo

We have quorum.

I. Administration

L: I move to approve 18th January meeting minutes. https://lists.oasis-open.org/archives/xliff/202201/msg00001.html

Y: I second.

L: Meeting minutes approved.

II. Technical work

A. Proposal for changes template/protocol. Discuss and vote on Yoshito’s proposal. https://lists.oasis-open.org/archives/xliff/202201/msg00005.html

Y: The specification changes can be recorded through that mechanism.

L: I have looked at it and I think it would be a good mechanism to record and discuss the changes proposals.

Df: (looks at it) it is like a wizard. It looks good.

Y: we can discus and modify the items I included.

Df: I can include it in the XLIFF repository, or I can talk to Chet to give you the rights to include it yourself.

Y: Not necessary. I can just give you a PR.

DF: in the area of changes, instead of “xliff schema”, you could make two checkboxes one “XLIFF schema” and another “xliff module schemas”. If the proposal is in a module. For example, when the Unicode people will come to propose a new module, maybe a checkbox to include a new module schema.

Y: after you create the issue, it would not look like this.

Df: yes, but it will have labels.

Y: the label that is created is “change proposal”.

Df: there will be another wizard, xliff core change, xliff module change, and xliff new module. Then the label will be clear.

Y: Yes.

Df: You can keep all the checkboxes in all the wizards. I think it would be easier to use as a separate wizard.

Df: I like it really, it is great to have a process like this.

L: I was wondering if we would need to explain in the wizard some of the specialised terms like core or extended specifications.

Df: Engineers they are aware of those terms, I do not think we need to explain them.

Y: We might need to implement changes that are simple bug fixes. Simply correcting those mistakes should be handle differently. We could have a fourth template, for simple bug fixes.

Df: yes, that can be a good idea.

L: I agree. Yoshito, could you implement the changes that were discussed before the next meeting?

Y: I will.

L: Thank you, that would be great, so we would be able to discuss them and hopefully approve them to include the next changes proposals.

B. Version attribute. See meeting minutes from last meeting. https://lists.oasis-open.org/archives/xliff/202201/msg00001.html

(Lucía summarises the discussion from last meeting)

Df : We did not do enumeration in 2.x. It does not feel clean in the engineering sense.

Y: we discussed to have a similar enumeration like in the schema of 1.2.

Df: that means that this will be not making it forward compatible.

What you put there is guiding to validation, if you open an XLIFF in Oxygen, they have conditional behaviour, it recognises several scenarios based on 1.2, 2.0, 2.1. If you want to use XLIFF in a private scenario, you could use 2.3 not to trigger validation, some value that does not make sense.

Bryan, you were considering roundtrip scenarios. Another thing that people do is to separate in smaller files, this is not in the spec, but you can do it privately.

B: I do not have a strong opinion on this.

Df: This seems like a non-breaking change to me. If they work with the old schema, it does not break any scenarios. I would classify it at non-breaking change, as it does not affect back compatibility.

Y: yes, this is not breaking back compatibility.

Df: I am sort of hesitant. It will harder to make other validation scenarios. If you do it in the schematron, you could just add a warning, not an error.

Y: There are three possible solutions: one is keeping undefined, second is to keep it an enumeration, the third is to have a 2.2.

B: We can do patterns that will also allow future versions, with numerals and strings.

Df: Imagine a scenario where we develop 3.0 where we only have values 2.x, we will have forward compatibility issues. The pattern can be more permissive. I am trying to understand what is the benefit of making the change.

Y: This is why is so important when proposing the change in the template I prepared to include the argument, so we can have the discussion based on that.

L: We can have this discussion again after the template will be implemented and Rodolfo would be able to include that particular proposal change there.

C. Namespace name. See meeting minutes from last meeting. https://lists.oasis-open.org/archives/xliff/202201/msg00001.html

Df : If we do schema changes, we have the urn schema for the changes. It is ok to stay there.

L: We can have this discussion again in the next meeting.

D. Test suite correction. Schematron (update). https://docs.google.com/spreadsheets/d/1uaQ1oSqhXRkRKXNLvgIwcffvNzhcTj9dIkIN__7EH4o/edit

Df : no updates. I have gone through half of the document. I will try to commit at least have what I have done so far.

E. New feature requirements?

III. Subcommittee and sister TC reports
XOMOS - Sister TC
Df: I have some news. We have this discussion in OMOS how to handle some artefacts in JLIFF. For instance it is ok to have xml illegal characters in json, something like that would be considered code and would be masked in <ph>. If you are doing conversions, some aspects cannot be easily converted. Our use case is not to expose code to translators, can we ensure that the cat tools would know how to display that. My fear is that they would just treat it as part of the string and show it to the translator.

B: that is a good argument.

Df: it is not XML against Json, the purpose is to be able to do roundtrip, imagine the scenario where you extract directly on jliff, you ccould have backslash end.

Y: we are looking into some implementations. In the okapi framework, they use the json.

Df: It will be replaced with a paragraph back space. But not masked as ph.

Y: Not preserved.

Df: if it is native json. It is a very challenging topic. We are kind of in an impasse now. Philip and I we want this mask mechanism. But other member does not agree.

We would need more experience and feedback from more tool implementers.

L: I have invited an implementer for the next informative meeting. You could take that opportunity to ask him.

IV. New business

L: No new business, meeting adjourned.

xliff message