search

erasmus-without-paper / ewp-specs-api-omobility-las

Learning Agreements
MIT License
1 stars 2 forks source link

Semantics of the presence/absence of the <changes-proposal> element #26

Closed jiripetrzelka closed 3 years ago

jiripetrzelka commented 3 years ago

Are server implementers allowed to keep the changes-proposal published in the GET endpoint after it has been commented on by the receiving party? The commented proposal would contain the section with host signature. The semantics would be: Sending party is in the process of deciding what to do next with the declined proposal. I see that according to https://github.com/erasmus-without-paper/ewp-specs-api-omobility-las/blob/stable-v1/examples/ola-dashboard-example-scenarios/src/xml/Ex6.xml the changes-proposal should not be included once the stance of the host party is clear. However, according to https://github.com/erasmus-without-paper/ewp-specs-api-omobility-las/blob/cff3fa39452eade0a7262a59da2f3c2b19ab1a10/endpoints/get-response.xsd#L197 - the changes-proposal MUST be provided if the first-version element is not provided. So this is all somewhat confusing. Does the changes-proposal element serve primarily to reflect the current state of the LA, or is its presence primarily intended to be an indication to host party that an action is required from them? From the following comment I assume that there may exist states in which changes-proposal is present and contains the receiving-hei-signature element: https://github.com/erasmus-without-paper/ewp-specs-api-omobility-las/blob/cff3fa39452eade0a7262a59da2f3c2b19ab1a10/endpoints/get-response.xsd#L590 However, from the dashboard scenarios, it seems to me that changes-proposal may actually never contain the receiving-hei-signature element.

kamil-olszewski-uw commented 3 years ago

We already asked the colleagues responsible for the examples for a correction, because Ex. 6 shows a situation that, according to the get response specification, should not have happened.

"If this element is not provided than you MUST providechanges-proposal"means that LA cannot be transferred through EWP without any set of components. So if the changes proposal of the FIRST version is rejected by receiving HEI and therefore sending HEI withdraws this proposal, LA disappears from EWP until a new proposal is made. if the changes proposal of the LATER version is rejected by receiving HEI and therefore sending HEI withdraws this proposal, LA is transferred by EWP without any proposal until a new proposal is made.

Technically, recently rejected changes proposal MAY be present in get response, but only until rejection is handled by the system/coordinator of the sending HEI.

There will never be a signature of the receiving coordinator in changes proposal.

jiripetrzelka commented 3 years ago

Ok, just to confirm that I understand it right:

kamil-olszewski-uw commented 3 years ago

If server implementers decide to keep the rejected proposal in the GET response until decision of the sending party is made then its contents is exactly the same as it was before the rejection and it is up to the client to understand it - i.e. keep its own record of the rejected proposal id.

Right. But it should be noted here that at this time sending HEI has no reason to send a CNR for that LA, so it will not get special attention of receiving HEI. But then hiding a rejected proposal should result in CNR.

If the proposal represents the first version and it is rejected, it may also be kept in the GET response until sending party decides what to do next, but eventually, if no other proposal is created, it will disappear from the GET and INDEX endpoint as well.

Right. And then LA may reappear if there is a new changes proposal. In practice, such a temporary disappearance of LA after the rejection of the first version is likely to occur almost always, because from the moment of processing the rejected proposal in sending HEI's system to the development and publication of a new proposal some time must pass.