Voting for providers on changes in IIA

[demilatof]

I open this new issue to discuss about the voting survey proposed today; I think we may need a place to better understand the options provided or to receive clarifications.

Termination as a whole For option B ("We need to keep content of the terminated IIA") we have two sub options:

1. Section <cooperation-condition>CCs<terminated-as-a-whole/></cooperation-condition> stays as is with an extra parameter at the end.
2. Section <cooperation-condition terminated-as-a-whole=”true”>CCs</cooperation-condition> stays as is with an extra attribute set to true (this is the only acceptable value of this attribute).

I don't remember we discussed about the option B2; I don't see any particular problem, but maybe that other developers can notice something relevant. As concern option B1, why we should put an extra parameter at the end? I think that at the beginning may be more useful for debugging.

Wrongly mapped IIAs When we read: "Now B realizes that mapping (A1, B1) is a mistake, and that it should be (A1, B2)." we consider only half of the problem, because A receives an IIA CNR for B2 and in some way it recognizes a new IIA, with a new Hash Code (or version number). But B could realize a different mistake, "the mapping (A1, B1) is wrong and it should be (A2, B1)". In this case, B sends an IIA CNR but A cannot realize the change because when it fetches the IIA the cooperation conditions are not changed (A1 is still the same).

I think that option 2 ("(A1,B1) is mutually approved. Both partners could have started mobilities") lacks of some consideration

How can we unmap a couple that has already been used to start the mobilities? We should have to check that all the cooperation conditions that have already produced mobilities are replicated in the new mapped IIA. Extremely difficult; I don't say that we cannot, but I stress that everybody should know that there maybe a lot of controls to add that we have no yet discussed here, on GitHub.

Moreover, if we can unmap after that (A1, B1) is mutually approved we introduce the possibility to delete an IIA by replacing it; but the deletion after the mutual approving should be forbidden, if I well understood.

Option 3 is represented under the hypothesis "B1 and B2 differ only slightly", but I think that already now, if we need to little modify an IIA to match the partner's one, we can change it. Therefore, how can the "option 3" be implemented when B1 and B2 differ deeply?

[janinamincer-daszkiewicz]

As concern option B1, why we should put an extra parameter at the end? I think that at the beginning may be more useful for debugging.

It's not for humans, so the order is only important from the point of view of the following rules:

• the required fields come before the optional ones,
• for the optional ones, the more frequently used ones come first,
• plus often newly defined fields are added at the end.

That's what we're trying to stick to.

[janinamincer-daszkiewicz]

the deletion after the mutual approving should be forbidden, if I well understood

Yes

[demilatof]

As concern option B1, why we should put an extra parameter at the end? I think that at the beginning may be more useful for debugging.

It's not for humans, so the order is only important from the point of view of the following rules:

* the required fields come before the optional ones,

* for the optional ones, the more frequently used ones come first,

* plus often newly defined fields add added at the end.

That's what we're trying to stick to.

Ok, I understand; if there is a rule, no objection. I thank you because this answer can make me change my mind in favor of option B2 (instead of B1), so that if I have to debug a problem, I see at a glance that the IIA is terminated as a whole

[demilatof]

the deletion after the mutual approving should be forbidden, if I well understood

Yes

If so, how we can change (A1, B1) mapping when it is mutually approved, without infringing the rule of no deletion after the mutual approving? E.g.: B unmap B1 and map B2, so that we have (A1, B2); now B1 is no more approved and can be deleted. We have violated the rule with a trick.

Unless the rule becomes "the deletion is forbidden until an IIA is part of a mutual approved couple of IIAs". But this formula is deeply different from the original one.

[demilatof]

Moreover, if we can unmap after that (A1, B1) is mutually approved we introduce the possibility to delete an IIA by replacing it; but the deletion after the mutual approving should be forbidden, if I well understood.

Could anyone suggest anything about the above issue? Unmapping after the mutual approve can give the maximum of flexibility in events that are anyway really occasional. But I'm afraid that allowing unmapping could increment the number of abuses of the functionality just to delete mutual approved IIA. This could be an unpleasant side effect.

