Meeting minutes

Dear all,

Please find below a summary of todayâs discussion.

Attendance: Bryan, Rodolfo, Manuel, LucÃa, Yoshito, David. We have quorum.

I. Administrationâ
A. R: I move to approve 5 July meeting minutes. https://lists.oasis-open.org/archives/xliff/202207/msg00001.html â

L: I second.

R: Meeting minutes approved.

II. Technical workâ

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

Df: I do not have any updated news on this.

B. [Erratum] Investigate definitions of srgLang and trgLang attributes. https://github.com/oasis-tcs/xliff-xliff-22/issues/17 Rodolfo

R: This is a common mistake that we have been for some years. The XML schema allows to implement an empty string.

Df: I think since 2.0 is xml:lang.

R: I am talking about schema language. We have language which is an empty string. It is a common mistake that makes perfect sense. I know it is a contradiction.

Df: In XML:lang it allows many languages, but I also validates empty string as the BCP validation rules can be quite complex.

R: (Rodolfo shows the XML Schema). This is just an empty string.

Df: the datatype is xslanguage, we also have xslang in the spec.

R: xslang is defined as an empty string.

Df: it validates as a string. That means that an empty string would also satisfy. We can always attach a constraint to indicate the accepted values.

R: It was an investigation thing, we can close it then.

Df: I agree. It is even available on fora, the regex is available to validate bcp 47 for this.

R: that is a terrible idea, if you want to validate it, you need to make sure it exits.

Df: nobody tries to validate this.

R: I do.

Df: the list is not stable.

R: The list is updated every six months, I update my tools every six months.

Df: we could publish a note with some resources, we would not provide the artefact.

R: It does exist, it is provided by IANA.

Df: it is a list of components.

R: I have the code that does it. You can read and verify my mistakes if you wish.

Df: I believe this IANA. The BCP takes it from ISO.

R: No, it takes more than that.

Df: One of the options is the two-letter code from the library of Congress, and other bunch of things. You can combine the admissible tags with regex, and you would

R: You need different codes: script, language, regions, etc.

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

R: Any updates on this point? you were going to write about this.

Df: I remember that, I just wonder where it would go on the spec.

D. 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 am waiting to know what to do. This is related to the next points that we need to discuss.

E. 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 were supposed to have a roll call to decide what to do with this artefact.

B; We have discussed in a previous meeting that we might not have the confidence nor the manpower to maintain this artefact.

R: It needs to be updated or dropped. David it is basically up to you.

Df: I am going to through the issue list, it is much smaller than described. I think I can have the person to do it. We can input under the OASIS licence.

R: Ok, we need to decide it before the next release, on the previous meeting that we did not have quorum, I discussed with Yoshito a possible deadline and we agreed that we might be able to publish the new version by the end of the year.

Df: I would wait for the formatting group. To have a new feature on the new version.

R: This can take a lot of time. We have already a new feature, separating the code and the modules. And also the new changes that were proposed and accepted during this period.

Df: Separating core and module is not a new feature. Breaking the core is not a new feature.

F. [Core Proposal] Support <notes> and <mda:metadata> for entire XLIFF document #18. https://github.com/oasis-tcs/xliff-xliff-22/issues/18 .âYoshito.

R: We can do a formal ballot or a roll call it.

Df: can you show the proposals?

(Rodolfo shows on the screen Yoshitoâs proposal)

Df: I am very reluctant to making core schema changes.

R: Do you want to make a roll call or a ballot?

Df: We have everybody with voting rights on the call today.

R: We have 5 out of 5 voting members today. We can have a roll call or a ballot.

Df: we can have a roll call.

R: Can we have a roll call to support <notes> and <mda:metadata> for entire XLIFF document #18. https://github.com/oasis-tcs/xliff-xliff-22/issues/18_

B: I second.

L: Do you agree on the following wording:

Do you agree on modifying the specification and the schema to support <notes> and <mda:metadata> for entire XLIFF document?

Df: this change is bigger than ref on note. I would be neutral on this one. I will abstain. This can have an impact on current implementations. I still think that is a very bad idea to modify the core.

Y: there is of course some considerations.

M: If this change is approved? Does it mean that you cannot use notes?

R: No, the opposite. Today you cannot have one note for all files. We are not forcing people to use it, it is optional.

Df: you do not expect notes on the root level.

R: we are making a different version.

L: roll call:

Do you agree on modify the specification and the schema to support <notes> and <mda:metadata> for entire XLIFF document?

Yes; Yoshito, Rodolfo, Bryan, LucÃa.

Abstain: David

(Manuel does not have yet voting rights)

R: I will try to implement this for the next meeting.

G. New feature requirements?

L: David, could you give us an update on the current work messaging group that you mentioned before?

Df: I will communicate with them that there is a sense of urgency to have this new module. Some members could actually join our TC as their companies are members of OASIS.

R: Last meeting was informal, but we discussed that could have something ready by the end of the year.

Df: I could request to them in the next meeting. I am the official liaison.

R: You are not the official liaison. We never had a ballot to designate you.

Df: I have been the official liaison for many years in many other groups.

Y: we can make a proposal, for message group to create the issues in github.

Df: In the past, we had a feature collection method in kavi. We used to have a rendering feature. It would make sense the feature requirements to github.

R: Is anybody going to implement that? Does it make sense if nobody is going to use it?

Y: My understanding is that folks from Google and other companies are going to create some modules, is not it?

Df: there are many moving parts in the messaging format, but how they are going to communicate with the TC is not affected.

R: that is good news, but the question is when?

Df: I can ask them in the next meeting on the 8 of August.

Y: I am also the cochair of CLDR group and serve in ICU. Next release of ICU libraries are coming in October, at this point, I am not seeing any possibility to include the message format in next ICU release. I am not seeing anything coming in the next three weeks. We do have ICU in the Spring release. That is my current observation.

R: the official release ICU will go with or without XLIFF mapping.

Df: it is not a mapping. It will be an ICU implementation, and xliff mapping, it is three separate things.

Y: my understanding is that is does not have any impact on the core. So we can have 2.2 published by the end of the year and then having that module included later. We have already made a big change, separating core from modules. So the module can be released later.

R: I agree with Yoshito.

L: I also agree with Yoshitoâs plan.

R: can we change the meetings status so new members can get sooner their voting rights?

Df: It is not 3 out of 5. It is 2 consecutive meetings.

M: I will make it eventually.

R: My suggestion is making all meeting count.

Df: Consider if you make all the meeting count, you can lose them faster.

R: You are not losing your voting rights as you are an officer.

M: what is the rationale for this difference of meetings.

L: it is a historical reason, some time ago it was difficult to obtain quorum so we decided to have one single meeting per month that was considered towards voters eligibility to better concentrate our efforts. I do not know if Bryan wants to add something to this.

B: That is also my recollection.

M: I personally think that it makes sense to have the rights depending the attendance.

Df: We cannot change the rule of OASIS. At the moment, we have two meetings per month and only one counts for voting eligibility.

M: the change sounds good, I am neutral here. No need to change it for me.

R: I am thinking more general here. I do not see agreement on this.

M: Thank you Rodolfo.

Df: I would say that we can make this actual meeting voting eligibility as all active members are present.

R: This can be done in the system.

R: David, any news on JLIFF?

Df: JLIFF, we are moving slowly, we have three different specs.

L: No new business, meeting adjourned.

xliff message