Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Per document wil ik een gestempelde versie kunnen opslaan #2079

Open
johannesbattjes opened this issue Aug 17, 2022 · 31 comments
Open

Per document wil ik een gestempelde versie kunnen opslaan #2079

johannesbattjes opened this issue Aug 17, 2022 · 31 comments
Assignees
@HenriKorver
Labels
user story

Comments

@johannesbattjes
Copy link

Bij OLO/DSO-verzoeken komen grote aantallen bouwtekeningen en dergelijke mee. Deze krijgen direct status definitief vanwege business rule DRC-005: "Wanneer InformatieObject.ontvangstdatum een waarde heeft, dan zijn de waarden in bewerking en ter vaststelling voor InformatieObject.status NIET TOEGESTAAN"

Vaak maken vergunningverleners wel annotaties op deze documenten, stempelen ze deze documenten of voeren er anderszins bewerkingen op uit middels tools als Bluebeam en Digeplan.

Deze wijzigingen moeten kunnen worden opgeslagen. Beste oplossing lijkt een nieuwe documentregistratie aan te maken - maar die moet dan wel een relatie kunnen hebben met het originele document. Het moet dus mogelijk worden in DRC relaties tussen documenten te leggen.

Alternatief is er voor te zorgen dat er bij definitieve documenten wel nieuwe versies mogen worden toegevoegd van een apart type bv "annotatieversie"
@michielverhoef michielverhoef mentioned this issue Oct 20, 2022
Open
@erwinkusters
Copy link

Gemeente Maastricht wil graag met Rx.Mission in productie maar daarvoor moet dit issue zijn opgelost. Wij stempelen en annoteren, met DigEplan, tientallen/honderden documenten per dag die we vanuit het OLO/DSO met een vergunningaanvraag binnen hebben gekregen. Na het stempelen/annoteren moeten deze documenten automatisch teruggezet worden in de zaak. Het terugschrijven werkt nu niet. Graag met spoed oppakken!

Met vriendelijke groet,

Erwin Kusters
SSC Beheer Bedrijfsinformatiesystemen | Functioneel Beheerder
T (043) 350 31 58 | M (06) 55 41 57 49 | erwin.kusters@maastricht.nl
Mosae Forum 10, 6211 DW | Postbus 1992, 6201 BZ Maastricht | www.gemeentemaastricht.nl

@erwinkusters erwinkusters mentioned this issue Mar 8, 2023
Open
@tieskremer
Copy link

Mijn naam is Ties Kremer en ben van Avolve Software, wij ontwikkelen software voor gemeenten en andere partijen die zich bezighouden met de omgevingswetgeving.

Sinds kort komen bij de klanten alle documenten in definitieve status binnen wat voor de klant vervelend is en in onze ogen ook niet juist. Je creëert een hoop dubbele documenten ipv dat je versie beheer toepast zoals in alle dms en zaaksystemen in Nederland.

Wij leveren software voor het werken met de documenten zoals: het maken van digitale aantekeningen, waarmerken, meten, vergelijken enz... Ook met onze software kan men goede versie beheer toepassen en zijn de originele documenten nooit aan te passen zijn beschermd.

Is het mogelijk dit onderwerp te bespreken met jullie, we bedienen ongeveer 25 % van alle gemeenten, of kunnen jullie aangeven dat de documenten weer als "In bewerking" binnen kunnen komen daarmee is dit probleem ook van tafel en blijven dossiers overzichtelijk maar de originelen wel beschermd. Tevens is het dan mogelijk als er een nieuwe versie weggeschreven wordt deze de status definitief mee te geven zodat deze pas definitief wordt wanneer het echt nodig is.

Met vriendelijke groet,

Ties Kremer
Avolve software
06-46061480

@michielverhoef
Copy link
Collaborator

Er zit een gedachte achter de status definitief van documenten die niet door gemeenten worden toegevoegd. Immers, het document is volgens de indiener af. Mocht er iets niet goed zijn dient de indiener een nieuw document op te leveren. Maar ik snap ook wel dat het verwerken van een document betekent metadata wijzigen en dat het lastig is (zacht uitgedrukt) wanneer dat niet kan.

