Validation

[kinlane]

I am working on a JSON schema for HSDS, and for HSDA.

I already have an API for validating an API path or JSON snippet against any JSON schema when ready. Will release as extra set of API paths.

Once schema are establish we will need to establish the set of rules being applied, and how strict we intend on being.

[boxfoot]

@kinlane I'm not clear on the difference between this JSON schema you're working on vs the "model definitions" which are already part of the OpenAPI definition file and lay out the data types being exchanged. Can you help me understand? Thanks!

[NeilMcKLogic]

@kinlane also you have an older topic with a very similar introductory post that I'm too lazy to look up now after going through nearly all of them methodically. ;-)

[kinlane]

All the information you need regarding JSON Schema is here - http://json-schema.org/

When I find the time to finish this project, I will be writing up blog post that covers.

The definitions portion of OpenAPI is JSON Schema, so I have been creating a representation for HSDS (which is the definitions) in the HSDA OpenAPI.

The HSDA validator is an API that accepts a JSON Body, and validates it against the JSON schema I give it. The JSON could be:

1. HSDA Response - Any of the JSON responses, which then uses the JSON schema in the OpenAPI.
2. HSDA OpenAPI - Takes a JSON schema for the OpenAPI, and validates the API is valid schema.

So, I've done the work on creating:

1. JSON Schema for HSDS (In the OpenAPI)
2. The validation API which access JSON and validates.

I'm still working on:

1. The JSON schema for HSDA (The OpenAPI)

I've struggled with it being a boolean decision (yes/no) or % complete validation.

I've stopped worked on because of the discussion leading up to #45 /complete, because it changes the schema, forcing me to redo work.

Also I'm struggling because the OpenAPI usage of JSON schema isn't complete, and I'm missing some operators to handle validation. Some of this is coming in OpenAPI 3.0, but some I will have to handcode, and my JSON schema chops are only about 65% currently.

The validator is becoming it's own HSDA microservice, and will be versioned and evolved on it's own. It depends on the JSON schema in the OpenAPI, and the JSON schema for the OpenAPI.

[timgdavies]

@kinlane Is the process of getting from HSDS datapackage.json -> jsonschema documented anywhere?

On validation, it's worth separating out a couple of different concepts we find:

• Technical validation - does the data that is provided meet the spec, in-so-far as required fields are present, and other fields that are present are in the right structure and data types. This is what a schema validator would generally check.
• Conformance - are terms being used in the right way? I.e. are people putting the right data in the right fields. This is much harder to automatically check in a comprehensive way - and schema languages often don't provide all that is needed to check it. We tend to find the best validation here is from human checks - but that tools can help by feeding data back to people as it might appear in a user interface e.g., as that helps data creators spot incorrect mappings or things that are not quite right.
• Quality - which can only be assessed in relation to a particular use-case, and which involves looking at how much data is filled in, how consistent it is and so-on. Again, this falls outside of schema checks, although some checks like this can be scripted.

Happy to work with you on exploring more how we can get a good approach to validation across HSDA and HSDS going.

[kinlane]

I have not put HSDS datapackage.json into the road map. Will do.

Agreed on these three breakdown areas, and will be using as guide as I begin organizing the rules being entered in the JSON schema, and applied at validation time.

[kinlane]

The Postman collection for HSDA is validated against the OpenAPI for HSDA core, and we'll adding contract test scripts to each request to test against the OpenAPI as a monitor on a schedule, or as part of the CI/CD pipeline -