Process for correcting wrongly mapped IIAs about ewp-specs-api-iias HOT 160 CLOSED

Let's wait for the community to decide first on how to handle this, technically, before writing "Please note there is no restriction on changing an agreement that is approved from both side" as it is some kind of global truth.

@kkaraogl
Could you show me where is written that once approved by both parties, an IIA cannot be modified and approved again as it was the first time?
The community is discussing about the problems this solution involves, and how to agree on a better procedure.
But this doesn't mean that currently the specifications are saying "once approved by both parties, the IIA cannot be modified".
And therefore, the general procedure is the only still valid

from ewp-specs-api-iias.

Yes, if there is wrong mapping it has to be corrected and one of the partners should start (points 8-10).

@kkaraogl I hope Dashboard is able to handle this scenario.

from ewp-specs-api-iias.

Yes. Please note there is no restriction on changing an agreement that is approved from both side.

from ewp-specs-api-iias.

You always tend to divert from one point to another. You mentioned that spec is very clear on it. Where does the spec say changes to approved IIA is not allowed? In fact the mandatory business requirement tied to the spec just tells that changes to approved IIA are allowed.
I would like to mention here that we have this even before work on Dashboard started and even before you were part of it.
Also there are already providers who have implemented the process to allow changes after IIA is approved.
Probably you are not aware of lot of stuff that happened before you just like you were not aware how IIAs were approved earlier compared to how it is done now.
Please do not generalize how Dashboard works. You even implemented auto creation of IIA and sharing without user input. Does the spec say this is allowed? So please get out of the notion that whatever Dashboard does must be followed by everyone.

from ewp-specs-api-iias.

By sheer luck, the email presenting and asking the providers' community to vote on the specs options of making changes to approved by both IIAs, just arrived in my inbox.

Too much of a coincidence. But that doesn't change the fact the specs do not restrict changes in approved IIA and the fact that it is a mandatory business requirement tied to IIA spec

from ewp-specs-api-iias.

@umesh-qs I am ignoring the remark of me disappearing from the forum as usual, because it is kind of unfair, and sounds like an insult.

Again, this is not about the Dashboard. The steps you proposed will not work, in my opinion, for all partners, and will add to the confusion.

We can follow up on this in a call, to properly discuss this.

Let's investigate collaboratively If there is a simple wholesome technically feasible way to handle this, and we will not object to it. If there is such a solution, then both of us will come on this thread asking from Warsaw to acknowledge the issue and properly address it from specs.

@kkaraogl it might sound unfair, but I am only telling the what I have seen. Last reply from @demilatof seems to suggest the same. Also your point of view has and is always from Dashboard perspective. I have mentioned this earlier and I am saying it again.
We will do what is best for our clients and not go by what technical problems/limitations Dashboard has. AND THIS IS NOT A PROPOSAL. THIS IS A GENUINE USE CASE. Your limitation cannot force us to limit our system. I cannot force my clients to do more work for a silly mistake that they can make when linking IIAs

from ewp-specs-api-iias.

@umesh-qs if Partner A calls the IIA Get in Step 7, could you please list how many and which IDs is gonna find in there?

Let me try to explain from Dashboard perspective as you most likely are thinking in that direction only

1. MoveOn creates new IIA (IIA1) and shares it with Dashboard with empty partner IIA ID
2. Dashboard automatically creates IIA (IIA2) in their system and share their IIA with MoveOn
3. MoveOn automatically links Dashboard IIA (IIA2) with their IIA (IIA1)
4. MoveOn user finds that there is already an IIA (IIA3) shared by Dashboard earlier
5. MoveOn user unlinks IIA2 with IIA1. CNR sent to Dashboard
6. Dashboard pulls IIA1 from MoveOn and finds IIA2 missing.
7. MoveOn user links IIA3 with IIA1. CNR sent to Dashboard.

What is Dashboard doing in step 6?

I cannot be more detailed then this. I hope this is clear.

from ewp-specs-api-iias.

@umesh-qs I already did pinpoint where the problem with the proposal lies, multiple times.

This issue persists in the production network, because there are some implementations that unilaterally disseminate this changing of IDs from their local implementations to their remote partners.

I will send an email to QS technical team, Monday morning, to collaboratively discuss the issue, show you where your proposal lacks, and investigate if we can jointly bring forward a wholesome technical proposal for other partners and Warsaw to review publicly in GitHub. Please do take up on the offer to collaboratively figure this out.

@kkaraogl I think you have not provided any counter arguments. Even if you would have I am sure all are countered. If not please for benefit of everyone please list down again.
Can you please elaborate on "unilaterally disseminate this changing of IDs"? This is where I say you only think from the current design of Dashboard.
I am open discussion on call, once you have listed down the problems with changing the mapped IIA ID, which I already mention is one of the workflow that is already in place.

from ewp-specs-api-iias.

@umesh-qs specs are pretty clear about what I wrote above:

ewp-specs-api-iias/endpoints/get-response.xsd

Line 99 in 83a208e

<xs:element name="iia-id" type="ewp:AsciiPrintableIdentifier" minOccurs="0" maxOccurs="1">

What is the problem with this point? It may always happen, not only when someone removes the mapping.

Could you contribute on how you are currently dealing with it or how you suggest that the other partners should interpret it and act upon it?

If A gets B1 and doesn't find the mapping with A1, in our implementation the IRO see an error and:

1. Cannot approve B1
2. Can select "remove this association" and remove A1-B1 from A1

After point 2 we have reset the situation to the initial point: we have A1 that we need to associate to another B's IIA.
Since we fetch all B's IIAs by means of the Index API, we most probably have even B2 that suggest a mapping with A1.
The IRO can check this suggestion and eventually associate A1 to B2.
I think that this is a normal good practice, no much complicated.

In our implementations we always start from our IIAs; if we lack some IIA, we may add it.
But our implementations are not driven by partner's IIAs

from ewp-specs-api-iias.

we are discussing an internal implementation of each system that is not EWP spec.
Everyone choose how to manage it and if you choose to link/bind automatically you have to manage this scenario when someone remove the link/binding.
if you choose to link/bind them manually you already could manage all scenarios.

this is my point of view.

from ewp-specs-api-iias.

1. Yes – users can freely map and unmap copies of IIAs.

I agree with point 1 : user can freely map and unmap copies of IIAs.

In every scenario this happen, mutual approved or one side approved or not still approved, this must be managed as a change that need approval , in my opinion. That solve all scenarios.

from ewp-specs-api-iias.

Yes, if there is wrong mapping it has to be corrected and one of the partners should start (points 8-10).

from ewp-specs-api-iias.

Yes, if there is wrong mapping it has to be corrected and one of the partners should start (points 8-10).

@kkaraogl I hope Dashboard is able to handle this scenario.

I hope too, but I think that at point 5 it would be better if B contacts A by mail/phone.
It seems to me that you do everything in an automatic way, relying on partner information to map you IIA.
For us it could only be a suggestion, nothing more. Our officer has to choice by his/her self the partner's IIA.

Therefore, we could already have the right mapping and ask partner to correct its mapping.
Obviously, until then we will not send an Approval CNR.

from ewp-specs-api-iias.

What is the problem that these steps are aimed to correct?
Is it for implementations that do not support 1:1 mapping?
I need some context before responding.
I don't understand Step 5.
Step 7 will probably create duplicate in Partner A. There is no way to determine if this is a new IIA or a correction (unmapping/unbinding?) for an existing one.

from ewp-specs-api-iias.

