search

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

Specifications of EWP's Interinstitutional Agreements API.
MIT License
4 stars 13 forks source link

Re-introduce the maxOccurs unbounded for sending-ounit-id and receiving-ounit-id #71

Closed jiripetrzelka closed 1 year ago

jiripetrzelka commented 2 years ago

SUMMARY (our proposed changes to IIAs API based on our discussion):

  1. We will remove sending-contact and receiving-contact from the calculation of the hash.

  2. We will NOT remove sending-ounit-id and receiving-ounit-id from the calculation of the hash.

  3. We will change maxOccurs of sending-ounit-id and receiving-ounit-id from unbounded to 1.

  4. We will NOT change max Occurs of student-studies-mobility-spec, student-traineeship-mobility-spec, staff-teacher-mobility-spec and staff-training-mobility-spec from unbounded to 1.

  5. We will NOT force a specific number of digits in the isced-f-code, but in the commentary to this element we will strongly recommend that the ISCED code should be four-digit, because this way it will be compliant with the requirements of Mobility Tool+ apllication, which only accepts four-digit codes for mobilities (see issue: #49).

Originally posted by @kamil-olszewski-uw in https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/48#issuecomment-797501411

jiripetrzelka commented 2 years ago

I would like to point out that the change in point 3 does not reflect the needs of some universities because there are IIAs in which two or more units share one cooperation condition and do not know in advance how many places will be distributed to which unit. By making this change you force them to divide the places in advance between individual units and if they later find out that student/staff interest is greater in some of the units, then they will have to create an amendment to the agreement and re-distribute the numbers of persons. Or they put the names of the 2+ units into other-info-terms to circumvent this restriction.

I wonder why this change was actually put in place. Was the rationale behind it to make universities not have shared places among multiple units? Because if not, then the only possible reason I see is that the change was based on analysing the majority of IIA, in which this use case is not necessary, rather than the analysis all use cases that come up in reality, including the most specific ones. I believe that software design should always be based on the second approach and I suggest to re-introduce the maxOccurs unbounded for sending-ounit-id and receiving-ounit-id in the nearest major version of the IIA API.

georgschermann commented 2 years ago

As far as I remember point 3 was done to be in line with the partner elements of the iia which always had maxOccurence 1. So if an agreement is between two ounits, there is little use to have uninvolved ounits in the coop conditions. I don't know where exactly this restriction came from, since I have limited domain knowlege, probably from the iia template, MT+ or the larger SIS providers involved in the specification.

At least in our system providing multiple ounits is not possible and would result in a splitted condition (with best-guess places) or an university-wide agreement omitting the ounits alltogether.

umesh-qs commented 2 years ago

It was done because no one objected or could give a valid use case for unbounded ounit at that time. Or may be most of the systems (including Dashboard) were only supporting only 1 ounit per agreement.

sascoms commented 2 years ago

We are in favor of multiple ounit-ids as agreements are made mostly based on ounits (academic departments/faculties) in our country. Our HEIs have many IIAs with ounits more than one. But we have to put only the first one into the IIA due to the limitation.

If the ounit-ids are set to unbounded, than IIAs of our HEIs would reflect the real life data in IIA exchanges in between partners.

janinamincer-daszkiewicz commented 2 years ago

We will go in this direction.

umesh-qs commented 2 years ago

We have some clients asking for it. So we are in favor of this.

jiripetrzelka commented 2 years ago

Can you please add this change to the IIA V7 specification?

janinamincer-daszkiewicz commented 2 years ago

OK, the last call - is anybody strongly AGAINST this change? If not it will be added to IIA V7. Be aware that some f your partner will not be ready or not be willing to handle these many units and will probably skip them anyway.

janinamincer-daszkiewicz commented 2 years ago

We also have ounit on a global level:

Should this element also allow unbounded? If there is only one ounit (let say A) on a global level, should it be allowed to have more ounits on a CC level (A and B or B and C)? May be we should add strong recommendation that the list of ounits on CC level should be a subset of the list of units on a global level?
kamil-olszewski-uw commented 2 years ago

The element ounit-id on the global (IIA) level has a specific use: If given, then it refers to the unit within the partner HEI's organizational structure, which is the actual partner of this agreement. Agreements can be signed between units, not only between HEIs: https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/11

If such a solution were found to be satisfactory and reasonable, then the set of organizational units could be introduced at the IIA level, but the existence of a current ounit-id at this level should not affect this, and this ounit-id should remain separate.

janinamincer-daszkiewicz commented 2 years ago

I understand that you suggest the following approach:

  1. We keep one ounit on a global level (agreement is always signed with one entity).
  2. We allow many ounits on CC level, and do not impose any restrictions on a relation of the global ounit with CC ounits.

OK we will follow this approach.

jiripetrzelka commented 2 years ago

I confirm that this solution is in line with the needs of the universities using our system.

janinamincer-daszkiewicz commented 2 years ago

This will be part of incoming changes in IIAs.

mkurzydlowski commented 2 years ago

It looks like we just need to revert previous commits (https://github.com/erasmus-without-paper/ewp-specs-api-iias/pull/78).

jiripetrzelka commented 1 year ago

Is this approved for IIA 7.0?

georgschermann commented 1 year ago

if this is re-introduced I think we need a mechanism for HEIs which don't support this or if compliance is enforced, probably a definition how places are distributed across the ounits.

currently in our system agreements are very strictly separated between ounits and there is no possibility to send e.g. 5 students to any of 2+ onuits. Several HEIs won't allow for IIAs to span multiple ounits. There was a similar discussion when the Dashboard didn't support multilateral IIAs and the IIAs were moved to bilateral ones, the change to multiple ounits makes it multilateral for us again.

janinamincer-daszkiewicz commented 1 year ago

Georg, I understand your arguments, but there are also arguments of the other partners. Do you see a solution to this dillema? Let's try to to summarize pros and cons for every option:

  1. <xs:element name="sending-ounit-id" type="ewp:AsciiPrintableIdentifier" minOccurs="0" maxOccurs="1">
  2. <xs:element name="sending-ounit-id" type="ewp:AsciiPrintableIdentifier" minOccurs="0" maxOccurs="unbounded">

(the same for receiving-ounit-id) If we cannot get consensus we will have to vote, but I prefer to find a solution acceptable for all.

janinamincer-daszkiewicz commented 1 year ago

Jiri, Georg, please find solution for each other :) Let's assume that :

How should their common IIA look like in this case?

jiripetrzelka commented 1 year ago

if this is re-introduced I think we need a mechanism for HEIs which don't support this or if compliance is enforced, probably a definition how places are distributed across the ounits.

If a certain HEI does not want to support an IIA with unclear distribution of places among units, the IRO officer would inform the other IRO officer and they would probably sign/approve an IIA in which each cooperation condition would contain just one unit and the distribution of places would be clearly defined accross units.

This request, however, is about IROs that have the business need to not specify the exact number of places for each unit. If we accept that this need it real and still want to hypothesize about a scenario in which some systems would not offer a technical solution for this need then the IRO using the system with limited functionality would probably omit the units in their IIA or enter just one of the units and possibly add some explanation into other-info-terms. On the other hand, the IIA of the other party supporting multiple units would insert all units into their IIAs that reflect the actual reality, i.e. what has been agreed among IROs.

janinamincer-daszkiewicz commented 1 year ago

Couldn't they just agree to sign IIA where for a specific mobility:

We have two copies of this IIA, why cannot they differ in such respect?

jiripetrzelka commented 1 year ago

They could. I think it is similar to the scenario when some implementations were not able to put even one ounit of partner into their IIA. The other party probably accepted it or asked at least for some clarification in the other-info-terms.

georgschermann commented 1 year ago

one possiblity would be to omit ounits in the own agreement, so the partner IIA would state 2 sending ounits, the mapped own IIA wouldn't state any ounit meaning "hei-wide", the partners would need to be able to approve on these differing IIAs and the ounit information would be lost on one side, which probably couldn't use it anyway This would most likely be our internal solution if this change makes it to specification.

maximum numbers could be used with additional information provided somehow that these numbers are "shared", so one CC with 2 onuits would be split in two CCs each with one ounit and same everything, probably again only on one of the partners IIAs which doesn't support multiple ounits, in this case without other information the numbers are doubled

umesh-qs commented 1 year ago

I understand that you suggest the following approach:

  1. We keep one ounit on a global level (agreement is always signed with one entity).
  2. We allow many ounits on CC level, and do not impose any restrictions on a relation of the global ounit with CC ounits.

OK we will follow this approach.

I assume all ounits used in the IIA are child of the partner HEIs

umesh-qs commented 1 year ago

one possiblity would be to omit ounits in the own agreement, so the partner IIA would state 2 sending ounits, the mapped own IIA wouldn't state any ounit meaning "hei-wide", the partners would need to be able to approve on these differing IIAs and the ounit information would be lost on one side, which probably couldn't use it anyway This would most likely be our internal solution if this change makes it to specification.

maximum numbers could be used with additional information provided somehow that these numbers are "shared", so one CC with 2 onuits would be split in two CCs each with one ounit and same everything, probably again only on one of the partners IIAs which doesn't support multiple ounits, in this case without other information the numbers are doubled

@georgschermann above is against the specs image

janinamincer-daszkiewicz commented 1 year ago

maximum numbers could be used with additional information provided somehow that these numbers are "shared", so one CC with 2 onuits would be split in two CCs each with one ounit and same everything, probably again only on one of the partners IIAs which doesn't support multiple ounits, in this case without other information the numbers are doubled

Georg, what I propose does not need splitting, the number of CCs remains the same but we have a different numbers of ounits in each partner's HEI. Umesh is right that the number of CCs should not change.

To summarise, we should make it after we make a change to:

<xs:element name="sending-ounit-id" type="ewp:AsciiPrintableIdentifier" minOccurs="0" maxOccurs="unbounded">

You would put 1, and your partner would put 2. Any objections?

umesh-qs commented 1 year ago

maximum numbers could be used with additional information provided somehow that these numbers are "shared", so one CC with 2 onuits would be split in two CCs each with one ounit and same everything, probably again only on one of the partners IIAs which doesn't support multiple ounits, in this case without other information the numbers are doubled

Georg, what I propose does not need splitting, the number of CCs remains the same but we have a different numbers of ounits in each partner's HEI. Umesh is right that the number of CCs should not change.

To summarise, we should make it after we make a change to:

<xs:element name="sending-ounit-id" type="ewp:AsciiPrintableIdentifier" minOccurs="0" maxOccurs="unbounded">

You would put 1, and your partner would put 2. Any objections?

@janinamincer-daszkiewicz It would mean that you will approve my IIA with 2 ounit, but I will have no choice but to wrongly approve only 1 ounit on your IIA. Both IIAs are not in sync. It this a legally valid contract?

@janinamincer-daszkiewicz is this requirement of more than 1 ounit in CC coming from DG EAC? Is this what BPOs want? Has this been confirmed by @pleys?

janinamincer-daszkiewicz commented 1 year ago

It would mean that you will approve my IIA with 2 ounit, but I will have no choice but to wrongly approve only 1 ounit on your IIA. Both IIAs are not in sync. It this a legally valid contract?

Why the number of ounits should be the same in sending and receiving?

umesh-qs commented 1 year ago 
Assuming my HEI is A and your HEI is B

My IIA that you must approve
<cooperation-conditions>
    <student-studies-mobility-spec>
        <sending-hei-id>A</sending-hei-id>
        <receiving-hei-id>B</receiving-hei-id>
        <sending-ounit-id>Unit1</sending-ounit-id>
        <sending-ounit-id>Unit2</sending-ounit-id>
        <receiving-academic-year-id>2019/2020</receiving-academic-year-id>
        <receiving-academic-year-id>2020/2021</receiving-academic-year-id>
        <mobilities-per-year>2</mobilities-per-year>
        <eqf-level>7</eqf-level>
        <eqf-level>8</eqf-level>
    </student-studies-mobility-spec>
    <student-studies-mobility-spec>
        <sending-hei-id>B</sending-hei-id>
        <receiving-hei-id>A</receiving-hei-id>
        <receiving-ounit-id>Unit1</receiving-ounit-id>
        <receiving-ounit-id>Unit2</receiving-ounit-id>
        <receiving-academic-year-id>2019/2020</receiving-academic-year-id>
        <receiving-academic-year-id>2020/2021</receiving-academic-year-id>
        <mobilities-per-year>2</mobilities-per-year>
        <eqf-level>7</eqf-level>
        <eqf-level>8</eqf-level>
    </student-studies-mobility-spec>
</cooperation-conditions>

Yor IIA which I have to approve
<cooperation-conditions>
    <student-studies-mobility-spec>
        <sending-hei-id>A</sending-hei-id>
        <receiving-hei-id>B</receiving-hei-id>
        <sending-hei-id>A</sending-hei-id>
        <sending-ounit-id>Unit1</sending-ounit-id>
        <receiving-academic-year-id>2019/2020</receiving-academic-year-id>
        <receiving-academic-year-id>2020/2021</receiving-academic-year-id>
        <mobilities-per-year>2</mobilities-per-year>
        <eqf-level>7</eqf-level>
        <eqf-level>8</eqf-level>
    </student-studies-mobility-spec>
    <student-studies-mobility-spec>
        <sending-hei-id>B</sending-hei-id>
        <receiving-hei-id>A</receiving-hei-id>
        <receiving-ounit-id>Unit1</receiving-ounit-id>
        <receiving-academic-year-id>2019/2020</receiving-academic-year-id>
        <receiving-academic-year-id>2020/2021</receiving-academic-year-id>
        <mobilities-per-year>2</mobilities-per-year>
        <eqf-level>7</eqf-level>
        <eqf-level>8</eqf-level>
    </student-studies-mobility-spec>
</cooperation-conditions>

Is this correct that you are approving a contract with my ounit1 and ounit2 and I am forced to approve you contract with only ounit1. Is the contract valid?

janinamincer-daszkiewicz commented 1 year ago

I do not understand your example. Why sending ounits are exactly the same as receiving ounits? These are two different HEIs.

umesh-qs commented 1 year ago

I do not understand your example. Why sending ounits are exactly the same as receiving ounits? These are two different HEIs.

Because it is for HEI A. In first cooperation condition HEI A is sender and second cooperation condition HEI A is receiver.

umesh-qs commented 1 year ago

@janinamincer-daszkiewicz is this requirement of more than 1 ounit in CC coming from DG EAC? Is this what BPOs want? Has this been confirmed by @pleys?

@janinamincer-daszkiewicz still waiting for response on this.

janinamincer-daszkiewicz commented 1 year ago

And this part? Why sending-hei-id is given twice?

        <sending-hei-id>A</sending-hei-id>
        <receiving-hei-id>B</receiving-hei-id>
        <sending-hei-id>A</sending-hei-id>
umesh-qs commented 1 year ago

And this part? Why sending-hei-id is given twice?

      <sending-hei-id>A</sending-hei-id>
      <receiving-hei-id>B</receiving-hei-id>
      <sending-hei-id>A</sending-hei-id>

Copy paste issue. Please ignore extra <sending-hei-id>A</sending-hei-id>

umesh-qs commented 1 year ago

And this part? Why sending-hei-id is given twice?

        <sending-hei-id>A</sending-hei-id>
        <receiving-hei-id>B</receiving-hei-id>
        <sending-hei-id>A</sending-hei-id>

Copy paste issue. Please ignore extra <sending-hei-id>A</sending-hei-id>

Updated it now

janinamincer-daszkiewicz commented 1 year ago

I still don't follow. What I wanted to say is that both partners would agree to the following IIA (2 options given, number changes from 2 to 10-3+7, to better express the difference between A and B): Option 1

<cooperation-conditions>
    <student-studies-mobility-spec>
        <sending-hei-id>A</sending-hei-id>
        <sending-ounit-id>Unit_A1</sending-ounit-id>
        <sending-ounit-id>Unit_A2</sending-ounit-id>
        <receiving-hei-id>B</receiving-hei-id>
        <receiving-academic-year-id>2019/2020</receiving-academic-year-id>
        <receiving-academic-year-id>2020/2021</receiving-academic-year-id>
        <mobilities-per-year>10</mobilities-per-year>
        <eqf-level>7</eqf-level>
        <eqf-level>8</eqf-level>
    </student-studies-mobility-spec>
    <student-studies-mobility-spec>
        <sending-hei-id>B</sending-hei-id>
        <sending-ounit-id>Unit_B1</sending-ounit-id>
        <receiving-hei-id>A</receiving-hei-id>
        <receiving-academic-year-id>2019/2020</receiving-academic-year-id>
        <receiving-academic-year-id>2020/2021</receiving-academic-year-id>
        <mobilities-per-year>3</mobilities-per-year>
        <eqf-level>7</eqf-level>
        <eqf-level>8</eqf-level>
    </student-studies-mobility-spec>
    <student-studies-mobility-spec>
        <sending-hei-id>B</sending-hei-id>
        <sending-ounit-id>Unit_B2</sending-ounit-id>
        <receiving-hei-id>A</receiving-hei-id>
        <receiving-academic-year-id>2019/2020</receiving-academic-year-id>
        <receiving-academic-year-id>2020/2021</receiving-academic-year-id>
        <mobilities-per-year>7</mobilities-per-year>
        <eqf-level>7</eqf-level>
        <eqf-level>8</eqf-level>
    </student-studies-mobility-spec>
</cooperation-conditions>

Option 2

<cooperation-conditions>
    <student-studies-mobility-spec>
        <sending-hei-id>A</sending-hei-id>
        <sending-ounit-id>Unit_A1</sending-ounit-id>
        <sending-ounit-id>Unit_A2</sending-ounit-id>
        <receiving-hei-id>B</receiving-hei-id>
        <receiving-ounit-id>Unit_B1</receiving-ounit-id>
        <receiving-ounit-id>Unit_B2</receiving-ounit-id>
        <receiving-academic-year-id>2019/2020</receiving-academic-year-id>
        <receiving-academic-year-id>2020/2021</receiving-academic-year-id>
        <mobilities-per-year>10</mobilities-per-year>
        <eqf-level>7</eqf-level>
        <eqf-level>8</eqf-level>
    </student-studies-mobility-spec>
    <student-studies-mobility-spec>
        <sending-hei-id>B</sending-hei-id>
        <sending-ounit-id>Unit_B1</sending-ounit-id>
        <receiving-hei-id>A</receiving-hei-id>
        <receiving-ounit-id>Unit_A1</receiving-ounit-id>
        <receiving-ounit-id>Unit_A2</receiving-ounit-id>
        <receiving-academic-year-id>2019/2020</receiving-academic-year-id>
        <receiving-academic-year-id>2020/2021</receiving-academic-year-id>
        <mobilities-per-year>3</mobilities-per-year>
        <eqf-level>7</eqf-level>
        <eqf-level>8</eqf-level>
    </student-studies-mobility-spec>
    <student-studies-mobility-spec>
        <sending-hei-id>B</sending-hei-id>
        <sending-ounit-id>Unit_B2</sending-ounit-id>
        <receiving-hei-id>A</receiving-hei-id>
        <receiving-ounit-id>Unit_A1</receiving-ounit-id>
        <receiving-ounit-id>Unit_A2</receiving-ounit-id>
        <receiving-academic-year-id>2019/2020</receiving-academic-year-id>
        <receiving-academic-year-id>2020/2021</receiving-academic-year-id>
        <mobilities-per-year>7</mobilities-per-year>
        <eqf-level>7</eqf-level>
        <eqf-level>8</eqf-level>
    </student-studies-mobility-spec>
</cooperation-conditions>
janinamincer-daszkiewicz commented 1 year ago

is this requirement of more than 1 ounit in CC coming from DG EAC? Is this what BPOs want? Has this been confirmed by @pleys?

This requirement comes from this issue, see very first post by Jiri. Also in referenced https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/48#issuecomment-800331957 some providers (also you) mentioned that having unbounded instead of 1 may be too restrictive. In https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/71#issuecomment-1004287059 I promised to introduce such change and in https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/71#issuecomment-1514464847 Jiri reminded us about it.

As we are now gathering changes to be issued under IIA version 7.0.0 I go through all issues concerning IIAs. I want to close this thread with the belief that all arguments have been presented and that we can make a final decision together.

umesh-qs commented 1 year ago

is this requirement of more than 1 ounit in CC coming from DG EAC? Is this what BPOs want? Has this been confirmed by @pleys?

This requirement comes from this issue, see very first post by Jiri. Also in referenced #48 (comment) some providers (also you) mentioned that having unbounded instead of 1 may be too restrictive. In #71 (comment) I promised to introduce such change and in #71 (comment) Jiri reminded us about it.

As we are now gathering changes to be issued under IIA version 7.0.0 I go through all issues concerning IIAs. I want to close this thread with the belief that all arguments have been presented and that we can make a final decision together.

We were not in favor of changing limit the ounit to max 1. We asked the same question earlier on who approved that. And going through the topic I see it probably was driven by Dashboard limitation at that time. Coming to changing it back to unbounded ounit, let us not do the same mistake again. This is a business requirement and should be driven by BPOs. I would like have @pleys or someone from DG EAC patriciate in this discussion and confirm if IROs want this change now. If the IROs are now settled with using max 1 ounit, why to make their life difficult by re-introducing unbounded ounits.

georgschermann commented 1 year ago

above is against the specs

I know, but since a change in specs is discussed here, this should not be an issue. These were possible solutions for the case that one provider/hei wants multiple ounits and the other doesn't.

janinamincer-daszkiewicz commented 1 year ago

We were not in favor of changing limit the ounit to max 1. We asked the same question earlier on who approved that. And going through the topic I see it probably was driven by Dashboard limitation at that time.

It was not driven by anybody's limitation but was a result of a long discussion among the EDSSI partners. In charge were EDSSI authorities.

Coming to changing it back to unbounded ounit, let us not do the same mistake again. This is a business requirement and should be driven by BPOs. I would like have @pleys or someone from DG EAC patriciate in this discussion and confirm if IROs want this change now. If the IROs are now settled with using max 1 ounit, why to make their life difficult by re-introducing unbounded ounits.

I don't mind, let's wait for BPOs. Their next meeting is scheduled on 13/06.

demilatof commented 1 year ago

We were not in favor of changing limit the ounit to max 1. We asked the same question earlier on who approved that. And going through the topic I see it probably was driven by Dashboard limitation at that time. Coming to changing it back to unbounded ounit, let us not do the same mistake again. This is a business requirement and should be driven by BPOs. I would like have @pleys or someone from DG EAC patriciate in this discussion and confirm if IROs want this change now. If the IROs are now settled with using max 1 ounit, why to make their life difficult by re-introducing unbounded ounits.

I agree with you, now we are settled with using max 1 ounit, our GUIs, our data models, our data are settled so. We need a strong request by the DG EAC to change them, and not a generic request that can be discussed only if there is strong objection by the majority of providers.

The current specifications are quite different from the template, I don't know who decided to introduce more elements and why. E.g. the template doesn't allow more ISCED-F or study cycles for a single mobility, whilst we can have several ISCED-F or study cycles in the specification. I'm still waiting for an answer. If we follow every time the requests of few IROs or providers, we move to a dangerous criteria that can over complicate the implementation. Now we have ISCED-F, and language level per an ounit (if specified). If we introduce more ounits may be that after that, some IROs will ask to specify the ISCED-F per each ounit, because an ISCED could be valid for a given ounit but not for the other one. Are we moving toward this?

Georg, what I propose does not need splitting, the number of CCs remains the same but we have a different numbers of ounits in each partner's HEI.

If my partner can express several ounits, I don't have any advantage of the possibility to keep on putting only an ounit on my side, I have to modify anyway the model, the GUI and the controls to accept more than ounit.

I don't mind, let's wait for BPOs. Their next meeting is scheduled on 13/06.

What could we expect that they will say or decide at that meeting?

georgschermann commented 1 year ago

If my partner can express several ounits, I don't have any advantage of the possibility to keep on putting only an ounit on my side, I have to modify anyway the model, the GUI and the controls to accept more than ounit.

not 1 ounit on your side of the IIA but only 1 ounit per CC for your entire version of the IIA on all sides, IIAs and CC count would differ though, but no need to deal with multiple ounits in a CC in your local system

not saying that this is a good solution

demilatof commented 1 year ago

not 1 ounit on your side of the IIA but only 1 ounit per CC for your entire version of the IIA on all sides, IIAs and CC count would differ though, but no need to deal with multiple ounits in a CC in your local system

I don't fully understand you clarification; @janinamincer-daszkiewicz said:

You would put 1, and your partner would put 2.

Even if I put 1 ounit on my side per CC, to save and show my partner's IIA I have to manage anyway more than one ounit per CC.

I think that we should well understand what is the need of IROs that asked for more than one ounit. If they are interested in differentiate, on their side, some ounits, they should accept to know how many places per ounit they want to offer. Therefore, they should not indicate 10 places for ounit_A1 and ounit_A2 (that could mean "8 and 2" but even "6 and 4" or "5 and 5"), but they should indicate exactly how many places for ounit_A1 and how many places for ounit_A2.

Doing so they could reach their aim with the current specifications:

         <student-studies-mobility-spec>
        <sending-hei-id>A</sending-hei-id>
        <receiving-hei-id>B</receiving-hei-id>
        <sending-ounit-id>Unit_A1</sending-ounit-id>   <!-- *** 3 places from Unit A1 *** -->
        <mobilities-per-year>3</mobilities-per-year>
                ...
    </student-studies-mobility-spec>

         <student-studies-mobility-spec>
        <sending-hei-id>A</sending-hei-id>
        <receiving-hei-id>B</receiving-hei-id>
        <sending-ounit-id>Unit_A2</sending-ounit-id>     <!-- *** 7 places from Unit A2 *** -->
        <mobilities-per-year>7</mobilities-per-year>
                ...
    </student-studies-mobility-spec>

But since I suppose that B partner's isn't interested in checking if the A's students will arrive from a ounit or another one, there is no reason to specify this in the cooperation conditions; it is an issue of B concerning its application form for outgoing mobilities, that is not important from the EWP network perspective. And the same for incoming mobilities.

Last but not least: if an institution wishes to specify more than one ounit, it could do a really simple operation. It creates a new ounit in the EWP world that is a set of the ounits that the HEI wants to indicate in the CC. So, if it has:

  1. ounit "Department of A1" with ounit-ID: Unit_A1
  2. ounit "Department of A2" with ounit-ID: Unit_A2

the HEI can make the following new virtual ounit in its internal system (EWP side):

ounit "Departments of A1 and A2" with ounit-ID: Unit_A1_A2

It's really simple, we don't touch the current specifications, every local system implements its own solution. And we don't need any opinion or recommendation from BPO or DG EAC

janinamincer-daszkiewicz commented 1 year ago

ounit "Departments of A1 and A2" with ounit-ID: Unit_A1_A2

Should partner B expect to get such virtual ad hoc created ounits in the response to the Institutional API? All possible combinations?

demilatof commented 1 year ago

Should partner B expect to get such virtual ad hoc created ounits in the response to the Institutional API?

Of course, someone may need to have it in the response to the Institutional API to fetch its description from organizational units API. The response.xsd states something similar:

A list of IDs of all significant organizational units. Clients can fetch more information on these via the Organizational Units API.

It is not required to expose all units. Servers may choose which units are relevant for EWP data exchange (and, in fact, they often SHOULD limit what they expose, to avoid clutter in client user interfaces).

Do you think that it could be a problem?

All possible combinations?

I don't think so. When a partner wishes to indicate more than one ounit in his IIA, he should perform the following tasks:

  1. Creating a new (virtual) ounit that collects all the needed ounits (if not yet created)
  2. Adding it in the response to the Institutional API and Organizational Units API
  3. Using this new ounit-id in the IIA

How many combinations depends on the partner that needs to indicate more than one sending/receiving ounit. Maybe he needs always the same two or three ounits; in this situation, once created the virtual organization unit, he can use it always. Anyway, no extra work to the other partner.

janinamincer-daszkiewicz commented 1 year ago

I just think that creating such artificial ounits, which do not exist in real life, is not a good way to go.

demilatof commented 1 year ago

I just think that creating such artificial ounits, which do not exist in real life, is not a good way to go.

How many HEIs need to have more sending/receiving ounit in cooperation conditions? We have more than 5.000 HEIs if I'm not wrong; it there are only some tens of them that need more cooperation conditions, my proposal is the least intrusive and can allow several combinations of ounits (A and B, A and C). If we are worried of the mix real ounit vs. virtual ounit, just introduce an optional element or attribute "virtual" in the response.xsd to mark the new organizational unit.


<ounit virtual="true">
    ...
</ounit>

And if we wish to have a more structured data, we can list the real ounits that compose a virtual ounit by adding an optional element to be used with the virtual ounit:

<xs:element name="real-ounit-id" minOccurs="0" maxOccurs="unbounded">

The advantage of this solution is that all the changes are upon the providers that want to manage more than one sending/receiving ounit. There is no need that the others do something, because they see only an ounit-id and when they fetch the information about it, they see a name and don't need anything more (or aren't interested in anything more)

