IATI Consultations Archive

Live discussions and consultations can be found at discuss.iatistandard.org.

Version 2.01 - Iteration 2 - 8. Miscellaneous

This is part of the formal proposal that makes up the second iteration of the Version 2.01 Upgrade process. The first iteration can be found here.

Combined usage of recipient-country and recipient-region

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/71

Tightening up on version

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. [Removed by IATI Tech Team on 12/08/2014 - see discusssion]. It is therefore proposed that:

  •  iati-activities/@version is MANDATORY
  • iati-activity/@version is MANDATORY [Removed by IATI Tech Team on 12/08/2014]
  • iati-activity/@version is DELETED [Removed 12/08/2014]
  • All @version attributes in a given file MUST have the same value [Removed by IATI Tech Team on 12/08/2014]
  • The value of @version MUST be on the (new to 2.01) version codelist
  • for discussion go to http://support.iatistandard.org/entries/57866638-Tightening-up-on-version

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/109

A new non-embedded codelist for IATI Version has been created at  https://github.com/IATI/IATI-Guidance/blob/master/en/upgrades/decimal-upgrade-to-2-01/2-01-changes.rst#codelist-changes

Segmentation and file size

  • In order to ensure that all all IATI-XML files can be handled by all consuming systems it is proposed that a limit of 40MB is placed on the size of any single XML file.
  • Publishers are still encouraged to segment there data into meaningful chunks, BUT the guidance to segment by country is no longer necessarily considered to be best practice.
  • (NB the rule that the activity iati-identifier must be unique still applies. i.e. the same activity should not be reported in two different files by the same publisher)
  • for discussion go to http://support.iatistandard.org/entries/61867937-File-size-and-segmentation

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Extra-Documentation/issues/145

Redefine activity-website as a document-link

  • Remove the iati-activities/iati-activity/activity-website element
  • Add documentary-category codelist categories for Organisation Webpage, Sector Webpage, Country Webpage and Activity Webpage
  • for discussion go to http://support.iatistandard.org/entries/76684383-Redefine-activity-website-as-a-document-link

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/118

Allow multiple languages to be specified for a single document

  •  Change cardinality of document-link/language from single to multiple occurrences
  • This applies to both Activity and Organisation standard
  • for discussion go to http://support.iatistandard.org/entries/77513977-Multiple-languages-per-document

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/130

Delete all previously deprecated items

  • Delete elements, attributes and codes that have previously been deprecated.
  • Delete (not deprecate) elements, attributes and codes that are being removed in this upgrade.
  • for discussion go to http://support.iatistandard.org/entries/78002476-Delete-previously-deprecated-items
  • see also http://support.iatistandard.org/entries/51310806-Delete-don-t-just-deprecate-codes-in-2-01 

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/114

Planned-disbursement Type

  • Delete planned-disbursement/@updated 
  • Add planned-disbursement/@type (using IATI codelist BudgetType)
  • for discussion go to http://support.iatistandard.org/entries/77495498-Align-planned-disbursement-with-budget

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/117

Addition to RelatedActivityType Codelist

  • Add a value to the codelist which means "The same activity reported by another organisation"
  • for discussion go to http://support.iatistandard.org/entries/76862583-Referencing-another-publisher-s-report-of-the-same-activity

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/131

Vocabulary Codelists

  • Add Sector Vocabulary codelist (derived from current Vocabulary codelist) and link to sector/@vocabulary
  • Add Policy Marker Codelist and link to policy-marker/@vocabulary
  • for discussion go to http://support.iatistandard.org/entries/78019646-Separate-vocabulary-codelists

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/132

Date and DateTime formats

  • All dates must now validate against xsd:date
  • All datetimes must now validate against xsd:datetime
  • for discussion go to http://support.iatistandard.org/entries/77542148-Date-and-DateTime-formats

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/133

URL validation

  • Where links are expected we have changed some datatypes from xsd:string to xsd:anyURI

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/116

Removal of "mixed=true"

  •  https://github.com/IATI/IATI-Schemas/issues/112
  • This is set as an option on many elements in the schema to allow a mix of text, elements and attributes. We don't think it is necessary any longer, so have removed all occurances of it in the schema.

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/112

Remove indicatorOutcomeType

  • This is a type that seems to have no use, so it has been removed.

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/129

Rename crs-add/aid-type-flag

