Dear all,
In the next official meeting (19 October), we will have a roll call on the issue #4 in github https://github.com/oasis-tcs/xliff-xliff-22/issues/4 . As this discussion might have some important implications in the development of the new version, please attend to the meeting if you want to have your voice heard on that day and to take part in the decision.
Please find below a summary of todayâs discussion.
LucÃa
I. Administration
Attendance: LucÃa, Yoshito, Rodolfo, Bryan.
Already approved in the previous meeting: 17th August meeting minutes. https://lists.oasis-open.org/archives/xliff/202108/msg00000.html
II. Technical work
A. Follow up on the discussion about the separation of core and modules in the spec: publication of one spec with core information only to simplify its adoption. How to proceed
with logistics of the preparation of the specs.
-Core & Extended drafts: https://lists.oasis-open.org/archives/xliff/202108/msg00007.html (Rodolfo)
R: Since last meeting, I could not work on it, I was too busy with my work.
-Invalid example (Example in 4.3.1.40 type is invalid #10) https://github.com/oasis-tcs/xliff-xliff-22/issues/10 (Yoshito).
(Rodolfo shares the screen and shows the github repository and the issues that are included there.)
L: Can you mark them as completed once you have completed them?
R: Sure, I will do it now.
R: I would like to have a way to associate <note> elements with <segment> elements. (Issue 4 in github)
Y: Yesterday I had the same issues.
Y: What is the downside of having that change?
R: It involves a minor change in the spec. David does not want to make any changes in the spec.
Y: if it is an optional attribute, it is a low impact change.
R: for me it is a minor change and a useful one.
R: Bryan, would you agree to have this change?
B: Yes, I do, I am in favour of making XLIFF progress to the new needs.
R: Even if we do not go the full OASIS standard, 1.0 and 1.1 were never oasis standard.
B: XLIFF benefits from being an OASIS standard.
R: should we jump to 3.0?
B: I think if we change the core, we might need 3.0. I think the world is ready for that. I have no fear in going to 3.0.
R: we need some changes; this is minor but important one. The spec is not clear in some points.
R: We can also update or clear modules that are no longer maintained.
B:David might say that we are a small committee, but if we commit to have the job done within the few of us, it can be done.
R: If we agree on this, we might be able to have 3.0 by the end of the year. We need to agree on making the changes to core.
Y: I am worried that if we go to 3.0, not compatible to 2.0.
R: 3.0 will be back compatible.
Y: I am just worried that it might be give the wrong impression.
R: For me is less the important the number we use, but to make the changes that are needed.
Y: What we want to see is to agree on the changes that are needed. I think we need to limit the scope for those changes. What was holding me is to making. We need to clarify that we will make this discussion.
R: once we will have a core change approved, we could have others.
Y: we should be able to label the pending issues as important changes (changes to core) or just editorial
R: should we have a ballot for the issue 4 https://github.com/oasis-tcs/xliff-xliff-22/issues/4?
L: we can announce in an email to have a roll call in the next meeting.
B: We can socialise it in an email. And everybody should attend, so they now they need to discuss and attend. https://github.com/oasis-tcs/xliff-xliff-22/issues/4
R: So, what would you like to minor changes like this? It would mean that we would go to 2.2 instead of 2.1.1.
Y: it depends what we would like to do. The schema would change and people might want the schema to be stable.
R: sure, but we can have a new schema for 2.2.
Y: It makes sense to have 2.2 to include this type of change.
Y: Splitting the spec in two, it makes sense to have 2.1.1. And some examples. The question is if we want to have a quick 2.1.1 or a 2.2 later?
L: I have another idea. Work on both 2.1.1 (with editorial changes) and 2.2 (that might include other changes that might mean to change the schema). However, this might mean to duplicate the work, I am not sure if it is a good idea taking into account our current members.
R: I would actually mean to duplicate the job, as it will have to be done in two separate locations.
L: Ok.
Y: when do we want to publish the separation of core/modules? If we do it now, just editorial changes. Like an errata. We can publish it quick as 2.1.1
C. Test suite correction. Schematron (update). https://docs.google.com/spreadsheets/d/1uaQ1oSqhXRkRKXNLvgIwcffvNzhcTj9dIkIN__7EH4o/edit
R: David is not here to update us on this.
III. Subcommittee and sister TC reports
A. Promotion and Liaison SC
- MessageFormat (XLIFF 2 module). https://docs.google.com/document/d/1D702OBAzT-Crb9XXUiZYJnFO9Yq5duRy4Zc3Br6JwRU/edit
David F.
B. XOMOS - Sister TC
R: David is not here to update us on this.
L: No new business, meeting adjourned.
Bureau 6336 (Uni Mail)
DÃpartement de traitement informatique multilingue
Facultà de traduction et d'interprÃtation
Università de GenÃve
