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.

 

Best,

Lucía

 

 

 

 

 

-----------------------------

 

Attendance: Rodolfo, Yoshito, Lucía. We have quorum

 

 

 

I. Administration

R: I move to approve 7 March meeting minutes. https://lists.oasis-open.org/archives/xliff/202303/msg00001.html

Y : I second.

R : Meeting minutes approved.


II. Technical work

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

R: You can download the latest version from Github.

 

B. Typos in the spec. https://lists.oasis-open.org/archives/xliff/202302/msg00003.html Lucia. Issue 21 in Github. https://github.com/oasis-tcs/0xliff-xliff-22/issues/21

[Rodolfo shows the github page and goes through the changes in the spec.]

R: I have fixed most of the issues as it is documented on the column on the right (status of the reported issue).

 

Section about information on “Backwards Compatility”.

Y: support to 2.2 is automatically compatible with 2.0 and 2.1. Should we delete the “Backwards compatibility”? We do not really need that information. I have one technical question: If you have an application that is in conformant with 2.2, is it possible not to handle 2.1?

R: If you can handle 2.2 you can also handle 2.0 and 2.1. The only thing that changes is the schema. This information is also included in Appendix C. I propose that we delete the section as Yoshito suggests as the same information can be found in Appendix C.

L: Rodolfo, you can make a reference to that section of the spec where that is specified (Appendix C). So it is clear that deleting that section does not really delete the information because is already in Appendix C).

 

About the missing entity.

Y: I was wondering if the W3C has specific examples on how to do this. Like a style guide where they define how to represent examples.

R: Sometimes they do it sometimes they do not. It is not really an error. It improves the readability if we keep it consistent. We can leave it.

Y: Do we have a specific style for the examples?  Like adding or not spaces.

R: We do not have one.

Y: We should be consistent.

R: What do you prefer?

Y: No spaces, but the important thing is that we always use the same solution in the spec.

R: I agree, I will make that change to have the examples consistent.

 

 

Inconsistency in capitalisation:

R: when we do a search of the term “XLIFF Documents” for example. It has a definition. It refers to a term that is defined.

Y: do we need to differentiate the two?

R: In the ITS module, they make reference to 2.1. Should we change it to 2.2 or remove the version number?

Y: We should not have the information about the specific version on this type of definitions. I suggest that we refer to XLIFF only without specifying the version.

R: I agree.

L: Me too.

 

Missing information:

There was a bug in the merging process, it has been fixed.

 

 

C. Next steps to review the new spec.

R: Lucía, you can remove point A from the agenda, and just leave B as this is an ongoing process.

 

L: No new business, meeting adjourned.

 



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