Bepaalt het DMS de documentversie?

Ken de discussie van jaren geleden. Toen was de stelling dat de praktijk is dat je bewerkingen op documenten (incl. versies bijhouden) soms het liefst doet in een zelf gekozen omgeving die informele, makkelijke samenwerking mogelijk maakt. En dat is niet altijd het DMS. Wat vaak vooral wordt ingezet voor opslag van documenten die een meer formele status hebben. Het ligt dus sterk aan de omstandigheden en aan de rol die je het DMS toebedeelt. Zelf ben ik geneigd versienummering flexibel te houden (zoals het is blijkbaar) omdat je daarmee het best lijkt aan te sluiten bij hoe de praktijk er uit ziet.

De praktijk is dat veel bestaande DMS oplossingen het versienummer van een document zelf bepalen. Het lijkt me niet verstandig om deze functionaliteit te wijzigen. Dus mee eens om het DMS het versienummer te laten bepalen.

Mijn punten ter reactie:

1. Hier wil ik graag meer reacties op hebben dan alleen de genoemde. Dus lezers, reageer, waarvoor bij voorbaat dank.
2. RGBZ stelt alleen "Aanduiding van de bewerkingsfase van het ENKELVOUDIG DOCUMENT". Dit geeft in elk geval de ruimte om keuzes te maken naar inzicht van de werkgroep.
3. Zelf lijkt me de suggestie van Dennis prima. Zijn we er zeker van dat er geen functionele behoefte is om dit te kunnen overrulen?
4. In paragraaf 2.1 van de specificatie is de Documentversie geen onderdeel van de informatie die zich zowel in het ZS als in het DMS bevindt. Waarom zou deze informatie dan teruggegeven moeten kunnen worden richting het ZS? Veld maakt wel deel uit van de vragen die aan het ZS gesteld moeten worden. Als teruggave van dit veld nodig is, moeten we volgens mij de standaard daar op aanpassen qua benodigde te synchroniseren velden. Eens?
5. In paragraaf 2.1 van de specificatie is de Documentversie een optioneel veld in tabel 1 (RGBZ-attributen in DMS). Zou dit dan niet een verplicht veld moeten zijn?
6. Dit item is in mijn lijst geregistreerd als item ZDS-36. Wellicht ter bespreking voor volgende werkgroepbijeenkomst?

Het lijkt mij inderdaad niet wenselijk twee verschillende versienummeringen te hanteren. En aangezien een CMIS compliant DMS zelf het versienummer toekent lijkt het mij de beste keuze deze te verwijderen uit de StUF-kennisgevingen (van voegZaakdocumentToe, etc.). Synchronisatie van dit gegeven met het Zaaksysteem lijkt mij niet nodig. Het gegeven kan worden opgevraagd via geefZaakdocumentLezen en geefZaakdocumentBewerken. Ik denk niet dat het nodig is dit gegeven verplicht te maken maar heb er ook geen bezwaar tegen als anders besloten wordt.

De discussie hiervoor tendeert er naar dat een applicatie (i.c. een DMS) het versienummer van een document bepaalt. Ik betwijfel of dat de bedoeling is van het RGBZ-attribuut 'Documentversie'. In de definitie staat "Aanduiding van de bewerkingsfase ...". M.i. kan een dergelijke aanduiding alleen door de documentbewerker bepaald worden, niet door een applicatie. Een applicatie heeft immers geen weet van de bewerkingsfase. Verder, het RGBZ is een semantisch model, dat poogt de werkelijkheid te modelleren. Een werkelijkheid waarin mensen documenten maken en updaten en vanuit hun context versies bepalen en van een aanduiding voorzien. Techniek speelt daarbij geen rol, tenzij anders vermeld. Het kan in mijn ogen dan ook niet de bedoeling zijn dat de techniek de waarde van dit attribuut bepaalt. Ik kan me hooguit voorstellen dat een applicatie een technische versieaanduiding genereert omdat die applicatie dat nodig heeft. Aangezien deze voor de gebruiker niet relevant is, wordt deze niet uitgewisseld en zit derhalve niet in het bericht.

Ik heb alle argumenten en discussies nog eens goed doorgespit en ben tot de volgende conclusie gekomen. Deze conclusie verduidelijkt hopelijk de reactie van Arjan maar zie ook bijgevoegd document voor de gebruikte documentatie en argumenten.

Conclusie:

De elementen ZKN:Documentversie en ZKN:Documentstatus vertegenwoordigen de respectievelijke RGBZ attributen en niet het technische attribuut cmis:versionLabel wat door het DMS bepaald wordt.

Het gaat dus om drie verschillende attributen. In Tabel 3: Mapping CMIS-properties op RGBZ-attributen (par 5.3) wordt het attribuut cmis:versionLabel ook niet gemapped naar één van de RGBZ attributen ZKN:Documentversie en ZKN:Documentstatus.

In onderstaande definities van de attributen ZKN:Documentversie, ZKN:Documentstatus en cmis:versionLabel komen de verschillen in functionaliteit en waarde-betekenis naar voren.

cmis:versionLabel Is een readonly attribuut wat door het DMS bepaald wordt en dient niet op het RGBZ:Documentversie attribuut gemapped te worden. Om de oorspronkelijke discussie te beantwoorden:

Het DMS bepaalt de waarde van het attribuut cmis:versionLabel. De waarden van de attributen ZKN:Documentversie en ZKN:Documentstatus worden bepaald door het aanleverende (Zaak)systeem.

De mapping van ZKN:Documentversie op cmis:versionLabel is dus onterecht en niet correct.

Tijdens de afgelopen bijeenkomst van de werkgroep Zaak- Documentservices op 17 oktober jl. kwam dit onderwerp weer ter sprake.

Het verzoek was hier een discussie over te openen maar omdat dit al een bestaand en afgesloten issue is breng ik deze discussie weer onder de aandacht. Wat mij betreft staan de conclusies van de vorige post (inmiddels meer dan 2 jaar oud) nog steeds overeind.

Aanvullend: de mapping RGBZ - CMIS attributen is naar aanleiding van bovenstaande discussie op 12 oktober 2016 bijgewerkt en gepubliceerd op GEMMA Online. Hierin is de mapping van Documentversie op cmis:versionLabel aangepast.