ZTC 1.3: welke url's van besluittype, zaaktype en informatieobjecttype worden teruggegeven in de GET-reponse

[johannesbattjes]

In versie 3.1 refereren zaaktypes (ZT), besluittypes (BT) en Informatieobjecttypes (IOT) naar elkaar middels benamingen (omschrijving of identificatie) in plaats van url's.
In de GET op ZT, BT en IOT worden echter url's teruggegeven in plaats van benamingen, vermoedelijk om deze functie backwards compatible te houden.
De vraag is nu, bij de implementatie van de ZTC, welke url's precies moeten worden teruggegeven in de GET responses als meerdere versies van een type zijn die aan de benaming voldoen.

De huidige omschrijving is nu voor mij het duidelijkst bij de response op GET Zaaktypen -> besluittypen:
"Array of strings (heeft relevante besluittypen) unique [ items ]
URL-referenties naar de BESLUITTYPEN die mogelijk zijn binnen dit ZAAKTYPE."

De vraag is hierbij wat er bedoeld wordt met "mogelijk zijn".
Aanname: de waarde in response-besluittypen wordt gebruikt wordt om te bepalen welke besluittype gebruikt kan worden door een client bij het aanmaken van een besluit bij een zaak van het betreffende zaaktype.
Een nadere definitie van mogelijk zijn zou dan kunnen zijn:

• het zaaktype heeft een relatie met het besluittype
• het besluittype heeft concept=false;
• begingeldigheid van besluittype <= de dag waarop de GET plaatsvindt;
• eindegeldigheid van besluittype is leeg of, indien gevuld, > de dag waarop de GET plaatsvindt.

Als jullie het met deze definitie eens zijn implementeren wij het zo.
Tevens moeten er dan soortgelijke definities vastgesteld worden voor (ik hoop dat mijn lijstje compleet is)

GET Zaaktypen -> informatieobjecttypen
GET Zaaktypen -> gerelateerdezaaktypen
GET Zaaktypen -> deelzaaktypen
GET Zaaktype-informatieobjecttypen -> informatieobjecttype (hier is de specificering
extra noodzakelijk: er is hier maar één waarde mogelijk)
GET Besluittypen -> informatieobjecttypen
GET Besluittypen -> zaaktypen
GET Informatieobjecttypen -> zaaktypen
GET Informatieobjecttypen -> besluittypen

[johannesbattjes]

Aanvulling: als datumgeldigheid als filter wordt meegegeven met de GET wordt die datum gebruikt in plaats van de dag waarop de GET plaatsvindt.

[HenriKorver]

Als jullie het met deze definitie eens zijn implementeren wij het zo.

@johannesbattjes Jullie definitie ziet er goed uit en ik ben het eens met de aanvulling. Alleen kan ik de soortgelijke definitie van

GET Zaaktype-informatieobjecttypen -> informatieobjecttype (hier is de specificering extra noodzakelijk: er is hier maar één waarde mogelijk)

nu nog niet helemaal goed overzien. Daar moet nog verder ingedoken worden.

[michielverhoef]

GET Zaaktype-informatieobjecttypen -> informatieobjecttype (hier is de specificering extra noodzakelijk: er is hier maar één waarde mogelijk)

ZaaktypeInformatieobjecttype (ZIO-type) is een groepsattribuut van Zaaktype (net als eigenschap, roltype, statustype etc.). Een ZIO-type is gekoppeld aan 1 versie van een Zaaktype dus wanneer een op een datumGeldigheid geldige versie van een zaaktype opgehaald wordt krijg je de versie van Informatieobjecttype van het bijbehorende ZIO-type terug. Onderwater haalt de Catalogi API de op datumGeldigheid geldige versie van het Informatieobjecttype op behorende bij de Informatieobjecttype.omschrijving.

Bij opvragen van een Zaaktype krijg je dus altijd de versies van het Informatieobjecttype terug zoals geldig op datumGeldigheid. Niet een array van alle mogelijke versies van Informatieobjecttypen.

[johannesbattjes]

@HenriKorver Ik bedoel het volgende. Voor dit geval (GET Zaaktype-informatieobjecttypen -> informatieobjecttype) is de definitie zoals ik hem voorstel met de vier bullets denk ik goed. Maar ook noodzakelijk: als je bijvoorbeeld één van de bullets zou weglatendan komen er meerdere versies van het IOT terug terwijl er maar één waarde mogelijk is.

[johannesbattjes]

Bij het testen van business rule ztc-013 realiseerde ik me dat er nog een voorwaarde is voor een type om geretourneerd te worden als url: het type moet in dezelfde catalogus zitten.
De lijst wordt dan:

• zaaktype en besluittype zitten in dezelfde catalogus;
• het zaaktype heeft een relatie met het besluittype;
• het besluittype heeft concept=false;
• begingeldigheid van besluittype <= de dag waarop de GET plaatsvindt (of datumgeldigheid indien die wordt meegegeven);
• eindegeldigheid van besluittype is leeg of, indien gevuld, > de dag waarop de GET plaatsvindt (of datumgeldigheid indien die wordt meegegeven).

