Ontdubbeling bij dubbelle toetsinschrijving

[JosVanderArend]

Door een mismatch tussen de resultatenstructuur in DR/SIS en de betreffende kerntaken/werkprocessen van de toets/examen zoals ingepland in TPL kunnen de verwachtingen over resultaten verschillen tussen TPL en DR/SIS.
Om dit op te lossen wordt de volgende tekst toegevoegd aan de specificaties van versie 1.1 (in paragraaf 3.1 "Informatiestroom 1. Toetsdeelnemers"):

Let op, niet iedere Toetsinschrijving van een Planbare toets voor de Student zal tot een Studentresultaat (informatiestroom 5) leiden. Voorbeelden van dergelijke situaties zijn:

1. Toetsinschrijving wordt door TPL als dubbele toetsinschrijving genegeerd (*),
2. Toetsinschrijving of Planbare toets wordt teruggetrokken (geannuleerd) door DR/SIS,
3. Student heeft zich in DR/SIS uitgeschreven voor Opleidingsdeel of Opleiding,
4. Student kan door TPL niet worden ingepland voor deelname aan een toetsafname,
5. Student tekent zich niet in voor deelname aan een geplande toetsafname,
6. Zitting wordt geannuleerd.

(*) Toetsinschrijving is dubbeling van eerdere Toetsinschrijving wanneer:
• Beide Toetsinschrijvingen betreffen dezelfde Student, dezelfde Planbare toets en hetzelfde pogingnummer, en
• Eerdere Toetsinschrijving heeft nog niet geleid tot een Studentresultaat.

Bovenstaande houdt in dat DR/SIS niet meerdere Toetsinschrijvingen voor dezelfde Planbare toets kan versturen om ervoor te zorgen dat één toetsafname tot meerdere Studentresultaten leidt. Eén toetsafname leidt altijd tot één Studentresultaat (afgezien van wijzigingen/updates hierop). Indien het Studentresultaat van een toetsafname door DR/SIS op meerdere plaatsen in de resultaatstructuur moet worden geregistreerd dan zal DR/SIS dit zelfstandig moeten doen bij de verwerking van het ontvangen Studentresultaat.

[JosVanderArend]

Aanvullingen/vragen:

• Misschien moet TPL (direct) terugmelden aan DR/SIS wanneer het een Toetsinschrijving negeert (dubbeling constateert)?
• Dit zou ook moeten werken als DR/SIS de toetsen niet kent (geen flow 0) omdat de toets (object Component) wel of niet gekoppeld is aan de Planbare toets (ComponentOffering).
• Is het idee dat de dubbeling als dubbele inschrijving mag worden gezien zolang er nog een Toetsdeelnemerresultaat (flow 2) is ontvangen door TPL op eerdere Toetsinschrijving correct? Of, kunnen we ervanuit gaan dat dubbele Toetsinschrinvingen altijd tegelijkertijd worden verzonden?

[roelgrif]

Ik snap niet helemaal waarom het criterium "Eerdere Toetsinschrijving heeft nog niet geleid tot een Studentresultaat." er bij staat. Lijkt me dat je geen twee associationId's wilt hebben van dezelfde student/planbaretoets/poging combinatie. Of er al dan niet al een resultaat is gehaald maakt dan toch niet uit? Dubbele toetsinschrijvingen hoeven natuurlijk niet altijd tegelijk verzonden te worden, maar als ik vandaag association-Id 1 stuur en morgen association-Id 2 (op dezelfde student/planbaretoets/poging) dan mag er wat mij betreft direct een terugkoppeling/foutmelding komen van TPL 'dubbele toetsinschrijving' maar daarvoor is het verschillende association-Id wel essentieel want als dat hetzelfde is, dan is het gewoon een update van de bestaande toetsinschrijving.

[JosVanderArend]

@roelgrif, om antwoord te geven op je eerste vraag: Of er al dan niet al een resultaat is gehaald maakt dan toch niet uit?
Volgens mij wel. Het kan namelijk voorkomen dat een resultaat in DR/SIS ongeldig wordt verklaard en dat een student dus dezelfde poging mag overdoen. In dat geval zijn Student en pogingnummer gelijk, en mogelijk ook de Planbare toets.
Ik vroeg me hierbij wel af tot welk moment we een latere toetsinschrijving als dubbel mogen zien: resultaatinfo uitgewisseld, deelnameinfo uitgewisseld, toetsafname beeindigd, toetsafname gestart, of misschien nog eerder (deelname gepland).

Je opmerkng over dat bij een dubbele toetsinschrijving het id van de Association moet verschillen is terecht. Anders is het inderdaad een update van de eerdere toetsinschrijving.

[rrutte]

Ik begrijp eerlijk gezegd niet wat de achterliggende problematiek is. Bijvoorbeeld rond de toetspogingen:

• Een toetsinschrijving wordt geïdentificeerd door een associationId. Niet door een pogingnummer. Dit omdat een testComponentOfferingAssociation meerdere attempts kan bevatten.
• Een SIS kan meerdere testComponentOfferingAssociations aan een TPL aanbieden voor dezelfde offering en student.

De beschreven voorbeelden zijn voor mij flow voorbeelden waarvan het merendeel al gewoon door OKE en gerelateerde applicaties ondersteund worden. Zijn voor mij dan ook niet gerelateerd aan mismatch.

Is het niet beter om een los artikel te maken met scenario's hoe een TPL of afnamesysteem discrepanties tussen aggregatieniveau van een toets in SIS en de benodigde (praktijk)examens in het afnamesysteem kan oplossen met behulp van standaard OKE berichtuitwisseling?