[umesh-qs]

Moreover, if we can unmap after that (A1, B1) is mutually approved we introduce the possibility to delete an IIA by replacing it; but the deletion after the mutual approving should be forbidden, if I well understood.

Could anyone suggest anything about the above issue? Unmapping after the mutual approve can give the maximum of flexibility in events that are anyway really occasional. But I'm afraid that allowing unmapping could increment the number of abuses of the functionality just to delete mutual approved IIA. This could be an unpleasant side effect.

How do you define DELETE?

[demilatof]

How do you define DELETE?

In my opinion, if not elsewhere specified, DELETE is permanent, we loose every track of the item, IIA ID included (doesn't matter if in my implementation I do a soft delete, other partner can do a permanent deletion). And therefore the same IIA ID could later re-appear, because the deletion has made that IIA ID available again.

But this is no much relevant to my question: if we allow to un-map after mutual approving, we allow to:

1. Delete the no more mapped IIA (this infringe the rule "no deletion after mutual approving")
2. Allow the disapproval of mutual approved IIAs if we perform only half of the task

As a matter of fact, I don't see any point that makes mandatory to re-approve a mapping (new or old). So that, after we have approved the un-mapping to prepare the new mapping, we have agreed that the approved mapping doesn't exist anymore. It's irrelevant that we have a snapshot, we have approved an un-mapping. We are not compelled to re-map at last one of the IIA involved in the previous mapping, neither we have a deadline to revert to the previous mapping. We have approved that the previous mapping is no more valid, nothing else. This is not a termination, it is simply a disapproval. Do we accept to introduce a disapproval in EWP?

All that said, I think that it should be extremely rare that we have a wrong mapping after an approval (two copies of the IIA completely different, IROs should have noticed them....), but for the same reason I voted to forbid the un-mapping after the approval to limit the consequences. Much better doing a manual change in the DB if strictly necessary.

[umesh-qs]

How do you define DELETE?

In my opinion, if not elsewhere specified, DELETE is permanent, we loose every track of the item, IIA ID included (doesn't matter if in my implementation I do a soft delete, other partner can do a permanent deletion). And therefore the same IIA ID could later re-appear, because the deletion has made that IIA ID available again.

But this is no much relevant to my question: if we allow to un-map after mutual approving, we allow to:

1. Delete the no more mapped IIA (this infringe the rule "no deletion after mutual approving")
2. Allow the disapproval of mutual approved IIAs if we perform only half of the task

As a matter of fact, I don't see any point that makes mandatory to re-approve a mapping (new or old). So that, after we have approved the un-mapping to prepare the new mapping, we have agreed that the approved mapping doesn't exist anymore. It's irrelevant that we have a snapshot, we have approved an un-mapping. We are not compelled to re-map at last one of the IIA involved in the previous mapping, neither we have a deadline to revert to the previous mapping. We have approved that the previous mapping is no more valid, nothing else. This is not a termination, it is simply a disapproval. Do we accept to introduce a disapproval in EWP?

All that said, I think that it should be extremely rare that we have a wrong mapping after an approval (two copies of the IIA completely different, IROs should have noticed them....), but for the same reason I voted to forbid the un-mapping after the approval to limit the consequences. Much better doing a manual change in the DB if strictly necessary.

@demilatof I was asking DELETE in terms of the EWP specs and not the dictionary definition. If it is up to the partner to define the meaning of DELETE (allowing IIA to re-appear vs not allowing), then the same applies to un-mapping/mapping the approved IIA. Partner may choose to consider the old IIA as terminated and assume the new mapping as a new agreement.

[demilatof]

@demilatof I was asking DELETE in terms of the EWP specs and not the dictionary definition. If it is up to the partner to define the meaning of DELETE (allowing IIA to re-appear vs not allowing), then the same applies to un-mapping/mapping the approved IIA. Partner may choose to consider the old IIA as terminated and assume the new mapping as a new agreement.

@umesh-qs you asked me how I define DELETE and not how EWP specs define it or how I understand EWP specification definition. And to avoid misunderstanding, I define it as the dictionary does: a permanent removal.

In my opinion, if EWP wants to use the term DELETE, it must use with its real meaning, widespread understood, to avoid errors. No one should have his own interpretation. The same for mapping. We can decide in any way, but we have to understand well the side effects, otherwise we solve now a question and tomorrow we have a new problem.

All that said, I'm still waiting for an answer about deletion from @janinamincer-daszkiewicz or DG EAC that approved a solution that contains ambiguities: https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/100#issuecomment-1521658900

[janinamincer-daszkiewicz]

All that said, I'm still waiting for an answer about deletion from @janinamincer-daszkiewicz or DG EAC that approved a solution that contains ambiguities: https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/100#issuecomment-1521658900

Discussion continues in the referenced issue: https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/100#issuecomment-1537120096

[janinamincer-daszkiewicz]

@umesh-qs asked in email

Background information on general termination of IIAs: We assume that an IIA is mutually approved by both partners for a duration of several academic years. The partners have decided that they want to terminate the IIA, meaning as from a specific academic year, neither partner will be able to nominate and send its students to the other partner anymore. Despite the IIA being terminated, both partners need to be able to demonstrate in auditing by DG EAC and/or Erasmus+ National Agencies that there was an IIA in effect for the duration of any Erasmus+ funded student exchanges between the two partners. As decided in the IF – this will be handled by modifying the parameter <receiving-academic-year-end-id> -- when was it decided?

We agreed by voting to implement termination like any other modification and we rejected the other voting option to have separate termination and separate modification. Which means that to terminate IIA from let say 2024/2025 we will change the range of academic years from

<receiving-first-academic-year-id>2022/2023</receiving-first-academic-year-id>
<receiving-last-academic-year-id>2025/2026</receiving-last-academic-year-id>

to

<receiving-first-academic-year-id>2022/2023</receiving-first-academic-year-id>
<receiving-last-academic-year-id>2023/2024</receiving-last-academic-year-id>

(I use names of elements we want to propose for the change in academic years, see https://github.com/erasmus-without-paper/ewp-specs-api-iias/commit/6dd87624ff942a5a52dd99972396bed7d3e6d589)

[umesh-qs]

@umesh-qs asked in email

Background information on general termination of IIAs: We assume that an IIA is mutually approved by both partners for a duration of several academic years. The partners have decided that they want to terminate the IIA, meaning as from a specific academic year, neither partner will be able to nominate and send its students to the other partner anymore. Despite the IIA being terminated, both partners need to be able to demonstrate in auditing by DG EAC and/or Erasmus+ National Agencies that there was an IIA in effect for the duration of any Erasmus+ funded student exchanges between the two partners. As decided in the IF – this will be handled by modifying the parameter <receiving-academic-year-end-id> -- when was it decided?

We agreed by voting to implement termination like any other modification and we rejected the other voting option to have separate termination and separate modification. Which means that to terminate IIA from let say 2024/2025 we will change the range of academic years from

<receiving-first-academic-year-id>2022/2023</receiving-first-academic-year-id>
<receiving-last-academic-year-id>2025/2026</receiving-last-academic-year-id>

to

<receiving-first-academic-year-id>2022/2023</receiving-first-academic-year-id>
<receiving-last-academic-year-id>2023/2024</receiving-last-academic-year-id>

(I use names of elements we want to propose for the change in academic years, see 6dd8762)

I am not aware of anything that QS voted for. Assuming that voting on this specific change did happen. Can someone explain how can we differentiate between a change and a termination?

[janinamincer-daszkiewicz]

Assuming that voting on this specific change did happen.

Presentation for Infrastructure Forum meeting on 2023-03-15, slides 30-35.

Can someone explain how can we differentiate between a change and a termination?

We don't, because providers voted for option 2.

[umesh-qs]

Assuming that voting on this specific change did happen.

Presentation for Infrastructure Forum meeting on 2023-03-15, slides 30-35.

Can someone explain how can we differentiate between a change and a termination?

We don't, because providers voted for option 2.

So you are saying that below is what can happen and DG EAC is ok with that? Same agreement can continue endlessly?

From

2022/2023 2025/2026

To

2022/2023 2023/2024

To

2022/2024 2023/2027

To

2022/2023 2023/2025

[janinamincer-daszkiewicz]

2022/2024, 2023/2027, 2023/2025

These are not correct academic years

[umesh-qs]

From 2022/2023 2025/2026 To 2022/2023 2023/2024 To 2022/2024 2023/2027 To 2022/2023 2023/2025

ok. let me correct it. Point was "endless" use of an IIA. From receiving-first-academic-year-id -- 2022/2023 receiving-last-academic-year-id -- 2025/2026 To receiving-first-academic-year-id -- 2022/2023 receiving-last-academic-year-id -- 2023/2024 To receiving-first-academic-year-id -- 2023/2024 receiving-last-academic-year-id -- 2026/2027 To receiving-first-academic-year-id -- 2022/2023 receiving-last-academic-year-id -- 2024/2025

[janinamincer-daszkiewicz]

Yes, if the partners agree.

[umesh-qs]

Yes, if the partners agree.

Interesting. So at some point for an IIA that is in action, lets say for from year 2021/2022 to year 2024/25. I can change this as from 2025/26 to 2028/29. Assuming both parties approve, I can then change this IIA to terminate as a whole? Or may be DELETE it as point by @demilatof earlier. Basically an IIA that was in action at a point can be terminated/DELETED as a whole. Is that what the thought process is from DG EAC? I wish DG EAC participating in the discussion directly.

[janinamincer-daszkiewicz]

DELETE can only be done for IIAs which are not mutually approved. Termination as a whole has been described in an introduction to voting.

[demilatof]

Assuming both parties approve, I can then change this IIA to terminate as a whole? Or may be DELETE it as point by @demilatof earlier. Basically an IIA that was in action at a point can be terminated/DELETED as a whole. Is that what the thought process is from DG EAC? I wish DG EAC participating in the discussion directly.

I think that termination as a whole may happen only if we are in time, that is, the first mobilities are not yet started. Or the two partners agree that no mobility has produced effect (students were not interested, pandemic, war, hearth quake and so on). The fact that every time we need a mutual approval grant the max flexibility to the parties. And yes, from time to time, the parties can agree to terminate/suspend/resume/extend an IIA several times. But if there is even only one mobility "in effect", they cannot terminate as whole neither terminate before the academic year of that mobility. Who have to check? The IROs: if my IROs thinks that your proposal of amendment is acceptable, they approve it, otherwise they don't send any Approval CNR.

The problem about the DELETE is when we un-map two mutual approved IIAs; once un-mapped an IIA may be deleted. Anyway I think there are other issues with un-mapping after the mutual approval. I'll try to explain them later, in the appropriate issue

[umesh-qs]

Assuming both parties approve, I can then change this IIA to terminate as a whole? Or may be DELETE it as point by @demilatof earlier. Basically an IIA that was in action at a point can be terminated/DELETED as a whole. Is that what the thought process is from DG EAC? I wish DG EAC participating in the discussion directly.

I think that termination as a whole may happen only if we are in time, that is, the first mobilities are not yet started. Or the two partners agree that no mobility has produced effect (students were not interested, pandemic, war, hearth quake and so on). The fact that every time we need a mutual approval grant the max flexibility to the parties. And yes, from time to time, the parties can agree to terminate/suspend/resume/extend an IIA several times. But if there is even only one mobility "in effect", they cannot terminate as whole neither terminate before the academic year of that mobility. Who have to check? The IROs: if my IROs thinks that your proposal of amendment is acceptable, they approve it, otherwise they don't send any Approval CNR.

@demilatof in current design please explain how do I terminate an agreement that was earlier from 2022/23 to 2024/25 and then changed to 2027/28 to 2029/30?

The problem about the DELETE is when we un-map two mutual approved IIAs; once un-mapped an IIA may be deleted. Anyway I think there are other issues with un-mapping after the mutual approval. I'll try to explain them later, in the appropriate issue

[skishk]

In my opinion we can think a termination-as-a-whole like a modify on the IIA that need approval action, so until the partner doesn't approve it can't have effect.

More in general when someone need to change something and need the approval i think the 2 IROs talk together to discuss the change (any changes) and then send it to the other. If this not happen the partner could not approve the change if he doesn't like it. In the end of any case they have to talk to each other :relaxed:

this is my view and opinion to simplify the whole scenario, obviously if someone use any functionality inappropriately (eg: using terminate to simulate a delete or allow a delete) we can not do too much...

[demilatof]

@demilatof in current design please explain how do I terminate an agreement that was earlier from 2022/23 to 2024/25 and then changed to 2027/28 to 2029/30?

Do you mean that now we have a mobility from 2027/28 to 2029/30 and nothing else? Or do you mean that we have the old mobility from 2022/23 to 2024/25 plus a second one from 2027/28 to 2029/30?

In the first case, according my proposal, you keep the same XML code for IIA adding . In the latter case, you have to keep the academic years that have produced effects (from 2022/23 to 2024/25) and to remove the others (from 2027/28 to 2029/30). If I have well understood your question.

But, mean the way, why @janinamincer-daszkiewicz my proposal of adding an element <terminated-as-a-whole>true</terminated-as-a-whole> has been switched to: <terminated-as-a-whole/> ?

Someone make me noticed that some parser could have problems in distinguish an element empty to an element not present

[mkurzydlowski]

Someone make me noticed that some parser could have problems in distinguish an element empty to an element not present

@demilatof, can you elaborate on that? I don't really understand what you are saying. Maybe an example would be helpful?

[skishk]

probably some parser couldn't distinguish between :

<cooperation-condition>CCs<terminated-as-a-whole/></cooperation-condition> and <cooperation-condition>CCs</cooperation-condition>

where <terminated-as-a-whole/> is null in both situations

[demilatof]

probably some parser couldn't distinguish between :

<cooperation-condition>CCs<terminated-as-a-whole/></cooperation-condition> and <cooperation-condition>CCs</cooperation-condition>

where <terminated-as-a-whole/> is null in both situations

@mkurzydlowski as he said ;-) (he is the one who told me this morning)

I think there exist some workaround, but better to avoid problems, if they may happen

[demilatof]

As concern the un-mapping of mutually approved IIAs, I still have some doubts. May be due to my implementation, but I think it could be quite common. Scenario: I have (A1, B1) in my mapping table, and I have two fields (among others): B1_APPROVED_BY_ME, A1_APPROVED_BY_PARTNER. This is my representation of mutually approved IIAs.

I realize that I had to map A2 to B1 (and not A1, the one which was mutually approved). What can I do? I un-map A1 and send an IIA CNR, according to the specifications. B partner realizes that I have removed his IIA ID from my A1 IIA (un-mapping) and he does the same with B1, then he sends me an IIA CNR.

And then? We have an approved couple (A1, B1) and the same two IIAs un-mapped. The approved couple is still valid, we can revert to it if we need, whenever we want.

Anyway, now I'm ready to bind A2 (the right IIA) to B1. First problem for B partner: an IIA can be bound only to one IIA ID; instead he has (A1, B1) and now he want to map B1 to A2. Therefore he has two mapping for the same IIA B1. This is not allowed.

The second problem: invoking approval. B has still the approval for (A1, B1). Every time I invoke his Approval API for my old A1, he MUST answer with old hash code (version number), but in any case he has to say: "that version was approved". If I add again B1 to my A1 IIA, using the same version (who check if I use a new version number at every change?), B answers me that A1 is approved. But if now I invoke Approval API for my IIA A2, B has to answer again that even A2 is approved.

Can I have two IIA approved (A1, A2), both of them tied to the same IIA (B1)?

In my opinion, the great problem of un-mapping mutually approved IIAs is that before we must be able to approve the un-mapping, that is to void an approval; but there is no way in EWP to de-approve anything.

I point out that it's forbidden to approve an IIA not bound to the partner's IIA

[mkurzydlowski]

probably some parser couldn't distinguish between : <cooperation-condition>CCs<terminated-as-a-whole/></cooperation-condition> and <cooperation-condition>CCs</cooperation-condition> where <terminated-as-a-whole/> is null in both situations

@mkurzydlowski as he said ;-) (he is the one who told me this morning)

I think there exist some workaround, but better to avoid problems, if they may happen

I'm lost even more. @demilatof, what did I tell you this morning? Where?

[demilatof]

I'm lost even more. @demilatof, what did I tell you this morning? Where?

@mkurzydlowski I apologize for the misunderstanding... I replace the pronoun with the name:

@mkurzydlowski as @skishk said ;-) (@skishk is the one who told me this morning) I think there exist some workaround, but better to avoid problems, if they may happen

