OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Meeting minutes



Please find below a summary of yesterday’s discussion:



I. Administration

Attendance: Lucía, Rodolfo, Bryan, Yoshito. We have quorum.

Regrets: DavidF.
A.  Approve 6 April meeting minutes. https://lists.oasis-open.org/archives/xliff/202104/msg00001.html 

R: I move to approve meeting minutes

B: I second

R: No objections. Meetings minutes approved.


B. OASIS web site updates - Rodolfo https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff

R: Chet has solved the encoding problem. But I sent Chet an email about the email archives, the problem lies on Kavi side.

-Roster update. David, Yoshito

L: David said he will address the liaison information this week.

Y: I have not done it yet.

-FAQ Section. Liaison information (David)


II. Technical work

A. Migration guide. Rodolfo. I have not worked on the migration guide I have worked on the test suite correction.

I have updated the XLIFF Validation Service, https://dev.maxprograms.com/Validation/ you can use the drop and drop, I have also included the feedback information section. 

B. Test suite correction. https://docs.google.com/spreadsheets/d/1uaQ1oSqhXRkRKXNLvgIwcffvNzhcTj9dIkIN__7EH4o/edit 

I have gone through all the files taking into account the file that Lucía started.

I have noted that many test case that have errors. Should we delete them?

I have also found cases with smechatron errors. [Rodolfo shows an error on his screen]. For example the file “withNotesxlf”. We have these type of schematron errors.

I have also found problems in the support of my validation tool, I will fix it.

B: Do you have schematron expertise?

R: I do not. I have only used it here.

B: Me neither.

R: I know if I learn on this I might use it, but I do not use it anywhere else.

[Rodolfo shows another example where the schematron does not show an error in a file.]

L: We can take this discussion in the next meeting when Df will be here, he was the last person responsible for the schematron. And if he cannot solve this, as you mentioned two months ago, we could discuss the possibility of dropping it.

B: I agree. If we cannot support a feature, we would be better off dropping support, unless David says that he has the resources to support it.

Validation questions:

1. Question about validation of an untranslated segment. https://lists.oasis-open.org/archives/xliff/202104/msg00020.html

R: In my point of view is valid, but the schematron is an error.

Y: I believe it is valid.

2. Pointing to notes outside current unit. https://lists.oasis-open.org/archives/xliff/202104/msg00021.html

R: This is a problem with the definition on the comment annotation. This forces you to have the comment in the same unit. In the case that there is a point for changing .This would force you to have repetitions.

L: I think that you have a point there, that would solve the problem with repetitions.

B: I think that there is a strong case to have it outside the unit. There has been a discussion on whether units can be standalone or not. People that were afraid that they could be standalone.

R: It is a matter of making a change. How do you refer to a note? Normally using the identifier. That is a simplification. The pointing to the note is the problem here. That is the case that I try to fix.

3. Pairing isolated with . https://lists.oasis-open.org/archives/xliff/202104/msg00022.html

In this case, it is another identification issue. We do not which id are we referring to.

B: We have a long precedent for not requiring unique ids, which can be troublesome.

R: The id should be unique within the file. This is a problem that we need to fix.

B: that is because is nmtoken.

R: Yes, but we can say that they need to say that they need to be unique within the file element.

B: We can have multiple files, so that would solve the problem.

R: Yes, but it would work within the same document. The file element contains the document. It is a matter of scope.

B: Do we have a strict requirement of the file element. The scope can be a document, but it can be something different.

R: Yes, if we use the fragment identifier we would be making it unique. It is a matter of changing some definitions here.

We have a problem matching here. Where to point to, that is the discussion we had with discussion. It is a similar problem that is related to the one that Yoshito mentioned.


C. Online technical discussions:

-ref value in translation candidates module element . Yoshito. https://lists.oasis-open.org/archives/xliff/202104/msg00002.html

R: We have to set a criterion to make it uniform. I have been doing some tests. I know that some people are using it to point segment. With Yoshito, we were talking about making it optional. We also talked to pointing to the target, which is possible but I am not sure if it is a good idea.

Y: Do we use a github issue to track discussions for this type of issues?

R: There are some issues in github. I have added an issue about the note. It is only us looking at github.

B: We have historically used the mailing list.

R: Only members that are members of OASIS can comment there, and to make changes it is only David and I who have the rights to do it. I do not think it is a good idea to use github because it is restricted.

B: we should be able to keep an open system than can be consulted.

Y: In another project that I collaborate, we have documents shared and we have mailing lists. But the actual work is done through internal documents. When making decisions it is easier to make those discussion on internal google sheets.

R: Lucía used this google sheet [Rodolfo shows the google sheet where the test suite results are tracked. But I also sent three emails to the mailing list because fixing the test suite is one thing but we need to address the problems with the specification.

R: I have uploaded a draft of 2.2, if we decide to make a change I can quickly make it there.

Y: Usually this type of communications. I think the best way to address them are: here are the issues, here is the proposal. We should give a deadline so we can collect feedback within a limited timeframe.

R: I think I can change my questions to proposals.

Y: So it is a clear what you are doing.

R: Just to give you an idea. I have sent a message about the release of my tool in linkedin, 700 people saw it but no feedback.

Y: In other committees, we only receive very few feedback while working, and when we release the idea, it is there when we get the complaints. But I believe that if we do not get any feedback, then the tc decides.

R: So in the discussion we had, what would be your solution?

Y: For the matches, I think the segment makes more sense.

R: Ok. I would be make a proposal for that. Would you accept something like that?

Y: We can have a template for the proposal, it would be good to have a deadline to collect information.

L: What about using github to create the proposal and the mailing list to point at it?

R: The problem is that only David and I could work on github, so you would not be able to work there.

Y: In another committee, we have a project folder, and then we share them internally with the members the working documents and when we require feedback, we make them public.

R: We do not have an xliff account for that, we would be using our personal accounts.

Y: we do not need any xliff account. Another approach is to create a google group that can have a folder.

IV. New business

L: No new business, meeting adjourned.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]