OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  Re: [xliff] Meeting Minutes: 20 August 2013

    Posted 09-02-2013 10:50
    Bryan, all I have an important amendment to the minutes As Chet explained LOA do not count as Voters so we had quorum at 80% with 8 out of 10 eligible voters present People on LOA were Lucía, Helena, Uwe Victor regained voting rights in this meeting, I have changed his status in kavi Otherwise, the minutes look good to me Cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Tue, Aug 27, 2013 at 6:04 PM, Schnabel, Bryan S < bryan.s.schnabel@tektronix.com > wrote: Hello,   Kavi is not playing nicely. So here are the meeting minutes (thank Asanka):   b: - attendance: David W, Yves, Victor, Asanka, Bryan, Kevin, Ryan, Fredrik, Tom, DavidF;  - achieved quorum: 7 voters (51%); - df seconded the meeting minutes of 16th of July 2013. no objections. - df seconded the meeting minutes of non-quorum meeting held on 6th of August 2013. no objections. df: - we should probably start with com1141. b: - agree; there are two different opinions for this and the TC have to come to an agreement; df: - we have 'state' and 'approved' both on segments; - Ryan proposed to have the approved recursively inherited, but this is not a good idea; this is back again to the solution I presented in the non-quorum meeting, except for some qualifications driven by the discussion with Yves; - opinions: whether approved and state are dependent attributes or whether they are independent attributes; - if they are dependent, the solution in the current spec is ok; if the TC thinks they are independent then Yves’ proposal needs to be implemented; the final decision is whether they are dependent or not. r: - can we have a summary of the two proposals? y: - df's proposal I guess is the current one in the draft spec; what I would propose to do is to disconnect the state attribute from the approved attribute. First rename the approved attribute to canMerge, as it seems to be about merging; Also remove the PRs linked to the value of states... breaking down any links in the spec between approved and state; then make canMerge have "yes" as the default attribute value; df: - is it 'required' or 'optional'? y - there is a default; does not matter; df: - currently it is required and undefined. b: - there is a good workflow suggested by Yves for his proposal; was that clear Ryan? r: - clear enough; seems like we are still in two positions: df sees a need for a review state and Yves does not see a need for a review state; y: - no. I see a complete disconnection between a flag that would allow you or not allow you to merge something and the states; because I don’t see there is any reason for having a relationship between the state and what you can merge or not. r: - …whether the concept of reviewed is taken care of the final state? y: - well... there is a reviewed state as well. r: - …whether concept of approved is taken care by either reviewed or final in the states; y: - approved attribute is misnamed; it is not about approving anything; it is about allowing to merge or not; r: - agree. do you feel like there is a need for some kind of a flag or state to be able to approve or not-approve translations? y: - I think there is already a state; there is a flag that says if it is approved or not; that's the state; r: - that's reviewed or final; y: - exactly; there are sub-states in between ; df: - the fix I did was based as much as possible on what was in the spec before; it was largely driven by Ryan's observation; … there would be some strange combinations like approved and no; I tied these together by a better constraint staying initial must not be used, if and only if(IFF) the approved is yes and final must not be used IFF the approved is no; this would make a hierarchical method of indicating the readiness;... if you wanted you could expand by using the state and sub-states; basically, approved, state, sub-state specify different granularity; in  this scenario, tie is needed to avoid conflicting combinations; ..it is required; now defined as default; I think it is not offensive; if people want to be able to merge right away ,they can set the flag to yes, otherwise set it to no; Yves thought approved is completely a different entity; it is just a readiness indicator; he also does not want to be forced to change the flag; this is also catered in this scenario when the flag is required and undefined; it comes back to the decision whether they are dependent or not; whether the flag is completely different or not; I think that the readiness indicator is narrowing down the semantics; r: - I actually can see a need for both; need for determining whether a translation has been reviewed and approved; or reviewed and not approved; I see that completely separate from being able to merge or not; df: - we all agree that we don’t' want to implement too much workflow prescription logic into the spec; if we have the approved flag, approved flag can be used as a readiness indicator; .. I would not multiply the flags; I prefer the current solution; if the TC wants to disconnect them, let's do it; r: - I don’t see readiness and approved … review as the same thing; our use case is similar to Yves’; merge can happen at any time independent of whether something has been translated and approved or not; f: - we do the same thing; r: - approved is a completely separate workflow concept; - if we say that reviewed and final state values incorporate whether a translation has been approved or not, then I don’t even see a need for the approved or canMerge attributes at all; f: -I'd agree; I don't completely understand why all users could just derive from state if they wanted to merge that portion of the translation or not; df: - because state is optional and it has four states and it's not simple; y: - that does not present any merging based on the ...; you can decide what to do; df: - the default value is initial; does not seem very intuitive to merge back with the initial to me; f: - if a tool need on ... approved flag to be compatible I think it means that we would set the approved or canMerge to yes before we translate anything at all; in that case we would do a source-roundtrip test; dF: - what are you merging after you just generated the XLIFF? f: - we are running an automated copy of .. source to target; df: - it's ok to do;  why not set a flag when doing that; when it goes away really for the translation you can set it again to No? y: - why make things complicated? df: - this was a month now; I don't know what to think; y: - approved flag has always been a problem; we got comments from outside people; it was there for a while; df: - when I started the discussion, no one reacted until I proposed the solution; let's agree on something; y: - it seems to me ... consensus on that state can provide information about the state of the translation and ... merge based on the state of the translation .. I am wondering why canMerge or approved flag is needed at all; the only reason was because you said that some process want to set ... is it  something useful? I am just wondering whether it's useful to have that flag; r: - I don’t think it is useful; df: - everyone thinks (except me) state is enough; f: - state together with sub-state; df: - sub-state is not public so it is not interoperable; it's only useful if you are in a private loop; r: - if we think values for state does not cover general workflows well enough for most consumers, then we should consider changing values in state; I think most people agreed that's enough; df: - they are enough in general; values of state provide some interoperability for sub-state; r: - that's correct; we don't need any other values; df: - we currently have 1 PR and 1 constraint using the approved attribute; r: - they are too prescriptive; df: - if you don't have them, then LSPs have no way to say don't merge y: - it has the state values; df: - state values are about the state of the translation y: - and that's not enough for the decision of merging or not? r: - what are the criteria ... translation? this is a translation interchange format.. df: - initial, translated, reviewed, final ... for tacking for what’s happening; [describes scenarios]; you can indicate by using the flags (canMerge or approved); why we artificially progress the state of  the translation when we know it is not final; we just decided to merge now for whatever reason y: - that's a decision the merger takes; df: - ..is there a way for service provider to tell the merger not to merge? y: - if it does not set the state to the minimum level to which the other provider is merging ..  that’s the way to do it; df: - it is overloading, you'd set to review or final just to give a signal; f: - if it's ready for merging, I would say its final in my opinion; df: - why so? it can be raw crowd sourced translation; it does not need to be final; it could be just published now; f: - then I would not want to merge it; df: - they would; they want some content; y: - in the crowdsourcing kind of merger, they are going to merge whatever they get; df: - there must be something in the target even if it is the copied source; there should be something in the target if you want to merge; y: - if … shouldn't merged what should you do? df: - if you don't merge you can call your LSP and ask them why it is not set for merge? ... y: - that would be probably fine ..; df: - it is not interoperable in the core; y: - adding something that says can merge, and not having the logic of the decision of why it has been set to merge is not interoperable either; df: - no one can misunderstand the yes or no; y: - why is it yes or no; df: - it is simple; y: - why it is set to yes or no; which criteria that have been chosen yes or no? df: - it is linked to the state to a certain extent; y: - I think it’s a weird case scenario; in the worst case scenario we could have one additional state like mergeable ; df: - it would confuse two different things in one value set; y: - there is a need for a flag that says you can merge or you cannot merge; and there is not enough discussion and proof of concept; we cannot make a decision on that at this point; it could be a module or something we add to .1; we don't need to stop everything to cater for one specific use case; df: - there could be more use cases [describes scenario]; f: - my problem is really with PR requirements on the flag; if somebody hasn't set merge="yes" on the segment we are not going to skip merging if there is something to merge; df: - you can do it; one who provided with the file set to no for a good reason; they told you not to merge; f: - then they should not have submitted to the file on the first place; df: - it could be on a repository that could be accessible for the both; b: - do we have enough information here to go with either Yves’ scenario, DavidF’s scenario, or shall we postpone the resolution of this? df: - Ryan suggested other combinatorics; what would be the options for a ballot?  Would you be happy with only two options or third or fourth options? r: - ... PR requirements around the approved state; df: - you don't like this? r: - I don't like prescriptiveness around the approved state; if there is only two options I would probably vote against the approved state due to prescriptiveness of it; f: - I agree; can merge with default "yes" ; if someone has set to "no" that means they have valid reasons to do so; y: - no specific PRs or any specific requirements; I’d be ok with that; df: - what would be usefulness if there was no PRs tied to it? y: - you could have "should" or so; f: - or say that an agent "may" refuse to merge segments for this state.; df: - are you saying "merger may refuse to merge if it set to no?"; I think the constraint on unit is not too restrictive; it says for a unit to be ready for merging it is required to have all the segments..  it is defining a state; it is not a PR..; you can do it but you have been told it is not being ready for merging; y: - it is a really weird requirement; df: - merger was told the unit is not ready for merging; it does not say you must not attend for merging; it only says on the segment; not on unit; we can move it from the segment if you like; but I would still define the state of readiness; f: - I think it should sit on unit, not on segment; df: - currently we have a PR on segment and a constraint on the unit; the constraint on the unit explains that the unit is not ready for merging if not all of its segments are not ready for merging.. r: - I think the only way we are going to move forwards is to have a ballot df: - I think too; we need to know the exact options; r: two options: what is currently in the specification as you have worded..; Yves wants to have the canMerge attribute; or to remove approved attribute; df: - I can after this meeting write these three options for a simple majority ballot; b: - are you saying it is an electronic ballot? df: - I think the third option need to be elaborated; if we can do it now; let's do it now; r: - I think it is clear enough so we can do it now; df: - not against, I second it; y: - we need to state the three different options then; df: option 1: approved related to state through PRs; uses approved to define merging readiness option 2: rename approved to canMerge; make it optional with default yes; remove relationship with state; add weak PR for Mergers option 3: drop the flag approved/canMerge. no PRs; df: - roll call: - t:abstain,f:2,r:3,y:3,b:2,a:abstain,k:3,df:1 df: - option 3 got three votes; df: - summery approval of comments: 017 - sm/em justification 019 - inline codes solution justification 023 - clarifications in mtc module 026/032/048/054 - changes and examples in mda module 045 - handling of xmlns attributes 051 - justification and clarification of [ignorable] 052 - clarification of mtc origin attribute 059 - corrections of schema leaves us with 031, 058, 003 to be still pursued offline; f: - very quick update on the two items that I have still: I have not been able to make good examples for slr module due to lack of time; for the other PR about renaming equivalent .... to Storage info I am actually against that because I believe that .. storage is more accurate name for the attribute; because it tells how many bytes of storage inline code would have in the native code when back coded df: - one of your slr actions would remain pending; one could be subsumed under the summery approval; which? f: 31 df: - I will include 31 - rejected rename; ...ballot for summery approval of solutions. b: - I second that. any objections? df: - ballot passes unanimously; - dropping the flag is so simple; - Tom and Fredrick will need to work on the examples by the end of August b: - if we have no controversy in the examples, this is quite doable; I feel that with this advancement I can take a second look at the calendar and predict when we are going to complete. df: - please commit and socialise. I will do the final printout out just in time for the meeting; - f,t does it sound doable by the end of August; f,t: yes; b: - no new business. meeting adjourned


  • 2.  Re: [xliff] Meeting Minutes: 20 August 2013

    Posted 09-02-2013 10:53
    A follow up Uwe and Helena will be back from LOA tomorrow and Victor has regained his Voting Right, so our quorum will be calculated against 13 total eligible voters with Lucía being LOA until the next meeting. We will need 7 Voters in attendance to progress. See you tomorrow dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Mon, Sep 2, 2013 at 11:48 AM, Dr. David Filip < David.Filip@ul.ie > wrote: Bryan, all I have an important amendment to the minutes As Chet explained LOA do not count as Voters so we had quorum at 80% with 8 out of 10 eligible voters present People on LOA were Lucía, Helena, Uwe Victor regained voting rights in this meeting, I have changed his status in kavi Otherwise, the minutes look good to me Cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone:  +353-6120-2781 cellphone: +353-86-0222-158 facsimile:  +353-6120-2734 mailto: david.filip@ul.ie On Tue, Aug 27, 2013 at 6:04 PM, Schnabel, Bryan S < bryan.s.schnabel@tektronix.com > wrote: Hello,   Kavi is not playing nicely. So here are the meeting minutes (thank Asanka):   b: - attendance: David W, Yves, Victor, Asanka, Bryan, Kevin, Ryan, Fredrik, Tom, DavidF;  - achieved quorum: 7 voters (51%); - df seconded the meeting minutes of 16th of July 2013. no objections. - df seconded the meeting minutes of non-quorum meeting held on 6th of August 2013. no objections. df: - we should probably start with com1141. b: - agree; there are two different opinions for this and the TC have to come to an agreement; df: - we have 'state' and 'approved' both on segments; - Ryan proposed to have the approved recursively inherited, but this is not a good idea; this is back again to the solution I presented in the non-quorum meeting, except for some qualifications driven by the discussion with Yves; - opinions: whether approved and state are dependent attributes or whether they are independent attributes; - if they are dependent, the solution in the current spec is ok; if the TC thinks they are independent then Yves’ proposal needs to be implemented; the final decision is whether they are dependent or not. r: - can we have a summary of the two proposals? y: - df's proposal I guess is the current one in the draft spec; what I would propose to do is to disconnect the state attribute from the approved attribute. First rename the approved attribute to canMerge, as it seems to be about merging; Also remove the PRs linked to the value of states... breaking down any links in the spec between approved and state; then make canMerge have "yes" as the default attribute value; df: - is it 'required' or 'optional'? y - there is a default; does not matter; df: - currently it is required and undefined. b: - there is a good workflow suggested by Yves for his proposal; was that clear Ryan? r: - clear enough; seems like we are still in two positions: df sees a need for a review state and Yves does not see a need for a review state; y: - no. I see a complete disconnection between a flag that would allow you or not allow you to merge something and the states; because I don’t see there is any reason for having a relationship between the state and what you can merge or not. r: - …whether the concept of reviewed is taken care of the final state? y: - well... there is a reviewed state as well. r: - …whether concept of approved is taken care by either reviewed or final in the states; y: - approved attribute is misnamed; it is not about approving anything; it is about allowing to merge or not; r: - agree. do you feel like there is a need for some kind of a flag or state to be able to approve or not-approve translations? y: - I think there is already a state; there is a flag that says if it is approved or not; that's the state; r: - that's reviewed or final; y: - exactly; there are sub-states in between ; df: - the fix I did was based as much as possible on what was in the spec before; it was largely driven by Ryan's observation; … there would be some strange combinations like approved and no; I tied these together by a better constraint staying initial must not be used, if and only if(IFF) the approved is yes and final must not be used IFF the approved is no; this would make a hierarchical method of indicating the readiness;... if you wanted you could expand by using the state and sub-states; basically, approved, state, sub-state specify different granularity; in  this scenario, tie is needed to avoid conflicting combinations; ..it is required; now defined as default; I think it is not offensive; if people want to be able to merge right away ,they can set the flag to yes, otherwise set it to no; Yves thought approved is completely a different entity; it is just a readiness indicator; he also does not want to be forced to change the flag; this is also catered in this scenario when the flag is required and undefined; it comes back to the decision whether they are dependent or not; whether the flag is completely different or not; I think that the readiness indicator is narrowing down the semantics; r: - I actually can see a need for both; need for determining whether a translation has been reviewed and approved; or reviewed and not approved; I see that completely separate from being able to merge or not; df: - we all agree that we don’t' want to implement too much workflow prescription logic into the spec; if we have the approved flag, approved flag can be used as a readiness indicator; .. I would not multiply the flags; I prefer the current solution; if the TC wants to disconnect them, let's do it; r: - I don’t see readiness and approved … review as the same thing; our use case is similar to Yves’; merge can happen at any time independent of whether something has been translated and approved or not; f: - we do the same thing; r: - approved is a completely separate workflow concept; - if we say that reviewed and final state values incorporate whether a translation has been approved or not, then I don’t even see a need for the approved or canMerge attributes at all; f: -I'd agree; I don't completely understand why all users could just derive from state if they wanted to merge that portion of the translation or not; df: - because state is optional and it has four states and it's not simple; y: - that does not present any merging based on the ...; you can decide what to do; df: - the default value is initial; does not seem very intuitive to merge back with the initial to me; f: - if a tool need on ... approved flag to be compatible I think it means that we would set the approved or canMerge to yes before we translate anything at all; in that case we would do a source-roundtrip test; dF: - what are you merging after you just generated the XLIFF? f: - we are running an automated copy of .. source to target; df: - it's ok to do;  why not set a flag when doing that; when it goes away really for the translation you can set it again to No? y: - why make things complicated? df: - this was a month now; I don't know what to think; y: - approved flag has always been a problem; we got comments from outside people; it was there for a while; df: - when I started the discussion, no one reacted until I proposed the solution; let's agree on something; y: - it seems to me ... consensus on that state can provide information about the state of the translation and ... merge based on the state of the translation .. I am wondering why canMerge or approved flag is needed at all; the only reason was because you said that some process want to set ... is it  something useful? I am just wondering whether it's useful to have that flag; r: - I don’t think it is useful; df: - everyone thinks (except me) state is enough; f: - state together with sub-state; df: - sub-state is not public so it is not interoperable; it's only useful if you are in a private loop; r: - if we think values for state does not cover general workflows well enough for most consumers, then we should consider changing values in state; I think most people agreed that's enough; df: - they are enough in general; values of state provide some interoperability for sub-state; r: - that's correct; we don't need any other values; df: - we currently have 1 PR and 1 constraint using the approved attribute; r: - they are too prescriptive; df: - if you don't have them, then LSPs have no way to say don't merge y: - it has the state values; df: - state values are about the state of the translation y: - and that's not enough for the decision of merging or not? r: - what are the criteria ... translation? this is a translation interchange format.. df: - initial, translated, reviewed, final ... for tacking for what’s happening; [describes scenarios]; you can indicate by using the flags (canMerge or approved); why we artificially progress the state of  the translation when we know it is not final; we just decided to merge now for whatever reason y: - that's a decision the merger takes; df: - ..is there a way for service provider to tell the merger not to merge? y: - if it does not set the state to the minimum level to which the other provider is merging ..  that’s the way to do it; df: - it is overloading, you'd set to review or final just to give a signal; f: - if it's ready for merging, I would say its final in my opinion; df: - why so? it can be raw crowd sourced translation; it does not need to be final; it could be just published now; f: - then I would not want to merge it; df: - they would; they want some content; y: - in the crowdsourcing kind of merger, they are going to merge whatever they get; df: - there must be something in the target even if it is the copied source; there should be something in the target if you want to merge; y: - if … shouldn't merged what should you do? df: - if you don't merge you can call your LSP and ask them why it is not set for merge? ... y: - that would be probably fine ..; df: - it is not interoperable in the core; y: - adding something that says can merge, and not having the logic of the decision of why it has been set to merge is not interoperable either; df: - no one can misunderstand the yes or no; y: - why is it yes or no; df: - it is simple; y: - why it is set to yes or no; which criteria that have been chosen yes or no? df: - it is linked to the state to a certain extent; y: - I think it’s a weird case scenario; in the worst case scenario we could have one additional state like mergeable ; df: - it would confuse two different things in one value set; y: - there is a need for a flag that says you can merge or you cannot merge; and there is not enough discussion and proof of concept; we cannot make a decision on that at this point; it could be a module or something we add to .1; we don't need to stop everything to cater for one specific use case; df: - there could be more use cases [describes scenario]; f: - my problem is really with PR requirements on the flag; if somebody hasn't set merge="yes" on the segment we are not going to skip merging if there is something to merge; df: - you can do it; one who provided with the file set to no for a good reason; they told you not to merge; f: - then they should not have submitted to the file on the first place; df: - it could be on a repository that could be accessible for the both; b: - do we have enough information here to go with either Yves’ scenario, DavidF’s scenario, or shall we postpone the resolution of this? df: - Ryan suggested other combinatorics; what would be the options for a ballot?  Would you be happy with only two options or third or fourth options? r: - ... PR requirements around the approved state; df: - you don't like this? r: - I don't like prescriptiveness around the approved state; if there is only two options I would probably vote against the approved state due to prescriptiveness of it; f: - I agree; can merge with default "yes" ; if someone has set to "no" that means they have valid reasons to do so; y: - no specific PRs or any specific requirements; I’d be ok with that; df: - what would be usefulness if there was no PRs tied to it? y: - you could have "should" or so; f: - or say that an agent "may" refuse to merge segments for this state.; df: - are you saying "merger may refuse to merge if it set to no?"; I think the constraint on unit is not too restrictive; it says for a unit to be ready for merging it is required to have all the segments..  it is defining a state; it is not a PR..; you can do it but you have been told it is not being ready for merging; y: - it is a really weird requirement; df: - merger was told the unit is not ready for merging; it does not say you must not attend for merging; it only says on the segment; not on unit; we can move it from the segment if you like; but I would still define the state of readiness; f: - I think it should sit on unit, not on segment; df: - currently we have a PR on segment and a constraint on the unit; the constraint on the unit explains that the unit is not ready for merging if not all of its segments are not ready for merging.. r: - I think the only way we are going to move forwards is to have a ballot df: - I think too; we need to know the exact options; r: two options: what is currently in the specification as you have worded..; Yves wants to have the canMerge attribute; or to remove approved attribute; df: - I can after this meeting write these three options for a simple majority ballot; b: - are you saying it is an electronic ballot? df: - I think the third option need to be elaborated; if we can do it now; let's do it now; r: - I think it is clear enough so we can do it now; df: - not against, I second it; y: - we need to state the three different options then; df: option 1: approved related to state through PRs; uses approved to define merging readiness option 2: rename approved to canMerge; make it optional with default yes; remove relationship with state; add weak PR for Mergers option 3: drop the flag approved/canMerge. no PRs; df: - roll call: - t:abstain,f:2,r:3,y:3,b:2,a:abstain,k:3,df:1 df: - option 3 got three votes; df: - summery approval of comments: 017 - sm/em justification 019 - inline codes solution justification 023 - clarifications in mtc module 026/032/048/054 - changes and examples in mda module 045 - handling of xmlns attributes 051 - justification and clarification of [ignorable] 052 - clarification of mtc origin attribute 059 - corrections of schema leaves us with 031, 058, 003 to be still pursued offline; f: - very quick update on the two items that I have still: I have not been able to make good examples for slr module due to lack of time; for the other PR about renaming equivalent .... to Storage info I am actually against that because I believe that .. storage is more accurate name for the attribute; because it tells how many bytes of storage inline code would have in the native code when back coded df: - one of your slr actions would remain pending; one could be subsumed under the summery approval; which? f: 31 df: - I will include 31 - rejected rename; ...ballot for summery approval of solutions. b: - I second that. any objections? df: - ballot passes unanimously; - dropping the flag is so simple; - Tom and Fredrick will need to work on the examples by the end of August b: - if we have no controversy in the examples, this is quite doable; I feel that with this advancement I can take a second look at the calendar and predict when we are going to complete. df: - please commit and socialise. I will do the final printout out just in time for the meeting; - f,t does it sound doable by the end of August; f,t: yes; b: - no new business. meeting adjourned