[janinamincer-daszkiewicz]

So now the question is directed to @skishk :)

probably some parser couldn't distinguish between :

What parser? Any details?

[demilatof]

So now the question is directed to @skishk :)

probably some parser couldn't distinguish between :

What parser? Any details?

Waiting for @skishk, my question still remains even if there are no problems with the parser. When I proposed to use this element at the beginning of the cooperation conditions, you explained to me that there is a kind of convention. Ok, I really appreciate that there is a standard. For the same reason now I ask because we should have a different way to represent the same thing (true/false) just because it is an optional element. For example, we have <in-effect> and <blended> that contain the value true/false.

[umesh-qs]

@demilatof in current design please explain how do I terminate an agreement that was earlier from 2022/23 to 2024/25 and then changed to 2027/28 to 2029/30?

Do you mean that now we have a mobility from 2027/28 to 2029/30 and nothing else? Or do you mean that we have the old mobility from 2022/23 to 2024/25 plus a second one from 2027/28 to 2029/30?

In the first case, according my proposal, you keep the same XML code for IIA adding . In the latter case, you have to keep the academic years that have produced effects (from 2022/23 to 2024/25) and to remove the others (from 2027/28 to 2029/30). If I have well understood your question.

@demilatof in the first case, what can happen is that I can now terminate the agreement as a whole, that was once in action. Is that correct to do? Also during the changes in an approved IIA, will the old contract remain valid? how can we access the old approved copy from the partner? Should the exchange of new students pause?

