Probleem Het voorbeeld bestand van het Kadaster voor de gemeente ASSEN bevat voor de ZKR's identificaties met een lengte 20, omdat het nummer nog wordt voorafgegaan door bijv 'AKR1.' In dat geval wordt niet meer voldaan aan de regular expression [0-9]{1,15} in IdentificatieBRK-e. Delen van het voorbeeldbestand kunnen derhalve niet vertaald worden naar bg0310. Oplossing: Wijzig in IdentificatieBRK-e de regular expression in bijv [a-zA-Z0-9\.]{0,5}[0-9]{1,15}.
di, 11-11-2014 - 16.12u
#1
Erratum: ComplexType IdentificatieBRK-e bevat foutieve regular expression
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0352.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 19 november 2014 is besloten de door Maarten van den Broek voorgestelde aanpassing van de regular expression goed te keuren. In principe zal de aanpassing meegaan in patch 21 maar dat hangt nog wel af van de mate waarin het complexType al in gebruik is.
Sid Brouwer en Maarten van den Broek gaan dit uitzoeken.
Maarten van den Broek heeft daarbij aangegeven dat vanaf juni het kadaster nieuwe berichten met het nieuwe formaat zal gaan uitleveren als de aanpassing niet doorgevoerd wordt zullen er op dat moment enorm veel connectiviteitsproblemen ontstaan.
Maarten geeft aan dat het RSGB en StUF-BG hier niet correct zijn.
Het onderhoudsverzoek is omgezet naar het erratum ERR0352.
Ik heb inmiddels uitgezocht wat de door het Kadaster gebruikte regular expression is (zie het schema BRKLeveringImkadNEN3610_v1_1_0.xsd) "\S.*", wat wil zeggen een string van een willekeurige lengte die niet begint met een white space character. Dit is een ongelukkige definitie voor database ontwerpers, omdat je niet weet hoe lang het veld maximaal mag zijn, maar so be it. Ik stel voor dat we deze regular expression overnemen in bg0310. De andere regular expression in bovengenoemd schema is valideert een subset van de hierboven gegeven regular expression en is dus irrelevant.