Query on structure of student-studies-mobility-spec

[umesh-qs]

Following is the definition of "student-studies-mobility-spec"
<xs:element ref="student-studies-mobility-spec" minOccurs="0" maxOccurs="unbounded">

It means that it can be repeated. In case it is repeated can someone tell me how can I identify the unique key. Is combination of sending-hei-id,receiving-academic-year-id unique?

[MartaJuzepczuk]

This combination is not necessarily unique. Do you need a unique key for cooperation condition?

[umesh-qs]

At-least some combination should be unique. If not then how do I automate the updates?

[MartaJuzepczuk]

We are planning some changes in this API in near future. We will think about this.

[kamil-olszewski-uw]

We considered whether the cooperation conditions identifiers would be useful in the context of counting the hash needed to approve agreements. However, we felt that this would complicate the process.

As there is no apparent support for this postulate from other partners, we will allow ourselves to close this thread.

[umesh-qs]

@kamil-olszewski-uw
If there is not a unique identifier for the cooperation condition, then how can we tie mobility to a cooperation condition?

[umesh-qs]

@kamil-olszewski-uw
You might ask what is the need for linking cooperation condition with student mobility. This is needed to calculate the remaining months/days from the cooperation condition, so that number of mobility month doesn't exceed what is there in the cooperation condition.
I am not sure if we are the only ones with this use case. Requesting feedback from other service provider.

[kamil-olszewski-uw]

If more people ask for these identifiers, we will try to come back to the topic and possibly implement the identifiers in some future version of the API.

So far, Outgoing Mobilities API does not indicate specific cooperation conditions, just as there was no indication of them when sending nominations on paper or by e-mail. It was up to the user to ensure that the limits were not exceeded.

Adding id of cooperation condidtions to the nominations sent by the Outgoing Mobilities API would indeed have its advantages, but it would involve implementation problems. First, such a change would be incompatible backwards (also in terms of hash computation). Secondly (and more importantly) - agreements have different ids in the systems of both partners and in the same way we would have to specify the ids of cooperation conditions (we would multiply the already existing tiresome necessity, which is a consequence of the fact that agreements are not sent in the master-slave mode).

[milsorm]

As IS4U provider we are also asking for unique identification of cooperation condition as we stated in #105.