-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IIA version change impact on cooperation conditions hash #109
Comments
I think that your question may involve three issues:
But I think that we should realize that the hash code is a useless computation. |
This is not true. Hash will change if the major version changes. Timing of implementation has no impact.
Last approved version can be retrieved from local backup as well, if backups are kept. Problem here is, how would such agreements be show to IROs, so that they don't have to spend time on them.
Agree. Hash should be just considered as version id. IIA approval should be reset based on the change in the content of the cooperation condition. |
Yes, hash changes if the major version changes; but if I'm with 7.0 and you still with 6.0, how do we exchange data?
This is true if we save both of the backups; our version and partner's version. |
We would like to propose serving a snapshot of partner's IIA in the IIA Approval API. That way version changes won't affect the approval. IIA version update would change the hash in the IIA get response but this would not affect what has already been approved. |
I repeat here some considerations I've already made in the other issue because this should be a more appropriate thread to discuss about the consequences of the namespace upgrade.
Could you provide an example? The question to understand your proposal is: why I have to re-approve the IIA if the hash code changes due to namespace version upgrade? I think, as you if I remember well, that what could rule the need of an approval is the partner will: if he sends us an IIA CNR, we can suppose that he needs a new approval (may even be he doesn't need it, of course). This is not the perfect solution, I know: the partner may send us an IIA CNR even if he doesn't need a new approval. We should catch the opportunity of the next namespace upgrade to add all the elements may help us for a better management. |
I think that the |
Do you mean the |
Exactly. |
I'm trying to make EWP Network more stable asking for something that could fix the problem for missing IIA CNRs, and you tell me that you "think that the modified_since parameter of IIA index should be enough"?
This means that the server SHOULD and not MUST filter; "modified after" in our implementation (and not only in our implementation, I think) means every modification, even those we don't need to communicate immediately to the partner because we want to give to the IRO a small amount of time to avoid mistakes.
So it is not much useful...
Again, if this may happen, the parameter it is useless
INDEX and GET are useful for the synchronization, but we cannot substitute the IIA-CNR thanks to this parameter. |
We are looking for the simplest possible solution which would allow us to avoid any automatic triggering of re-approval after the change of the name space in IIA (version change from 6.2.0 to 7.0.0) due to changes we plan for the current window. We have some flexibility in choosing the final solution for IIA negotiate/approve/terminate/modify/delete, but the general guidelines are the following:
I will post here the more elaborated proposal, trying to take into account recent discussion in GitHub and Thessaloniki. |
I noticed discussing with @mkurzydlowski that we all agree that presently there is the risk of an automatic triggering of re-approval after the change of the name space in IIA. |
If the content is same and only change is in the namespace then it is not complicated to handle it. |
But how? Field by field? And in which order? |
You define a object and populate that with the data. Then compare the object. It will work with full warranty :) as long as the sequence is not changed |
Maybe it works, even if I had a bad experienced in the past using that system in Java (I've had to implement an algorithm that collects all fields in a given order). But what are the two versions you try to compare? Your snapshot and the one fetched again from the partner? |
If the new fields are part of hash calculation then there is a problem. In that case there either we have separate logic for each version or reset the approval. |
This is out of the question. We have to find a solution where re-approval is not needed. I will describe this proposal it in more detail later today or tomorrow. |
so you are saying that even if the hash logic has changed to include new fields, old approvals will remain intact even if the old IIA has new data in it? |
It depends on a specific case. The timestamp would allow us to decide when we have real changes and when only 'technical' changes. Name space is such a technical change. No need to approve again IIA which differs from the approved one only in a name space. |
Ok. Will wait for the timestamp proposal before further comments |
A timestamp of what?
Doing so, if the partner for whatever reason (valid or not) ask us for a new approval, we can give him a new approval, switching to the new namespace version. If there is no request (IIA CNR), we have nothing to do. |
Timestamp of a last business change in IIA. |
This may require a shared definition of "last business change in IIA". May be that the solution is the set of fields computed in the hash code, but I think we have to investigate on what providers have to modify. |
Yes, it may be intuitive, but difficult to define in such a way that everybody will understand this the same way. Anyway, we need a method of saying that there are some cases when the change of hash does not mean a (business) change in IIA (only change in its format) and need not trigger an action on the partner side (like re-approval or even comparing the new object with the old object).
We will have (at least) these changes in this round:
|
How is it different when it comes to implementation, when compared with to having different logic for each version (v6 vs v7)? |
I am not sure I understand your question. Moving from version 6.2.0 to version 7.0.0 will not change logic of already approved IIAs. These is what we care about. We need a solution that will allow us to automatically recognize between two situations:
|
Yes I get the problem. My question was, how is the solution you are proposing different from what I have proposed in terms of implementation? |
Can you link to this proposal? |
This is what I have proposed which you just rejected. In any solution you will have to add a special logic in the implementation. |
My typo; 077 is a valid value for v6, but doesn't exist.
You could give the advice, but it's outside of the XSLT scope.
There is no warranty in any way without a constraint list in the XSD. And, in any case, have you decided what we have to do for the approval? If we don't know what you choose, we cannot propose any valid strategy. |
I agree. Although saying in the specifiation that the value should be a proper dictionary value is not just an advice, the partner should reject the value which is not compliant. Yes, it may happen that due to an error v6 value may not be from dictionary, also v7 value with 4-digit may not be from dictionary but these are errors which should be rejected by the partners.
We do both, at least this is my goal. Providers may ask, we should not tell them to pad with zeroes.
Michał will answer. |
That is still needed when both partner's upgrade to version 7 and they want to algorithmically check that the other side responds with a previously approved version.
This is only valid during the upgrade window and enables the side that is not yet upgraded to still read the old-style hash approved. But we should ask if this is something that is needed. Maybe this compatibility issue that occurs during transition period isn't something we should be tackling? This seems to be a business decision. |
The fact that we are discussing about invalid v6 ISCED codes means that what you think that should happen, in the real world doesn't happen.
Of course, but the only answer is that we need a four digit code. They have few options:
ok |
So it's still useless suggesting any algorithm here to patch the real ISCED code, because both of the partners should have to implement the same strategy and anyway we need to compare only the old ISCED value, not the new one.
But we haven't an upgrade window, because it was said that there will be places for only one API version per HEI. We need a clear address about the road map to v7 |
There will be one week for the upgrade.
It is ready and will be send to providers by DG EAC (probably on the 1st of August). |
One week to test a new version!! really? |
For a week of overlapping, doesn't worth discussing about managing v6 IIA approval.
So you already know if we will have one or two versions at the same time in the registry? |
Could someone explain why it's not possible have one or two versions at the same time in the registry? What is the problem? |
Testing will be done in DEV network and there will be more time for that. |
I'm sorry but if I remember correctly You told that the DEV network would have been only for the 6 version . |
During the infrastructure forum it was said something different, v6 in DEV, v7 in PROD. |
As to my knowledge each providers has at least one installation in DEV. Most 3rd party providers have more the one. Anybody who wants to be accepted to PROD should first test in DEV, according to 'How to join' procedure. |
For IIAs We make test and exchange data with institutions, not providers. Do you say I need to create a new fake HEI, e.g. unige2.it and a fork of my my program, to be in the same DEV environment with two different versions? |
The Dashboard has only 3 accounts in DEV, as I remember.
This is why we always encourage to use real but anonymised data, as we (MUCI) do in our installations in DEV. PROD is not for testing. |
Please review changes to ISCED field description: |
I also attach changes to XSLT: |
most of them are not working... |
I know, but please explain how do you think to have DEV with only one version that is both 1.6.3 and 1.7.0 at the same time. |
many of those that work do not display data, or display 3 or 4 elements, often not formally valid |
From DG EAC: We have checked and confirm that the field of education list in the BM Data dictionary is aligned with the UNESCO list. It seems to us that providing the link to UNESCO is easier to access and more stable for developers as a reference to enforce the mandatory use of 4 digit ISCED codes. |
And I tell you that they should check better, as I did months ago (one by one).
I leave you and DG EAC the fun of finding the other eight ISCED codes that are in the UNESCO list and not in the BM Dictionary. |
There is one more thing we need to change in the XSLT. The Changes the order of elements and XSLT would not work without further changes... |
I must also add an important disclaimer. After we introduce the XSLT template we run into an important issue. If for some reason we decide to improve the template then we are required to change the API major version. Otherwise people would use different templates. Before the XSLT we would only change the major number if there are incompatibilities in the XML structure. |
This is the updated branch with the |
As you have probably seen, the XSLT can work with not-yet-attribute wherever you want without the need to be changed.
This is a choice you made and that complicate the structure uselessly, therefore is up to you finding the proper solution for the XSLT.
What do you mean with this disclaimer? |
I thank you for your consideration, I'm happy to have suggested some possible solution to address the problem, but I think we all need to come back to our respective role. We other developers have little if nothing knowledge of relevant information about the decisions and the future of the version 7, we cannot spend more time than this in finding a solution that the day after needs to be changed because the DG EAC decided something different that we didn't know even that it was discussing about. And even the problem of the versioning prevents us to give a useful contribution that is not a waste of time.
Therefore, personally, I'll return to examine what specifications we will have to comply in our further developments only when they will be officially released with the description of the solution to switch from a version to another with or without keeping both of them, at the same time, in the same registry. I hope that the final conclusion obtained in Thessaloniki, the famous strict and simple rules, has not been already abandoned in the name of the flexibility aimed by the DG EAC and by the solutions of writing XSD with recommendation and not formal declaration. Therefore, I'm ready to return in a world where the DG EAC keeps on doing the product owner and you implement their requirements, later the BPOs and us (technicians/providers) will examine what will be the final result of your efforts and if it will be compatible with our IROs work from an administrative and technical point of view. I wish you a good job, see you later, after at least an alpha v7 version will be published, hoping not too late to be ready for the next month of march. |
@demilatof, adding extensions in subtypes like |
I propose using XSD |
As we already know IIA major version change impacts the cooperation conditions hash, as it changes the XML namespace that is part of the cooperation conditions XML element being hashed. So even if a IIA version change doesn't impact the fields in this element, the hash changes.
Let's discuss how this case should be handled and what impact this has.
Should the cooperation conditions hash change after version change or should it be stored and stable until IIA changes?
If we choose to recalculate hashes then should we send CNRs?
If the partner chooses to recalculate hashes, should we recalculate IIA approvals?
The text was updated successfully, but these errors were encountered: