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: 20 August 2013


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



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