Stream: implementers
Topic: validiating to IGs
Eric Haas (Jan 08 2017 at 23:52):
I am still not clear on how and when to use all the artifacts produced by the ig publisher. As discussed here and other places there is a validation.pack and I have used that to validate individual resources like this. ( using bash script variables )
java -jar /Users/ehaas/Downloads/validator/org.hl7.fhir.validator.jar ${fs} -defn /Users/ehaas/Downloads/igpack.zip -ig "${path}"/output/validator.pack
There are also definition files: definitions.xml.zip and definitions.json.zip are they used for resource validation or only when your guide depends on another IG? Is validator.pack needed for this as well?
Also the IG publisher can be used in "validation mode" (my words) If I add instances to the IG and run it, 0 will do the same validation on those instances as the jar file above? For some reason the CLI tool takes longer than running the IG publlsher so I am considering this as another validation option.
Grahame Grieve (Jan 09 2017 at 00:40):
the validator produces (or may produce) several different zip files. The most significant is "validator.pack". This is a zip file that contains all the conformance & example resources, a version marker, and a json file that lists all the pages and urls in the ig itself. This file is used:
- by the vaidator if you refer to the IG directly by it's canonical URL
- by the IG publisher if you declare that one IG depends on another
- by my server, if you add the IG to server load list
Grahame Grieve (Jan 09 2017 at 00:42):
in addition, the IG publisher will generate definitions.[fmt].zip (unless instructed not to) - these may be useful for other tools that have format specific requirements, and must have json, xml., or ttl inputs. None of the tools that I work on will use them
Eric Haas (Jan 09 2017 at 01:51):
Thanks for that clarification. mind if I add that to the IG publisher documentation?
Grahame Grieve (Jan 09 2017 at 02:00):
sure, good idea
Mario Hyland (Jan 09 2017 at 20:08):
Any ideas on approaches to Testing IG's - or testing implementations and there after information exchanges against published IG's? Is it fair to comment that the validator can not assure the IG / Profile is/are being adhered to during normal workflow operations (beyond the basic structure/schematron) - would we improve the efforts by having an initial base level of associated test(s)? With advanced testing as a follow on later? Thoughts and feedback welcomed -
Last updated: Apr 12 2022 at 19:14 UTC
