Een van de best practices bij de verstuffing van een sectormodel naar XSDs is het zo scherp mogelijk valideren van de berichten. Dit lijkt me een goed streven.
Bij het vaststellen van de specificaties voor de BAG berichtencatalogus is gebruik gemaakt van een spreadsheet om aan te geven welke entiteiten in welke gebeurtenis een rol kunnen spelen. Vervolgens is er per entiteit een spreadsheet om per gebeurtenis aan te geven in hoeverre een element opgenomen moet/mag worden in de toevoeg- of wijzigkennisgevingen.
Is het hierbij de bedoeling, conform de spreadsheets, dat de inhoud van een kennisgeving gebeurtenis afhankelijk is?
Wij zouden daar niet blij mee zijn. Dit leidt tot een warboel aan code die afhankelijk van de gebeurtenis een bericht voor een bepaalde entiteit moet samenstellen. Wij zouden liever zien dat de inhoud van een kennisgeving voldoet aan algemene, gebeurtenisonafhankelijke regels namelijk de bestaande StUF 03.01 regels; kort door de bocht: in een wijzigkennisgeving worden opgenomen de elementen die behoren tot de kerngegevens en de te wijzigen elementen.
Han,
Inderdaad is bij de totstandkoming van de berichtcatalogus BAG gewerkt met een spreadsheet om aan te geven bij welke gebeurtenissen welke mutaties aan de orde zijn en welke kennisgevingsberichten dus verzonden moeten worden. Bij de verdere discussie over de berichtcatalogus is geconstateerd dat een dergelijk spreadsheet voor de implementatie erg lastig is. Immers zowel de applicatie die de kennisgevingen maakt als degene die ze verwerkt moet deze spreadsheet als achtergrond informatie gebruiken om te beoordelen of een bericht "geldig" is.
Daarom is er voor gekozen het spreadsheet te vertalen in de xsd-schema's. Door het werken met samengestelde berichten per gebeurtenis is in de berichtspecificaties zelf exact bekend welke berichten van belang zijn en welke attributen gevuld moeten zijn. Zowel bij het vervaardigen van de berichten als het verwerken kunnen de xsd-schema's direct worden gebruikt voor schemavalidatie.
Door de definitie van de samengesstelde berichten per gebeurtenis in de xsd-schema's hebben de spreadsheets hun betekenis verloren. Maar inderdaad de berichten hebben een inhoud die gebeurtenis afhankelijk is, namelijk afhankelijk van "de plaats binnen een samengesteld bericht".
Naast de voordelen die dit heeft op het terrein van schemavalidatie, is dit ook een eerste (flinke) stap in de richting van het gebeurtenisgericht werken dat door NORA wordt "voorgeschreven".
Het voordeel van de scherpere validatie moet mijns inziens afgewogen worden tegen het nadeel van de complexere software om een bericht te vullen.
Nu is bijvoorbeeld de inhoud van een AOA-LK01 kennisgevng afhankelijk van de gebeurtenis. Je kunt niet eenvoudig zeggen: de gebeurtenis heeft geleid tot een wijziging in de AOA dus ik maak een AOA_LK01 kennisgeving. In plaats daarvan heb je verschillende vullingen afhankelijk van de gebeurtenis. Dat leidt tot heel veel code.
Daarnaast heeft een gebeurtenisafhankelijke vulling van een bericht weinig te maken met gebeurtenisgericht werken. Dat laatste lijkt me erg zinvol en haalbaar zonder de noodzaak voor gebeurtenisafhankelijke inhoud.
Kortom, ik pleit voor het herzien van de spreadsheets/XSDs, zodat de inhoud van een kennisgeving niet afhankelijk is van de gebeurtenis (afgezien van bijvoorbeeld gebeurteniscode wat eenduidig te herleiden is tot de gebeurtenis).
Han,
Ik denk dat jij je toch teveel zorgen maakt over die extra programmeercode die nodig is. Bij al die "gebeurtenis afhankelijke" berichten geldt namelijk het algemene uitgangspunt dat naast de kerngegevens alleen die gegevens in het bericht worden opgenomen die gemuteerd zijn.
Wanneer je met dat algemene uitgangspunt de berichten "vult" moet je precies uitkomen bij wat er gespecificeerd is in de "gebeurtenis afhankelijke" berichten. Het voordeel is dan dat je met schemavalidatie nog kan toetsen of dat ook daadwerkelijk het geval is. Wanneer dat niet het geval is, zal er bij de verwerking van die gebeurtenis iets mis gegaan zijn, want het uitgangspunt is dat er in de gespecificeerde berichten naast de kerngegevens alleen de attributen zijn opgenomen die door die gebeurtenis muteren.
Beste Ruud,
In je reactie zit de impliciete aanname dat iedere BAG (bron) applicatie op dit moment reeds 100% gebeurtenis georienteerd werkt. In de praktijk lijkt dat echter niet het geval. Soms is het mogelijk om gegevens te muteren of te corrigeren waarbij de gebruiker (vooraf) niet verplicht is om de feitelijke gebeurtenis(sen) in te geven. Ook is het niet altijd mogelijk om de gebeurtenis(sen) eenduidig af te leiden uit de gewijzigde gegevens. Hiermee bepleit ik overigens niet om het gebeurtenis geörienteerd werken te negeren of af te zweren ... in tegendeel zelfs. Maar het is te kort door de bocht om te verwachten dat alle in de markt aanwezige (BAG) applicaties momenteel reeds op deze wijze functioneren terwijl hierop tot voor kort niet of nauwelijks (expliciet) werd gestuurd vanuit de basisregistratie verantwoordelijken. Het later alsnog toepassen van deze werkwijze in een bestaande applicaties is niet evident.
Groeten, John.
De opmerking van John sterkt mij in de gedachte dat we af moeten van gebeurtenisafhankelijke inhoud van de enkelvoudige kennisgevingen in een samengestelde kennisgeving.
Een voorbeeld om het probleem te duiden.
Neem de spreadsheet over de AOA-LK01 kennisgevingen. Bekijk de kolommen voor de elementen huisnummer, huisletter en huisnummertoevoeging. Mer op dat deze elementen deel uitmaken van de kerngegevens van een AOA. Bij de meestegebeurtenissen MOETEN de elementen aanwezig zijn (X) of MOETEN de elementen aanwezig zijn als ze GEWIJZIGD zijn (W). Bij de gebeurtenissen BRA-HOR, BRA-HOB en BRA-IOR (hernoemen openbare ruimte, hernoemen openbare ruimte in buurgemeente en intrekken openbare ruimte) MOGEN ZE NIET aanwezig zijn (-). Kortom, gebeurtenisafhankelijke vulling.
Bij een gebeurtenisonafhankelijke vulling zou voor deze elementen gelden: zij maken deel uit van de kerngegevens dus ze moeten altijd aanwezig zijn, ook als hun waarde niet is gewijzigd. In de spreadsheet zou voor deze kolommen bij alle gebeurtenissen een X moeten staan . Zelfs het gebruik van een W zou ik afraden, omdat dat zou kunnen doen vermoeden dat het element niet hoeft worden opgenomen als het niet is gewijzigd.
Als de spreadsheet volledig is vervangen door XSD validatie, mag je overal waar ik spreadsheet zeg dit vervangen door XSD.
Ruud, ik begrijp trouwens niet wat je in jouw eerste opmerking bedoelt met "de berichten hebben een inhoud die gebeurtenis afhankelijk is, namelijk afhankelijk van 'de plaats binnen een samengesteld bericht'. Kun je dat toelichten?
Hallo Han,
Ik heb nog even naar het bericht BRA-HOR gekeken, maar daar zijn in de xsd alle kerngegevens verplicht en is de vulling in die zin dus niet gebeurtenisafhankelijk. Mogelijk dat er een fourt in de spreadsheet zat die in de xsd is verbeterd. Ik verwacht dat deze verbetering bij al deze berichten is doorgevoerd.
Maarten
Han,
Met "de berichten hebben een inhoud die gebeurtenis afhankelijk is, namelijk afhankelijk van 'de plaats binnen een samengesteld bericht", bedoel ik dat de (verplichte) inhoud van bijvoorbeeld een PNDLk01 bericht in een samengesteld bericht bgtMAB_Lk03 anders is dan van "hetzelfde" PNDLk01 bericht binnen bgrVBN_Lk03.
Met deze opmerking bevestig dus jouw opmerking dat de berichten "gebeurtenisafhankelijk" zijn. Maar aan de andere kant zeg ik in mijn tweede bericht dat wanneer je de relevante wijzigingen hebt en deze kan koppelen aan een gebeurtenis code dan moet je zonder veel problemen die enkelvoudige berichten kunnen samenvoegen in een samengesteld bericht behorend bij die gebeurteniscode.
John,
Jouw opmerking over het niet gebeurtenisgeoriënteerd zijn van BAG-applicaties verbaast mij.
In de documentatie van BAG speelt het processenhandboek een grote rol. De daarin beschreven processen (gebeurtenissen) geven exact aan bij welke gebeurtenis welke gegevenslevering aan de LV BAG moet plaatsvinden. Wanneer ik de discussies volg die in de BAG-communities plaatsvinden dan blijken gemeenten juist er soms tegen aan te lopen dat zij in hun applicatie alleen aan de hand van deze gebeurtenissen kunnen muteren.
Met andere worden, gebruikers klagen eerder dat de systemen zich "te strikt" aan het gebeurtenisgeoriënteerd werken houden en jij geeft aan dat ze niet gebeurtenisgeoriëneerd zijn. Ik kan die twee opmerkingen niet met elkaar rijmen.
Overigens blijf ik het wel jammer vinden dat deze discussie nu pas naar boven komt.
Ruud,
In het processenhandboek staat op blz. 7 bovenaan "Het processenhandboek beschrijft de veelvoorkomende gebeurtenissen in een gemeente, maar is niet uitputtend in het beschrijven van alle mogelijke gebeurtenissen." Omdat het processenhandboek niet uitputtend is, moet een BAG applicatie wel de mogelijkheid bieden om ook niet gebeurtenisgeoriëneerd te kunnen werken.
Ruud,
Het is niet zo dat de discussie nu pas gevoerd wordt. Op 21 juni 2010 heb ik René Kok onderstaande mail gestuurd:
Hoi René,
Uit InventarisatieGebeurtenissenBAGvsGBA_v1.2.xls blijkt dat de code gebeurtenis altijd moet worden gecommuniceerd in de berichten naar GBA. Verder staat in het processenhandboek BAG dat de daar genoemde gebeurtenissen niet uitputtend zijn en er altijd andere wijzigingen moeten kunnen worden doorgevoerd.
Mijn vraag is nu wanneer de andere wijzigingen gecommuniceerd moeten worden naar GBA en welke waarde de code gebeurtenis dan moet krijgen.
Met vriendelijke groeten,
Robin
Robin,
Dat het processenhandboek niet uitputtend is, is ons bekend. En ook weten wij dat bij die andere BAG-mutaties buiten de gebeurtenissen van het processenhandboek er een gegevenslevering aan de GBA en alle andere afnemers gestuurd moeten.
Deze eerdere discussies waarnaar jij verwijst zijn dan ook meegenomen in het ontwerp van de Berichtcatalogus BAG. Want bij de uitwerking van deze Berichtcatalogus BAG zijn naast de in het processenhandboek BAG beschreven gebeurtenissen ook enkele generieke andere mutaties als extra gebeurtenis gedefinieerd.
Daarom kent de Berichtcatalogus BAG een tiental extra gebeurtenissen, waaronder generieke gebeurtenissen als "BAG-MUT Muteren naar aanleiding van signalering" en "BAG-COR Correctie". Met deze extra gebeurtenissen moeten wel alle mutaties in de BAG afgedekt zijn, mede gezien de generieke eis dat alle gegevens/mutaties gebaseerd moeten zijn op een brondocument.
Mijn opmerking dat ik het jammer vindt dat deze discussie nu pas wordt gevoerd, heeft overigens te maken met het feit dat de Berichtcatalogus BAG (voorheen koppelvlak BAG-WOZ) inmiddels gedurende een aantal maanden binnen de community ter discussie staat, enkele malen besproken is en vastgesteld is in de Expertgroep StUF en dat nu net na deze procedure en vaststelling één van de uitgangspunten ter discussie wordt gesteld.
Beste Ruud,
Voor alle duidelijkheid: wij onderschrijven de waarde van het gebeurtenis georienteerd werken en stellen dit dus niet ter discussie. Wel constateren wij dat dit binnen diverse applicaties (van verschillende leveranciers) op dit moment nog niet (volledig) wordt afgedwongen. Blijkbaar is dit in het verleden ook niet geconstateerd bij het aansluiten van gemeenten op de LV-BAG.
Groet, John Rooijakkers.
De oorspronkelijke reden voor deze post was de constatering dat in de BAG berichtencatalogus (volgens de spreadsheet en wellicht ook de daarvan afgeleide XSDs) de inhoud van de LK01 berichten afhankelijk is van de gebeurtenis die aanleiding is voor het versturen van het LK01 bericht als onderdeel van een LK03 samengestelde kennisgeving bericht.
Ik stel dan ook voor dat alle discussies rondom het al dan niet gebeurtenisgericht werken worden voortgezet in een aparte post op dit forum.