janinamincer-daszkiewicz commented 1 year ago

How many HEIs need to have more sending/receiving ounit in cooperation conditions?

It doesn't matter. The idea is bad by design. You do not know what your partner will do with these ounits, may be will create a web page showing all partners and their ounits. There are much more natural ways to solve the problem.

demilatof commented 1 year ago

How many HEIs need to have more sending/receiving ounit in cooperation conditions?

It doesn't matter.

Instead, it does really matter.

The idea is bad by design.

This is your opinion. In my opinion, what is bad by design here is that in march 2021 there was no limit to the number of units, then it was changed to 1 and now we discover that there is the need to remove the limit again. We cannot develop adding and removing pieces of code from time to time; pieces of code to manage information that we cannot find in the official template.

You do not know what your partner will do with these ounits, may be will create a web page showing all partners and their ounits. There are much more natural ways to solve the problem.

Are you serious? This is a matter of each local system and now you are using this possibility as an example of bad design? From the network perspective we are only interested about what the HEIs do with ounits in EWP exchanges. In their local system every provider can implement his own solution to identify this virtual unit and exclude them from other management. This is the most trivial problem.

And this is claimed by the response.xsd for Institutions API, not by me

It is not required to expose all units. Servers may choose which units are relevant for EWP data exchange (and, in fact, they often SHOULD limit what they expose, to avoid clutter in client user interfaces).

This could also mean that to avoid clutter in client user interfaces is much better a single line with a set of ounits than several lines to list all the units involved.

janinamincer-daszkiewicz commented 1 year ago

Thank you Francesco for your analysis and opinion. We will not be following this proposal. I suggest to wait for BPOs - as already been outlined in this issue they should be the one to decide if changes are needed. @pleys, please add this topic to the agenda of the coming meeting.

demilatof commented 1 year ago

Janina, you're welcome.

May I remember that is not up to you what an HEI lists as its significant organizational units but "Servers may choose which units are relevant for EWP data exchange"? And that organizational units may be faculties, departments, divisions, etc.? And that "In a large organization, a division is a group of departments whose work is done in the same place or is connected with similar tasks."? (point 5)

The specifications already consider the virtual organizational units (or division, if you'd like better), the HEIs could already use them and we don't know. You decided to not follow a proposal that is already in the specifications. Good to know.

Since I discovered that is up to you and not to the community to decide what proposal is good or not, may we know what problem and solution have you represented to BPOs now and two years ago?

I've shared my analysis and opinion, what is your to minimize the problems to the providers not interested in this change?