In de indOnvolledigeDatum ontbreekt in het waardebereik de mogelijkheid om aan te geven dat bekend is dat de datum er is, maar dat de waarde niet bekend is. In de bevolkingsadministratie komt dit voor bij de overlijdensdatum van vertrokken personen. Als ze 150 jaar geleden geboren zijn, dan is het zeker dat ze zijn overleden, maar de overlijdensdatum kan onbekend zijn (indien een stoffelijk overschot is gevonden rond de jaarwisseling en de datum overlijden kan niet nauwkeurig vastgesteld worden). Hetzelfde geldt voor de begindatums van allerhande relaties. Lang niet altijd is op een jaar nauwkeurig bekend op welk moment een relatie is ontstaan. Bij datum elementen met optionaliteit 0 kan hiervoor niet de waarde null gebruikt worden, omdat deze ook de waarde heeftGeenWaarde omvat.
Voor datumelementen met optionaliteit 1 lijkt het niet opnemen van een dergelijk element of het opnemen met StUF:noValue = waardeOnbekend dezelfde betekenis te hebben als het opnemen met jaar onbekend. Toch wordt ook voor datum elementen met optionaliteit 1 om de volgende twee redenen een onderscheid gemaakt tussen deze twee waarden:
- We maken dit onderscheid ook bij datumelementen met optionaliteit 0;
- Jaar onbekend heeft binnen bijvoorbeeld de bevolkingsadministratie als extra betekenis dat het niet aannemelijk is dat de datum nauwkeuriger is vast te stellen (net een nuance anders dan dat je het gewoon niet weet). Deze nuance kan semantisch relevant zijn.
Voorstel
Voeg in het waardebereik van het attribuut indOnvolledigeDatum de waarde J toe met als betekenis: De datum heeft een waarde, maar onbekend welke.
Met dank aan MvdB dd 11-08-2006.
Hoi John,
Op pagina 31 en 32 van de stuf0204 standaard staat de volgende definitie van waardeOnbekend:
Indien het element wel een waarde heeft maar de waarde is bij de zender niet bekend en het element is verplicht, dan wordt dit met StUF:noValue=waardeOnbekend (e) en een lege elementinhoud.
Deze zin is grammaticaal niet helemaal correct en moet nog eens worden herschreven. Bijvoorbeeld:
Indien het element wel een waarde heeft, maar de waarde bij de zender niet bekend is, en het element verplicht is, dan wordt dit element voorzien met het attribute StUF:noValue=waardeOnbekend (e) en een lege elementinhoud.
De strekking blijft natuurlijk hetzelfde. Let goed op de zinsnede wel een waarde heeft in de eerste regel. Dit betekent dat de attribuutwaarde waardeOnbekend gebruikt kan worden om uit te drukken dat een datum in de werkelijkheid wel een waarde heeft maar niet bekend is. M.a.w. er is in jouw geval geen uitbreiding J voor het attribute StUF:indOnvolledigeDatum nodig.
Ik weet niet of bovenstaande definitie van waardeOnbekend bewust zo bedoeld was in stuf0204 maar het komt nu goed van pas om geen erratum door te hoeven voeren. Zelf had ik, waarschijnlijk net als jij, een andere definitie in mijn hoofd waarbij waardeOnbekend ook de situatie dekt waarin er überhaupt geen waarde is. Dus ik was enigszins verrast toen ik de tekst erop nalas. Maar de huidige definitie lijkt me ook prima werkbaar. In dit geval is het dus een gelukje bij een ongelukje dat de standaard niet voldeed aan onze aanvankelijke perceptie.
Naar aanleiding van deze inzichten heb ik de stuf0301 documentatie erop nageslagen en daar blijken inconsistente definities voor te komen van waardeOnbekend. Dus daar is het wel nuttig om een erratum door te voeren om tot één interpretatie te komen. In het geval van stuf0301 zou ik willen kiezen voor een definitie van waardeOnbekend waarin ook de situatie wordt afgedekt waarin er geen waarde is.
Daarnaast zou er een RFC voor stuf0301 ingediend kunnen worden waarin de 'J' waarde voor StUF:inOnVolledigeDatum wordt gegeneraliseerd naar andere gegevens dan alleen datumvelden. Dit kan bijvoorbeeld door het waardebereik van het attribute StUF:noValue te verrijken met de waarde bestaandeWaardeOnbekend (er is een waarde maar die is onbekend).
In ieder geval zal ik deze discussie agenderen voor de aankomende StUF Expertgroep vergadering.
Mvg,
Henri Korver
Beste Henri,
Mijns inziens leid je uit "if A then B" onterecht af dat ook geldt "if B then A" en dat is uiteraard niet het geval.
Het is inderdaad zo dat "Indien het element wel een waarde heeft maar de waarde is bij de zender niet bekend en het element is verplicht, dan wordt dit met StUF:noValue=waardeOnbekend (e) en een lege elementinhoud.", maar uit het gebruik van "waardeOnbekend" mag je niet afleiden dat "het element wel een waarde heeft maar de waarde bij de zender niet bekend is en het element verplicht is". Het kan namelijk ook zo zijn dat de zender niet weet óf het element een waarde heeft. Overigens is het element Overlijdensdatum (waarover deze discussie gestart is) geen verplicht element.
Ik blijf dus bij het standpunt dat de waarde "J" voor het attribute indOnvolledigeDatum vereist is om de GBA wetgeving correct te kunnen volgen. Indien je de waarde 00000000 voor datumOverlijden namelijk implementeert met het StUF attribute waardeOnbekend, dan weet de afnemer niet of 1) onbekend is OF de persoon overleden is of 2) bekend is DAT de persoon overleden is, maar onbekend is op welke datum dit is gebeurd. Dit verschil is dusdanig essentieel dat een erratum gerechtvaardigd is. Daarnaast hoort een element met waardeOnbekend in een kennisgeving überhaupt niet opgenomen te worden indien het geen verplicht element is.
Bij de laatste twee alinea's van je post raak ik je helaas kwijt. In StUF 3 is er voor het noValue attribute juist (en geheel terecht) de extra waarde "vastgesteldOnbekend" toegevoegd.
Ik stel daarom dringend voor om op de kortst mogelijke termijn tot besluitvorming te komen over het erratum voorstel op StUF 02.04 en de discussies aangaande het gebruik van de attributes onValue en indOnvolledigeDatum binnen StUF 03.01 strikt gescheiden van de huidige StUF 02.04 discussie te voeren.
Mocht KING het erratum voorstel ondanks de aangevoerde argumentatiue verwerpen, dan moet zij tevens specificeren hoe in het genoemde voorbeeld (datumOverlijden) de GBA wetgeving correct gevolgd kan worden bij het informeren van (binnengemeentelijke) afnemers.
Tevens is het van belang dat meegewogen wordt dat diverse leveranciers (dus niet aleen PinkRoccade) hun standaard programmatuur daarop dan moeten aanpassen en bij al hun klanten moeten implementeren. Met name gezien de komende gefaseerde overgang naar StUF 3 en de mapping van StUF 2 op StUF 3 vice versa, is het de vraag of hiermee het paard niet achter de wagen gespannen wordt.
Groeten, John
Beste John,
Gezien de context van de hele paragraaf heb ik het woordje Indien niet geïnterpreteerd als Als maar als Dan en slechts dan. Dat is mijns inziens de enige natuurlijke interpretatie. Anders heeft de conditie het element wel een waarde heeft geen enkele toegevoegde waarde en had deze zinsnede net zo goed weggelaten kunnen worden uit het het tekstfragment.
Het is een vervelende situatie dat er momenteel blijkbaar ruimte is voor twee verschillende interpretaties. Voor wat betreft stuf0204 neig ik vanuit praktische overwegingen te kiezen voor de interpretatie die door de meeste leveranciers reeds geïmplementeerd is.
Ik stel voor om in de aankomende expertgroepvergadering een telling te doen onder de aanwezige leveranciers welke interpretatie het meest voorkomt in de bestaande software:
waardeOnbekend met als betekenis dat er wel een waarde bestaat maar dat die onbekend is bij de zender.
waardeOnbekend met als betekenis dat het zowel onbekend is of er een waarde bestaat en als die wel zou bestaan wat de waarde is.
Bij deze doe ik een oproep naar alle belanghebbende experts om aanwezig te zijn in de komende vergadering.
Mvg,
Henri Korver
Dag Henri,
De conditie heeft mijn inziens wel degelijk een waarde, maar we lijken hierover een ander beeld te hebben.
Bij de tweede door jou genoemde optie: "met als betekenis dat het zowel onbekend is of er een waarde bestaat en als die wel zou bestaan wat de waarde is" is het laatste deel van de zin irrelevant. Indien onbekend is OF er een waarde bestaat, dan is de feitelijke waarde per definitie onbekend.
Verder beperk je het aantal opties tot 2, maar ik mis:
3. waardeOnbekend zowel (maar afhankelijk van de situatie) met als betekenis dat er wel een waarde bestaat maar dat die onbekend is bij de zender alsook met als betekenis dat het onbekend is of er een waarde bestaat.
4. "waardeOnbekend met als betekenis dat het onbekend is of er een waarde bestaat en daarnaast (bij een datum) een (geldige) waarde met indOnvolledigeDatum = "J" met als betekenis dat er wel een waarde bestaat maar dat die onbekend is bij de zender. Niet alleen PinkRoccade gebruikt inmiddels deze extentie die het erratum voorstaat.
Groeten, John.
PS: het lijkt erop dat je de discussie breder trekt dan datums, maar dat lijkt onterecht, 0 is namelijk voor een numeriek element een geldige waarde terwijl dit (00000000) voor een datum GEEN geldige waarde is.
Hallo Henri,
ik denk dat wij als leveranciers en KING de behoefte van de belangrijkste belanghebbenden moeten polsen, de gemeenten en BPR. Hoe zullen zij tegenover een standaard staan die niet alle GBA waardes kan doorgeven?
Kan KING hierin het voortouw nemen?
Beste belanghebbenden bij dit erratum,
In de discussie over dit erratum spelen de volgende overwegingen in elk geval een rol:
Betrouwbaarheid
Voor een betrouwbare standaard is het noodzakelijk dat er zo min mogelijk wijzigingen worden doorgevoerd die niet downwards compatible zijn en gebruikers van de standaard ertoe nopen om nieuwe versies van de software uit te brengen om een correcte verwerking van de berichten te garanderen. Het is maar de vraag of alle leveranciers van StUF software tijdig in staat zijn een en ander te realiseren. Dit punt klemt in het geval van dit erratum te meer, omdat het erratum al eerder is ingediend en toen is afgewezen.
Functionele noodzaak
In StUF3 is terecht de waarde 'J' ingevoerd voor JaarOnbekend in datums, omdat je ten principale verschil wilt kunnen maken tussen datums waarvan je helemaal niets weet (dus ook niet of de datum al dan niet geenWaarde heeft) en datums waarvan je weet dat ze een waarde, maar de waarde niet nauwkeurig kent.
Kijkend naar de GBA moet je echter wel constateren dat de GBA in elk geval voor de overlijdensdatum - en vermoedelijk ook voor de andere datums die geenWaarde kunnen hebben - òf zeker weet dat de datum geenWaarde heeft (de persoon is niet overleden òf zeker weet dat de datum een meer of minder precieze waarde heeft. In de praktijk is er dus geen probleem om voor datums uit de GBA met als waarde "waardeOnbekend" te interpreteren als datums waarvan het jaar onbekend is (GBA-waarde 00000000 en StUF3-waarde indOnvolledigeDatum = "J"). Je kunt je derhalve afvragen hoe groot de functionele behoefte aan het doorvoeren van dit erratum in StUF2 is.
Het lijkt mij goed als belanghebbenden bij dit erratum nog voor de komende expertgroepvergadering van 21 juli hun visie geven, want er zal een knoop moet worden doorgehakt.
Omdat ikzelf toch vaak in XML structuren denk, een vorm van beroepsdeformatie zullen we maar zeggen, heb ik even de verschillende in XML syntax uitgewerkt.
Het huidige XML-schema voorziet in de volgende mogelijkheid:
<BG:datumOverlijden StUF:noValue="waardeOnbekend">00000000</BG:datumOverlijden>
Waarmee je naar de mening van John onvoldoende het verschil kunt aangeven tussen het feit dat je niet weet of er een waarde is en het feit dat je weet dat er een waarde is maar deze niet kent.
Daarom stelt John ook het volgende voor:
<BG:datumOverlijden StUF:indOnvolledigeDatum="J">00000000</BG:datumOverlijden>
waarbij de waarde 'J' een aanpassing in het schema betekend. Juist deze aanpassing in het schema stuit bij een aantal leveranciers op problemen in de implementatie. Reden waarom zij geen voorstander zijn van deze wijziging.
Tijdens de afgelopen Expertgroep riep Henri iedereen op om te kijken of er andere oplossingen zijn. Deze reactie is even een poging om door hardop te denken iedereen even met andere ogen naar het probleem te laten kijken. Of dat geslaagd is mogen jullie beoordelen.
Ik heb in ieder geval eens zitten kijken wat het huidige schema ons aan uitwegen biedt en daarbij liep ik tegen het attribuut 'StUF:exact' aan. Ik besef dat dit attribuut op dit moment alleen een functie heeft binnen vraagBerichten maar misschien biedt het ons wel een uitweg in de impasse.
De vraag is daarom wat de volgende structuur voor ons kan betekenen:
<BG:datumOverlijden StUF:noValue="waardeOnbekend" StUF:exact="false">00000000</BG:datumOverlijden>
Voor mijn gevoel geeft het feit dat je hier het attribuut 'StUF:exact' gebruikt aan dat je weet dat er wel een waarde is maar dat je de waarde niet exact weet. In combinatie met 'StUF:noValue' geef je dan aan dat je weet dat er een waarde is maar dat je de waarde niet kent.
Het lijkt me dat hiermee het voorstel van John tijdens de laatste Expertgroep 'accepteren (de waarde wel ontvangen maar er niets mee doen) of implementeren (de waarde ontvangen en er ook iets mee doen)' wel realiseerbaar is.
Hoi Robert,
In StUF mag je geen ongeldige datums als "00000000" gebruiken, in ieder geval dat dachten we. Immers als dat wel het geval was dan was het probleem van John een non-issue en had hij nooit een erratum ingediend.
Echter bij het herlezen van stuf0204 werd ik wederom verrast (zie pagina 28):
Dit betekent dat alleen datums in een tijdvak een geldige waarde moeten hebben als inhoud van een element en dat deze eis niet geldt voor andere datumvelden zoals "overlijdensdatum".
Bovendien wordt in het RSGB bij "overlijdensdatum" niet vermeld dat de datumdefinitie van het GBA overruled wordt door de datumdefinitie van StUF. Dus ook het RSGB verbiedt ons niet de waarde "00000000" te gebruiken.
Mvg,
Henri Korver
In de schema's is ook de overlijdensdatum en nog een paar andere data voorzien van het attribute indOnvolledigeDatum. Ofschoon strikt logisch niet correct is dit altijd geinterpreteerd als voor te schrijven wat gespecificeerd is voor de begindatumGeldigheid (een soort generalisatie naar alle datums waar dit attribute voorkomt.
Het RSGB heeft als semantisch model de taak om te specificeren welke waarden voor een datum mogelijk zijn. Het is logisch dat voor GBA-datums hierbij wordt aangesloten bij de GBA. StUF biedt een encoding hiervoor en er is geen probleem zolang de encoding van StUF de semantiek in de GBA aankan. Over de vraag in hoeverre dit in 0204 het geval is ging een belangrijk deel van deze discussie.
Henri,
In mijn betoog heb ik inderdaad als voorbeeld waarde '00000000' gebruikt.
Voor de kern van mijn betoog maakt het echter niet zoveel uit of je er een geldige waarde inzet of deze waarde.
De kern van mijn betoog gaat over het gebruik van het attribuut 'StUF:exact' in een kennisgevingsbericht als alternatief voor het definieren van een extra waarde voor 'StUF:indOnvolledigeDatum'.
Robert,
Inderdaad. Mocht het zo zijn dat er functionele behoefte is aan het erratum van John dan zou je ook "StUF:exact" kunnen gebruiken i.p.v. een extra waarde "J" voor het attribuut inOnvolledigeDatum. Immers dit attribuut zit al (per ongeluk?) in het schema voor kennisgevingen. Het voordeel van jouw benadering is dat het schema niet aangepast hoeft te worden qua syntax. Echter "StUF:exact" is alleen bedoeld voor vraagberichten. Dus qua semantiek moet dan wel de StUF-documentatie worden aangepast en daar wordt de tekst niet eleganter van.
Mvg,
Henri
Henri,
Daar was ik me van bewust. Toch vond ik dat deze optie als alternatief moest worden meegenomen in de discussie a.s. woensdag.