Ik heb me nog eens verder verdiept in het gebruik van het attribuut ‘stuf:noValue’ (zie ook blz. 37/38 in de StUF-standaard). Één van de uitgangspunten van het BRP-berichtenmodel betreft het compact houden van de berichten. Indien elementen geen waarde hebben, dan worden deze dan ook weg gelaten in de Bijhouding-, Antwoord- en Lever-berichten. Tenzij ze verplicht zijn in de berichtdefinitie; in die gevallen wil ik dan het attribuut stuf:noValue=”geenWaarde” toepassen.
Dit blijkt strijdig met de StUF-standaard. Hierin is namelijk gespecificeerd dat het niet voorkomen van een element impliceert dat de waarde van dat element ‘onbekend’ is; dit in de betekenis van ‘ik weet het niet’; gerepresenteerd door stuf:noValue=”waardeOnbekend”.
Hier aan tegemoet komen zou betekenen dat we in de BRP-berichten voor alle elementen die geen waarde hebben, dit expliciet moeten aangeven met het attribuut ‘ stuf:noValue=”geenWaarde” ‘; dus zowel voor de optionele als de verplichte elementen. Dit schuurt dan weer met ons uitgangspunt om de berichten compact en leesbaar te houden.
Overigens is het voor de basisregistratie personen (en andere basisregistraties? vreemd als hierin ‘onbekend’ (in de betekenis van ‘ik weet het niet’) zou zijn opgenomen. De BRP maakt dit door StUF gemaakte onderscheid dan ook niet. In voorkomende gevallen komen alleen de in StUF gehanteerde waarden ‘geenWaarde’ en ‘vastgesteldOnbekend’ in de BRP voor. Deze laatste dan veelal getypeerd door het voorkomen van een speciale tabel-waarde of een standaardwaarde.
Aangezien het volgen van de standaard op dit punt te veel botst met de door ons gehanteerde uitgangspunten voor het berichtenmodel, moet hiervoor een (StUF-harmonisatie-)oplossing worden gevonden.
Onderstaand hiervoor een aantal mogelijke oplossingsrichtingen:
1. Berichtenmodel BRP volgt StUF-standaard …
>>> Niet realistisch vanuit BRP-optiek; dit leidt tot grote hoeveelheden ‘geenWaarde’-regels; terwijl dit voor de BRP feitelijk de default is ...
2. Aanpassen StUF-standaard, zodat ‘geenWaarde’ de default wordt bij het ontbreken van elementen.
>>> Lijkt me niet realistisch afgezet tegen de huidige StUF-implementaties.
3. Definiëren extra Di/Du-berichtsoorten (Di-/Du10, …), waarvoor geldt dat ‘geenWaarde’ de default wordt bij het ontbreken van elementen …
>>> Alhoewel deze me haalbaar lijkt voor beide stromingen is dit geen nette oplossing; meer een noodverbandje.
4. De StUF-standaard inperken tot het beschrijven van het mechanisme van 'stuf:noValue' en de mogelijke waarden hierbinnen. Vervolgens per sectormodel te definieren:
a) welke waarden van stuf:noValue binnen het sectormodel van toepassing zijn
b) welke defaultwaarde gehanteerd dient te worden
Oftewel het schema op blz 37/38 per sectormodel in te kleuren.
Mijn voorkeur gaat uit naar optie 4. Mogelijk ziet iemand nog andere mogelijkheden, dan hoor/lees ik deze graag terug.
Mvg, Gert Jan
Hoi Gert Jan,
het gebruik van het attribuut "stuf:noValue" is verplicht op bepaalde plekken in kennsigeving-, synchronisatie en vraagantwoordberichten maar niet verplicht in de vrije berichten (zolang je daar geen hergebruik maakt van de bovengenoemde berichtsoorten). Aangezien de mGBA vooralsnog alleen pure vrije berichten gebruikt (dus zonder hergebruik van andere berichtsoorten) lijkt me dit wijzigingsvoorstel niet nodig. Of zijn jullie al bezig met StUF-kennisgevingen voor de binnengemeentelijke leveringen?
Mvg,
Henri
Hallo Henri,
Alhoewel niet verplicht zal de BRP op een aantal plaatsen (zie post) ook in de vrije berichten gebruik maken van 'stuf:noValue' (geenWaarde). Het attribuut wordt dus wel gebruikt.
Verder worden niet in de Vrije berichten meegegeven elementen binnen StUF BRP beschouwd als 'geenWaarde' (denk bv. huisletter bij adres of voorvoegsels bij naam).
Hiermee wijken we af van het gestelde in de standaard. Als dit inderdaad geen issue is, dan is vooralsnog geen aanpassing nodig.
Mogelijk wel als we voor het Koppelvlak Leveren gebruik gaan maken van StUF-kennisgevingen. Hiervoor zijn de eerste afstemmingen met leveranciers gestart. Vooralsnog is mijn verwachting dat ook hier Vrije berichten worden toegepast.
Ik zie ook het meeste heil in de vierde oplossingsrichting. Een en ander impliceert wel dat de berichten niet meer zelfbeschrijvend zijn, zoals nu het geval is (ontbreken impliceert onbekend), maar dat je per ontbrekend element moet nagaan wat daarvoor in het sectormodel is gedefinieerd.
Het lijkt mewat gortig om in de standaard te definiëren dat je deze keuze alleen op sectormodelniveau kunt maken. Voor een telefoonnummer of emailadres bij een persoon is de interpretatie geenWaarde bij ontbreken van dit element ongelukkig.
Zullen we in de StUF-standaard afspreken dat de default semantiek van een ontbrekend element stuf:noValue="waardeOnbekend" is en dat deze semantiek overruled kan worden in een sectormodel? Bijv. het sectormodel StUF-BRP kan de semantiek van bepaalde of alle ontbrekende elementen overrulen met stuf:noValue="geenWaarde".
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0137.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 20-5-2015 is besloten dit RFC af te voeren.