KING Aan Deelnemers StUF Expertgroep CC tijd/locatie 9:30 12:30 Utrecht (Regardz La Vie) Betreft/datum Aanwezig: Henri Korver (KING, voorzitter) Robert Melskens (KING, notulist) Jan Campschroer (KING) Maarten van de Broek (MessageDesign) Han Welmer (GeoTax) Erik de Lepper (Circle Software) Wouter Wigman (Roxit) Ruud Kathmann (Waarderingskamer) Annemiek Droogh (Waarderingskamer) Ton Timmermans (Pink Roccade) Sid Brouwer (Centric) Henry Verdonschot (Procura) Mark Paanakker (GouwIT) Paul Keverkamp (Gemeente Breda) Afgemeld: Marco Aarts (ICTU) Hans Harskamp (Gem. Woerden) 1. ing en mededelingen Henri heet iedereen welkom. Henri constateert een nieuw gezicht en stelt voor om een voorstelrondje te doen. Paul Keverkamp is recent begonnen bij de gemeente Breda. In het verleden heeft hij ook al bij andere gemeenten gewerkt. In het verleden is hij ook al in aanraking gekomen met de StUF Expertgroep en KING. Henri vindt het heel goed dat er weer een vertegenwoordiger van de gemeentes aansluit. Ook de anderen stellen zich even voor. Robert meldt dat er een nieuwe versie van StUF-RIHa is opgeleverd door het ICTU. Deze is te vinden in de StUF deelcommunity. Henri meldt namens Johan Boer dat de consultatie van het WABO-BAG koppelvlak 175 commentaren heeft opgeleverd, Daar zaten geen blokkerende commentaren bij. Alle opmerkingen zijn overigens al verwerkt. Ruud zegt dat we in het verleden al discussies hebben gehad over wat we met al die BAG koppelvlakken moeten. Hij krijgt hier het idee dat ook dit koppelvlak gepromoot wordt als weer een BAG koppelvlak terwijl wij eigenlijk liever hadden gezien dat het een generiek BAG koppelvlak zou zijn. Hij maakt zich daar wat zorgen over. Sid gaat hier op in en zegt dat dit koppelvlak meer een proceskoppeling is. Het is meer een WABO-BAG dan een BAG-WABO koppelvlak. Het gaat hier meer om het zaakgericht afhandelen van allerlei aanvragen. Henri geeft aan dat Ruud zich niet zo veel zorgen hoeft te maken. 1/11
2. Goedkeuring notulen vorige vergadering (inclusief actie- en besluitenlijst) Sid doet nogmaals het verzoek om het verslag eerder te verzenden. Henri geeft aan dat dit helaas de afgelopen maand niet gelukt is maar dat we zeker van plan zijn om dat voortaan te doen. 2: De hele behandeling van project Utrecht is voor Ruud nog steeds wat warrig. Volgens hem gaat het over een aantal belangrijke zaken die gevolgen voor ons hebben. Ruud begrijpt niet hoe een weging van de inbreng heeft plaatsgevonden. Jan licht het e.e.a. toe. Er zijn nu een aantal RFC's gedefinieerd. Daarvan zijn er 6 waarvan de kans groot is dat deze geaccepteerd gaan worden. De andere RFC's worden herschreven en zullen nogmaals passeren. We proberen uiteindelijk 1 voorstel te krijgen die bij de verschillende standaarden geaccepteerd en doorgevoerd gaan worden. De wijziging voor de ene partij is wat groter dan voor de andere. Ruud constateert dat er voor heel veel voorstellen geen StUF mening is. Hij heeft het idee dat het project Utrecht de conclusie zou kunnen trekken dat een bepaalde kant de juiste kant is om op te gaan en dat wij als StUF Expertgroep daarbij wat aan de zijkant staan. Jan zegt dat er nog een voorstel wordt geschreven door Arnold Reinders met betrekking tot de governance, hij zal dit doorsturen (Actiepunt 434: Jan). Ruud vraagt hoe de besluitvorming van project Utrecht plaatsvindt. Henri geeft aan dat dit de eerste keer is dat dit traject wordt doorlopen en dat er nog geen beheermodel is. Er wordt op dit moment een klein beetje op ad hoc basis ingeschoten. Ook wij zijn daarin nog aan het zoeken naar de juiste weg/balans. Jan gaat proberen om hier meer duidelijkheid over te geven (Actiepunt 435: Jan). Ruud is bang dat er voorstellen van project Utrecht komen waar wij niet blij mee zijn maar die wij wel door moeten voeren. Han zegt dat elke organisatie zelf bepaald hoe de wijzigingen in de eigen organisatie worden doorgevoerd. Henri zegt dat de bezwaren die zijn besproken zijn ingediend. Deze zijn vooralsnog niet afgewezen. Ruud zegt dat wij van StUF op sommige punten aangeven dat we daar meerdere meningen over hebben. Henri geeft aan dat dit inderdaad niet goed is en belooft het op te pikken. Sid constateert dat actiepunt 428 al is afgehandeld terwijl dit nog niet door de StUF Expertgroep is afgehandeld. Robert geeft aan dat als hij in de periode voorafgaand aan de volgende StUF Expertgroep een actiepunt afhandelt hij dit ook meteen aangeeft. Er wordt afgesproken dat hij dat niet meer doet. Actiepunten blijven voortaan open staan totdat ze zijn afgesloten door de StUF Expertgroep. 359: Dit punt mag afgevoerd worden. 396: Dit punt wordt de volgende keer op de agenda geplaatst. 402: Dit punt blijft open staan. 414: Dit punt blijft open staan. 430: Dit punt blijft open staan. In de definitie 'punten' wijzigen in 'RFC's'. 431: Dit punt blijft open staan. 433: Jan is hier al wel mee bezig maar hij heeft nog geen bespreekbaar stuk. Hij constateert dat het een meerkoppig monster is. Dit wordt morgen ook besproken in de Informatiemodellen werkgroep. De notulen worden goedgekeurd. 3. Goedkeuring uitgewerkte errata ERR0320:Mark vindt het jammer dat het op deze manier moet worden opgelost. Henri legt nog even uit dat hier echt sprake is van een schema fout. Deze wordt hiermee opgelost. De StUF Expertgroep keurt het voorstel goed. ERR0321:Ton vraagt zich af waarom er in de nieuwe rij van tabel 5.5 in de kolom 'verwerkingssoort van de Topfundamenteel' nog 'W/I/V/S' staat. Dit moet 2/11
naar zijn mening 'V' zijn. De rest van de StUF Expertgroep is het daarmee eens. Maarten zegt dat het ook niet het oude voorkomen moet zijn maar het huidige. Na wat discussie is iedereen het daarmee eens. De StUF Expertgroep keurt het voorstel goed er van uitgaand dat de aangegeven wijzigingen worden doorgevoerd. ERR277: Maarten merkt op dat er nu heel veel herhaald wordt wat al ergens anders beschreven staat ('vertaling0204vs0301.pdf'). Dit is voor de onderhoudbaarheid en begrijpelijkheid niet goed. Henri vraagt of er dan überhaupt nog wel wat gewijzigd moet worden. Ton zegt dat er wat hem betreft nog wel wijzigingen nodig zijn. Zo kan er een toelichting op de historie worden opgenomen. Maarten zegt dat de algemene toelichting op de mapping wellicht verbeterd moet worden. Op de generieke tab zou je dan een extra verwijzing op kunnen nemen. Henri constateert dat we hiermee dus nog aan de slag moeten. Henri geeft aan dat als er iets niet helder is in de generieke mapping dat dit dan ook gemeld moet worden. Henri en Robert pakken dit punt nog een keer samen op. Erratum gaat niet mee in de patch van 1 juni. 4. Backwards compatibiliteit en errata (Jan Campschroer) Jan leidt het agendapunt in door te zeggen dat Sid ooit de vraag heeft gesteld hoe we om moeten gaan met verbeteringen op fouten waarbij de nieuwe versie niet compatibel is met de oude versie. De zou hier een uitspraak moeten doen. Jan geeft aan dat de StUF Expertgroep naar zijn mening de Regiegroep Berichten en Gegevens StUF/RSGB/RGBZ wel zou moeten voeden met een advies. Jan heeft daarom een aantal alternatieven beschreven. Jan zegt dat je het uitbrengen van een nieuwe versie van de standaard los zou moeten koppelen van het uitbrengen van een nieuwe versie van de software. Naast de wijze waarop je om moet gaan met patches speelt nog de vraag hoe je de besluitvorming zou moeten laten verlopen. Jan is van mening dat je aanpassingen in het beheermodel in de StUF Expertgroep zou moeten bespreken. Henri is het daar niet mee eens en daarom wil Jan dat hier bespreken. Jan geeft aan dat we een aantal alternatieven hebben waar we het over eens moeten zien te worden. Mocht dat niet lukken dan zullen we daarover moeten stemmen. Hij hoopt echter via consensus tot een besluit te kunnen komen. Wouter heeft een voorstel hoe we om zouden kunnen gaan met dit soort issues. Hij vindt het gebruik van extraelementen nu erg beperkt. Je zou deze elementen op meer niveaus aan moeten kunnen brengen. Daarmee kun je dan een overgangssituatie creëren. Henri vraagt zich af wanneer een fout echt noodzakelijk hersteld moet worden. Betreft het een echte fout? Dat moeten we hier dan bespreken. Een echte fout kan echter ook betekenen dat je met de oplossing niet backwards compatibel bent. Henri vindt dat wij in de StUF Expertgroep moeten kunnen beslissen of een erratum doorgevoerd moet worden zelfs als het niet backwards compatibel is. Hij vraagt of iedereen het daarmee eens is. Maarten geeft aan van wel. Henri vraagt daarnaast hoelang het mag duren voordat een partij een patch heeft geïmplementeerd. Han vindt dat een leverancier dat zelf mag bepalen, al duurt het tot Sint Juttemis. Mark is het er over eens dat je daar niets in kunt bepalen. Henri zegt dat de Waarderingskamer wel mag bepalen wanneer een bepaalde patch voor haar software opgelost moet zijn. 3/11
Han denk dat wij als beheerders van de StUF standaard de afwegingen moeten beperken tot de eigen verantwoordelijkheden. Paul vraagt of je dan geen situaties krijgt dat leveranciers niet aan StUF standaard voldoen. Dit blijkt inderdaad de conclusie te zijn. Paul zegt dat gemeenten daar niet blij mee zijn. Sid zegt dat het niet zo zal zijn dat 1 pakket achterloopt, dat zou nog niet zo'n probleem zijn, nee er zullen meerdere pakketten zijn die achterlopen. Han zegt dat je zelfs een situatie kunt krijgen dat 1 pakket de nieuwe patch heeft doorgevoerd en alle andere pakketten niet. Henri zegt dat elke gemeente voor zich moet beoordelen of ze op de nieuwste patch over gaan of op de vorige blijven zitten. KING kan hier niets over zeggen. Han is van mening dat KING er voor moet zorgen dat fouten uit de standaard worden gehaald. Wouter zegt dat ze er daarnaast ook voor moeten zorgen dat noodzakelijke functionele wijzigingen worden uitgebracht. Maarten vindt dat de erratum procedure zich zou moeten beperken tot de basis berichtencatalogi. Alles wat daar buiten valt gaat daar niet in mee. Sid geeft aan dat wij daar wel wat van kunnen vinden en dat we een advies mogen verstrekken. Han zegt dat het niet veel uitmaakt wat voor type bericht het is, een uit de standaard berichtencatalogi of een uit een andere berichtencatalogus. Ook een aanpassing van een bestaand dienstenbericht geeft immers backwards compatibiliteits problemen. Han zegt dat het niet zozeer gaat om welke oplossingsrichting je kiest. Hij geeft als voorbeeld de situatie waarbij je een element mist en somt enkele oplossingsrichtingen op. Maarten probeert de discussie wat scherper te krijgen door te kijken wat de errata zijn. Sid zegt dat de uiteindelijke problematiek hetzelfde is. Maarten zegt dat het voor de complexiteit van de overgang wel uit kan maken of je voor de ene oplossingsrichting of juist voor een andere oplossingsrichting kiest. Han schetst nogmaals een aantal oplossingsrichtingen die je kunt toepassen. Henri zegt dat de oplossingsrichtingen voor een basis berichtencatalogus wat beperkter zijn. Je kunt geen nieuwe berichten toevoegen. Hij zegt dat er nog meer verscherping noodzakelijk is. Henri zegt dat de discussie was 'moeten we aan de Regiegroep Berichten en Gegevens StUF/RSGB/RGBZ voorleggen als een erratum niet backwards compatible is'. Hij vraagt of dat is opgelost als we zeggen dat een patch niet meteen geïmplementeerd hoeft te worden. Sid zegt dat dit niets oplost omdat de leveranciers wel door de situatie of de gemeenten worden gedwongen om te voldoen aan een patch. Henri zegt dat wij niet kunnen bepalen dat alle leveranciers de nieuwe patch moeten gaan ondersteunen. Sid zegt dat we er op moeten letten als de interoperabiliteit in de knel komt. Henri zegt dat het oplossen van een fout een interoperabiliteitsprobleem wel eens groter kan maken. Jan zegt dat als je een fout hebt dat je dan zo snel mogelijk helder moet hebben wat de oplossing is. Daarnaast ga je in een bepaalde situatie kijken hoe je de fout kunt gaan oplossen, evt. al voordat de patch uitkomt. Ton zegt dat je wel als leverancier een oplossing neer kunt zetten maar dat je afhankelijk bent van hoe het landschap er uitziet, de andere applicaties waarmee applicaties koppelen. Maarten zegt dat gemeenten verantwoordlijk zijn voor het bepalen van welke patch ondersteund moet worden. Paul vindt dat leveranciers hier ook een gedeeltelijke verantwoordelijkheid hebben. Dit moet je dus in overleg doen. 4/11
Ruud schetst een situatie waarin het probleem speelt. Erik geeft aan dat je in een bepaalde situatie met een big bang voor al je applicaties over moet naar een nieuwe patch. Ton geeft aan dat het meest zuivere zou zijn om deze errata op te lossen als een RFC. Han zegt dat dit het probleem niet oplost. Sid denkt dat de discussie makkelijker worden als we niet zo star vasthouden aan het niet uitbrengen van een nieuwe versie. Ondertussen verandert er toch al heel veel om ons heen. De keuze om het als een errata of een RFC te behandelen wordt al anders als je weet dat het als een RFC in een release van volgend jaar mee kan gaan. Nu kan dat niet omdat je weet dat als het als RFC wordt geclassificeerd je de oplossing voorlopig niet zult krijgen. Om die reden zul je een RFC misschien wat eerder als een errata willen oplossen. Mark geeft aan dat we inmiddels voldoende RFC's hebben die een nieuwe versie rechtvaardigen. Sid vindt dat we kunnen zeggen dat we elk jaar een nieuwe release op basis van RFC's moeten hebben. Daardoor kan het makkelijker zijn om bepaalde issues niet als een erratum op te pakken maar te wachten totdat deze middels een RFC worden ingevuld. Henri zegt dat we met errata echt alleen de harde fouten moeten oplossen. Een erratum mag geen functionele wijziging zijn. Han zegt dat het in zijn ogen op dit moment niet zo gaat. Han stelt dat het criterium voor de bepaling of een issue een erratum is of een RFC op dit moment is in welke mate het backwards compatibel is. Henri zegt dat een fout vaak niet backwards compatibel is. Dat heb je niet in de hand. Sid zegt dat de essentiële vraag zou moeten zijn 'Is het een fout die er uitgehaald moet worden?' niet 'Is het een fout?'. Sid vraagt zich af waarom we errata oplossen waarin we alleen de structuur van de xsd's aanpassen maar die verder geen verbeteringen op in de interoperabiliteit opleveren. Het kan zijn dat je een fout constateert in StUF waarvoor inmiddels een workarround is, dan kun je je afvragen of we het alsnog met een erratum moeten oplossen. Henri vindt dat een fout mag er alleen uitgehaald mag worden als hij blokkerend is en als we hem niet op een andere wijze kunnen oplossen. Erik vindt het een rare gang van zaken om een erratum als RFC te classificeren om hem door te kunnen schuiven. Henri zegt dat als het een functionele wijziging is die backwards compatibel is dat het dan wel handig is om hem in een erratum op te lossen. Erik zegt dat dit klopt maar dat het niet zuiver is. Jan gaat even terug naar de vraag over releasebeleid. Om die vraag beter te kunnen beantwoorden wil hij graag meer begrip krijgen. Hij vraagt zich af wat het nu aan werk geeft als je nu een nieuwe patch uitbrengt. Hij wil ook graag weten wat voor problemen het oplevert als je de implementatie van een patch uitstelt. Jan wil daarnaast scherpere definities neerzetten voor RFC's, errata, minorreleases, etc... Henri constateert dat er minimaal 4 smaken van wijzigingen zijn: * verbeteren van een blokkerende fout; * verbeteren van een niet blokkerende fout; * functionele aanpassing die backwards compatible is; * functionele aanpassing die niet backwards compatible is. Sid heeft met het oog op dit agendapunt nog een opmerking met betrekking tot het StUF Testplatform. Hij zegt dat het testen van berichten op het StUF Testplatform problemen oplevert omdat het StUF Testplatform alleen de laatste patch ondersteund. Zo komt het voor dat je lang bezig bent geweest om te voldoen aan een patch maar dat je die vervolgens niet meer kunt testen. Het StUF Testplatform zou dus minimaal 2 patches moeten ondersteunen. 5/11
Erik zegt dat dit eigenlijk zelden een probleem op zou moeten leveren omdat patches over het algemeen backwards compatibel zouden moeten zijn. Wouter zegt dat we er aan moeten werken dat we een situatie creëren dat een volgende versie nooit backwards incompatibel kan worden. Zo komen we van de incompatibiliteits problemen af. Henri vindt dat dit een mooie RFC is en zegt dat we in de toekomst daarnaar gaan kijken. Maarten zegt dat als we kijken naar hoeveel patches we het afgelopen jaar hebben uitgebracht die incompatibel zijn dat dan blijkt dat het aantal erg beperkt is. We besteden veel te veel tijd aan een probleem waar we het toch niet over eens worden. Jan vindt de opmerking van Wouter wel hout snijden. Wouter zegt dat we ons beter kunnen concentreren op de volgende versie. Maarten zegt nogmaals dat het aantal backwards incompatibiliteits issues erg beperkt zijn. Ton geeft aan dat er met betrekking tot de BAG berichtencatalogus toch wijzigingen zijn aangebracht die niet compatibel zijn. Jan geeft aan weer een hele hoop input te hebben gekregen. Hij zal weer een rondje langs iedereen gaan maken. Daarbij zal hij een andere oplossingsrichting in ogenschouw nemen. Daarmee de discussie afrondend. Maarten geeft aan nog een vraag te hebben met betrekking het voorstel zelf. Op pagina 3 staat 'we gaan werken met een hoofdversie van 1/7'. Wat wordt daarmee bedoeld. Jan geeft aan dat hij hiermee de patch van 1/7 bedoeld. Hij zegt dat je overal waar 'versie' je ook 'patch' kunt lezen. Ruud geeft aan dat we misschien niet zo krampachtig moeten zijn met nieuwe versies. In een nieuwe versie kun je dan wel alle RFC's in meenemen. Iedereen moet daar dan gewoon rekening mee houden. Hij stelt voor om op vast momenten een patch en een release te doen. Ruud wil weten wat we nu naar de Regiegroep Berichten en Gegevens StUF/RSGB/RGBZ gaan doen. Jan zegt dat we hoogstens gaan melden dat we hiermee bezig zijn (Actiepunt 436: Jan). Jan heeft voldoende input gekregen voor een nieuwe versie van zijn document. Henri vraagt of we het er allemaal over eens zijn dat we de implementatie van een patch loskoppelen van de publicatie van een patch. Kunnen we dit voorleggen aan de RG? Wouter zegt dat we toch wel kunnen zeggen dat we hier niets kunnen zeggen over de implementatie van een patch. Jan meent dat we ook consensus hebben over dat er vanuit de gemeenten geregeld wordt of een patch geïmplementeerd moet worden. Dit is eigenlijk precies wat Henri met zijn uitspraak bedoelt. De StUF Expertgroep blijkt het hier echter toch niet over eens te zijn. 5. Behandelen openstaande errata ERR315 Mapping AOA naar ADR BG0204 niet correct Henri licht het punt nog even toe en bekijkt het voorstel van Robert. Er zijn van twee personen opmerkingen gekomen ban Sid en van Han. Het aanpassingsvoorstel van Sid is redelijk eenvoudig aan te brengen. Er wordt geconstateerd dat de aanpassing ook in de andere richting uitgevoerd moet worden (dus van bg0204 naar bg0310). Han merkte in zijn reactie op dat dit probleem op meerdere locaties speelt. We kijken gezamenlijk even naar een voorbeeld van waar dit het geval is. Binnen TGO komt bijvoorbeeld ook een element 6/11
'aoa.woonplaatswaaringelegen/wpl.woonplaatsnaam' voorkomt. We besluiten om hier, zolang er geen problemen gemeld worden, geen wijzigingen op uit te voren. In de locatie waarop Robert de wijzigingen heeft aangebracht moet volgens Henri ook nog iets gebeuren met 'wpl.identificatie' die eveneens in de groep 'woonplaatswaaringelegen' zit. Sid zegt dat bg204 niet zo'n veld heeft. Volgens Henri is dat er wel in de vorm van een extraelement. Ton geeft aan dat er ook op het extraelement 'woonplaatsnaambag' wellicht nog wat gewijzigd moet worden. Henri constateert in ieder geval dat er nog onduidelijkheid is hoe te mappen en dat KING daarvoor de hulp van de andere StUF Expertgroepleden nodig heeft. Er ontstaat een discussie over het veld 'woonplaatswaaringelegen' tussen Sid en Maarten. Ruud zegt dat we eens moeten kijken of het probleem niet in StUF-BG 3.10 zit en niet in de mapping. Hij licht dit toe. Maarten geeft hem gelijk. Binnen Subject is dit volgens Maarten in ieder geval wel verkeerd gedaan. Volgens Maarten moet er in het keuzeverstuffingsdocument een wijziging worden doorgevoerd met betrekking tot het vullen van platgeslagen elementen. Er ontspint zich een discussie over dit punt. Henri vraagt of er nu een probleem is of niet. Maarten denkt dat er geen probleem in de verstuffing zit. Ruud is daarvan niet overtuigd. Sid zegt dat zolang het probleem zich niet voordoet en het ook nog niet is gemeld we het ook nog niet op hoeven te lossen. Henri vraagt hoe de mapping naar 'wpl.identificatie' moet zijn. Sid zegt dat als er een 'wpl.identificatie' staat in 'woonplaatswaaringelegen' dat deze dan gemapt moet worden naar het extraelement 'identificatiewoonplaats'. In de mapping moet dus in de groep 'woonplaatswaaringelegen' het element 'wpl.identificatie' toegevoegd worden. Methode is analoog aan die voor de 'wpl.woonplaatsnaam'. Henri besluit ook nog even te kijken hoe de mapping naar de andere kant gaat (bg0310 naar bg0204). Erik vraagt of het handig is om dit in dit verband te doen. Henri geeft hem gelijk en zegt dat KING gaat kijken of ze dit met de afzonderlijke personen kan afhandelen. ERR307: Correspondentieadres en andere contactgegevens zitten niet in zaklk01 Erik wil dit graag behandeld hebben. Wouter licht nog even toe waarom het voor Roxit en Circle Software belangrijk is. Naar zijn mening levert dit issue bij zaakgericht werken problemen op omdat het e-mailadres van een aanvrager vaak een andere waarde heeft dan die van de contactpersoon. Juist voor het zaakgericht werken is dit van belang. Mark geeft aan dat je hiervoor een eigen constructie moet gebruiken. Hij licht dit toe. Henri constateert dat je op dit moment geen e-mailadres kwijt kunt in een 'afwijkendcorrespondentieadres'. Volgens Maarten zit het hem in het woordje 'afwijkend'. Ton zegt dat je de verstuffing misschien anders in elkaar moet zetten. Mark zegt dat er een idee zit achter het feit dat dit niet mag. Erik zegt dat bepaalde gegevens niet centraal gearchiveerd mogen worden maar dat je het wel moet kunnen doorgeven. 7/11
Maarten constateert dat er in dit geval een e-mailadres op de relatie zou moeten worden gedefinieerd. Dat betekent een wijziging van het informatiemodel. We moeten dit punt dus bij de Informatiemodellenwerkgroep neerleggen. Wouter constateert dat het door Maarten gehanteerde uitgangspunt dat een zaaksysteem de gegevens uit het gegevensmagazijn moet gebruiken niet correct is. Dit is volgens Maarten, Sid en Mark wel het geval. Henri probeert de discussie wat transparanter te maken door even naar de schemastructuur te kijken. Het toevoegen van een e-mailadres aan een natuurlijk persoon gaat niet daarvoor moeten we bij de Informatiemodellenwerkgroep zijn. Wouter zegt dat voor zaakgerichtwerken de kennisgevingen niet toereikend zijn. Sid concludeert dat Wouter graag een correspondentieadres gedefinieerd zag dat hoort bij een zaak. Dat is echter niet gedefinieerd in het RGBZ. Er ontspint zich een discussie tussen Wouter en Sid. Henri zegt dat Wouter via een zakenbericht het gegevensmagazijn wil updaten. De vraag is of dat mag. Hij vindt het wel een vreemde keuze. Volgens Maarten kan het ook niet. Wouter denkt dat het probleem duidelijk is. Ruud zegt dat het inderdaad in het RGBZ moet worden opgelost. Maarten denkt dat er inderdaad meer aandacht moet komen voor afwijkende gegevens. Henri vraagt zich af of je, als we in die natuurlijke persoon niet alleen de kerngegevens zouden hebben maar ook de andere gegevens, de wijziging van een persoon aan het gegevensmagazijn mag doorgeven?. Maarten zegt dat dat mag als je dat maar afspreekt. Sid zegt dat we dit pas kunnen wijzigen in StUF als deze gegevens in het informatiemodel worden gedefinieerd. Henri vraagt of we het er over eens zijn dat dit een RFC is op het RGBZ en StUF-ZKN. Iedereen is het daarmee eens. Maarten doet Wouter een workaround aan de hand beseffend dat dat niet echt is wat hij wil. Sid denkt dat het afwijkende e-mailadres aan de ROL gehangen moet worden. Wouter gaat een RFC indienen op het RGBZ. Het erratum wordt afgevoerd. ERR293: BRA-HNU woonplaatswaaringelegen Voor Sid is dit een RFC, het gaat immers over een nieuwe versie van het processenhandboek. Henri ziet dit ook zo. Ruud vraagt zich af of dit in de huidige processen niet tot problemen leidt. Het niet beschikbaar hebben van het attribuut 'woonplaatswaaringelegen' zal tot problemen leiden. Sid zegt dat er in het huidige berichtenverkeer een mutatie niet mogelijk is die ook volgens het oude procesenhandboek niet mogelijk is en in het nieuwe wel. Han heeft het gevoel dat het een erratum is. Er is dus geen consensus waarna Henri besluit dat het een erratum blijft. Dit erratum wordt in de volgende vergadering besproken. ERR254: Welke waarde(n) teruggeven bij een vraag op peiltijdstip materieel en formeel? Henri licht nog even toe waar dit erratum over gaat en geeft aan dat hij denkt dat het een RFC moet zijn. Han denkt dat hij heel snel met een antwoord kan komen. Voor Han is het geen RFC. Henri besluit daarop dat het een erratum blijft. ERR303: Dynamisch toevoegen van nieuwe gegevens in een StUF-bericht Dit erratum is in de voorgaande StUF Expertgroep goedgekeurd (zie vorig verslag 8/11
ERR308: agendapunt 4). Belangrijke identificerende gegevens bedrijf zitten niet in zaklk01 Henri licht het erratum nog even toe. Han vraagt of bij een vestiging niet de identificatie van de moederorganisatie zit. Dit blijkt niet het geval te zijn. Sid zegt dat het 'kvknummer' ook niet uniek is en dat het wel gevaarlijk is. Ton geeft aan dat het wel kan helpen in bepaalde situaties (bijv. bij verenigingen). Erik zegt dat bedrijven en vestigingen vaak door elkaar lopen. Erik geeft aan dat zij vaak doen wat Henri voorstelt (in 'vestigingsnumer' het 'kvknummer' plaatsen). Han stelt dat het geen eenvoudig op te lossen probleem is. Henri zegt dat het eenvoudigste is als je in een 'vestigingsnummer' een 'kvknummer' mag zetten. Dit is volgens Han niet correct en het is dus niet eenvoudig op te lossen. Erik geeft aan dat er hele strikte voorwaarden zijn om 'vestigingsnummer' te kunnen misbruiken. Sid vindt de oplossing te dirty. Henri vraagt of een 'extraelement' kan helpen. Han vindt van niet. Henri vraagt of we zien hoe het op te lossen is. Maarten zegt dat we 'kvknummer' dan moeten toevoegen maar dat geeft wel backwards compatibiliteits problemen. Ruud zegt dat zij bij de LV-WOZ tegen vergelijkbare problemen zijn aangelopen. Paul geeft aan dat dit voor gemeenten heel veel gevolgen heeft. Er blijken diverse haken en ogen te zitten aan dit probleem wat volgens Henri wel erg urgent is en hij constateert dat er hier toch snel een bugfix voor nodig is. Sid zegt dat je er niet voor moet gaan om id's te plaatsen in velden die daar niet voor bedoeld zijn. Mark vind dat je ook geen id's moet plaatsen in extraelementen. We gaan het erratum grondig oplossen. Wel moet besloten worden of het backwards compatibiliteits issue blokkerend is. ERR309: Extra verbeteringen synchronisatieberichten Henri schat in dat iedereen het er over eens is dat dit een RFC moet zijn. Iedereen gaat daar inderdaad mee akkoord. ONV0325: Gebruik SOAP 1.1 of 1.2 Henri licht het issue nog even toe. Han geeft aan dat het naar zijn mening een erratum is. De vergadering is het daarmee eens. ONV0326: Foutcodes ten onrechte beperkt tot synchrone kennisgevingen Henri gaat hier even dieper op in zodat we het voor de volgende vergadering duidelijk hebben. Maarten geeft aan waarom het nu gedefinieerd is zoals het gedefinieerd is. Bij asynchrone berichten is er ook vaak geen foutafhandeling gedefinieerd. Een Fo01 is niet van toepassing op een asynchrone kennisgeving. De standaard komt hier dus te kort. Henri geeft aan dat het hele verhaal met foutafhandeling verscherpt en geherstructureerd moet worden en dat we daarvoor al een ander onderhoudsverzoek hebben. Han wil dit in ieder geval heel graag opgelost hebben. De StUF standaard laat nog heel veel open. Henri is van mening dat we het hier echt over moeten gaan hebben. Maarten constateert dat we ook niet altijd alles in een foutbericht moeten willen stoppen. Veel moet toch opgelost worden met het aanpassen van software. Mark merkt op dat het wel van belang is dat de foutmeldingen niet onder tafel verdwijnen. Ruud constateert dat de LV-WOZ weer 9/11
op een punt afwijkt van de StUF standaard. Henri geeft aan dat hij bij CORV fouten in stuurgegevens opstuurt met een Fo01, ook hij wijkt dus af en toe af van de standaard. Het is nog niet duidelijk of het een erratum of een RFC is. 6. Rondvraag en sluiting Sid geeft aan het jammer te vinden dat er in het BAG-WABO koppelvlak een issue zat met camelcase. Naar zijn idee is er een semantisch verschil tussen 'statusnotificatie' en 'statusnotificatie'. Robert geeft aan dat Johan Boer het met hem hierover heeft gehad. Hij zegt dat camelcase niet op zichzelf een doel moet zijn. Het gaat er om dat camelcase de leesbaarheid vergroot. Hij heeft zich echter onvoldoende gerealiseerd dat er een subtiel semantisch verschil zit tussen de eerste camelcase vorm en de tweede ('een notificatiebericht waarin de status wordt gemeld' versus 'een bericht waarin de status van een notificatie wordt gemeld'). Sid zegt dat het voor hem niet blokkerend is. Hij vraagt ons wel om ons wat beter te houden aan de best practices. De vraag is echter of hierover wel iets in de best practices staat. Henri sluit de vergadering. Eerstvolgende vergadering: 18 juni 2014 Actielijst (vaste nummering) StUF Expertgroep 15 mei 2013 359 De StUF Regieroep een beslissing laten nemen hoe wij om moeten gaan met errata die niet backwards compatible zijn. StUF Expertgroep 18 december 2013 396 Agendapunt opvoeren voor volgende StUF Expertgroep m.b.t. de verschillende soorten extraelementen, hun optionaliteit en hun gebruikslocatie. 402 Voorzet in de vorm van een functionele samenvatting maken waarin staat welke richting we uit willen met de StUF onderlaag. StUF Expertgroep 19 februari 2014 414 Duidelijkheid verkrijgen over hoe historie in het RSGB op groepen is gedefinieerd. StUF Expertgroep 16 april 2014 430 Doormailen welke RFC's m.b.t. de onderlaag belangrijk zijn. 431 Kritiek m.b.t. object identificatie posten op het Jan C. Robert Henri KING Allen Ellen Een volgende Afgehandeld 10/11
forum 433 Voorstel uitwerken voor een procedure waarin staat hoe om te gaan met versies, errata, RFC's (versiebeheer) en hoe om te gaan met versienummers. StUF Expertgroep 21 mei 2014 434 Doorsturen rapport van project Utrecht. 435 Duidelijkheid verschaffen over besluitvormingsproces project Utrecht. 436 Melden aan de Regiegroep dat we bezig zijn met een visie omtrent releasebeleid en een aanscherping van het errata/rfc proces. Jan C. Jan C. Jan C. Jan C. 11/11