But, mean the way, why @janinamincer-daszkiewicz my proposal of adding an element <terminated-as-a-whole>true</terminated-as-a-whole> has been switched to: <terminated-as-a-whole/> ?

Someone make me noticed that some parser could have problems in distinguish an element empty to an element not present

[skishk]

So now the question is directed to @skishk :)

probably some parser couldn't distinguish between :

What parser? Any details?

Depends on the parser that every one use, if you use JAXB, for example, or others parser. So can't distinguish from the tag is not present because libraries are optimized to no wrote empty tag that are useless.

explained example: online example stackoverflow

tags are made to have a value or attribute empty tag like have no meaning so is null as is not present.

This just to say that is not a recommended way to manage it and it could be managed correctly from some parser and others no.

it is a different solution and better what @demilatof said about in-effect and blended tag.

Or it is a good solution too the <cooperation-condition terminated-as-a-whole=”true”>CCs</cooperation-condition> because use an attribute with a value.

[demilatof]

@demilatof in the first case, what can happen is that I can now terminate the agreement as a whole, that was once in action. Is that correct to do?

In my opinion, it should be correct, none of the mobilities in the cooperation conditions has ever started, therefore we can terminate as a whole.

Also during the changes in an approved IIA, will the old contract remain valid? how can we access the old approved copy from the partner? Should the exchange of new students pause?

