I think we need this as we migrate UK publishers to the new structure and API which are not radically different from what we have in the UK now, but bring more international consistency. (Consultation on the UK profile is still needed before it is finalised.)
The validator and dashboard ultimately need to work for all future versions of the Standard and for different profiles. The UK has the most immediate need.
We’d welcome comments here and at the new working group meeting.
I wonder if the ORUK API Connector concept can fit into this. If I recall the idea with that was that a feed could be registered in the connector, then used by other tools such as the validator or a directory viewer app or in the future a merge/dedupe tool etc.
Thanks @devin This is the ORUK Connector. We removed it from our menus because we don’t (yet) have sufficient feeds and consuming tools that meet enough API rules for it to work in many circumstances.
The idea of the connector is to connect any API feed, such as Placecube’s Open Place Directory or TPX Impact’s Outpost to any consuming application such as the Local Government Association’s Service Finder or TPX Impact’s Scout. However, most front-end tools rely on the search filters for the /services web method being implemented so no local data storage is needed by the consuming application. That is quite rare.
Nevertheless, I think it’s work us exploring bringing back the Connector. The code is very easy to implement and configure.
So we’ve heard a lot of interest in an updated validator, and I’m going to try to accelerate the process from here.
I’m glad to hear @devin likes @MikeThacker’s proposal, and also I want to get more input from a broader swath of the community as to desired features and related design objectives.
One thing that might help me is updating this proposal to include a set of user stories that are specifically formatted in the standard way – so that we can clearly state our assumptions about who wants to do what. i.e. “As a [database administrator] I want to [take this action] in order to [receive this benefit].” Perhaps mike can help us articulate the user stories that are implicitly assumed by this proposal – and then we can do some polling to get input on which of them are the highest priority, and whether any important stories are missing.
We have some other big questions – such as whether this validator tool should be deployable code or a hosted service, and what language it should be developed in – but perhaps we’ll be better able to have those conversations by first more clearly articulating our assumptions about what the users need.