Add a field for the version of the standard the data is published to

[duncandewhurst]

Related discussion about how to model this in OCDS: open-contracting/standard#426

[duncandewhurst]

As part of #83, we plan to rename links to spans, in which case we can also rename relatedResources to links since the former name was chosen only to avoid a clash.

Once that is done, this issue can be addressed by the same approach as proposed in open-contracting/standard#426 (comment) so data published against the alpha would include the following:

{
  "links": [
    {
      "rel": "describedby",
      "href": "https://raw.githubusercontent.com/Open-Telecoms-Data/open-fibre-data-standard/0__1__0__alpha/schema/network-schema.json"
    }
  ]
}

I think we would want to make this entry in the links array required, whilst allowing for other, optional, entries. That seems possible using a combination of either tuple validation for the schema link and additional items for the optional links, or items for the optional links and contains for the schema link.

Much of the discussion in the OCDS issue is about how to support extensions, which is not currently an issue for OFDS. However, similar options can be considered if an extensions mechanism is implemented in the future.

@kindly, as you were involved in the OCDS discussion, could you check that you're happy with the proposal above?

@odscjames, would this present an issue for COVE at all? (Either in terms of fetching the linked schema or in using the additional array validation options)

[kindly]

Seems good to me.

[odscjames]

@odscjames, would this present an issue for COVE at all? (Either in terms of fetching the linked schema or in using the additional array validation options)

Can't see any issues.

Cove would probably look through the links array and find certain hard coded strings to decide what version it was looking at. Once it knew, it would apply it's own known JSON Schema and additional checks to work on the data. It would have to do this instead of just downloading the URL given, as it needs to know special things about conversions, additional checks and so on.

Extensions would be interesting. For above reason, Cove would want extensions to be defined by multiple "describedby" entries, one for the core then one for each extension. Having one entry of all schemas merged would causes issues in detecting things.

By default, I suspect the fancy JSON Schema options used will mean the raw JSON Schema validation errors coming out of JSON schema tools will be very unhelpful. We'll need some extra time to make the error messages helpful, but we have already faced that in BODS thanks to their use of oneOf so I'm not worried.

[duncandewhurst]

Great. Thanks, both!