Volgens de StUF-regels voor Vrije berichten dient het attribuut ‘stuf:functie’ in de berichten bij entiteiten te worden opgenomen.
Als verwerker van de Bijhoudingberichten zal de BRP geen gebruik maken van het attribuut ‘stuf:functie’. Het attribuut is hiermee overbodig in het Koppelvlak Bijhouden. Om die reden wil de BRP haar berichtenmodel en de communicatie met de Burgerzakenmodules niet belasten met dit attribuut en heeft het verzoek het gebruik hiervan optioneel te verklaren.
vr, 23-11-2012 - 11.13u
#1
Optioneel verklaren van gebruik attribuut stuf:functie in Vrije berichten
Ik zal dit voorstel toevoegen aan de onderhoudsverzoeken en agenderen voor de aankomende expertbijeenkomst. Ik verwacht een pittige discussie. Mijn compromis voorstel is om het attribuut 'stuf:functie' optioneel te maken op voorwaarde dat als dit attribuut weggelaten is de default semantiek "entiteit" is.
Mogelijk valt de discussie mee ...
Als ik de tekst bovenaan blz. 112 nog eens goed tot me neem, dan mag het al! Hier staat immers "In willekeurige volgorde 0, 1 of meer van de volgende elementen ...".
Het attribuut functie is bedoeld om vrije berichten "scherper" te kunnen definiëren en meer hergebruik te maken van structuren. Indien dit niet voldoet (voor de BRP) dan is het de vraag of het hele gebruik van functie niet beter ter discussie gesteld kan worden. Het opnemen van functionaliteit die niet gebruikt wordt, maakt de standaard onnodig complex.
Hoi Gert Jan, in een vrij bericht mag je na de stuurgegevens, parameters, meldingen en zaakinfo inderdaad 0, 1 of meer elementen met willekeurige namen opnemen maar als je 1 of meer van deze elementen hebt opgenomen dan zijn de attibuten "stuf:functie" en "stuf:entiteittype" altijd verplicht.
Mvg,
Henri
Hoi John, het gebruik van het attribuut "stuf:functie" is verplicht in vrije berichten (zie mijn reactie naar Gert Jan). Ik neem aan dat de Waarderingskamer zich netjes aan de stuf0301 specificatie heeft gehouden en dat dit attribuut daar veelvuldig wordt gebruikt. Ook wordt het attribuuut gebruikt in de schema's van de KvK.
Mvg,
Henri
Zoals ik al eerder aangaf is het probleem van Gert Jan eenvoudig op te lossen door het attribuut "stuf:functie" in de syntax van StUF-berichten optioneel te maken. In het geval dat dit attribuut is weggelaten kunnen we in de standaard eisen dat de default semantiek "entiteit" is. Als de expertgroep het hiermee eens is kan dit wellicht als een erratum worden doorgevoerd.
Dit helpt niet echt aan de oplossing van deze post ... immers voor de BRP heeft 'stuf:funtie' geen betekenis en zal overal worden weg gelaten. Zonder dat hier wordt bedoeld dat hiervoor de semantiek van "entiteit' gelezen moet worden.
Voor de LV WOZ (en ook breder binnen het Sectormodel WOZ) hebben we veel vrije berichten gedefinieerd. Inderdaad hebben we bij al die vrije berichten de StUF:functie consequent in de berichten opgenomen.
Voordeel hiervan is dat dit toch bijdraagt aan het direct, vanuit het bericht zelf, begrijpelijk zijn van de betekenis van het bericht.
Natuurlijk betekent het opnemen hiervan een kleine toevoeging aan het bericht, maar dit is een marginale vergroting van het bericht. Verder vergt het eenmalig bij de definitie van het vrije bericht opnemen van deze StUF:functie even zorgvuldig controleren of de juiste functie is benoemd.
Ons inziens wegen de voordelen van wel opnemen ruim op tegen de nadelen. Ik zou in deze discussie daarom graag een onderbowuing zien van de argumenten waarom GBA de voorkeur geeft voor het niet opnemen van deze StUF:functie.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0126.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 18 februari 2015 is aangegeven dat er een behoefte is aan een status update. Enkele leden van de StUF Expertgroep hebben hier in ieder geval wel moeite mee. De routeerbaarheid zou hierdoor ook worden ondermijnd.
Tijdens de StUF Expertgroep van 20-5-2015 is besloten dit RFC op te nemen in StUF 3.02.
Tijdens de StUF Expertgroep van 21-10-2015 is besloten dit RFC toch af te voeren.
Bijgaand (zie bijlage) de uitwerking van het terugdraaien van RFC0126. Dit RFC was al eerder doorgevoerd en wordt bij deze weer teruggedraaid conform het besluit van de EG-groep van 21-10-2015 om het RFC toch af te voeren (zie vorige post). In het bijgevoegde document zijn alleen de wijzingen m.b.t. dit RFC zichtbaar. Deze uitwerking zal in de aankomende EG-meeting als hamerstuk behandeld worden. In geval van bezwaar, graag ruim van te voren melden via dit forum.
Bijlage
Bijgaand (zie bijlage) de Word-versie van de uitwerking van bovenstaande RFC. In Word is het voor sommigen handiger om van de ene revisie naar de andere te springen dan in PDF. Ook zijn er mogelijk nog een paar verbeteringen doorgevoerd. Dus graag deze word-versie gebruiken voor de review.
Bijlage
Tijdens de StUF Expertgroep van 16 november 2016 is besloten de uitwerking n.a.v. het afvoeren van dit RFC goed te keuren.