Consecutive academic years or not?

sascoms commented 2 years ago

The question is: The academic years in the conditions must be consecutive? Or not?

We have received such academic years in different conditions: Condition 1: 2021-2022 (one academic year. ok) Condition 2: 2021-2022 | 2022-2023 (consecutive. ok) Condition 3: 2021-2022 | 2023-2024 (not consecutive. 22-23 is missing here) Condition 4: 2021-2022 | 2022-2023 | 2023-2024 | 2025-2026 (not consecutive. 24-25 is missing)

How shall these academic years be interpreted?

The non-consecutive years are acceptable?

And is there a principle or rule about the consecutiveness of the academic years?

Any ideas? Or a reference to an explanation or discussion about this issue?

umesh-qs commented 2 years ago

Only reason I suppose it was done it to provide some sort of flexibility. There are already issues raised for this. Again it is left to individual service provider to deal with. Some sort of standardization is needed. Atleast they should be in sequence.

https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/28 https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/12

sascoms commented 2 years ago

@umesh-qs Thanks Umesh. I will check those issues.

We are also in favor of it to be in sequence and with no gaps.

We propose the documentation to be changed so there is no flexibility regarding the academic years list.

jiripetrzelka commented 2 years ago

I have consulted this with IRO staff at Masaryk University who deals with IIAs and she told me that gap years are never put in the original IIA but they may occur later when the agreement is amended. For example, the original IIA may be signed for 2021/22-2022/23 for SMS, then just left in the system and later, say in 2024 someone may have interest in the mobility so the IIA is "renewed" with an amendment and could be signed for example for 2024/25-2027/28. And this amendment may be for SMS but also for another type of mobility, such as STA. So I'm in favor of keeping the gap years possible and also for the option that different mobility specifications can have different sets of academic years.

kamil-olszewski-uw commented 2 years ago

If the system of some university does not allow gaps, the user may simply refuse to sign IIA with gaps. It is not controversial, because agreements with gaps are so exotic that they do not need to be supported in the system. All the system should be able to do is show academic years with gaps when displaying the IIA retrieved from the partner.

umesh-qs commented 2 years ago

@kamil-olszewski-uw So what you are saying that universities will use the same agreement (IIA ID) years later and just add a new academic year? Or is it something else that I have missed.

kamil-olszewski-uw commented 2 years ago

All I'm saying is that gaps shouldn't be a technical problem (regardless of the purpose for which the partner would like to use them) because for technical or business reasons we may not agree to them.

umesh-qs commented 2 years ago

Yes it is a problem. We are leaving it to individual interpretation which has been a problem with IIA API specifically. Some system might create multiple agreements for different academic year range, some might just take the last years in sequence.

And as you already said that "agreements with gaps are so exotic that they do not need to be supported in the system", why not make it mandatory to be in sequence or have start and end academic year instead.

sascoms commented 2 years ago

why not make it mandatory to be in sequence or have start and end academic year instead.

We still support this idea as in our first comments.

Academic years should not have any gaps. Or a start and end academic year would also work for fixing this issue.

@kamil-olszewski-uw It definitely brings technical problems. Providers need to put some logic and controls to find out if the academic years have gaps or not. And if you leave it to the end user, they are human. They may miss this control. And why should they need to control every condition if it has gaps or not? And let's say they found some gaps: this time user needs to update the iia and send it back to the partner (more exchange more steps) and maybe email communication! Why putting extra work and time both for development and end users?

Putting a standard and disallowing the gaps would eliminate all these problems.

@jiripetrzelka To clarify the issue, we mention gaps in the academic years of "a" condition. Each condition under an iia already has its own academic years. And having different academic years in different conditions is already supported.

Regarding your example case, I would go with a new iia instead of extending an existing iia in your case.

georgschermann commented 2 years ago

initial thought about gaps in the years was to allow for different conditions for a single year, like a general condition for 2021-2028, but in 2023/24 you can send an additional 2 students -> 2nd coop condition only for this year. if consecutive years would be mandatory this would result in 3 conditions instead of 2. not sure if this is currently used this way in practice

janinamincer-daszkiewicz commented 2 years ago

Let me know if:

we can assume that there is no real, urgent need to change the specification this way or the other and we can close this issue, or
there is still real, urgent need to change the specification this way or the other and we should schedule one of the future Infrastructure Forum meetings to discuss the topic and come to some commonly agreed conclusion.

umesh-qs commented 2 years ago

@janinamincer-daszkiewicz I would like to ask other way round. What is the problem doing it now?

janinamincer-daszkiewicz commented 2 years ago

Doing what now?

umesh-qs commented 2 years ago

Making changes to the specification.

janinamincer-daszkiewicz commented 2 years ago

Because I do not see here one version which would be accepted by all taking part in the discussion.

umesh-qs commented 2 years ago

Ok. I do not see any one against it. How did you arrive at this conclusion?

sascoms commented 2 years ago

@janinamincer-daszkiewicz

I do not see any reason not to add this change to the first new version of IIAs.

And if you would like to discuss it in the next meetings, that is fine, too.

lioliosn commented 2 years ago

The consecutiveness of academic years derives from the IIA template where there is only start and end year, with no field to indicate that there is an interruption period. None of our 1600 IIAs with 600 partner universities had any provision for gaps so far, so I think that consecutive years is the default for the majority of HEIs.

muratyuceer commented 2 years ago

We also think that years should only be consecutive.