Tot dit opgelost is in een nieuwe versie van de standaard kan vanaf versie 1.2 (uitgekomen 19-12-2022) van de Documenten API de scope documenten.geforceerd-bijwerken (enigszins mis)bruikt worden om dit op korte termijn op te lossen.

@tieskremer
Copy link

tieskremer commented Mar 13, 2023 via email

@HenriKorver HenriKorver self-assigned this Mar 14, 2023
@MNIJ
Copy link

MNIJ commented Mar 21, 2023

Tot dit opgelost is in een nieuwe versie van de standaard kan vanaf versie 1.2 (uitgekomen 19-12-2022) van de Documenten API de scope documenten.geforceerd-bijwerken (enigszins mis)bruikt worden om dit op korte termijn op te lossen.

Dat is geen oplossing voor deze use-case. De scope documenten.geforceerd-bijwerken staat toe om de metadata van een definitief document bij te werken. Maar bij het stempelen / annoteren / anonimiseren gaat het niet (alleen) om een meta-data wijziging, maar wordt juist de bestandsinhoud van het document aangepast. Dat is volgens de DRC 1.2 standaard niet toegestaan, zelfs niet met geforceerd-bijwerken.

@RemcovBeelen
Copy link

Dit is ook een wens vanuit de gemeente Nieuwegein

@Nunspeet
Copy link

Dit is ook een uitdrukkelijke wens vanuit de gemeente Nunspeet

@JMV1Stroom
Copy link

Ik ben het geheel eens met de redenatie van TiesKremer. Dat deze status definitief in de ogen van de aanvrager zou kloppen snap ik, maar het stuk ligt ter besluitvorming van een aanvraag. Documenten die nu uit Olo ontvangen worden, vereisen ingevolge art. 1.4 2e lid van de Ministeriele regeling Omgevinsgrecht dat ze 'read only' zijn. Zie: https://wetten.overheid.nl/BWBR0027471/2022-06-01#Hoofdstuk1_Artikel1.4 Dit is m.i. wat anders dan het document meteen de status 'definitief' meegeven.

@MNIJ
Copy link

MNIJ commented Mar 22, 2023

Dit issue heeft heel veel raakvlakken en overeenkomsten met issue #2078 over het maken van een geanonimiseerde versie.

De oplossing die daarin wordt voorgesteld is niet om het originele ontvangen document bewerkbaar te houden, maar om een nieuw documentregistratie te maken met een betekenisvolle relatie naar het oorspronkelijke document. Dat is overigens ook de oplossing die in de start van dit issue door @johannesbattjes wordt voorgesteld.

Volgens mij is dit een fundamentele keuze die gemaakt moet worden: Maak je bij het stempelen / annoteren / anonimiseren...

  1. Een nieuwe versie van de bestaande documentregistratie
  2. OF een kopie van de bestaande documentregistratie, met een relatie naar de oorspronkelijke registratie

De tweede oplossing is meer in lijn met MDTO en ook met het wetsartikel waar @JMV1Stroom naar verwijst.

@tieskremer
Copy link

tieskremer commented Mar 22, 2023 via email

@tieskremer
Copy link

tieskremer commented Mar 22, 2023 via email

@MNIJ
Copy link

MNIJ commented Mar 22, 2023

Als het mogelijk wordt om documenten aan elkaar te relateren, dan kan in de user-interface van "consumers" natuurlijk gezorgd worden dat deze netjes en overzichtelijk bij elkaar komen te staan en niet gewoon als twee losse regels in de lijst.

Uiteraard is dat niet iets dan vanzelf gaat, dus daar zit wel werk aan vast voor leveranciers (zoals wijzelf).

@michielverhoef michielverhoef removed their assignment Mar 31, 2023
@michielverhoef
Copy link
Collaborator

Hiervoor kan dezelfde oplossingsrichting gebruikt worden als voor #2078

