Omgang met "voorloop-nullen" en "naloop-spaties"

3 reacties / 0 nieuw
John Rooijakkers
Omgang met "voorloop-nullen" en "naloop-spaties"

Beste StUF collega's,

In de “oude” StUF versie (01.05) was een passage opgenomen die dwingende richtlijnen gaf over het al dan niet opnemen van voorloop-nullen of naloop-spaties. Binnen StUF 02.04 is daarover echter niets opgenomen.

Maarten van den Broek gaf op mijn vraag hierover als antwoord dat dit bewust is gedaan bij de overgang van StUF naar XML. Voor numerieke typen staat XML daarbij expliciet het gebruik van voorloopnullen toe. De omgang met nullen en spaties in strings lijkt echter niet zo duidelijk beschreven. Hierdoor kunnen ongewenste interpretatieverschillen ontstaan.

Naar mijn mening moet de waarde van een element met het type string altijd ontdaan worden van naloop-spaties en de waarde van een element met het type numeriek altijd ontdaan worden van voorloop-nullen. Indien een element met het type string een waarde heeft die geheel bestaat uit cijfers (bv authentieke identificatie of geboortegemeente), dan mogen  eventuele voorloop-nullen uiteraard niet verwijderd worden.

Met name in de laatstgenoemde situatie worden wij momenteel geconfronteerd met elementen (bv geboorteplaats) waarbij sommige leveranciers wel en anderen geen voorloopnul(len) opnemen (bv "772" versus "0772").

De GBA (en daarmee GFO en RSGB) omschrijft de geboorteplaats met het type string als volgt:

De eerste 4 posities kunnen een 4-cijferige gemeentecode uit de Tabel 33, Gemeententabel bevatten, of het geheel bevat een buitenlandse plaatsnaam, of het geheel bevat een omschrijving zo nodig aangevuld met een aanduiding in lengte- en breedtegraden, indien de geboorte niet in een gemeente of buitenlandse plaats heeft plaatsgevonden (bijvoorbeeld bij een geboorte op of boven internationaal gebied). Standaardwaarde indien onbekend. Voorwaarden Indien geen 4-cijferige gemeentecode is ingevuld begint het veld met een niet-numeriek karakter.

Geautomatiseerde systemen (en met name systemen voor gegevenssynchronisatie) zullen een verschil constateren indien in een element (van het type string) soms wel en soms niet voorloop-nullen worden opgenomen. Om deze en andere interpretatieverschillen te voorkomen is het noodzakelijk om de dwingende richtlijnen voor de omgang met voorloop-nullen en naloop-spaties opnieuw in de StUF definitie op te nemen.

Met vriendelijke groet,

John Rooijakkers

Anoniem

Dit is volgens mij geen StUF-issue maar een probleem van het datamodel (zoals RSGB of het GFO BG in dit geval). Het gegevenswoordenboek dient eenduidig het waardebereik (met of zonder voorloopnullen of naloopspaties) van haar attributen te specificeren. Het verwondert mij dat StUF 1.05
zich bemoeide met datadefinities. Misschien waren toen het gegevensmodel en de berichtenstandaard nog niet helemaal goed uitelkaar getrokken.

John Rooijakkers

Hoi Henry,

StUF issue ja of nee ... momenteel praten partijen langs elkaar heen ... moet dus wel een richtlijn voor komen.

Groet, John.