Redundant start-year-month and end-year-month in get-response

[j-be]

The two fields start-date and end-date carrying the same (and more, as it is a full date) information. Having all of them optional also introduces possibility of weird combinations, like having only start-date and end-year-month. This needlessly makes client implementations more complex with extensive if (...) then else for all 4 cases (none, one, other, both) for either of the fields.

If the 2 actually carry different information it needs to be documented what these differences are.

[kamil-olszewski-uw]

Please read the annotations for these four date-related fields. Those contain information that both date pairs are used for different types of mobility. Annotations are an integral part of the specification and the guidelines contained therein should be followed.

Instead of the current solution, we considered creating separate fields for the year + month and day of the month. But we found that for full dates it would be better to operate on common XML types than to force systems to parse and merge the date based on two elements.

[j-be]

I see how my report is misleading. Please allow me to clarify:

<xs:element name="start-year-month" type="xs:gYearMonth" minOccurs="0" maxOccurs="1"> and
<xs:element name="start-date" type="xs:date" minOccurs="0" maxOccurs="1">

are both described as

                <xs:annotation>
                    <xs:documentation>
                        Planned start ${dateFormat} of the mobility (when the student is supposed to arrive).

                        Note: This field MUST be provided only for ${someType} mobilities
                        and MUST NOT be provided for ${otherType} mobility types.
                    </xs:documentation>
                </xs:annotation>

The same applies to end-date and end-year-month.

EDIT: This was garbage, the rest still applies.

From my understanding, duplicating the start and end date from mobility API here serves one purpose only, and that is to determine whether is to late or not to approve. So for deciding on:

• firstVersion I need start (from spec I must not change firstVersion after mobility began)
• changesProposal I need end (or am I allowed to approve changes after the fact?)

For both I would think that:

• either both of them are defined as "MUST be first of the month" or "MUST be last of the month", else
• I need the full date to make any informed decision

In either case, I will need only one of them to make a decision - I fail to think of a scenario where having both date and year-month makes sense.

EDIT: Changed documentation to further clarify.

[kamil-olszewski-uw]

These dates are part of the template required by the EC. While from a business point of view, new la versions should not be created after certain dates, the dates sent in the LA API should be treated as an indication for the mobility coordinator, and not as strict boundaries on which IF instructions could be based in the application code. For example, it cannot be that you cannot create a new version of LA retrospectively just because the creation of a new version has been neglected at some point.

Do not think of these dates as a duplicate from the Outgoing Mobilities API. Each university decides which EWP API will implement in its system. It is possible to implement the LA API without implementing the Outgoing Mobilities API.

[j-be]

Forgot to mention: if this is just there, because it is part of the PDF: I don't see why that would be a reason to send it over the wire. The PDF would be created by sending institution anyway, and that already has the date, so I don't see that as a use-case.

The date is not part of the approved portion of the LA (i.e. I can change these dates without nullifying any existing approval, right?)

For this API, receiving institution should be only interested in "is there something to approve? if so, am I in time to do so?" and for the latter decision it needs a date to show to the user a "sorry, you're to late" or an approve button.

[j-be]

Do not think of these dates as a duplicate from the Outgoing Mobilities API

Sure, but if both APIs are implemented, the dates should match, right?

part of the template required by the EC

So are we exposing data here, which is not even meant to be read by the other side?

[j-be]

indication for the mobility coordinator

As the student is already nominated, and the nomination has been approved, receiving hei already has that information, right?

And after reading through your comment very carefully once again:

not as strict boundaries on which IF instructions could be based in the application code

This confuses me...

I thought: What sense does it make to have a firstVersion at a random point in time? None. E.g. "we have a firstVersion in January, we all approved changes in February, mobility starts in March" makes no sense. As soon as "we agree on changes in April" comes in we cannot even reconstruct Table A and Table B in the PDF, i.e. firstVersion is January, latestApproval is April. The approved version valid right at mobility start is lost.

So it must be firstVersion is "the version that is the one we all agreed on before mobility starts (i.e. Table A and Table B in the PDF) and is (or was) valid right at mobility start". Once mobility started, that thing won't change anymore. So in order to decide what it is I need date boundaries.

Are you now telling me, that every single piece of information in this whole API, including firstVersion, needs to be changeable for all time to come?

[j-be]

I'm more and more confused about this.

These dates are part of the template required by the EC

Which template are we even talking about? If you refer to https://wiki.uni-foundation.eu/display/EWP/New+LA+template I only see

Nowhere does it state, that day is required for some types and forbidden for others, as the current version of the XSD states.

The "guidelines" document only refers to start and end in regards to the Transcript of Record, which is an entirely different API and hence out-of-scope here anyways.

If you have an additional source, could you please state it somewhere, or add it to the repository, as was the old one on master branch?

EDIT: And it just pops my eyes right now - above screenshot: Estimated duration (to be confirmed by the Receiving Institution) - that does not at all sound like "dates sent in the LA API should be treated as an indication for the mobility coordinator" to me.

EDIT 2: What would even be the proposed mechanism for to be confirmed by the Receiving Institution? This indicates a change of one of these dates would bring the need for re-apporving everything? But there is no way to code that into changes-proposal - so how would that go?

[j-be]

ddeff52 solves part of my questions

Only thing remaining: how would Estimated duration (to be confirmed by the Receiving Institution) be confirmed by Receiving Institution if one or both change after everything was approved for the first time.

Alternative (I guess) would be to declare them Immutable as soon as a firstVersion is approved by all parties.