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.