What is the problem that these steps are aimed to correct?
Is it for implementations that do not support 1:1 mapping?

As concern what these steps are aimed to correct, I try to explain what I understood from @umesh-qs' description.
The problem concerns a bad mapping: e.g. you (A) mapped your ID A1 with my ID B1.
I realized that you made a bad mapping, because comparing the two IIAs I noticed that your A1 IIA is the same of my B2 IIA, not B1.

ps: personally I would ignore your IIA and I would email you to explain that your IIA A1 has a bad mapping.
In the mean time I add A1 to my B1 IIA and then I send you an IIA-CNR.
Are you able to modify the mapping in your A1 IIA, the one previously mapped by mistake with B1?

Step 7 will probably create duplicate in Partner A. There is no way to determine if this is a new IIA or a correction (unmapping/unbinding?) for an existing one.

Just to understand: every time you see one of my IIAs without a mapping, you create a new IIA in your system?
And if yes, only when you receive an IIA-CNR or even when you look for them starting from an IIA-Index?

from ewp-specs-api-iias.

Let's wait for Umesh to provide a decription of the problem.

@demilatof Dashboard acts only when it receives IIA-CNR from the partner. But there are other partners that heavily utilize the index endpoint. Not sure if we've tested with each other. Are you in the production network? If not, please ping us to test, whenever you feel ready.

from ewp-specs-api-iias.

What is the problem that these steps are aimed to correct?
Is it for implementations that do not support 1:1 mapping?

As concern what these steps are aimed to correct, I try to explain what I understood from @umesh-qs' description. The problem concerns a bad mapping: e.g. you (A) mapped your ID A1 with my ID B1. I realized that you made a bad mapping, because comparing the two IIAs I noticed that your A1 IIA is the same of my B2 IIA, not B1.

ps: personally I would ignore your IIA and I would email you to explain that your IIA A1 has a bad mapping. In the mean time I add A1 to my B1 IIA and then I send you an IIA-CNR. Are you able to modify the mapping in your A1 IIA, the one previously mapped by mistake with B1?

Step 7 will probably create duplicate in Partner A. There is no way to determine if this is a new IIA or a correction (unmapping/unbinding?) for an existing one.

Just to understand: every time you see one of my IIAs without a mapping, you create a new IIA in your system? And if yes, only when you receive an IIA-CNR or even when you look for them starting from an IIA-Index?

Yes this is what I mean. But I will not want my users to contact Dashboard. Instead I would like them to correct the mapping and send IIA CNR. This would mean that my partner would unlink the IIA triggering a CNR and then they would map the correct IIA which would trigger another CNR.

Also automatic creation of IIA when there is no mapping is a risky process. You are allowing your system to be screwed because of some problem in partner system. This can become worse if your system is doing bulk refresh and there is a problem in partner system, responding all IIA with empty partner IIA

from ewp-specs-api-iias.

@demilatof Dashboard acts only when it receives IIA-CNR from the partner. But there are other partners that heavily utilize the index endpoint. Not sure if we've tested with each other. Are you in the production network? If not, please ping us to test, whenever you feel ready.

If you don't receive an IIA-CNR, don't you initiate any process?
Thanks for your offer, we are still in dev; do you have an hei_id to contact the dashboard in dev?
We are doing the final internal test

from ewp-specs-api-iias.

Ok, I am now aware of what this is about. The issue is the partner changed their local ID, after they previously shared another local ID, i.e changing your local ID in the midst of negotiation. @umesh-qs please confirm.

Step 7 is tricky. There is no way for Partner A to identify that this is a correction in the local ID of the partner B of an IIA previously shared by simply doing an IIA Get. @umesh-qs do you have in mind what check should Partner A do to identify such a case by only parsing the IIA get?

from ewp-specs-api-iias.

Ok, I am now aware of what this is about. The issue is the partner changed their local ID, after they previously shared another local ID, i.e changing your local ID in the midst of negotiation. @umesh-qs please confirm.

@kkaraogl most likely at the start of negotiation. But not limited to that. As mentioned earlier, there can be some issue that causes partner IIA to be passed as empty in all IIAs

Step 7 is tricky. There is no way for Partner A to identify that this is a correction in the local ID of the partner B of an IIA previously shared by simply doing an IIA Get. @umesh-qs do you have in mind what check should Partner A do to identify such a case by only parsing the IIA get?

@kkaraogl Partner A should mark the IIA in error and ask institution to contact the partner. Then proceed based on discussion
Or
Partner A should unlink the IIA in their system and ask the partner to send correct linking or allow their client to provide correct linking.

from ewp-specs-api-iias.

@umesh-qs what is there on the XML response of the IIA Get, in Step 7, that will make Partner A determine that this IIA should be marked "in error" so that Partner A proceeds to the next steps?

from ewp-specs-api-iias.

@umesh-qs what is there on the XML response of the IIA Get, in Step 7, that will make Partner A determine that this IIA should be marked "in error" so that Partner A proceeds to the next steps?

IIAs that partner A had linked earlier are not linked any more.

from ewp-specs-api-iias.

@umesh-qs not sure what this means. There has to be something in the XML response to drive Partner A to identify such a case, and allow them to proceed in next steps.

from ewp-specs-api-iias.

Ok, I am now aware of what this is about. The issue is the partner changed their local ID, after they previously shared another local ID, i.e changing your local ID in the midst of negotiation. @umesh-qs please confirm.

@kkaraogl
I don't know if @umesh-qs agrees with me, but I think that the above issue could not be the only one.
It seems to me that you are blaming the partner that changed its local ID, as if you're waiting for your partner doing something (mapping and sharing); but it may happen that on your side someone has mapped the IIA-Ids before, and therefore you are the first who mapped the two IDs. And you could make an error.

Are you waiting for your partner's IIA-CNR before mapping yours IIA?

from ewp-specs-api-iias.

@umesh-qs if Partner A calls the IIA Get in Step 7, could you please list how many and which IDs is gonna find in there?

from ewp-specs-api-iias.

@umesh-qs I am investigating of whether the steps you propose can be applied globally. Nothing to do with the Dashboard or MoveOn.

The above scenario could work because Partner A initiated the IIA and wishes to change their local ID, but it is not the whole story.

Could you please detail it the same way with Partner A initiating the IIA but Partner B wishes to change their local IIA ID after they previously shared another local ID?

from ewp-specs-api-iias.

@umesh-qs I am investigating of whether the steps you propose can be applied globally. Nothing to do with the Dashboard or MoveOn.

The above scenario could work because Partner A initiated the IIA and wishes to change their local ID, but it is not the whole story.

Could you please detail it the same way with Partner A initiating the IIA but Partner B wishes to change their local IIA ID after they previously shared another local ID?

@kkaraogl Can you please respond on what Dashboard is currently doing in point 6?

from ewp-specs-api-iias.

@umesh-qs again, not a matter of Dashboard. Everyone could accommodate step 6, including Dashboard, if we agree. It is technically feasible.

Now back to the other scenario and its technical feasibility. Could you please detail it the same way with Partner A initiating the IIA but Partner B wishes to change their local IIA ID after they previously shared another local ID?

from ewp-specs-api-iias.

@umesh-qs again, not a matter of Dashboard. Everyone could accommodate step 6, including Dashboard, if we agree. It is technically feasible.

@kkaraogl will deal with other systems later on. I am asking this question specifically to you (Dashboard). How are you handling this currently?

Now back to the other scenario and its technical feasibility. Could you please detail it the same way with Partner A initiating the IIA but Partner B wishes to change their local IIA ID after they previously shared another local ID?