Yes, it should remain valid and if no changes are approved again, we have to revert to it. They said that there is no need do access the old approved copy, we should rely on our snapshot of partner's IIA; I asked for an extra parameter to retrieve the last approved copy, but without success.

[umesh-qs]

@demilatof in the first case, what can happen is that I can now terminate the agreement as a whole, that was once in action. Is that correct to do?

In my opinion, it should be correct, none of the mobilities in the cooperation conditions has ever started, therefore we can terminate as a whole.

@demilatof whether any mobility started as per the contract or not, is only known to the IROs. System cannot determined that, unless IIA ID is mandatory in the mobility specifications. We are allowing data corruption for a contract that was operational at some point. There has to be some checks on what can be changed and until when it can be changed. With this approach there is no end of life for an IIA ID and it will remain forever. We need a mechanism to terminate/remove/mark obsolete an agreement once it is no more needed.

Also during the changes in an approved IIA, will the old contract remain valid? how can we access the old approved copy from the partner? Should the exchange of new students pause?

Yes, it should remain valid and if no changes are approved again, we have to revert to it. They said that there is no need do access the old approved copy, we should rely on our snapshot of partner's IIA; I asked for an extra parameter to retrieve the last approved copy, but without success.

[mkurzydlowski]

You are right to suggest that it is better to stick to xs:boolean. Still I think that this should be an optional element as it will very rarely be set to true. Thanks for pointing this out!

