total-months-per-year / total-days-per-year decimal qustion

[sascoms]

<xs:element name="total-months-per-year" minOccurs="1" maxOccurs="1">
<xs:element name="total-days-per-year" minOccurs="1" maxOccurs="1">

ewp-specs-api-iias/endpoints/get-response.xsd

Line 516 in 48437c5

<xs:restriction base="xs:decimal">

The total months per year and the total days per year elements are defined as decimal numbers in the specs.

We need some clarification on these definitions:

• What does it mean if the "total months" is given as 7.33? How shall this be interpreted by the HEI?

• Is it possible to give 15.80 as total days? And if yes, what does it mean? How shall this be interpreted by the HEI?

• What is the point and intention in having this information in decimal number format?

Having made many many IIA tests meetings (provider-to-provider, HEI to HEI, provider to HEI, and vice versa), we have seen only one provider requires and sends decimal number. And the rest uses integers.

Also, I think that this is just another point that causes the hash calculation differences between software.

We will be happy if somebody can clarify this issue for us?

[kamil-olszewski-uw]

I asked our Polish universities if they actually use fractions for total months and total days.

And they always use total days as integers. However, total months can be decimal for traineeship. In this case, the fraction value can be converted into days using the official EU algorithm, which is used, for example, to calculate the number of mobility days in the context of scholarship payments.

Could you please elaborate on why decimals could be an additional problem with the hash calculation?

[sascoms]

Thanks @kamil-olszewski-uw

<xs:restriction base="xs:decimal">

Because of this direction, some systems send the duration in decimals such as 10.00, 5.00, etc.
And systems that does not take this direction into consideration save and send such duration information as 10, 5, and similar with no decimals.

Would not this cause unmatching hash problems?

Sample code:

<total-months-per-year>10</total-months-per-year>

<total-months-per-year>10.00</total-months-per-year>

[kamil-olszewski-uw]

Hash must always be calculated on exactly the XML sent by the partner (excluding matters of namespaces and omitted contacts). No matter if partner's get response contains "10" or "10.00" - you shouldn't convert that to anything else when calculating the hash of this response.

[georgschermann]

initial thought about this - as far as I remember - was that different systems store different time units and that in most cases some calculation is done which could easily end in fractions.
In our system the users are free to set the duration in days/weeks/months/semesters/years, split through the amount of applicants, and so on

[janinamincer-daszkiewicz]

Is more clarification needed? If not, I will close this issue.

[sascoms]

We need some clarification on these definitions:
What does it mean if the "total months" is given as 7.33? How shall this be interpreted by the HEI?
Is it possible to give 15.80 as total days? And if yes, what does it mean? How shall this be interpreted by the HEI?

There is still need for clarification on the documentation for these questions.

<xs:element name="total-months-per-year" minOccurs="1" maxOccurs="1">
ie: If the fraction is days, then a clarification can be added that this fraction can only be max 31 for the total-months field.

<xs:element name="total-days-per-year" minOccurs="1" maxOccurs="1">
ie: total-days fields cannot have fractions.

Yet, our opinion is that it is still not practical to have fractions and changing the definition to

<xs:restriction base="xs:integer">
would be clearer.

[janinamincer-daszkiewicz]

Some need these fractions. Why disallow if that does not cost extra effort? Changing specifiation in a non-backward compatible way would make a headache to most developers.

We have to remember that only minority leaves their opinion here.

[sascoms]

API versions are for these changes.

But no problem, and whatever the decision is, at least some clarification/explanation can be added as mentioned in my comment.

[janinamincer-daszkiewicz]

API versions are for these changes.

You know as well as us that the higher number of versions is not what we all look for now. We all look for stability.

What clarification? You are the only one to raise this issue so we do not think that clarification is needed. But can add if that helps. What exactly should we add and where?

[darrinjc]

@janinamincer-daszkiewicz I'm not a programmer, but an EWP coordinator with some technical experience. Just tested in my SIS and decimals aren't allowed and are in fact automatically removed: for example 1,4 days is saved as 14 days. Not really a big issue, since the programmers building an eventual integration to connect our SIS with a third-party provider would likely discover this sooner or later and find a solution, for example round up or down.

But why not add a simple clarification like sascoms is asking and save everyone the hassle of finding out on their own? I agree with him that this should be documented.

[janinamincer-daszkiewicz]

I would be happy to add clarification under the condition that we all agree that it really clarifies for all and does not add more confusion. Are we sure that the meaning will be the same in all cases?
If that would happen to me I would probably ask by e-mail what they have in mind. Especially if this is indeed (as Kamil says) a rare case. We would find a common ground, I hope.

[janinamincer-daszkiewicz]

P.S. During the coming months we will built e-mail lists of in-house system providers (we already have the e-mail list of 3-rd party software providers). It will be possible to reach all (or at least majority) of the providers, validate our early assumptions on the business process (based on intensive research made in early days of EWP) and consult changes in the specification. We don't want to lose anybody's opinion and needs.

Of course, if the community decides that after all decimals in this context do not make sense, the specification will be changed.

[FrederikDejaeghereUGent]

I agree that, regarding the total-months-per-year, the calculation of fractions can use clarification. If there is an official way to convert this into nr of days like kamil-olszewski-uw says, then this should be added.

[janinamincer-daszkiewicz]

I do not think there is anything official.

[darrinjc]

P.S. During the coming months we will built e-mail lists of in-house system providers (we already have the e-mail list of 3-rd party software providers). It will be possible to reach all (or at least majority) of the providers, validate our early assumptions on the business process (based on intensive research made in early days of EWP) and consult changes in the specification. We don't want to lose anybody's opinion and needs.

Of course, if the community decides that after all decimals in this context do not make sense, the specification will be changed.

Good to know, @janinamincer-daszkiewicz , thank you :) In our case, at this point we don't know who will be responsible for connecting the third-party system with EWP -- the tender of a third-party provider is taking a long time, and sometimes our own IT department builds our own in-house API integration with a third-party system, if the provider's (or sector's) integration is insufficient. Would it be possible to add our IT department to the email list, even though we don't know if they will be involved yet?

[janinamincer-daszkiewicz]

I think so.

[janinamincer-daszkiewicz]

The issue comes back with BIPs (Blended Intensive Programmes) on a table . This topic will be discussed at the coming Infrastructure Forum meetings. We wait for recommendation from DG EAG.

[demilatof]

The issue comes back with BIPs (Blended Intensive Programmes) on a table . This topic will be discussed at the coming Infrastructure Forum meetings. We wait for recommendation from DG EAG.

I think BIP is more than this; presently the specifications cannot support BIP in my opinion, for the following reasons:

1. The element "blended" is not enough to define a Blended Intensive Program; we may have a blended mobility that is not BIP
2. The BIP mobility is multilateral (at least three partners) whilst the IIA must involve only two partners

I think that we can solve both of the problems with current specifications and a minimal modification only if we accept that an IIA can be dedicated exclusively to BIP, without mixing BIP mobilities and standard mobilities in the cooperation conditions.
The solution may be adding an optional BIP ID inside the cooperation conditions <BIP_ID>123abc</BIP_ID>; if provided, this ID represents the element to unify several different IIAs that represent the same BIP.

But we should have a full analysis of the BIP requirements before trying to introduce something in the current specification.