|Slide No.||Paper||Link||Issue||Type||Version||Proposal||Outcome||Next Step||Discussion (Public)|
|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.|
|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.
|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.
|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.|
|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.|
|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.
|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.
|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|
|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
|116||Activity Standard||http://bit.ly/2lCMYvS||Budget Identifier||Codelist||2.03||Deprecate the BudgetIdentifier codelist||Accept||Consensus as codelist has been replaced by expanded CRS Purpose codes|
|117||Activity Standard||http://bit.ly/2lCMYvS||Budget Identifier||Schema||2.03||Remove reference to the BudgetIdentifier codelist in the definition of country-budget-items/budget-item/@code.||Accept||We would deprecate at 2.03 and remove in integer, although it was noted that there is no process on the deprecation of individual elements.|
Comms would need to be provided to publishers about this, perhaps as separate guidelines.
|118||Activity Standard||http://bit.ly/2lCMYvS||Total estimated cost||Schema||2.03||Add element <total-estimated-cost> with <value> and <narrative> sub-elements as used elsewhere||Consult further||There was a call to reuse and existing element, rather than add something new. It was suggested that use of a pledge transaction would be useful in this context.|
|120||Activity Standard||http://bit.ly/2lCMYvS||Use of Description Type||Schema||2.03 (?)||Add maxOccurs="1" to the schema entry for iati-activity/description/@type.||Accept||Consensus|
|122||Activity Standard||http://bit.ly/2lCMYvS||Publishers’ use of their own coded vocabularies||Guideline||2.03||Strongly recommend that publishers either include URLs or descriptions on elements with a publisher-provided codelist.||Accept||It was argued that user-defined codelists should publish their codelist as per the codelist schema.|
In general there was agreement that this guideline should progress.
|123||Activity Standard||http://bit.ly/2m4ra8Q||Sector Aggregation Status||Schema||2.03||Add an @aggregation-status attribute to the iati-activity/sector element||Consult further||Proponents of this proposal cited that there is a clear user need for this. Others supported this as it would make activities more searchable.|
An alternative approach was also mentioned - i.e. the introduction of a 'tag' element.
It was suggested that changes to the sector element may cause existing tools to break, and that the least disruptive approach should be taken.
|124||Activity Standard||http://bit.ly/2m4G3YA||Exemption from forward-looking budgets||Schema||2.03||Add @budget-exempt attribute to iati-activity element with associated BudgetExempt codelist||Consult further||There was some confusion about if this applied to planned disbursements.|
An objection was raised that this proposal is included for the purpose of publishing statistics. It also asks publsihers to declare a negative.
Others mentioned this could be helpful in some use cases, for example to explain why data does not exist, and for humanitarian activities.
|125||Activity Standard||http://bit.ly/2m4G3YA||Exemption from forward-looking budgets||Codelist||2.03||Add BudgetExempt codelist with values|
1 - Commercial restrictions
2 - Legal restrictions
3 - Rapid onset emergency