@kkaraogl Not sure what you want from me. You already listed the scenario.

from ewp-specs-api-iias.

@umesh-qs we don't. This is a new process you are proposing, right? We are now collaboratively trying to find a way to cover this.

But I am saying that it is technically feasible to cover this specific scenario. When Partner B creates it and Partner B wishes to change its local ID, Partner A can identify such a case from the IIA Get (A's local ID is not anymore in the response), and proceed with the "unlinking" steps.

When, let's say Partner A creates it, both partners have exchanged IDs, and then Partner B wishes to change its local ID, Partner A cannot identify this case by simply doing an IIA Get after B's CNR ( it will only find B's new IIA ID in the response, right?), and cannot proceed with the "unlinking" steps. The steps you are proposing will not work in these cases.

Unless I don't see something clearly... In which case, please do correct me.

from ewp-specs-api-iias.

4. MoveOn user finds that there is already an IIA (IIA3) shared by Dashboard earlier
5. MoveOn user unlinks IIA2 with IIA1. CNR sent to Dashboard
6. Dashboard pulls IIA1 from MoveOn and finds IIA2 missing.
7. MoveOn user links IIA3 with IIA1. CNR sent to Dashboard.

Point 5 may happen, so could be interesting to know what happens at point 6.
But why are you doing this in 2 steps?
At point 5 you could unlink IIA2, link IIA3 and send CNR.

from ewp-specs-api-iias.

4. MoveOn user finds that there is already an IIA (IIA3) shared by Dashboard earlier
5. MoveOn user unlinks IIA2 with IIA1. CNR sent to Dashboard
6. Dashboard pulls IIA1 from MoveOn and finds IIA2 missing.
7. MoveOn user links IIA3 with IIA1. CNR sent to Dashboard.

Point 5 may happen, so could be interesting to know what happens at point 6. But why are you doing this in 2 steps? At point 5 you could unlink IIA2, link IIA3 and send CNR.

Any change has to have a CNR. It is user driven so user might not link it immediately. I need to keep partner updated with the latest status.
This is just one example where it is done with client knowledge. Imagine there is a problem and all IIAs have partner ID empty. If Dashboard or any other provider can do bulk updates. So it is important to know how systems handle it, specially Dashboard that is catering to large user base.

from ewp-specs-api-iias.

@umesh-qs we don't. This is a new process you are proposing, right? We are now collaboratively trying to find a way to cover this.

But I am saying that it is technically feasible to cover this specific scenario. When Partner B creates it and Partner B wishes to change its local ID, Partner A can identify such a case from the IIA Get (A's local ID is not anymore in the response), and proceed with the "unlinking" steps.

When, let's say Partner A creates it, both partners have exchanged IDs, and then Partner B wishes to change its local ID, Partner A cannot identify this case by simply doing an IIA Get after B's CNR ( it will only find B's new IIA ID in the response, right?), and cannot proceed with the "unlinking" steps. The steps you are proposing will not work in these cases.

Unless I don't see something clearly... In which case, please do correct me.

@kkaraogl I am not proposing a new process. I am highlighting potential problem with some systems, if not handled properly.

from ewp-specs-api-iias.

Any change has to have a CNR.

@umesh-qs this is your interpretation.
For complex changes we'll send a CNR when finished, a CNR for every little change is only confusing.
Anyway, the change you propose can be done in one shot.

from ewp-specs-api-iias.

Any change has to have a CNR.

@umesh-qs this is your interpretation. For complex changes we'll send a CNR when finished, a CNR for every little change is only confusing. Anyway, the change you propose can be done in one shot.

Of course it is up to individual provider to interpret. In our system we do not restrict. So user can unlink and link it back, or contact the partner to correct it. But then even without CNR situation remains the same.
There would be systems doing bulk refresh of IIA without CNR.

from ewp-specs-api-iias.

There would be systems doing bulk refresh of IIA without CNR.

Using the index, because for whatever reasons we could miss CNR.
I think that in EWP project there is a lot of space for improving and very little availability for improving something.
E.g.: all we know that we cannot rely on a CNR.
But it is important to know if a CNR was sent, it can give a sort of timings declaring what the partner aimed to do.

I think that an improvement could be adding two elements in IIA, outside the cooperation condition:

1. IIA_CNR_sent
2. Approval_CNR_sent

They can help knowing if we are seeing an IIA that we miss due to a CNR lost or not.
What I'm not sure: may be helpful adding the hash code to specify at what version of IIA was sent the CNR?
I think yes, but I need to evaluate better

from ewp-specs-api-iias.

There would be systems doing bulk refresh of IIA without CNR.

Using the index, because for whatever reasons we could miss CNR. I think that in EWP project there is a lot of space for improving and very little availability for improving something. E.g.: all we know that we cannot rely on a CNR. But it is important to know if a CNR was sent, it can give a sort of timings declaring what the partner aimed to do.

I think that an improvement could be adding two elements in IIA, outside the cooperation condition:

1. IIA_CNR_sent
2. Approval_CNR_sent

I think it is overengineering. I would rather have my system designed internally to not to let any other provider screw it.

They can help knowing if we are seeing an IIA that we miss due to a CNR lost or not. What I'm not sure: may be helpful adding the hash code to specify at what version of IIA was sent the CNR? I think yes, but I need to evaluate better

from ewp-specs-api-iias.

In the following situations, should we allow the correction of the mapping?

1. Our agreement was already approved and the partner agreement was not.
2. We already approved the partner agreement, but the partner didn't approve ours.

from ewp-specs-api-iias.

I agree with Umesh: as an example, in our system (University of Bologna) the operator can always change an incorrect mapping, but we think that EWP Dashboard cannot handle this scenario.

from ewp-specs-api-iias.

yeah, in the real life of Agreements they could be change in any time for different reasons and they could be changed in their mapping with others Agreements for different reason. So i think is better to give to all IROs the possibility to work well with a good flexibility on the needed actions to not block the normal/real work of IROs like unfortunately is happening now...

from ewp-specs-api-iias.

Yes. Please note there is no restriction on changing an agreement that is approved from both side.

This is not true for all EWP partners.

I agree with Umesh: as an example, in our system (University of Bologna) the operator can always change an incorrect mapping, but we think that EWP Dashboard cannot handle this scenario.

Specs are pretty clear about this. Unless there is a common procedure followed by everyone, we all have to comply with what we have now.

This new proposal by Umesh discussed in this thread to tackle the issue of changing IDs in the midst of the flow, is technically not wholesome (in my opinion), as I've previously shared.

from ewp-specs-api-iias.

Yes. Please note there is no restriction on changing an agreement that is approved from both side.

This is not true for all EWP partners.

Then those partners are not following mandatory business requirement. Is Dashboard one of them?

I agree with Umesh: as an example, in our system (University of Bologna) the operator can always change an incorrect mapping, but we think that EWP Dashboard cannot handle this scenario.

Specs are pretty clear about this. Unless there is a common procedure followed by everyone, we all have to comply with what we have now.

Not sure what you mean by this point.

This new proposal by Umesh discussed in this thread to tackle the issue of changing IDs in the midst of the flow, is technically not wholesome (in my opinion), as I've previously shared.

It is not a new process. You are probably assuming it as a new process

from ewp-specs-api-iias.

The community discusses only recently on how to handle changes in approved by both IIAs, per the latest mandatory business requirements.

Hence the discussions in the Infrastructure Forum and the voting options on how to officially implement this, lead and guided by the specs.

The fact that you've implemented it unilaterally in a non-specs-regulated way, is another issue.

Let's wait for the community to decide first on how to handle this, technically, before writing "Please note there is no restriction on changing an agreement that is approved from both side" as it is some kind of global truth.

from ewp-specs-api-iias.

By sheer luck, the email presenting and asking the providers' community to vote on the specs options of making changes to approved by both IIAs, just arrived in my inbox.

from ewp-specs-api-iias.

We want to prepare a test scenario for this use case. Who else wants to comment? Do we already have a common understanding on how it should look like?

from ewp-specs-api-iias.

Devil is in the details. The proposed steps do not tackle the issue in a wholesome way, in my opinion. There are cases, as I've already shared in comments above, that have not been taken into account.

@janinamincer-daszkiewicz I saw you've shared the issue in the email alias. Hopefully, more colleagues will come and share their technical opinions of whether this proposal is feasible for all the possible cases.

from ewp-specs-api-iias.

We discussed this issue during the technical workshop in Thessaloniki (30-31 March 2023). The final conclusion was that we need strict and simple rules because even if some partners can implement sophisticated solutions and cope with the problem of mapping changes, some may not. Also the whole mapping business will create additional confusion for end users. If we decide that changing mapping is like any other change (e.g. number of mobilities) and can be done at any time in an asynchronous way in a distributed system we may have many scenarios to discuss and elaborate (and more potential errors).

The proposed approach is the following.
IIA-id is a key of the copy of the IIA (its primary key). A pair of (mapped) copies is identified by a pair of iia-ids. They should also be treated as the primary key. Different primary keys mean that we have different objects. If the system find out that the local IIA with some id A1 once mapped with id B1 now comes from the partner mapped with another id B2, it should treat this as an error. Identifiers are identifiers and should not be freely mapped and unmapped.

Instead of changing the mapping a system can change the (content of the) object and keep the mapping.

from ewp-specs-api-iias.

The proposed approach is the following. IIA-id is a key of the copy of the IIA (its primary key). A pair of (mapped) copies is identified by a pair of iia-ids. They should also be treated as the primary key. Different primary keys mean that we have different objects. If the system find out that the local IIA with some id A1 once mapped with id B1 now comes from the partner mapped with another id B2, it should treat this as an error. Identifiers are identifiers and should not be freely mapped and unmapped.

Instead of changing the mapping a system can change the (content of the) object and keep the mapping.

Are we talking about mutual approved IIA?
If so, I may agree; otherwise, I have some doubts and don't understand what is the difficulty to disassociate an IIA and to reset the process.
If A1-B1 is a key, there is no problem to make a second key with A1-B2, keeping or not the old key.

from ewp-specs-api-iias.

Are we talking about mutual approved IIA?

Mutually approved objects must not be mapped/unmapped.

If so, I may agree; otherwise, I have some doubts and don't understand what is the difficulty to disassociate an IIA and to reset the process.
If A1-B1 is a key, there is no problem to make a second key with A1-B2, keeping or not the old key.

Because it adds complexity. One partner changes mapping from A1/B1 to A2/B1, in the same time the other partner changes mapping from A1/B1 to A1/B2 etc.

from ewp-specs-api-iias.

Because it adds complexity. One partner changes mapping from A1/B1 to A2/B1, in the same time the other partner changes mapping from A1/B1 to A1/B2 etc.

Already now a partner can map A1/B1 and the other A1/B2.
And what we have to do? Thrash away everything or one of the two partners has to correct his mapping?
We don't want to interfere with internal systems, but some internal system can interfere with the whole network?
There is no much complexity in voiding a key for IIAs not mutually approved.
If someone finds this too complex may he/she should ask why to themselves.

Identifiers are identifiers and should not be freely mapped and unmapped.

Instead of changing the mapping a system can change the (content of the) object and keep the mapping.

And IIA-ID is the "unique surrogate ID of this IIA" and not for a different IIA.
You instead are suggesting to infringe the specification for a not clear complexity and to transform the IIA in something else.

from ewp-specs-api-iias.

Thrash away everything or one of the two partners has to correct his mapping?

Yes. But making a copy and starting from scratch is not a big deal.

There is no much complexity in voiding a key for IIAs not mutually approved.
There is a lot of complexity of understanding what is going on, what is allowed, what not and how to recover from this situation.

And IIA-ID is the "unique surrogate ID of this IIA" and not for a different IIA.

Replacing current content and keeping the previous identifiers will simplify the understanding.

for a not clear complexity

Complexity is very clear. We have evidence in the network with much less complex issues which create problems like putting many emails into a field for one email. or not ordering academic years, or not keeping the format of the telephone number. You can find many examples here: https://stats.erasmuswithoutpaper.eu/monitoring.

from ewp-specs-api-iias.

Anyway, DG EAC will make a final decision.

from ewp-specs-api-iias.

Yes. But making a copy and starting from scratch is not a big deal.

May be for some implementations that are interested in this solution, not for all.
I hope we all agree that EWP is not living alone; we have other tools that share an IIA and its IIA-Id. We cannot change their content to satisfy the incapacity of someone to change a mapping.

Replacing current content and keeping the previous identifiers will simplify the understanding.

It's your opinion and may infringe the specifications
In my opinion, in the master-master model my IIA-ID represent a given IIA; there is no simplification if it could represent something different.

Complexity is very clear. We have evidence in the network with much less complex issues which create problems like putting many emails into a field for one email. or not ordering academic years, or not keeping the format of the telephone number. You can find many examples here: https://stats.erasmuswithoutpaper.eu/monitoring.

You're not giving me any example of the complexity in changing the mapping. What you are listing are mistakes that nothing has to do with your proposal or with the complexity in changing the mapping.

Anyway, DG EAC will make a final decision.

Hoping they understand the problem, because it's mainly a technical matter that could interfere with internal systems.
Before asking DG EAC I think that we (all) should have to discuss on GitHub and vote during an Infrastructure Forum.

from ewp-specs-api-iias.

DG EAC will decide if voting is needed.

from ewp-specs-api-iias.

DG EAC will decide if voting is needed.

...if voting is needed about:

The proposed approach is the following.

That is: you propose something to DG EAC that modifies the behavior of internal system without consulting the providers and if DG EAC says that there is no need to vote, this proposal becomes a requirement without a shared discussion?

from ewp-specs-api-iias.

In this GitHub issue I shared results of the discussion from Thessaloniki. GitHub issue is not closed, anybody can comment.
DG EAC will make a decision.

from ewp-specs-api-iias.

In this GitHub issue I shared results of the discussion from Thessaloniki. GitHub issue is not closed, anybody can comment. DG EAC will make a decision.

@janinamincer-daszkiewicz
Since you are referring to the discussion Thessaloniki, please post here all the providers who voted against changing the mapping IIA ID in Thessaloniki.

As @demilatof mentioned, please point out the specific complexity that you are referring to. Let us not make wild assumptions without providing examples.

As for the voting, I see rules of the game are being changed often. I am not sure how and when this new rule of DG EAC allowing voting came into effect. You cannot pick and choose what goes for voting and what doesn't. If there is a disagreement, it must go for voting.

from ewp-specs-api-iias.

Since you are referring to the discussion Thessaloniki, please post here all the providers who voted against changing the mapping IIA ID in Thessaloniki.

There was discussion, not voting. I leave to the providers decision if they want to be named.

please point out the specific complexity that you are referring to.

I already did and will not be repeating myself. I leave the floor to the others.

DG EAC is making decisions, the rules are not changed, before the previous voting this was also their decision what exactly should be voted.

from ewp-specs-api-iias.

Since you are referring to the discussion Thessaloniki, please post here all the providers who voted against changing the mapping IIA ID in Thessaloniki.

There was discussion, not voting. I leave to the providers decision if they want to be named.

@janinamincer-daszkiewicz then let us not try to influence the voting. And if there was a discussion then I assume that pros and cons would have been discussed. I would expect that to be listed instead of a one line that discussion happened

please point out the specific complexity that you are referring to.

I already did and will not be repeating myself. I leave the floor to the others.

@janinamincer-daszkiewicz No you didn't. Please explain with examples. Merely specifying "complexity" wont do.

DG EAC is making decisions, the rules are not changed, before the previous voting this was also their decision what exactly should be voted.

@janinamincer-daszkiewicz This is not true. Again misleading. Process is to go for voting whenever there is lack of consensus.

from ewp-specs-api-iias.

Since you are referring to the discussion Thessaloniki, please post here all the providers who voted against changing the mapping IIA ID in Thessaloniki.

There was discussion, not voting. I leave to the providers decision if they want to be named.

I attended remotely, I don't remember any discussion about this, otherwise I would have said or written something.
May be I missed it; may even be they talked about this problem during a coffee or during the tests.

Anyway, I saw no more than fifty participants in Zoom, and some of the connection where present twice or three times in the same moment.
In Thessaloniki there were 10-12 peoples, including Janina and Kostantinos.
Too few people and too little representative (them, including me, are in-house system developers) to address a problem toward a solution or another.
We are talking of no more twenty HEIs against thousands.

If I have a problem, I expose myself. @umesh-qs is doing the same. Doing so, we expose ourselves to criticism, no problem.
I think that if someone considers the changing mapping a problem he must expose his/her problem on GitHub.
Otherwise we may think that there isn't a real owner of the problem neither a real issue, but this a problem in your implementation or in the implementation of someone near you.

@janinamincer-daszkiewicz then let us not try to influence the voting. And if there was a discussion then I assume that pros and cons would have been discussed. I would expect that to be listed instead of a one line that discussion happened

please point out the specific complexity that you are referring to.

I already did and will not be repeating myself. I leave the floor to the others.

@janinamincer-daszkiewicz No you didn't. Please explain with examples. Merely specifying "complexity" wont do.

@umesh-qs I confirm, until now it is complex because it is.

from ewp-specs-api-iias.

@demilatof more than 35 testing sessions in pairs have occurred in the workshop. Have you tested with someone during the sessions?

For this thread, Umesh's proposal is not wholesome, in my opinion. I've already shared it a couple of times in this thread. Until someone presents a simple and efficient way, always keeping in mind the integrity of data for both involved partners, I cannot add anything else here.

from ewp-specs-api-iias.

@demilatof more than 35 testing sessions in pairs have occurred in the workshop. Have you tested with someone during the sessions?
@kkaraogl this is irrelevant. Please focus on this issue.

For this thread, Umesh's proposal is not wholesome, in my opinion. I've already shared it a couple of times in this thread. Until someone presents a simple and efficient way, always keeping in mind the integrity of data for both involved partners, I cannot add anything else here.

@kkaraogl please share the problem with example. Let us not go over again and again with one liners.
@janinamincer-daszkiewicz please share here the details of the discussion in detail (pros and cons).

from ewp-specs-api-iias.

@umesh-qs I already did, multiple times. Until someone presents a simple and efficient way, always keeping in mind the integrity of data for both involved partners, I cannot add anything else here.

from ewp-specs-api-iias.

@umesh-qs I already did, multiple times. Until someone presents a simple and efficient way, always keeping in mind the integrity of data for both involved partners, I cannot add anything else here.

No you didn't. You are replying exactly same as @janinamincer-daszkiewicz . Please explain what is the complexity here for the IIAs that are not approved?

from ewp-specs-api-iias.

@demilatof more than 35 testing sessions in pairs have occurred in the workshop. Have you tested with someone during the sessions?

No, because I'm alone in developing our in-house system and we are not yet ready (almost ready, but not completely).
And I'm involved not only in this project, but even in the existing Erasmus software at our HEI.
And, moreover, I've to spend half of my time discussing here to stop proposals that have no sense or are necessary due to a bad design and analysis of the EWP.
I answered you, even if I've not to justify myself.

All that said, you may consult your file to realize that 35 testing sessions means 14 HEIs.
https://docs.google.com/spreadsheets/d/19nldiHlWsbBOF0gX_RR2ySvsmP9U7xL4TfkIeT9VTD0/edit#gid=196398466

For this thread, Umesh's proposal is not wholesome, in my opinion. I've already shared it a couple of times in this thread. Until someone presents a simple and efficient way, always keeping in mind the integrity of data for both involved partners, I cannot add anything else here.

Who has an issue, should publicly declare it, not during a coffee or a private chat.

from ewp-specs-api-iias.

@demilatof please ping the EWP Dashboard team whenever you are ready to test in the development registry. Most of your questions and objections will be resolved by testing, once you actually test the exchanges with a working implementation of another partner.

If you still have objections or questions you could bring them up in GitHub, not the other way around.

Please don't take this the wrong way, I am simply suggesting the way that makes sense to me, after testing with a vast number of partners.

from ewp-specs-api-iias.

@kkaraogl since you have come to the discussion forum, please do not disappear as usual before closing this.
Also if there are problems with Dashboard, as the previous comment suggests then fix those in Dashboard and not just blindly say it is complex.

from ewp-specs-api-iias.

@umesh-qs I am ignoring the remark of me disappearing from the forum as usual, because it is kind of unfair, and sounds like an insult.

Again, this is not about the Dashboard. The steps you proposed will not work, in my opinion, for all partners, and will add to the confusion.

We can follow up on this in a call, to properly discuss this.

Let's investigate collaboratively If there is a simple wholesome technically feasible way to handle this, and we will not object to it. If there is such a solution, then both of us will come on this thread asking from Warsaw to acknowledge the issue and properly address it from specs.

from ewp-specs-api-iias.

If you still have objections or questions you could bring them up in GitHub, not the other way around.

Is what I have done, I write often in GitHub. Did you do the same?

Please don't take this the wrong way, I am simply suggesting the way that makes sense to me, after testing with a vast number of partners.

So this is your need or your proposal?

Also if there are problems with Dashboard, as the previous comment suggests then fix those in Dashboard and not just blindly say it is complex.

As a matter of fact, often I have the impression that we have to conform to the Dashboard model and not the contrary, even when it could be a good practice.

from ewp-specs-api-iias.

Again, this is not about the Dashboard. The steps you proposed will not work, in my opinion, for all partners, and will add to the confusion.

Your opinion should not be more relevant than the others.
You haven't explained what is the confusion, until now.
I have two IIAs bounded together with A1 id and B1 id; I make a change and I associate A1 to B2, and send you an IIA CNR.
Now, two possibilities:

1. If your IROs work basing on their IIAs, when they open B1 IIA they see that it is bounded with A1 IIA that instead is bounded to B2. You remove B1-A1 association and open B2 to join it to A1.
2. If your IROs work reacting to IIA CNR, they fetch A1 IIA, they see that it was joined with B2 and therefore they remove any other association with A1 IIA.

Where is the confusion, where is the complexity?

The confusion starts with your proposal, when the content on an IIA start flying from an IIA ID to another.

We can follow up on this in a call, to properly discuss this.

No, this is a public matter, all are interested in this solution and can bring their contribute.

from ewp-specs-api-iias.

@kkaraogl it might sound unfair, but I am only telling the what I have seen. Last reply from @demilatof seems to suggest the same. Also your point of view has and is always from Dashboard perspective. I have mentioned this earlier and I am saying it again.
We will do what is best for our clients and not go by what technical problems/limitations Dashboard has. AND THIS IS NOT A PROPOSAL. THIS IS A GENUINE USE CASE. Your limitation cannot force us to limit our system. I cannot force my clients to do more work for a silly mistake that they can make when linking IIAs

Standing ovation ;-)

from ewp-specs-api-iias.

@umesh-qs again, nothing to do with the Dashboard. I am sharing my technical opinion on this matter.

You proposed some steps to tackle a problem. I've shared my opinion and pinpointed why it is not technically feasible.

I've also offered to collaboratively figure it out, thoroughly test it, and bring forward a joint proposal for Warsaw to review and address it from specs. So that all partners in the network can implement it without adding more confusion.

I will send an email to QS technical team, Monday morning, to collaboratively discuss the issue, and investigate if we can jointly bring forward a wholesome technical proposal for other partners and Warsaw to review publicly in GitHub.

from ewp-specs-api-iias.

@umesh-qs again, nothing to do with the Dashboard. I am sharing my technical opinion on this matter.

You proposed some steps to tackle a problem. I've shared my opinion and pinpointed why it is not technically feasible.

I've also offered to collaboratively figure it out, thoroughly test it, and bring forward a joint proposal for Warsaw to review and address it from specs. So that all partners in the network can implement it without adding more confusion.

I will send an email to QS technical team, Monday morning, to collaboratively discuss the issue, and investigate if we can jointly bring forward a wholesome technical proposal for other partners and Warsaw to review publicly in GitHub.

@kkaraogl you may say so. But in absence of any concrete example from your side, it will only point to limitation in Dashboard. Can you please point out what is wrong in the steps? I am repeating again .. this is not a proposal. This is a scenario that exists already.

from ewp-specs-api-iias.

@umesh-qs I already did pinpoint where the problem with the proposal lies, multiple times.

This issue persists in the production network, because there are some implementations that unilaterally disseminate this changing of IDs from their local implementations to their remote partners.

I will send an email to QS technical team, Monday morning, to collaboratively discuss the issue, show you where your proposal lacks, and investigate if we can jointly bring forward a wholesome technical proposal for other partners and Warsaw to review publicly in GitHub. Please do take up on the offer to collaboratively figure this out.

from ewp-specs-api-iias.

This issue persists in the production network, because there are some implementations that unilaterally disseminate this changing of IDs from their local implementations to their remote partners.

How much? 1, 10, 100?
If they are few, they have to review their implementation, not the others.
If they have problems, they have to represent them here, not to you.
Until now, I heard only "it's complex"; the complexity depends on the competence.
For a child may be complex 2x2; for a boy not.
Let's understand what kind of complexity we have, please invite the partners that find the actual solution "complex" to come here and explain their difficulties.
We all want to collaborate, but here.

from ewp-specs-api-iias.

Here is Umesh's scenario:

1. Partner A maps IIA of partner B which it received earlier
2. Partner A call IIA CNR API of partner B
3. Partner B call IIA GET API of partner A
4. Partner B maps the IIA based on the mapping in IIA GET of partner A
5. Partner B realized that partner A has mapped wrong IIAs
6. Partner B removes the mapping in their system and calls CNR of partner A
7. Partner A calls IIA GET API of partner B and sees no mapping
8. Partner A also unlinks the IIAs and wait for partner B to do the mapping.
9. Partner B maps a different IIA and calls IIA CNR of partner A
10. Partner A calls IIA GET of partner B and sees the new linking and does the same in their system.

Here is Janina's proposal:

The proposed approach is the following.
IIA-id is a key of the copy of the IIA (its primary key). A pair of (mapped) copies is identified by a pair of iia-ids. They should also be treated as the primary key. Different primary keys mean that we have different objects. If the system find out that the local IIA with some id A1 once mapped with id B1 now comes from the partner mapped with another id B2, it should treat this as an error. Identifiers are identifiers and should not be freely mapped and unmapped.

My thoughts:

What happens if partner A makes a mistake in point 1 and later realizes it and needs to change it? According to Janina's proposal, it would not be possible (partner B could find out that the mapping changed and would consider it to be an error). Partner A would therefore have just one chance to come up with a correct mapping and if s/he fails, s/he would face dire consequences: The obligation to rewrite the contents of its incorrectly mapped IIA with the other (correct) IIA and then probably discard the other IIA. I think this would create total havoc considering that there may already be mobilities attached to the IIA from previous academic years (2021/22 or 2022/23). If this interpretation of mine is correct, I am strongly against this proposal.

I think that we need to take into account that IROs can make a mistake and that both parties can almost simultaneously come up with different mapping and that neither party is automatically right because it was first to suggest a mapping. The truth is with the business level, and in case of conflict, it must be the business level at which a mutually acceptable mapping is found - that is, in some cases, IROs will have to contact each other by phone/e-mail and decide which IIA belongs to which IIA.
Once both partners have identical mapping in their systems and they have verified this, they can start approvals. At this point, the mapping should become immutable and any change by any partner should be treated as an error.

from ewp-specs-api-iias.

@jiripetrzelka please consider the following and please help towards closing it

1. Partner A & Partner B have successfully exchanged IDs that are binded: A1, B1.

Partner A: A1, B1
Partner B: B1, A1

2. Partner B changes its local ID to B2 and sends CNR

Partner A: A1, B1
Partner B: B2, the question is if A1 is still included in Partner's B IIA GET response

3. Partner A does IIA Get from Partner B

If B's GET response includes both B2 and A1, there might be a possibility that this could work, so let's look into this direction.
If B's GET response contains only B2, according to the specs (nothing to do with the Dashboard), this is a new IIA. Partner B, in the process of changing local ID, also left Partner A with the (A1,B1) copy, stuck in their system.

from ewp-specs-api-iias.

If the intention of partner B is to re-associate A1 to B2, partner A would GET IIA B2 and would find there the binding B2-A1.

In the other scenario you describe, B2 would not have anything to do with this pair of IIAs. Yes, Dashboard could consider it to be a new IIA. But it could also be that B2 would correspond to some other "orphaned" IIA in Dashboard and the IRO could locate it and bind it to B2 so that a duplicate creation is prevented. I don't know how much leeway Dashboard gives their users at this point but in our system the IRO could decide between the option to bind the B2 to an existing IIA or create a new IIA.

The question is rather what to do in case partner A GETs IIA B1 and the binding is missing. This corresponds to Umesh's points 6 and 7. How to interpret this? Partner B has probably realized B1 does not belong to A1 and neither has he found any other IIA of partner A that would correspond to B1. So it either does not exist or he didn't look properly at all potential matches of partner A for B1. So Partner A would then probably look too and realize that he should create a new IIA or would match it to some of his "orphaned" IIAs.

Back to the "workable" scenario you described: Partner A would see that partner B suggests that the correct mapping is B2-A1. Partner A has A1-B1. So partner A would change it to A1-B2. In our system, this would require an explicit action from the user because there already was a mapping and this is a non-standard scenario and the user should be aware of what is happening, at least in my opinion.

from ewp-specs-api-iias.

Partner B: B2, the question is if A1 is still included in Partner's B IIA GET response

3. Partner A does IIA Get from Partner B

If B's GET response includes both B2 and A1, there might be a possibility that this could work, so let's look into this direction.

This is a real mapping change

If B's GET response contains only B2, according to the specs (nothing to do with the Dashboard), this is a new IIA. Partner B, in the process of changing local ID, also left Partner A with the (A1,B1) copy, stuck in their system.

In this case B2 has nothing to do with the previous mapping, how can you say that B2 has replaced B1?
What we have to see is if B1 still exists and still have an A1 ID in its body.
If B1 no more exists, A should remove the association A1-B1.
If B1 has no partner's ID inside its body, A should contact B to be sure that he has to remove the association A1-B1.
If B1 has another A's ID inside (e.g. A2), A should unlink A1-B1 and if A accepts the new match, open A2 and join to B1

from ewp-specs-api-iias.

The real mapping changes, as @demilatof put it, must be thoroughly tested, then communicated/presented to the IF to all the partners, and then addressed by the specs, in my opinion.

There are a lot of partners, including Dashboard, that honor the binding of IIA IDs and do not allow this, as @janinamincer-daszkiewicz already shared in her proposal, treating them as primary keys. I still prefer Janina's proposal. There is not a use case I can identify for a local implementation to change its local ID, especially if they've previously shared another ID with their partner. Why not maintain the local ID, and change the data in the response, as a simple edit action?

Once Delete kicks-in in the network, the potential (A1, B1) stuck copy on Partner A, will organically resolve by itself, right?

The *manual matching/linking/unlinking of IIAs in the local system, changing local IDs, still looks to me like a feature of a local system, that once disseminated in the network, can cause problems to the other partner, unless everyone technically acknowledges it and deals with it efficiently.

*I've used more candid words about this local manual matching feature when we discussed with @jiripetrzelka in Thessaloniki, but I am not trying to impose my technical opinion on what other local systems do.

from ewp-specs-api-iias.

And after all said and done, we are still left with this edge case that both @jiripetrzelka and @demilatof described. Copying it from Jiri's response:

The question is rather what to do in case partner A GETs IIA B1 and the binding is missing. This corresponds to Umesh's points 6 and 7. How to interpret this? Partner B has probably realized B1 does not belong to A1 and neither has he found any other IIA of partner A that would correspond to B1. So it either does not exist or he didn't look properly at all potential matches of partner A for B1. So Partner A would then probably look too and realize that he should create a new IIA or would match it to some of his "orphaned" IIAs.

from ewp-specs-api-iias.

The real mapping changes, as @demilatof put it, must be thoroughly tested, then communicated/presented to the IF to all the partners, and then addressed by the specs, in my opinion.

I think that it is not necessary; the specifications don't forbid the mapping changes, as they don't forbid a change in a cooperation condition.
Or should we come back and require a discussion for everything during the IF?
The explanation of the EWP mobility process says: "Each partner uses his own ID for the IIA, so partners will need to manually "bind" their local agreements with their remote counterparts"

If some implementer is doing this automatically and now he has problems to manage particular cases, the problem is in his approach that don't follow the above sentence.

There are a lot of partners, including Dashboard, that honor the binding of IIA IDs and do not allow this,

As I already said, these partners should participate in this discussion on GitHub; I hope you'll be so kind to invite them to explain here their problem.
"A lot of" doesn't tell me anything: 1, 10 or 100?
Until now, we can suppose that only Dashboard has this problem; we are waiting for other partners coming out.

Why not maintain the local ID, and change the data in the response, as a simple edit action?

Because an ID identifies an IIA and not other data, not only on EWP but even in local system where most of the partners have other software.
From "Important Rules": Partners should exchange identifiers of their copies of the IIA to match these copies respectively in their systems.
Not two generic identifiers that later the partners can fill in some information, but the identifier of a given IIA (and not another one).
@janinamincer-daszkiewicz also said: "Identifier is the unique identifier of the object and should never be reused to identify a different object."

Once Delete kicks-in in the network, the potential (A1, B1) stuck copy on Partner A, will organically resolve by itself, right?

You have to delete nothing; it's probably a problem of your implementation.
There is no (A1, B1), there is an A1 that doesn't need to be joined to B1. You remove B1 from it, and then you could associate A1 to another B's IIA or delete, if you want.

The *manual matching/linking/unlinking of IIAs in the local system, changing local IDs, still looks to me like a feature of a local system, that once disseminated in the network, can cause problems to the other partner, unless everyone technically acknowledges it and deals with it efficiently.

I think you are wrong: as I've reminded you just above, the manual bind is strongly suggested as a well known need.

*I've used more candid words about this manual matching feature when we discussed with @jiripetrzelka in Thessaloniki, but I am not trying to impose my technical opinion on what other local systems do.

We are not imposing our technical opinion on what your local system does, but if your system has problems because it doesn't consider all the technical requirement (e.g. manual mapping), we cannot take in consideration to modify and complicate our systems to help you.

from ewp-specs-api-iias.

The question is rather what to do in case partner A GETs IIA B1 and the binding is missing.

This happens almost always: I (partner A) have my list of IIAs, you (partner B) have your list of IIAs.
The first time I fetch your B1 most probably it has no binding and I have to do.
What is the difference with the problem you've described?
If I can bind B1 with something, I do it.
Otherwise, I know there is a B1 that I can ignore.

from ewp-specs-api-iias.

@jiripetrzelka please consider the following and please help towards closing it

1. Partner A & Partner B have successfully exchanged IDs that are binded: A1, B1.

Partner A: A1, B1 Partner B: B1, A1

2. Partner B changes its local ID to B2 and sends CNR

Partner A: A1, B1 Partner B: B2, the question is if A1 is still included in Partner's B IIA GET response

3. Partner A does IIA Get from Partner B

If B's GET response includes both B2 and A1, there might be a possibility that this could work, so let's look into this direction. If B's GET response contains only B2, according to the specs (nothing to do with the Dashboard), this is a new IIA. Partner B, in the process of changing local ID, also left Partner A with the (A1,B1) copy, stuck in their system.

@kkaraogl please do not mislead on according to the specs. What specs say that individual system might treat it as duplicate. So it is up-to your implementation. No problem for our system. Also I strongly believe this statement in the specs is added in favor of Dashboard alone.

from ewp-specs-api-iias.

Also I strongly believe this statement in the specs is added in favor of Dashboard alone.

Umesh, please, do not make such statements which are not true. Never ever anything in the specification has been crafted with the Dashboard in mind. Nor any other system. You should remember that as you were partner in EWP 2.0.

from ewp-specs-api-iias.

Also I strongly believe this statement in the specs is added in favor of Dashboard alone.

Umesh, please, do not make such statements which are not true. Never ever anything in the specification has been crafted with the Dashboard in mind. Nor any other system. You should remember that as you were partner in EWP 2.0.

I am ready to take it back. Please share just a couple of providers who were facing this duplicate issue at the time this statement was added.
Yes we were partner in EWP 2.0. But that does not mean that we were ok with everything that was done

from ewp-specs-api-iias.

@umesh-qs specs are pretty clear about what I wrote above:

If we start debating step 0, I won't be able to contribute in the discussion.

We are still left with this edge case that both @jiripetrzelka and @demilatof described. Copying it from Jiri's response:

The question is rather what to do in case partner A GETs IIA B1 and the binding is missing. This corresponds to Umesh's points 6 and 7. How to interpret this? Partner B has probably realized B1 does not belong to A1 and neither has he found any other IIA of partner A that would correspond to B1. So it either does not exist or he didn't look properly at all potential matches of partner A for B1. So Partner A would then probably look too and realize that he should create a new IIA or would match it to some of his "orphaned" IIAs.

Could you contribute on how you are currently dealing with it or how you suggest that the other partners should interpret it and act upon it?

from ewp-specs-api-iias.

From the position of partner A you show B1 to the user and let him decide to either import it as a new local IIA (ID will be automatically created and assigned to B1) or let them link B1 to an existing IIA from the list of "orphaned" local IIAs in A's system. Ideally, user's attention should first be brought to the list of best potential matches and only if the match is not found should he be offered the option to import the IIA and create a new IIA. In our system, the system lists potentially matching IIAs in such an order that the most probable matches are on top of the list (i.e. IIAs with the same ISCED).

from ewp-specs-api-iias.

@umesh-qs specs are pretty clear about what I wrote above:

ewp-specs-api-iias/endpoints/get-response.xsd

Line 99 in 83a208e

<xs:element name="iia-id" type="ewp:AsciiPrintableIdentifier" minOccurs="0" maxOccurs="1">

If we start debating step 0, I won't be able to contribute in the discussion.

We are still left with this edge case that both @jiripetrzelka and @demilatof described. Copying it from Jiri's response:

The question is rather what to do in case partner A GETs IIA B1 and the binding is missing. This corresponds to Umesh's points 6 and 7. How to interpret this? Partner B has probably realized B1 does not belong to A1 and neither has he found any other IIA of partner A that would correspond to B1. So it either does not exist or he didn't look properly at all potential matches of partner A for B1. So Partner A would then probably look too and realize that he should create a new IIA or would match it to some of his "orphaned" IIAs.

Could you contribute on how you are currently dealing with it or how you suggest that the other partners should interpret it and act upon it?

@kkaraogl I am not starting from 0. I am only countering what you said "If B's GET response contains only B2, according to the specs (nothing to do with the Dashboard), this is a new IIA". I cannot help if you don't like it the counter arguments.
As I said your statement is not entirely true. It depends on how individual systems handle it. And I guess only Dashboard creates automatic IIA internally which creates duplicates.

from ewp-specs-api-iias.

I'll agree with @skishk that what we are discussing is a matter of the local implementations to handle it.

I would still argue that it should be communicated to all the other partners, so that they are aware. Nothing further to contribute in this discussion.

from ewp-specs-api-iias.

DG EAC suggests to vote on this issue. Help me in preparing the questions for the voting. The first draft proposal.

Wrongly mapped IIAs
GitHub issue: https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/101  
Let’s assume that partner A maps IIA received from partner B with their local copy A1 
and shares this mapping with B. After some time it changes the mapping to A2 
and again shares this mapping with B. 
Should specification allow A to change the mapping?

1. Yes – users can freely map and unmap copies of IIAs.
2. No – after sharing the mapping with the partner the user can not change it.

In case 2 how should B behave?

1. Treat such change in the mapping as an error.
2. Allow the local user to update the mapping.

from ewp-specs-api-iias.

My two cents...

The voting will be for wrong mapping not mutual approved IIAs or even for mutual approved IIAs?
I think it could be specified to avoid misunderstandings.

I understand and agree with the question; I understand less the two possible solutions...

In case 2 how should B behave?

1. Treat such change in the mapping as an error.

What does it mean treat such change in the mapping as an error?
Or, to be more clear, once we decide to treat such change in the mapping as an error, what can we do to remove the error?

2. Allow the local user to update the mapping.

How can the local user update the mapping if this possibility is the consequence of "after sharing the mapping with the partner the user can not change it"?

from ewp-specs-api-iias.

Only for not mutually approved IIAs.
Please give your proposal for the questions.

from ewp-specs-api-iias.

Please give your proposal for the questions.

I am in trouble in finding any proposal, since I would like better the first solution (free mapping and unmapping).
Therefore, if the partners vote for the second option, I hope in the less invasive consequence (even if ugly).
My proposal, in this case, is:

A) The wrong mapping A1-B1 makes void IIA IDs A1 and B1, therefore they cannot be used anymore in EWP and should be considered as deleted (as a matter of fact, what happens if I delete an IIA that I've already mapped? We have not discussed about this possibility, or perhaps we said that we can delete it anyway).

The consequence should be managed at local level, if the partner needs to reuse the same IIA; e.g. one partner could:

• Make a copy if its own IIA and give it a new IIA Id.
• Change the IIA ID of the object with a completely new one IIA ID
• Change the IIA ID simply by adding a suffix (A1 -> A1v2, in case of a second error A1v3, then A1v4 and so on)

from ewp-specs-api-iias.

Should specification allow A to change the mapping?

1. Yes – users can freely map and unmap copies of IIAs.

Agree with point 1; the mapping of an IIA with the corrisponding partner IIA is an attribute and - in my opinion - an un-map and a re-map should be managed as a change.

from ewp-specs-api-iias.

DG EAC suggests to vote on this issue. Help me in preparing the questions for the voting. The first draft proposal.

Wrongly mapped IIAs
GitHub issue: https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/101  
Let’s assume that partner A maps IIA received from partner B with their local copy A1 
and shares this mapping with B. After some time it changes the mapping to A2 
and again shares this mapping with B. 
Should specification allow A to change the mapping?

1. Yes – users can freely map and unmap copies of IIAs.
2. No – after sharing the mapping with the partner the user can not change it.

In case 2 how should B behave?

1. Treat such change in the mapping as an error.
2. Allow the local user to update the mapping.

@janinamincer-daszkiewicz if in option 2 you are allowing "Allow the local user to update the mapping", then how is it different from option 1?

from ewp-specs-api-iias.

@umesh-qs Please give your proposal for the questions..

from ewp-specs-api-iias.

Wrongly mapped IIAs
GitHub issue: #101
Let’s assume that partner A maps IIA received from partner B with their local copy A1
and shares this mapping with B. After some time it changes the mapping to A2
and again shares this mapping with B.
Should specification allow A to change the mapping?

1. Yes – users can freely map and unmap copies of IIAs. This should be treated like any other change.
2. No – after sharing the mapping with the partner the user cannot change it. Treat such change in the mapping as an error and not accept the IIA.

from ewp-specs-api-iias.

2. Treat such change in the mapping as an error and not accept the IIA.

And then? What do you mean with "not accept the IIA"? How do we have to manage those IIA-IDs?
If they are lost, what are the lost IIA-IDs? A1, B1 and even A2?

@janinamincer-daszkiewicz
At some point we have A1-B1, the old mapping, and A2-B1, the new attempting.
A1-B1 is wrong by the wills of the A partner, A2 is good but used with B1 (already used with A1).

What have we to discard for ever? A2 remains good and B partner has to replicate B1 in B2, and then we can have A2-B2?
That is, for the mistake of A, B has to go into trouble to duplicate and to discard B1?

from ewp-specs-api-iias.

2. Treat such change in the mapping as an error and not accept the IIA.

And then? What do you mean with "not accept the IIA"? How do we have to manage those IIA-IDs? If they are lost, what are the lost IIA-IDs? A1, B1 and even A2?

@demilatof then is it a special case, to be handled via email. Like many such cases that is handled outside the system. Partner causing this error should correct it. I do not see any problem here.

@janinamincer-daszkiewicz At some point we have A1-B1, the old mapping, and A2-B1, the new attempting. A1-B1 is wrong by the wills of the A partner, A2 is good but used with B1 (already used with A1).

What have we to discard for ever? A2 remains good and B partner has to replicate B1 in B2, and then we can have A2-B2? That is, for the mistake of A, B has to go into trouble to duplicate and to discard B1?

from ewp-specs-api-iias.