[demilatof]

@demilatof whether any mobility started as per the contract or not, is only known to the IROs. System cannot determined that, unless IIA ID is mandatory in the mobility specifications. We are allowing data corruption for a contract that was operational at some point. There has to be some checks on what can be changed and until when it can be changed. With this approach there is no end of life for an IIA ID and it will remain forever. We need a mechanism to terminate/remove/mark obsolete an agreement once it is no more needed.

I don't understand your objection. Every step needs a new approval, that is the IROs know if they can approve or not. They know if it is possible to flag a "terminate as a whole" or not, depending on their mobilities. They know if a mobility can be terminated even if it is already started.

In the real world we have often exception of this type; we give the IROs the flexibility to do what they need to adjust an IIA. We can implement a warning in the GUI, if we wish, but then it is up to the IROs to choose the best option (terminated, terminate as a whole, modify, and so on)

[skishk]

in point 5 (in the survey) is mentioned "language requirements" , what does it mean?

[demilatof]

in point 5 (in the survey) is mentioned "language requirements" , what does it mean?

I think they refer to this

[skishk]

in point 5 (in the survey) is mentioned "language requirements" , what does it mean?

I think they refer to this

thank you !

so something recommended will be mandatory :sweat_smile: I hope just for the incoming flow because each Institution recommend a language level of incoming people

