Review bg0320 basisschema's

16 reacties / 0 nieuw
Henri Korver
Review bg0320 basisschema's

In de bijlage (bg0320_20170405.zip) zijn de basisschema's te vinden voor bg0320. Deze schema's zijn gegenereerd vanuit het UGM. De schema's worden bij deze aan de StUF Expertgroep aangeboden ter review. De review betreft de volgende twee schema's die te vinden zijn in de folder bg0320 van de zipfile: 

  • ​bg0320_ent_basis.xsd
  • bg0320_datatypes.xsd

In dezelfde folder bevindt zich tevens de spreadsheet "review bg0320.xlsx" waarin het commentaar kan worden geplaatst in een van te voren gedefinieerd formaat. Per complex- of simpleType kan het commentaar op een gestructureerde manier ingevoerd worden. De spreadsheet bevat twee tabbladen: een voor bg0320_ent_basis.xsd​ en een voor bg0320_datatypes.xsd​.

De deadline voor inzending van de feedback is  vrijdag 14 april 2017 om 17.00 te versturen per email (naar henri.korver@kinggemeenten.nl).

Mocht je input hebben die belangrijk is dan kun je die al eerder delen via deze discussie. Dan kan iedereen daar zo snel mogelijk op reageren.

De feedback zal worden behandeld in de EG van 19 april.

 

 

Ruud Kathmann

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?

Henri Korver

In de bijlage heb ik de versie van het RSGB 3.0 toegevoegd zoals die in de regiegroep van 7 oktober 2015 is goedgekeurd. Er is een recentere versie waarin allerlei kleine foutjes zijn hersteld die tijdens het verstuffen aan het licht zijn gekomen. Die versie heb ik als een EA-bestand maar helaas niet in word of pdf formaat. Ik heb Ellen Debats gevraagd die zo snel mogelijk beschikbaar te stellen.

Bijlage

7_GEMMA_RSGB_3.0_deel_1_en_2_20150918_-_Word_versies.zip
Henri Korver

Zojuist heb ik een recentere versie gevonden van RSGB 3.0 in pdf-formaat, klik hier. Dit zou voldoende nauwkeurig moeten zijn voor de review van de schema's. Als ik Ellen heb weten te bereiken zal ik de meest recente versie hier beschikbaar stellen.

 

 

 

Henri Korver

Ik heb zojuist te horen gekregen dat de laatstgenoemde versie van het RSGB 3.0 (die in pdf formaat) de meest recente versie is.

Remko de Haas

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

Mark Paanakker

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

 

Mark Paanakker

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.

Sid Brouwer

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.
Henri Korver

Bijgaand de spreadsheet waarin ik de feedback op de review heb verzameld. Tevens ben ik vandaag begonnen met de verwerking van het commentaar, zie de kolommen Actie, Reactie KING en Status. Morgenochtend tijdens de EG zal ik deze spreadsheet  gebruiken om het review-commentaar te bespreken

Bijlage

review bg0320.xlsx
Henri Korver

Naar aanleiding van de discussies in de expertgroep van gisteren heb ik de volgende twee complexType’s aan het schema toegevoegd en in alle relaties PES-super en SUB-super vervangen door resp. PES-basis en SUB-basis (zie ook het schema in de BIJLAGE).

       <complexType name="PES-basis">
             <choice minOccurs="0" maxOccurs="2">
                    <element name="natuurlijkPersoon" type="bg:NPS-basis"/>
                    <element name="nietNatuurlijkPersoon" type="bg:NNP-basis"/>
             </choice>
             <attribute ref="bg:entiteittype" fixed="PES"/>
       </complexType>


       <complexType name="SUB-basis">
             <choice minOccurs="0" maxOccurs="3">
                    <element name="natuurlijkPersoon" type="bg:NPS-basis"/>
                    <element name="nietNatuurlijkPersoon" type="bg:NNP-basis"/>
                    <element name="vestiging" type="bg:VES-basis"/>
             </choice>
             <attribute ref="bg:entiteittype" fixed="SUB"/>
       </complexType>

Het aardige van de bovenstaande oplossing is dat we nog steeds XSD-extension gebruiken voor het definiëren van NPS-basis en NNP-basis (op basis van VES-super en PES-super) en VES-basis (op basis van SUB-super). Dus het beste uit twee werelden: zowel choice als extension.

Dus bij deze de vraag aan de StUF Expertgroep of het nu naar wens is? Zo nee, graag zo snel mogelijk reageren via dit forum.

Bijlage

bg0320_ent_basis_v02.xsd
Ton Timmermans

Ondanks de deadline wil ik toch nog graag reageren.

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

SUB:adresBinnenland

tekst? Onder welke binnenlandsAdres relatie hieronder valt deze?

SUB: correspondentieadresBuitenland

adresregels en landnaam (geen landcode: Conflict met GBA tabellen?)

Is deze relatie echt onderdeel van SUB, speelt dit bij NPS èn NNP?

SUB:postadres

lijkt me duidelijk.

SUB: verblijfBuitenland

adresregels en landnaam (geen landcode: Conflict met GBA tabellen?)

SUB:heeftAlsCorrespondentieadres

lijkt me duidelijk.

inp.datumBeginGeldigheidVerblijfplaats

Is dit element het equivalent van de persoonslijst categorie 8? Is dus redundant met tijdvakRelatie van inp.VerblijfAdres en heeftAlsAdres

inp.bronAdresBuitenland

tekst? Overlap met SUB:verblijfBuitenland!

inp.verblijfadres

Relatie naar TGO, maar wordt nu in Bg0204/0310 alleen vanuit BRP/GBA aangeleverd. In feite kent de GBA de relatie niet als zodanig, maar wordt dit afgeleid aangezien bij de verblijfplaats op de persoonslijst ook de id van het 'verblijfsobject' is opgenomen.  

heeftAlsAdres

Relatie naar AOA, ook vanuit andere bronnen dan BRP/GBA geleverd. Is dit het verblijfsadres dat nu onder BG0310NPS als groep voorkomt wat in feite een doublure is van de inp.verblijfadres?
Het is daarom niet duidelijk wanneer een leverancier/afnemer/vraagsteller de inp.verbijfadres of heeftAls Adres moet gebruiken!

Ook vraag ik af of deze zo algemeen gedefinieerd kan worden dat het onder SUB thuishoort. Denk aan het bezoekadres bij een NNP!

 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.

 

 

 

Henri Korver

Zie bijlage voor de nieuwe schema's die in de aankomende bijeenkomst van de EG behandeld zullen worden.

Bijlage

bg0320_20170509.zip
Henri Korver

Zie bijlage voor het UGM RSGB 3 van waaruit de bg0320 schema's zijn gegenereerd.

Bijlage

UGM RSGB 3.zip
Henri Korver

De relevante diagrammen zijn te vinden in de package Relatiegrafieken dat via het volgende pad te vinden is:

KING/KING:UGM/UGM BG/Diagram/Relatiegrafieken.

 

 

Henri Korver

Bijgaand mijn presentatie van vanochtend in de Workshop Generatie Standaarden in La Vie te Utrecht.

Bijlage

workshop ugm.pptx