Meeting minutes

[Lucia Morado Vazquez <Lucia.Morado@unige.ch>]

Dear all,

 

Please find below a summary of todayâs discussion.

 

Attendance: Yoshito, Rodolfo, David, Manuel, LucÃa 

 

I. Administration 
R: I move to approve 19th April meeting minutes.âhttps://lists.oasis-open.org/archives/xliff/202204/msg00021.html  

Y: I second. 

L: Meeting minutes approved. 

 
II. Technical work 

A. ISO template.âhttps://github.com/oasis-tcs/xliff-xliff-22/issues/3âDavid. 

Df: I do not really have the bandwidth to with this, that is why I assigned to you. 

R: And I assigned to you. 

Df: XLIFF goes under review this year, the ISO version, that was published in SC37 it will go on the ballot. The national bodies will vote on this. We could act as maintainers there and give recommendations. Recommendations would be to update the ISO published version with 2.1. But if we are not able to transform the spec with the 

R: I do not know what the ISO template looks like. 

Df: It is on SVN, Tom Comerford did work on this. 

R: I do not know what is missing. I am focusing on 2.2. If you want to do the work on 2.1 for ISO, it is fine with me. 

Df: If it is up to me, I do not have any progress to report and I do not know when I will have the time to do it. 

R: It takes time, I know. That is why I prefer to focus my time on working 2.2 instead of that. Let us know what you can do with that.  

 

B. Requirements for <sc> and <ec>. Yoshito. See the original question https://lists.oasis-open.org/archives/xliff/202204/msg00023.html and the discussion with Rodolfo on the mailing list https://lists.oasis-open.org/archives/xliff/202204/msg00025.html  

R: Yoshito found a problem here. I think the spec is ok, the problem is with the validation. You have sc in source but you do not have ec in target. 

Y: the spec is not clear.  

R: The spec does not specify sc in source or target. You might have a sc coming from a segment. The default is isolated. 

Df: It is conditional. If it is orphan, it should be isolated. 

R: It can be marked and isolated. 

Df: then it is invalided. If it is in target, it can be a warning if the state is initial.  

R: There is not any information about that in the specification. 

Df: The final target is obliged to do the same thing. 

Y: Yes, but in the process. 

Df: in any other state, it is a warning. 

R: where is it? I do not see it in the spec. 

Df: It is written around the state attribute. 

R: that is the part that is missing. I cannot see it there. 

Df: I will find it, I am pretty sure that we did that. I also remember including it in the schematron. 

R: the schematron does not check the state. 

Y: In addition to that, even if we add a warning, from the processing point of view, it is very annoying. The distinction between error and warning is very blurred. 

Df: It kind of make sense, that when you are not in the final state. 

R: Like in this example. 

Df: we had the discussion we said that in not target is no problem, but if it is initial a warning. 

R: It is a good idea, but it is not in the spec. 

Y: In this case, we just need a clarification. 

R: Yes, that would be enough. We also need a clarification for fs in note. 

Y: what are the action items? We need to create an action item. 

R: Can you do that? 

Y: Yes, I can. 

 

C. Use of fs:fs/fs:subFs in <note> element. Yoshito. See the original question:âhttps://lists.oasis-open.org/archives/xliff/202204/msg00004.htmlâand the discussion with Rodolfoâon the mailing listâhttps://lists.oasis-open.org/archives/xliff/202204/maillist.html 

R: the problem that Yoshito found is that you cannot use fs in a note. For note there is nothing you can do.  

Df: the functionality is up to you, is up to the implementer what you want to do there. There is a list of HTML allowed elements. It is described in the fs module. 

Y: the problem is that you cannot use inline elements in note. 

Df: you are not allowed to us mrk in note. 

R: That is why Yoshito could not do it. 

Df: It is not meant to give you that capability. 

Y: what is the use case of fs. 

Df: it is not supposed to have a parallel structure. The main purpose of note is human-readable content. It is a method to include human readable content. 

Y: These are minor issues. 

Df: <a> is an allowed element. 

R: Yoshito is up to do what you propose to do with this. 

Y: I would like to see the user case. 

Df: You can make the whole note with a <note>, but I do not think  

Y: What I want from the readerâs point of view of the spec. When I look at this and how to use it, but if you look at the sentence about the wildcard, what is the use case for this. 

