OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[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.

 

 

Attendance: Yoshito, Rodolfo, Lucía, Bryan

Regrets: Davidf.


I. Administration
A. Approve 4th January meeting minutes.
https://lists.oasis-open.org/archives/xliff/202201/msg00001.html

Y: I second.

R: Meeting minutes approved.


II. Technical work

Rofoldo shows the latest changes in the documents in github. https://github.com/oasis-tcs/xliff-xliff-22

R: I have a big issue with the version attribute. In the specification the default value is undefined. It should be 2.0.

B: Ok.

Y: the default value is undefined, that is right. I am not sure if we need to make something requirement.

R: I think we should add a default value. We can make it a constant.

L: How was defined in previous versions? And in their schemas?

R: (Shows the enumeration that is used in the schema of 1.2 for backcompatiblity.)

Y: Maybe we should use the same for backcompatibility.

L: can we have a look at the 2.0 schema?

R: it is not defined, the default value.

Y: I do not have a strong opinion.

L: For validity purposes, it might be better to have the enumeration as it was in 1.2, for example.

Y: My concern for 2.2 is that people in the industry might think that we are making major changes if we go for 3.0.

R: Exactly, we are not making major changes and it is back compatibility, so 2.2 might be the best solution..

B: I agree, we should change the note to reflect the values that are available.

Y: that means that 2.2 compliant is still back compliant with 2.0.

R: Exactly. And I think we should a note in the spec explaining that 2.2 is backcompatible with 2.1 and 2.0.

Y: I think we should rename the schema file.

R: In the folder, the file is name as xliff_core_2.0.xsd, only for the schematron the name is 2.1.

R: the uptaded pdf and xml are in github, I do not if you want me to send them by email.

B: that would be helpful, thank you.

Y: At this point, we should also start working on Appendix C to start including the changes that we are including in this new version.

R: yes, I will clear this section and start include it.

Y: this will help people that are not attending to follow the changes.

 

R: I am not expecting to have many more changes in the near future, are you?

Y: I am not expecting any more changes.

R: I am thinking about when 2.2 would be completed.

Y: the big change in 2.2 is the separation of the core of the modules in the spec.

R: That is the big changes. I want to concentrate on finalising this and close this.

Y: I think that message format module might take longer, so if we wait for that we might not close this year.

R: Yes, I will not think it will be done this year.

Y: Do you have any date in mind?

R: I do not. But if you do not want to make any more changes, we can concentrate in finalising.

R: We would also have to change the namespace. If we also make changes in the schema. We would be taking about two different xsd files.

B: I like the idea that the core/module would be the big change, and that the rest would be minor. Once we have that the community would be adapted to that separation, we could start talking about 3.0. I have that bigger ideas to include former lisa standards, but I do not want 2.2 to hold for that.

R: good, but you could always work on a module that could be implemented later. For example, for SRx. For example, if you want to get back the abandoned SRX, but you could include the segmentation rules in <mda:metadata>, but we will not be breaking back compatibility.

 

L: I think we need to make a ballot to vote on the changes that have been discussed today and make the decision process as transparent as possible.

B: I agree.

R: Me too.

Y: We should make a ballot to decide on the xliff version and also on the attribute enumeration.

L: Yoshito it would be great if you could work on the changes/template protocol, so we could discuss it before the next meeting, and we could apply it for the changes that were discussed today.

Proposal for changes template/protocol. Yoshito

Y: I have not had the time to do it yet.

L: It would be great if we can have it for next meeting, so we can use this protocol for the changes that we discuss today.

 

R: No new business. Meeting adjourned.

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]