In order to properly "verify" mobilities against IIA's conditions, we will need some kind of mapping between the mobility and the academic year. Let's call such academic year a "connected" one (we will probably need a better term before we introduce this).
Previously I was thinking that this mapping could be extrapolated from <planned-arrival-date> and <planned-departure-date> , but this doesn't seem to be the case. Some mobilities begin or end in different academic years than those with which they are "connected". So, it would seem that we need an extra element for that.
Note, that we are also planning to make <planned-arrival-date> and <planned-departure-date> optional. So, this new element would be the only temporal property of newly created nominations.
In order to properly "verify" mobilities against IIA's conditions, we will need some kind of mapping between the mobility and the academic year. Let's call such academic year a "connected" one (we will probably need a better term before we introduce this).
Previously I was thinking that this mapping could be extrapolated from
<planned-arrival-date>
and<planned-departure-date>
, but this doesn't seem to be the case. Some mobilities begin or end in different academic years than those with which they are "connected". So, it would seem that we need an extra element for that.I'm not yet sure, if the type of this extra element should be
AcademicYearId
or<academic-term>
?Note, that we are also planning to make
<planned-arrival-date>
and<planned-departure-date>
optional. So, this new element would be the only temporal property of newly created nominations.