[added by IATI Tech Team on 16-07-2014]

  • Rename the element iati-activity/crs-add/aid-type-flag to iati-activity/crs-add/ftc-pb-ip-af [Removed by IATI Tech Team on 12/08/2014]
  • Rename the element iati-activity/crs-add/aid-type-flag to iati-activity/crs-add/other-flags [Added by IATI Tech Team on 12/08/2014]
  • Rename codelist AidTypeFlag to FtcPbIpAf CRSAddOtherFlags [edited by IATI Tech Team on 12/08/2014]
  • for discussion go to http://support.iatistandard.org/entries/29705458-Confusion-Between-Aid-Type-Flag-Type-of-Aid- 

For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/140

Add contact-info/department

[added by IATI Tech Team on 16-07-2014]

  • Add a new element iati-activity/contact-info/department
  • This also requires a narrative sub-element 
  • For discussion go to http://support.iatistandard.org/entries/44571616-Organisational-unit-within-contact-details

 For technical details about implementing this proposal go to: https://github.com/IATI/IATI-Schemas/issues/141

Have more questions? Submit a request

3 Comments

  • 0
    Avatar
    Yue Wang

    Based on my research about processing data using IATI tools, I have some
    thoughts/comments regarding *activity at transaction level* as well as *applying multiple
    data strctures*. However, it's hard to be expressed in a professional way.

    I understand that there are already some plans such as applying @percentage,etc.still
    let's have a look at the two points here:

    <!--Summary-->
    1.Making data in each transaction more related to each other when multiple
    transactions/locations coccur within the same identifier.

    2.Improving the "multiple data structure" processing mechanism in the IATI tool.

     

    <!--In details-->
    1.I believe that Block B is more meaningful than Block A for a couple of reasons.

    Block A:

    <iati-activity>
    <iati-identifier = "123456">
    <sector>
    <sector>
    <transaction>
    <transaction>
    <location>
    <location>
    </iati-activity>

    vs.

    Block B:
    <iati-activity>
    <iati-identifier = "123456">
    <sector>
    <transaction>
    <location>

    <sector>
    <transaction>
    <location>
    </iati-activity>

    To this idea, Owen has mentioned this:
    " IATI XML is designed to be parsed by machines, not read by humans (except incidentally
    for QA purposes), and the order of sibling elements has no semantic meaning under IATI -
    essentially we could order it however we want, and IATI parsers would treat it the same.
    "
    I agree with this point, but if in any case, in the future IATI standard become more
    universal, and potentially it also suppose human to read it. I think it's easier for a
    person to do a quick search of the identifier from the xml file and then start to look at
    it.

    Moreover, to a well-formed xml, it is not supposed to change syntax during the way of processing.
    According to wikipedia " In other words a well formed XML document does not need a DTD, but it must conform to the XML syntax rules.", we can check this out.
    http://en.wikipedia.org/wiki/Well-formed_document#cite_note-2


    Seems that, originally it has the structure of Block B by the time it is first designed based on the globally unique identifier. But later, when multiple transactions/sectors/locations etc. occur, in order to still keep the identifier globally unique, the program needs to reorganize their order from Block C to Block A.

    Block C:
    <iati-activity>
    <iati-identifier = "123456">
    <sector>
    <transaction>
    <location>
    </iati-activity>
    <iati-activity>
    <iati-identifier = "123456">
    <sector>
    <transaction>
    <location>
    </iati-activity>

    I'm not sure whether this way has changed the syntax of xml structure.

    2.This one has some internal relation has the first point.
    By selecting "multiple data structure" to change the way xml looks in the final result, we have figured out that a large amount of data is cut off. Seems that there's a bug especially when it deals with the multiple "same identifiers".
    Currently AidData has proposed some mechanism which can cope with folding different content within each of the "same identifier activity block" together.

    Comments?
    Thanks!

  • 0
    Avatar
    rachel.rank

    Including an exclusions marker attribute to every element in the standard was discussed at the last IATI Steering Committee meeting and there was no objection to this proposal in the meeting. Exclusions is listed under the list of miscellaneous items for the upgrade but there is no specific proposal on how to implement this. Please clarify if any work has been done on developing an exclusions marker, and if it will be included in the upgrade.

    Thanks.

  • 0
    Avatar
    Bill Anderson

    Views both for and against exclusion markers were presented at the last Steering Committee and the meeting did not express an opinion one way or another. I led the argument within the IATI Technical Team not to include this proposal for the following reasons:

    • The standard already requires that all publishers are clear and transparent about the details of their exclusion policy. 
    • Adding an attribute to every element in the standard is a large overhead for unknown benefits
    • Most exclusions that we are aware of are done for security reasons. Flagging where data is being withheld for security reasons is itself a potential security risk.
    • Most importantly, I am unaware of any IATI members other than Publish What You Fund supporting this proposal

     

Please sign in to leave a comment.