Momenteel is het pattern bij tijdstipBericht nog afgeleid van Tijdstip namelijk: '[0-9]{8,17}'.
Omdat StUF voorschijft dat elk bericht een uniek (groter) tijdstipBericht heeft lijkt het mij beter om het formaat voor dit veld aan te passen naar '[0-9]{17}' of eventueel, indien niet iedereen milliseconden aan kan, naar '[0-9]{14,17}' zodat het niet meer mogelijk is om berichten op te sturen met alleen een datum. Alleen een datum en bovenstaande StUF regel resulteert erin dat wij maar 1 bericht per dag accepteren en dat is grappig maar niet de bedoeling.
di, 5-06-2012 - 11.06u
#1
Voorgeschreven formaat tijdstipBericht in de stuurgegevens
Ik begrijp je wens volledig maar dit lijkt mij meer een RFC dan een erratum. Immers het is (blijkbaar) een bewuste keuze in StUF om de zender de mogelijkheid te bieden om tijdstipBericht alleen met een datum te vullen als het zendende systeem maar één bericht per dag verstuurt. Indien de zender meer berichten per dag wil versturen moet ook het tijdstip (eventueel inclusief milliseconden) worden opgenomen. Dus de zender kan meerdere berichten bij jullie systeem geaccepteerd krijgen door in het veld tijdstipBericht zowel een datum als een tijdstip op te nemen. M.a.w. in eerste instantie ligt het probleem niet bij jullie of bij de stuf-standaard maar bij de zender.
Ook gezien de mapping van bg0204 op bg0310 is het aanscherpen van de eisen mijn inziens niet mogelijk.
Voor de toekomst is het wellicht een idee om in een nieuwe versie van StUF voor alle tijd/datum-velden heel specifiek te definieren waaraan de waarde moet voldoen?
Je zou daarvoor een pattern als: '[0-9]{4}(0[1-9]{1}|1[0-2]{1})(0[1-9]{1}|[1-2]{1}[0-9]{1}|3[0-1]{1})([0-5]{1}[0-9]{1})([0-5]{1}[0-9]{1})[0-9]{3}' kunnen gebruiken.
Het gebruik van het built-in type 'xs:date' behoort echter ook tot de opties'.
Nu kan de inhoud van dit attribuut nl. nog op heel veel verschillende manieren ingevuld worden. Als '20120606163934123' maar ook als '06062012163934123' of zelfs nog anders. Op basis van het bovenstaande pattern dwing je wellicht niet alles af (bijvoorbeeld de extra dag in februari in schrikkeljaren) maar je scherpt het datatype wel aan.
Misschien kan eenzelfde aanscherping voor meerdere elementen bereikt worden.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0120.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 18 februari 2015 zijn verschillende opties besproken om dit probleem op te lossen zonder het formaat aan te passen zoals:
Er is gesteld dat er nu geen systemen zijn die meer berichten per milliseconden uitzenden. Als zo’n systeem er wel komt dan moet dat systeem maar wachten met het verzenden van dat bericht.
Tijdens de StUF Expertgroep van 20-5-2015 is vastgesteld dat dit RFC in feite al was afgevoerd. In deze vergadering is dat bevestigd.