HSDS Validator Technical Requirements

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!