Stream: ig publishing requirements
Topic: IG resource as a build tool or deliverable?
Elliot Silver (Dec 08 2021 at 22:36):
(continued from a very short comment here)
There seems to be two viewpoints on the IG resource. On the one hand, it is used to drive the IG publisher. The IG publisher process manipulates my IG resource, and litters it with all sorts of extensions and parameters that are of no use (as far as I can tell) beyond the build. This point of view is also supported by the fact that Simplifier doesn't require an IG resource in order to create a package, and the optional one they can create only lists the narrative pages, not the resources. On the other hand, there is a point of view that the IG resource can be loaded onto a FHIR server, and used by a system at runtime, perhaps allowing you to track down all the resources that are part of an IG, etc. (Why you'd want to do that, and the value of the IG as a runtime resource isn't entirely clear to me.) Actually I suppose there is a third role, which is the IG resource as part of the package management and discovery process.
It feels to me that we should clarify and separate those uses. I can't think of any other resources that we've defined that (if we subscribe only to the first viewpoint) don't have a runtime value. If we subscribe to the second viewpoint and we expect the IG resource that I've authored to be used beyond the build process, then we shouldn't put temporary build parameters, etc. in the resource that I'm going to distribute; those should go into a separate publisher-controlled control file that only exists in the project temp directory, or similar.
Perhaps this conflation of uses was a conscious decision and I am unaware of previous discussion, but I'm more tempted to think that it is accidental.
Grahame Grieve (Dec 08 2021 at 23:03):
the use cases are separated by definition and manifest in the IG resource, and parameters seems to follow that
Elliot Silver (Dec 08 2021 at 23:04):
So, definition is used only for build, and manifest is for runtime information?
Grahame Grieve (Dec 08 2021 at 23:06):
broadly speaking, yes. The definition is preserved in the case that some consumer wants to know how it was built, but it could be deleted
Elliot Silver (Dec 08 2021 at 23:07):
Why do we have any of the build information in the resource, why not a separate resource/config file? Or if definition is used only for the build process, does it make sense for the publisher to remove it?
Elliot Silver (Dec 08 2021 at 23:08):
That seems like an edge case, and more likely to leak info about my internal processes than be useful.
Elliot Silver (Dec 08 2021 at 23:08):
oooh, a parameter to preserve the parameters :-D
Grahame Grieve (Dec 08 2021 at 23:10):
we wanted all the inputs to be able to be resources. And some pre-IG publisher systems depend on that. So that was a deliberate decision
Grahame Grieve (Dec 08 2021 at 23:10):
I wouldn't ever remove something unless I needed to for security/privacy reasons.
Elliot Silver (Dec 08 2021 at 23:11):
Do we expect anything other than the IG publisher to use the definition elements?
Grahame Grieve (Dec 08 2021 at 23:18):
I don't think I have anywhere.
Last updated: Apr 12 2022 at 19:14 UTC
