Meeting minutes

Dear all,

Please find below a summary of todayâs discussion.

Attendance: Rodolfo, LucÃa, David, Yoshito, Bryan.

Regrets: Manuel.

I. Administration
R: I move to approve 3^rd May meeting minutes. https://lists.oasis-open.org/archives/xliff/202205/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.

I did not have time to work on this.

B. Requirements for <sc> and <ec>. See the original question https://lists.oasis-open.org/archives/xliff/202204/msg00023.html, the discussion with Rodolfo on the mailing list https://lists.oasis-open.org/archives/xliff/202204/msg00025.html and the discussion on the last meeting (point B)https://lists.oasis-open.org/archives/xliff/202205/msg00001.html

Y: I have just created an issue for this one (15).

R: It is quite clear, we need to decide what to do with it.

Df: There is a copy-paste error. âthe attribute isolatedââ, it might be elsewhere in the issue.

R: it is not a big issue.

Y: I need to add the code with the brackets.

R: You can use the preview option to see if the code is properly displayed.

Df: what is in target is driven by rules, you need to check if the corresponding attributes are in the source. This is related to the state attribute.

R: the first segment is translated.

Df: I see. The problem is that sc should be marked as isolated.

Y: I wanted to make this example valid. At this moment, depending on how to read the specification, you need to add the âisolated=âyesââ. During a translation process, sometimes you do not have the target.

R: Clearly this sentence is right. What I am not happy with the sentence that only applies to <source>, but it can apply to target if the state value is not initial.

Df: I agree with it. It is kind of tricky.

R: If you add that text, I can adapt to the specification.

C. Use of fs:fs/fs:subFs in <note> element. Yoshito. 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/msg00001.html

R: Bryan, I do not know if you have seen Yoshitoâs discussion on this topic.

B: I am still having issues not receiving the messages from the mailing list.

R: you cannot add fs in note.

Df: you can format it as <a> and then format it.

B: The issue is with the use of fs in note.

Df: I think it is perfectly fine.

B: we have a processing requirement that does not allow us to scape elements. It is designed to do something but then we discourage it.

Y: note element is fs allowed. I understand Davidâs points. I feel that it is awkward, not wrong.

Df: note is xliff commenting method, it is meant for human readable messages. It does not have the same formatting capabilities. So of course, fs is limited. But you can look at the html elements are allowed, it is a hint for styling, it is not an interoperability thing. I do not think any change is needed.

R: I do not want to add inline elements to notes, it would be a mess.

B: we should just allow the fs.

Df: fs is a preview mechanism. It is ok to style the note. At least to give a hint. It is limited but it is intended so.

B: I think the use of fs without fs, is not the goal of that module.

Df: you can still use an element that allows for formatting and helps to style the preview.

Y: my impression is that when I look at this, this functionality is very limited. It might not be a part of the spec, but an example of a use case.

Df: I think we all agree that we do not want to allow inline in the note element. I would suggest we can add a note in the fs module to express.

Y: more importantly, I would include a use case.

Df: yes, you can group notes.

R: Do you know any tool that currently supports fs?

Df: I think Trados is using fs as a request of the EC.

R: It partially supports 2.0. It does not support matches nor notes.

Df: their internal format is still xliff 1.2, they use 2.0 for interoperability. I can volunteer to write the note warning. But I would not have time to create an example.

R: This is not critical, it is a limitation.

Df: Exactly, I am suggesting to add a note in the fs module.

R: I would put it in the note element.

Df: for me the natural place is the fs module, but it can be also close to the constrains in notes.

R: I do not think we need to do anything here.

Df: you can add a sibling note.

Y: I think that explanation can go to the fs module.

R: I think it can be also in the note, it might be logic to have it in here.

D. Processing requirements for state attribute. Yoshito. See the original question: https://lists.oasis-open.org/archives/xliff/202204/msg00006.html, the discussion with Rodolfo on the mailing list https://lists.oasis-open.org/archives/xliff/202204/maillist.html and the discussion on the last meeting (point D) https://lists.oasis-open.org/archives/xliff/202205/msg00001.html

Issue 14 in Github. https://github.com/oasis-tcs/xliff-xliff-22/issues/14 Yoshito

R: Yoshito, I also created an issue for the state attribute that we discussed last meeting. I have modified the text according to what was discussed last meeting.

Df: The âmustâ should be in the style. We used the style for that. The other part is using caps. You should use capitalised âcanâ too and use âMAYâ instead. The stylesheet needs to say that this needs to be capitalised.

R: in the new official stylesheet, glossterm is no longer capitalised.

Df: this is the way that machine can identified.

R: Yes, the stylesheet does not change them to uppercase, we need to change them in the source. I will search and replace all glossterm elements and capitalise.

Df: I believe the changes you made is equivalent. It is very important that the glossterm are capitalised.

R: If you are happy with this change, we can leave it as it is.

R: With that change, then Yoshitoâs example is valid.

Df: I would like to keep the right to sleep on it, but it looks like the same the logic is maintained. Do you keep the change log?

R: I have started modifying the log change today.

Df: For this one, it is important to record that is only a clarification, that is not really a change in the meaning of the spec.

R: I do not know how to make the difference between the core and the extended version.

Df: Can you look for BCP 14?

R: (goes to âKey wordsâ) It is not there.

Df: Good, you need to change the existing reference to âBCP 14â. https://tools.ietf.org/search/bcp14#:~:text=BCP%2014%20-%20Key%20words%20for,use%20in%20RFCs%20to%20Indicate%20Requirement%20Levels

R: Can you open an issue to change that?

Df: I can do it yes.

R: it is not a big change, it does not change the way we use xliff, it only changes the way we write the spec.

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

Df: they are part of the module, I understand.

R: there is a problem if you want to use startRef (Rofolfo shows dataRef and match in the spec 2.1). We have the original data in <match>, when we want to point to dataRef, the definition of dataRef does not point the match, only the unit.

Df: we need to clarify it in the module. I am not sure is a problem. It just needs a better description on the spec.

R: the bad news is that the implementation of Trados does not like it. It creates interoperability issues.

Df: It is their problem.

Râ: It is also my problem, because my files are not well supported in their tool.

R: I can write the dataRef clarification.

F. Version attribute. See meeting minutes from February meeting. https://lists.oasis-open.org/archives/xliff/202202/msg00004.html. Rodolfo

R: Last time we talked about having the enumeration and accept the following values 2.0, 2.1, 2.2.

Df: I remember the discussion we had. I am split between the enumeration and the pattern.

R: The problem with the pattern is that 2.3 would be valid.

Df: that is the idea.

R: But when we will create 2.3, we could add the enumeration.

Df: For the long term, it might need less maintenance.

R: I am thinking about the validation code. It is easier if you have the enumeration. XML parsers do not like the pattern, but they are happy with enumeration.

L: For historically reasons, we used to have enumeration in 1.2 and that did not cause any issues.

R: You are right, it did not.

R: any objections?

Df: I do not object.

R: Ok, so I can make the change.

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

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

Df: I do not have much time, I might try to recruit somebody to this task

I. New feature requirements?

III. Subcommittee and sister TC reports
B. XOMOS - Sister TC

Df: I could not attend last meeting. They are doing some steady work.

L: Meeting adjourned.

xliff message