[HenriKorver]

@michielverhoef @johannesbattjes Bedankt voor jullie extra uitleg. Nu is het geval

GET Zaaktype-informatieobjecttypen -> informatieobjecttype (hier is de specificering extra noodzakelijk: er is hier maar één waarde mogelijk)

mij ook duidelijk.

[HenriKorver]

Bij het testen van business rule ztc-013 realiseerde ik me dat er nog een voorwaarde is voor een type om geretourneerd te worden als url: het type moet in dezelfde catalogus zitten.

@johannesbattjes Deze voorwaarde hoef je toch niet te checken want in de Catalogi API kun je alleen maar types aanmaken die in dezelfde catalogus zitten gezien issues #2468 en #2482?

[johannesbattjes]

Mijn redenering was: stel de relatie tussen twee types (laten we zeggen BT -> IOT) is gelegd op basis van bijvoorbeeld omschrijving "bijlage". Stel verder dat er in de ZTC twee catalogi zijn die beide een IOT hebben hebben met omschrijving "bijlage". Dan mag bij GET BT alleen die IOT teruggegeven worden die in dezelfde catalogus zit.

[HenriKorver]

Oké, ik begrijp nu wat je bedoelt en ben het daar mee eens. Mijn bewering is dat een dergelijke eis (business rule) ook al in de beginfase moet worden afgedwongen bij het aanmaken van de relatie tussen een BT en een IOT, dus bij de POST-operatie.

.

M.a.w. in de beschrijving van deze POST-operatie moet expliciet worden vermeld dat alleen de relatie kan worden gelegd met een IOT die in dezelfde catalogus zit als het BT. En als er geen IOT binnen de catalogus van het BT kan worden gevonden die matched met de omschrijving dan moet de POST-operatie een foutmelding teruggeven eventueel in combinatie met een extra waarschuwing als er wel een IOT met dezelfde omschrijving voorkomt in een andere catalogus.

[HenriKorver]

Ter aanvulling. De bovengenoemde checklist met 5 items:

• zaaktype en besluittype zitten in dezelfde catalogus;
• het zaaktype heeft een relatie met het besluittype;
• het besluittype heeft concept=false;
• begingeldigheid van besluittype <= de dag waarop de GET plaatsvindt (of datumgeldigheid indien die wordt meegegeven);
• eindegeldigheid van besluittype is leeg of, indien gevuld, > de dag waarop de GET plaatsvindt (of datumgeldigheid indien die wordt meegegeven).

geldt niet alleen voor de GET-, maar ook voor de POST-operaties. Immers de POST-operaties geven in de response ook weer arrays met url's terug van BT, ZT en IOT, net zoals bij de GET-operaties.

[johannesbattjes]

Hoi Henri je zegt over de POST : "En als er geen IOT binnen de catalogus van het BT kan worden gevonden die matched met de omschrijving...."
Ik denk dat het heel lastig wordt hier een zinvolle regel voor te maken.
Stel bijvoorbeeld dat er wel een IOT is (in dezelfde catalogus) maar die is concept. Of hij heeft een einddatum van gisteren. Of hij is nog geldig maar over 1 minuut verlopen. Dan kun je de relatie wel accepteren, maar op het moment dat een informatieobject aan een besluit wordt gerelateerd (en daar gaat het om) is er dan toch geen geldige combinatie BT-IOT.
En waarom zou je niet, bijvoorbeeld eerst een BT mogen aanmaken (met verwijzing naar nog niet bestaand IOT) en dan pas de IOT met die omschrijving?

Je zou het checken op bestaan van omschrijving bij de POST ook helemaal los kunnen laten: als de IOT er toch niet (geldig) is op het moment dat een informatieobject wordt aangemaakt, kan het informatieobject dat type niet krijgen en is er dus ook geen probleem.

De focus ligt nu heel erg op relaties in de ZTC, maar we zouden juist meer aandacht moeten besteden aan het moment dat zaken, besluiten, en informatieobjecten aan elkaar gerelateerd worden. Het is nu vaak niet gespecificeerd wat wel en niet mag (bijvoorbeeld: bij BESLUIT-INFORMATIEOBJECT staat niet dat het informatieobject een type moet hebben waarvan de omschrijving is opgevoerd bij het besluittype van het besluit). Hier zijn overigens weer lastige vervolgvragen. Stel dat er een informatieobject is van een niet meer geldig IOT, maar waarvan de omschrijving wel is opgevoerd bij het besluittype van het besluit. Mag deze dan nog steeds aan een besluit worden gerelateerd aan het besluit.

[HenriKorver]

Hoi Johannes, bedankt voor je reactie. Ik begrijp je punt en het is inderdaad lastig om zinvolle regels te formuleren voor de POST-operaties. Dus laten we dat vooralsnog nog maar even zitten.