HSDS Validator Technical Requirements

Technical
1

Hi all,

I’ve started work on a draft set of technical requirements for a HSDS Validator tool, which you can review in the following doc:

The doc is in no way finished, and I prefer working in the open on stuff like this so I’m really keen to have people comment and add suggestions etc.

The goal of this doc is to move us up from talking about user stories to thinking about the actual technical requirements for what a validator does; which could then be implemented in different ways. This is in order to help steer existing work on validators in the UK (which might aim to become more re-usable), or steer new opportunities should they arise.

One piece of context: I’ve been quite selective about which User Stories I think are actually in scope should be considered for this because a lot of them sit at a higher level than “validation”; being concerned about issues of Data Quality or User Interface issues. These are all important and we shouldn’t lose sight of them, but validating HSDS is the foundation for all of those things so I want to really focus down on that first.

Anyway, any and all feedback is appreciated!

EDIT:

I’ve put the requirements into the tools spreadsheet and removed them from the Doc to ensure that they’re not contradicting as we iterate on them. I have left the “out of scope” justifications in the doc so we can reference this though:

2

Thanks so much @mrshll . Seems like this analysis could bedone in the same spreadsheet, though – does that seem right? So that we don’t have proliferating documents…

3

Thanks so much @mrshll . Seems like this analysis could bedone in the same spreadsheet, though – does that seem right? So that we don’t have proliferating documents…

Agree, happy to port it back over to the spreadsheet :slight_smile:

4

I’ve ported this back now, and I’ll update my original post to use the new link. I’ll keep the old doc link up because I think the explanation of being “out of scope” is useful and I don’t want to clutter the tools spreadsheet too much.

5

Hi folks – especially committee members
@JenAbels @skyleryoung @MikeThacker @sasha @switzersc – one of the main action items from the Technical Committee is to review the Technical Requirements for the validator (also included in the Validator Technical Requirements tab of our Tools spreadsheet, which references the User Stories that we have developed).

Please review before the next Technical Committee meeting (October 8th) and help us figure out:

  1. are these requirements phrased clearly and accurately?
  2. what is a MUST DO and what is SHOULD DO or merely COULD DO?
  3. is anything important missing?

We’re now getting into some nitty-gritty in which it would help to get more substantive input on some nuanced details. For example, on the requirement of “The validator should provide a JSON report which includes details of fields which have passed and failed validation,” Matt asks “Do we want to define the format of this JSON report to ensure that it contains details that we will find useful?”

Also for you to review, Matt has published a Forum post – FYI: Draft Guidance for using general-purpose validation tools with HSDS – referencing document Draft Guidance for Validating HSDS using generic tooling – which could be included in our documentation to guide people in basic validation using already-existing tools, at least during the interim as we are developing our own tools.

Also related to Validation: Should we add `$id` properties to the HSDS Schemas? describes schema ids which would help soft-coding of validation for different versions and profiles and allow schemas to be cached.

Thanks for your review! Ideally you would review by the beginning of October so that you can get us feedback to put on the agenda in advance of the meeting. Thanks!