ZTC relatie besluittype - zaaktype: één bron twee waarheden

[johannesbattjes]

In het informatiemodel van ZTC staat de relatie tussen zaaktype (ZT) en besluittype (BT) één keer en wel met een richting, van ZT naar BT. Maar in de Api-standaard bestaat de relatie twee keer. Bij een ZT kunnen meerdere BT toegevoegd worden, en aan de BT kunnen meerdere ZT toegevoegd worden. Deze hoeven niet hetzelfde te zijn. Dus een BT kan aan een ZT gerelateerd worden terwijl vanuit ZT bezien er geen relatie met het BT is.
Terwijl dit al onduidelijk was in ZTC 1.0 is dit in ZTC 1.3 helemaal problematisch, omdat met het relateren op basis van omschrijving/identificatie veel meer relaties ontstaan. Het is bijvoorbeeld denkbaar dat aan een nieuw BT een ZT-identificatie wordt toegevoegd, waarmee een nu geldige ZT-versie met die identificatie ook een relatie krijgt met deze BT, zonder dat correctiemodus wordt toegepast of zelfs maar bedoeld is.

Verder kon ik nergens vinden waar deze relatie toegepast wordt. Bij "Maak een BESLUIT-INFORMATIEOBJECT relatie aan" staat bijvoorbeeld: "informatieobject.informatieobjecttype moet in het ZTC gerelateerd zijn aan besluit.besluittype" maar iets dergelijks staat niet bij "Maak een BESLUIT aan." (als ik het goed heb de enige manier om met een POST een relatie zaak-besluit te maken).

De vraag is hoe een dergelijke toepassingsregel bij POST Besluit zou kunnen luiden.
Optie 1: "Het zaaktype van de zaak moet in de ZTC een relatie hebben met het besluittype van het besluit";
Optie 2: "Het besluittype van het besluit moet in de ZTC een relatie hebben met het zaaktype van de zaak";
Optie 3: "Het zaaktype van de zaak moet in de ZTC een relatie hebben met het besluittype van het besluit. Als dat niet zo is moet het besluittype van het besluit in de ZTC een relatie hebben met het zaaktype van de zaak".

Optie 1 is in overeenstemming met het informatiemodel qua richting. Het lijkt ook de meest logische manier van configureren, omdat je bij een zaaktype toch al veel andere objecttypes zoals resultaattypes, roltypes etc invult.

Als je voor optie 1 kiest wordt het opslaan van ZT bij BT volledig overbodig.

Optie 3 is verwarrend. Stel dat een relatie BT-ZT zowel op BT als ZT is vastgelegd, en je wilt in een volgende versie van een ZT deze relatie niet meer hebben en verwijdert deze alleen van het ZT. Dan blijkt dat de relatie toch nog mogelijk is omdat deze op BT niet is verwijderd.

Voorstel: optie 1. Verklaar het opslaan van relaties in het BT als deprecated.

[HenriKorver]

Maar in de Api-standaard bestaat de relatie twee keer. Bij een ZT kunnen meerdere BT toegevoegd worden, en aan de BT kunnen meerdere ZT toegevoegd worden.

Dat laatste (zie vetgedrukte text) begrijp ik niet. In mijn 1.3.1 versie van de Catalogi API zie ik geen mogelijkheid om bij een besluittype één of meerdere zaaktypen toe te voegen:

[johannesbattjes]

Ja zeg dat had ik niet gezien!
Maar in onze ZTC zat attribuut zaaktypen wel in de POST, omdat het in 1.0 t/m 1.2 van de ZTC een verplicht veld was.

Is dit veld bewust weggehaald dan? Dat lijkt me qua gewenste functionaliteit prima (conform mijn optie 1).
Qua versiebeheer snap ik hem niet: ik dacht dat je in een minor versie geen attributen kan verwijderen ivm backwards compatibility.

[michielverhoef]

Qua versiebeheer snap ik hem niet: ik dacht dat je in een minor versie geen attributen kan verwijderen ivm backwards compatibility.

Normaal gesproken niet nee maar in dit geval ligt het iets anders: De enige client die schrijft in de ZTC is de onderhoudstool/beheerschermen van de ZTC. Een nieuwe versie van een ZTC zal gepaard gaan met nieuwe beheerschermen/onderhoudstool dus daar kunnen aanpassingen in gemaakt worden. Een gewone Zaakafhandelcomponent (ZAC) vraagt alleen op en daarvoor verandert er niets. Vanuit het zaakgericht werken gezien is dit geen breaking change, de ZAC krijgt nog steeds backwards compatible antwoorden.

[johannesbattjes]

@michielverhoef je beantwoordt de vraag niet: "Is dit bewust weggehaald?".

Je zegt "De enige client die schrijft in de ZTC is de onderhoudstool/beheerschermen van de ZTC. ". Dat is waar, maar

• er zijn hoe dan ook twee componenten betrokken: de beheertool en de ZTC (Api) zelf. Als de ZTC eerder live gaat met de breaking change dan de (aangepaste) beheertool dan kunnen fouten optreden;
• er kunnen meerdere ZTC-beheertools op één (versie van een ) ZTC-component draaien. Deze moeten dan tegelijk de fix voor de breaking change implementeren.
  Kortom ook bij de ZTC heeft een breaking change grote impact.

Nu is er in ZTC 1.3 al gekozen voor een breaking change: identificatie/omschrijving in plaats van url voor ZT, BT en IOT. Maar voor zover ik weet was de breaking change alleen daartoe beperkt. Vandaar mijn vraag of dit bewust is gedaan.