< Return to Calendar

* XLIFF TC Meeting (Conference Call)
Name * XLIFF TC Meeting (Conference Call)
Time Tuesday, 23 June 2020, 11:00am to 12:00pm EDT
(Tuesday, 23 June 2020, 03:00pm to 04:00pm UTC)
Description

New dial-in link at this action item.

https://www.oasis-open.org/apps/org/workgroup/xliff/members/action_item.php?action_item_id=3921

Minutes

Agenda

I. Administration

Attendance: Bryan, Rodolfo, Lucía.

We can switch to Microsoft teams, it is free now.

A. Approve 26-May meeting minutes

https://lists.oasis-open.org/archives/xliff/202006/msg00000.html

R: I move to approve the meeting minutes.

B: I second. Meetings approved.

 

B: I move to change to Ms Meetings.

L: I second.

R: I can send an invite from my meetings account.

L: I have never used, but if it works, I am for it.

 

 

II. Where do we go next?
A. XLIFF 2.X or 3.0 wiki space for new features (Bryan)
RESOLVED

B. Rendering Requirements for XLIFF 2.2 - David
https://lists.oasis-open.org/archives/xliff/201901/msg00001.html

R: This item is not resolved. As I demonstrated it during last week, it can be done already in some tools. The standard is not an obstacle.

B: This could be working paper, not something we should put in the spec.

R: Or at least it should not be normative.

B: We can wait for somebody to propose it as a working paper.

R: That is ok.

 

E. Invalid sample files identified by Rodolfo Raya

R: there are things that go beyond the files. The validation method was the issue, because the schematron has issues. We have not decided whether we should fix it or drop it.

B: I say that we can fix it. Unfortunately, we do not have anybody to do it now.

R: I can take care the XSD. But I do not really up for the Schematron. It is more expressible, but not all parsers support schematron.

B: The reason as I recall it, is that the validation module could not be covered by XSD.

R: I understand the reason. The problem is with its practical implementation, as parsers do not support it.

B: I think that we will benefit from David’s presence in this discussion.

R: David wants to fix it. Ok, fix it, I cannot fix it. This can be delayed, if it is not ready when we the other features ready, we can decide what to do.

B: We can have this conversation when David is present.

R: I understand that he wants to keep it, and his reasons are valid. My concern is the time, we are meeting once a month, for the last six months nor a single line of the spec has been written.

B: I agree with your concerns. We are having issues attracting numbers to move forward.

R: I would suggest something but that is not up to me. We introduce the features that are already are. And start writing and put the code that we have in place for public discussion. At least we can start publishing the draft.

B: I like that, you are proposing an agile methodology. Which is related with the problem that we have attracting more people. One solution would be nominate Rodolfo as secretary and giving him the capability to make edits to the spec and the XML schema in real time. To have a working draft that we can publish and discuss.

R: Yes, and if you are using something like Ms teams. We can share screens and make changes in real time. If you want to attract people, you need to show progress.

L: I totally agree with this direction.

B: we can start an email thread in the mailing list of stating this new way of operating. I can do that, I am having an issue with my email, as soon as I fix it, I can send it.

R: Ok. I have a problem with my email. I need to use the web interface every time.

B: I want this to be public. I see this as a very positive move. And if anybody disagrees, they can publicly say it.

R: That seems reasonable.

 

F. XLIFF calls, Steven Loomis
https://lists.oasis-open.org/archives/xliff/201912/msg00000.html

G. Features, Steven Loomis
https://lists.oasis-open.org/archives/xliff/201912/msg00001.html

R: When I mentioned the RSX module for segmenting XLIFF, David said they meant something different. I send him a note but I did not get a reply. I can volunteer is to put SRX as a module, but if it is not what is needed, I do not know what do to.

B: I can check with Steven. If he does not have time to respond, we can go back to your proposal Rodolfo.

R: What I can propose is not difficult to implement. We can only use it when the xliff file does not have target. That is the limitation.

B: That makes sense.

R: I tried it and it did not work.

B: I can review it.

R: The code is already there and is open source.

B: I have an intern who can exercise your utility, we can give you feedback.

R: That would be good, let me know if you could see any possible improvement.

 

H. FragID prefix registration, Rodolfo
https://lists.oasis-open.org/archives/xliff/202002/msg00000.html

R : the wiki says you must register your prefixes, but the standard does not say so. I suggest that we make in the specification a requirement for this; otherwise, we cannot validate it.

B: That makes sense to me.

R: I put the links in my email. You will see the links for wiki and for the specification.

B: Ok. We should change that in the spec. Rodolfo, I will make you the owner.

III. Subcommittee and sister TC reports
A. Promotion and Liaison SC
B. XOMOS - Sister TC

L: The PL has not meet. And, I am not aware about the other one. I have joined the Message format working group https://github.com/unicode-org/message-format-wg that David mentioned in the last meeting. One of their goals is to create a specification for a one-to-one mapping between the data model and XLIFF. I will try to join the next meeting and keep you updated.

B: it seems interesting. I made contact in Ryan King from Ms he was interested in knowing native support of XLIFF 2.0. I think it would be nice to have that information in general.

R: There is not any place as far as I know. In my research, I can tell you that is supported. Memsource does it. I can tell you that the next version of Swordfish will have XLIFF 2.0 native support.

B: that is good news Rodolfo.

IV. New business

B: Meeting adjourned.

 



Agenda

I. Administration

 A. Approve 26-May meeting minutes

https://lists.oasis-open.org/archives/xliff/202006/msg00000.html

 B. Meeting availability in light of COVID-19

II. Where do we go next?
 A. XLIFF 2.X or 3.0 wiki space for new features (Bryan)
 RESOLVED

 B. Rendering Requirements for XLIFF 2.2 - David
 https://lists.oasis-open.org/archives/xliff/201901/msg00001.html

 C. GALA TAPICC XLIFF Extraction and Merging Best Practice v1.0 Allison
 https://lists.oasis-open.org/archives/xliff/201901/msg00003.html

 D. New comment from Yves
 https://lists.oasis-open.org/archives/xliff-comment/201911/msg00000.html
 Issue #34: Lynx - XLIFF files created with missing subFlowsEnd attribute and found Valid (okapiframework/xliff-toolkit)

 E. Invalid sample files identified by Rodolfo Raya

 F. XLIFF calls, Steven Loomis
 https://lists.oasis-open.org/archives/xliff/201912/msg00000.html

 G. Features, Steven Loomis
 https://lists.oasis-open.org/archives/xliff/201912/msg00001.html

 H. FragID prefix registration, Rodolfo
 https://lists.oasis-open.org/archives/xliff/202002/msg00000.html

III. Subcommittee and sister TC reports
 A. Promotion and Liaison SC
 B. XOMOS - Sister TC

IV. New business

 



Submitter Bryan Schnabel
GroupOASIS XML Localisation Interchange File Format (XLIFF) TC
Access This event is visible to OASIS XML Localisation Interchange File Format (XLIFF) TC and shared with
  • OASIS Open (General Membership)
  • General Public