Bring back update-components-studied-v1 in new-la-template

[j-be]

In the long term, this should be a feature provided by the API, as receiving-hei knows best about their courses.

E.g. think of a proposal, where the student just fills in the courses names, but no IDs (this is valid as far as https://github.com/erasmus-without-paper/ewp-specs-api-omobility-las/blob/new-la-template/endpoints/get-response.xsd is concerned). Now, receiving-hei wants to assign actual course IDs to the LA, e.g. by cross-referencing their course database. To do so, in the new schema it would have to send out a comment, which would then be manually copied to the LA by human interaction at sending-hei, which for me is alarmingly close to the "let's just send an EMail"-workflow this API is trying to replace.

My proposal would be to reintroduce the feature in one way or another and for now make it optional by adding supported-update-types back to manifest-entry.xsd, as already lobbied for in #11.

[kamil-olszewski-uw]

What you write about (adding component IDs by receiving HEI and sending them back to sending HEI) in an ideal world would be a cool feature. However, the truth is that in the vast majority of cases, receiving HEI is only interested in LA enough to accept components or make a comment. Most receiving HEIs will not store incoming LAs in their systems. Most receiving coordinators would be very reluctant to add component identifiers.

This is why, after a long international discussion, we decided to get rid of the structured comment with the list of proposed changes to components from the API. Implementing this in the interface of each receiving HEI would be a lot of additional work that most users would not want to use anyway (due to overwork, lack of motivation, lack of such a command from their supervisors - you name it).

Alarmingly getting closer to email-like feedback messages doesn't always have to be a bad thing :-)

[j-be]

It kind of makes me sad to read this. I liked master's update spec a lot. I mean, it showed vision, cool ideas, attempts to replace the old way rather than mimicking it digitally as closely as we can. And: the cool and more sophisticated features were optional anyway. So, I don't understand how one could insist on removing optional, but objectively cool and maybe useful features.

But hey, this is what we got, right?

About the email-likeness: I agree with "not always", but I sure think more often than not.

Just as a final remark: I think comment is not very usable as it is:

• users currently don't see his/her own comments, something our staff is very keen about
• there is no way to reply to other comments

These are 2 features, which EMail offers, but the API currently does not.

[kamil-olszewski-uw]

It kind of makes me sad to read this. I liked master's update spec a lot. I mean, it showed vision, cool ideas, attempts to replace the old way rather than mimicking it digitally as closely as we can.

Sometimes vision has to give way to the field of reality. Believe me, almost every piece of API is the result of long discussions, sometimes compromises. We try to make the end result not only an electronic form of a model PDF file, but also we must not go too far with additional ideas beyond what the EC requires from us.

And: the cool and more sophisticated features were optional anyway. So, I don't understand how one could insist on removing optional, but objectively cool and maybe useful features.

Optional for end users. But for implementers all over Europe it would be mandatory. So according to our predictions, a lot of work would be put into a function that would benefit very few people.

users currently don't see his/her own comments, something our staff is very keen about

This is not an API issue. If users want to see their own comments, this must somehow be programmed in the system of receiving HEI.

there is no way to reply to other comments

EWP was never intended as a completely autonomous network that precludes the use of other communication channels. It is okay to clarify certain matters by e-mail or telephone in the case of rejection comment, with which the sending HEI does not agree. Likewise, for example, you can negotiate an interinstitutional agreement outside the EWP before using the IIAs API.

Otherwise, we would have to specify in the EWP something like an e-mail exchange, which would necessarily be more flawed than the existing e-mail protocols and clients.

[j-be]

Understood. We as TU Vienna are late to the party, as somehow noboby found it necessary to tell us, that EWP even exists (neither our department, nor anybody from any other institution) until a few weeks ago.

I don't seem to find any protocols of the discussions you mention, so for me it is a black box. I thought there is still room for discussion, seem to have misunderstood that.

Apart from that:

must not go too far with additional ideas beyond what the EC requires from us

that depends on whether your goal is to satisfy the EC, or if your goal is to let data flow more unrestricted between heis across Europe

But for implementers all over Europe it would be mandatory

there are ways to avoid that. master's manifest-entry.xsd is a perfect example

programmed in the system of receiving HEI

that kind-of contradicts the whole "sending hei is single point of truth". But yes, one could. And mark my words: one will.

But be it, as already mentioned, seems like I'm late to the party. Feel free to close the issue.

[kamil-olszewski-uw]

Understood. We as TU Vienna are late to the party, as somehow noboby found it necessary to tell us, that EWP even exists (neither our department, nor anybody from any other institution) until a few weeks ago.

I don't seem to find any protocols of the discussions you mention, so for me it is a black box. I thought there is still room for discussion, seem to have misunderstood that.

I am afraid it is already very late on this point. We are racing against close deadlines set by the EC roadmap.