[demilatof]

thank you !

so something recommended will be mandatory sweat_smile I hope just for the incoming flow because each Institution recommend a language level of incoming people

My concerns are that now the language levels are at "MobilitySpecification" level, that is at the top. If they want to differentiate study from traineeship, I have to touch a lot of code that now is common between the two types of mobilities.

My proposal is to not touch the XML schema.

[mkurzydlowski]

I agree with @demilatof, that changing XML schema is not worth it.

If we choose to update the description then I propose: https://github.com/erasmus-without-paper/ewp-specs-api-iias/commit/a4e987b06a44ee71f65c94a338bf2598245c653d

[janinamincer-daszkiewicz]

There was a short discussion on this topic during yesterday's Infrastructure Forum meeting (2023-05-17). If there are still open issues and you are strongly against the proposed commit, please let us know in this issue. We would like to finalise this topic before the next meeting (2023-05-31).

[skishk]

about Language Skills required : "Align recommended language levels to programme rules: It is mandatory to provide this information for Student Mobilities for Studies and Staff Mobility for Teaching"

that means all Student Mobilities for Studies and Staff Mobility for Teaching that now don't have this information specified and the IIA is already approved then they will have this information added and they will need all the approval flow. so all the IIA of the network needs new approval. right?

[janinamincer-daszkiewicz]

I hope this is already clear how to handle missing values in the fields which are now required.