HenriKorver added a commit that referenced this issue Apr 3, 2023
@HenriKorver
Relateren van andere versies #2078
6865c21 
Zie issue #2078 en #2079.
@HenriKorver HenriKorver mentioned this issue Apr 3, 2023
Closed
@HenriKorver HenriKorver mentioned this issue Apr 4, 2023
Closed
@HenriKorver HenriKorver moved this from In Progress to Review in Kanban bord API's voor Zaakgericht werken Apr 5, 2023
@HenriKorver HenriKorver moved this from Review to In Progress in Kanban bord API's voor Zaakgericht werken Apr 5, 2023
@HenriKorver
Copy link
Collaborator

HenriKorver commented Apr 5, 2023 •
edited by michielverhoef
Loading

Zie pull request #2222 of redoc voor een oplossing. In de nieuwe OAS is de resource /enkelvoudiginformatieobject uitgebreid met het attribuut andereVersies waarmee je documenten kunt relateren aan andere versies. Voorbeeld:

"andereVersies": [
    {
        "andereVersie": "[url naar de gestempelde versie van het document]",
        "aanduidingVersie": "gestempeld",
        "richtingRelatie": "heeft_versie"
    }
]

Automatisch wordt door de API de inverse relatie aangemaakt bij het gestempelde document:

"andereVersies": [
    {
        "andereVersie": "[url naar het originele document zonder stempel]",
        "aanduidingVersie": "gestempeld",
        "richtingRelatie": "is_een_versie_van"
    }
]

@HenriKorver
Copy link
Collaborator

@johannesbattjes Is de bovenstaande oplossing naar wens?

@HenriKorver HenriKorver moved this from In Progress to Review in Kanban bord API's voor Zaakgericht werken Apr 5, 2023
@johannesbattjes
Copy link
Author

Hoi @HenriKorver , de link naar Redoc werkt niet. Kun je dat fixen?
Zoals je het in de quasicode laat zien lijkt het mij goed, ik ga hier volgende week nog induiken met Michiel Nijdam.
We zouden andereVersies overigens ook heel mooi kunnen gebruiken om versies van documenten die aanvragers indienen (gebeurt vaak bij bouwaanvragen) te relateren.

