search

erasmus-without-paper / ewp-mobility-vs-api-use-cases

"API Design vs. Use Cases" document.
0 stars 0 forks source link

Learning Agreement #2

Closed StefanJahnke closed 7 years ago

StefanJahnke commented 8 years ago

In our model, LAs can be accepted and rejected many times. LA can be changed whenever needed, by both sides. Whenever "accepted by X" and "accepted by Y" events appear in unison, such new LA becomes "accepted by both parties".

Since both institutions have access to the complete history of the Outgoing Mobility object, both institutions can always determine which revision was accepted first, and what other versions of it has been accepted.

If I understand correctly, some 'parts' of the Learning Agreement can be accepted. e.g. both institutions can agree on one educational component. This doesn't make the Learning Agreement "complete" though. In your model - in which moment is the whole Learning Agreement considered as "complete"?

wrygiel commented 8 years ago

We have talked about in live, but I will reply here just to sum up once more. We propose that the Mobility object describes a set of actions (a <timeline>). Whenever a <timeline> contains three consecutive "approval history entries" (by all the parties), the content is considered approved. There will be a couple of types of such approval. Based on these types, systems will be able to produce an Erasmus+-compatible PDF document.

I hope @erasmus-without-paper/wp3 can confirm this.

StefanJahnke commented 8 years ago

The approval history entries would be only by institutions, thus there would be the need only for two of those and we would need to assume that one of the institutions is in touch with the student and gets the students' approval before updating the Learning Agreement.

It is quite an 'unclean' solution when it comes to the political question of how valid a LA is. From a technical level it should be sufficient though.

wrygiel commented 8 years ago

The approval history entries would be only by institutions

We could have three types of approval entries:

StefanJahnke commented 8 years ago

seems like a good enough solution to me

wrygiel commented 8 years ago

This is closely related to https://github.com/erasmus-without-paper/general-issues/issues/14. In my <timeline/> proposal these approvals are represented as <tag/> elements.

@mpuzar, probably you should take a look at this topic too.

wrygiel commented 7 years ago

This is already implemented in the current version of the API.