Semi-automate the additional_data fields

[yolile]

ref #291

We can maybe also (semi-)automate the additional_data fields – at minimum checking whether "No extensions or additional fields are used." is still true. We can also check that a declared extension is actually used (we shouldn't report extensions unless the fields they define are used).

[jpmckinney]

Agree!

When working on lib-cove-ocds updates, I created a giant mapping sheet that uses all known registered and declared extensions. We can do something similar to create a static lookup between field paths and extensions (and then update it from time to time, at minimum when adding new publishers).

In 2024, I had started manually reviewing this field and had noted offline the following (which would be resolved via automation):

• Prefer Extension Explorer links instead of links with raw.githubusercontent.com, /raw/, github.com/
• Fix the naming of extensions, and their translations, to match the Extension Explorer
• Use es links in Spanish text, where available
• Change the “such as” phrases, based on the extensions automatically detected within the data
• Avoid phrases like "core OCDS"

Re: semi-automating versus fully automating: for semi-automation I had considered:

• Autogenerate a paragraph about registered extensions.
• Display the calculated extensions, etc. in the admin, highlighting extended and undocumented fields, to help admins to author the paragraph about undocumented fields.
• Write a management command to find and give links to datasets that have content to cut from other paragraphs.

---

Back then, I considered relying on the extensions array at the package level, but (as you propose) it is more relevant to describe the extension fields that are actually used. For posterity, my thinking had been:

• Extend the OCDS schema with the declared extensions, and store any warnings that occur like in CoVE
• Calculate the extended fields using ocdskit.schema (remove overlaps with OCDS, like when Australia NSW's extension copies the full release schema), in order to report undocumented fields and extensions used/unused
• Use ocdsextensionregistry to get the extension versions, URLs and names
• Display the extension version, or the commit if the version isn't a tag or master

[jpmckinney]

I'll assign myself to at least share relevant code for that lookup.