Standards Day Notes
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

Comment only
Slide No.PaperLinkIssueTypeVersionProposalOutcomeNext StepDiscussion (Public)
7Rules and Guidelines Schedules Guideline2.03The need to produce and maintain an implementation schedule should no longer be a requirement of IATI publishing.Consult furtherThe 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.1Rules and Guidelines Schedules Guideline2.03Publishers should improve and regularly maintain the content of all fields in their IATI Registry publishing accounts.
Consult furtherIt 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.
8Rules and Guidelines 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 furtherNew 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.
9Rules and Guidelines Registry Publisher Status Action?Make the status of ‘Active’ or ‘Dormant’ visible to all
Consult furtherSome 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.
11Rules and Guidelines Registry Publisher Status Action?Amend the highlighted published ‘count’ on the IATI Registry to refer to ‘Active’ publishers.
Consult furtherNo discussion.
36Codelist Management
Embedded and Non-embedded listsAction2.03Redefine 30 codelists (as per list in paper) from embedded to non-embedded during the 2.03 upgrade process
Consult furtherAccept in principle but check details of which should be movedAgreement on principle.

Need to look through the proposd list to ensure that all should definitely be moved.
44Codelist Management
Shared governance of Organisation Identifier Lists codelistAction2.03Maintenance of the OrganisationIdentifierList list should be carried out by the 'org-id project’
AcceptTech 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.
45Codelist Management
Codelist mappings Codelist2.03Codelist mappings should refer to a Schema, not a Dataset
AcceptThis 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.
72Core Funding fundingSchema2.03Use 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 furtherFurther 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.
73Core Funding fundingSchema2.03Mirror 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 furtherNo discussion.
77Results Results IssuesSchema2.03Change cardinality of target and actual elements from 0..1 to 0..*NoneAs the proposals for this section were submitted late it was decided to defer substantive discussion to the 2.03 consultation
78Results Results IssuesSchema2.03Change all results value attributes to optionalNoneNo discussion.
79Results Results IssuesCodelist2.03Add qualitative code to IndicatorMeasure codelistNoneNo discussion.
80Results Results IssuesCodelist2.03Add indicator lists to IndicatorVocabulary codelist per StandardisedIndicators worksheet.NoneNo discussion.
81Results Results IssuesSchema2.03Add optional aggregation-status attribute to indicator elementNoneNo discussion.
82Results Results IssuesSchema2.031) 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..*
NoneNo discussion.
83Results Results IssuesSchema2.03Add participating-org element as a sub-element of result and indicator elementsNoneNo discussion.
89Common Standard encodingGuideline2.03IATI files should use UTF-8 character encodingRejectXML parsers should be able to handle varied character encoding. If they cannot, they're not a good parser.

This is a non-issue.
91Common Standard applicationSchema and Codelist2.03Add attribute iati-activities/@publisher-app
Add attribute iati-organisations/@publisher-app
Add new non-embedded codelist PublisherApplication
Consult furtherTech 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.
92Common Standard ratesGuideline2.03Monetary values should, wherever possible, be reported in the primary currency in which the reporting organisation accounts for its operationsConsult furtherConsider 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.
93Common Standard on valid XMLGuideline2.03Change 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
AcceptThis is guideline documentation.

Approved with no objections.
94Common Standard percentages should be specified to be inclusive of boundary valuesAcceptNo objections.
95Common Standard 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. …”
AcceptExpands 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.
96Common StandardNoneDocument-link DescriptionSchema2.03Add a description (with narrative) sub-element to all document-link elements AcceptNo objections.

Clarification that the element would be optional.
99Organisation Standard operational expenditureSchema2.03Add total-operational-expenditure element With sub-elements: period-start period-end value narrative document-link as already used in other monetary complex elementsAcceptThis 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'
100Organisation Standard typeSchema2.03Add a budget-type attribute to the following elements:
Consult furtherGo 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.
101Organisation Standard typeCodelist2.03Add a BudgetType codelist with values
1 - Commitment-based
2 - Disbursement-based
Consult furtherSee slide 100
102Organisation Standard typeSchema2.03If no budget-type attribute is specified a commitment-based budget type is assumed.Consult furtherSee slide 100
103Organisation Standard non-flow dataSchema2.03Add crs-nonflow element with five attributes
year (for which the data applies)
Consult furtherBill 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.
106Activity Standard publishersSchema2.03Modify 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 furtherThere 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.
107Activity Standard publishersSchema2.03Add 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 furtherFor discssion, see above
108Activity Standard publishersSchema2.03Add a code to OrganisationRole codelist used by participating-org
5 – Owner (?)
Consult furtherFor discssion, see above
109Activity Standard 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 furtherStrong argument that this is an edge case that should not be included.

But no final consensus.
110Activity Standard 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 furtherDetermine whether any rules need to be undo'd following this decision.See above
112Activity Standard description of TransactionType “Interest Repayment” to “Interest Payment”AcceptNo objections.
113Activity Standard to TransactionType codelist. 12 - PledgeAcceptNeed 'Incoming Pledge' as well as 'Pledge'.
114Activity Standard Channel of DeliverySchema or Codelist2.03Two 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
Consult further
116Activity Standard IdentifierCodelist2.03Deprecate the BudgetIdentifier codelistAcceptConsensus as codelist has been replaced by expanded CRS Purpose codes
117Activity Standard IdentifierSchema2.03Remove reference to the BudgetIdentifier codelist in the definition of country-budget-items/budget-item/@code.AcceptWe 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.
118Activity Standard estimated costSchema2.03Add element <total-estimated-cost> with <value> and <narrative> sub-elements as used elsewhereConsult furtherThere 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.
120Activity Standard of Description TypeSchema2.03 (?)Add maxOccurs="1" to the schema entry for iati-activity/description/@type.AcceptConsensus
122Activity Standard’ use of their own coded vocabulariesGuideline2.03Strongly recommend that publishers either include URLs or descriptions on elements with a publisher-provided codelist.AcceptIt 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.
123Activity Standard Aggregation StatusSchema2.03Add an @aggregation-status attribute to the iati-activity/sector elementConsult furtherProponents 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.
124Activity Standard from forward-looking budgetsSchema2.03Add @budget-exempt attribute to iati-activity element with associated BudgetExempt codelistConsult furtherThere 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.
125Activity Standard from forward-looking budgetsCodelist2.03Add BudgetExempt codelist with values
1 - Commercial restrictions
2 - Legal restrictions
3 - Rapid onset emergency
Consult further