Re-introduce the maxOccurs unbounded for sending-ounit-id and receiving-ounit-id

[jiripetrzelka]

SUMMARY (our proposed changes to IIAs API based on our discussion):

1. We will remove sending-contact and receiving-contact from the calculation of the hash.

2. We will NOT remove sending-ounit-id and receiving-ounit-id from the calculation of the hash.

3. We will change maxOccurs of sending-ounit-id and receiving-ounit-id from unbounded to 1.

4. We will NOT change max Occurs of student-studies-mobility-spec, student-traineeship-mobility-spec, staff-teacher-mobility-spec and staff-training-mobility-spec from unbounded to 1.

5. We will NOT force a specific number of digits in the isced-f-code, but in the commentary to this element we will strongly recommend that the ISCED code should be four-digit, because this way it will be compliant with the requirements of Mobility Tool+ apllication, which only accepts four-digit codes for mobilities (see issue: #49).

Originally posted by @kamil-olszewski-uw in https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/48#issuecomment-797501411

[janinamincer-daszkiewicz]

Opinion of DG EAC Regarding changing back the maxOccurs unbounded for sending-ounit-id and receiving-ounit-id – this change was not requested by EAC nor BPOs. It seems to us that it might introduce some level of complexity that is best to avoid and also, we have surveyed already the IF on the scope of changes so we should avoid as much as possible to add any further changes to the major release.

[demilatof]

Opinion of DG EAC Regarding changing back the maxOccurs unbounded for sending-ounit-id and receiving-ounit-id – this change was not requested by EAC nor BPOs. It seems to us that it might introduce some level of complexity that is best to avoid and also, we have surveyed already the IF on the scope of changes so we should avoid as much as possible to add any further changes to the major release.

Thanks for sharing their answer; I agree with them but I think that this issue could remain still open because some providers have this problem anyway, and they could desire to find a solution compatible with DG EAC response. In my opinion, they have only 2 solutions:

1. My proposal, "bad by design", of using divisions to organize their set of ounits, as specifications already allow
2. Accepting of being less generic avoiding to specify a list of ounits for a mobility, but splitting the mobilities, declaring how many place per each one (and not as a whole offer)

[jiripetrzelka]

Opinion of DG EAC Regarding changing back the maxOccurs unbounded for sending-ounit-id and receiving-ounit-id – this change was not requested by EAC nor BPOs.

It is, however, clear from the start of this thread that some "users are asking for this" because it reflects the reality at some universities. The argument that BPOs have not requested it should not stand in the way of actually asking BPOs at the next meeting what they think about it. As I understand it, it is not strictly necessary that all ideas discussed by BPOs must have originated from them.

It seems to us that it might introduce some level of complexity that is best to avoid and also, we have surveyed already the IF on the scope of changes so we should avoid as much as possible to add any further changes to the major release.

Since there will most probably be another survey in June, there is no need to base the decision on what "it seems to you" but you can actually ask providers and support your hypothesis by the standard mechanism of democratic voting instead of imposing a top-bottom approach based on the preference of several providers that have contributed to this thread.

[janinamincer-daszkiewicz]

Jiri, please write this to the providers mailing list to get attention of DG EAC.

[umesh-qs]

Jiri, please write this to the providers mailing list to get attention of DG EAC.

Really. I thought DG EAC is monitoring an going through the comments.

[jiripetrzelka]

Jiri, please write this to the providers mailing list to get attention of DG EAC.

Have DG EAC representatives actually subscribed to the ewp-providers mailing list? When you sent us the last e-mail with invitation for IF, all DG EAC contacts were in CC.

[jiripetrzelka]

I have drawn my arguments to the attention of DG EAC by e-mailing Harpa and received a confirmation that it will be shared with the person(s) who made the decision to discard the issue.

[umesh-qs]

I have drawn my arguments to the attention of DG EAC by e-mailing Harpa and received a confirmation that it will be shared with the person(s) who made the decision to discard the issue.

Any idea who are the person(s) who made the decision. Wanting to know it from a long time. There is no list. For transparency everyone should know who all are part of decision making.

[demilatof]

I can say that our IROs don't like too much the possibility of having to to with more sending/receiving ounits, because can hide realities too complex to manage. The actual solution is better, they can know how many students come from or go to a ounit, and not from or to a mix of ounits. When a student comes to us, we don't bother if he/she comes from an ounit or another. When we send a student, we consider the ISCED-F more than the ounit. I see this issue as an internal matter.

Anyway, if you and your partner are interested in using more ounits, e.g. we can say 3 each one, you have potentially 9 combinations of exchange with unknown number of places for each combination. Good luck!

[jiripetrzelka]

Any idea who are the person(s) who made the decision. Wanting to know it from a long time. There is no list. For transparency everyone should know who all are part of decision making.

No specific name was given by Harpa but my guess is that it will be the people who were in CC in the invitation to the IF.

I can say that our IROs don't like too much the possibility of having to to with more sending/receiving ounits, because can hide realities too complex to manage. The actual solution is better, they can know how many students come from or go to a ounit, and not from or to a mix of ounits.

I do agree that it is much better and it will probably be the prevailing case. But I also know that some departments at our university do share the limits. I do not question why they do it or whether they should stop doing it. I just think that EWP should provide a specification that reflects the full reality and not just a convenient subset of it.

[demilatof]

I do agree that it is much better and it will probably be the prevailing case. But I also know that some departments at our university do share the limits. I do not question why they do it or whether they should stop doing it. I just think that EWP should provide a specification that reflects the full reality and not just a convenient subset of it.

Even if Janina don't like the idea, have you thought to use "division" as a set of ounits, where you can list more ounits in the name and use this new ounit as a sending/receiving unit? If you haven't used yet the field parent ounit id, you can even create a structure of ounits

[jiripetrzelka]

Even if Janina don't like the idea, have you thought to use "division" as a set of ounits, where you can list more ounits in the name and use this new ounit as a sending/receiving unit? If you haven't used yet the field parent ounit id, you can even create a structure of ounits

I don't like the idea. We have a tree organisational structure and each unit can have just one parent. Your proposal would require multiple parents and the actual organisational structure would be obfuscated.

[demilatof]

Even if Janina don't like the idea, have you thought to use "division" as a set of ounits, where you can list more ounits in the name and use this new ounit as a sending/receiving unit? If you haven't used yet the field parent ounit id, you can even create a structure of ounits

I don't like the idea. We have a tree organisational structure and each unit can have just one parent. Your proposal would require multiple parents and the actual organisational structure would be obfuscated.

And using "other-info-terms"?

Optional field for any other information regarding the terms of the agreement.

[jiripetrzelka]

And using "other-info-terms"?

That's the suboptimal option I will use in case this proposal will indeed be rejected.