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

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

The death of version 7 #117

Closed demilatof closed 1 year ago

demilatof commented 1 year ago

After the Infrastructure Forum, where I've received a non conclusive answer to my question:

Could you kindly remind me why we have to move to version 7?

I'm going to suppose that:

  1. DG EAC asked for new constraints on template
  2. DG EAC was represented (by whom?) that these constraints involve a new IIA version
  3. DG EAC started asking for a new IIA version as synonymous of their new requirements
  4. DG EAC didn't realized that the new IIA version is required only if we change elements from minOccurs="0" to minOccurs="1" or if we add new elements in cooperation conditions that we could not avoid anyway

Now, after more than a year we are still struggling with the issues to move to version 7 because of this (may 2022):

mobilities mandatory

But today we discovered that what was clearly represented as mandatory via formal specification and not via description, is no more mandatory, because @janinamincer-daszkiewicz don't like technical solution and find more natural, as habits ("de gustibus non est disputandum"), to describe a rule than formalizing it. So we will have, most probably mobilities non mandatory

At this point I have wasted almost a year (and not only me) finding solutions, writing and discussing issues, coding example to solve a problem that does not exist and that we could have solved months ago if @janinamincer-daszkiewicz had represented that what is asked as mandatory by DG EAC would be mandatory only at the description level in the IIA XSD.

Because if all the new mandatory fields are such only by description, we don't need anymore a new IIA Ver.7. I've heard examples as the pdf or the pdf-file, but they are out of the cooperation conditions and they are already optional:

<xs:element name="pdf" type="xs:base64Binary" minOccurs="0" maxOccurs="1

For them, it is just enough writing in the description "don't use this one for new IIAs" and "use this one for new IIAs". The academic years have not been a problem until now, just keep them and adding the description that the providers will consider only the first one and the last one, ignoring any holes. Thanks to descriptions we solved all the problems, we don't need an XSLT, but what is more important we don't need a Version 7, we can always stay with Version 6 and at the same time we fulfill the requests of DG EAC. The version 7 is dead under the descriptions, long life to version 6!
umesh-qs commented 1 year ago

After the Infrastructure Forum, where I've received a non conclusive answer to my question:

Could you kindly remind me why we have to move to version 7?

I'm going to suppose that:

  1. DG EAC asked for new constraints on template
  2. DG EAC was represented (by whom?) that these constraints involve a new IIA version
  3. DG EAC started asking for a new IIA version as synonymous of their new requirements
  4. DG EAC didn't realized that the new IIA version is required only if we change elements from minOccurs="0" to minOccurs="1" or if we add new elements in cooperation conditions that we could not avoid anyway

Now, after more than a year we are still struggling with the issues to move to version 7 because of this (may 2022):

mobilities mandatory

But today we discovered that what was clearly represented as mandatory via formal specification and not via description, is no more mandatory, because @janinamincer-daszkiewicz don't like technical solution and find more natural, as habits ("de gustibus non est disputandum"), to describe a rule than formalizing it. So we will have, most probably mobilities non mandatory

At this point I have wasted almost a year (and not only me) finding solutions, writing and discussing issues, coding example to solve a problem that does not exist and that we could have solved months ago if @janinamincer-daszkiewicz had represented that what is asked as mandatory by DG EAC would be mandatory only at the description level in the IIA XSD.

Because if all the new mandatory fields are such only by description, we don't need anymore a new IIA Ver.7. I've heard examples as the pdf or the pdf-file, but they are out of the cooperation conditions and they are already optional:

<xs:element name="pdf" type="xs:base64Binary" minOccurs="0" maxOccurs="1

For them, it is just enough writing in the description "don't use this one for new IIAs" and "use this one for new IIAs". The academic years have not been a problem until now, just keep them and adding the description that the providers will consider only the first one and the last one, ignoring any holes.

Thanks to descriptions we solved all the problems, we don't need an XSLT, but what is more important we don't need a Version 7, we can always stay with Version 6 and at the same time we fulfill the requests of DG EAC.

