BAG berichtencatalogus en Benoemen/Intrekken nevenadres

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

4 reacties / 0 nieuw
Han Welmer
BAG berichtencatalogus en Benoemen/Intrekken nevenadres

Volgens de XSD van de BAG berichtencatalogus mag het TGO object bij een bagBN of eeen bagIN bericht niet een brondocument of tijdvakgeldigeid element bevatten. Als bij dezelfde gebeurtenis de LV-BAG geïnformeerd wordt, dan moet daar het TGO wel deze elementen bevatten.

Dit leidt tot complexiteit en verwarring in een BAG applicatie.

Klopt onze constatering? Moet hier niet iets aan gedaan worden in de BAG berichtencatalogus?

Robert Melskens

Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR263.
De lijst met onderhoudsverzoeken vind je op: 
www.wikixl.nl/wiki/basisgemeente/index.php/StUF-Expertgroep#Documenten

Han Welmer

De opmerking over LV-BAG is in zoverre relevant dat bij deze gebeurtenissen conform de LV-BAg specificaties historie wordt opgebouwd voor het TGO object. Het is dus raadzaam dat ook voor binnengemeentelijke berichten dezelfde voorkomens worden opgebouwd.

Daarnaast ben ik vergeten te melden dat ook het element tijdstipregistratie niet is toegestaan bij een TGO dat is betrokken in een benoemen/intrekken nevenadres, terwijl dit ons inziens wel gewenst is.

Dezelfde problematiek met brondocument treedt op bij de geberutenissen in onderzoek plaatsen en uit onderzoek halen. Ook daar vereist de LV-BAg dat bij deze gebeurtenissen een brondocument moet worden vermeld, waardoor er nieuwe voorkomens worden aangemaakt, welke voorkomens inclusief brondocument ons inziens ook binnengemeentelijk gedistribueerd zouden moeten worden.

Robert Melskens

Tijdens de StUF Expertgroep van 19 april 2017 is besloten het erratum om te zetten naar een RFC (RFC0482). het probleem blijkt ook niet specifiek voor BG te gelden.