Up until now the need for publishers to accurately report the version of the standard that they are using has not been of great importance as all current versions are backwardly compatible. With an integer upgrade this is not the case and it becomes critical for consumers of IATI data to know which version they are processing. The version is reported in two places: at file level (iati-activities) and record level (iati-activity). The reason for this is to facilitate the processing of a single activity independent of the original file in which it was published (for example, from the data store) AND provide a speedy way for whole files to be processed. It is therefore proposed that:
- iati-activities/@version is MANDATORY
- iati-activity/@version is DELETED
- iati-activity/@version is MANDATORY
- All @version attributes in a given file MUST have the same value
- The value of @version MUST be on the (new to 2.01) version codelist
Should the same rules that apply to iati-activities/@version and iati-activity/@version also apply to iati-organisations/@version and iati-organisation/@version? I think having this be consistent across the two schemas would be useful.
On 12 August 2014 the IATI Technical Team reviewed this issue and took note of Herman van Loon's argument here - http://support.iatistandard.org/entries/50761977--version-should-be-consistent.
The team agreed that duplication was not the best solution and decided to drop the proposal that individual activities MUST contain a version. It agreed that a separate solution should be found to record versions on individual activity blobs, as delivered by the Data Store and other services.
Discussion on versions is now split across a number of posts, so for clarity:
Omitted to record that the logic of enforcing only iati-activities/@version means that iati-activity/@version should be DELETED