programOfferingAssociation wel gebruikt in flow 1 maar niet in flow 5 - logisch?

[roelgrif]

k vind het wat merkwaardig dat we het element programOfferingAssociation in flow 5 niet gebruiken en in flow 1 wel, dat zou m.i. symmetrisch moeten zijn (zeker als het een PUT betreft) , met name omdat we accepteren dat er in beide flows nieuwe programOfferingAssociation objecten aangemaakt kunnen worden.

[hamrt]

Volgens mij komt dat voornamelijk omdat we in flow1 deze gegevens alleen ophalen om groepen in te kunnen delen. De informatie wordt NIET gebruikt om gegevens aan de hand van planning of inzet iets op terug te sturen.

[rrutte]

Volgens mij zijn de attributen binnen de consumers niet symetrisch gespect, maar is aangegeven welke attributen noodzakelijk zijn in welke flow. We hebben door deze verschillen een tijd geleden nog kort overwogen om per flow een aparte consumer te gebruiken, maar vanwege de daarmee gepaard gaande complexiteit daar niet voor gekozen.

[JosVanderArend]

Op zich zouden we gegeven m.b.t. de studentcontext (programOffAssociation, courseOffAssociation) ook in terugweg kunnen toestaan. Lastiger wordt het bij attemptLeft waarvan de werkelijke waarde mogelijk ander is na een gedane poging (dus na flow 1 ).

Geldt wellicht ook voor orgAssociationId (ook in flow 1)? En additionallTimeInMin en personalNeeds (ook in flow 5)?

[JosVanderArend]

We doen aan dataminimalisatie en specificeren in de koppelingen alleen de gegevens die nodig zijn in de informatiestroom. Gegevens terugkoppelen aan het SIS die het eerder zelf heeft aangeleverd, is hierbij alleen maar riskant: wat te doen als dit gegeven niet overeenkomt? Als het SIS deze informatie nodig heeft, is het de taak van het SIS om deze contextinformatie zelf bij de Toetsinschrijving (ComponentOfferingAssociation) te bewaren.

[mcginkel]

De studentcontext (programOffAssociation, courseOffAssociation) op de terug weg weer meegeven is voor mij onwenselijk. wat als die afwijkt van de huidige stand in het SIS? moet je het SIS dan aanpasen? of fout of negeren? Waarschijnlijk negeren en dan is het onlogish om de situatie te laten ontstaan.

en je ontslaat de TPS van de verplichting om dit bij te houden. als je een eenvoudig TPS ben (of praktijk examens TPS?) dan heb je hier misschien wel helemaal niets mee te doen en word je ook niet verplicht om dit up to date te houden of te bewaren

[roelgrif]

Bij een PATCH ben ik het er hier helemaal mee eens. Maar bij een PUT zeggen we dus eigenlijk: beschouw een PUT ook maar als een PATCH. Voor een standaard vind ik dat onwenselijk. Als het TPS dit soort gegevens niet wil meegeven, helemaal prima, maar stuur dan geen PUT.

[JosVanderArend]

Er is verschil tussen de gegevens in flow 1 en flow 5. Issue is daarmee gesloten