Clarify Location:Country Code in 360Giving Reference

[ekoner]

In the 360Giving Reference document for Location:Country Code, the description reads: "The ISO Country Code of the location of this activity."

There are multiple ISO country codes. Please update to add a link to the specific ISO country code i.e. "The 2-digit ISO Country Code of the location of this activity."

[caprenter]

I think we should refer to the codes as "ISO 3166-1-alpha-2 country code"

I don't think we should include a link in our documentation tho (as this is currently part of the standard, and would require us to maintain it, although I'm not too upset if that link is the one suggested)

[ekoner]

Can we be consistent then as the Currency definition includes a link: http://www.threesixtygiving.org/standard/reference/#toc-grants-sheet

[caprenter]

Ah - good point. This is generated directly from the schema. In the schema we also refer to "The date must be in ISO 8601 format (YYYY-MM-DD)" without a link.

I think we need to decide: 1) Link or no link 2) If link; is wikipedia the place to link to (as opposed to ISO)

We then need to apply our decision where ISO is mentioned (in the following places): https://github.com/ThreeSixtyGiving/standard/blob/master/schema/360-giving-schema.json#L8 https://github.com/ThreeSixtyGiving/standard/blob/master/schema/360-giving-schema.json#L41 https://github.com/ThreeSixtyGiving/standard/blob/master/schema/360-giving-schema.json#L133 https://github.com/ThreeSixtyGiving/standard/blob/master/schema/360-giving-schema.json#L452

[stevieflow]

I say Link

[caprenter]

Is that an order or an opinion?

I'm still not sure about links in the schema - partly because maintaining links in the schema doesn't seem right. I'm also not really convinced that we should be linking to other than anything where the standard is described (i.e. wikipedia might be practical, but that's not really a 'standard')

An alternative way would be to add this as guidance (FAQs), and keep it out of the schema

[stevieflow]

Sorry - my answer was too brief

I've linked to an issue around codelists too https://github.com/ThreeSixtyGiving/standard/issues/109 - as we might have to consider this, as we seem to "store" the currency values (for example) within the schema

I agree that this might be better served in documentation --> @ekoner

[caprenter]

I think the reason for storing codelists in the schema is to enable some sort of validation - but I'm not sure it has turned out to be useful. @timgdavies will probably know.

Having more stuff in the schema potentially gives us upgrade problems as we try to keep a stable schema. IATI for example resisted having codelists in the schema so that they can be maintained separately.

[timgdavies]

The main user story that matters here might be:

• It should be possible to validate a file, and get a report that includes cases where mandatory code-lists were used incorrectly

So - there may be a good way of dealing with this by (a) not including the codelist in the schema itself, but (b) adding functionality to our validator (CoVE) to pull in and validate against external codelists.

This might require us to create some custom schema property/properties in the JSON Schema to point to where the codelist can be found, and to indicate whether the codelist is a 'closed' or 'open' codelist (using OCDS description of these).

In this situation we may want to also script the creation of a 'validation schema' which does pull in the codelists, that third-parties can use to validate their data without using CoVE.

[stevieflow]

Thinking action is to centre on :

I think we should refer to the codes as "ISO 3166-1-alpha-2 country code"

Flagged that for 0.9. Getting documentation alongside also needed

[KDuerden]

Amendment made in draft, ready to be checked as part of 'housekeeping' of Standard docs.