Df: the original discussion was, do we need it in note? And people agreed that it might be useful. You could make the note linked in a preview that is capability that it would be possible. 

Y: If there is a small example, I will be happy with that. 

 

 

D. Processing requirements for state attribute. Yoshito. See the original question:âhttps://lists.oasis-open.org/archives/xliff/202204/msg00006.htmlââand the discussion with Rodolfoâon the mailing listâhttps://lists.oasis-open.org/archives/xliff/202204/maillist.html 

 

R: Yoshito, I see that you created the issue in github (14) https://github.com/oasis-tcs/xliff-xliff-22/issues/14 . (Rodolfo reads and explains the issue described by Yoshito). The proposed solution is to remove the default value âinitialâ. 

Y: this might have an impact on current implementations. 

Df: This can have a big impact, you do not force people to use attributes. If we change the example this could be solved. You must not have a target if it is initial. 

R: Here in the example, the state is initial, and the target is here. The problem is with the sentence: âhence implementers donât have to make explicit use of the attributeâ. 

Y:âIf and only ifâ is a problem. 

Df: It is fine, if it does not have the target, the only attribute admitted is initial. In the spec it says âother than initial and defaultâ. 

R: I do not read it like that. 

Df: it is a question of logic, not interpretation. 

R: When an XML parser reads it, it is invalid. 

Df: if you do not have a target, the value must be initial. If you do have a target, it other than. 

Y: there must be another way. 

Df: it is a double negative. I understand that is hard to pass. âIf and only ifâ and âifâ is equivalent. Not other value must be used if it does not have target. 

Y: it is not equivalent. 

R: We need to rewrite this, we might not need to change the schema.  

Df: I agree it is hard to pass. I would put it in a note. It is in the style in the provisions. 

R: It is not clear. 

Y: I am struggling to understand these processing requirements. If you add this example, state=âinitialâ, is this invalid? 

Df: This would be valid. It is a business processors problem. It is nothing the spec should prescribe. It is not invalid, only a warning. 

Y: we wanted to add a state âunknownâ.  I kind use state or not, it is optional. I think you are assuming that there is a user case where the state value does not matter. 

Df: then it would be initial if it does not matter. 

R: so then, why adding the default. 

Df: I think it would be dangerous not to have the attribute if there are not default values. 

Y: Yes, but again it is very hard to process this in the tool.  

Df: they can give you a warning if they care for it. 

Y: but it is truly optional, the default value could be undefined. 

Df: if there is a state machine, it would be wrong not to have the default. 

R: we can have the default value, but clarify this. 

Df: It can be added it a note. 

R: I think it would be better in the processing requirements. We are making a specification for implementers. If it is not clear, we are not making a good job. We need to focus on our public. 

Y: it is ok to use standard writing. But, then we can add an example. 

Df: maybe the provision can be writing in a better way. 

R: Yes.  

R: The problem with substate is that is tool dependent.  

Df: sure, substate is intended for private values. You can ignore it if you do not understand. 

R: we need to add âif necessaryâ to make it clearer. 

R: why delete it? 

Y: the statement is too strong for me. 

R: It should be âshouldâ instead of âmustâ.  

Df: it is a substate, it is likely a subdivision of a previous state.  

Y: the assumption is maybe difficult to put through vendors. I am ok with this behaviour. But I know people tend not to touch nothing unless it is necessary. 

Df: I understand it, but the spec it says that if you do not use it is useless. The advocate of this subsate were people from Ms, they had strong protocols on how to process substate. 

R: I would change it from âmustâ to âshouldâ.  

Df: But if you are not close in the loop, there is no use of keeping it. 

R: I have seen this in files that travelled through different tools. If we leave those details out, there is extra compatibility between tools. 

Df: we keep only a few places where namespaces are allowed, because is very open useful. 

R: Then you have companies complaining because translators are working with different tools. 

Y: the point is that you look at the state attribute, then you can look at the subtate. Deleting substate is too strong in my opinion. I do not know if processor must actively delete it. 

R: the most common practice is to delete it. 

Df: The standard should facilitate roundtrip.  

Y: I will update the issue with our discussion. 

L: Thank you, Yoshito. We do not have time for more discussion today. See you in two weeks.