Recognizing different cooperation conditions

[milsorm]

We have one pity issue in communication with our partners (and with USOS too), because they didn't return us our contacts written to every individual conditions inside IIA (when sending their copy of agreement). And we need to match which cooperation condition in our copy is the same in partner's copy.

Example:

HEI A is preparing IIA with two cooperation conditions and in both is written some contact from their party.

HEI B is receiving this IIA and ignoring some cooperation condition optional fields like contacts.

HEI B is changing conditions (one is removed, another two is added) and send IIA back to A.

HEI A is receving their copy and if we copy it at all, there will be no contacts in kept cooperation condition. IRO from HEI A is asking why it is disappeared. We need to compare this two copies and found which cooperation conditions are the same and keep contacts from our copy and merge it with new conditions from partner copy.

Is it possible to add some ID for every cooperation conditions which allow during the negotiation to understand which condition is which and allow this merge process?

Or everybody else is doing this manually by IRO staff?

Thnx in advance for answer, Milan

[umesh-qs]

@milsorm I would say it is a wrong implementation by HEI A. HEI A should not replace the content of their internal IIA, without showing the changes made by HEI B.

[umesh-qs]

@milsorm for your reference, we asked for some identifiers in cooperation conditions
#29

[milsorm]

@milsorm I would say it is a wrong implementation by HEI A. HEI A should not replace the content of their internal IIA, without showing the changes made by HEI B.

Our IRO don't expect to see two copies of approval, manually to reentering all things from one side to another one, looking for same conditions between 30 others and doing this every thime when counter-party is sending something else.

We are trying to display changes to IRO when received counter-IIA and trying to merge everything to keep only one existing copy. Of course sometimes it is not possible (when both parties are editing the same IIA simultaneouslly) and then we left to IRO to decide which one is newer one and manually merge it (like git with manual merge), but for continuing with process we want to have one "agreed" copy.

The same things works many years with MS Word - copy is send than and back and than and back with revisions and merged together to one document, which is kept signed in two copies. And I understand business requirements to the the same thing eletronically.

But BTW thanks for asking for identifier in #29.

[umesh-qs]

@milsorm I would say it is a wrong implementation by HEI A. HEI A should not replace the content of their internal IIA, without showing the changes made by HEI B.

Our IRO don't expect to see two copies of approval, manually to reentering all things from one side to another one, looking for same conditions between 30 others and doing this every thime when counter-party is sending something else.

We are trying to display changes to IRO when received counter-IIA and trying to merge everything to keep only one existing copy. Of course sometimes it is not possible (when both parties are editing the same IIA simultaneouslly) and then we left to IRO to decide which one is newer one and manually merge it (like git with manual merge), but for continuing with process we want to have one "agreed" copy.

The same things works many years with MS Word - copy is send than and back and than and back with revisions and merged together to one document, which is kept signed in two copies. And I understand business requirements to the the same thing eletronically.

But BTW thanks for asking for identifier in #29.

So how will identifier help here? What you are asking is partner B always keep the content that you have added to the IIA. But partner B is not bound to keep your contacts in their system and send it back.

[milsorm]

So how will identifier help here? What you are asking is partner B always keep the content that you have added to the IIA. But partner B is not bound to keep your contacts in their system and send it back.

If partner is sending contacts we can use them.
If partner is not sending contacts we can found ours according to ID for same conditions and keep them.

OK it can be that partner WANT to remove our contact - this cannot be distinguish but it is rare so it can be solve via email/call.

[milsorm]

This is also for @kamil-olszewski-uw because we are solving the same situation with USOS in Wroclaw - they receive our contact "Filáčková" but rewrite to their copy "Fláčková" (by mistake because they are doing it manually). And we have disproportion between contacts - we cannot found "Fláčková" but with ID we will have hint that it was our (relatively same named) contact because we can compare it automatically with our older copy. That ID will definitely helps us a lot.

[umesh-qs]

So how will identifier help here? What you are asking is partner B always keep the content that you have added to the IIA. But partner B is not bound to keep your contacts in their system and send it back.

If partner is sending contacts we can use them. If partner is not sending contacts we can found ours according to ID for same conditions and keep them.

OK it can be that partner WANT to remove our contact - this cannot be distinguish but it is rare so it can be solve via email/call.

