New validation check: bodsVersion

[kd-ods]

Check that publicationDetails.bodsVersion is the same for all statements in the package.

[odscjames]

This has been done in the lib but not added to the Cove UI

[odscjames]

Look ok? @kd-ods @ScatteredInk

[kd-ods]

I think we need to work on this validation check a bit.

First: is it a validation check at all? Nowhere in the BODS docs or schema, explicitly require that all statements in a pseudo-package being run through CoVE conform to the same BODS version. So really this is more of a flag/warning to publishers.

Secondly, we can't say "...is a different version of the schema than the file", since the file doesn't have a version.

Conclusion: all this test can do is flag that statements in the pseudo-package are stated to conform to different versions of the standard. So

Check Statements in this file are published against different versions of the BODS schema.

Information Schema versions used: 0.1, 0.2

Where problem occurs Not applicable

Thoughts?

[robredpath]

@kd-ods in 360 CoVE we've added some next to explain a bit more about what additional checks are and split them out into some groupings - the template file is in https://github.com/OpenDataServices/cove/blob/490e6ae25ff6498a4fd24994837b87ec03726f33/cove_360/templates/cove_360/explore.html and the message text is in https://github.com/OpenDataServices/cove/blob/master/cove_360/lib/threesixtygiving.py#L404-L994 (sorry, it's all embedded in code - let me know if it's not clear and I'll pull it out for you).

Applying some of the same process to BODS CoVE might help contextualise the additional checks a bit more (they're not validation, they're another kind of feedback).

[kd-ods]

Thanks, @robredpath - Yes, this is something I've been thinking about for a while. My initial concern, which remains, was that from a user's perspective the divide between checks and additional checks is an artificial and not particularly helpful one.

I discussed this a way back with @odscjames which lead to the idea of finessing the architecture so that all checks, additional checks, report stats etc could be black-boxed and presentation of the results be considered at the UI level. I think that's currently still a live discussion amongst ODSC devs?

That aside and to get back to your suggestion: yes, we should take a step back and think about how BODS CoVE reports are best presented to users.

[odscjames]

Call with @kd-ods

File starts with a good version, goes to a bad one:

File starts with a bad version, goes to a good one

[kd-ods]

Some error message suggestions. I'm trying to make them consistent with the suggestion in https://github.com/openownership/cove-bods/issues/56:

File starts with a good version, goes to a bad one:

The first statement of the submitted data has a BODS version of: [VALID BODS VERSION]

A subsequent statement (or statements) specify a different BODS version.

All statements in the submitted data will therefore be validated against the above version: [VALID BODS VERSION].

File starts with a bad version, goes to a good one

The first statement of the submitted data has a BODS version of: [INVALID BODS VERSION]

A subsequent statement (or statements) specify a different BODS version.

All statements in the submitted data will therefore be validated against the latest version of BODS: [BODS latest].

[odscjames]

deployed