jiripetrzelka commented 2 years ago

If I understand it correctly, the benefits of the proposed changes are:

To ensure IIAs as such (after all cooperation conditions are merged) contain gaps only if end users really want it (not by mistake).
To ensure that in these exotic cases the partner's copy does not have 2 cooperation conditions (e.g. 2021/22-2023/24 and 2025/26-2028/29) when my copy has only 1 cooperation condition with the same years and a gap (e.g. 2021/22-2023/24 and 2025/26-2028/29). So we will both we forced to have 2 cooperation conditions.

I think this proposal makes sense because it brings more clarity on the business level, while not reducing the current expression power of the allowed combinations of academic years at the IIA level as such.

janinamincer-daszkiewicz commented 2 years ago

On the Infrastructure Forum 2022-04-06 many providers supported this change. Currently this element is specified as: <xs:element name="receiving-academic-year-id" type="trm:AcademicYearId" minOccurs="1" maxOccurs="unbounded">

Example:

<receiving-academic-year-id>2016/2017</receiving-academic-year-id>
<receiving-academic-year-id>2017/2018</receiving-academic-year-id>
<receiving-academic-year-id>2018/2019</receiving-academic-year-id>
<receiving-academic-year-id>2019/2020</receiving-academic-year-id>
<receiving-academic-year-id>2020/2021</receiving-academic-year-id>

We have two options:

Leave the definiton of the element as it is now, add in the description part of the specification extra requirements imposed on the sequence of the academic years.

Change the definition to something like:

<receiving-academic-year-start-id>2014/2015</receiving-academic-year-start-id>
<receiving-academic-year-end-id>2015/2016</receiving-academic-year-end-id>

Many developers already avoid gaps and keep the proper order of he academic years, they will have no extra work in option 1. However it is more difficult to validate correctness. Option 2 leaves no doubts but everybody would have to make changes.

Which one do you prefer?

umesh-qs commented 2 years ago

Option 1 is preferred initially. In our system we will reject the IIAs where academic year is not in sequence.

Once we have other breaking changes that change the hash, we would like to include option 2 along with those changes.

janinamincer-daszkiewicz commented 2 years ago

Message from the Business Process Owners (BPOs):

BPOs were quite clear about this issue. This should not be allowed for the initial agreement. The use case is very rare so if needed, HEI can create two agreements with consecutive academic years. What would be useful is that approved agreement can be paused/cooperation conditions renegotiated (mostly regarding #of students and #of months) + re-approved for a given academic year(s) in the course of the duration of the agreement (will be part of the business requirements).

janinamincer-daszkiewicz commented 2 years ago

Decision made at Infrastructue Forum on 2022-04-20:

First option will be implemented now
Second option is postponed until 2023.

janinamincer-daszkiewicz commented 2 years ago

Current description available at: https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/b8aed419061eba1b86c57389299841114bf500b1/endpoints/get-response.xsd#L385 will change to:

A list of academic years for which this mobility specification is required to be in effect during a given programme period (each mobility specification can be bound to a different set of academic years).

It must be a list of unique IDs in chronological order, where gaps are not allowed (in case of a gap separate agreements with consecutive academic years could be signed). For example: the list "2021/2022, 2022/2023, 2023/2024" is correct, but the lists "2021/2022, 2023/2024" and "2021/2022, 2023/2024, 2022/2023" are not allowed.

If one of the partners is from the southern hemisphere (so that partner uses academic years in a form of "2021/2021" instead of "2021/2022"), then IDs provided here should refer to the scheme used by the receiving partner (not the sending one).

janinamincer-daszkiewicz commented 1 year ago

Some changes in the IIA and IIA Approval APIs will take place by the end of 2022. It makes sense to group them to make the change in the major number of the APIs once.

During the Infrastructure Forum meeting on 2022-11-16 the providers will vote if we want to introduce the option 2 from https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/70#issuecomment-1093832175.

janinamincer-daszkiewicz commented 1 year ago

Voting took place during the Infrastructure Forum meeting on 2022-11-16. According to chat: 17 providers voted YES, nobody voted NO.

This change will be implemented under the condition that the others, more important ones, will be implemented.

umesh-qs commented 1 year ago

There was an open question on how to handle existing IIA structure.

janinamincer-daszkiewicz commented 1 year ago

@umesh-qs

There was an open question on how to handle existing IIA structure.

Yes, I remember, we will come back to it before finalizing the specification.

janinamincer-daszkiewicz commented 1 year ago

There was an open question on how to handle existing IIA structure.

Will the proposal on handling IIA amendments work also for change in academic years? As in case of amendments, server implementers would be required to keep all logs (snapshots) and therefore be able to find the original partner IIA before the change in format of academic years .

In the local system we either still keep the list or replace it with the pair of begin/end dates.

In the network we share the pair of begin/end dates (under the new version).

umesh-qs commented 1 year ago

@janinamincer-daszkiewicz -- hash gets changed once the change is implemented. And as soon as we pull any data from partner system approval gets reset on hash change. How do we handle this scenario is not clear to me yet.

janinamincer-daszkiewicz commented 1 year ago

And as soon as we pull any data from partner system approval gets reset on hash change.

I guess this is you local implementation. It need not be like that.

umesh-qs commented 1 year ago

I don't think this is a issue of local implementation. We are just going by the specs. What alternative does EWP Consortia suggests for this?

janinamincer-daszkiewicz commented 1 year ago