Meeting minutes

Dear all,

Please find below a summary of todayâs discussion.

Attendance:

David, Yoshito, David (has to leave early), Lucia, Bryan, Manuel. We have quorum

I. Administrationâ
A. Approve 2 August meeting minutes. https://lists.oasis-open.org/archives/xliff/202208/msg00002.html â

R: moves to approve previous meeting minutes

Y: seconds

Minutes approvedâ

II. Technical workâ

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

(point not covered in this meeting).

B. Clarify validation of core elements in modules (Issue 9). https://github.com/oasis-tcs/xliff-xliff-22/issues/9 David. See the discussion discussion on the official meeting on May (point E) https://lists.oasis-open.org/archives/xliff/202205/msg00004.htmlââ.

Df: Did you see the changes I put in this github issue? I was looking into the best place where to put it in the spec. I do not know where else to put it. https://github.com/oasis-tcs/xliff-xliff-22/issues/9.

R: We have it in the content but is not visible here.

Df: It is on the id attribute https://github.com/oasis-tcs/xliff-xliff-22/issues/9. It is a note. It would be impossible to impose this. This is the basic assumption. They can ignore modules and extensions. For the xlf id.

R: it is not only that. This only covers one of the issues. For example, mtc:maches.

Df: mtc:matches it has its own scope.

R: We need to put this kind of notes in a more visible place.

Df: the content exists, it just is somewhere else.

R: This is a note for id, but we need to replicate it in different places. Because it is not the only where it is affecting. There are other issues, in mtc:matches, for example.

Df: the problem is the uniqueness scope of the id.

R: we have a problem with mtc:matches and dataRef.

Df: the dataref has its unique scope.

R: originalData had a problem. We can have duplicates when we have matches from tm, and that is a problem. The originalData has a problem with that. We can have duplicates. That is why the note is ok, but we need to have more notes in other places. The originalData element is within the match.

Df: the module has to specify its own constraint. We did modules where matches is clarified. I am going into matches module specification, in the constraints it is speficified in âWhen the xliff attribute is usedââ It is clear.

R: Yes, these constraints clarify the issue. I have encountered real files that do not respect this.

Df: this is a clarification that was added in 2.1. I will add this to the issue, the link to the matches to show that is already implemented.

R: That would be great.

Df: I will close it with this comment.

R. Ok, thatâs good. This item can be dropped from the next agenda.

Df: Quick update about the Message format working group. It is on a development branch, this is the link: https://github.com/unicode-org/message-format-wg/blob/develop/spec/syntax.md. It is working very fast. Next week there will be a meeting and I will be asking for a time frame.

C. Namespace name. See meeting minutes from Januaryâs meeting. https://lists.oasis-open.org/archives/xliff/202201/msg00001.html and February meeting https://lists.oasis-open.org/archives/xliff/202202/msg00004.htmlâ

R: Points C and E can be combined in the next agenda.

L: Ok, I will do it.

D. 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 â

R: we have not voted on this in the last meeting and David has just left.

L: I will add it again to the agenda of the next meeting.

E. Discussed and approved changes in the spec. Rodolfo

R: I have not had the time to implement the changes that were approved in the last meeting. I will do it as soon as I can.

F. New feature requirements?

M: do we foresee any new feature requirements?

R: We foresee that the message format working group will be introducing a module, but we do not have a date. Df will request them a date in the next meeting. We can publish the version and will publish the module when they release it. Unless you need something special, I do not see anything else. We have already pointed out the mistakes that we have already spotted in the previous spec.

L: Agenda for this year. When do you think that we can have a solid draft?

R: We can have a draft for this year, maybe in September. If I implement the notes and the other changes. I can have a working draft. Unless there is any other feature request

L: Rodolfo, the differences between the versions, could you tell us about that?

R: The section is not ready yet, because the changes have not all been implemented. (Rodolfo shows the section with the changes that have already been documented)

L: That is good. It would be also good to have some explanation of the rationale of those changes and why we think they would be useful. For example, the separation of the specs to help implementers, etc.

R: Yes, we need to have it but not on that section. This will be something that we could use in the release communication.

Y: We might create a github tag, where we can include the releasing information where we can have all hat information.

R: OASIS does it, not us. I can create an informal tag for the release.

Y: That is fine, at some point, we would get the contents from here.

R: If you look at 2.1, we have 2.1 and 2.2 in this repository. It is ok, we can take the same article and have it as a release note. I think that we can have these changes this year. Maybe we can make the two meeting per month that count towards voting rights. Unless we are all present like last time. Do you think that we can make the change? It is complicated to have a ballot without this. We can change all the meetings to account for voting rights.

L: This was discussed on the last meeting, but we can make a roll call on this.

B: I second.

R: (roll call text): Should we make all meetings count towards voting eligibility?

Yes: Lucia, Bryan, Yoshito, Rodolfo, Manuel.

L: Meeting adjourned.

xliff message