Hi all,
As I’ve mentioned, I’ve been investigating the ORUK Validator to see how much work it would take to adapt it to general use with “vanilla” HSDS or other Profiles.
To that end, I’ve produced a short Technical Report outlining my findings and recommendations:
- Technical Report: ORUK Validator (Google Docs)
The report covers my understanding of the shape of the validator and its capabilities, as well as my recommendation.
In summary:
- You can deploy/run the back-end validation service independantly of the dashboard, and use it to validate an API feed. It’s required that the API feed is open, or otherwise you need to do some network-fu to host the validator in a location where it can access the URLs it needs to validate without any authentication
- Schemas need to be manually loaded in, so you can load in copies of the HSDS Schemas in place of the current ORUK schemas to “trick” it to validate vanilla HSDS feeds, or your own profile.
- It looks like it covers 11 out of 22 use cases from the use case spreadsheet, with some caveats.
- Purely out of pragmatism, I recommend that if we want a general purpose HSDS validator we should reimplement the validation logic as a re-usable library; as the ORUK Validator is designed to be a monolithic “application” rather than a reusable tool (not a value judgement!). This also side-steps some of the licensing issues with the ORUK Validator, and gives the community a choice to determine the tech stack based on its own needs (not that there’s anything explicitly wrong with the tech stack used in the ORUK Validator).
I aim to present some headlines from this at the next Technical Committee meeting, alongside the list of use cases not explicitly covered by the tool so that the committee and work to prioritise these remaining ones for any future validation tool development.
Cheers,
Matt