Ik kreeg via de service desk van EGEM i-teams een email binnen met de volgende vraag over bg0204:
Hoe gaan we om met de volgende situatie?
Wij ontvangen bijv. een bericht met een wijziging: het oude voorkomen bevat bijv.
<StUF:begindatumRelatie StUF:indOnvolledigeDatum="V">20010101</StUF:begindatumRelatie>
<StUF:einddatumRelatie StUF:indOnvolledigeDatum="M">20090000</StUF:einddatumRelatie>het nieuwe voorkomen bevat:
<StUF:begindatumRelatie StUF:indOnvolledigeDatum="V">20090401</StUF:begindatumRelatie>
<StUF:einddatumRelatie StUF:noValue="geenWaarde" xsi:nil="true"Er zit nu een gat in de geldigheid. Wordt dit onveranderd vastgelegd (met als gevolg dat je in bepaalde perioden geen geldige voorkomens hebt), wordt het gat gedicht door voor de oude einddatum de nieuwe begindatum-1 te gebruiken, nog anders?
Het gegeven voorbeeld is in StUF niet geldig, want een datum mag geen nullen bevatten. Voor de einddatum moet ipv 20090000 bijvoorbeeld gekozen worden 20090701.
De geschetste situatie mag in wezen niet voorkomen bij het vervangen van een relatie, want dan dient eindRelatie in oud gelijk te zijn aan beginRelatie in nieuw (NB: Dit is pas echt zo gespecificeerd in StUF0301, zie tabel 5.6). In StUF0204 is dit niet hard gespecificeerd, maar het is wel de bedoeling. Verder geeft StUF geen voorschriften hoe tegenstrijdige zaken te verwerken in een database, maar slechts betekenis van berichten. Het lijkt me verstandig om een oplossing te kiezen die zo goed mogelijk aansluit bij opvolgende versies van de standaard. In dit geval zou ik dus de meest nauwkeurige datum (1-4-2009) voor zowel einddatumRelatie in oud als begindatumRelatie in nieuw.