Review bg0320 basisschema's

Henri,

Wij wilden proberen de gegenereerde schema's te beoordelen. Daarbij liepen wij tegen wat vragen aan. Die vragen wilden wij graag vergelijken met de actuele versie van RSGB 3.0. Wij kunnen echter nergens op Gemmaonline de actuele versie van RSGB 3.0 vinden. Kan jij deze aan deze discussie koppelen of op andere wijze voor iedereen toegankelijk maken?

op verzoek zijn de documenten van RSGB3.0 en het Sparx-EA-bestand verplaatst naar https://gemmaonline.nl/index.php/RSGB_3.0_in_ontwikkeling 

Ik kom in het schema nogal wat circulaire relaties tegen, bijvoorbeeld in NPS-basis -> heeftReisdocument (NPSRSD-basis) -> gerelateerde (RSD-basis) -> heeftAlsHouder (RSDNPS-basis) -> gerelateerde (NPS-basis) -> heeftReisdocument enz.

Een oplossing hiervoor zou een restriction op XXX-basis zijn (XXX-gerelateerde) waarbij alle heeftXxxx relaties uit zijn weggerestrict en die kan worden gebruikt bij het eerste voorkomen van een gerelateerde, dan krijg je dus:

NPS-basis -> NPSRSD-basis -> RSD-gerelateerde
en
RSD-basis -> RSDNPS-basis -> NPS-gerelateerde

Er zijn een aantal xxxPES relaties gedefinieerd bijvoorbeeld KOZPES, deze moeten volgens mij worden vervangen door KOZNNP en KOZNPS. PES bevat namelijk geen identificerende gegevens zoals sofinummer of RSIN.

Enkele (vooral algemene) opmerkingen vanuit Centric:

1. We stellen voor numerieke elementen die weliswaar cijfers bevatten maar niet per definitie een getal aanduiden om te zetten naar strings met een pattern. Bv. huisnummer, perceelnummer.
2. We stellen voor om de leesbaarheid te vergroten, de generieke simpeltypes (Decimal_1, Integer_1, etc.) een naam te geven die de definitie wat beter beschrijft op dezelfde wijze zoals dat bij strings nu ook al is gedaan.
3. Complextypes voor matchgegevens zijn nu restricties op de basisvariant. Als we minder restricties willen dan is het wellicht beter de basisvariant te definiëren als extensie van de matchgegevens.
4. Als we het gebruik van restricties willen beperken, is het de vraag of de basis complextypes überhaupt moeten worden gedefinieerd. Die worden nu immers alleen gebruikt om met behulp van restriction andere complextypes te definiëren.
   Of we moeten in de koppelvlakken niet gaan restricten, maar de basistypes als 'voorbeeld' gebruiken, waarbij elementen kunnen zijn weggelaten (maar niet verplaatst of toegevoegd).
5. Omdat de matchgegevens-complextypes restricties zijn van de basis-complextypes, zijn de gerelateerden in relaties die deel uitmaken van de matchgegevens niet van het type matchgegevens maar van het type basis (en bevatten dus te veel elementen voor een relatie als matchgegeven).
6. De relaties PESPESHFT en PESPESVAN zijn gerelateerd aan complextype PES-super, maar deze heeft geen identificerende gegevens.
   Vergelijkbaar aan de opmerking die Mark al heeft gemaakt.
7. Doordat er geen choice constructie meer wordt gebruikt, zijn nu alle elementen optioneel waar vroeger een van beide verplicht was (bv. bsn en anpid in nps-basis).
   Gevolg: business rules moeten nu met de hand worden geprogrammeerd. Doet dit de winst van kunnen genereren niet teniet?
8. Attributen die qua definitie niet zijn gewijzigd, hebben soms wel een andere naam gekregen. Dit is jammer. Is het bewust gedaan?
9. Door het gebruik van basis-complextypes in relaties ontstaan oneindige en mogelijk cyclische relaties. Dat lijkt mij onwenselijk. Daarom zou ik ervoor willen pleiten bepaalde relaties uit te sluiten in gerelateerde entiteiten (bv. ouders van kinderen, kinderen van kinderen, etc.).
   Zie ook de opmerking van Mark.
10. Element jaarMaand is gedefinieerd als type gMonth. Die kan echter alleen de maand bevatten en niet het jaar. Daarom deze vervangen door type gYearMonth.
    Deze fout zit in de onderlaag.

Ondanks de deadline wil ik toch nog graag reageren.

Ik heb de NPS bekeken voor wat betreft adres gerelateerde gegevens en vond het volgende:

 Algemeen: Hoe moet je hier mee omgaan bij het vaststellen van een koppelvlak. Ik denk dat er meer uitleg bij een dergelijke opzet moet komen. Ik kan me voorstellen dat er bij NNP en andere entiteiten soortgelijke vragen kunnen worden gesteld.