extraElements in gerelateerde

Ditzelfde geldt ook voor ZKN 3.10! Dus ook graag daar in meenemen.

Ditzelfde geldt ook voor EF 03.10! Dus ook graag daar in meenemen.

Voorbeeld: extra element voor het meegeven van een codeGemeenteVanInschrijving van de aanvrager in de gerelateerde VHD/isAangevraagdDoor/gerelateerde/. Hierdoor kan bepaald worden of de verhuizing binnen- of buitengemeentelijk is. Dit is van belang voor het bepalen van de afhandeling.

Dit issue is door mij onderzocht en na overleg met Maarten van de Broek is de conclusie getrokken dat alleen op de complexType 'NAT-gerelateerde' (bg0310-ent-vraagAntwoord.xsd) een 'StUF:extraElementen' element gedefinieerd moest worden.

Aan NAT-identificatie en NAT-identificatieKennisgeving hoeft dit niet toegevoegd te worden, omdat deze twee types uitsluitend bedoeld zijn voor identificatie.In alle andere gevallen waar de complexType in gebruik is als gerelateerde entiteit en dit element afwezig is, is ingeschat dat het terecht afwezig is omdat het een complexType betreft met kerngegevens of een complexType van een superentiteittype.

Zie 'complexTypes en extraElementen v2.1.xlsx' waarin we overigens ook andere type complexTypes hebben onderzocht op het al dan niet terecht ontbreken van het element 'StUF:extraElementen'.

Dennis de Wit heeft op mijn onderzoek gereageerd en naar mijn mening goede argumenten argumenten aangedragen om het 'StUF:extraElementen' element toch op meer gerelateerde complexTypes te definieren.

In het kort komt het op het volgende neer. Als je in een StUF-BG 2.04 bericht de mogelijkheid had om een gegeven mee te geven in een element danwel in een extraElement dan lijkt het me logisch dat je dat gegeven ook in een StUF 3.01 bericht mee wilt kunnen geven, bijv. omdat het StUF 2.04 bericht getransformeerd moet worden naar een StUF 3.01 bericht.
Als je in versie 3.01 echter op een equivalente gerelateerde entiteit echter geen extraElement kunt definiëren dan betekent dat het volgende:

• Een in versie 2.04 in een extraElement meegegeven gegeven (binnen een gerelateerde entiteit) kan je niet meer meegeven in versie 3.01.
• Een in versie 2.04 in een normaal (een wel in GFO of RSGB gedefinieerd) element meegegeven gegeven (binnen een gerelateerde entiteit) dat niet meer ondersteund wordt in versie 3.01 kan je niet meer meegeven in versie 3.01.

PinkRoccade zegt dat dit o.a. speelt bij de entiteiten NPS en NNP zodra deze als gereleateerde worden meegegeven binnen de sectormodellen bg0310, zkn0310 en ef0310.

Enkele voorbeelden:

• In StUF-EF komt in een VHD-kennisgeving van ef0204 in het element  ‘VHDPRSANV/PRS’ een ‘extraElementen’ element voor. Binnen ef0310 in ‘vhdLk01/object/isAangevraagdDoor/gerelateerde’ komt het ‘extraElementen’ elementniet meer voor. De onderliggende StUF-BG complexType ondersteunt het ‘extraElementen’ elementen opdie plaats echter wel dus lijkt dit een zaak voor de StUF-EF beheerder. Het EF complexType verwijderd het‘extraElementen’ element onterecht.
• Wellicht komen dit soort errata op nog enkele plaatsen voor.
• Binnen bg0204 ‘HHD-kennisgeving/HHDPRS/PRS/PRSADRVBL/ADR’ komen enkele elementen (zoals ‘Postbusnummer’ en ‘Antwoordnummer’) voor waarvoor in bg0310 geen placeholder aanwezig is.Deze gegevens lijken dan ook buiten de boot te vallen.
• In ‘KDO-kennisgeving’ (versie 2.04) komen binnen ‘KDOSUBVZG/NNP’ elementen voor (bijv. ‘zaaknaam’ en ‘datumOprichtingNietNatuurlijkPersoon’) die binnen versie 3.10 (‘kozLk01/object/heeftAlsVoornaamsteZakelijkGerechtigde/gerelateerde/nietNatuurlijkPersoon’) niet voorkomen maar waarvoor je ook geen ‘extraElementen’ element kunt gebruiken.

