Kind reminder, open ballot (issue 4)

[Lucia Morado Vazquez <Lucia.Morado@unige.ch>]

Dear voting members,

 

There is an open ballot to vote on issue 4.

The closing date is Tuesday, 29 March 2022 @ 8:00 am EDT.

 

Have a nice weekend,

 

Lucía

 

 

 

De : xliff@lists.oasis-open.org <xliff@lists.oasis-open.org> De la part de Lucia Morado Vazquez
Envoyé : 15 March 2022 18:33
À : xliff@lists.oasis-open.org
Objet : [xliff] Meeting minutes

 

Dear all,

 

Please find below a summary of today’s discussion.

 

 

Attendance: Yoshito, Rodolfo, Lucia, Bryan

Regrets: David.

We have quorum

I. Administration

L: I move to approve 15th February meeting minutes. https://lists.oasis-open.org/archives/xliff/202202/msg00004.html

R: I second.

L: Meeting minutes approved.

B. Approve 1^st March meeting minutes (informative meeting). https://lists.oasis-open.org/archives/xliff/202203/msg00000.html

Y: I second.

L: Meeting minutes approved.

 

II. Technical work

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

L: We will have this discussion in the next meeting when David will be here.

R: This issue is assigned to me on github. I will assign it to David.

 

B. Clarify validation of core elements in modules (Issue 9). https://github.com/oasis-tcs/xliff-xliff-22/issues/9 David.

L: We can also move this discussion to the next meeting when David will be present.

 

R: I have found out a similar issue in the current spec, but I do not have an easy solution for it.  I would like to discuss it.

If you have a <unit> with TM matches, you can have an <originalData> element at <unit> level and another one inside each <mtc:match> element. Inline tags that have “dataRef” attribute in a TM match should point to the <data> children of the <originalData> in the enclosing<mtc:match> but the specification only says that “dataRef” points to a <data> element at <unit> level. This renders the <orignalData> child of <mtc:match> unusable.

Currently, Trados Studio 2021 considers that if “dataRef” points to a <data> element in a match it is wrong because the specification says it should point something at <unit> level. Trados Studio is right according to current spec, but we need to do something to properly handle inline tags from TM matches.

Depending on what we do, we might break the backwards compatibility.

Y: Id should be unique within unit. In <mtt:match>, the data might be different from the original data. That would be a problem.

R: Yes, you can have a match from xml and the original data coming from html.

Y: in this case you need to compose the data for <mt:matches>.

R: If you have ten tags in the match, where do you put the corresponding <data>?

R: My temporary solution is to duplicate the data in the match and in the unit, but duplicating data like this is crazy. There are risks of having elements with the same “id”.

Y: you could include this in our github repository to open the discussion.

R: this means that we might have some problems with backwards compatibility as some tools like Trados have already implemented tag handling.

B: Let’s put the data at unit or match level, letting them choose.

R: that will resolve the problem.

R: I send my file to Trados and it will say that my file is not valid if they only support 2.0 or 2.1. I am not sure what solution to implement. Original data as it is, is useless in the mt:matches.

B: These compatibilities have come up from time to time. For example, in DITA.

R: Yes, in DITA, they published errata in those cases.

B: I do not think I have never done that.

R: For XLIFF, I do not remember. I will add an issue in github. What would you put as possible solutions? Errata?  This is also related to issue 9. The text is missing, we need put some text there.

R: Should I create a new one issue or redefine a new one?

Y: if you have edit rights, you can edit it.

 

C. Guests invitation, next informative meeting. Lucía

L: I have invited two localisation engineers/specialists to the next informative meeting. I will provide some point of discussions for that day.

 

D. Provide a way to associate <note> elements with <segment> elements (Issue 4). https://github.com/oasis-tcs/xliff-xliff-22/issues/4  Rodolfo

R: (Rodolfo goes to the historical of the issue and shows the discussion on github. He shows the summary of the discussions that were taking on that matter, this summary is also on the issue discussion in github) We approved to make changes in the schema. David disagrees and stated that he will always oppose to this.

B: If I recall correctly, he also mentioned that we do not currently have enough representation in the TC. But this is not my view. We still need to make progress. Change needs to happen. In my opinion, we need to move forward, I am open to making changes.

R: I agree with you. To progress, we need to make a decision on this issue.

B: I appreciate David’s contribution to the TC, so the best way to vote on this item would be to make an electronic ballot. We can have roll call for issues that are straightforward, but this is an important issue.

R: Do you agree on having an online ballot?

B: I second.

Y/L: we agree.

 

Y: My impression on the informative meeting is that we need to move forward if necessary. Individual issues, before deciding, we need to have a discussion. I do not have enough information to understand why he is opposing so much.

R: We have been discussion for more than a year.

Y: I see, I am sorry, I have joined late and I was not present in the initial discussions.

R: My concern is that if we keep arguing and postponing we might never have a ballot. If we do not have a ballot, the discussion will never end. This have been discussed. We either accept or discard this and move on.

Y: I think we had a ballot on whether we could make changes on the core.

R: And we voted on a meeting.

Y: There are two things here: one is core schema changes. We have already had an agreement on that and voted it. The second point is specific to issue (4). We need to discuss these two points separately, the first one, we have already agreed on that.

 

R: we have already discussed issue 4.

L: Yoshito, do you have enough information on the github discussion to vote on the issue?

Y: Yes. My view is from the implementer’s point of view, and I agree with what Rodolfo proposed there.

B: In my opinion, there is no shortage of documentation on this case. Email ballot can be an opportunity to have also an opportunity to attach comments in case of dissent. The ballot is in the core of the XLIFF TC for many years.

R: Ok. (Rodolfo prepares the text of the ballot and all agree on the text and the timeline (2 weeks) for the electronic ballot).

L: Meeting adjourned.