In de verschillende discussies, o.a. over de omvang van RSGB, wordt zo hier en daar het gebruik van ‘aanvullendeElementen’ genoemd. Bijvoorbeeld een toepassing waarbij voor een koppelvlak benodigde maar niet in het RSGB aanwezige attributen aan het UGM van een koppelvlak worden toegevoegd. Dit soort elementen zouden dan in de XML-berichten m.b.v. ‘aanvullendeElementen’ aan de betreffende entiteit worden toegevoegd. Denk daarbij aan een attribuut als ‘leerlingnummer’ voor een leerling.
StUF kent verschillende manieren om extra gegevens aan een entiteit toe te voegen. Ik zou graag willen dat duidelijk wordt wanneer welke manier gebruikt wordt. En hier een nieuwe manier aan toevoegen die naar mijn idee in bepaalde situaties beter aansluit bij de wens scherpe koppelvlakken te definiëren.
Hieronder een aanzet daarvoor, op basis van verschillend soort gebruik:
1. Bij de implementatie van een koppelvlak (bij een gemeente) worden (voor dit proces en bij deze gemeente) specifieke gegevens toegevoegd aan een entiteit en meegestuurd, die niet in een gekend informatiemodel (RSGB, RGBZ, imZTC of een domeinmodel) voorkomen.
In deze situatie dienen extraElementen of aanvullendeElementen te worden gebruikt.
Het gebruik van extraElementen is mogelijk wanneer er geen schemavalidatie gewenst is en de gegevens éénlagig zijn (niet hiërarchisch gestructureerd). Wanneer wel schemavalidatie noodzakelijk of gewenst is, of wanneer de gegevens in een meerlagige structuur moeten worden opgenomen, kan hiervoor aanvullendeElementen worden gebruikt. Het voordeel van extraElementen kan zijn dat hiermee elementen makkelijk en snel kunnen worden toegevoegd.
2. In een koppelvlak moeten additionele entiteiten en/of gegevens worden toegevoegd t.b.v. optionele functionaliteit in een taakspecifieke applicatie. Deze entiteiten en/of gegevens komen niet in een gekend informatiemodel (RSGB, RGBZ, imZTC of een domeinmodel) voor. Van de ontvangers binnen de keten mag niet worden vereist dat ze deze aanvullende gegevens kennen en kunnen verwerken.
Een voorbeeld zou kunnen zijn dat er één service voor productaanvragen is (in de service bus), maar er voor elk soort product een aantal productspecifieke gegevens zijn. Of wanneer hetzelfde bericht naar een taakspecifieke applicatie gaat (die de productspecifieke gegevens kent en nodig heeft) en naar een gegevensmagazijn/zakenmagazijn (die de productspecifieke gegevens niet kent).
Een ander voorbeeld is dat het vertalen van een bericht van bijvoorbeeld RSGB3 naar RSGB2 niet alle elementen, groepen en/of relaties in RSGB 2 voorkomen. Je wilt in het RSGB 2 bericht de niet-vertaalbare RSGB 3 elementen, groepen en relaties kunnen opnemen die voor de ontvanger niet bekend hoeven te zijn.
Hiervoor moeten aanvullendeElementen worden gebruikt.
3. In een koppelvlak wordt een entiteittype/objecttype gebruikt die een specialisatie is van een entiteittype/objecttype in een ander informatiemodel. Bijvoorbeeld een leerling is een specialisatie van natuurlijkPersoon.
Hiervoor wordt de specialisatie entiteit (bijvoorbeeld leerling) gedefinieerd als extensie op het type waar het een specialisatie op is (bijvoorbeeld natuurlijkPersoon). De elementen van de specialisatie zitten dan in de namespace van het domeinmodel of koppelvlak, de elementen van het basistype zitten in de orginele namespace van dat type.
Bijvoorbeeld:
<KV:leerling KV:entiteittype="LRL">
<BG:inp.bsn>555333111</BG:inp.bsn>
<BG:geslachtsnaam>aaaaaaaa</BG:geslachtsnaam>
<BG:voorletters>abc</BG:voorletters>
<BG:geslachtsaanduiding>M</BG:geslachtsaanduiding>
<BG:geboortedatum>12345678</BG:geboortedatum>
<KV:leerlingnummer>1234567</KV:leerlingnummer>
</KV:leerling>
4. Bij het definiëren van koppelvlakken is vaak behoefte aan specifieke gegevens die niet in het UGM zitten. Zie bijvoorbeeld de koppelvlakken Taxatie Motorbrandstofverkooppunten (StUF-WOZ) en Jeugdzorg (StUF-ZKN).
In een koppelvlak worden domeinspecifieke of processpecifieke gegevens bij een entiteit gestuurd. De basisentiteit is een objecttype uit een horizontaal informatiemodel (RSGB, RGBZ, imZTC). Binnen dit domein/koppelvlak zijn gegevens relevant die niet zijn opgenomen in het horizontale model (die alleen meervoudig gebruikte gegevens bevat).
Bijvoorbeeld in een specifiek koppelvlak moet bij de natuurlijkPersoon ook de kleur ogen gecommuniceerd worden.
Ik zou hier dezelfde methode gebruiken als bij punt 3 is beschreven
<KV:object KV:entiteittype="NPS">
<BG:inp.bsn>555333111</BG:inp.bsn>
<BG:geslachtsnaam>aaaaaaaa</BG:geslachtsnaam>
<BG:voorletters>abc</BG:voorletters>
<BG:geslachtsaanduiding>M</BG:geslachtsaanduiding>
<BG:geboortedatum>12345678</BG:geboortedatum>
<KV:kleurOgen>bruin</KV:kleurOgen>
</KV:object>
5. Nieuwe ontwikkelingen in de basisregistraties of Europese wetgeving (bijv. invoering van IBAN en BIC voor bankrekeningen). Deze kunnen worden toegevoegd aan het horizontale UGM, meestal (en bij voorkeur) gevoed vanuit een toevoeging in het semantische informatiemodel (RSGB, RGBZ, imZTC of domeinmodel).
Het element kan in een of meerdere berichten in een of meerdere koppelvlakken worden toegevoegd naar behoefte, en zal daar als "normaal" onderdeel van de entiteit worden opgenomen. Het element wordt dus alleen in koppelvlakken opgenomen als onderdeel van een release van het koppelvlak op basis van functionele behoefte bij het koppelvlak.
Aangezien de impact van een toevoeging aan een horizontaal UGM veel kleiner is dan een toevoeging aan een sectormodel (waarbij de toevoeging consequenties zou hebben in alle berichten op betreffende entiteit in de berichtencatalogus), hoeft hiervoor geen extraElementen te worden gebruikt.
<KV:object BG:entiteittype="NPS">
<BG:inp.bsn>555333111</BG:inp.bsn>
<BG:geslachtsnaam>aaaaaaaa</BG:geslachtsnaam>
<BG:voorletters>abc</BG:voorletters>
<BG:geslachtsaanduiding>M</BG:geslachtsaanduiding>
<BG:geboortedatum>12345678</BG:geboortedatum>
<BG:iban>11BANK0000000000</BG:iban>
</KV:object>