I am not sure at want point you will use call/email. You keep sending the same contact and partner B keeps removing them. And the IIA process is stuck because non mandatory contacts? Forget about contact. Each system can have their own way of representing the cooperation condition. You might have singe cooperation condition for 2 ISCED, while partner can have 2 cooperation conditions for 2 ISCED. How are you handling that?

[skishk]

are you talking about sending-contact or receiving-contact tags? which are not required...
in cooperation-condition there are no contacts... 😅 or probably i didn't understand very well

[milsorm]

I am not sure at want point you will use call/email. You keep sending the same contact and partner B keeps removing them. And the IIA process is stuck because non mandatory contacts?

If there whill be ID and I can found which cooperation condition is which one in our copy, I can keep our contacts (as HEI A because we are responsible for them) and get contacts from HEI B for their party. But if I am not able to recognize which cooperation condition is which that this has to be done MANUALLY and this is bad (mistake by typos, a lot of workload for IRO etc.).

Forget about contact. Each system can have their own way of representing the cooperation condition. You might have singe cooperation condition for 2 ISCED, while partner can have 2 cooperation conditions for 2 ISCED. How are you handling that?

Because I am not able to find which cooperation condition in our copy is which in partner copy I can only overtake the whole conditions as new ones and display to IRO "one is removed and two is added".

[milsorm]

are you talking about sending-contact or receiving-contact tags? which are not required... in cooperation-condition there are no contacts... 😅 or probably i didn't understand very well

Yes, sending and receiving contact inside MobilitySpecification. It is not required, but if our IRO is filling it and counter-party is not using it, we cannot distinguish which of our sending-contact can keep to which cooperation condition without any ID of that condition (returned list of condition can be in different order).

[demilatof]

In my opinion your implementation may not be very compliant with master-master model.
If you like, you may use it, but I think that we should not modify EWP to solve this kind of problem.
You have a copy, your partner has its copy. You exchange them, and you have to make the two copies similar, editing your own.
Personally, I don't like to trust partner's changes and import them in a blind fashion.
My IROs look over the partner copy, and then they edit our copy.
If you choose to import partner's copy without human activity, you can do, but I'm afraid you can have some issues and not only concerning the contacts. And you could lose control over your internal data.

You might have singe cooperation condition for 2 ISCED, while partner can have 2 cooperation conditions for 2 ISCED. How are you handling that?

@umesh-qs
You cannot, not any more at least.
I have had to modify our implementation to solve this problem and to adapt our copy to partner's copy.
Obviously, we could choose to do nothing and to ask the partner to change its own copy.
The crucial points are listed here:

• Both copies of the same IIA stored in both partners' systems must be presented to each other as exactly one IIA having the same number of corresponding cooperation conditions.
• Regardless of whether a field is mandatory in the API, if it is present in the IIA of one HEI it is highly recommended to have it in the matched IIA of the partner HEI.
• Providers are free to implement their local solutions to best support the needs of their customers but under the condition that the general principle expressed in the points above is maintained.

@milsorm
The second point suggests that your partner should add the contacts in its copy, but it can write "Mark Twain" whilst you have "Twain Mark" and this can complicate your matching algorithm

[milsorm]

In my opinion your implementation may not be very compliant with master-master model. If you like, you may use it, but I think that we should not modify EWP to solve this kind of problem. You have a copy, your partner has its copy. You exchange them, and you have to make the two copies similar, editing your own. Personally, I don't like to trust partner's changes and import them in a blind fashion. My IROs look over the partner copy, and then they edit our copy. If you choose to import partner's copy without human activity, you can do, but I'm afraid you can have some issues and not only concerning the contacts. And you could lose control over your internal data.

