Meeting minutes

Dear all,

Please find below a summary of today’s discussion.

Attendance: DavidF, Lucia, Rodolfo, Yoshito, Bryan (joins during the meeting).

I. Administration
L: I move to approve 1st February meeting minutes. https://lists.oasis-open.org/archives/xliff/202202/msg00001.html. Can I have a second?

Y: I second.

L: Meeting minutes approved.

II. Technical work

A. Proposal for changes template/protocol. Discuss and vote on Yoshito’s new proposal. https://lists.oasis-open.org/archives/xliff/202201/msg00005.html see also minutes from last meeting https://lists.oasis-open.org/archives/xliff/202202/msg00001.html

Y: I updated it, I have not yet shared the PR. (Yoshito shares the url with Rodolfo who shows on his screen the three new proposals: one for core proposal, one for errata, one for change proposals. Each template is associated to a specific label.

R: It looks great to me. Why do not you send us the links?

Y: Sure, the only issue is to define the labels and the categories.

R: We are going to use this to record the key changes that we made so far and the couple of changes. Those issues are already recorded in github as regular issues.

Y: we need to assign a label to each issue.

R: How many issues do we have? We have already documented some in issues. I do not think we need to spend more time on this.

Y: Ok, I understand.

R: you can send the full request.

Df: he changed it based on the discussion we had on the last meeting. We are on good timing. This will be especially useful when we will be in public reviews.

R: Yes, in the spec we need a section where we will record the changes. I cannot start here, because I do not have the links to github.

Y: how to we manage the version? Do we continue to use a repository to 2.3 or 3.0?

Df: they gave us a repository for 2.2, but we could request a new one if we change the number. It will not be a problem, it will be a separate folder.

Y: As long we will use 2.x I would like to see continuity. It would be good to have the same repository tracking the history.

R: once we will have ideas and start working on 3.0, we will have to worry about that. We need to concentrate on 2.2

Df: the links that are on the spec, they are in a repository held by OASIS.

R: yes. We have to create the file for them and they will upload them. We can simply send it to Chet and he will take care of it. We will need those when the ballot will be approved. For now, all we need is the ability to keep moving.

Y: Good, I will create the PR.

R: that would be perfect, I will include the issues through that system. I will need the

B. Version attribute. See meeting minutes from two last meetings. https://lists.oasis-open.org/archives/xliff/202201/msg00001.html and https://lists.oasis-open.org/archives/xliff/202202/msg00001.html

L: I can create the pattern that Bryan proposed on the last meeting.

R: The pattern will not be the best solution, as some invalid values could still be accepted as valid. If we make changes in the schema, we can change the value of that attribute. An xml parser will check and see that it is ok. If we restrict 2.0, 2.1 and 2.2 is ok. I understand the idea for the future.

Df: In the last meeting, we discussed three options: one option is leaving it as it is. One option is the enumeration. And the third option is the pattern. So I am not sure what are the benefits of them. When you develop 2.2 is not invalid. When you want against an existing validor is valid.

R: If we take a 2.5 file today the validator would say that it is ok. We do not have any value predefined. That is why I propose to add 2.2, 2.1 and 2.0, so we can say that the rest is not valid.

Df: the current value is undefined, it is a text string.

R: If we use the pattern 2.5 it still will be valid. The enumeration idea is already in 1.2.

Df: I agree that the current thing is very loose. But I am worried that the enumeration would be too strict.

R: If we make changes in the schema in the future, we can change the value at that point. For backwards compatibility I say that we include 2.1 and 2.0. So, the tool can actually use the right catalogue to check the validity. Having a version would help.

L: the problem I think we had in the previous discussion is that we did not clearly see the need for this change. So it is great that you are explaining it now and if you could add it the change proposal that Yoshito has made.

R: I am working on a parser and one of the problems I had was that that I could not based on the version used. Using a regular _expression_ would not work in this case, because other invalid valid could be seen as valid. Using the parser to check the right version would be very helpful.

L: Thank you Rodolfo, it is clear now. Once it will be in the change proposal template we will discuss it one last time and vote on it.

C. Namespace name. See meeting minutes from January’s meeting. https://lists.oasis-open.org/archives/xliff/202201/msg00001.html

R: This is related to the previous issue. When you create an XLIFF file, you declare a version and you declare a namespace and then you declare the schema location. Any xml parser will look for the schema location. In the catalog, the tool will look for the specific file. We need to change the namespace value so the schema can be located. It is a catalog issue. (Rodolfo shows the issue in his screen). The only way to differentiate it is to make a different namespace.

Df: the idea is that 2.x does not change the core.

R: we have different catalogs for 2.0 and 2.1.

R: we are changing the core. We have already had that discussion.

Df: In the messaging group, I managed to explain them that the core is not modifiable.

R: It was your idea to tell them that core will not change.

Df: this is what the community agreed.

R: are we going back two months?

Df: I will always oppose to changes that are not needed in the core. we need to move forward and add modules that make changes. You are just proposing changes randomly.

R: I am proposing changes based on what we need in the real world. I would need the tc to tell me if we can or cannot make changes and move forward.

Y: this is my experience. I am working with translation vendors, in my honest opinion, xliff 2.0 adoption is not mature enough. My impression every vendor is not strictly following the specification. We are working on proposal changes, as Rodoflo says, from the developers point of view. But I do not feel that those changes are breaking back compatibility, it is just expanding . In my honest opinion, it will not impact the community, as the support in 2.0 is not wide. My gut feeling is that the changes will not impact the vendors. I understand that from the standard point of view, even small changes, are changes. The reality I do not think the changes that we proposed are going to have an impact in the community.

Df: I agree that there is not wide support. But there is the principle that the core will not be changed.

Y: I do not think it will have an impact.

Df: there is the okapi implementation, the oxygen implemetantion, sdl, Lionbridge. This issue of note, it goes back to 1.2 . It never needed a ref because it simply applies to that level. Note is kind of overloaded in note, because it can be used at the level of comment. This is the functionality that Rodolfo needs, but this is making two ways of using the same thing.

R: I am already implementing what the spec says, but it is a problem because it is modifying the source. I proposed a change to avoid that.

Y: this is the one thing, I think again I doubt that we will never change the core specification. I disagree in protecting the core schema on going forward. I think, when necessary, we should change the core.

Df: I agree, we should study the impact.

R: if you are planning to blocking us, I am out. It is your choice.

Df: I will oppose to this when the spec will be in public review.

L: Time is over, we can continue this conversation in the next meeting.

xliff message