Open jasperroes opened 5 years ago
Deze zit niet in de core, is een extensie die belangrijk is en die we apart gaan bespreken en vervolgens specificeren.
Vervallen is veelal een procesnaam, of een mutatietype, en niet een woord wat voor tijdslijnen wordt gebruikt.
De parameters geldigOp, beschikbaarOp en werkendOp corresponderen met de bijbehorende gedefinieerde tijdslijnen. Vervallen is daar geen term in.
Deze gedefinieerde tijdslijnen zijn er als harmonisatie. Er zijn vele woorden die gebruikt worden om het begin van een tijdvak en het eind van een tijdvak van een tijdslijn te benoemen. Zo heet het soms: technisch tijdstip vervallen, of logisch tijdstip vervallen, maar bij een andere registratie heet het bv. einddatum geldigheid, geldig tot, of eindGeldigheid. Vervallen komt rondom de tijdslijnen volgens mij niet voor (maar wie weet, het is immers aan elke registratie zelf om de eigen termen te behouden).
Tijdslijnen zijn vaak geen onderdeel van de vraag, maar van het antwoord. Daarom kan je dat vrijlaten. De namen van de parameters staan wel vast.
Nuttig om te weten: de meeste registraties kennen alleen geldigOp en beschikbaarOp, en niet werkendOp.
werkendOp is wat bijzonder, in de zin dat het alleen aan de orde is in een juridische context waarin wetgeving werking krijgt, op een andere datum dan dat de gegevens geldig worden.
Bv. regelgeving wordt op 1 februari gepubliceerd, en deze regels treden juridisch in werking op 1 maart. Mensen hebben bv. dan een maand om bezwaar te maken. Zodra deze regels in werking treden, zijn ze geldig per 1 januari (ze gaan met terugwerkende kracht in).
Als deze use case voor iemand niet aan de orde is, dan neem je de parameter werkendOp niet op in je API.
De andere twee, geldigOp en beschikbaarOp, horen er altijd te zijn.
Opmerkingen via review-formulier:
Ik mis "vervallen" ? Of is dit dat een versie van een object een nieuw "in werking getreden op" krijgt ?
Objecten kunnen meedere versies per dag hebben. "geldigOp" en "inWerkingOp" zijn datums, het moeten timestamps zijn. Deze alinea moet specificeren dat alle tijden altijd nederlandse wintertijd zijn. De timestamps moeten een tijdzone bevatten. Onduidelijkheid over zomer / wintertijd en tijdzone levert storingen, meningsverschillen en integratie problemen op. Het is essentieel dat API's hiet expliciet over zijn.