ExtraElementen ontbreken binnen de relatie TGOPND

[HenriKorver]

In de relatie TGOPND ontbreekt binnen TGOPND-kennisgeving en TGOPND-kennisgeving_Sh het element extraElementen, dat wel voorkomt in TGOPND-basis. Het lijkt daar vergeten te zijn. Ook moeten we even checken of op deze relatie tbv BAG2.0 extraElementen zijn gedefinieerd.

[HenriKorver]

@melsk-r Ik probeer hier de vraag uit je email te beantwoorden. Is zo het zo duidelijk?

Het complextype TGOPND-kennisgeving (zie screenshot) bevat het element brondocument.identificatie met maxLen 20. Volgens BAG 2.0 mag dit veld lengte 40 zijn. Dit probleem moet dan via een extraElement opgelost worden. Echter de extraElementen zijn hier per ongeluk uitgezet door middel van restriction. Deze restriction moet weer worden opgeheven.

Zelfde verhaal voor TGOPND-kennisgeving_Sh, daar moeten de extraElementen ook weer uit de restriction gehaald worden.

[melsk-r]

Aangezien niet iedereen mijn e-Mail heeft gezien hierbij de vraag die ik Henri daarin had gesteld.

Henri geeft in de initiële post van dit issue het volgende aan:

Ook moeten we even checken of op deze relatie tbv BAG2.0 extraElementen zijn gedefinieerd.

Het leek mij dat die vraag niet 'Ook' maar juist 'Als eerste' beantwoord moet worden. Met het antwoord van Henri hierboven is daar wat mij betreft aan voldaan.

[melsk-r]

Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ERR0522. De lijst met onderhoudsverzoeken vind je hier.

[timmerto]

Als ik het goed begrijp wordt nu geprobeerd om een workaround te maken voor een element waar de lengte niet meer overeenkomt met de definitie in BAG 2.0.
In dit geval maakt het toch niet uit of je het element zelf uitbreidt of een nog niet bestaand 'extraElelemten' toevoegt. In beide gevallen heb je een backwards compatibility issue. Of is het de bedoeling om deze aanpassing mee te nemen in dezelfde extra patch als voor GML is bedacht?

[RuudKathmann]

Het uitbreiden van het aantal positie van 20 naar 40 posities lijkt mijn aanzienlijk minder compatibiliteitsproblemen te geven dat het toevoegen van extraElements. Ik zou daarom zeker die weg bewandelen. Overigens vraag ik mij af hoe vaak dit in de praktijk een probleem zal geven. Ik verwacht dat er maar zelden specifiek een brondocument geregistreerd zal worden op de TGOPND relatie.

[mvdbro]

De work around met extraElements is al geruime tijd geleden gedefinieerd in een stuk van Henri Korver en Arjan Kloosterboer over het omgaan met de wijzigingen tgv BAG2.0. Het feit dat bg0310 een bug bevat, namelijk dat alleen op de relatie TGOPND is vergeten om extraElements op te nemen, lijkt me geen reden om nu opeens een andere oplossing te kiezen. Het meest logische is nu het oplossen van de bug dat alleen op de TGOPND relatie extraElements niet zijn gedefinieerd in bg0310. Dit is een verandering die backwards compatible is, want iedereen mag zo'n extraElement negeren.

[sbrouwer71]

Samen met Maarten, ben ik van mening dat we de werkwijze moeten aanhouden die in 2018 ook voor de andere BAG-wijzigingen is doorgevoerd. Dit is met extraElements opgelost, dus ook in dit geval, lijkt me dat de meest gepaste oplossing. Zie de lijst met extraElements voor deze oplossing.

