Error with validation checks for Release IDs

[mrshll1001]

In OCDS the guidance for release IDs is given as follows:

A release identifier must be unique within the scope of the contracting process of which it is a part. In other words, across all OCDS releases with the same ocid value, each release identifier refers to exactly one release; no two releases use the same release identifier.

A release identifier must also be consistent within this scope. For example, if the id of a release is “12345” in one release package, then the id of the same release in another release package must also be “12345”.

This means two releases may have the same release id if they are under different contracting processes (OCIDs) and still be valid. In this gist there are 11 releases under 11 different OCIDs, which all happen to share a release ID. The expected behaviour is that the release ids are not flagged as invalid however CoVE is flagging this as a problem.

[Bjwebb]

Note: CoVE's behaviour reflects what the 1.0 and 1.1 standard used to say open-contracting/standard#455

Which is not to say we shouldn't change it now, of course.

[robredpath]

Update validation checks for Release IDs to reflect standard change

[duncandewhurst]

Noting that this came up again with another publisher, so it would be good to fix.

[Bjwebb]

@mrshll1001 @duncandewhurst How does this look for the error if the combination is non-unqiue? I'm looking especially for feedback on the Examples column, is seperating with a comma sufficiently obvious as to what's going on?

[duncandewhurst]

Shouldn't this error be reported under 'Conformance (rules)' rather than Structural Errors?

We could then have a more verbose error, e.g.

1 of your ocids has duplicate release identifier(s). (view all error(s)) ^

ocid	release id
ocds-123456-001	001
ocds-123456-001	001
ocds-123456-001	002
ocds-123456-001	002

A release identifier must be unique within the scope of the contracting process of which it is a part. In other words, across all OCDS releases with the same ocid value, each release identifier refers to exactly one release; no two releases use the same release identifier.

[Bjwebb]

"Structural Errors" is what we call errors that have come out of schema validation, and the unique IDs check happens as part of schema validation.

Strictly speaking the schema doesn't describe the ID uniqueness, but it does say that each whole release must be unique. However, checking this for a lot of laregish releases is computationally expensive. Therefore, we override this particular aspect of schema validation, so that if there are IDs, we check those first, because its quicker (but if there aren't IDs we do the slower check). Identical whole releases must necessarily have the same IDs (but not vice versa), so our check is stricter than normal schema validation.

Because we've implemented this by overriding the json schema validator for uniqueness, the errors come out with the other validation errors. However, it would still be possible to keep this implementation the same, but move it in the frontend. I'm not sure if this is a good idea or not. (If we just do that, the CLI would stay the same, as well as the errors that go into kingfisher).

[duncandewhurst]

Ah, I see. I thought it would be an additional check since it involves looking at two fields.

I think this error benefits from a more verbose explanation in the CoVE front-end because of the extra complexity, so I'd favour moving it to conformance errors.

For the CLI and Kingfisher, since the audience for those is mostly helpdesk analysts I think it's fine to keep it as a structural error with the shorter description - as we can still report it to publishers as a conformance issue.

Adding @jpmckinney in case he has a view

[jpmckinney]

I have no strong feeling. It occurs rarely, so it's not terrible to leave it as-is, but I agree that it'd be clearer to have a longer explanation.

[jpmckinney]

@Bjwebb To understand the state of the issue: Has the check been updated in lib-cove-ocds, and now we're just discussing how it's reported, or does that first step still need to be done? (I can then rename and/or transfer the issue.)

[Bjwebb]

I've made the change on a branch, but haven't had chance to look at tests.

https://github.com/OpenDataServices/lib-cove/compare/cove-1253-multiple-ids
https://github.com/open-contracting/lib-cove-ocds/compare/cove-1253-multiple-ids

[Bjwebb]

There's now lib-cove and lib-cove-ocds PRs for this work, with tests:

• common_checks: Update unique_ids override to support multiple ids  OpenDataServices/lib-cove#85
• common_checks: Check the combination of ocid,id is unique in releases lib-cove-ocds#91