Ik begrijp dat "aanduidingVersie" vrij invulbaar wordt. Hoe kunnen we ervoor zorgen dat als het een geanonimiseerde versie betreft alle systemen dit snappen? Mogelijk door dit in de beschrijving te zetten? ("gebruik geanonimiseerd in het geval van geanonimiseerde documenten"

@michielverhoef
Copy link
Collaborator

@johannesbattjes Waarschijnlijk gebruik je Chrome. Dan moet het vinkje bij "cors" weggehaald worden. In Firefox werkt dit wel. Ik heb in ieder geval de link ook gefixed in de post van Henri .

Mooi om te zien dat de oplossing generieker bruikbaar is.

Ik begrijp dat "aanduidingVersie" vrij invulbaar wordt. Hoe kunnen we ervoor zorgen dat als het een geanonimiseerde versie betreft alle systemen dit snappen? Mogelijk door dit in de beschrijving te zetten? ("gebruik geanonimiseerd in het geval van geanonimiseerde documenten".

Het liefst zou ik voor een enum kiezen maar dat zou betekenen dat een andere invulling van de relatie (zoals in het voorbeeld hierboven) meteen een andere versie van de standaard vereist. Dan zitten we een beetje in een catch-22: Netjes dichttimmeren maakt het misschien robuust en voorspelbaar maar niet flexibel genoeg om toe te passen.

Een enum met toelichting in de documentatie opnemen is misshchen het beste. Dan wordt het niet hard afgedwongen en blijft de standaard flexibel maar is er toch een zekere mate van eenheid.

@Rdenboer
Copy link

ook vanuit Putten sluiten we aan bij andere gemeenten en Ties. Graag geannoteerde/gestempelde documenten als nieuwe versie kunnen opslaan binnen dezelfde registratie. Krijgen op dit moment in testomgeving soms een verdubbeling van documenten binnen een zaak wat niet altijd handig is voor overzicht, ook niet als je ze aan elkaar relateert.

@MNIJ
Copy link

MNIJ commented Apr 11, 2023

@HenriKorver dit voorstel kan zeker werken en lijkt ook op hoe de relaties tussen zaken onderling gemodelleerd zijn. Maar over die zaak-zaak relaties hadden we ook al geconcludeerd dat er nadelen zitten aan deze syntax.
Bijvoorbeeld:

Het is in dit model niet mogelijk om een relatie tussen documenten toe te voegen of te verwijderen zonder eerst te weten wat de bestaande relaties van het document zijn, omdat het één lijst van relaties is. Dus om een relatie toe te voegen moet je de bestaande lijst opvragen en dan de nieuwe met een PUT of PATCH toevoegen. In het zeldzame maar niet onmogelijke geval dat er in de tussentijd al een andere relatie aan de lijst is toegevoegd, wordt deze weer verwijderd door de nieuwe wijziging.

Een alternatieve en mogelijk robuustere oplossing is een los relatie-object. Dat zou dus een nieuwe entiteit zijn InformatieobjectRelatie die er zo uit zou kunnen zien:

{
"url" : "[identificatie van deze InformatieobjectRelatie]",
"informatieobject-1" : "[url naar document 1]",
"informatieobject-2" : "[url naar document 1]",
"aardRelatie" : "gestempelde_versie"
}

Dit voorbeeld zou dus betekenen dat informatieobject-1 de gestempelde versie van 2 is.

De GET op deze nieuwe entiteit zou dan een query parameter moeten kennen waarmee je alle relaties van een document kan opvragen, dus ongeacht of het "informatieobject-1" of "informatieobject-2" is. En een delete op een informatieobject zou ook automatisch alle relaties moeten verwijderen waar deze in voorkomt.

@HenriKorver
Copy link
Collaborator

HenriKorver commented Apr 12, 2023 •
edited
Loading

@MNIJ Eens dat jouw voorstel beter c.q. robuuster is en ben van plan dit over te nemen. Wel denk ik erover om het attribuut andereVersies bij een zaak zoals gespecificeerd in de OAS van mijn voorstel te handhaven, maar nu als een read-only veld. Dus de schrijfacties vinden dan plaats via een losse cross resource zoals /gerelateerdeInformatieObjecten of iets dergelijks, nog even zoeken naar een goede naam. En de leesacties kunnen zowel op deze cross resource als op de /zaken resource worden uitgevoerd. Dit laatste is bedoeld als conveniance richting de client-developer. Kun je jezelf vinden in deze gecombineerde oplossing?

@Nunspeet
Copy link

Ik begrijp niet goed wat het probleem is om binnen dezelfde registratie te blijven. In mijn beleving kan met de status of versie voldoende geborgd worden. Het gaat immers om een kenmerk dat aan een registratie wordt gegeven. In dit geval gewaarmerkt of geanonimiseerd. Op die wijze is voor publicatie, bijlage bij beschikking en dergelijke altijd het juiste document te relateren.
In het 'oude' tijdperk werd het door de aanvrager ontvangen document ook voorzien van een stempel en als zodanig gearchiveerd. Het door de aanvrager ontvangen 'originele' document werd ook niet separaat gearchiveerd. Ik vind dat dit vergelijkbaar is met wat we nu feitelijk wensen. Wel het originele document behouden, maar binnen dezelfde registratie het mogelijk maken een geanonimiseerd en een gewaarmerkt document raadpleegbaar maken.

@MNIJ
Copy link

MNIJ commented Apr 13, 2023

@HenriKorver, prima.

@Nunspeet, dat is ook een valide use-case maar een andere. Mogelijk is "gestempelde versie" dan ook een slecht voorbeeld. Maar voor bijvoorbeeld een geanonimiseerde versie voor publicatie is het (ons inziens) wel echt nodig om een tweede registratie met een relatie naar het oorspronkelijke document op te slaan.

@michielverhoef
Copy link
Collaborator

Wat wordt bedoeld met 'registratie'?

Daarnaast is hier denk ik ook sprake van begripsverwarring rondom de term versie. Versie kan (minstens) drie betekenissen hebben in deze:

Zowel voor een technische als een functionele versie geldt dat een nieuwe versie de voorgaande versie vervangt (overschrijft). Een weergave-variant zoals een geanonimiseerde versie vervangt niet de voorgaande technische/functionele versie maar bestaat naast de oorspronkelijke versie. Er kunnen ook verschillende weergave-varianten van een document bestaan, naast de oorspronkelijke versie.

@HenriKorver
Copy link
Collaborator

@MNIJ Zie de nieuwe versie van de OAS via redoc.

Hierin heb ik de resource /objectinformatieobjecten uitgebreid zodat deze resource kan worden hergebruikt voor relaties tussen informatieobjecten. O.a. heb ik de waarde informatieobjecttype toegevoegd aan de enum van objectType.

Voorbeeld:

POST /objectinformatieobjecten

{
  "object": "[url naar document 1]",
  "informatieobject": "[url naar document 2]",
  "objectType": "informatieobject",
  "naamRelatie": "heeft_als_gestempelde_versie",
  "naamInverseRelatie": "is_een_gestempelde_versie_van"
}

@hdksi
Copy link
Collaborator

hdksi commented Apr 19, 2023 •
edited
Loading

Ten langen leste nog een duit in het zakje ten aanzien van vorm en inhoud van de voorgestelde oplossing.

Te beginnen met de vorm. De 'koppeltabelvorm' waarvoor nu gekozen is lijkt me in principe een goede oplossing. Maar waarom wordt het generieke 'system endpoint' object-informatieobject gebruikt voor het vastleggen van relaties tussen informatieobjecten en wordt daarvoor niet een specifiek endpoint informatieobjectrelaties of iets dergelijks toegevoegd? Dat levert volgens mij alleen maar voordelen op:

  1. de kans op verwarring over het doel van het bestaande 'system endpoint' en daaraan gerelateerd (onbedoeld) ongeoorloofd gebruik - lees: het endpoint direct aanspreken voor registratie van relaties tussen informatieobjecten en andersoortige objecten - neemt af want je spreekt dit endpoint als consumer eenvoudigweg onder geen enkele omstandigheid aan;
  2. het maakt expliciet dat altijd referenties naar twee objecten van het type informatieobject moeten worden aangeleverd, en dus
  3. neemt het de noodzaak een objecttype te specificeren weg (dat is immers altijd informatieobject);
  4. neemt het de noodzaak weg voor de volgens mij nauwelijks afdwingbare - want hoe valideer je dit? - regel "dit endpoint mag je [behalve als je de Zaken API, Besluiten API of andere relatiesynchroniserende component bent, IH] alleen aanspreken als het objectType de waarde informatieobject heeft", en
  5. het maakt het, nu of in de toekomst, mogelijk relaties tussen informatieobjecten specifiek (dus onafhankelijk van relaties tussen informatieobjecten en andere objecten) nader te beschrijven (zie ook mijn pleidooi om dat nu te doen hieronder).

Over wat er 'onder water' met deze relaties gebeurt heb ik geen mening. Prima als ze samen met andere 'informatieobject-objectrelaties' in één databasetabel worden weggeschreven.

Dan de inhoud. Daarbij vind ik de opmerking van Michiel over 'versieverwarring' belangrijk. Ik ben bang dat we ons over het helemaal vrijlaten van typering van relaties tussen informatieobjecten over tien jaar, dan aankijkend tegen een onontwarbare en in ieder geval geautomatiseerd niet te interpreteren kluwen relaties tussen informatieobjecten, voor de kop zullen slaan dat we het zover hebben laten komen.

Ten allerminste (en ook omwille van comptabiliteit met e-depots en RM-systemen) zou ik daarom de relatietypen voor informatieobject uit MDTO (zie hieronder) als enumeratie of voorgeschreven waardelijst willen opnemen, liefst aangevuld met daarop voortbouwende meer specifieke en dus betekenisvolle aanduidingen waarvan we weten dat ze veel (gaan) voorkomen als "is publiceerbare (want geanonimiseerd alleen ≠ publiceerbaar) versie van"/"heeft publiceerbare versie", "vervangt ongestempelde versie"/"vervangen door gestempelde versie" of iets dergelijks. Deze specifieke aanduidingen kunnen dan bij migratie naar systemen die ze niet ondersteunen eventueel weer worden gegeneraliseerd. Bovenstaande verhindert uiteraard niet dat daarnaast (aanvullend!) de mogelijkheid blijft bestaan in een meer vrije vorm een nadere typering of beschrijving van de relatie te geven.

Label Betekenis Overeenkomstig Dublin Core label
Heeft Versie Een gerelateerd object dat een versie, editie of een aanpassing is van het beschreven object. dcterms:hasVersion
Wordt aangehaald door Een gerelateerd object dat refereert aan, citeert of op een andere wijze verwijst naar het beschreven object. dcterms:isReferencedBy
Is vervangen door Een gerelateerd object dat het beschreven object vervangt, verdringt of opvolgt. dcterms:isReplacedBy
Is vereist door Een gerelateerd object dat het beschreven object nodig heeft ter ondersteuning van de functie, levering of coherentie. dcterms:isRequiredBy
Is een versie van Een gerelateerd object waarvan het beschreven object een versie, editie of een aanpassing is. dcterms:isVersionOf
Refereert aan Een gerelateerd object waarnaar wordt gerefereerd, uit wordt geciteerd of op een andere wijze naar wordt verwezen door het beschreven object. dcterms:references
Vervangt Een gerelateerd object dat wordt vervangen, verdrongen of opgevolgd door het beschreven object. dcterms:replaces
Heeft nodig Een gerelateerd object wat het beschreven object nodig heeft ter ondersteuning van de functie, levering of coherentie. dcterms:requires

@MNIJ
Copy link

MNIJ commented May 4, 2023 •
edited
Loading

Ik was initieel wel gecharmeerd van de oplossing om hiervoor het bestaande object-informatieobject uit te breiden. Maar het heeft ook diverse nadelen, zoals hierboven beschreven door @hdksi. Met name het punt dat dit endpoint expliciet is aangemerkt als een interne die niet door consumers aangesproken hoort te worden. Maar ook:

  • Het is verwarrend om een relatie tussen twee documenten vast te leggen in een koppelobject waarbij de ene in een property informatieobject zit en de andere in een property object, terwijl het allebei informatieobjecten zijn die niet per se een hiërarchische verhouding hebben.
  • Het is in deze oplossing nodig om 2 calls te doen naar GET /object-informatieobjecten om alle relaties van een enkel document op te vragen, het kan immers in beide properties zitten.

Het lijkt me dus zowel zuiverder als praktischer om het met een nieuw en specifiek koppelobject te doen.

Wat betreft deze suggestie van @HenriKorver

Wel denk ik erover om het attribuut andereVersies bij een zaak zoals gespecificeerd in de OAS van mijn voorstel te handhaven, maar nu als een read-only veld. Dus de schrijfacties vinden dan plaats via een losse cross resource zoals /gerelateerdeInformatieObjecten of iets dergelijks, nog even zoeken naar een goede naam. En de leesacties kunnen zowel op deze cross resource als op de /zaken resource worden uitgevoerd. Dit laatste is bedoeld als conveniance richting de client-developer. Kun je jezelf vinden in deze gecombineerde oplossing?

Daar heb ik geen bezwaar tegen. Maakt het iets complexer aan de DRC kant, maar is wel praktisch voor consumers.

@HenriKorver
Copy link
Collaborator

HenriKorver commented May 5, 2023 •
edited
Loading

Eens met @hdksi en @MNIJ om toch maar een separaat endpoint te introduceren om documenten aan elkaar te kunnen relateren. Ik zal hiervoor een nieuw voorstel doen.

Wat betreft mijn eerdere suggestie om de resource /enkelvoudiginformatieobjecten uit te breiden met read-only velden als gemak richting de consumers ben ik nu van mening deze extra feature uit te stellen tot een latere release en eerst af te wachten of er echt vraag naar is.

Alleen ben ik er nog niet helemaal uit hoe we het potentiële wildgroei probleem van verschillende relaties tussen documenten kunnen tackelen. Ik zie nu de volgende scenario's:

  1. Vrijhouden van typering van relaties en duizend bloemen laten bloeien (conform het huidige voorstel).
  2. Enumeraties met relatietypen (geanonimiseerd, gestempeld, etc.). Elke keer als er een nieuwe relatie nodig is zal er een nieuwe versie van de Documenten API moeten worden uitgebracht.
  3. De typen relaties beheren in de Referentielijsten API. In dit geval hoef je geen nieuwe versies van de api uit te brengen zoals bij 2.
  4. De typen relaties beheren in een spreadsheet die door de VNG als standaard wordt verklaard. In dit geval zijn we niet afhankelijk van een productieversie van de Referentielijsten API.

Alle scenario's hebben voor- en nadelen.

@HenriKorver HenriKorver moved this from Done to In Progress in Kanban bord API's voor Zaakgericht werken May 8, 2023
@HenriKorver
Copy link
Collaborator

HenriKorver commented May 15, 2023 •
edited
Loading

Eens met @hdksi en @MNIJ om toch maar een separaat endpoint te introduceren om documenten aan elkaar te kunnen relateren. Ik zal hiervoor een nieuw voorstel doen.

Zie #2240 voor het beloofde nieuwe voorstel. In dit voorstel heb ik gekozen voor scenario 4 dat me voor nu het beste lijkt:

  1. De typen relaties beheren in een spreadsheet die door de VNG als standaard wordt verklaard. In dit geval zijn we niet afhankelijk van een productieversie van de Referentielijsten API.

Echter deze keuze kan nog vrij eenvoudig worden veranderd wanneer er voortschrijdend inzicht is.

@michielverhoef
Copy link
Collaborator

  1. De typen relaties beheren in een spreadsheet die door de VNG als standaard wordt verklaard. In dit geval zijn we niet afhankelijk van een productieversie van de Referentielijsten API.

Om versnippering tegen te gaan zou ik dit liever een tabel met bijbehorende business rule (DCR-xxx) in de aanvullende documentatie laten zijn. Dat scheelt bovendien een aparte "tot standaardverklaring".

De (denk ik) beste oplossing is no 3 maar vanwege de haflbakken status van de Referentielijsten API lijkt het me niet verstandig nog meer afhankelijkheden te maken.

@HenriKorver
Copy link
Collaborator

Om versnippering tegen te gaan zou ik dit liever een tabel met bijbehorende business rule (DCR-xxx) in de aanvullende documentatie laten zijn. Dat scheelt bovendien een aparte "tot standaardverklaring"

Eens, punt 4 is heel generiek geformuleerd. In het concrete voorstel #2240 laat ik de tabel ook onderdeel zijn van de aanvullende specificatie van de Documenten API.

@michielverhoef
Copy link
Collaborator

Er is een relatie met #2241

@HenriKorver HenriKorver moved this from In Progress to Done in Kanban bord API's voor Zaakgericht werken Mar 13, 2024
@HenriKorver HenriKorver moved this from Done to In Progress in Kanban bord API's voor Zaakgericht werken Mar 13, 2024
@HenriKorver HenriKorver moved this from In Progress to Geparkeerd in Kanban bord API's voor Zaakgericht werken Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@HenriKorver HenriKorver

Labels
user story
Projects
Kanban bord API's voor Zaakgericht werken
Status: Geparkeerd
Milestone
No milestone
Development

No branches or pull requests