Als in basiregistratie een onvolledige datum staat, bijvoorbeeld geboortedatum 00-00-1965, mag dan in het StUF-bericht de waarde van geboortedatum 19650000, of moet het een valide datum zijn, bijvoorbeeld 19650101 of 19650701 (uiteraard altijd met indOnvolledigeDatum="M")?
Volgens mij moet een datumelement altijd een geldige datumwaarde bevatten, maar en andere leverancier wees mij erop dat het volgende in de schemas staat:
In het schema bg0310_ent_basis.xsd staat:
<element name="geboortedatum" type="StUF:DatumMetIndicator" nillable="true" minOccurs="0"/>
In het schema stuf0301.xsd is DatumMetIndicator gedefinieerd als:
<complexType name="DatumMetIndicator">
<simpleContent>
<extension base="StUF:Datum">
<attributeGroup ref="StUF:element"/>
<attribute ref="StUF:indOnvolledigeDatum"/>
</extension>
</simpleContent>
</complexType>
In hetzelfde schema is Date gedefinieerd als:
<simpleType name="Datum">
<annotation>
<documentation>Er is niet aangesloten bij date, omdat hier allerlei opmaak in zit</documentation>
</annotation>
<restriction base="decimal">
<totalDigits value="8"/>
<fractionDigits value="0"/>
</restriction>
</simpleType>
Als schema boven documentatie gaat zou de andere leverancier gelijk hebben, maar waarom leveren datadistributiesystemen dan altijd valide datums?
Wie weet het juiste antwoord?
In de stuf0301.pdf documentatie wordt geëist dat er altijd een geldige datum moet worden ingevuld. Dit is een aanvullende verscherping op het stuf0301.xsd schema. Je kunt namelijk niet alles afdwingen op schemaniveau. In dit geval staat de stuf0301-documentatie boven het schema.
Bij het document "keuzenVerStUFfing RSGB.pdf" is het anders geregeld, daar staan de bg0310-schema's boven de documentatie. Dat wordt ook expliciet gemeld in de inleiding van het laatstgenoemde document.
In de StUF0301.pdf wordt alleen een geldige datum geëist in de context van 'Metagegevens met betrekking tot historische waarden' (pagina 31). Dus niet voor datums in algemene zin.
Als ik Henri goed begrijp geldt voor StUF-bg expliciet dat schema boven documentatie gaat en dat geboortdatum een ongeldige datumwaarden (bijvooreeld 19650000) mag bevatten.
Dat zou ook betekenen dat de uitspraak van Maarten van den Broek in discussie-item 'Formaat onvolledigedatum' (https://vng-realisatie.github.io/StUF-Standaarden/comment/2733#comment-2733) niet klopt: "De datum zelf moet altijd geldig zijn."
Nee, zo bedoel ik het niet. Ik ga ervan uit dat in algemene zin er altijd een geldige datum moet zijn, dus ook voor datums die geen betrekking hebben tot historische waarden zoals een geboortedatum. Blijkbaar staat dit niet helemaal duidelijk in de standaard, maar het lijkt mij niet in de geest van StUF als er twee conflicterende datumformaten binnen dezelfde standaard worden gehanteerd. Mijn voorstel is om dit zo snel mogelijk te verduidelijken in de StUF 3.01 standaard door middel van een erratum. Ergo, naar mijn mening klopt de uitspraak van Maarten wel en moeten datums zoals 19650000 worden afgekeurd.
Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR0513.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Waarschijnlijk heeft het te maken met de richtlijnen van XML. Daarin wordt gesteld dat een datum element altijd een geldige datum moet bevatten. Waarschijnlijk is met dat uitgangspunt is in StUF 0204 de indicator onvolledig meegenomen. Als je dan compatibel met StUF 0310 wilt zijn, neem je dat weer mee!
In de bijlage heb ik een voorstel uitgewerkt waarbij aan hoofdstuk 1 van de StUF 3.01 standaard een paragraaf is toegevoegd met algemeen geldende afspraken. Daarin heb ik aangegeven dat een datum element indien niet leeg altijd voorzien moet zijn van een valide datum.
Bijlage
Het is een late reactie, maar is dit niet een gevaar voor de data integriteit? Ga er even van uit dat een systeem wat een StUF bericht moet maken alleen een jaar als informatie heeft, dan lijkt het mij niet dat er dan maar een maand en dag moeten worden bij verzonnen om de het veld valide te maken. Volgens mij voorziet het schema daar prima in door de waarde op 0000 te zetten en de indicator op "J" te zetten. In het schema is het ook geen XML date type veld.
Marcel,
StUF zegt niets over hoe gegevens moeten worden opgeslagen, alleen iets over de wijze waarop gegevens moeten worden getransporteerd. De data integriteit hoeft dus niet in gevaar te komen. Je moet er alleen voor zorgen dat je in het bericht een valide datum plaatst zodra deze niet volledig kan worden aangeleverd.
Robert,
Het klopt dat StUF niets over de opslag hoeft te weten, maar het ontvangende systeem moet wel weten dat de maand en dag informatie in die datum dus niet valide zijn. De geboden oplossing is nu voor verkeerde interpretatie vatbaar. even dit voorbeeld, in het systeem is de registratie op basis van het jaar gedaan, dit gegeven wordt verzonden met de datum waar maand en dag op 01 01 worden gezet, en het ontvangende systeem neemt nu 1 januari als datum. Dit is dan niet meer de werkelijke datum, want daar was alleen het jaar geregistreerd. Eigenlijk vul je dus 1 januari is als fictieve data terwijl er niets fictief zou mogen zijn, ook niet in het transport!.
De ontvanger kan uit de waarde van het attribute indOnvolledigeDatum afleiden welk deel van de datum geldig is.