Reacties consultatie Documenten API 1.5.0 of 2.0.0

[hdksi]

Deze discussie is bedoeld voor reacties bij de consultatie van wijzigingen in de Documenten API die resulteren in een 1.5.0 of 2.0.0-release van de bijbehorende specificaties. Deze zijn ontstaan op initiatief van een aantal gemeenten en leveranciers. De voorafgaande discussie is gedocumenteerd in issue #2242.

De toelichting bij deze wijzigingen is hier te vinden.

De concept-OAS is hier gepubliceerd (Redoc).

Belanghebbenden worden uitgenodigd op ieder onderdeel van de voorgestelde specificaties of de toelichting daarbij te reageren. We hebben echter ook een tweetal specifieke vragen (overgenomen uit de toelichting):

1. We horen graag van belanghebbenden:

   • of het hun voorkeur heeft deze wijzigingen door te voeren in in minor of major versie van de API-specificaties,
   • waarop dit oordeel is gebaseerd,
   • en of zij opmerkingen hebben over het gedrag dat we van API-providers verwachten.

2. Over nut en noodzaak van het opnemen van archiefstatus duurzaam_toegankelijk was tijdens het voorbereiden van bovenstaande wijzigingen geen volledige overeenstemming. Belanghebbenden met inzichten die helpen bepalen of we deze waarde moeten opnemen of niet zijn daarom van harte uitgenodigd die inzichten te delen.

Deze consultatie eindigt op maandag 26 februari 2024.

[WVerdaasGemTilburg]

Hoewel ik de derde archiefstatus duurzaam toegankelijk in essentie snap vraag ik me wel af of je dit op dit niveau moet vastleggen. Je regelt m.i. duurzaamheidseisen in op applicatieniveau waarbij je wellicht achteraf in bulk documenten omzet in een duurzaam formaat als de applicatie dat zelf niet kan.

Ook bij het punt 'Op basis van onveranderlijke informatieobjecten kan een 'werklijst' voor informatiebeheerders worden gecreëerd. Het uitgevoerde werk levert dan een duurzaam_toegankelijk informatieobject op.' heb ik me vraagtekens bij. Ik interpreteer dit punt (wellicht verkeerd) als dat een informatiebeheerder handmatig allerlei controles op duurzaamheidsaspecten op documentniveau moet gaan uitvoeren o.b.v. een werklijst. Kijkend naar het groot aantal zaken en documenten die worden ontvangen en gecreëerd is handmatig uitvoeren van deze controles onbegonnen werk bij mijn gemeente. Wanneer deze controles en evt. omzettingen/aanpassingen niet automatisch kunnen voorzie ik dat van deze status weinig gebruik gemaakt zal worden.

[hdksi]

Ik denk je redenering te begrijpen, maar niet helemaal je conclusie ;).

Juist als je periodiek geautomatiseerd door een externe component de duurzame toegankelijkheid van informatieobjecten bij afgesloten zaken zou laten controleren waarborgen is het onderscheid tussen de archiefstatussen muteerbaar en onveranderlijk toch nuttig? Je selecteert dan voor alle zaken waarvan de eindstatus is bereikt de gerelateerde alle informatieobjecten met archiefstatus onmuteerbaar, laat daar wat controles op uitvoeren als het gaat om compleetheid en juistheid van geregistreerde metadata en regelt eventueel conversie naar een duurzaam formaat. Zijn deze handelingen succesvol uitgevoerd, dan krijgt het informatieobject de archiefstatus duurzaam_toegankelijk toegekend. Dit is precies wat ik bedoelde met een 'werklijst'. Misschien was dat niet voldoende duidelijk?

[WVerdaasGemTilburg]

Ik had het iets anders geïnterpreteerd, maar het is mij duidelijk nu. Eens met het voorstel.

[erikdelepper]

Vanuit de gemeente 's-Hertogenbosch zijn we het eens met het voorstel. Wel hebben we suggesties voor andere waarden bij archiefstatus:
'veranderlijk' i.p.v. 'mutabel', omdat dat meer in lijn ligt met de andere waarden.
'gepreserveerd' i.p.v. 'duurzaam_toegankelijk' omdat toegankelijkheid minder breed is dan preserveren.

[hdksi]