Kijkend naar die lijst, valt me op dat daar geen extraElement is opgenomen voor het brondocument-id voor deze relatie. In de BAG is het immers gebruikelijk om de relaties te beschouwen als een kenmerk van één van de betrokken objecten. Zo is de relatie tussen VBO en PND onderdeel van de VBO en wijzigingen daarin worden met een brondocument dat is gekoppeld aan het VBO opgenomen in de registratie. De extraElements voor document-id zijn dan ook alleen van toepassing gesteld op AOA, NUM, OPR, PND, TGO, VBO en WPL. Een nieuw extraElement op deze relatie is voor de BAG dus overbodig. Het lijkt me dus dat om die reden het opnemen van de extraElements in de TGOPND-relatie niet nodig is. Er zal bij deze relatie geen brondocument worden opgenomen met een id conform de BAG.

De vraag is daarmee of het écht nodig is om deze patch door te voeren: theoretisch gezien zijn de extraElements inderdaad vergeten, maar hierboven staat geen praktische reden om dit te patchen. Is er daadwerkelijk behoefte aan deze patch? Als die er is, dan is het opnemen van de extraElements een (blijkbaar) noodzakelijke en redelijk backwards compatible correctie en kunnen we die doorvoeren.

[sbrouwer71]

In aanvulling op het bovenstaande: in 2016 is dit al opgemerkt (RFC0344). Dit is destijds besproken en er is gesteld dat dit te ingrijpend was voor een patch (niet backwards compatible). Het is als RFC goedgekeurd, en staat als zodanig dus (nog steeds) klaar voor een nieuwe versie.

Dan blijft mijn vraag of er nu wél dringende redenen zijn om dit alsnog te patchen?

Opmerking bij de RFC van destijds:

16-3-2016, Robert Melskens: Tijdens de StUF Expertgroep van 16 maart 2016 is aangegeven dat het niet voorkomen van de extraElementen weliswaar een fout is maar dat een toevoeging daarvan helaas niet backwards compatibel is. Daardoor zal het pas goed gaan werken als alle partijen de betreffende patch hebben geïmplementeerd. Om die reden is besloten het onderhoudsverzoek om te zetten naar een RFC. 20-7-2016, Robert Melskens: Tijdens de StUF Expertgroep van 20 juli 2016 is besloten dit RFC goed te keuren.

--

[timmerto]

Mocht er toch een aanpassing nodig zijn.... Dan maakt het op zich niet uit of je een extraElement opneemt of de lengte aanpast. In beide gevallen moet het ontvangende systeem de nieuwe xsd eerder hebben toegepast dan het zendende systeem. Als je kijkt naar de impact van de aanpassing is het uitbreiden van de lengte minder ingrijpend dan het implementeren van een nieuw 'extra' element. De BAG 2.0 oplossing dmv extraElementen is geen fraaie oplossing. Laten we proberen dit niet tot standaard te verheffen.

[mvdbro]

Binnen bg0310 kan je het brondocument voor de wijziging van een relatie tussen een VBO en een PND alleen met goed fatsoen kwijt op de relatie TGOPND. Bij opname binnen PND of TGO is niet helder waarop het brondocument betrekking heeft. Om die reden is in deze relatie ook het element brondocument opgenomen.

Met de komst van de BAG2.0 heeft VNG Realisatie extraElements gedefinieerd om de grotere lengte van het brondocument/identificatie kwijt te kunnen. Dit extraElement moet dan ook toegepast kunnen worden binnen TGOPND en daarom is het toevoegen van het vergeten aan te zetten extraElementen in het complexType TGOPND-kennisgeving nodig (het is wel aanwezig binnen TGOPND-basis).

Installatie van deze patch is noodzakelijk in alle situaties waarin berichten met BAG-gegevens conform BAG2.0 worden verwerkt. Deze patch is downwards compatible, want alle berichten die eerder valideerden, valideren nog steeds. Er valideren alleen ook berichten die zonder de patch niet valideren. Iedereen die functioneel niets wil doen met de extra informatie staat dit vrij, want het gaat om een extraElement.

De opmerking van Ton dat het ontvangende systeem de patch eerder moet toepassen dan het zendende systeem snap ik niet. Zo lang het zendende systeem de patch niet heeft toegepast, hoeft het ontvangende systeem toch ook niets te doen. Het is natuurlijk wel waar dat het ontvangende systeem ook moet patchen, als het zendende systeem dit doet om van de patch gebruik te kunnen maken en om de berichten te kunnen blijven valideren. Dit geldt volgens mij voor elke patch die leidt tot wijzigingen in het valideren van berichten. Als dit voldoende is om een patch te verbieden, dan kan je nooit een patch doorvoeren om een fout te herstellen.

