Meeting minutes

Dear all,

Please find below a summary of today’s discussion.

Attendance: Yoshito, Manuel, Lucía, Bryan, Rodolfo

Regrets: DavidF.

I. Administration
A. Approve 17th May meeting minutes. https://lists.oasis-open.org/archives/xliff/202205/msg00004.html

R. I move to approve the meeting minutes: https://lists.oasis-open.org/archives/xliff/202205/msg00004.html

Y. Seconds

R: Meeting minutes approved.

B. XLIFF TC Members June-September availability.

L. In order to better organise our meetings in the following months, please use this doodle to provide your availability information https://doodle.com/meeting/participate/id/avg2B5rb

If you have some minutes after this meeting, please fill in the doodle.

II. Technical work

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

L: David has sent his regrets.

B. Requirements for <sc> and <ec>. Issue 15. Yoshito. https://github.com/oasis-tcs/xliff-xliff-22/issues/15 See also discussion from last meeting (point B) https://lists.oasis-open.org/archives/xliff/202205/msg00004.html.

R: Yoshito is in charge from this issue.

Y: This can be closed.

L: Rodolfo, can we remove then this item of the next week’s agenda?

R: Yes, there are some items that can be left out of the agenda: B, C, F, G and E.

C. 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 meeting (point C) https://lists.oasis-open.org/archives/xliff/202205/msg00004.html

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

R: Yoshito, you were going to provide the example and I was going to include it. The text in the spec was corrected. (Rodolfo shows the change in the spec).

I was thinking about changing the “if and only” in the rest of the spec. There are 9 cases. Do you agree?

M: I do.

L: I agree, I suggest that an issue is created for this, so we can have all the 9 cases in an issue. We could discuss it and vote it in the next official meeting. I will add it to the next week’s agenda.

R: Sure, I will add an issue and assign it to me.

Y: Does OASIS have any type of definitions of this type of wording?

R: Not for “if and only if”. You can find it in many specs.

E. Change existing reference to BCP 14. Issue 16. David https://github.com/oasis-tcs/xliff-xliff-22/issues/16 https://tools.ietf.org/search/bcp14#:~:text=BCP%2014%20-%20Key%20words%20for,use%20in%20RFCs%20to%20Indicate%20Requirement%20Levels David. See the end of the point D discussion from the last meeting. https://lists.oasis-open.org/archives/xliff/202205/msg00004.html

R: David created the issue in GitHub. I have to modify the text.

L: Can we close this item?

R: Yes.

F. 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 meeting (point E)

G. Version attribute. See the discussion on the last meeting (point F). https://lists.oasis-open.org/archives/xliff/202202/msg00004.html.

R: We can close this issue. It will be documented in the track changes of the new spec

H. 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

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

R: We need to decide what to do with the schematron. If we make changes to the spec, the schematron needs to be also updated if we want to keep it

B: is the schematron part of the advanced validation module or just an artefact?

R: It is just an artefact. There are many issues in the schematron as it is.

B: In the official meeting, we can have a vote on the confidence on the artefact. Personally, I do not see why the TC should support an artefact that does not have official status.

R: In the current spec, the schematron is not mentioned as an official additional artefact. It is not part of the spec. I agree with you, we might have to do a ballot for this.

L: I second.

R: Manuel, have you ever worked with schematron?

M: No, I have never worked with it.

R: The ones that we have now, they need to be rewritten.

Y: A schematron is a validation method, is similar to DTD and schema, with more processing requirements.

R: There are things that you cannot validate with schematron. For example, the language code. It is a common problem in XLIFF files.

R: In the schema, we have a warning saying that NVDL is not capable of discerning Schematron Errors.

B: I think the goal was that we had processing requirements that could not be tested with schema.

R: I would keep the schemas, and just drop the schematron. We can suggest validation tools, for example the one I created or Yves or even tools like Trados have internal validators.

Y: In general, what do we need to do to maintain the schematron?

R: first, you need to learn how to code schematron files, and even if you do, there are things that the schematron cannot do.

Y: If we are working on the 2.1 versions, changes might be minimal to implement.

R: the problem is that the current schematron also has issues, we have documented in the excel file that Lucía created a list of issues (Rodolfo shows the list of errors that were documented). I would prefer to work on working on making strong test cases that would be useful for people that need to implement it, for example.

Y: Should we move the schematron out of the main repository? And isolated in a specific place where somebody could work if they want to implement it?

R: In the server, we have 2.1, 2.2, and merger. We can move the schematron to 2.1, it will be there. If they want to updated in the future for 2.2, it will be possible. We can move the schematron outside at the same level of merger.

M: What does the merger do?

R: We write the spec using docbook, and the spec is made of hundreds of docbook files. The merger unifies all those files into one. In order to publish, we need to create a single one. From the merged xml that is created, we create a pdf and a html. It is too large to work on a single document, it has more than 15000 lines of code. We use a small version that pulls all the details from all the documents. The merger code does this.

L: Do we want to keep also the test suite files?

R: Right now, we have the 2.1, we need to fix them and publish the 2.2.

J. New feature requirements?

R: Yoshito had two proposals, but you never created the issues, so we can vote and maybe approve them. The metadatada and note element at xliff level

Y: Ah, that is right.

Y: Did we used to create issues before the changes?

R: I agree and I like your idea, but we need to have the issues so we can vote them.

Y: I will create the issues before the next meeting.

L: No new business. Meeting adjourned.

xliff message