Tegen het wijzigen mutabel naar veranderlijk heb ik geen bezwaar; volgens mij zijn die synoniem, waarbij inderdaad geldt dat het paar veranderlijk/onveranderlijk misschien mooier is. Wellicht dat anderen hier een sterke(re) mening over hebben.

Het wijzigen van duurzaam_toegankelijk naar gepreserveerd zou ik niet adviseren. Preservering is een specifieke, maar niet de enige activiteit die wordt uitgevoerd om de duurzame toegankelijkheid van informatieobjecten te waarborgen. 'Duurzaam toegankelijk' (niet te verwarren met digitale toegankelijkheid is dus juist een begrip met een bredere betekenis dan 'gepreserveerd'.

Bij duurzame toegankelijkheid spelen naast aan preservering verbonden concepten als 'raadpleegbaarheid', 'toegankelijkheid' en 'authenticiteit' ook begrippen als 'vindbaarheid' en 'beschikbaarheid' een rol. Een deel daarvan is uiteraard afhankelijk van méér dan alleen informatiebeheerhandelingen die worden uitgevoerd op individuele informatieobjecten - denk aan de aanwezigheid van een goed classificatiesysteem of het bestaan van een online archiefportaal of studiezaal in een regionaal archief waar het überhaupt ingezien kan worden. Dit soort voorwaarden kan een opgeslagen individueel informatieobject uiteraard niet creëren.

Met duurzaam toegankelijk bedoelen we in de context van de Documenten API daarom dat het informatieobject zo goed binnen de beperkingen van zo'n register mogelijk is voorbereid is op toekomstig gebruik.

[johannesbattjes]

Allereerst onze complimenten voor de zorgvuldige en duidelijke uitwerking.

Wij hebben de voorkeur voor een minor versie en zijn het eens dat deze potentieel breaking is voor clients die hard coded een beperkte lijst waardes in de enum voor status hebben.
De potentiële problemen met deze clients moeten daarom gedetecteerd worden voordat een DRC 1.5 in productie gaat.
De verwachting is dat in ons geval (Fundament) bij deze test geen of hooguit een enkele client deze enum hard coded heeft waarbij de oplossing snel en eenvoudig te maken is.
Een dergelijke test met alle clients zal ook moeten gebeuren voordat we met major versie 2.0 zouden live gaan. De meerderheid van de clients die op dit moment gebruik maken van onze DRC zullen de voorgestelde wijziging namelijk hoe dan ook moeten implementeren.
Een major versie levert daarmee niet minder inspanning op maar meer:

• het maken van een major versie is meer werk dan een minor versie voor developers van onze DRC
• het coördineren van de overgang van alle clients is ingewikkelder (uitleggen aan teams/bedrijven achter alle clients dat ze nieuwe endpoints moeten gebruiken).
  Een ander nadeel is de verwachting: bij een major versie verwacht je grotere wijzigingen dan alleen een nieuwe enumwaarde.

Verder commentaar: we zien in de Redoc voor 1.5.0 nog het volgende staan bij PATCH en PUT: "status NIET definitief".
Deze zou moeten zijn vervallen volgens het voorstel. Kunnen jullie deze verwijderen?
Eventueel zou in een volgende minor versie een nieuwe business rule op archiefstatus kunnen worden toegevoegd conform #2390. Bijvoorbeeld in de trant van "als archiefstatus onveranderlijk is mag het document alleen gewijzigd worden door een applicatie met de scope geforceerd_bijwerken". Omdat dit voorstel nog verder uitgewerkt moet worden stellen we voor dit in DRC 1.6 te doen en niet in de 1.5.

Het voorstel om voor archiefstatus niet "mutabel" maar "veranderlijk" te gebruiken is wat ons betreft prima.

Johannes Battjes en Michiel Nijdam (Roxit)

[HenriKorver]

Verder commentaar: we zien in de Redoc voor 1.5.0 nog het volgende staan bij PATCH en PUT: "status NIET definitief".
Deze zou moeten zijn vervallen volgens het voorstel. Kunnen jullie deze verwijderen?

Gedaan, zie deze commit in de PR.

[CMasselink]

Vanuit Utrecht hebben wij de volgende feedback op het voorstel.
We kunnen ons grotendeels vinden in de wijzigingen maar we hebben wel een aantal vragen / opmerkingen.

property 'archiefstatus'
We hebben onze vragen bij de meerwaarde van de de archiefstatus "duurzaam_toegankelijk".
Duurzaam toegankelijk is een containerbegrip waar best wat aspecten onder vallen (vindbaar, leesbaar, interpreteerbaar, betrouwbaar etc.). en daardoor lastig te vatten in 1 attribuut. Op welk moment geef je een informatieobject het label, als het informatieobject aan alle eisen voldoet of is een beetje voldoen aan een aantal eisen ook al goed?
Als het doel is om aan te kunnen geven dat er voldoende informatie is om te bepalen wanneer een informatieobject vernietigd / bewaard moet worden, kan een informatieobject dan daar wel aan voldoen qua metadata maar niet duurzaam toegankelijk zijn?

property 'bevatNietOpenbarePersoonsgegevens
In hoeverre is hier rekening gehouden met de MDTO waarden Beperking in gebruik? Hierbij geef je de type beperking aan en de beperking die erop zit. Optioneel met een datum. De AVG / de aanwezigheid van persoonsgegeven is dan 1 van de redenen voor beperking in gebruik.
Het advies van onze informatiebeheer experts is om de werkwijze zoals die gehanteerd wordt in MDTO te hanteren voor openbaarheidsbeperkingen.

[hdksi]

Duurzaam toegankelijk is een containerbegrip waar best wat aspecten onder vallen (vindbaar, leesbaar, interpreteerbaar, betrouwbaar etc.). en daardoor lastig te vatten in 1 attribuut. Op welk moment geef je een informatieobject het label, als het informatieobject aan alle eisen voldoet of is een beetje voldoen aan een aantal eisen ook al goed?

Het is lastig generiek te stellen wanneer een informatieobject 'duurzaam toegankelijk' is. De maatregelen die daarvoor nodig zijn kunnen immers afhankelijk zijn van bijvoorbeeld de uitkomsten van een risico-analyse.

Het was mijn verwachting dat het begrip duurzaam_toegankelijk beter begrepen wordt dan het buiten het zaakgericht werken (nog) minder eenduidig gedefinieerde gearchiveerd, maar ik constateer op basis van de reacties bij deze consultatie dat ik me daarin wellicht vergist heb.

In hoeverre is hier rekening gehouden met de MDTO waarden Beperking in gebruik? [...] Het advies van onze informatiebeheer experts is om de werkwijze zoals die gehanteerd wordt in MDTO te hanteren voor openbaarheidsbeperkingen.

We hebben naar MDTO gekeken; het volgen van die standaard heeft ook mijn voorkeur, maar zo'n wijziging vraagt beduidend meer aanpassingen in de standaard omdat het bereik van de resource gebruiksrechten geraakt wordt, terwijl het bovendien gewenst is een (referentie)waardelijst met beperkingen en hun grond mee te leveren.

[w-van-weelden]

Bedankt voor de voorbereiding. Vanuit Centric willen we graag het volgende meegeven:

Major / Minor

De aanpassingen zoals die zijn voorgesteld, leveren breaking changes op API niveau. De NL Design Rules schrijven voor dat dit in een major versie moet worden ondergebracht. Daarmee lijkt het helder dat dit een major versie moet zijn.

Property Archiefstatus

In RGBZ hadden we een archiefnominatie en een archiefactiedatum op het niveau van de zaak. In RGBZ 2.0 is daar een archiefstatus op zaakniveau bijgekomen. Maar nu wordt er een archiefstatus op documentniveau toegevoegd. Daarmee wordt het model wel heel gedetailleerd. Een archiefstatus op zaakniveau lijkt ons voldoende. Mocht de behoefte aan een archiefstatus op document niveau er blijven, dan bevelen we aan om het waardebereik van beide properties gelijk te houden. Op zaakniveau worden de volgende waarden ondersteund:

• nog_te_archiveren - De zaak cq. het zaakdossier is nog niet als geheel gearchiveerd.
• gearchiveerd - De zaak cq. het zaakdossier is als geheel niet-wijzigbaar bewaarbaar gemaakt.
• gearchiveerd_procestermijn_onbekend - De zaak cq. het zaakdossier is als geheel niet-wijzigbaar bewaarbaar gemaakt maar de vernietigingsdatum kan nog niet bepaald worden.
• overgedragen - De zaak c.q. het zaakdossier is overgebracht naar een archiefbewaarplaats.

Waarschijnlijk zijn dan alleen de eerste twee van toepassing op documenten. En dan is nog de vraag of de term ‘archiveren’ hier dan wel de juiste is. Feitelijk geef je aan of het document al dan niet in een wijzigbaar formaat is vastgelegd. Op documentniveau kan in de property ‘status’ op de waarde ‘gearchiveerd’ verwijderd worden. Of een document in wijzigbare vorm is vastgelegd blijkt dan wel uit de property ‘formaat’.

Property bevatNietOpenbarePersoonsgegevens

Dit property weerspiegeld een eerdere discussie: #2240

Het lastige van dit voorstel is dat er meerdere gronden zijn waarop een document (deels) niet openbaar is te maken. Het zou mooier zijn om een property te definiëren voor beperkingen voor openbaarheid met een enumeratie van alle mogelijke uitzonderingsgronden. (En 1 document kan meerdere uitzonderingsgronden van toepassing hebben.)

Ook is het met een property voor uitzonderingsgronden logisch om direct een andere relatie op te nemen met een document wat wél openbaar gemaakt kan worden, bijvoorbeeld omdat het geschikt gemaakt is voor publicatie.

We stellen voor deze property nu niet op te nemen en in plaats daarvan een uitgebreidere oplossing te ontwikkelen.

Duurzaam_Toegankelijk

Of een informatieobject duurzaam toegankelijk is, bepaal je niet op documentniveau, maar op zaakniveau. Zeker in de nieuwe archiefwet gaat het met archiefbescheiden/document/informatie-object/record om het geheel aan gegevens: de zaak.

Voor duurzame toegankelijkheid op documentniveau bestaat de lijst van voorkeursformaten van het Nationaal Archief en dat is af te leiden uit het formaat van het document. Een extra property bij documenten lijkt ons niet nuttig.

[hdksi]

De aanpassingen zoals die zijn voorgesteld, leveren breaking changes op API niveau. De NL Design Rules schrijven voor dat dit in een major versie moet worden ondergebracht. Daarmee lijkt het helder dat dit een major versie moet zijn.

Dit klopt. Zie API-56.

Een archiefstatus op zaakniveau lijkt ons voldoende.

Omdat een informatieobject eerder dan de zaak als geheel gearchiveerd kan worden, is een archiefstatus op informatieobjectniveau inderdaad wenselijk.

Mocht de behoefte aan een archiefstatus op document niveau er blijven, dan bevelen we aan om het waardebereik van beide properties gelijk te houden [met zaken, IH].

Dit vind ik een logisch argument, maar eigenlijk geef je hieronder zelf aan waarom die waarde(n) misschien niet ideaal zijn, want:

En dan is nog de vraag of de term ‘archiveren’ hier dan wel de juiste is.

Vandaar het voorstel de waarde onveranderlijk op te nemen in plaats van gearchiveerd.

Feitelijk geef je aan of het document al dan niet in een wijzigbaar formaat is vastgelegd.

De property geeft inderdaad onder meer aan of het informatieobject nog wijzigbaar is. 'Onwijzigbaar' maken kan meer maatregelen vragen dan alleen een verandering van (bestands)formaat. Denk aan het intrekken van bewerkingsautorisaties.

We stellen voor deze [bevatNietOpenbarePersoonsgegevens, IH] property nu niet op te nemen en in plaats daarvan een uitgebreidere oplossing te ontwikkelen.

Dit is een herkenbare opmerking.

Of een informatieobject duurzaam toegankelijk is, bepaal je niet op documentniveau, maar op zaakniveau. Zeker in de nieuwe archiefwet gaat het met archiefbescheiden/document/informatie-object/record om het geheel aan gegevens: de zaak.

Voor duurzame toegankelijkheid op documentniveau bestaat de lijst van voorkeursformaten van het Nationaal Archief en dat is af te leiden uit het formaat van het document. Een extra property bij documenten lijkt ons niet nuttig.

Op conceptueel niveau klopt dit waarschijnlijk, maar in de praktijk bestaan heel veel documenten buiten de context van een zaak. Op dit moment kunnen we daarmee vanwege de harde koppeling met zaken en zaaktypen in de Documenten API weinig. Maar ik kan me voorstellen dat bijvoorbeeld openbaarmakingsverplichtingen die voorkomen uit de Wet open overheid een vraag met zich meebrengen naar meer 'zelfstandig' duurzaam toegankelijk te beheren documenten. Wellicht is deze verwachting - en het onder meer naar aanleiding daarvan gedane voorstel voor opname van de waarde duurzaam_toegankelijk - onjuist of nu nog niet relevant.

[hdksi]

Beste collega's, hartelijk dank voor jullie uitgebreide en constructieve reacties!

Ik zal deze week nog reageren op de individuele opmerkingen waarop nog niet was gereageerd en op basis van de reacties een voorstel doen voor verwerking in een nieuwe versie van de Documenten API-specificatie.

[hdksi]

Ik beloofde deze week op basis van de ontvangen reacties nog met een voorstel te komen. Bij dezen op de valreep.

Ik begin met de vragen waarbij we specifiek om reacties hadden gevraagd.

1. We horen graag van belanghebbenden:
   • of het hun voorkeur heeft deze wijzigingen door te voeren in in minor of major versie van de API-specificaties,
   • waarop dit oordeel is gebaseerd,
   • en of zij opmerkingen hebben over het gedrag dat we van API-providers verwachten.

In reactie op de vraag naar verwerking van de wijzigingen in een minor- of majorversie zijn twee verschillende antwoorden gegeven. Ik begrijp goed dat implementatie van een majorversie extra werk oplevert. Tegelijkertijd stellen de API-design rules klip en klaar dat "when releasing a new version which contains backwards-incompatible changes, a new major version must be released".

Punt waarover dan nog gediscussieerd kan worden is de vraag of de voorgestelde wijzigingen inderdaad "backwards-incompatible changes" met zich meebrengen. In de toelichting is beargumenteerd dat hiervan in dit geval sprake is. In de opmerkingen hierboven is die argumentatie niet betwist. Naar aanleiding daarvan stel ik voor de wijzigingen op te nemen in een 2.0-versie van specificaties voor de Documenten API.

Bij het punt over verwacht gedrag heb ik één opmerking gezien. Het lijkt me inderdaad goed om te kijken of we de archiefstatus onveranderlijk kunnen verbinden aan een beperking in toegestane scope(s) voor mutaties. Omdat die vraag in deze consultatie niet heeft voorgelegen, stel ik zoals gesuggereerd voor om dit issue voor een volgende versie te bewaren.

Dan de tweede vraag.

2. Over nut en noodzaak van het opnemen van archiefstatus duurzaam_toegankelijk was tijdens het voorbereiden van bovenstaande wijzigingen geen volledige overeenstemming. Belanghebbenden met inzichten die helpen bepalen of we deze waarde moeten opnemen of niet zijn daarom van harte uitgenodigd die inzichten te delen.

Naar aanleiding van drie reacties deze vraag constateer ik dat doel en betekenis van de waarde duurzaam_toegankelijk bij de property 'archiefstatus' onvoldoende duidelijk zijn voor opname in de standaard. Ik stel dus voor de waarde duurzaam_toegankelijk (nu) niet op te nemen. Om de mogelijkheid open te houden dat later alsnog te doen stel ik niet voor van de property een boolean (isOnvervanderlijk o.i.d.) te maken (wat bij twee toegestane waarden wel een mogelijkheid zou zijn).

Dan door naar andere opmerkingen over 'archiefstatus'. Eén reactie stelt voor aan te sluiten bij de toegestane waarden in de Zaken API, echter gevolgd door de vraag of het begrip 'archiveren' - en in het verlengde daarvan de waardenaam gearchiveerd - in het licht van de bedoeling binnen de Documenten API wel de juiste is.

Mede op basis van andere reacties is mijn conclusie dat duidelijkheid en begrijpelijkheid in dit geval boven consistentie moeten gaan. Als waarden voor 'archiefstatus' stel ik daarom de waarden veranderlijk en onveranderlijk voor. Die eerste betekent een naamswijziging ten opzichte van het originele voorstel (muteerbaar), ingegeven door het voorstel van 's-Hertogenbosch waartegen niemand bezwaar had.

Omdat de voor archiefstatus voorgestelde description ("Geeft aan in hoeverre het informatieobject duurzaam toegankelijk is en op het voorgeschreven moment vernietigd of overgebracht kan worden.") zonder de waarde duurzaam_toegankelijk nog moeilijk te begrijpen is, stel ik voor die te wijzigen naar: "Geeft aan of vorm en inhoud van het informatieobject nog aanpast mogen worden, of dat deze het in het kader van archivering zijn bevroren."

Rest nog één discussiepunt; het opnemen van de property 'bevatNietOpenbarePersoonsgegevens'. Omdat twee reacties expliciet vragen om te kijken naar een oplossing die ook voor andere gronden die de openbaarheid beperken voldoet én aansluit bij MDTO, stel ik voor de property 'bevatNietOpenbarePersoonsgegevens' niet op te nemen.

Het voorstel voor een volgende versie van de Documenten API zou een zoveel mogelijk bij MDTO aansluitend mechanisme moeten omvatten dat registratie van verschillende gronden die openbaarheid en gebruik beperken mogelijk maakt. Hiervoor is een issue (#2419) aangemaakt.

In deze reactie niet besproken wijzigingen nemen we volgens voorstel op.

Komende week maken we naar aanleiding van deze bevindingen een OAS voor versie 2.0 van de Documenten API-standaard. Ook gaan we aan de slag met het verwerken van deze wijzigingen in de referentieimplementatie bij deze standaard.

[johannesbattjes]

We zijn erg teleurgesteld dat versie 1.5, die oorspronkelijk al eind december gereed zou zijn, nu niet komt.

Duizenden VTH-medewerkers die (vaak zonder dat te weten) deze standaard dagelijks gebruiken zijn hiervan de dupe.
In plaats daarvan komt een 2.0 die meer tijd zal nemen om in gebruik genomen te worden.
Bovendien ontbreekt nu ook een van de belangrijkste functies (bevatNietOpenbarePersoonsgegevens).
De daarmee samenhangende functie "andere versies" (#2079 (comment)) was al eerder afgevallen op verzoek van VNG om een snelle 1.5 mogelijk te maken.
Nu alles opnieuw vertraagt stellen wij het volgende voor:

een (snel te publiceren) 1.5 met alleen:

• property 'inhoudIsVervallen'
• laten vervallen van de regel 'status NIET definitief'

een 2.0 met

• bevatNietOpenbarePersoonsgegevens (met de nu voorgestelde uitzonderingsgrond-waardes)
• uitbreiding van de waardelijst voor status zoals voorgesteld
• property 'archiefstatus'
• mogelijkheid voor het relateren 'andere versies' (dus een link tussen origineel EIO en geanonimiseerd EIO)

[NolWitte]

Ik deel de teleurstelling van Johannes. Circa 175 collega's van mij zijn deel van de duizenden waar Johannes het over heeft. We zitten echt te wachten op de wijzigingen.

[hdksi]

Ik begrijp jullie teleurstelling. We zijn hiermee al erg lang bezig.

Het voorstel om alsnog een versie 1.5 uit te brengen waarin de property 'inhoudIsVervallen' wordt toegevoegd en bedrijfsregel drc-005 [sorry, in eerste instantie verkeerd begrepen naar welke regel verwezen werd, IH] het deel van bedrijfsregel drc-010 dat gaat over het bijwerken van informatieobjecten met status definitief vervalt, nemen we daarom graag over. We maken daarbij deze week een nieuwe OAS en toelichtende documentatie. vervalt nemen we daarom graag over. We maken daarbij deze week een nieuwe OAS en toelichtende documentatie.

[hdksi]

De naar aanleiding van het voorstel van Johannes voorgenomen wijzigingen voor versie 1.5 van de Documenten API zijn gedocumenteerd in pull request #2423. De bijgewerkte OpenAPI-spec is te bereiken via de links in de documentatie van bovenstaand pull request of via #2421.

Voordat we bovenstaande documentatie releasen, wachten we nog één collegiale review af. Ik verwacht die begin volgende week binnen te hebben.

Verwerking van deze wijzigingen in de referentie-implementatie zal later (maar wel ergens de komende weken) plaatsvinden.

[hdksi]

Ondertussen is de OAS voor versie 1.5.0 van de Documenten API-specificatie gepubliceerd. Hierin opgenomen wijzigingen zijn gedocumenteerd in de bijbehorende release notes.

Een bericht hierover aan belanghebbenden per mail volgt na het doorvoeren van de uit deze versie voortkomende wijzigingen in de referentie-implementatie bij de Documenten API. We verwachten hiervoor ergens de komende twee weken ontwikkelcapaciteit te hebben.