[sbrouwer71]

Ik snap nog steeds niet waarom de patch nodig is: dit document zou door de BAG moeten worden aangeleverd. Deze zal dat echter nooit doen omdat bij een wijziging van deze relatie in de BAG ook het betreffende VBO wordt gewijzigd en op díe wijziging zal het nieuwe brondocument worden gekoppeld (aan het VBO dus).

Als er een TGOPND-wijziging wordt aangeboden met een eigen brondocumentnummer, dan zal dit document niet uit de BAG komen (in ieder geval niet uit de basisregistratie) en kunnen we deze dus blijven beperken tot de lengte van alle andere document-id's in het schema. Het extraElement is daardoor in mijn ogen dus nog steeds niet noodzakelijk.

Overigens zal de ontvanger in dit geval weldegelijk op tijd moeten patchen: het kan nu het extraElement niet zomaar negeren omdat het geen element is in de xsd. Tenzij de ontvanger geen schemavalidatie uitvoert, zal het dus een bericht met een extraElement op deze plek moeten afkeuren.

[mvdbro]

Mijn interpretatie van de gewenste werkwijze is dat bij een wijziging vanuit de BAG in een TGOPND relatie het brondocument voor deze wijziging hoort te worden vastgelegd op de TGOPND-relatie en niet bij de TGO. Binnen bg0310 verandert er bij een wijziging van een TGOPND-relatie er per slot van rekening ook niets in de TGO. Alleen TGOPND-relaties worden toegevoegd, gewijzigd of verwijderd en het lijkt mij dan ook logisch om bij de gewijzigde relaties vast te leggen wat de grond voor die wijziging is. Het werkt in bg0310 inderdaad anders dan in de BAG, omdat in de BAG de relaties attributen zijn van de VBO.

[sbrouwer71]

Krijg je dan niet een situatie dat in de basisregistratie aan het VBO een ander document is gekoppeld dan voor de afnemers het geval is? Dat lijkt mij zeker zo onwenselijk. Het is in StUF inderdaad niet zo bedoeld, maar moeten we niet toch de basisregistratie blijven volgen? Dát zorgt volgens mij voor meer eenduidigheid dan in het berichtenverkeer af te gaan wijken van de vastgelegde situatie in de basisregistratie. Er zal sowieso een VBO-mutatie worden verstuurd door de BAG omdat één van de TGO-eigenschappen (namelijk het document waarin de huidige situatie is vastgelegd) is gewijzigd.

[mvdbro]

Functioneel zijn aan de VBO in een bg0310 gegevensmagazijn dezelfde brondocumenten gekoppeld als in de BAG. Alleen liggen de brondocumenten vast op twee verschillende plaatsen, namelijk binnen TGO en binnen TGOPND. Het RSGB heeft lang geleden deze keuze gemaakt en het vergeten zijn van extraElementen binnen TGOPND is een rare aanleiding om dit ter discussie te stellen.

Op de achtergrond speelt voor mijn gevoel een grote weerzin tegen het patchen van bg0310, waarbij een nieuwe schemaversie ontstaat. Deze patch is overigens sowieso nodig door de verandering in de GBA. Omdat een patch toch noodzakelijk is heeft het dan mijn voorkeur om vast te houden aan de huidige werkwijze. Afwijking van de huidige werkwijze zal door VNG Realisatie moeten worden vastgesteld door ook het RSGB aan te passen.

[sbrouwer71]

Dat gevoel is niet helemaal bezijden de waarheid... Zoals ik eerder al schreef: als we dit aan moeten passen, dan moet het maar en dan ligt de meest voor de hand liggende oplossing in het toevoegen van de extraElements, omdat dit in lijn is met de andere aanpassingen voro BAG 2.0. Dat neemt niet weg dat het naar mijn gevoel nu nog steeds een oplossing is voor een vooral theoretisch probleem en dan ook nog een oplossing die praktisch tot problemen zou kunnen leiden. Daarom mijn aarzeling en mijn vraag of het nu een daadwerkelijk probleem is of een theoretisch geval.

