Deze vraag is niet gerelateerd aan https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/stuf-testplatform/dat..., vandaar een nieuwe thread.
In het antwoord op een geefZaakdetails kun je meer dan 1 status terugkrijgen. Ik ben geïnteresseerd in de details én de actuele status van de zaak en wil nu bepalen welke status de laatste is. Daarvoor kan ik gebruik maken van datumStatusGezet en het volgnummer. Logischerwijs, de meest recente datumStatusGezet / het hoogste volgnummer geven de laatste status weer.
Echter, beide velden zijn optioneel. Stel, ze zijn er beide niet. Wat is dan de actuele status? De volgorde van statussen wordt niet voorgeschreven door de standaard: is het de eerste in de lijst? Of misschien de laatste?
De standaard biedt een service geefZaakstatus om de actuele status op te halen, maar dan moet ik als consumer altijd twee calls uitvoeren om de informatie compleet te hebben (en drie als ik ook de lijst met tot de zaak behorende documenten wil zien).
Kan de standaard worden aangescherpt op dit onderdeel door minimaal één van de velden verplicht te maken, zodat je als consumer met 1 query af kan?
De laatste status kan afgeleid worden uit het attribuut ZKN:indicatieLaatsteStatus (in het RGBZ 1: https://www.gemmaonline.nl/index.php/Rgbz_1.0/doc/objecttype/status#Attribuutsoort_Indicatie_laatst_gezette_status )
De omschrijving van dit attribuut: Dit afleidbaar gegeven is toegevoegd omdat het bepalen van de laatst bekende status anders alleen te doen is op basis van analyse van alle statussen van de zaak.
Door dit gegeven mee te nemen in de vraag geefZaakdetails_zakLv01 kan zonder gepuzzel de laatst gezette status opgezocht worden.
Die heb ik over het hoofd gezien. Even de XSD erop nageslagen, ook het element indicatieLaatsteStatus is in het bericht optioneel. Als alles optioneel is, dan is het een free format waar je eigenlijk nooit conclusies aan kunt verbinden...
In het bericht geefZaakdetails bepaalt de vraagsteller welke gegevens hij wil ontvangen. Dit gebeurt met behulp van de scope in het bericht.
Weliswaar zijn de velden in het bericht optioneel (zodat een vraagsteller die niet geinteresseerd is in bepaalde informatie deze ook niet verplicht mee krijgt in een bericht waardoor dit onnodig groot wordt) maar de provider (het zaaksysteem) is wel verplicht deze te kunnen leveren. Overigens is het attribuut indicatie Laatst Gezette Status volgens het RGBZ 1 verplicht.
Wij testen met drie verschillende zaaksystemen en sturen een vraag geefZaakdetails met scope="alles". De antwoorden die we terugkrijgen verschillen van elkaar, implementaties verschillen en mogelijk zijn ze niet allemaal correct ook al valideren ze tegen de XSD.
Het zou fijn zijn als in een volgende versie van de standaard dit soort verplichtingen ook in de berichten worden afgedwongen.
In de specificaties staat nu:
Dit interpreteer ik als wanneer een status terug gegeven wordt de volgende gegevens in het bericht opgenomen moeten worden:
Ik heb onderhoudsverzoek 489657 aangemaakt om deze gegevens ook verplicht in het bericht op te nemen.
Ah, top! Dat platform voor onderhoudsverzoeken kende ik nog niet, goed om te weten dat die bestaat.
Even helemaal off topic:
Als ontwikkelaars zijn we afhankelijk van de publicatie van zip bestanden om gemmaonline en hebben niet echt inzicht / overzicht in wat er aan wijzigingen in een nieuwe versie zit of gaat komen. Is er binnen KING weleens nagedacht om over te stappen op een platform als bijv. Github? Dat zou heel veel voordelen hebben, bovendien is het gratis voor open source projecten. Het kan ook bijdragen aan het creëren van een community, leveranciers die een bug vinden kunnen zelf de oplossing aandragen middels een pull request. Dit werkt erg prettig en zou de doorontwikkeling een boost kunnen geven, je maakt je minder afhankelijk van de huidige capaciteit.
Het is juist de bedoeling om alle gemeldde issues in Redmine op te nemen. Deze omgeving staat al ruim een jaar alleen-leesbaar open voor iedereen. Dit is aangekondigd op een bijeenkomst van de werkgroep in de zomer van 2016 en staat op de werkgroep pagina op GEMMA Online vermeld
De issues van ZDS staan hier: https://kinggemeenten.plan.io/projects/zaak-en-documentservices/issues
Het lastige van standaardisatie is dat duidelijk moet zijn wat de huidige versie is omdat leveranciers natuurlijk wel dezelfde versies van schema's moeten hebben. Het is niet zo als met broncode dat een gebruiker zelf kan kiezen om de laatste versie op te halen of niet. Wanneer leveranciers een bug vinden kan nu altijd al een oplossing voorgesteld worden.
Een boost voor de doorontwikkeling zou wel kunnen zijn wanneer gemeenten een actievere rol nemen in de werkgroep. Daarmee kan veel beter richting gegeven worden aan de doorontwikkeling dan alleen acteren op gevonden bugs. Bovendien is het voor leveranciers belangrijk wanneer vanuit opdrachtgevers commitment is om de door te voeren wijzigingen ook daadwerkelijk af te nemen en is het voor de opdrachtgevers belangrijk dat leveranciers zich gaan commiteren aan het op standaard wijze implementeren van de oplossingen.
Even een off-topic ondersteuning voor dit super plan. Ontwikkel de standaarden in git, met de volgende voordelen:
Op die manier creëer je echte co-creatie. Het idee van standaarden op https://github.com/kinggemeenten ondersteun ik van harte. Ik kan geen nadelen bedenken.
Ik heb niets tegen GIThub maar zie de voordelen of verschillen niet echt. Als ik kijk naar de Zaak- Documentservices zit eea. nu zo in elkaar:
Vanuit de werkgroep heb ik het signaal van behoefte aan een GIThub/development branch om verder te ontwikkelen nog niet gekregen. Sterker nog, er zijn nog wel wat partijen die de huidige versie nog moeten inbouwen... Ik vraag me dan ook serieus af hoeveel animo er is voor zoiets. Mocht er een partij zijn die deze werkwijze wel ziet zitten zie ik de aanmelding voor de werkgroep graag tegemoet!
Ik denk dat het onderwerp Github of een soortgelijke oplossing beter in de StUF-regiegroep besproken kan worden. Het gaat breder dan alleen de Zaak- en documentservices. Het is ook niet zo dat het dan gaat om een nieuwe 'versie' van de standaard, ik kan het argument 'Sterker nog, er zijn nog wel wat partijen die de huidige versie nog moeten inbouwen...' dan ook niet goed plaatsen.
Waar het ons als leverancier omgaat is transparantie en dan niet alleen in doorontwikkeling, maar ook in de samenhang tussen de verschillende deelproducten. Nu zijn het allemaal losse zip files. Als leverancier van een regiesysteem voor het sociaal domein worden we geacht verschillende vormen van te StUF ondersteunen: StUF-ZKN, StUF-BG, Zaak- en documentservices, Regie- en zaakservices en StUF-Jeugdzorg (CORV). Allemaal zijn ze te downloaden in een eigen zip file met een eigen versie.
Buiten deze bestanden is er nog een StUF 3.01 zip file te downloaden waarvan periodiek een patch level wordt uitgebracht. De samenhang tussen al die bestanden en en versies is niet transparant. Een publieke Git repository met daarin de volledige standaard inclusief alle eindproductstandaarden en een duidelijk model van branching en tagging (Git flow?) zou daarin het nodige aan duidelijkheid verschaffen.
In mijn vorige reactie noemde ik al het voordeel van pull requests waarbij leveranciers bugs of wensen als pull request in kunnen dienen. Het is dan een kwestie van een druk op de knop om zo'n wijziging upstream mee te nemen. Dat scheelt tijd en zorgt ervoor dat je sneller patches kunt uitrollen. Met zijn allen houden we de kwaliteit hoog. Doordat je met berichten op pull requests kunt reageren houd je codewijzigingen en discussies bij elkaar.
De combinatie van code repository, pull requests, wiki en issue tracker zoals Github dat biedt (maar bijvoorbeeld ook Bitbucket of Gitlab), maakt dat je niet een aparte issue tracker, een website met downloads, een discussieforum en je achterliggende code repository (-ies?) handmatig moet onderhouden.
Ik zal deze reactie ook als nieuwe discussie plaatsen in het StUF 3.01 forum om de animo voor dit onderwerp te polsen. Met datumStatusGezet en volgnummer als titel zal die sowieso niet op gang komen ;)
Reactie is weliswaar wat aan de late kant, maar beter laat dan nooit. De leden van de werkgroep RSGB bevragingen hebben eenzelfde oproep gedaan om de ontwikkeling van standaarden in Github te doen. Echter, met alleen co-creatie in github gaan we ons doel niet bereiken. Zonder afspraken over de criteria waaraan standaarden moeten voldoen, worden de lange termijn doelstellingen voor standaardisatie niet behaald. Kortom, co-creatie met Github is geen holy grail, maar absoluut onmisbaar bij de toetsing van bijdragen, bijvoorbeeld op eigenschappen als genereerbaarheid.
@Michiel Verhoef: de suggestie dat KING in z'n eentje zowel (door)ontwikkeling van standaarden als de toetsing aan (nieuwe) criteria op zich neemt is niet houdbaar om snel en accuraat in de behoeften van gemeenten te voorzien. De kennis en tooling van leveranciers en gemeenten zijn hierbij onmisbaar!
@Cathy: bedankt voor je bijdragen. Ik had liever gezien dat die toegevoegd waren aan de discussie die Rens hierover gestart is: https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/stuf-301/voorstel-beheer-van-schemas-github
Dan houden we deze discussie op de inhoud.
@Michiel: dat is prima, en dat heb ik alsnog gedaan. Op de inhoud.