Extra property voor identificatie in ExterneVeiligheidsObject in het json-schema

[PB-GNM]

Aanleiding wijziging

Het is lastig refereren naar een object wanneer de identificatie daarvan zelf ook een object is. (NEN3610ID)
Dit refereren en opzoeken van objecten op basis van identificatie gebeurt op heel veel plaatsen in de codebase van het REV en ook in generieke modules. In de voorbeeldbestanden van versie 1.3 was dit nog 1 los element die de 3 afzonderlijke samenvoegde.
Dat het nu 3 losse zijn geworden gaat veel pijn doen in de applicaties die hier gebruik van maken.

Voorgestelde wijziging

Er wordt voorgesteld om bij het ExterneVeiligheidsObject een extra niet verplicht element voor de indentificatie op te nemen in het schema dat een samenvoeging is van de 3 losse elementen uit het NEN3610ID.
Dus

"identificatie": {

    "namespace": "NL.IMEV",
    "lokaalID": "gm1979.0003100000119847",
    "versie": "01"

},

wordt

"id": "NL.IMEV.gm1979.0003100000119847.01",
"identificatie": {

    "namespace": "NL.IMEV",
    "lokaalID": "gm1979.0003100000119847",
    "versie": "01"

},

Er is bewust voorlopig voor niet verplicht gekozen, omdat het anders een te grote impact zou hebben, waardoor het niet als z-wijziging gezien zou worden en waardoor het niet op korte termijn ingevoerd zou kunnen worden in het schema. Als het niet door bronhouders aangeleverd wordt, kunnen softwarebouwers het zelf invullen op basis van de inhoud van het oorspronkelijke wel verplichte identificatie element.

Impactanalyse

Geef hier een indicatie van de impact van de wijziging:

• Wie gaat er wat van merken? Softwareleveranciers
• Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
• Heeft het impact op het json-schema? Ja
• Is het backwardscompatibel? Ja, want niet verplicht
• X-, Y- of Z-wijziging: Z Omdat het een afgeleid element is dat automatisch afgeleid kan worden. Het is dus geen nieuwe informatie.

Prioriteit

laag, midden, hoog

Toelichting

Ruimte voor extra toelichting. Bijvoorbeeld alternatieven die je overwogen hebt.

[ob-soge]

Ik zou graag willen voorstellen het element 'entityID' te noemen ipv 'id'.
Dit ivm impact op de codebase waarin 'id' vaak gebruikt wordt in de context van database records.