Description:
https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/202007/msg00005.html
==========
Agenda:
I. Administration
A. Approve 15-September meeting minutes
https://lists.oasis-open.org/archives/xliff/202010/msg00001.html
B. Review Action Items
C. Standards-based representation of term translations based on XLIFF 2.1 Resource Data Module (and Linguistic Linked Open Data) in XLIFF 1.2 (Rodolfo)
Christian commented:
https://lists.oasis-open.org/archives/xliff-comment/202009/msg00000.html
Which was a follow up to his post in July
https://lists.oasis-open.org/archives/xliff-comment/202009/msg00000.html
II. Round table
A. Lucia
B. David
C. Rodolfo
D. Yoshito
III. Subcommittee and sister TC reports
A. Promotion and Liaison SC
B. XOMOS - Sister TC
IV. New business
==========
Minutes:
Agenda
I. Administration
Attendance: Lucia, Rodolfo, Yoshito, Bryan, David.
B: I propose to approve 18-August meeting minutes
https://lists.oasis-open.org/archives/xliff/202008/msg00021.html
R: I second.
B: Meetings approved.
B. Closed/Modified Action Items
- Action Item "Provide test files for ITS text analytics in ITSM" Modified
- Action Item "Proposal For Change Tracking in XLIFF 2.1" Closed
- Action Item "Verify that namespace re-writing is well addressed in ITSM
- Action Item "Verify that ITSM Elements within text conforms to XLIFF 2.0
- Action Item "ITS text analytics" Modified
- Action Item "allow inline elements in change tracking" Closed
- Action Item "Errors in XLFF 2.0 test suite files" Modified
- Action Item "ITS storage size restriction" Modified
- Action Item "Errors in test suite for Change Tracking module" Modified
- Action Item "Errors in XLFF 2.0 test suite files" Modified
- Action Item "CTR test suite files" Closed
- Action Item "Errors in test suite for Change Tracking module" Modified
- Action Item "Errors in test suite for Change Tracking module" Closed
- Action Item "ITS storage size restriction" Modified
- Action Item "Question on namespace re-writing and ITS text analysis" Closed
- Action Item "Review "XLIFF and ITS mapping- Elements within text "" Closed
- Action Item "Create new CTR 2.1 test files (w/inlines)" Closed
B: David is not here to confirm it. But we assume that they are closed.
R: There are some that are modified but not closed.
B: I assume the closed items are either closed or no longer applicable. If the action item but we do not have anybody to work on that, so there is a gap.
R: For example, the ITS storage is still opened but it does not have an owner. Today we have there AI with owner and one without owner.
[David joins the meeting]
D: My action item last meeting was that, I went through all them, I have left the ones that are relevant and closed the ones that did not seem relevant or did not have an owner. I left a couple opened on the OASIS system and those are not on the critical path to the new version. So everything that is open now is either transferred to github.
R: I noticed that there is one without owner.
D: I put the open ones with the due time by Christmas this year. And yours are basically to transfer to github. So, basically when they will be done in github, you can close them here. The errors in XLIFF 2.0 test suite files, I think there is no point to move them to github. I am happy to own that, to propagate the changes to SVN. I did not put an owner because we did not have one. The goal of 2.1 was to provide native support of ITS. Currently the spec says that for this data category it does not give an implementation method. The options are to close it because we do not have an owner, or to transfer it to github. So do we want to kill it or transfer it?
R: we do not have an owner, we can leave it here.
Df: for the time being we can leave it open here.
Df: I really just left opened the ones that were opened.
B: So this point is resolved in this meeting.
C. Standards-based representation of term translations based on XLIFF 2.1 Resource Data Module (and Linguistic Linked Open Data) in XLIFF 1.2 (Rodolfo)
https://lists.oasis-open.org/archives/xliff-comment/202009/msg00000.html
[Bryan explains the discussion on the email thread]
B: I agree with Rodolfo’s comment.
R: This was an interesting conversation. This is a current topic. They are trying to use 1.2 with features of 2.0 instead of migrating to 2.0. It shows that 2.0 is not the preferred option.
B: I would ask them why 2.0 is not being implemented.
D: From the point of view of the TC, 2.1 is the latest version.
R: That is the thing, that is the important thing here.
B: we though that by making the XLIFF 2.X certifiable in favor of using modules. But the evidence shows us otherwise. XLIFF 2.0 being completely extensible. The implementation standards are more harder. Interesting observation.
D: From the point of view of 1.2, you can extend it as you like. The fragment identification of 2.0 were never intented to work 1.2, if people do that, they will produce valid 1.2. There are intended to cooperate with 2.0 core not to 1.2. I think it is out of the scope of this TC to define how to use 2.0 modules with 1.2.
R: Exactly, but it is worrying that they are still using 1.2. During the pandemic, I migrated Swordfish to 2.0, and really I noticed a few things: 2.0 is not difficult to use, it has a few problems in the way it was defined (like the fragment identifier), as a developer it is very difficulty to implement it.
D: Even the legacy version, did not use the XML id. You do not have unique ids. We had to create our fragment mechanisms.
R: I understand it. But from the point of the view of the developer it was not necessary. There was no need to complicate things from referencing. That is what found from my experience. In my case, I ended up ignoring the frag identifiers and use the ids instead. There are other things that I found more comfortable with, for example, terms, they are stored at the unit level instead that at the segment level.
R: Yes, but from the point of view of implementing them internally, it is very difficult. But when you are moving away from the spec to match with your internal database is very difficult.
D: Segment has an id.
R: You can be flexible in segmentation, but still have matches. Until there is a mixmatch in the XML model. I am telling you what the problem is, so we can facilitate the implementation.
D: We decided that segment is not extensible.
R: It does not need to be extensible, but it practical from the point of view of the developer to have term and segment at the same level. The conversation started with the adoption. Christian is putting the data where is needed. Maybe is not the complete reason why people are not adopting. These are things that can be modified and improved to simplify the adoption.
D: that will break the 2.0 core. You will bring all the problems that trans-unit had. This was resolved after years of discussion.
R: Ok, but I am telling you an adoption problem.
D: we need more representation to discuss these things. I think we really lack implementation guides. We probably need a modification guide. And the pro and cons. I understand your pain. This is what the TC decided, this is the core of 2. I know implementers that are outside this TC, we have to boost representation.
B: Good discussion, we definitely need to attract the community. Another observation is that the localization community can be comfortable with the previous version, and changes are slowly implemented. For example, the LISA standards are still in the community.
D: I am working in the localisation standard reader. The TBX produced a new version.
R: It is a clever version.
D: I spent many hours in that committee, and the inline markup follows the 2.0 vocabulary. The core is very small. It is also accessible outside from ISO. Other than that, nothing really happened to the LISA standards.
R: Bryan has a good point. TMX, SRX work and that is why they are still used.
B: However, in the case of XLIFF, the problem was the different flavours that go against the standarisation.
R: You are right. The problem is that some developers have 1.2 already working for them.
B: We had this discussion with Lionbridge, they are able to input and output 2.0 even if internally they use other format.
R: And others do it too.
R: The problem with 1.2 is that proprietary markup was allowed, and 2.0 has the same defect.
D: But we stated that if something should be in the core cannot be in the module and vice versa. The only interoperable thing that remain interoperable is source and target.
R: that obstacle was not removed.
D: I think it goes in the right direction. The industry was always slow to adopt. I really like differentiate internal use and use of transferring exchange amongst agents.
B: I agree. The next action item is that I should respond to Cristian why they are not using 2.0. The proper thing would be to discuss this in the XLIFF PL subcommittee.
D: Due our current number of members. We could concentrate our efforts in creating an adoption guide instead of working on the new version.
D: I will report on the new implementation in GALA and the message group.
Y: Some stablished tools like android and mac, they producing 1.2. So localisation tools should support 1.2. The messaging group and their work would be a good thing to push the 2.0 adoption.
D: I agree, thank you.
==========
Attendance:
| Meeting Statistics |
| Quorum rule |
51% of voting members
|
| Achieved quorum |
yes |
| Individual Attendance |
Contributing Members: 4 of 23 (17%)
Voting Members: 4 of 5 (80%) (used for quorum calculation)
|
| Company Attendance |
Contributing Companies: 3 of 12 (25%)
Voting Companies: 3 of 4 (75%)
|