There are currently no policies or guidelines relating to the continuing validity of old versions of the standard. There is a clear need for the earliest versions to now be deprecated. We welcome proposals as to how this should be approached and implemented.
This paper is part of the Agenda for the IATI TAG 2016 Technical Consultation Workshop
#IATI #TAG2016
I tend to agree with Hayden Field and Tim Davies . There is another consideration regarding the use of old standard versions: wouldn’t it be be better to slow down on introducing new integer upgrades of the standard? Given the fact that there are a lot of quality issues with the existing publications , shouldn’t publishers concentrate on getting their data right, instead of concentrating on conversion of their data to a new version of the standard?
That would mean slowing down on standard development, which would also mean that older versions of the standard can be longer supported. Lets focus for a while on the use of what we have instead of converting from one version to another.
Herman van Loon I agree
I agree that the codes should not be removed, though in what way would the deprecated code be marked as deprecated?
As such…
(though it may be worth splitting this into a separate discussion)
While it is reasonable to formally encourage or prevent publishers to stop publishing new data on old versions of the standard, care needs to be taken with regards to data which has already been published in a given version of the standard.
For example, say a set of activities has been published using version 2.01 of the standard. Upon the release of version 2.04 or 3.01, support for this version of the standard would be deprecated. Functionality in IATI tools and helpdesk support for utilising this data would then be removed or reduced. This is of even more immediate concern to the ~28% of activities currently published in versions of the standard that would be deprecated upon approval of this policy.
With this in mind, consideration needs to be had with regards to how:
With regards to removing support for deprecated versions in tools that utilise IATI data…
With regards to adjusting publisher statistics…
I would support option 1 for a two year support window after a new integer version is released.
I would not support removing past versions from the version codelist, because, as Hayden notes, this would cause historic and archived data to cease to validate. Instead, I would suggest:
I would also encourage investment in conversion tools when new versions are released - as in a number of cases, where changes are structural, but not semantic, it is possible to programmatically map from old versions to newer versions.
I would propose that we update the deprecation process, from saying:
dalepotter:To saying