ZTC: problemen relatie resultaattype-besluittype en resultaattype-informatieobjecttype oplossen

[johannesbattjes]

In ZTC 1.3 staat dit:

1. Het veld is verplicht maar was dit niet in versie 1.2.1. Het is dus een breaking change.
   => voorstel: required weghalen
2. De besluittypen hebben als formaat een array of type strings () en informatieobjecttypen array of type uri.
   => Voorstel: gelijk trekken (bij beide "omschrijving")
3. Bij IOT staat er een toelichting waarvoor het gebruikt moet worden maar bij BT niet
   => Voorstel bij BT ook vertellen waarvoor de relatie gebruikt moet worden. Daarbij ook het woord omschrijvingen noemen.
4. Het is onduidelijk welke applicatie de regel moet afdwingen bij IOT. Is dat de ZRC of de Client Applicatie die het resultaat toevoegt?
   => Voorstel: maak dit duidelijk
5. In de response is sprake van
   "besluittypen": [ "http://example.com/" ], "besluittypeOmschrijving": [ "string" ], "informatieobjecttypen": [ "http://example.com/" ], "informatieobjecttypeOmschrijving": [ "string"
   Maar dit is de enige plek waar twee arrays voor één type worden gegeven. Bij zaaktypes bijvoorbeeld worden alleen url's van besluittypen en resultaattypen in de (GET) response teruggegeven.
   => Voorstel: laat besluittypeOmschrijving en informatieobjecttypeOmschrijving vervallen (of pas dit patroon overal toe dus ook bij zaaktypen).

[HenriKorver]

1. Het veld is verplicht maar was dit niet in versie 1.2.1. Het is dus een breaking change.
   => voorstel: required weghalen

Eens

[HenriKorver]

2. De besluittypen hebben als formaat een array of type strings () en informatieobjecttypen array of type uri.
   => Voorstel: gelijk trekken (bij beide "omschrijving")

Eens. Ik neem aan dat je bij informatieobjecttypen geen "array van uri's" meer wilt maar een "array van strings" waarbij de strings refereren naar de omschrijving van een informatieobjecttype.

[HenriKorver]

3. Bij IOT staat er een toelichting waarvoor het gebruikt moet worden maar bij BT niet
   => Voorstel bij BT ook vertellen waarvoor de relatie gebruikt moet worden. Daarbij ook het woord omschrijvingen noemen.

Eens

[HenriKorver]

4. Het is onduidelijk welke applicatie de regel moet afdwingen bij IOT. Is dat de ZRC of de Client Applicatie die het resultaat toevoegt?
   => Voorstel: maak dit duidelijk

Je bedoelt deze regel neem ik aan:

Het mooist is als deze regel wordt afgedwongen door de Zaken API. Echter dat doet ie niet (lees: deze regel zit niet in de aanvullende spec van Zaken API). Dus vooralsnog zal deze eis afgedwongen moeten worden in de Client Applicatie.

[HenriKorver]

5. In de response is sprake van
   "besluittypen": [ "http://example.com/" ], "besluittypeOmschrijving": [ "string" ], "informatieobjecttypen": [ "http://example.com/" ], "informatieobjecttypeOmschrijving": [ "string"
   Maar dit is de enige plek waar twee arrays voor één type worden gegeven. Bij zaaktypes bijvoorbeeld worden alleen url's van besluittypen en resultaattypen in de (GET) response teruggegeven.
   => Voorstel: laat besluittypeOmschrijving en informatieobjecttypeOmschrijving vervallen (of pas dit patroon overal toe dus ook bij zaaktypen).

Eens dat het mechanisme overal consequent moet worden toegepast. Mijn eerste voorkeur gaat uit naar het overal toepassen van het patroon met twee arrays omdat het dan backwards compatible blijft en het geeft ook meer conveniance omdat je niet de omschrijving van het type hoeft op te halen met extra calls.

[michielverhoef]

De besluittypen hebben als formaat een array of type strings () en informatieobjecttypen array of type uri.
=> Voorstel: gelijk trekken (bij beide "omschrijving")

De verschillen zitten hem in de operatie: De schrijfacties (POST, PATCH, PUT) worden gedaan met omschrijvingen om geen harde koppelingen tussen versies van Zaaktype en Informatieobjecttype/Besluittype te leggen. De vraagacties (GET) geven juist wel de urls naar de exacte versies van de gerelateerde Informatieobjecttypen/Besluittypen ten tijde van de datumgeldigheid (vaak aanmaakdatum van de Zaak).

Op zich hoeft dit geen probleem te zijn, immers schrijven en bevragen wordt gedaan door totaal andere consumers. Bevragen gebeurt door taakspecifieke vakapplicaties, schrijven door de beheerschermen van de zaaktypecatalogus. Een normale taakspecifieke vakapplicatie schrijft niet in de zaaktypecatalogus.

Dus ik zou dit niet gelijk trekken maar op deze manier beide soorten acties optimaliseren.

[michielverhoef]

5. In de response is sprake van
   "besluittypen": [ "http://example.com/" ], "besluittypeOmschrijving": [ "string" ], "informatieobjecttypen": [ "http://example.com/" ], "informatieobjecttypeOmschrijving": [ "string"
   Maar dit is de enige plek waar twee arrays voor één type worden gegeven. Bij zaaktypes bijvoorbeeld worden alleen url's van besluittypen en resultaattypen in de (GET) response teruggegeven.
   => Voorstel: laat besluittypeOmschrijving en informatieobjecttypeOmschrijving vervallen (of pas dit patroon overal toe dus ook bij zaaktypen).

Eens dat het mechanisme overal consequent moet worden toegepast. Mijn eerste voorkeur gaat uit naar het overal toepassen van het patroon met twee arrays omdat het dan backwards compatible blijft en het geeft ook meer conveniance omdat je niet de omschrijving van het type hoeft op te halen met extra calls.

Kan dat niet beter opgelost worden met expand?