/Planned disbursements do not have single dates only periods.
We should change the definition to say, if it is a single date, then use the period start date. If it actually is a period then obviously you can put a start and an end date in e.g. 1st July - 31st July.
We think that making the start date mandatory (if the element is used) will improve data quality and enable publishers and data users to better check that their data is complete.
Would this change be backward compatible? If not, shouldn't it be part of an integer upgrade?
Decimal Upgrades and Backward Compatibility
IATI's decimal upgrades must (as agreed by the Steering Committee) be backwardly compatible. This means that data produced for a particular version of the standard should have the same meaning, functionality and validity in all subsequent decimal versions of the same integer.
We had proposed to make a number of changes in the current decimal upgrade that would have make a number of optional fields mandatory. (These are the iso-date for activity dates, and the period start and end dates for budgets.) It has been pointed out to us that these changes break the backward compatibility test, as activities without these fields created under the current version of the standard would fail validation in the new version.
These items will therefore be placed in the proposal queue for the first integer upgrade.
Moved to the integer upgrade forum
Agree. Assuming the period-start and period-end provide the range within which a disbursement is likely to occur, would it be preferable to require both, and if a specific date is to be provided, then the start date and the end date could be the same date?
If this approach sounds sensible, would suggest making both period-start and period-end mandatory.
4 Comments