Termination as a whole and the not-yet-defined attribute

[jiripetrzelka]

Consider the following sequence of actions:

• IIA is mutually approved in version 6.
• Language requirements for SMS and/or STA are missing.
• Partners switch to version 7.
• Partners want to terminate the IIA as a whole.

Are IROs required to specify the language requirements before terminating the IIA?

According to https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/b2153a6c0d0824590571452d7acc5c1dc4632ffc/endpoints/get-response.xsd#L726-L737 the not-yet-defined attribute MUST NOT be used in case the IIA has been modified since the switch to version 7. And termination is a kind of modification. But what sense does it make to tell IROs that they have to decide on the language requirements they would have required in case the IIA had been valid before they can terminate it as a whole? Or are implementers expected to just come up with some random value, like English B1 or English B2, to satisfy the specification while expecting that the other partner will ignore it? I would rather prefer to treat termination as a whole as a special case which would allow to keep the not-yet-defined attribute. It would better reflect the reality what what was mutually approved.

[demilatof]

The problem may occur later, if you decide to undo the terminate as a whole the IIA. In this case you need a new approval, and if we decide to skip the control for terminating-as-a-whole you will have an IIA approved under v7 filled with not-yet-defined attributes, that is forbidden, because under v7 is mandatory to approve only IIA that satisfy the new requirements.

Therefore in my opinion, even if it would complicate the model, it could be correct to allow the termination-as-a-whole with not-yet-defined elements, but not to reactivate the IIA later.

[janinamincer-daszkiewicz]

Specification does not allow us under IIA version 7 to approve IIA which is not compliant with version 7. Which means that terminated IIA should have all mandatory values properly filled otherwise we will not be able to approve termination. Hopefully such situations will be very rare in real life.

[demilatof]

Specification does not allow us under IIA version 7 to approve IIA which is not compliant with version 7. Which means that terminated IIA should have all mandatory values properly filled otherwise we will not be able to approve termination. Hopefully such situations will be very rare in real life.

I understand, but I think that the reason for this requirement is to not spread IIAs that have not all the mandatory values. In this case, instead they are interested in an IIA that should end without producing any effect, so I understand their needs.

My proposal:

1. Changing the documentation in the XSD adding at the end, after otherwise: "except for terminated-as-a-whole=true"

https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/b2153a6c0d0824590571452d7acc5c1dc4632ffc/endpoints/get-response.xsd#L726-L737

2. Changing the XSLT to include the following fragment https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/b2153a6c0d0824590571452d7acc5c1dc4632ffc/resources/xsltKit/transform_version_7.xsl#L105-L111

inside an "if" clause

<xsl:if test="string-length(ewp:dumpTerminated(//*[local-name()='cooperation-conditions']/@*[local-name()='terminated-as-a-whole']))=0">
...
</xsl:if>

doing so, the XSLT declares the IIA not valid for approval only if there are not-yet-defined attributes AND terminated-as-a-whole is absent or not true. This means that if someone removes terminated-as-a-whole attribute later, the IIA could not be approved (and reactivated) if there are still some not-yet-defined attributes

[janinamincer-daszkiewicz]

I understand your proposal and the intention which lays behind but the use case is so rare that it does not justify changing the specification a month before the final deadline and after there are already testing sessions under 7.0 successfully concluded.

[demilatof]

I understand your proposal and the intention which lays behind but the use case is so rare that it does not justify changing the specification a month before the final deadline and after there are already testing sessions under 7.0 successfully concluded.

Ok for the deadline, but I think that the above proposal could be introduced even later without the need for a new version, since it doesn't affect the IIA hash code computation or other task, except the termination as a whole for an IIA approved under v6 and terminated under v7.