I discussed that with our IROs and they answered that they cannot imagine to manually compare and re-write texts between copies, that is even worser than sending MS Word with revisions across e-mail. That will not help them with IIA and process around them at all. That is not my expectation, that is business expectation of our IROs :-( They promised me to returned that problem to BPO Forum for business decision.

[demilatof]

I discussed that with our IROs and they answered that they cannot imagine to manually compare and re-write texts between copies,

I understand the problem, but we have the original sin, that is the master-master model.
Someone decided to adopt it, and now more than 4.000 HEIs have to manage the technical problems it involves.

In our internal system we have our copy with an editor to modify it; if the partner modifies its copy, our IROs can use the editor to change a few fields or to add/deleting a cooperation conditions. Something they have to do, but not to rewrite everything.
May be you can add a functionality to your system to let your IROs to select the partner's cooperation condition to replicate over your copy.

[umesh-qs]

In my opinion your implementation may not be very compliant with master-master model. If you like, you may use it, but I think that we should not modify EWP to solve this kind of problem. You have a copy, your partner has its copy. You exchange them, and you have to make the two copies similar, editing your own. Personally, I don't like to trust partner's changes and import them in a blind fashion. My IROs look over the partner copy, and then they edit our copy. If you choose to import partner's copy without human activity, you can do, but I'm afraid you can have some issues and not only concerning the contacts. And you could lose control over your internal data.

You might have singe cooperation condition for 2 ISCED, while partner can have 2 cooperation conditions for 2 ISCED. How are you handling that?

@umesh-qs You cannot, not any more at least. I have had to modify our implementation to solve this problem and to adapt our copy to partner's copy. Obviously, we could choose to do nothing and to ask the partner to change its own copy. The crucial points are listed here:

• Both copies of the same IIA stored in both partners' systems must be presented to each other as exactly one IIA having the same number of corresponding cooperation conditions.
• Regardless of whether a field is mandatory in the API, if it is present in the IIA of one HEI it is highly recommended to have it in the matched IIA of the partner HEI.
• Providers are free to implement their local solutions to best support the needs of their customers but under the condition that the general principle expressed in the points above is maintained.

@milsorm The second point suggests that your partner should add the contacts in its copy, but it can write "Mark Twain" whilst you have "Twain Mark" and this can complicate your matching algorithm

@demilatof Oops. This is a surprise. Look like recent update in the specification. But this is done without any discussion with all the stakeholders. I am not sure if everyone is ready with this.
@mkurzydlowski can you please explain this unilateral change? Was it discussed and approved in any of the Infrastructure Forum calls?

[umesh-qs]

In my opinion your implementation may not be very compliant with master-master model. If you like, you may use it, but I think that we should not modify EWP to solve this kind of problem. You have a copy, your partner has its copy. You exchange them, and you have to make the two copies similar, editing your own. Personally, I don't like to trust partner's changes and import them in a blind fashion. My IROs look over the partner copy, and then they edit our copy. If you choose to import partner's copy without human activity, you can do, but I'm afraid you can have some issues and not only concerning the contacts. And you could lose control over your internal data.

I discussed that with our IROs and they answered that they cannot imagine to manually compare and re-write texts between copies, that is even worser than sending MS Word with revisions across e-mail. That will not help them with IIA and process around them at all. That is not my expectation, that is business expectation of our IROs :-( They promised me to returned that problem to BPO Forum for business decision.

@milsorm you may choose to implement in whatever way you choose. But as @demilatof explain you are risking data entered by your clients because of changes done by the partner. The problem of manual comparison only arise when there is a change. And manual check can only limited to what is changed. I guess you are causing more problems for your clients with this approach. Apart from contacts how are you dealing with "isced-clarification" in cooperation condition. This can be different for my copy and your copy

[janinamincer-daszkiewicz]

Topic named 'Parent/child relationship' has been discussed at a couple of IF meetings.
First presented 2022-04-06. This GitHub issue was a place for discussion:
#66
Then discussed on 2022-04-20.
Then this post was added 2022-04-30:
#66 (comment)
Then discussed on 2022-05-04. After the meeting Github issue was closed.

[umesh-qs]

Topic named 'Parent/child relationship' has been discussed at a couple of IF meetings. First presented 2022-04-06. This GitHub issue was a place for discussion: #66 Then discussed on 2022-04-20. Then this post was added 2022-04-30: #66 (comment) Then discussed on 2022-05-04. After the meeting Github issue was closed.

I do not remember any discussion in any infrastructure forum meeting that we voted was regarding same number of cooperation condition. Nor do we remember any voting on not allowing approved IIAs to be modified. Only thing we remember is that there was agreement on 1-to-1 IIA mapping. Please share proof of voting on these points.

[janinamincer-daszkiewicz]

There was a long discussion, all proposals where available in presentations before the meeting and also in GitHub. Specification was shared before being finally approved. I do not see any counterproposals after the post in #66 (comment) (on the contrary, one thumb up). Whatever goes on during the meeting can be traced in chats .

[umesh-qs]

There was a long discussion, all proposals where available in presentations before the meeting and also in GitHub. Specification was shared before being finally approved. I do not see any counterproposals after the post in #66 (comment) (on the contrary, one thumb up). Whatever goes on during the meeting can be traced in chats .

As always, generic reply. Please share the proof or chat as you say that there was agreement on these points.

[janinamincer-daszkiewicz]

Everything is available in the shared drive.

[umesh-qs]

Everything is available in the shared drive.

I didn't find, so I am asking.

[skishk]

I think this proposal to add cooperation conditions ID only because someone is having one copy of IIA and not 2 , one for each partner, it's not compliant so there is no reason to consider this proposal for all the EWP network... i'm sorry but this is only my opinion.

[umesh-qs]

@skishk sorry I didn't understand your point on non compliance. 1-to-1 IIA doesn't means that cooperation conditions should also be 1-to-1.

[kamil-olszewski-uw]

This is also for @kamil-olszewski-uw because we are solving the same situation with USOS in Wroclaw - they receive our contact "Filáčková" but rewrite to their copy "Fláčková" (by mistake because they are doing it manually). And we have disproportion between contacts - we cannot found "Fláčková" but with ID we will have hint that it was our (relatively same named) contact because we can compare it automatically with our older copy. That ID will definitely helps us a lot.

We are aware of the potential advantages of ids of cooperation conditions. However, they would only be useful if they were always fully and unambiguously recognizable on both sides. And this, unfortunately, would be very difficult to achieve in a master-master model. Please notice how much effort is involved in exchanging information about IIA ids and making sure that, for example, the partner has not changed the IIA id (due to incorrect implementation or user's mistake).

As for our specific case of contact data, it is possible to enter these data manually in USOS, but it is also possible (and preferred) to copy them with a few clicks. It's hard for me to say why the user chose the first way. Nevertheless, mistakes like this do happen. In USOS, Dashboard, and other systems I've seen in action, users deal with this by comparing both copies of the IIA.

[skishk]

@skishk sorry I didn't understand your point on non compliance. 1-to-1 IIA doesn't means that cooperation conditions should also be 1-to-1.

He is proposing to add cooperation conditions ID because he can't understand when something is changed in contacts... and this problem he says is because he is working on one shared copy of IIA... so i can understand his problem but i can't understand why if he is working with one IIA copy for both partner must be a network problem if we must work with 2 IIA copies. that is my point. I'm not talking about cooperation conditions because the problem is in the beginning in my opinion.
than the other problem is to compare information that is not required...

[umesh-qs]

@skishk technically @milsorm is not doing anything again the specification. He must still be creating an IIA ID internally.
It is just that he is mapping same copy to both IIA ID.
But, I do agree that it is not a network problem. It is just that comparing will become easier for everyone if there is a unique identifier for each cooperation condition, in cases the cooperation conditions do not match or the sequence has changed

[skishk]

@skishk technically @milsorm is not doing anything again the specification. He must still be creating an IIA ID internally. It is just that he is mapping same copy to both IIA ID. But, I do agree that it is not a network problem. It is just that comparing will become easier for everyone if there is a unique identifier for each cooperation condition, in cases the cooperation conditions do not match or the sequence has changed

I'm sorry but i can't understand the meaning to have cooperation-condition-id, probably my limit.

scenario:
Partner A send IIA A1 with cooperation-condition-ID CCA1 to Partner B.
Partner B send IIA B1 with cooperation-condition-ID CCB1 to partner A.
Cooperation condition not include contacts...

so we are in the condition where we have 2 different cooperation-condition-ID , contacts are not required , so? i can change contacts but not cooperation-condition-ID.

please correct my scenario if you see that i'm not on the point of the problem.

thank you

[umesh-qs]

Topic named 'Parent/child relationship' has been discussed at a couple of IF meetings.
First presented 2022-04-06. This GitHub issue was a place for discussion:
#66
Then discussed on 2022-04-20.
Then this post was added 2022-04-30:
#66 (comment)
Then discussed on 2022-05-04. After the meeting Github issue was closed.

@janinamincer-daszkiewicz Could you explain how we moved in this post from

This issue has been discussed during the Infrastructure Forum on 2022-04-06. Participants voted for the 1:1 logic and matching identifiers.

to

This is the proposal of description which would be added to the IIA specification:

@umesh-qs I've examined the PDFs and chat transcriptions stored on the drive, but I cannot find we have voted something similar, only the 1:1 logic, as recalled at page 14:

Resolved Change approved Generally 1:1 logic and matching identifiers. Proposal of text to be added to specification

But as concern the second part "Proposal of text to be added to specification" I don't remember a discussion on GitHub, neither a detailed representation of the single points. If we read the chat we don't find a poll on this proposal and only a preliminary discussion about point 6 "Regardless of whether or not a field is mandatory in the API, if it is present in the IIA of one HEI it should also be present in the matched IIA of the partner HEI."

Why sometimes we have to vote whilst sometimes we discover later that specifications have been changed without a shared analysis or discussion?

I am struggling to find an answer to this question since years now. But it is far better now. Earlier based on convenience some changes were not allowed by saying that "not many have participated in discussion so they are not interested" and then some changes were pushed saying "there is no objection to the proposal"

[georgschermann]

With the upcoming IIA v7 changes I would also like to push this again to be included.
Introducing an id on the cooporating conditions would help serveral providers in identifying the conditions as stated in different issues like #29 and #66

From our point of view, these condition ids don't need to be mapped to partner conditions, they would just be used to track and visualize if conditions were changed / removed / added, but going with own-id and partner-id could also be useful in some cases.

[demilatof]

From our point of view, these condition ids don't need to be mapped to partner conditions, they would just be used to track and visualize if conditions were changed / removed / added, but going with own-id and partner-id could also be useful in some cases.

I don't see any problem to accomplish this need, we already have an ID for our mobilities.
Hoping that no one changes this ID every time an IIA is fetched

[georgschermann]

@janinamincer-daszkiewicz
can this also be considered for IIAs v7?
This would enable us to automate some of the tedious manual work of comparing IIAs.

[janinamincer-daszkiewicz]

Do you see a good solution for this problem? We spent a lot of time discussing how to map IIAs, mapping CCs would be much more complicated.
If you have a solution which is 100% proof, describe it here.

[demilatof]

Do you see a good solution for this problem? We spent a lot of time discussing how to map IIAs, mapping CCs would be much more complicated.
If you have a solution which is 100% proof, describe it here.

I think that it could enough if we add a mobility ID without mapping.
It could be useful to compare the same mobility from an IIA Get and the next one, not necessary useful to compare my CC and partner's CC.
Anyway, if someone wants to do it, he should know that it is an internal task without warranties.

There is even no warranties that a CC keeps the same CC-ID from a get to another one, but I think it could be a rare case that who wants to use the CC-IDs must accept.

We already have an ID to identify every CC in our database, therefore we have no problem to expose it if this is all we are required to do.

[janinamincer-daszkiewicz]

What do you mean by 'mobility ID' in the context of IIA?

[demilatof]

What do you mean by 'mobility ID' in the context of IIA?

The CC section is made of mobilities; I think that what @georgschermann is asking for is simply an ID for every mobility in the CC.
Therefore, when I say "Mobility ID" I mean the new ID to be introduced inside every mobility.
This new ID should be generated by the owner of the copy of the IIA; partner A always uses its own mob-id for the mobilities in his copy of the IIA, partner B uses a different set of IIAs.
If someone wishes to make a more complex management of mobilities to support his IROs, he can work with these elements; not the best solution, but the one with less impact.
Who are not interested has only to add a mobility ID to his mobilities.

The mob-ID could be an attribute or an element:

            <student-traineeship-mobility-spec>
                <mob-id>STM-123456</mob-id> <!-- ****** NEW ELEMENT ***** -->
                <sending-hei-id>uw.edu.pl</sending-hei-id>
                <sending-ounit-id>140</sending-ounit-id>
                <receiving-hei-id>hibo.no</receiving-hei-id>
                <receiving-academic-year-id>2014/2015</receiving-academic-year-id>
                ....
            </student-traineeship-mobility-spec>

[janinamincer-daszkiewicz]

So I add mobility ids to my copy, I send them to my partner, but partner omits them when making changes to his copy on the basis of my copy? Instead he adds his own mobility-ids? We both take mobility ids into account when calculating has? When I do IIA get, I see my partnner's mobility ids, but not mine.

How does it help?

[demilatof]

So I add mobility ids to my copy, I send them to my partner, but partner omits them when making changes to his copy on the basis of my copy?

My copy is mine, your copy is yours. I don't need to make changes to my copy on the basis of your copy, not always at least.

Instead he adds his own mobility-ids? We both take mobility ids into account when calculating has?

We can decide, there is no problem in taking ids into account when calculating hash.
I compute hash on your copy, with your mob-IDs, and it must be the same hash you have computed on your copy with your mob-IDs.
Where is the problem?

When I do IIA get, I see my partnner's mobility ids, but not mine.

How does it help?

It helps in this way:

1. If I'm not interested in this facility I only have to add my mob-id, I haven't to map anything; my internal system simply ignores your mob-id, I haven't to update my GUI and my controls
2. If I'm interested in this facility, I internally bind my mob-id with your mob-id; when I fetch again your IIA I can individuate your CC as already managed in my system and to my IROs I can represent them side by side with my CC, thanks to my previous mapping. Doing so I can even perform a check element by element to advice my IROs what is changed.

[georgschermann]

I think that what @georgschermann is asking for is simply an ID for every mobility in the CC.

exactly this

If I have your IIA with 4 CCs without ids and I receive a CNR from you and the GET contains 4 CCs with minimal differences, I have no chance in automatically checking the changes.

If I have CCs #1, #2, #3, #4 and pull a new GET from you with CCs #5, #6, #7, #8 I know these are unrelated, if I receive #1 with changed numbers, #2 with changed ISCED code, #5, #6, I know exactly which CCs have changed, which are new, which are deleted, etc.

they can be included in hash calculation or excluded doesn't matter, there should be no case where the CC is byte-identical with a different id, except when the user/system messed up pretty hard

The only requirement to the ids is that they don't change for the same CC.

[janinamincer-daszkiewicz]

Should they be optional or mandatory?
Should/could they be added to already approved IIAs?

[demilatof]

Should they be optional or mandatory?

I think they should be mandatory, otherwise they could lose importance and personally I wouldn't implement any automatism if I suspect that it could be useful only for a few providers. I don't know what could think @georgschermann about this.

Should/could they be added to already approved IIAs?

I think that it is not necessary, because until now nobody could have mapped them without an ID.
So, until they will not be used again for a new approval process, they can stay as they are.

If they have to be mandatory, we may have to consider what could happen to the hash code:

• If the mobility IDs will not be considered to compute the hash code, there is no problem.
• If the mobility IDs will be considered to compute the hash code we will have the same problem as for the mobilities-per-year, and we can solve in the same way if we will use XSLT

[janinamincer-daszkiewicz]

@georgschermann I still do not see fully your proposal, please help to elaborate.

Let's assume that mobility-ids are mandatory. Partner A adds mobility-ids to his copy and when partner B calls IIA-get he has to store them in his system to make them available for A when A calls IIA get which means that some mapping is necessary on the B's side.

Making mobility-ids mandatory means extra work for all partners, some may not be happy and will vote against.
Making them optional means that some will not implement and every implementation will have to cover both cases.

[georgschermann]

The ids need be mandatory, they should be very easy to add and maintain.

They need to be added to all existing / approved IIAs (this is debatable), hashes will change anyway once with new version, after that they can be ignored or included in hash generation - it shouldn't matter, since they only may change when the content of the CCs changes. If using XSLT or other transformations for hash calculation I would remove them for calculation, just to be on the safe side.

They are not meant to be matched at all, they don't need to be the same id for the same CC in both IIA versions, they can be the same but they don't need to be. If partner A uses UUIDs and partner B uses numeric ids and Partner C uses cc-sub-hashes(*) and partner D uses natural keys(*), thats perfectly fine, the only requirement is that they don't change for the same CC on one partners version of the IIA. (*) for those the implementation would need to make sure that they don't change when normal changes to the CC are made.

Partner A releases IIA A1:

       <cooperation-conditions>
            <student-studies-mobility-spec id="1" />
            <student-studies-mobility-spec id="2" />
        </cooperation-conditions>

partner B imports it as B1:

       <cooperation-conditions>
            <student-studies-mobility-spec id="7f26228f-3384-4c4a-8690-38122accc173" />
            <student-studies-mobility-spec id="abad792f-3fca-41a0-a8a5-15a25c183b8e" />
        </cooperation-conditions>

Partner A updates numbers on A1, ids stay the same on both sides.

Partner A removes one CC and adds a new one:

       <cooperation-conditions>
            <student-studies-mobility-spec id="1" />
            <student-studies-mobility-spec id="3" />
        </cooperation-conditions>

Partner B updates his version of B1:

       <cooperation-conditions>
            <student-studies-mobility-spec id="7f26228f-3384-4c4a-8690-38122accc173" />
            <student-studies-mobility-spec id="ae78b29b-b6c1-4053-b006-e365c785c311" />
        </cooperation-conditions>

This lets providers choose the most simple implementation in their system, maybe they already have some sort of ids, maybe they can generate ids on the fly based on the content like hashing or building a natural key or the like.

Providers which want to add mappings on CC level can do, those who don't want to don't need to.

Providers may have a different interpretation of what is a change to a CC and what is a new CC, This is OK to some extend, providers should keep in mind that abusing this (every change results in new id) may complicate exchange for their partners and also maybe for them in the long run, but for some it may be reasonable to have a new ID if e.g. the isced or ounit changes.

[janinamincer-daszkiewicz]

I am not sure I follow. When B gets A1 from A, he ignores ids of A (1, 3) and puts his own? So when A get B1 from B he will not find there his ids, but will find (7f26228f-3384-4c4a-8690-38122accc173, ae78b29b-b6c1-4053-b006-e365c785c311)?

[georgschermann]

exactly, he MAY ignore them, he may re-use them for his own CCs

[janinamincer-daszkiewicz]

How will this help A in comparing A1 with B1?

[georgschermann]

How will this help A in comparing A1 with B1?

It won't, but it will help after that to keep track of changes.
Mapped CC-ids would be definitely a plus, but could drastically increase the implementation effort needed, so we didn't propose it in favor of boader acceptence.
We could add this as a voting option:

• mapped cc-ids
• non-mapped cc-ids
• no cc-ids

[janinamincer-daszkiewicz]

Georg, if the added value is so small I suspect that providers will not be interested in this proposal.
If you really think you can convince them, then prepare the voting options in full, with the reasoning and arguments.

[georgschermann]

@umesh-qs @milsorm could you please comment on my proposal if this is still relevant for you before I prepare voting options, also if you require/prefer mapped ids or are fine with non-mapped ones.

[demilatof]

Georg, if the added value is so small I suspect that providers will not be interested in this proposal.

What is the effort of adding a mobility ID that we already have to our iia get response?
He's asking nothing more and can be useful to everyone to facilitate IROs, if needed.

Do you know how much providers don't have yet an ID to identify their mobilities in their DB tables?

[janinamincer-daszkiewicz]

Do you know how much providers don't have yet an ID to identify their mobilities in their DB tables?

All have, but sharing them in IIAs means changing software. Not much but still. Also their is still a problem with the hash - how to handle it.

[georgschermann]

Also their is still a problem with the hash - how to handle it.

hashes will change anyway once with new version, after that they can be ignored or included in hash generation - it shouldn't matter, since they only may change when the content of the CCs changes

Am I missing something with my reasoning?

[janinamincer-daszkiewicz]

We do not yet have a solution to hash changes which would allow us to avoid re-approval. I am not as optimistic as Jiri that providers do not care and can handle re-approval automatically.

[georgschermann]

Yes, but this has nothing to do with cc-ids.
The hash will change with the new iia version, with or without cc-ids.
The hash should not change after that without substantial changes to cooperating conditions, with or without cc-ids.

[demilatof]

All have, but sharing them in IIAs means changing software. Not much but still. Also their is still a problem with the hash - how to handle it.

If we stay with version 6, I could understand your doubts.
But since we are moving to version 7, this is not a problem, not even as concern the hash code (once we decide how to handle it, we can do the same for the mobility IDs)

Yes, but this has nothing to do with cc-ids.
The hash will change with the new iia version, with or without cc-ids.
The hash should not change after that without substantial changes to cooperating conditions, with or without cc-ids.

Exactly

[janinamincer-daszkiewicz]

No problems, great.
Please prepare the description which could be voted.

[georgschermann]

We want to be able to track changes to CCs across different versions of an IIA and map them to our own CCs.
Option 1 allows to map CCs and track their changes
Option 2 allows for tracking changes across versions, should be easy to implement for all.
With Option 3 in some cases it is not possible to check which ccs were changed / added / deleted.

We propose 3 options:

1 - add id attribute to all child elements of coopeating-conditions, the id needs to be unique within all partners versions of this IIA and be kept the same across changes of this CC, New IDs only appear for new CCs, deleted IDs for deleted CCs are not re-used. When a partner maps/updates his IIA version to a partner IIA he also needs to map and use all existing CC-ids.

2 - add id attribute to all child elements of coopeating-conditions, the id needs to be unique within their parent element and be kept the same across changes of this CC, New IDs only appear for new CCs, deleted IDs for deleted CCs are not re-used. The ids don't need to be mapped or used in any way.

3 - don't add cooperating-condition ids