Volgens de XSD van de BAG berichtencatalogus mag het elementen gor.straatnaam NIET voorkomen in een aoaLk01 kennisgeving van een braHOR_Lk03 bericht. Het element gor.openbareRuimteNaam mag WEL voorkomen.
Volgens het BAG processenhandboek (zie pagina 97) mag de waarde van het element Naam openbare ruimte wel degelijk wijzigen.
Volgens BG 03.10 bevat een OPR naast het element gor.openbareRuimteNaam ook het optionele element straatnaam, waarin de verkorte schrijfwijze van de Naam openbare ruimte is opgenomen.
De mogelijke aanwezigheid van gor.straatnaam lijkt ons gewenst ten behoeve van ontvangende applicaties die werken volgens 0204 en voor een correcte transfromatie naar 0204.
Wij vermoeden dat de restrictie AOA-bag-hernoemenOpenbareRuimte op dit punt een fout bevat. Wij stellen dus voor dit via een erratum op de BAG berichtencatalogus te corrigeren.
Volgens ons treedt hetzelfde probleem op bij een braHNO bericht (hernummeren openbare ruimte), waar gor.straatnaam niet mag voorkomen in een aoaLk01 kennisgeving.
Ik wordt even op het verkeerde been gezet door de uitdrukking 'wel degelijk' waardoor lijkt alsof er iets niet in orde is met 'gor.openbareRuimteNaam'. Volgens mij is er echter niets mis met dat element en ik neem aan dat je dat ook niet bedoeld.
Ik heb de mapping van bg0310 naar bg0204 er op nageslagen en daar staat dat als in bg010 in een AOA de gor.straatnaam
ontbreekt de gor.openbareRuimteNaam mapt op ADR straatnaam in bg0204.
Je zou dus zeggen dat er geen probleem zou hoeven te zijn.
Stel dat de Naam openbare ruimte veranderd. Dan kun je die volgens de huidige XSDs opnemen in het bericht.
Stel dat de lengte van dit veld niet langer is dan 24 posities. Dan mag de ontvangende partij, bij afwezigheid van het veld straatnaam, ervan uitgaan dat straatnaam hetzelfde is als Naam openbare ruimte.
Maar stel dat dat de lengte van dit veld langer is dan 24 posities. Dan is er een gerede kans dat de straatnaam ook is gewijsigd. Echter de XSDs staan op dit moment niet toe dat straatnaam wordt opgenomen in het bericht. Dat is ons probleem. Het elementen gor.straatnaam mag NIET voorkomen in een aoaLk01 kennisgeving van een braHOR_Lk03 bericht.
Als je conclusie dat bij een openbareRuimteNaam van meer dan 24 posities de kans groot is dat de straatnaam ook gewijzigd is klopt (en daar ga ik vanuit) dan lijkt het me inderdaad verstandig je verzoek te honoreren.
De genoemde binnen 'braHOR_LK03' gebruikte complexType 'BG:AOA-bag-hernoemenOpenbareRuimte' wordt ook gebruikt binnen 'braHOB_Lk03' en braGHO_Lk03'.
Ook de binnen 'braHNU_Lk03' gebruikte complexType 'BG:AOA-bag-wijzigAanduiding' wordt hergebruikt en wel binnen 'braOHN_Lk03' en 'braOPC_Lk03'.
De vraag is of de binnen beide complexTypes gevraagde wijziging (toevoeging van de optionele gor.straatnaam) ook binnen de andere samengestelde berichten gewenst zijn?
Dit probleem is opgenomen in de onderhoudsverzoeken als ERR258.
De StUF Expertgroep heeft besloten dat de wijziging ook mag worden aangebracht in de berichten 'braHOB_Lk03' en braGHO_Lk03'.
De Regiegroep Gegevens en Berichten heeft een uitspraak gedaan over de wijze waarop moet worden omgegaan met compatibility. Kern is dat streven altijd moet zijn om in patches geen errata door te voeren die niet backwards compatible zijn. De StUF Expertgroep moet altijd de afweging maken tussen de noodzaak om een erratum door te voeren en de impact op bestaande software implementaties.
In afwachting op deze uitspraak was erratum ERR258 in de wachtstand gezet. Nu de Regiegroep deze uitspraak heeft gedaan heb ik bij deze post een voorstel gevoegd voor het oplossen van dit erratum. De vraag is nu of de noodzaak voor het doorvoeren van dit erratum hoog genoeg is. Indien de StUF Expertgroep oordeelt dat dit het geval is dan kan dit erratum met patch 25 worden opgelost.
In 'bg0310_ent_bag.xsd' is de complexType 'AOA-bag-hernoemenOpenbareRuimte' aangepast.
Bijlage
Tijdens de StUF Expertgroep van 16 maart 2016 is besloten om het voorstel niet goed te keuren maar dit erratum (ERR258) wel om te zetten naar een RFC (RFC0258). Dit omdat dit erratum niet backwards compatible kan worden opgelost.