In de bijlage van deze post heb ik een spreadsheet (zowel in .ods als in .xsl formaat) toegevoegd waarin de extra elements zijn geinventariseerd mbt tot de BAG-GBA koppeling. In dit kader heb ik alleen de extra elements beschouwd die betrekking hebben tot de entiteittypen ADR (adres), R02 (straat-tabel) en R03 (woonplaats-tabel).
In het oranje gedeelte van de spreadsheet zijn de volgende kolommen toegevoegd.
Overlap: geeft aan met welke andere elementen een element overlap heeft.
0 = geen overlap
-1 = er klopt iets niet
x/y = element x heeft overlap met y
Accept: geeft aan welke elementen geaccepteerd zijn eventueel onder voorbehoud van een nieuwe naam (zie volgende kolom)
Nieuwe naam: de nieuwe naam van een extra element dat geaccepteerd is
Ik zie graag jullie commentaar tegemoet voor volgende week vrijdag.
Hieronder de reactie van PR.
Het volgende element trekken we terug:
- authentiekeWoonplaatscode
Het volgende element missen we nog:
- indicatieGeconstateerd in de tabel R02 (STT)
Verdere vragen:
zie nieuwe versie attached. Ik heb 'authentiekeWoonplaatscode' verwijderd en ik heb 'indicatieGeconstateerd' toegevoegd onder de nieuwe naam 'geconstateerd' om consistent te blijven met eerdere namen. Verder heb ik nu ook de extra elements bij de entiteit VBO beoordeeld. Niet alle elementen kon ik plaatsen om dat de betekenis niet altijd helder was.
EGEM heeft ook extraElements ingediend vanwege het 'kloppend maken' van de vertaalspecificatie bg0204 <--> bg0310.
Beste mensen,
Uiteindelijk heb ik toch besloten om de eerste lijst van extraElementen die door EGEM gepubliceerd gaat worden te beperken tot alleen die elementen die een rol spelen bij de BAG-GBA koppeling en de vertaalspecificaties (zie bijlage). Deze extra elementen hebben de meeste urgentie. Bovendien is de semantiek van de elementen vrij eenvoudig te definieren omdat deze extra elementen voor bg0204 bijna allemaal afkomstig zijn uit bg0310.
Verder heb ik besloten om de naamgeving van de extra elementen in eigen hand te houden om de consistentie zo goed mogelijk te bewaken. Het 1-op-1 overnemen van ingediende elementen leidde al snel tot onduidelijkheid en inconsistenties. Dit betekent dat ik afzie van een eerder gemaakte afspraak dat extra elementen worden overgenomen op basis van het 'eerst komt, eerst maalt' principe.
Het extra element 'codeGebeurtenis' heb ik ook toegevoegd aan bg0310 om de BAG-GBA koppeling compleet te maken voor beide versies 0204 en 0310. Uiteindelijk zal dit attribuut als officieel metagegeven gedefinieerd moeten worden binnen bg0310 als je het echt netjes wilt doen. Dit is een RFC dat ik zal indienen op het forum.
Indien ik geen reacties ontvang voor volgende week dinsdag einde dag zal ik de lijst de woensdag erna publiceren.
Mvg,
Henri
Beste mensen,
Ik voorzie dat er straks BAG/BWT, BAG/GEO, BAG/xxx koppelingen komen dit ook gebruik gaan maken van dezelfde codeGebeurtenis.
In de omschrijving staat nu "De code voor een gebeurtenis zoals gedefinieerd in de BAG-GBA koppeling" waarmee het gebruik beperkt wordt tot de BAG/GBA koppeling.
Kan deze definitie ruimer opgezet worden zoals bijvoorbeeld "De code voor een gebeurtenis zoals gedefinieerd in koppelingen met de BAG"?
Groeten,
René Kok
René,
Goede observatie, ik zal het aanpassen in de definitieve versie.
Mvg,
Henri
Beste Henri,
Je eenzijdige voornemen om, in tegenspraak met de eerder in de StUF expertgroep gemaake afspraak, de naamgeving van de extraElementen voor de GBA-BAG koppeling in eigen (EGEM) handen te houden, is voor PinkRoccade niet acceptabel. Wij vinden het enerzijds niet correct om de in de StUF expertgroep gemaakte afspraak eenzijdig te wijzigen. Daarnaast was er überhaupt geen afspraak op basis van het "wie het eerst komt, eerst maalt" principe, maar de afspraak dat "elementnamen overgenomen zouden worden van een leverancier indien deze de enige leverancier was die dat element had ingebracht". Indien meerdere leveranciers een element zouden inbrengen en deze elemementen zouden afwijkende namen hebben, dan zou EGEM een keuze maken.
Daarnaast lijkt het erop dat jij en ik een ander beeld hebben van de impact van jouw voorstel voor de huidge operationele koppelingen bij gemeenten. Niet alleen moeten meerdere leveranciers (tenminste PinkRoccade en diverse business- en koppelpartners) die deze elementen inmiddels gebruiken, door jouw voornemen nu hun software aanpassen en in samenhang met elkaar testen, ook verwachten gemeenten (geheel terecht overigens) van leveranciers dat aanpassingen onafhankelijk van elkaar gerealiseerd en geïmplementeerd worden en dat hierbij de compatibiliteit met de voorgaande versie(s) gewaarborgd wordt. Jouw voorstel leidt er nu toe dat wij naast onze huidige extraElementen ook de door EGEM gedefinieerde extraElementen moeten gaan ondersteunen en dat we daarbij tevens compatibiliteit transformaties tussen beide extraElementen moeten gaan opnemen. Het (her)gebruik van reeds bestaande extraElementen van Centric en PinkRoccade voorkomt deze consequentie voor het grootste deel.
Indien er (zoals je stelt) "onduidelijkheid" bestaat over de ingediende elementen, dan zijn wij uiteraard bereid om op korte termijn in een overleg met EGEM en Centric (de enige andere indiener van de extraElementen voor de GBA-BAG koppeling) deze onduidelijkheden samen te bespreken en weg te nemen. Ik zie je reactie graag tegemoet.
Met vriendelijke groet,
John Rooijakkers.
Het opnemen van de codeGebeurtenis als extraElement is in tegenspraak met de afspraak dat de GBA-BAG elementen in StUF BG 03.10 als reguliere elementen opgenomen zouden worden.
Daarnaast heeft de opname als (extra) element diverse nadelen. Feitelijk is de codeGebeurtenis een stuurgegeven en geen element (i.e. eigenschap van het object). Indien tweemaal achtereen op een bepaald object dezelfde gebeurtenis van toepassing is, dan is het niet zeker dat de (ongewijzigde) codeGebeurtenis ook daadwerkelijk in een kennisgeving wordt opgenomen.
Dit laatste is echter een functioneel aspect dat in eerste instantie behandeld dient te worden in de GBA-BAG werkgroep.
Groet, John Rooijakkers.
Beste John,
Ik ben het eens dat we de impact op bestaande software zoveel mogelijk moeten beperken. Helaas wordt dit een moeilijk verhaal omdat bijna alle extraElements die door PinkRoccade en Centric zijn ingediend mbt tot de BAG-GBA-koppeling overlappen. In de bijlage heb ik twee kolommen aan de spreadsheet toegevoegd om de overlap en het verschil in naamgeving tussen PR en Centric elementen aan te geven. Waarschijnlijk is er zelfs meer overlap dan de spreadsheet aangeeft omdat ik niet de betekenis van alle extra elementen die door Centric zijn ingediend volledig heb kunnen doorgronden.
En dan heb ik nog een wedervraag uit nieuwsgierigheid. Stel (in het hypothetische geval) dat PinkRoccade maar één extraElement hoeft aanpassen qua naamgeving. Dan moet je alle koppelingen waarin dat element voorkomt aanpassen en testen. Het maakt dan toch niet veel uit of je één of twintig extra elementen moet aanpassen zolang die maar bij de dezelfde koppeling horen. Of maak ik hier een gedachtenfout?
Mvg,
Henri
Waar is die afspraak gemaakt? Volgens mij niet in de expertgroep. Dat zou ik (als voorzitter) toch gemerkt moeten hebben ;-)
Afspraak of geen afspraak, we kunnen sowieso geen functionele uitbreidingen meer doorvoeren voor de volgende release van bg0310. Dus als je codeGebeurtenis als een regulier element wilt opvoeren dan kom je in de sfeer van een RFC. Op het StUF 3 forum heb ik deze RFC reeds ingediend. Over de uitwerking van die RFC valt inderdaad te twisten en zijn er diverse andere oplossingsrichtingen.
Dag Henri,
Er lopen mijn inziens een aantal zaken door elkaar heen:
1. Het forum is inderdaad samen met de vergaderingen van de Regiegroep en Expertgroep leidend voor besluitvorming
2. Het is niet verboden om ook met elkaar op andere wijzen te communiceren (hiervoor kunnen diverse redenen zijn)
Uiteraard heeft dit geen "formele waarde" zolang zaken niet ingebracht zijn in de eerder genoemde gremia.
Op het forum kan daarnaast (onder andere) geconstateerd worden dat:
a. PR het niet eens is met de door EGEM gevolgde procedure (constatering)
b. er wellicht verschillende beelden bestaan over de gevolgen van de invoering van deze extraElementen (veronderstelling)
In een later mail heeft PR overigens aan jou aangegeven gekozen EGEM beleid (uiteraard) te zullen uitvoeren.
Ik zie dus geen reden voor EGEM om de extraElementen in het kader van de BAG-GBA koppeling niet te publiceren.
Wel zijn er voldoende redenen om een en ander nog eens goed te evalueren en wellicht betere afspraken te maken.
Dit laatste graag tijdens een gelegenheid waarbij ik (of Pieter) aanwezig ben ! ... 26 augustus ben ik nog met verlof.
Groeten, John.
PS : Ik heb de vrijheid genomen om bovenstaande via mail te melden, omdat ik jouw bericht niet op het forum aantrof.
Voel je vrij om mijn bericht samem met dat van jou alsnog op het forum te publiceren.
PPS : Mijn e-mail adres is gewijzigd in John.Rooijakkers@pinkroccade.nl
Van: Henri Korver
Verzonden: dinsdag 14 juli 2009 18:26
Onderwerp: RE: extraElements BAG-GBA koppeling
Beste mensen,
helaas zal ik morgen de lijst met extra elementen voor de BAG-GBA koppeling niet publiceren. Formeel gezien had het wel gekund omdat het voorstel niet via het forum is tegengehouden. Praktisch gezien hebben we wel een probleem omdat een leverancier via de email te kennen heeft gegeven het niet eens te zijn met de lijst. Deze leverancier heb ik gevraagd haar reactie met jullie te delen op het forum. Dat is vooralsnog niet gebeurd.
Blijkbaar is nog niet iedereen ervan overtuigd dat dit soort discussies via het forum en niet via persoonlijke bila's moeten worden beslecht. Ik stel voor dat we in de volgende expertgroepvergadering hierover verdere en strakkere afspraken maken.
Mvg,
Henri
PS De url van de forumdiscussie:
https://www.surfgroepen.nl/sites/stuf/Lists/StUF%20301/Flat.aspx?RootFol...
Van: Henri Korver
Verzonden: di 7-7-2009 12:19
Onderwerp: extraElements BAG-GBA koppeling
Beste mensen,
uiteindelijk heb ik toch besloten om de eerste lijst van extraElementen die door EGEM gepubliceerd gaat worden te beperken tot alleen die elementen die een rol spelen bij de BAG-GBA koppeling (zie bijlage). Deze extra elementen hebben namelijk de meeste urgentie. Bovendien is de semantiek van de elementen vrij eenvoudig te definieren omdat deze extra elementen voor bg0204 bijna allemaal afkomstig zijn uit bg0310.
Verder heb ik besloten om de naamgeving van de extra elementen in eigen hand te houden om de consistentie zo goed mogelijk te bewaken. Het 1-op-1 overnemen van ingediende elementen leidde al snel tot onduidelijkheid en inconsistenties. Dit betekent dat ik afzie van een eerder gemaakte afspraak dat extra elementen worden overgenomen op basis van het 'eerst komt, eerst maalt' principe.
Het extra element 'codeGebeurtenis' heb ik ook toegevoegd aan bg0310 om de BAG-GBA koppeling compleet te maken voor beide versies 0204 en 0310. Uiteindelijk zal dit attribuut als een officieel metagegeven gedefinieerd moeten worden binnen bg0310 om het echt netjes te krijgen. Dit is een RFC dat ik zal indienen op het forum.
Indien ik geen reacties ontvang voor volgende week dinsdag einde dag zal ik de lijst de woensdag erna publiceren.
Mvg,
Henri
Beste mensen,
Dankzij een aantal goede observaties van Gert-Jan Kooijman van PinkRoccade heb ik twee nieuwe extraElements toegevoegd aan de spreadsheet (zie attachment). Deze twee extra elementen zijn nodig voor de BAG-GBA koppeling, te weten:
het extra element 'status' bij R03 (Woonplaatstabel)
het extra element 'indentificatieWoonplaats' bij R02 (Straattabel)
De verschillen t.o.v. het vorige spreadsheet zijn rood gekleurd.
Verder zijn er nog de volgende opmerkingen ter verheldering van gemaakte keuzen:
Ik laat de nieuwe spreadsheet nog drie dagen bezinken. Zonder tegenbericht op het forum zal ik deze versie donderdag publiceren.
Mvg,
Henri Korver
Per abuis verwijs ik in bovenstaande post naar Gert-Jan Kooijman ... dit moet natuurlijk zijn: Gert Jan van der Kooij.
Champagne! De eerste officiële lijst van extra elementen is vastgesteld. Klik hier...