Examples of well-implemented IATI extensions?

As something potentially useful that I can think of… The elements page on the dashboard includes information about non-standard namespaces.

A quick look through indicates that most of the provided namespaces resolve to 404, though it could act as somewhere useful to start from.

As to the question to OIPA; We indeed don’t support namespaces and have no plans to support them in the master of OIPA.

There’s certainly advantages for namespaces when used in certain groups of publishers, but there’s too much interpretation to be done to be able to standardize namespaces into a generic application. A customized branch to address that interpretation and its specific use cases would be a better option.

As to examples, I only know of RAIN foundation and Akvo that use namespaces. Maybe Marten Schoonman can tell you more on Akvo’s use.

Hi Rory Scott - we’ve recently implemented this during the OpenAg tool workshop but didn’t have time to talk about it.

Not sure if this helps but we’ve added element search and from your link, we can do either:

http://d-portal.org/q.json?from=element&orderby=element_volume-&limit=10&element_name0_like=usg:%

or

d-portal.org/q.json?from=element,act&orderby=element_volume-&limit=100&reporting_ref_nteq=US-1&element_name0_like=usg:%

You can go deeper into elements hierarchy like so:

d-portal.org/q.json?from=element&orderby=element_volume-&limit=10&element_name0=dimension&element_name1=target&element_name2=period&element_name3=indicator

For more info, I’ll be publishing a blog post about this next week on d-portal.

ps: This is new and may likely crash or fail to work.
pps: Hyperlinks are borked due to discuss platform limiting new users to one link for first post :}

Thanks everyone, this has been really helpful. I think it’s highlighted two things to me:

1. I’m still not completely clear on how I would go about making an extension, and it doesn’t seem like there are any obvious examples to draw upon.
2. It doesn’t look as though many (or even any?) publishers are using them correctly as of right now.

If anyone has any further insights please post them here

I can find a couple of namespace declarations:

• xmlns:akvo=“http://akvo.org/iati-activities”
• xmlns:ir=“http://iatiregistry.org/ns/record#”
• xmlns:ir=“http://iatistandard.org/downloads/iati-registry/record-schema.xsd”
• xmlns:cerf=“http://cerf-gms.unocha.org/CERF01”
• xmlns:fts=“http://fts.unocha.org”
• xmlns:fts=“nothing”
• xmlns:sida=“http://sida.se/ns/strategy#”
• xmlns:ns1=“xml”
• xmlns:usg=“http://foreignassistance.gov/iati#”
• xmlns:usg=“http://www.foreignassistance.gov/web/IATI/usg-extension”

A namespace declaration is supposed to contain a URI, not a URL, so you’re not required to provide a web page (but it’s recommended).

So xmlns:fts="nothing" and xmlns:ns1="xml" are wrong, but the others are technically ok. Although for instance both variations of ir or fts or usg are considered to be different namespaces, even if that wasn’t intended.

I internally use my own xmlns:iati-me="http://iati.me/..." variations in pipeline processes but (try to) make sure it doesn’t show up in published files. At the end of everything, I should be able to remove every attribute and element from none-IATI namespaces, and end up with valid IATI.

If you want, you can add invoices as UBL data to your expenditure transactions: <ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" ... and then provide an interface looking for //iati-actiivity[transaction[@type="4"]/ubl:Invoice.

I think the difficulty is that we don’t specify interpretation of IATI data:

If Akvo publishes (leaving out the narrative layer):
<description type="1" akvo:type="4">Subtitle</description> <description type="1" akvo:type="5">Project plan</description>

Can I can concatenate those as <description type="1">Subtitle&#xa;Project plan</description>?

Thank you Rolf Kleef and Marten Schoonman - I see what mistake I’ve made: I’ve been thinking that the reason these files are valid is that their namespace URI is also a URL which points to an actual schema extension. Not so. Even though the files which use this method will validate via the IATI Validator, they don’t actually strictly validate if you use something like xmllint -valid <file> -schema <iati-activities.xsd>:

### Validate agains the XML standards and the IATI activities schema
xmllint -valid http://iati.openaid.se/xml/189.xml -schema /IATI-Schemas/iati-activities-schema.xsd -noout
# -valid: validate this file
# -schema: fetch the xsd file from this address
# -noout: don't print the whole file to console afterwards!

######## Output ########
# http://iati.openaid.se/xml/189.xml:1: validity error : Validation failed: no DTD found!
# <iati-activities version="2.01" generated-datetime="2017-03-17T13:53:14">
#                                                                           ^
# http://iati.openaid.se/xml/189.xml validates

Similarly, when the namespace is declared at the top of the file: validator, versus terminal:

xmllint -valid http://beta.foreignassistance.gov/assets/IATI/Argentina.xml -schema http://iatistandard.org/202/schema/downloads/iati-activities-schema.xsd -noout

######## Output ########
# http://beta.foreignassistance.gov/assets/IATI/Argentina.xml:1: validity error: Validation failed: no DTD found!
# /web/IATI/usg-extension" generated-datetime="2017-03-22T23:18:00" version="2.01"
#                                                                               ^
# http://beta.foreignassistance.gov/assets/IATI/Argentina.xml validates

So the questions is, is this a problem? If not, I could happily just get around validation of an extension in this way, but it doesn’t seem ideal. For instance if I was extending a transaction to have a new date value within it, I would prefer to be able to extend the IATI schema so that when I run a validation procedure, I can tell if I’ve violated the original IATI specification or my own extension within one validation…

Ah right, got it - it still seems a little unsatisfying to me, but I see the logic. I really appreciate your time, thanks!