[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Meeting minutes
|
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
Y: I second.
R: No objections. Meeting minutes approved.
(David is not in the meeting).
(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.
R: Yoshito you wanted to add something in github.
Y: It is not really a requirement what I had mentioned last time. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]