Stream: IG creation
Topic: Template approach
Lloyd McKenzie (Jun 10 2019 at 03:37):
One of the things that would be nice to do as part of the onCheck (and/or onGenerate) is the ability for the Ant process to define additional validation results. For example, one of my clients has a rule that every element in a differential must declare mustSupport. Right now, I run a check before the IGPublisher launches that just blows up if the check fails, but really this should be something that shows up in the validation results. Would it be possible to define a file (presumably JSON) that the Ant script could populate with a list of additional issues (with severity, the artifact, the location and the issue) that could then be integrated and sorted and reported as part of the final build (including being incorporated into error and warning counts, etc.)? (@Grahame Grieve )
Grahame Grieve (Jun 10 2019 at 12:13):
ok. it's a file validation.json/xml in the root of the template directory. The IGPublisher will ensure that it doesn't exist before running the script, and if it does exist afterwards, will load it. Format will be :
- an OperationOutcome in json or xml format (by file extension) in R5 format
- each issue must have a severity, a code, a details.text, and an expression (which need not be fhirpath)
Issues may also carry extensions:
- "http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source" - the filename in which the error occurs, relative to the root. If this is not present, or not matched, the error will be reported against the IG as a whole
- http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-line
- http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-col
- http://hl7.org/fhir/StructureDefinition/rendering-xhtml - an html rendering of the element, if preferred as a view
Grahame Grieve (Jun 10 2019 at 12:35):
a fatal error will terminate the publication process
Grahame Grieve (Jun 10 2019 at 19:38):
done and released
Lloyd McKenzie (Jun 11 2019 at 05:06):
Another question:
The onLoad event says the only thing you're allowed to change is the IG resource. However, this seems like the appropriate time to make changes to other source files (or at least copying a transformed version of source files to a different location that will be used as actual input). There doesn't seem to be any other event that will allow for the source artifacts to be manipulated. (Examples of potential manipulation include changing the metadata associated with the artifacts, setting defaults for things like 'mustSupport' that haven't been declared, expanding "shortcuts" embedded in descriptive text, etc.) Is there a reason to not allow changes to other files? Does it create problems with the 'continuous publication' mode (because you're not watching source files that would be 'copied')? If so, is there a way we could work around that by letting you know where to look for files that should be monitored for changes but should not be used as source?
Grahame Grieve (Jun 11 2019 at 10:27):
at least copying a transformed version of source files to a different location that will be used as actual input
Why?
Grahame Grieve (Jun 11 2019 at 10:28):
hanging the metadata associated with the artifacts, setting defaults for things like 'mustSupport' that haven't been declared, expanding "shortcuts" embedded in descriptive text
Why is this the business of the template? Why not just get the content correct?
Lloyd McKenzie (Jun 11 2019 at 15:54):
Getting the content correct may require the author to correctly set values in 100s of artifacts and/or reproduce the 'same content' in hundreds of places. Doing that in bulk is much more efficient and more likely to be accurate/consistent
Lloyd McKenzie (Jun 11 2019 at 15:55):
Is there a reason why doing this is problematic?
Lloyd McKenzie (Jun 11 2019 at 21:53):
@Grahame Grieve ?
Last updated: Apr 12 2022 at 19:14 UTC
