documentation suggests that the usage of country codes is the provided extension mechanism for publicode.yml files

[mburri]

We already discussed about this here: puzzle/oss-catalog#17 (comment)

The misleading wording can be found here:

publiccode.yml/docs/standard/country.rst

Line 6 in bdb1d4a

While the standard is structured to be meaningful on an international

This sounds as it is possible to add country specific sections to a publiccode.yml, but that is not the case if the publiccode-parser-go is used to parse the yaml files.

I think it would actually be nice to add country specific sections without changing the parser!

[tomootes]

@mburri are you stating that countries should be authorized to do so with their extension as they like? And that the parser should not be checking on this?

[mburri]

Kind of.

It's just an idea. The current wording of the country-specific sections actually implies that this is the case. At the very least, the wording in the documentation should change.

But then I wonder if there should be an easy way to customise the standard for certain use cases (without working with forks).

[tomootes]

Hmmm. I'm not able to find the specific part of the text which implies this. Maybe we can add a sentence which states that the country extension is still part of the standard: https://yml.publiccode.tools/country.html.

We could create sub-projects/repo's for countries? But then, in the Netherlands we haven't come up with a property that was useful to NL only. If it's not needed, that's the best. Also, in the end i think project convergence on a European level should be a goal as well.

[mburri]

Yeah, me link was a bit misleading. I'm referring to the whole section: https://github.com/publiccodeyml/publiccode.yml/blob/bdb1d4a492e43a6c77f3a20520d5ef9e5eb2f645/docs/standard/country.rst?plain=1#L6C1-L10C27

The relevant sentence for me is: The provided extension mechanism is the usage of country-specific sections.

and then there is an example for it- but this is actually the only possible country specific section allowed by the parser at the moment. I tried to add a ch section after reading this section - but the parser did not allow this.

But it may be that I misinterpreted paragraph...

Meanwhile, I completely agree it's best if something is not needed.

Background: We wanted to add the organisation uri and name to our publiccode.yml files. In the meantime, this feature made it into the official standard 0.5, so we don't need an extension mechanism now.

[bfabio]

Yeah, me link was a bit misleading. I'm referring to the whole section: https://github.com/publiccodeyml/publiccode.yml/blob/bdb1d4a492e43a6c77f3a20520d5ef9e5eb2f645/docs/standard/country.rst?plain=1#L6C1-L10C27

The relevant sentence for me is: The provided extension mechanism is the usage of country-specific sections.

and then there is an example for it- but this is actually the only possible country specific section allowed by the parser at the moment. I tried to add a ch section after reading this section - but the parser did not allow this.

But it may be that I misinterpreted paragraph...

@mburri
That part is a leftover from when country sections had their own versioning, separate from the main spec, and they were even called "extension, not the case anymore. countryExtensionVersion is a vestigial hint of that (we should deprecate it BTW).

Sending a better worded PR ASAP.

Meanwhile, I completely agree it's best if something is not needed.

Background: We wanted to add the organisation uri and name to our publiccode.yml files. In the meantime, this feature made it into the official standard 0.5, so we don't need an extension mechanism now.

Honestly, I'd like country specific sections dropped. The only one that exists (it.) already has half its fields deprecated.
In general they feel smelly: if something is useful for one country, it's relevant for others too and should probably be part of the main standard instead, just like organisation.uri.

There might be cases when the country is so special that they need something custom, but we can kinda generalize that as well, eg.:

conformsTo:
  - https://eur-lex.europa.eu/eli/reg/2016/679/oj
  - [...]

instead of

it:
  conforme:
     gdpr: true

[bfabio]

@mburri are you stating that countries should be authorized to do so with their extension as they like? And that the parser should not be checking on this?

@tomootes letting everyone add their own country section is a big no-no.
Without validation, anyone will invent their own mini-format and break compatibility and we'd be in for a world of pain.

It's short term gain for long-term pain and besides, the voting rules already give some leeway to national section governance.

To put some weight behind my gut-feeling no no, a few things that come to mind and make me shiver:

• $ABC_COUNTRY adds its own section, abc.metadata. They define metadata as being a base64 XML document
• $ABC_COUNTRY's Ministry of Whatever adds a key, $ABC_COUNTRY's Agency of Whatever adds another key. $ABC_COUNTRY private sector's company working with PAs adds a different key altogether. Who's deciding/coordinating what's the canonical $ABC_COUNTRY country section?
• [...]

and there could be plenty more.