search

erasmus-without-paper / ewp-specs-api-omobilities

Specifications of EWP's Outgoing Mobilities API.
MIT License
1 stars 4 forks source link

Sending academic term start and end #37

Closed umesh-qs closed 1 year ago

umesh-qs commented 5 years ago

In API, sending-academic-term-ewp-id can only be defined for one term. What if the mobility is for more then one term? We should have 'sender start academic term' and 'sender end academic term' instead of single entry 'ending-academic-term-ewp-id'

MartaJuzepczuk commented 5 years ago

Academic term id can be a whole year too. If the mobility period cannot be expressed in this way, one can use non-standard-mobility-period element.

umesh-qs commented 5 years ago

But this is not a non-standard mobility period. Most of the systems I believe should have start and end mobility period. And this can be easily accommodated using start and end academic term.

I am not sure if I have understood your point. But if the mobility is for a full year and in your system you have defined 2 terms for a year then wouldn't it make sense to pass something like below in the API sending-start-academic-term-ewp-id 2009/2010-1/2 sending-end-academic-term-ewp-id 2009/2010-2/2

MartaJuzepczuk commented 5 years ago

But this is not a non-standard mobility period.

Can you give me an example? It would be easier to talk. I thought that only semester and year are standard periods.

Most of the systems I believe should have start and end mobility period. And this can be easily accommodated using start and end academic term.

I think so too. But we already have start and end dates in the API.

I am not sure if I have understood your point. But if the mobility is for a full year and in your system you have defined 2 terms for a year then wouldn't it make sense to pass something like below in the API sending-start-academic-term-ewp-id 2009/2010-1/2 sending-end-academic-term-ewp-id 2009/2010-2/2

Yes, it would make sense. We thought about sending 2009/2010-1/1 in this situation.

umesh-qs commented 5 years ago

  1. Having 2 terms in a year is a standard, I was referring to. For that we should be passing as below sending-start-academic-term-ewp-id 2009/2010-1/2 sending-end-academic-term-ewp-id 2009/2010-2/2

  2. Start and end dates are for a different purpose. Also these are not mandatory

  3. Having from and to academic term can cover lot more scenarios. For example a year having 4 terms and mobility is only for 2 terms. In that case we can pass sending-start-academic-term-ewp-id 2009/2010-2/4 sending-end-academic-term-ewp-id 2009/2010-3/4

In your case passing 2009/2010-1/1 does not tell me that sender academic year is divided into 2 semesters.

MartaJuzepczuk commented 5 years ago

Your comments sound reasonable. We'll think about it.

Having from and to academic term can cover lot more scenarios.

Sure. We introduces "non standard mobility period" flag as simple solution for those situations, which are not standard and which (as we thought) happen rarely. With your solution we could be more precise here.

In your case passing 2009/2010-1/1 does not tell me that sender academic year is divided into 2 semesters.

It doesn't. But do we need this information here?

janinamincer-daszkiewicz commented 3 years ago

If anybody still interested in changing sending-academic-term-ewp-id? If no, we will close this issue. If yes, we will discussed it at the technical workshop.

umesh-qs commented 3 years ago

Yes, if the below scenario cannot be handled with current specs.

If the academic year is divided into 3 parts (trimester). And the mobility is between 1st and 2nd part, how will it be represented with current specifications.

janinamincer-daszkiewicz commented 3 years ago

2020/2021 1/1 I guess. This is the best approximation. Good enough at this time. It looks that other developers can live with that.