Dear all, Please find below a summary of today’s discussion. Best, Lucía Attendance: Bryan, Lucia, Rodolfo, Yoshito, Manuel We have quorum Regrets: DavidF. I. Administration A. Approve 20 September meeting minutes.
https://lists.oasis-open.org/archives/xliff/202209/msg00007.html Y: I second. R: No objections. Meeting minutes approved. II. Technical work A. ISO template.
https://github.com/oasis-tcs/xliff-xliff-22/issues/3 David. (David is not in the meeting). B. Discussed and approved changes in the spec. Rodolfo. You can download updated versions of the specification from
https://github.com/oasis-tcs/xliff-xliff-22/tree/master/xliff-22 (Rodolfo shows the small changes that he committed yesterday in github.) R: I separated some parts of the spec. I did not want to remove anything from the spec before having a meeting with quorum. R:I have found a problem with one appendix. The change track is in the previous spec. It has been deprecated in version 2.1, but it is still part of the spec. I suggest that we can either move it back to a module or move it away. It is informative as it is. L: Do we know if somebody is using or wanted to use it? R: Not that I am aware of. I was not there when it was deprecated. I think there was no manpower to maintain it. The module itself can be useful. You might want to track history while translating/reviewing, etc, but it is not working like as it the module now. Yoshito, do you have plans for this in IBM? Y: Not now, but I also see the usefulness of the module. In my view the module is deprecated in the spec. R: It is part of 2.0 and deprecated in 2.1. Do we want to keep it deprecated and publish it later when we will have the time to work on it? Y: Publishing a new module takes time, and we might not want to wait for that. I think this deprecating term is confusing, I think we should clarify that this is deprecated. R: remove from the spec? leave a note? Y: Is it possible to create a section with deprecated extensions? R: Yes, it is. Y: In the current spec is in section 5.6 as deprecated, and in 5.5 and 5.7 we have active module. To me is odd that a deprecated module is part of the other extensions. I think we could include it in a deprecated modules section. R: We could have a note, and we could externalise it. Y: If we have decided to deprecate, we should not encourage people to use it. I think it makes sense. R: We can keep it there until we publish the final spec. M: Is it implemented? R: Not that I am aware of. M: What is the problem of keeping it? R: Either we work in this module, or we remove it. B: I was interested in this module, but I was not involved in its development. R: Bryan, what is your opinion on this? B: I think having a reference in the appendix might be enough. M: It is an interesting module though. L: I suggest we make a ballot to take a decision in Kavi. B: I agree. R: That sounds good, let’s do it on kavi so it gets recorded. ( Rodolfo prepares the ballot to decide this: Do you agree on removing deprecated tracking module from XLIFF 2.2 specification? Remove Change Tracking module from XLIFF 2.2 specification and add a note in Appendix C.) L: I propose we leave it open for two weeks, and close it one day after the next meeting. All: we agree. (Rodolfo prepares the ballot wording and settings and the rest of the members in the meeting agree on them. The ballot can be found at
https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=3731&referring_url=%2Fkws ) Y: I think the whole point that we inform on the situation of the modules. We should maintain the modules and namespaces. We still keep the modules and definitions. R: In the 2.1, the Change Tracking module namespace has been removed from the list. Y: If the namespace is not there, we should just say “do not use it”. Y: we need to agree on how to upgrade both the core spec and the extended spec. At some point next year, the message group will publish a module. What are we going to update in that case? R: We could add an errata, the core will not change. Y: Do we have the list of namespaces in the core or in the extended? R: In both. Y: then, we will have to update both specs. R: Yes. Y: what is the OASIS way of doing it? R: we did something similar in DITA in version 1.3. The original was from 2015, but the last document with the errata in 2018. Y: I think that adding a module is not really an errata. R: it is the term OASIS uses for this. Y: so, if we wanted to add the future modules for the messaging group or for the change tracking we would need to that that. R: Exactly. Y: That’s interesting. L: Did you have a section that specifies the changes made in the erratas? R: There is a general section that explains the changes from 1.2 and 1.3, but not from the erratas themselves. C. Ballot. Remove references to Schematron, NVDL and Test Suite from specification.
https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=3727 R: The ballot passed. I would start making the necessary changes in the spec. D. New feature requirements? R: Yoshito you wanted to add something in github. Y: It is not really a requirement what I had mentioned last time. L: no new business, meeting adjourned.