search

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

Specifications of EWP's Outgoing Mobilities API.
MIT License
1 stars 4 forks source link

Definition of OutgoingMobilityHistoryEntry #3

Closed kaiqu closed 7 years ago

kaiqu commented 7 years ago

I have some questions about the choices described in the comment.

Accepting/rejecting a nomination

I am unsure about who accepts/rejects: It seems logical that it's the host (receiving) institution. But since this is information from the home (sending) institution, that seems not to be the case? Is it the student?

Marking a course as recognized

Again - isn't this something the host (receiving) institution does? Have I misunderstood something about the process?

wrygiel commented 7 years ago

Accepting/rejecting a nomination

Yes, it's the coordinator from the receiving HEI who accepts these. See here.

Marking a course as recognized

Currently, we have only discussed "marking a course as ready for recognition" (see here).

As to the "marking as recognized", this is not documented yet, but I'm quite sure that it will be the sending HEI's job?

kaiqu commented 7 years ago

Accepting/rejecting a nomination

Yes, it's the coordinator from the receiving HEI who accepts these. See here.

That's what I thought, but this is a response to the receiving HEI (RH) from an API implemented by the sending HEI (SH). Why would the SH send information about accepting/rejecting a nomination to the RH - when the latter is the one doing the accepting/rejecting?

Or are we talking about an optional approval process at the SH?

Marking a course as recognized

Currently, we have only discussed "marking a course as ready for recognition" (see here).

That's the ToRs API (this is the Mobilities API)...?

As to the "marking as recognized", this is not documented yet, but I'm quite sure that it will be the sending HEI's job?

Ah, I see I have misunderstood that part.

kaiqu commented 7 years ago

As to the "marking as recognized", this is not documented yet, but I'm quite sure that it will be the sending HEI's job?

Ah, I see I have misunderstood that part.

The annotation in the "recognized" element in response_new.xsd says: "Recognized means the host institution has approved the following courses"

I understand "host" to be synonymous with "receiving"?

wrygiel commented 7 years ago

That's what I thought, but this is a response to the receiving HEI (RH) from an API implemented by the sending HEI (SH).

The receiving HEI adds new history entries via Outgoing Mobility Remote Update API, not this one.

Why would the SH send information about accepting/rejecting a nomination to the RH - when the latter is the one doing the accepting/rejecting?

Sending HEI is responsible for keeping all history of changes.

wrygiel commented 7 years ago

That's the ToRs API (this is the Mobilities API)...?

The current idea is that "marking a course as ready for recognition" will be handled by the Outgoing Mobility Remote Update API. It's a new history entry.

The annotation in the "recognized" element in response_new.xsd says: "Recognized means the host institution has approved the following courses"

I understand "host" to be synonymous with "receiving"?

I didn't write this one, you'll have to ask Richard what he meant. In my opinion it should be the sending HEI there.

kaiqu commented 7 years ago

That's what I thought, but this is a response to the receiving HEI (RH) from an API implemented by the sending HEI (SH).

The receiving HEI adds new history entries via Outgoing Mobility Remote Update API, not this one.

Why would the SH send information about accepting/rejecting a nomination to the RH - when the latter is the one doing the accepting/rejecting?

Sending HEI is responsible for keeping all history of changes.

Aha. So the SH sends the changes made by the RH (via Remote Update) back to the RH - as confirmation that the RH's changes have been stored correctly?

kaiqu commented 7 years ago

The annotation in the "recognized" element in response_new.xsd says: "Recognized means the host institution has approved the following courses"

I understand "host" to be synonymous with "receiving"?

I didn't write this one, you'll have to ask Richard what he meant. In my opinion it should be the sending HEI there.

Ok, we'll see what Richard says when he is back (next week)...

wrygiel commented 7 years ago

So the SH sends the changes made by the RH (via Remote Update) back to the RH - as confirmation that the RH's changes have been stored correctly?

Technically speaking, it doesn't send the change itself, only a notification that something has changed.

In your scenario, it will work this way:

The two latter calls are a bit redundant in this case, but it's just how it works.

kaiqu commented 7 years ago

Ok, the picture is gradually getting clearer.

Sorry if I'm asking questions that have been resolved a long time ago - since I haven't had the time to follow the earlier discussions, I'm kind of the "new guy" who needs to be brought up to speed...

Btw, my main task here is to ensure that the necessary information from the data model is being transferred (and provide a suggested logical structure). I might include too much information in a given response, to be on the safe side...

wrygiel commented 7 years ago

Sorry if I'm asking questions that have been resolved a long time ago

It's okay, perhaps we'll make a FAQ out of those later on ;) Our "CNR workflow" in an implementation of a publish–subscribe pattern. It might be complicated to grasp at first sight, but it's extremely easy.