Probleem
Paragraaf 3.4.2 van de StUF0301-standaard stelt over het opnemen van relaties in bullet 3:
"Het verzendende systeem weet dat een relatie niet voorkomt bij een object en de relatie is een kerngegeven, onderdeel van een gegevensgroep of gevraagd in een vraagbericht.Het element voor de relatie-entiteit wordt opgenomen met de attributes xsi:nil=”true”, StUF:aantalVoorkomens=”0” en StUF:aardAantal=”exact” zonder elementinhoud."
en in bullet 5:
"Het verzendende systeem weet niet of de relatie al dan niet voorkomt en de relatie is een kerngegeven, een onderdeel van een gegevensgroep of gevraagd in een vraagbericht.Het element voor de relatie-entiteit wordt opgenomen en met de attributes xsi:nil=”true”, StUF:aantalVoorkomens=”0” en StUF:aardAantal=”minimum” zonder elementinhoud."
Hiermee specificeert de StUF-standaard dat in plaats van StUF:noValue="geenWaarde" (bullet 3) c.q. StUF:noValue="waardeOnbekend" (bullet 5) de attributes StUF:aantalVoorkomens en StUF:aardAantal gebruikt moeten worden om te specificeren dat een relatie niet voorkomt of dat onbekend is of er relaties zijn.
In het sectormodel bg0310 zijn op relaties met kardinaliteit 1 de attributes StUF:aantalVoorkomens en StUF:aardAantal niet opgenomen, waardoor het onmogelijk is om te voldoen aan de specificatie in paragraaf 3.4.2. In het sectormodel woz0312 is ook afgezien van het gebruik van deze attributes. Deze sectormodellen zijn daarmee in strijd met StUF0301 standaard.
Discussie
De gangbare praktijk op dit moment lijkt te zijn om het attribute StUF:noValue te gebruiken om aan te geven of er geen relatie is c.q. of het aantal relaties onbekend is. Om die reden lijkt het de voorkeur te verdienen om dit probleem op te lossen door aanpassing van de StUF-standaard.
Op het moment dat deze attributes niet meer gebruikt worden om aan te geven dat er geen relatie is of dat het onbekend is of er een relatie is, rijst de vraag of deze attributes uberhaupt nog wel zin hebben.
Oplossing 1
Specificeer in de hierboven genoemde bullets 3 en 5 dat deze situaties aangegeven dienen te worden door het gebruik van StUF:noValue="geenWaarde" respectievelijk StUF:noValue="waardeOnbekend".
Er zijn dan ook aanpassingen nodig bovenaan pag. 24 en in enkele voorbeelden op pag. 24
Oplossing 2
Verwijder de attributes StUF:aantalVoorkomens en StUF:aardAantal in zijn geheel uit de StUF0301-standaard en de op StUF0301 gebaseerde sectormodellen.
Ik ben het er mee eens: Oplossing 2 en dus ook oplossing 1.
Ik kan mij al niet voorstellen dat er applicaties zijn die dit onderscheid kunnen aangeven: er zijn geen gegevens aanwezig om op te sturen maar de applicatie weet wel dat er minimaal 3 relaties bestaan...
Ik vermoed dus dat (bijna) alle applicaties deze niet bekende relaties zullen opsturen met aantalVoorkomens='0' aardAantal='exact' en dan heeft deze informatie mijns inziens geen toegevoegde waarde meer.
Voordat we deze functionaliteit schrappen, zullen we moeten bepalen of de aanleiding voor het opnemen ervan nog steeds relevant is en er daardoor wellicht opnieuw een probleem ontstaat.
Uit "de oude doos" heb ik onderstaande opgevist.
RFC – StUF 02.04: Aantal voorkomens relatie
Aanleiding:
Het StUF kennisgevingsbericht heeft een aantal beperkingen ten aanzien van het verstrekken van informatie over het aantal voorkomens van relaties. Het is nu niet mogelijk om expliciet aan te geven:
Analyse:
Bij een element bestaat de mogelijkheid om aan te geven dat een element geen waarde heeft of dat niet bekend is of het een waarde heeft. Ook indien een element een cardinaliteit groter dan 1 heeft, kan op deze wijze de gewenste informatie in een kennisgeving opgenomen worden. Bij relaties is dit momenteel niet mogelijk omdat in kennisgevingen wel voorkomens van relaties opgenomen kunnen worden, maar geen informatie over het aantal voorkomen van de relatie zelf.
Oplossing:
Neem binnen iedere fundamenteel per relatie een beschrijvend element “aantalVoorkomens<relatie>” op. In dit element kan het aantal voorkomens van de relatie worden opgenomen. Door het gebruik van de attributes “exact” of “minimum” kan aangegeven worden dat het aantal voorkomens exact respectievelijk minimaal het opgegeven aantal is. Indien een zender wil aangeven dat een relatie geen voorkomens heeft dan wordt dit element voorzien van de waarde nul met “exact”. Door dit element te voorzien van het attribute “StUF:waardeOnbekend” kan de zender aangeven dat het aantal voorkomens bij de zender niet bekend is. Dit laatste is feitelijk gelijk een waarde nul met “minimum” . De ontvanger kan op basis van de waarde van dit element de feitelijke cardinaliteit van de relatie afleiden en daardoor bepalen hoe de ontvangen voorkomens verwerkt moeten worden.
Use Cases:
Onderstaand wordt een aantal situaties beschreven met daarbij de wijze waarop informatie over deze situatie in een kennisgeving opgenomen kan worden.
Merk op dat door het introduceren van het nieuwe element de mogelijkheid bestaat om informatie over de fundamenteel en informatie over de verschillende voorkomens van een relatie op te nemen in afzonderlijke kennisgevingen, zonder dat daarmee informatie verloren gaat.
Na interne afstemming kunnen we ons wel vinden in voorstel 2.
Het kunnen specifiëren van het aantal relaties is ooit ontstaan uit de discussie dat een applicatie van Burgerzaken b.v. drie kinderen levert en dat een andere applicatie (b.v. Onderwijs) nog een vierde kind zou kunnen leveren, ervan uitgaande dat al deze kinderen in de eigen gemeente zijn ingeschreven. Het vierde kind zou dan niet in overeenstemming zijn met het feit dat Burgerzaken als authentieke bron mag worden beschouwd. De levering van het vierde kind zou daarmee als een afwijkende relatie moeten worden beschouwd. Het is toen een theoretische discussie geweest. Maar als je echt de authentieke bron wilt volgen is het voor een synchronisatiesysteem wel relevant om dat te weten.
Deze theoretische situatie kan simpelweg voorkomen worden (door binnen het synchronisatie systeem / de broker) niet toe te staan dat dergelijke relaties door andere applicaties gewijzigd worden dan de authentieke bron.
In de StUF Expertgroep van 20 maart 2013 is gediscusieerd over het wel of niet verwijderen van de atributen uit het schema. Sommige gemeenten kunnen door het verwijderen nl. problemen ondervinden. Uiteindelijk is besloten om in het schema en in de documentatie slechts aan te geven dat de attributen zoals "StUF:aantalVoorkomens" niet meer functioneel mogen worden gebruikt, de attributen laten we qua syntax echter staan zodat berichten waarin ze voorkomen wel blijven valideren. Op basis van dit erratum (ERR240) wordt een RFC opgevoerd zodat we niet vergeten in de nieuwe versie deze attributen wel weg te halen. Zie RFC RFC0145.
De StUF Expertgroep wil ondanks dat graag weten of er leveranciers zijn die de in de bullets 3 en 5 van paragraaf 3.4.2. gedefinieerde methode hebben geimplementeerd?
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0145.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
In de schema's stuf0301.xsd, bg0310_ent_mutatie.xsd, bg0310_ent_vraagAntwoord.xsd en zkn0310_ent_basis.xsd en in de documentatie (stuf0301.odt) is aangeven dat het gebruik van de attributen tegen de standaard is, de attributen zijn echter niet uit de schema's verwijderd. In de schema's is aangegeven dat de attributen 'deprecated' zijn.
Tijdens de StUF Expertgroep van 18 februari 2015 is gesteld dat de attributes niet meer worden gebruikt. Dit RFC kan dus worden meegenomen in de nieuwe versie van de standaard.
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 oktober 2015 is het RFC goedgekeurd.