Deze post is tijdens de StUF Expertgroep van 17 oktober 2012 besproken. Daar werd het volgende gesteld:

• Gerelateerde entiteiten in Kennisgevingen zijn alleen bedoeld ter identificatie en kunnen alleen maar kerngegevens of de sleutel van het object bevatten.
• Op plaatsen waar 'StUF:extraElementen' in Antwoord- en Vraagberichten is vergeten moet dit opgenomen worden.

Navraag bij Maarten van de Broek leerde mij ook dat 'StUF:extraElementen' niet is opgenomen in de entiteiten RPS en SUB omdat dit supertypen zijn. Ook complexTypes voor kerngegevens mogen eveneens geen 'StUF:extraElementen' bevatten. Deze regels toepassend op de lijst met gerelateerde complexTypes waarin 'StUF:extraElementen' ontbreekt, te weten:

AOA-kerngegevens, AOA-kerngegevensKennisgeving, KOZ-kerngegevens, KOZ-kerngegevensKennisgeving, KZA-kerngegevens, MAC-kerngegevens, MAC-kerngegevensKennisgeving, NAT-gerelateerde, NAT-identificatie, NAT-identificatieKennisgeving, NNP-kerngegevens, NNP-kerngegevensKennisgeving, NPS-kerngegevens, NPS-kerngegevensKennisgeving, PND-kerngegevens, PND-kerngegevensKennisgeving, RPS-antwoord, RPS-basis, RPS-gerelateerdeAntwoord, RPS-gerelateerdeKennisgeving, RPS-gerelateerdeVraagScope, RPS-gerelateerdeVraagSelectie, RPS-kerngegevens, RPS-kerngegevensKennisgeving, RPS-vraagScope, RPS-vraagSelectie, RSD-kerngegevensKennisgeving, SUB-gerelateerdeAntwoord, SUB-gerelateerdeVraagScope,
SUB-gerelateerdeVraagSelectie, SUB-kerngegevens, SUB-kerngegevensKennisgeving, SUBRPS-basis, TGO-kerngegevens, TGO-kerngegevensKennisgeving, TGO-kerngegevensKennisgevingPND, TGO-vraagScopeKerngegevens, VES-kerngegevens, VES-kerngegevensKennisgeving, WOZ-kerngegevens, WOZ-kerngegevensKennisgeving, ZKR-kerngegevens, ZKR-kerngegevensKennisgeving, ZRA-kerngegevens.

leert ons dat alleen de complexTypes 'NAT-gerelateerde' en 'NAT-identificatie' overblijven waarvan op de laatste ook geen extraElementen worden geplaatst omdat ook deze bedoeld is ter identificatie.

In een volgende patch zal aan de complexType 'NAT-gerelateerde' het element 'StUF:extraElementen' worden toegevoegd.

Centric is niet akkoord om deze door te voeren in een patch. Deze wijziging is niet backwards-compatible.

Dag Hein,

Zou je even aan kunnen geven in welke zin dit niet backwards compatible is?
Op berichtenniveau kan dit toch geen probleem vormen aangezien het 'StUF:extraElementen' element geen verplicht element wordt.

In de StUF Expertgroep van 20 maart 2013 wordt de in de vorige reactie gestelde vraag als volgt beantwoord:

Met een, conform dit erratum, gewijzigd schema kunnen systemen berichten verwachten die zij niet ondersteunen. In de Expertgroep wordt echter ook gesteld dat dit wel het principe is van XML. Een systeem moet een bericht kunnen verwerken ook al bevat het elementen die het niet kent. De StUF Expertgroep ziet echter een verschil tussen strenge validatie en het kunnen verwerken als applicatie. De StUF Expertgroep heeft daarom besloten het erratum (ERR233) af te wijzen.

Post gesloten.