The version 7 is dead under the descriptions, long life to version 6!

Looks like you are right. If everything can be managed using description why do we ever need to switch to a new version.

demilatof commented 1 year ago

Looks like you are right. If everything can be managed using description why do we ever need to switch to a new version.

I've been inspired by your observation in chat and I realized that you were right, damn right 😉

umesh-qs commented 1 year ago

@janinamincer-daszkiewicz to the question of adding IIA ID inside cooperation condition, you mentioned in the IF meeting that as soon as IIA ID is added inside cooperation condition, IIAs need to be re-approved? Just confirming, or you meant something else.

demilatof commented 1 year ago

@janinamincer-daszkiewicz to the question of adding IIA ID inside cooperation condition, you mentioned in the IF meeting that as soon as IIA ID is added inside cooperation condition, IIAs need to be re-approved? Just confirming, or you meant something else.

@umesh-qs This is something that she decided, because she likes to have the IIA IDs in cooperation conditions in order to compute them in the hash. Doing so she can state that this is a thing that needs a global re-approval (and, I add, a version change). In other words, this approach represents as problematic the inclusion of IIA IDs in the condition hash.

Instead, as I already said and proven [here], (https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/109#issuecomment-1593875245) thanks to the XSLT we can consider the IIA-IDs in the hash code but leave them in their place:

The transformation can manage the different formats for the academic year and the problem of the new mandatory elements in v7; it even considers the two IIA IDs

`

      </xsl:for-each>

`

where dumpElement is a function that write the value between two underscore characters at the beginning of the text to be hashed.

pargentieri commented 1 year ago

After the Infrastructure Forum, where I've received a non conclusive answer to my question:

Could you kindly remind me why we have to move to version 7?

I'm going to suppose that:

  1. DG EAC asked for new constraints on template
  2. DG EAC was represented (by whom?) that these constraints involve a new IIA version
  3. DG EAC started asking for a new IIA version as synonymous of their new requirements
  4. DG EAC didn't realized that the new IIA version is required only if we change elements from minOccurs="0" to minOccurs="1" or if we add new elements in cooperation conditions that we could not avoid anyway

Now, after more than a year we are still struggling with the issues to move to version 7 because of this (may 2022):

mobilities mandatory

But today we discovered that what was clearly represented as mandatory via formal specification and not via description, is no more mandatory, because @janinamincer-daszkiewicz don't like technical solution and find more natural, as habits ("de gustibus non est disputandum"), to describe a rule than formalizing it. So we will have, most probably mobilities non mandatory

At this point I have wasted almost a year (and not only me) finding solutions, writing and discussing issues, coding example to solve a problem that does not exist and that we could have solved months ago if @janinamincer-daszkiewicz had represented that what is asked as mandatory by DG EAC would be mandatory only at the description level in the IIA XSD.

Because if all the new mandatory fields are such only by description, we don't need anymore a new IIA Ver.7. I've heard examples as the pdf or the pdf-file, but they are out of the cooperation conditions and they are already optional:

<xs:element name="pdf" type="xs:base64Binary" minOccurs="0" maxOccurs="1

For them, it is just enough writing in the description "don't use this one for new IIAs" and "use this one for new IIAs". The academic years have not been a problem until now, just keep them and adding the description that the providers will consider only the first one and the last one, ignoring any holes.

Thanks to descriptions we solved all the problems, we don't need an XSLT, but what is more important we don't need a Version 7, we can always stay with Version 6 and at the same time we fulfill the requests of DG EAC.

The version 7 is dead under the descriptions, long life to version 6!

Hi, are there any news about this?

janinamincer-daszkiewicz commented 1 year ago

We are preparing version 6.3.0 and version 7.0.0. Everything will be explained at the next Infrastructure Forum meeting on 19 July.

demilatof commented 1 year ago

We are not in the same boat, definitely