Meeting minutes

Dear all,

Please find below a summary of today’s discussion.

Attendance: DavidF, Rodolfo, Yoshito, Lucía.

I. Administration
A. Approve 16th November meeting minutes. https://lists.oasis-open.org/archives/xliff/202111/msg00005.html

L:I second.

R : Meeting minutes approved.

II. Technical work

A. Spec draft published with internal links. https://lists.oasis-open.org/archives/xliff/202112/msg00002.html

R: I have fixed the merger. (Rodolfo shows the new document). All the links work.

I modified the merger to support missing links in the core-only document. Links that point to a module are not present in core and are shown in italics (using a <remark> element) instead of an actual <link>.

Df: this is the only core spec?

R: Yes it is. I was thinking about another option. As we have two different files. XLIFF core and xliff extended version 2.2. We need to have also different links to the previous versions.

Df: I think it is ok that both files to point to the previous version. We can include the explanation in the related work.

L: I agree.

R: Ok, I was not sure where to put this information.

L: can we see the differences in number of pages?

R: The extended version is 196 and the core 81. The difference is huge.

L: That is really good.

B. Integration of XLIFF 2.0/2.1 into GNU Emacs. https://lists.oasis-open.org/archives/xliff-users/202112/threads.html

R : Df replied to the email.

Df: I think Bryan did it for Drupal.

R: I also have an open solution, OpenXLIFF Filters. It is possible. The problem is that PO used plurals and so on. You use a formula for that.

Df: They could also wait for the module of the message group.

R: I wrote a paper 15 years ago about the conversion from PO to XLIFF 1.2. It has not been updated for XLIFF 2.x

Df: we had two proposals for the module, the need might come.

R: I do not know if we should answer more. I know people who implemented.

C. “ref” attribute in . Rodolfo. https://github.com/oasis-tcs/xliff-xliff-22/raw/master/xliff-22/xliff-core-v2.2wd.pdf

R: I have added the « ref » attribute in the element <note>, it is optional. I have added an example too in the spec.

R: This is an implementation change. We can just use an attribute in the notes.

My question is we add the support in <note>, that is the feedback I am looking at right now.

We are going to make changes, there will be backwards compatible

R: Yoshito, what do you think? Now you can point to the segment, the same way that it is used for <mtc:match>. It is the same mechanism.

Df: When was this decided?

R: We had a ballot. We announced it two weeks in advance.

L: Everything was transparent. We had a roll call during a meeting. I even sent an email to announce that we will have a call on this in the following meeting.

Df: My objection stands. I do not think it is clever to make these decisions on ballot with a small number of members.

R: We will not make any progress from this. If you have suggestions about making note element, please let me know.

Df: I think this was a bad decision. There is this method for linking notes to a fragment using the “comment annotation”.

R: But that meant that we would need to change the source. That is why we had the ballot and it passed.

The comment annotation method is still valid.

D. Fragid registration. (Rodolfo, Yoshito, DavidF)

Df: I think it should be kept.

R: ok. The validator does not require you to register a prefix now.

E. Tracked Changes module -> can't be used to store a translation that was modified. Was that intentional?

R: The module has been demoted. It is just a reference material.

Df: we kept it in place, so the number is not broken. It does not allow you to keep previous translations.

R: What was the intention for this module?

Df: I think people had found issues, like the inline elements were not included. There are some solutions given to improve, but people did not agree on the solutions. It is described as an extension, the intend for extension is that people are free to work on a different version of the module.

R: the problem is that we have already a schema for this. It is a module schema. If you decide to reintroduce the module, you just need to replace it with the new version of the schema. As it is, is useless. We have two options: fix or remove. We are trying to be cleaner in the next version.

Df: This is not in the core-only version. Just to keep the structure.

R: the number of the modules do not change.

L: do the users use the number?

R: We are creating a new version. Does it make sense to keep it?

Df: I have the new versions, but we did not come to a consensus. They are in the SVN. I think I stored it a significant branch.

R: If you can send me the folder. Thank you.

Df: It is on the committee page. http://tools.oasis-open.org/version-control/browse/wsvn/xliff/?sc=0 You can use it as a starting point. Phil was in charge of updating it. I think tracked changes might not be something on the format.

R: I have seen how other tools do this and make sense.

Df: Have a look at what I implemented.

R: I will do it.

Df: I think the final data model, it gave you some options, and I think it was able to mimic to target level.

R: That would be interesting.

Df: There were three options, depending on what level you are mimicking.

R: Ok. It sounds interesting. I will look into that.

F. Clarify the attribute ref. Discussion (Rodolfo & Yoshito).

R: I have made a small change allowing you to point to the <note> in the spec.

The other element that we were discussing is the ref of the mtc:matches

Should we use the same definition I used for the other ref?

Y: I think so.

R: we should have an example. I will add two, one using ref and one with annotations.

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

R : Have you made any changes in the schematron?

Df: I did not.

R: shows example in 5.1.8 with an error reported on GitHub, there is an issue with that.

Df: <source> and <target> are fully qualified, they are reused from the core.

R: any xml parser will allow without qualifies

Df: it is reused from core. You import XLIFF core xsd

R: parsers do not ask you to qualify. It is reference to the content, not the name.

Df: you have options for attributes, you do not have the options for elements.

(Rodolfo shows a file that is valid)

Df: what did you use to validate?

R: XML parser.

Df: I will try it on Oxygen. I do not think the example was wrong because of that.

R: In Oxygen is valid.

Df: it inherits from the root, right?

R: Yes.

III. Subcommittee and sister TC reports

Df: No news.

L: Meeting adjourned

xliff message