Stream: committers
Topic: Announcement: new validation website available
Grahame Grieve (May 04 2021 at 20:29):
@Mark Iantorno has been working hard on making the validator more available for FHIR implementers.
The jar now includes a GUI mode, and also can run as a local web server. The web server also runs in public at http://validator.fhir.org
Please feel free to start testing this - it's basically in beta mode, and then I'll make a general announcement for everyone
Mark Iantorno (May 04 2021 at 20:35):
Please, please, please, if you find an issue or bug, log it here -> https://github.com/hapifhir/org.hl7.fhir.validator-wrapper/issues
Mark Iantorno (May 04 2021 at 20:35):
It's great to get feedback, and it helps me iterate on the site
Mark Iantorno (May 04 2021 at 20:38):
Also, the above url is not resolving, please use https://fhirvalidator.org/ or https://fhirvalidator.com/ in the meantime
Mark Iantorno (May 04 2021 at 20:38):
@Grahame Grieve
Grahame Grieve (May 05 2021 at 03:09):
why is validator.fhir.org not resolving?
Mark Iantorno (May 05 2021 at 12:33):
I am unsure. Let me check today. What IP address is it pointing at?
Jens Villadsen (May 05 2021 at 17:38):
Where would you prefer feature requests? Github or here?
Mark Iantorno (May 05 2021 at 18:23):
Github
Mark Iantorno (May 05 2021 at 18:23):
Please open an issue
Mark Iantorno (May 05 2021 at 18:26):
..and assign to me
Grahame Grieve (May 05 2021 at 20:19):
@Mark Iantorno validator.fhir.org -> 34.67.71.191
Jens Villadsen (May 06 2021 at 21:14):
Mark Iantorno said:
..and assign to me
Assigning is something only you can do
Ward Weistra (May 26 2021 at 12:45):
@Mark Iantorno The fhirvalidator.org seems to get the IGs to validate against (under Options) from the the IG registry. It seems to work for US Core, but not for the German Basisprofil or the Nictiz Basisgegevensset Zorg. Have you considered using the packages from the FHIR Package Registry instead?
Some smaller issues I found:
- Couldn't paste XML text, gives me an error that it's invalid JSON. Does work when uploading an XML file.
- Selecting the Nictiz IG (under FHIR version 3.0.2) and then pasting any resource gives
Cannot parse entered text as valid JSON/XML.. Even on entered text that previously could be parsed. - The text under Options > Show Times (showTimes) seems to be be duplicated with the text under Options > Extensible Binding Warnings (noExtensibleBindingWarnings)
Mark Iantorno (May 26 2021 at 12:46):
This is good feedback, I will make those changes to fix
Mark Iantorno (May 26 2021 at 12:46):
Thanks
Grahame Grieve (May 26 2021 at 12:50):
Have you considered using the packages from the FHIR Package Registry instead?
There's still too many ridiculous packages in the FHIR Package registry. Why are those packages you refer to not in the IG registry?
Ward Weistra (May 26 2021 at 13:02):
@Grahame Grieve I guess you could maintain the IG Registry as a list on top of the package registry with which FHIR Packages/IGs are manually vetted and thus you want to show them in a suggestions/drop down list? (If people would also start adding package names to that listing)
But there are loads of quality IGs that are not listed in the IG registry. And the IG Registry also has many IGs in there which only have a link to the human readable IG (e.g., http://wiki.ihe.net/index.php/Non-patient_File_Sharing_(NPFS)) which currently breaks the validator and gives it no way to find the computable resources.
Grahame Grieve (May 26 2021 at 13:04):
hmm. interesting point about the non computable ones. But the IG registry has more metadata than the package registry. And all IGs should be listed in the IG registry
Ward Weistra (May 26 2021 at 13:06):
The metadata we can start to put into the package.json and expose. I think it largely already is, e.g., https://registry.fhir.org/package/hl7.fhir.us.davinci-pdex%7C1.0.0
Grahame Grieve (May 26 2021 at 13:07):
yes, some of it. but not all of it.
Ward Weistra (May 26 2021 at 13:10):
OK, the rest we can add to the package.json?
I think the package registry will be the new IG registry, but without the burden of a separate list maintained somewhere. But we will need to start letting the best ones rise to the top based on quality/popularity metrics. Until we have that in place, keeping a manual list (based on the IG registry?) of which ones you think are good enough to recommend could be an interim solution.
Grahame Grieve (May 26 2021 at 13:24):
well, I don't think we want to add that to package.json. It's certainly a lot of additions, and we've generally tried not to make them. Also, packages are version specific and the IG has metadata at the IG level, rather than the versions.
Grahame Grieve (May 26 2021 at 13:26):
I am wondering, @Mark Iantorno whether we merge the lists - anything in the IG registry that doesn't have a package gets dropped and then the list is all the listed IGs, and then any other IGs after.
Except, @Ward Weistra there are packages that are not something you can validate against, and no way to know without looking in the actual package
Mark Iantorno (May 26 2021 at 13:26):
I can write a quick test to see what that would look like?
Grahame Grieve (May 26 2021 at 13:28):
sure
Mark Iantorno (May 26 2021 at 13:31):
ward, I may need to ask you a couple questions
Mark Iantorno (May 26 2021 at 13:31):
at some point
Mark Iantorno (May 26 2021 at 13:31):
I have to fix a shex issue now
Grahame Grieve (May 26 2021 at 13:32):
ok
Ward Weistra (May 26 2021 at 14:36):
Grahame Grieve said:
Except, Ward Weistra there are packages that are not something you can validate against, and no way to know without looking in the actual package
What packages would those be? Technically there could (perhaps) be packages with nothing in them, but even that shouldn't break anything for the user, right?
The metadata on package name-level instead of package version-level is tricky, but in general we're then just taking the general data from the latest package version.
Looking at the IG registry I don't see a lot of extra info that isn't in packages? Title, description, author, versions and FHIR versions are already there. Just category then?
Ward Weistra (May 26 2021 at 14:40):
Mark Iantorno said:
ward, I may need to ask you a couple questions
Anytime! The docs for the FHIR Package API are here: https://docs.fire.ly/projects/Simplifier/api.html#package-server-api. Also a link to Swagger version there.
Grahame Grieve (May 26 2021 at 15:37):
This fragment:
"name": "US Core",
"category": "National Base",
"npm-name": "hl7.fhir.us.core",
"description": "Base US national implementation guide",
"authority": "HL7",
"country": "us",
"language": [
"en"
],
"history": "http://hl7.org/fhir/us/core/history.html",
"canonical": "http://hl7.org/fhir/us/core",
"ci-build": "http://build.fhir.org/ig/HL7/US-Core",
"editions": [
{
"name": "STU3",
"ig-version": "3.2.0",
"package": "hl7.fhir.us.core#3.2.0",
"fhir-version": [
"4.0.1"
],
"url": "http://hl7.org/fhir/us/core/2021Jan"
},
Grahame Grieve (May 26 2021 at 15:38):
I believe that you won't find these in the package.json:
categort
description
authority
country
language
history
ci-build
editions.name
Ward Weistra (May 27 2021 at 07:48):
@Grahame Grieve
- category, language, ci-build: Not there. Can be added as an optional item if important.
- description: description
- authority: author
- country: We were going to add jurisdiction already. Have you gotten around to adding this to your feed?
- history: This could link to the package page, which shows all versions of the package and the linked IGs.
- editions.name: All the editions are analogous to package versions. I agree they don't have a human readable version description, but we do have package versions and release notes per version.
Grahame Grieve (Jun 03 2021 at 00:44):
so these are not the same, and I've been thinking about this for a little while, and I think that we shouldn't mix the purposes - I'm ok with it being built manually
Last updated: Apr 12 2022 at 19:14 UTC
