Meeting minutes

Dear all,

Please find below a summary of todayâs discussion.

Attendance: Rodolfo, Yoshito, LucÃa, Manuel (we have quorum)

Regrets: David F (doodle), Bryan

I. Administrationâ
A. Approve 7 June meeting minutes. https://lists.oasis-open.org/archives/xliff/202206/msg00003.html

L/Y: I second.

R: Meeting minutes approved

B. XLIFF TC Members June-September availability.â

https://doodle.com/meeting/organize/id/avg2B5rb?authToken=bHVjaWEubW9yYWRvQHVuaWdlLmNoO0x1Y2lhIE1vcmFkbw%3D%3D.rE5qkeeVRXmEo09oJp

L: Thank you for providing your information. It looks as it will be fine for the next meetings. In my case, I am not sure if I will be able to attend the next meeting, but I will try to do it.
Y: I had not sent the information to that doodle because I was not sure about my dates at that time, but I will be available for the next meetings.

II. Technical workâ

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

R: David is not here to discuss this point.

B. Use of fs:fs/fs:subFs in <note> element. Yoshito. Issue 17. See the original question: https://lists.oasis-open.org/archives/xliff/202204/msg00004.html and the discussion on the last official meeting (point C) https://lists.oasis-open.org/archives/xliff/202205/msg00004.htmlââ

R: This was already discussed and agreed in the previous meeting. We are not making changes. So we can remove it from the agenda.â

C. Processing requirements for state attribute. Issue 14 in Github. https://github.com/oasis-tcs/xliff-xliff-22/issues/14 Yoshito. See the original question: https://lists.oasis-open.org/archives/xliff/202204/msg00006.html, and the discussion on the last meeting (point D) https://lists.oasis-open.org/archives/xliff/202205/msg00004.htmlâ

Yoshito was going to provide an example and Rodolfo implement it.

R: I have clarified it in the specification (Rodolfo shows changes on the screen). We discussed this, David agreed on the change. âWhen the optional xliff attributeââ I removed the âif and only ifâ that was not clear.

R: Yositho, is it clear? You were the one who opened the issue.

Y: Yes, it is. I can comment it and close it.

R: I have also modified the text that was pointed out in Issue 15, also from Yoshito.

Y: when you update the description, you create a pr.

R: I just do a commit.

Y: If you put an issue number with pound, then github put a link with the issue.

R: There is a problem with that. Today I made a change that affected more than 100 files.

Y: It would be good to have a specific commit for specific issues. If you update the description, then the link would be through the corresponding issue. So it would be easy to understand the changes that were done.

R: There are so many changes that affected so many files.

Y: That is fine, but last time you updated the state attribute, is it a separate commit? If the comment contains the issue number, it is automatically linked. I am talking about github not desktop. When you commit locally.

R: I am not working locally. I put a comment.

Y: you need to add a pound with the issue.

R: I know what you mean, but it does not always work. If I do it from Oxygen it might not work.

Y: I do not know the git integration of Oxygen.

R: Yes, but it gets removed sometimes.

Y: Git preserves the pound.

R: I know, but depending on the tool I use, it might be removed.

Y: That is strange, it should not remove information from git. In my projects, they all get preserved.

Y: my point is that when we say that something was fixed, outsiders might not be able to understand what has been changed and where.

R: I use diff.

Y: As you are producing the files. The parts that are modified can be highlighted.

R: with docbook you cannot do it, with DITA you can.

R: I have modified the change that was proposed by David. In previous versions, David used lowercase. Capitalisation was lost with the new stylesheet. Now I had to modify from lowercase to uppercase.

L: Are you including a Change Tracking section all these changes?

R: Yes, the ones that are not included is because they have not been approved yet.

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

E. 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: I have started making changes on the schema, I have not committed them yet, you cannot still see them in github.

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

R: In the last meeting, Bryan proposed to have a ballot for the next official meeting.

L: Yes, he talked about a confidence vote, see previous meeting minutes https://lists.oasis-open.org/archives/xliff/202206/msg00003.html (section I), I can add a point for that in the next agenda, so we can vote on this topic during the official meeting.

G. New feature requirements?âYoshito was going to create two issues, so we can discuss and vote on them (metadata and note element at xliff level)

Y: I have not had the time to do this.

L: It would be great if you could have the issues created by next meeting, so we can vote on them as it will be an official meeting.

Y: I will do it.

New issues

R: I have found that xs:language in XML Schema. The attribute that is present is lang. xs:language was create as an enumeration that only includes empty string. I do not know if we should use xs:language or we should switch to xs:string.

Y: what is the value that cannot be used. So that I understand the use case.

R: In our schema, we have defined that srcLang should have xs:language, but xs:language is an empty string. So strictly speaking, in the spec we are saying that this is valid language.

Y: is it inherit from xml:lang?

R: I think we should use xml:lang or string, not really xs:language. In the spec, we say that the language code should follow BCP 47, but in the schema we say that is empty. The schema accepts any value. I have created issue 17 to express my doubt. I do not have a really solution to propose.

Y: Is there is a reason not to use xml:lang?

R: I do not think there is any reason why.

L: and in 1.2?

R: same xs:language.

L: it is a legacy thing then. Has anybody reported an issue with this before?

R: Not that I am aware of, I have just found it today. I do not really know if this is a real issue.

L: no new business, meeting adjourned.

xliff message