Het feit dat er voor de wijziging in de GBA een patch moet worden uitgebracht is voor mij geen reden om nog meer potentiële interoperabiliteitsproblemen te introduceren. Hoe meer er wijzigt, hoe meer kans op problemen. Een systeem die TGOPND-gegevens verwerkt hoeft immers geen last te hebben van een wijziging in een codering in de GBA. Daarom wil ik de wijziging voor GBA geheel los zien van de wijziging die hier wordt voorgesteld (hoewel beide wijzigingen idealiter natuurlijk in één patch worden uitgebracht).

[melsk-r]

Ik en mijn collega's binnen VNG Realisatie hebben een voorkeur voor het aanbrengen van de extraElements in de schema's. Daarmee lossen we dit probleem op en herstellen we de inconsequentie in het schema. Daarmee heeft een meerderheid in de StUF Expertgroep een voorkeur voor die oplossing.

Zoals gebruikelijk zullen we ter review eerst een pre-patch aanbieden waarin dit issue op deze wijze wordt opgelost. De patch zelf verwachten we begin mei te publiceren.

[melsk-r]

In de pre-patch 30 zijn de complexTypes 'TGOPND-kennisgeving' en 'TGOPND-kennisgeving_Sh' als volgt aangepast:

<complexType name="TGOPND-kennisgeving">
    <complexContent>
        <restriction base="BG:TGOPND-basis">
            <sequence>
                <element name="gerelateerde" type="BG:PND-kerngegevensKennisgeving" nillable="true"/>
                <element name="inOnderzoek" type="StUF:StatusMetagegevenNoValue" nillable="true" minOccurs="0"/>
                <element name="brondocument" type="BG:BrondocumentBGR" minOccurs="0"/>
                <element ref="StUF:tijdvakRelatie" minOccurs="0"/>
                <element ref="StUF:tijdvakGeldigheid" minOccurs="0"/>
                <element ref="StUF:tijdstipRegistratie" minOccurs="0"/>
                <element ref="StUF:extraElementen" minOccurs="0"/>
            </sequence>
            <attribute ref="StUF:entiteittype" use="required" fixed="VBOPND"/>
            <attribute ref="StUF:scope" use="prohibited"/>
            <attribute ref="StUF:verwerkingssoort" use="required"/>
        </restriction>
    </complexContent>
</complexType>
<complexType name="TGOPND-kennisgeving_Sh">
    <complexContent>
        <restriction base="BG:TGOPND-kennisgeving">
            <sequence>
                <element name="gerelateerde" type="BG:PND-kerngegevensKennisgeving" nillable="true"/>
                <element name="inOnderzoek" type="StUF:StatusMetagegevenNoValue" nillable="true" minOccurs="0"/>
                <element name="brondocument" type="BG:BrondocumentBGR" minOccurs="0"/>
                <element ref="StUF:tijdvakRelatie" minOccurs="0"/>
                <element ref="StUF:tijdvakGeldigheid" minOccurs="0"/>
                <element ref="StUF:tijdstipRegistratie" minOccurs="0"/>
                <element ref="StUF:extraElementen" minOccurs="0"/>
            </sequence>
            <attribute ref="StUF:entiteittype" use="required" fixed="VBOPND"/>
            <attribute ref="StUF:sleutelSynchronisatie" use="required"/>
            <attribute ref="StUF:verwerkingssoort" use="required"/>
        </restriction>
    </complexContent>
</complexType>

[timmerto]

Ik zie in de pre-patch de aanpassing niet terug onder TGOPND bij de samengestelde berichten (BAG) terwijl daar brondocument wel bij de elementen is opgenomen

[melsk-r]

Je hebt helemaal gelijk Ton. Even over het hoofd gezien. Ik neem hem op in de patch.