|Slide No.||Paper||Link||Issue||Type||Version||Proposal||Outcome||Next Step||Discussion (Public)|
|3||Rules and Guidelines||http://bit.ly/2mi8W6A||Make Rules and Guidelines part of the IATI Standard||Rule||3.01||Rules and guidelines should be included as an integral part of the standard along with the schema and codelists||Accept||No discussion.|
|4||Rules and Guidelines||http://bit.ly/2mi8W6A||Make Rules and Guidelines part of the IATI Standard||Definition||3.01||A rule is a mandatory condition that cannot be defined in and enforced through the schema but is part of the standard and is validated through a machine-run procedure.||Accept||No discussion.|
|5||Rules and Guidelines||http://bit.ly/2mi8W6A||Make Rules and Guidelines part of the IATI Standard||Definition||3.01||A guideline is a description of recommended best practice that is implemented where applicable.||Accept||No discussion.|
|6||Rules and Guidelines||http://bit.ly/2mi8W6A||Make Rules and Guidelines part of the IATI Standard||Action||3.01||A new text based Rules section should be added to iatistandard.org which will be recognised in Version 3.03 as a definitive part of the IATI Standard||Accept||It was clarified that rules are not currently enforceable.|
|7||Rules and Guidelines||http://bit.ly/2mi8W6A||Implementation Schedules||Guideline||2.03||The need to produce and maintain an implementation schedule should no longer be a requirement of IATI publishing.||Consult further||The wording of the proposal needs to change and further discussion on how the information previosly captured in the implementation schedule can added to the IATI Registry. IATI tech team to take forward for further consultation and change wording of this proposal.||There was an agreement in the room that the implementation schedule is not widely used. However, if it is removed a suitable alternative should be put in place given that a lot of organisations still need to provide this information.|
Some proposals were made making improvements to the IATI Registry that can capture this information.
There were also strong views that the wording of the proposal should be changed as a guideline cannot provide a negative message "should no longer be a requirement", but rather focus on best practice for implementing that change.
|7.1||Rules and Guidelines||http://bit.ly/2mi8W6A||Implementation Schedules||Guideline||2.03||Publishers should improve and regularly maintain the content of all fields in their IATI Registry publishing accounts.||Consult further||It was clarified that the proposal is about the master publisher account on the IATI Registry.|
Some points were raised about difficulty in monitoring improvement against this proposal but it was clairifed that the guideline is about encouraging best practice.
|8||Rules and Guidelines||http://bit.ly/2mi8W6A||IATI Registry Publisher Status||Action||?||Introduce a new IATI Registry status of ‘Dormant’ for all accounts where no new information has been added within the most recent 12 months.||Consult further||New wording to be suggested for the "Publisher Status" that can replace dormant. IATI tech team to take forward for further consultation.||Various discussions took place around the proposed duration of 12 months. The majority of participants agreed that 12 months is not sufficient and proposals were made about extending to 15 or 18 months and also setting different rules for old and new organisations.|
It was agreed that a better wording for the status should be used and suggestions were welcomed.
Questions were raised about the implications for publishers that have this status and it was clarified that they will only be flagged on the IATI Registry.
|9||Rules and Guidelines||http://bit.ly/2mi8W6A||IATI Registry Publisher Status||Action||?||Make the status of ‘Active’ or ‘Dormant’ visible to all||Consult further||Some questions were raised around the implications of making the status visible to all.|
An agreement is required on slide 8 before any further discussion can take place regarding this proposal.
|11||Rules and Guidelines||http://bit.ly/2mi8W6A||IATI Registry Publisher Status||Action||?||Amend the highlighted published ‘count’ on the IATI Registry to refer to ‘Active’ publishers.||Consult further||No discussion.|
|13||Controlling Data Quality||http://bit.ly/2mhJeyM||Definitions||Definition||-||An illegitimate item or condition is an invalid item or condition that stops users from processing the data. The definition of what constitutes an illegitimate item is determined from a control list of invalid conditions. Eg: Badly formed and invalid xml; invalid characters; invalid reporting-org/@ref||Consult further||Generally there was confusion in the room about specified definitions, as well as the differences between them.|
Discussion cut short and later points in section skipped due to lack of clarity and discussion moving onto implementation details.
|14||Controlling Data Quality||http://bit.ly/2mhJeyM||Definitions||Definition||-||An invalid item or condition is one that fails validation against the schema, codelists or rules.||Consult further||See slide 13|
|15||Controlling Data Quality||http://bit.ly/2mhJeyM||Definitions||Definition||-||An imperfect item or condition is valid but doesn’t meet a guideline||None||See slide 13|
|16||Controlling Data Quality||http://bit.ly/2mhJeyM||Definitions||Definition||-||An Illegitimate/invalid/imperfect activity is one containing one or more illegitimate/invalid/imperfect items.||None||See slide 13|
|17||Controlling Data Quality||http://bit.ly/2mhJeyM||Definitions||Definition||-||A file (or API endpoint) is illegitimate/invalid if it contains one or more illegitimate/invalid items or activities||None||See slide 13|
|18||Controlling Data Quality||http://bit.ly/2mhJeyM||Definitions||Definition||-||A publisher is illegitimate if either all its files are illegitimate or its registry record is illegitimate||None||See slide 13|
|19||Controlling Data Quality||http://bit.ly/2mhJeyM||Validation Process||Action||-||The registry must run full validation on all new and changed files every night and stores the results in the dataset metadata||Accept||IATI tech team to take this action forward.||The steps in the validation process were clarified and consensus was reached on this proposal.|
No additional comments were raised.
|20||Controlling Data Quality||http://bit.ly/2mhJeyM||Registry Behaviour||Action||-||Illegitimate publisher|
1) Publisher is flagged in a similar way to the new proposed ‘Dormant’ status
2) Publisher record is not visible on the Registry. Status similar to ‘pending
|Consult further||There was not concensus about which option to choose.|
|21||Controlling Data Quality||http://bit.ly/2mhJeyM||Registry Behaviour||Action||-||Illegitimate file - Option One|
A dataset record is maintained without a publicly accessible link to the file. The dataset remains visible but flagged in the Publisher’s lists of datasets. The validation report is accessible in the dataset’s metadata.
|Accept||Several points were raised about invalid rather than illegitimate data.|
Suggestion that publishers should be emailed when there is a problem with their data.
Concensus around labelling. Noted that the infrastructure is not currently in place for full implementation involving notifications.
|22||Controlling Data Quality||http://bit.ly/2mhJeyM||Registry Behaviour||Action||-||Illegitimate file - Option Two|
No dataset record of the file is held. The publisher record maintains a list of illegitimate files. When adding a new file the API returns an error message informing the update process that registration failed.
|Reject||See slide 21|
|23||Controlling Data Quality||http://bit.ly/2mhJeyM||Registry Behaviour||Action||-||Invalid file - Option One|
The file is accessible. The file is flagged as invalid in the Publisher’s lists of datasets. The validation report is accessible in the dataset’s metadata.
|Accept||Concensus around Option 1. Noted that there are problems around master data management.|
|24||Controlling Data Quality||http://bit.ly/2mhJeyM||Registry Behaviour||Action||-||Invalid file – Option Two|
No dataset record of the file is held. The publisher record maintains a list of invalid files. When adding a new file the API returns an error message informing the update process that registration failed.
|Reject||See slide 23.|
|25||Controlling Data Quality||http://bit.ly/2mhJeyM||Registry Behaviour||Action||-||Imperfect file – Three options|
The validation report is accessible in the dataset’s metadata.
The file is flagged as imperfect in the Publisher’s list of datasets. The validation report is accessible in the dataset’s metadata
|None||This was skipped.|
|26||Controlling Data Quality||http://bit.ly/2mhJeyM||Registry Behaviour||Action||-||Illegitimate Publisher – Two Options|
Publisher is not included, other than on a separate, visible dashboard list
Publisher is included with zero scores
|Consult further||This was skipped.|
|27||Controlling Data Quality||http://bit.ly/2mhJeyM||Publisher Statistics Behaviour||Action||-||Illegitimate activity|
Under both registry options for illegitimate files the activity would not exist and therefore would not be part of the assessment.
|None||This was skipped.|
|28||Controlling Data Quality||http://bit.ly/2mhJeyM||Publisher Statistics Behaviour||Action||-||Invalid activity – Two Options|
1) Activity is counted in the total number of activity but scores zero on all assessments.
2) No action or lesser action. Option one would diminish the granular analysis, for example, of core fields as one missing core field would be interpreted as all core fields being missing.
|Consult further||This was skipped.|
|29||Controlling Data Quality||http://bit.ly/2mhJeyM||Compliance Scoring||Action||-||A kitemark for IATI compliance?|
A three-grade system?
*** - 80% plus score in publisher statistics
** - No invalid or imperfect files
* - No invalid files
|Consult further||Noted that data use is more important than compliance.|
Would act as an incentive to increase data quality, rather than the be-all-end-all.
Could act as a badge on top of the Publisher Statistics.
Agreed in principle, with details to be confirmed.
|30||Controlling Data Quality||http://bit.ly/2mhJeyM||Support||Action||-||Active feedback and support to publishers – Two Options|
No active feedback and support
Provide a two level data quality service:* Basic service: automatically inform publishers by e-mail on data quality problems* Premium service: Active support by the IATI technical team on data quality problems for those publishers who paid their membership fees.
|Consult further||MAINTAIN on discuss and then take proposal to members assembly.||General support for some sort of tiered support system, with integration into a free-market ecosystem, with basic levels of support involving automated tooling that provides feedback and suggestions for improvement.|
Decided that further discussion should be had on Discuss, before passing over to the Members Assembly to make a decision.
|32||Codelist Management||http://bit.ly/2m1jy70||Embedded and Non-embedded lists||Definition||-||Embedded codelists contain codes that involve functional logic that impacts on the way in which the standard is interpreted and processed. They are embedded in the standards’ schema||Accept||Investigate distinction between Embedded, Non-Embeddd and Replicated Codelists.|
Look into how to track versions of Codelists.
|Agreement on the definitions of the types of Codelist.|
May be worth looking into the naming of 'Embedded' and 'Non-Embedded'. Also consider a difference between IATI Codelists and those replicated from elsewhere.
Need to consider how to deal with varying versions of Codelists so that it can be seen when codes are added or removed.
|33||Codelist Management||http://bit.ly/2m1jy70||Embedded and Non-embedded lists||Definition||-||Non-embedded codelists contain codes that qualify data, not processes. They may be generated and maintained by third-parties or IATI.||Accept||See slide 32.|
|34||Codelist Management||http://bit.ly/2m1jy70||Embedded and Non-embedded lists||Rule||Embedded codelists can only be changed through the standard upgrade process and are versioned accordingly||Accept||See slide 32.|
|35||Codelist Management||http://bit.ly/2m1jy70||Embedded and Non-embedded lists||Guideline||-||Non-embedded codelists may be changed at any time subject to appropriate notification and/or consultation and are not versioned||Accept||See slide 32.|
|36||Codelist Management||http://bit.ly/2m1jy70||Embedded and Non-embedded lists||Action||2.03||Redefine 30 codelists (as per list in paper) from embedded to non-embedded during the 2.03 upgrade process||Consult further||Accept in principle but check details of which should be moved||Agreement on principle.|
Need to look through the proposd list to ensure that all should definitely be moved.
|37||Codelist Management||http://bit.ly/2m1jy70||Embedded and Non-embedded lists||Action||3.01||Move embedded codelists into the schema ||Accept||No discussion.|
|38||Codelist Management||http://bit.ly/2m1jy70||Replication of external vocabularies||Action||-||Create a new metadata category for Vocabulary Codes , one being ‘replicated’ and the other ‘non-replicated||Accept||IATI should work with WP-STAT and the DAC to provide Codelists in a machine-readable format.|
Historical Codelist information available through git could be exposed in a programmatic manner.
Could be useful to maintain a list of IATI org IDs.
|39||Codelist Management||http://bit.ly/2m1jy70||Replication of external vocabularies||Action||-||Create a new metadata category for Codelists - Update Frequency||Accept||See slide 38.|
|40||Codelist Management||http://bit.ly/2m1jy70||Replication of external vocabularies||Guideline||-||The decision on which codelists should be replicated needs to be a pragmatic one which reconciles the widespread use of a list, the length of the list and the overhead required to keep the list up to date.||Accept||See slide 38.|
|41||Codelist Management||http://bit.ly/2m1jy70||Replication of external vocabularies||Action||-||Manually replicated codelists should be updated by the Technical Team in line with the agreed Update Frequency||Accept||See slide 38.|
|42||Codelist Management||http://bit.ly/2m1jy70||Deprecation of retired codes||Guideline||-||Retired codes should be deprecated but never deleted from codelists maintained or replicated by IATI||Accept||Ideal situation would be a full historical list of historical versions of all Codelists.|
Agree in principle, but need to determine details.
|43||Codelist Management||http://bit.ly/2m1jy70||Shared governance of Organisation Identifier Lists codelist||Action||3.01||The OrganisationRegistrationAgency codelist should be renamed to 'OrganisationIdentifierList'||Reject||Unclear why the name of the list needs changing. Maybe the list may contain something other than Registration Agencies in the future.|
|44||Codelist Management||http://bit.ly/2m1jy70||Shared governance of Organisation Identifier Lists codelist||Action||2.03||Maintenance of the OrganisationIdentifierList list should be carried out by the 'org-id project’||Accept||Tech Team to look at change management & governance processes.||Various forms of clarification that because the list would be managed as other replicated Codelists are, this could be implemented as a decimal. With this clarified, agreed.|
|45||Codelist Management||http://bit.ly/2m1jy70||Codelist mappings||Codelist||2.03||Codelist mappings should refer to a Schema, not a Dataset||Accept||This would make it easier for developers to build tools that use Codelists.|
Deemed to be about back-end-processing, so discussion cut short.
Agreement that this should be a thing among those who understood what was being proposed.
|47||Upgrade Rules||http://bit.ly/2m1braz||New Timetables||Rule||-||Agree that the revised rules, guidelines and timetables for both decimal and upgrades can be submitted to the Members Assembly for adoption||Consult further||Conduct spearate consultation on Discuss ahead of Members Assembly, with a key discussion point of: Are the timescales long enough?||Various comments that the timelines in the initial version were too short. Noted that the Tech Team has revised the timescales.|
Key point for further consultation: Are the time periods long enough?
|49||Deprecation of Old Versions||http://bit.ly/2m15OsY||Deprecation Rule||-||Two years after the introduction of a new integer version of the standard all versions of previous integers will be deprecated||Consult further||Agreed in principle but timing needs further discussion. Tech Team to look at how Google Transit Feed handles deprecation.||No objection to the concept of version deprecation, though need to clarify the process and timescale - somewhere in the region of 2-5 years is the key timeframe to base further discussion around.|
Should look into how other standards such as Google Transit Feed handle deprecation.
Noted that automated conversion tools could provide best-effort conversion, though the addition of mandatory fields can be problematic.
|50||Deprecation of Old Versions||http://bit.ly/2m15OsY||Handling of deprecated versions||-||Publishers are strongly recommended NOT to use deprecated versions||Consult further||See slide 49.|
|51||Deprecation of Old Versions||http://bit.ly/2m15OsY||Handling of deprecated versions||-||Activities published in a deprecated version will be penalised according to new data quality guidelines||Consult further||See slide 49.|
|52||Deprecation of Old Versions||http://bit.ly/2m15OsY||Handling of deprecated versions||-||The use of deprecated versions within official tools maintained by the IATI Technical Team will be phased out.||Consult further||See slide 49.|
|53||Deprecation of Old Versions||http://bit.ly/2m15OsY||Handling of deprecated versions||-||The IATI Technical Team will prioritise help-desk support for data in current (non-deprecated) versions||Consult further||See slide 49.|
|55||Hierarchies||http://bit.ly/2m1widJ||Related Activities||-||Hierarchy activity linkage should be managed by use of the <related-activity> element and @type of 1 (parent) and 2 (child). ||Accept||Questions were raised about how widely hieararchies are used.|
|56||Hierarchies||http://bit.ly/2m1widJ||Related Activities||-||The ‘sibling’ @type value should be removed||Consult further||Further discussion was requested|
|57||Hierarchies||http://bit.ly/2m1widJ||Transactions||-||All types of transactions may be reported at any level provided that:|
There is no double counting within a hierarchical group of activities.
Transactions should not report disbursements within a hierarchical group. The flow of money down a hierarchical chain is implicitly assumed
Incoming Funds can be present at any level but must be reported only once and at only one level
|Accept||There was a wider discussion in the room around different use of hierarchy, described as hierarchy of relationship as well as hierarchy of funding flows. However, there was confusion around the definition being used for double counting and how that relates to reporting hierarchies. It was clarified that as long as the flow of resources is reported correctly, there will be no double counting. However, a number of examples were given from organisations highlighting that that there is inconsistency in how they use hierarchies and their understanding of double counting.|
|58||Hierarchies||http://bit.ly/2m1widJ||Budgets||-||Budgets & results can be defined at any number of levels||Accept||No discussion.|
|59||Hierarchies||http://bit.ly/2m1widJ||Inheritance||-||All mandatory and any other fields should be present at all levels. This therefore means that it may be necessary to repeat the same information at all levels.||Accept||The case of documents was mentioned and it was explained that they are not a mandatory field. It was suggested that the use of "any other fields" in this proposal should be clarified.|
|60||Hierarchies||http://bit.ly/2m1widJ||Scope||-||The scope of use must not extend beyond the reporting of the activities of a single organisation. ||Accept||A point was made by an organisation that there might be cases where an organisation might like to link to an activity of an another organsiation even if there is no transacation. A proposal was made about potentially adding a new related activity type.|
|60.1||Hierarchies||http://bit.ly/2m1widJ||Publisher Statistics||-||Hierarchical groups should be treated as a single activity for the purpose of publisher statistics assessments||None||There was no disagreement to this suggestion, but it requires further consultation as it was introduced during the discussion.|
|62||Traceability||http://bit.ly/2lCWRK9||Traceability guidelines||Guideline||-||Incoming funds and commitments transactions must contain provider-activity-id where the funds are received from an IATI reporting institution||Accept||While not specifically related to this proposal, question was raised about the possibility of adding incoming commitments.|
|63||Traceability||http://bit.ly/2lCWRK9||Traceability guidelines||Guideline||-||Transaction types ‘Disbursement’ and ‘Expenditure’ should be used in accordance with the descriptions in the Transaction Type codelist. i.e. Disbursements are made to recipients who should also be required to report their activities to IATI. The recipients of expenditures fall outside of IATI traceability standards||Accept||There seemed to be a consensus it the room about this proposal but it was pointed put that the definition of disbursement and expenditure can be better explained. There was discussion around the specific wording being used in this proposal and a suggestion to change it from "required to report activity to IATI" to "will be expected to report activity to IATI". It was clarified that this proposal is about a guideline.|
|64||Traceability||http://bit.ly/2lCWRK9||Traceability guidelines||Guideline||-||Incoming funds and commitments transactions should contain provider-org details where the funds are received from a non-IATI reporting institution||Accept||It was suggested that for better data use, provider org should provide full name and more elaborate description. It was also proposed that a common terms is used for organisations that are unable to disclose this informaton.|
|65||Traceability||http://bit.ly/2lCWRK9||Traceability guidelines||Guideline||-||Disbursements should contain receiver-org details and/or receiver-activity-id wherever possible||Accept||It was highlighted that the wording in this proposal should be made consistent with the previous slide (slide 64).|
|67||Double Counting||http://bit.ly/2lCWJdv||Double-counting guidelines||Guideline||-||There must be no double counting within a single publisher's activities||Accept|
|68||Double Counting||http://bit.ly/2lCWJdv||Double-counting guidelines||Guideline||-||Secondary publishers must be excluded from any attempt to aggregate IATI data. Wording of the reporting-org/@secondary-reporter documentation should be changed to reflect this||None||Better user guidance needs to be provided for secondary publishers.||It was agreed that this proposal should be worked out seperately and better user guidance should be provided for secondary publishers to avoid double counting.|
|69||Double Counting||http://bit.ly/2lCWJdv||Double-counting guidelines||Guideline||-||Use traceability guidelines to describe, and therefore cancel out activity or transaction duplication. Where an activity reports incoming funds that come from a disbursement reported elsewhere in IATI data, the disbursement should not be counted||None||See above|
|70||Double Counting||http://bit.ly/2lCWJdv||Double-counting guidelines||Action||-||Create a dedicated guidance page on this topic, informed by answers to the consultation questions below.||Accept||As double counting cannot be avoided in the IATI standard, the proposals for better guidance on the topic was welcomed by everyone. Following explanation of what is considered as double counting in IATI terms, it was suggested that the definition of double counting is made clearer and the following wording is added "following hiearachy and traceability guideline".|
|72||Core Funding||http://bit.ly/2m1jmo4||Core funding||Schema||2.03||Use activities with clearly defined aid-type (to be discussed under activity standard) to reflect core funding. This can also apply to other sources of income.||Consult further||Further discussion is required.||There was discussion on whether core funding should be handled under the activity or organisation standard with opposing view in the room. Trust funds were brought into the discussion on this proposal but was agreed that they should not be considered under this proposal.Overall, it was agreed that this should be discussed further with specific proposals being worked out, involving more multilateral organisations that can share their experience.|
|73||Core Funding||http://bit.ly/2m1jmo4||Core funding||Schema||2.03||Mirror the <total-expenditure> structure for income, allowing for the reporting of income sources such as mass fundraising, crowdsourcing, private donations, core support funding from donors etc.||Consult further||No discussion.|
|75||Humanitarian||Miscellaneous Humanitarian issues||-||None||Continue discussion on IATI Discuss.||There was discussion about how the IATI standard can meet the needs for both development and humanitarian aid. It was agreed that to understand the impact of the proposals being made further discussions should take place and everyone were encouraged to contribute to the IATI Discuss forum.|
|77||Results||http://bit.ly/2lEbPzM||Misellaneous Results Issues||Schema||2.03||Change cardinality of target and actual elements from 0..1 to 0..*||None||As the proposals for this section were submitted late it was decided to defer substantive discussion to the 2.03 consultation|
|78||Results||http://bit.ly/2lEg1za||Misellaneous Results Issues||Schema||2.03||Change all results value attributes to optional||None||No discussion.|
|79||Results||http://bit.ly/2lEg1za||Misellaneous Results Issues||Codelist||2.03||Add qualitative code to IndicatorMeasure codelist||None||No discussion.|
|80||Results||http://bit.ly/2lEg1za||Misellaneous Results Issues||Codelist||2.03||Add indicator lists to IndicatorVocabulary codelist per StandardisedIndicators worksheet.||None||No discussion.|
|81||Results||http://bit.ly/2lE9y7n||Misellaneous Results Issues||Schema||2.03||Add optional aggregation-status attribute to indicator element||None||No discussion.|
|82||Results||http://bit.ly/2lE9y7n||Misellaneous Results Issues||Schema||2.03||1) Add optional iso-date attribute to baseline element|
2) Add location and dimension elements (0..*) to baseline element
3) Change baseline element cardinality to 0..*
|83||Results||http://bit.ly/2mi2kDg||Misellaneous Results Issues||Schema||2.03||Add participating-org element as a sub-element of result and indicator elements||None||No discussion.|
|85||Common Standard||http://bit.ly/2m0EWJL||URL Syntax||Rule||3.01||Enforce all URL.s to be absolute, not relative||Accept||Look into implementing as a Guideline in 2.03||This could be implemented as a Guideline so that it is not necessary to wait for 3.01.|
|86||Common Standard||http://bit.ly/2m0EWJL||Organisation Identifier Syntax||Schema||3.01||Enforce use of uppercase for organisation identifiers (and registration agency suffixes)||Consult further||General agreement that there should be case-sensitivity.|
Less agreement around requiring upper-case. There are several problems around backward-compatibility.
|87||Common Standard||http://bit.ly/2m0EWJL||Activity identifier syntax / u.r.l encoding||Schema||3.01||1) Do nothing but enforce proper url encoding on all urls|
2) Restrict character set using Regex
|Consult further||Tech Team to look into why Option 1 may cause people problems.||Majority of persons in favour of Option 1. A couple of people favour option 2.|
Character encoding is a problem that has been solved. Need more investigation into the actual reasons why standard methods of character coding cannot work.
Noted that if Option 2 selected it would be a challenge to get all publishers to follow the rule. There will also be old data, so it wouldn't solve the root problem.
|88||Common Standard||http://bit.ly/2m0EWJL||Booleans||Schema||3.01||Enforce Booleans to be reported as 0/1 NOT false/true.||Reject||XML already specifies what a valid value for a boolean is (1, 0, true, false). IATI shouldn't redefine this.|
|89||Common Standard||http://bit.ly/2m0EWJL||Character encoding||Guideline||2.03||IATI files should use UTF-8 character encoding||Reject||XML parsers should be able to handle varied character encoding. If they cannot, they're not a good parser.|
This is a non-issue.
|90||Common Standard||http://bit.ly/2m0EWJL||Root element||Schema||3.01||Make root elements mandatory||Accept||This was not required from the start to allow for files to be made up of lots of separate parts. Nobody actually does this.|
|91||Common Standard||http://bit.ly/2m0EWJL||Publisher application||Schema and Codelist||2.03||Add attribute iati-activities/@publisher-app|
Add attribute iati-organisations/@publisher-app
Add new non-embedded codelist PublisherApplication
|Consult further||Tech Team to investigate options further.||Multiple tools can be used in the generation process, so this should be an element rather than an attribute. Is also metadata, so may want to sit in the Registry.|
May want to look at browser user agents (though the use cases are different).
Agree that the information would be useful, though more research needs to be undertaken.
|92||Common Standard||http://bit.ly/2m0EWJL||Exchange rates||Guideline||2.03||Monetary values should, wherever possible, be reported in the primary currency in which the reporting organisation accounts for its operations||Consult further||Consider how to best deal with specifying exchange rates.||Exchange rates caused problems in Bangladesh AIMS. More consultation is required to consider the inclusion of specific exchange rates.|
|93||Common Standard||http://bit.ly/2m0EWJL||Guidance on valid XML||Guideline||2.03||Change the guidance on structured data to read:|
Format - IATI data must be formatted correctly as well-formed XML
Valid - IATI data must pass the relevant IATI schema validation
Rules - IATI data must satisfy the relevant Ruleset that provides additional conditions and logic
|Accept||This is guideline documentation.|
Approved with no objections.
|94||Common Standard||http://bit.ly/2m0EWJL||Percentages||Schema||2.03||All percentages should be specified to be inclusive of boundary values||Accept||No objections.|
|95||Common Standard||http://bit.ly/2m0EWJL||Language||Schema||2.03||Change all definitions of @xml:lang to:|
“A code specifying the language of text in this element.It is recommended that only codes from ISO 639-1 are used. …”
|Accept||Expands permitted values under IATI to the full range of values permitted by BCP 47.|
Suggests as a Guideline that a subset is used. Does not prohibit use of ISO 639-2 or locale subtags.
|96||Common Standard||None||Document-link Description||Schema||2.03||Add a description (with narrative) sub-element to all document-link elements||Accept||No objections.|
Clarification that the element would be optional.
|98||Organisation Standard||http://bit.ly/2m0Wk0C||Core funding||-||Discussion in separate paper. See slide 73||Consult further|
|99||Organisation Standard||http://bit.ly/2m0Wk0C||Total operational expenditure||Schema||2.03||Add total-operational-expenditure element With sub-elements: period-start period-end value narrative document-link as already used in other monetary complex elements||Accept||This proposal arises from the need to capture publishers operational spending in a sustainable way.|
Confirmation was sought (and received) that this element would relate to retrospecive spending.
Suggestion that it should be made clear in the guidance that this refers to operational expenditure related to development.
Further consultation is required to better define or advise what is meant by 'operational expenditure'
|100||Organisation Standard||http://bit.ly/2m0Wk0C||Budget type||Schema||2.03||Add a budget-type attribute to the following elements:|
|Consult further||Go back to Discuss to explore in more detail.||Seems to be a new issue that few people are aware of.|
User need is unclear.
Organisations have different types of budget.
|101||Organisation Standard||http://bit.ly/2m0Wk0C||Budget type||Codelist||2.03||Add a BudgetType codelist with values|
1 - Commitment-based
2 - Disbursement-based
|Consult further||See slide 100|
|102||Organisation Standard||http://bit.ly/2m0Wk0C||Budget type||Schema||2.03||If no budget-type attribute is specified a commitment-based budget type is assumed.||Consult further||See slide 100|
|103||Organisation Standard||http://bit.ly/2m0Wk0C||CRS non-flow data||Schema||2.03||Add crs-nonflow element with five attributes|
year (for which the data applies)
|Consult further||Bill to lead on determining whether IATI needs to be fully compatible with the CRS.||Is required if IATI is to be fully compatible with the CRS.|
General consensus that the element is not needed. Cannot make a decision without determining whether IATI should be fully CRS-compatibile.
|106||Activity Standard||http://bit.ly/2lCMYvS||Secondary publishers||Schema||2.03||Modify definition of reporting-org/@secondary-publisher|
“A flag indicating that the reporting organisation of this activity is acting as a secondary publisher. A secondary publisher is one that reproduces data on the activities of an organisation for which it is not directly responsible. This does not include a publisher officially assigned to report on behalf of another.”
|Consult further||There was confusion about what is meant by the term 'secondary publisher'.|
The use of the term 'proxy' was suggested to clarify where publishers report 'officially' on behalf of another organisation. (eg Swedish SIDA amd Ministry of Foreign Affairs)
Further consultation required.
|107||Activity Standard||http://bit.ly/2lCMYvS||Secondary publishers||Schema||2.03||Add attribute reporting-org/@secondary-unique|
“A flag indicating that this activity, reported by a secondary reporter, is not reported to IATI by a primary publisher and can therefore be expected to be unique.”
|Consult further||For discssion, see above|
|108||Activity Standard||http://bit.ly/2lCMYvS||Secondary publishers||Schema||2.03||Add a code to OrganisationRole codelist used by participating-org|
5 – Owner (?)
|Consult further||For discssion, see above|
|109||Activity Standard||http://bit.ly/2lCMYvS||Transactions||Schema||2.03||1. Add attribute transaction/transaction-date/@advance-instruction|
2. A flag indicating that the transaction date, at the time at which the transaction was first published, is legitimately a future date.
|Consult further||Strong argument that this is an edge case that should not be included.|
But no final consensus.
|110||Activity Standard||http://bit.ly/2lCMYvS||Transactions||Rule||2.03||Transaction date must not be in the future, unless @advance-instruction flag is set in which case transaction must not be more than 30 days into the future.||Consult further||Determine whether any rules need to be undo'd following this decision.||See above|
|111||Activity Standard||http://bit.ly/2lCMYvS||Transactions||Schema||3.01||Value date – Two Options |
1. Make transaction/value/@value-date mandatory (for each occurrence of transaction)
2. Change definition of transaction/value/@value-date. “The date to be used for determining the exchange rate for currency conversions. If not present the value of transaction/transaction-date/@iso-date is assumed.”
|Accept||Consensus on Option 2. Option 1 rejected|
|112||Activity Standard||http://bit.ly/2lCMYvS||Transactions||Codelist||2.03||Change description of TransactionType “Interest Repayment” to “Interest Payment”||Accept||No objections.|
|113||Activity Standard||http://bit.ly/2lCMYvS||Transactions||Codelist||2.03||Addition to TransactionType codelist. 12 - Pledge||Accept||Need 'Incoming Pledge' as well as 'Pledge'.|
|114||Activity Standard||http://bit.ly/2lCMYvS||CRS Channel of Delivery||Schema or Codelist||2.03||Two options|
1) Codelist: Expand the OrganisationType codelist (through both additions and modifications in definitions) to contain all the generic CRS codes. (NB that the numbering of the codes would not align, but could be cross-mapped)
2) Schema: Add attribute participating-org/@channel-code