Stream: tooling
Topic: packages: index.json
Marten Smits (Oct 27 2021 at 15:58):
Couple of questions regarding index.json of the FHIR packages spec :
In the dotnet package tooling, we have been struggling with returning the right file when searching a package by canonicalUrl:
In this case we have a package that has dependencies to hl7.fhir.r3.core and hl7.fhir.r3.expansions.
When searching for a valueset, say: administrative-gender, we would like to return the expanded ValueSet, but there is currently no way to know based on the index.json file, both files would look exactly the same index.json.
The same goes for the theoretical case where there are dependencies to multiple packages containing the same StructureDefinition, one with a snapshot, and one without, we would always like to return the snapshot one, but there is no way to know.
Therefor I'd like to suggest to add the following fields to index.json:
hasSnapshot- a boolean stating whether a file contains a snapshot or nothasExpansion- a boolean stating wether a file is a valueset that has been expanded
When looking at the confluence page : I see each folder needs a index.json, I think it would be better if we have 1 index for the whole package, but it's probably too late for that. It also states that examples are found in a sibling folder, but looking at the existing packages, I see both sibling and child folders named example, or openapi, and other. I think the child folders are better in this case, shall I update it on the page?
Also, I don't think the current version of index.json has index-version 1 right? What's the latest version? And what does it look like? I'm willing to update the documentation myself if someone can tell me what the latest version looks like.
Grahame Grieve (Oct 28 2021 at 19:46):
i think it's a bad idea to have dependencies on both hl7.fhir.r3.core and hl7.fhir.r3.expansions. the expansions package was only published as a convenience to code generators, and shouldn't be a dependency anywhere.
Grahame Grieve (Oct 28 2021 at 19:47):
It's certainly not a replacement for a terminology service that generates expansions on request
Grahame Grieve (Oct 28 2021 at 19:48):
but if we're going to put expansion in .index.json, we should put the expansion id, since there could be more than one expansion per value set
Grahame Grieve (Oct 28 2021 at 19:48):
is there any rationale use case for having both with and without a snapshot? I can't think of any
Grahame Grieve (Oct 28 2021 at 19:49):
I agree that it's too late to have just one .index.json file for the entire package
Grahame Grieve (Oct 28 2021 at 19:51):
and please update the documentation - originally we said sibling folders, but we realised a few years ago that wasn't valid against the NPM spec, and so we had to change to child folders. I thought we updated the documentation at the time
Grahame Grieve (Oct 28 2021 at 19:51):
I don't understand the question about index-version?
Marten Smits (Oct 29 2021 at 07:09):
But we have to run the $expand operation everytime we want to access to actual codes from a ValueSet then? I don't think that's good practice at all. Packages are supposed the be frozen right? But you can get different outcomes each time you run $expand. Same would be to be running the snapshot generator each time, doesn't seem good practice either.
Marten Smits (Oct 29 2021 at 07:11):
I don't know if there is any use for having profiles with and without snapshots, but it's probably going to happen somewhere and I want to prepare for it.
Marten Smits (Oct 29 2021 at 07:11):
I'll update the documentaton about the sibling/child folders
Marten Smits (Oct 29 2021 at 07:13):
The question about index-version: What's the latest version? Is it still 1? Just like it says on the confluence page? Or have there been undocumented changes already? If so, what are they, and which version are we now on?
Grahame Grieve (Oct 29 2021 at 12:09):
But we have to run the $expand operation everytime we want to access to actual codes from a ValueSet then? I don't think that's good practice at all.
No, it's extremely necessary practice. The definition of the value set will define whether you should get different outcomes or not, and the terminology server better be reliable.
Grahame Grieve (Oct 29 2021 at 12:10):
and which one will you choose if you find multiple different expansions? How will you know which one matches the expansion conditions that you've been asked for? You need a terminology server, not to try to solve this in the packaging system
Grahame Grieve (Oct 29 2021 at 12:11):
I'm still not convinced about snapshots. Why would it be done when you can just remove the snapshot it you want one without
Grahame Grieve (Oct 29 2021 at 12:13):
index-version: still "1" - the last change we made was the addition of the supplements flag, and that didn't cause an increment in the version
Marten Smits (Oct 29 2021 at 14:22):
I totally agree that the use case of adding just profiles without snapshots. I even think that shouldn't be allowed. But then again, I can see this happening, and I want to make sure that I select the profile with the snapshot instead of the one without.
Grahame Grieve (Nov 05 2021 at 01:22):
so where are we with this? we could register ValueSet.expansion.identifier in the .index.json, but I don't think it's going to do much good. you need the parameters
Marten Smits (Nov 05 2021 at 08:19):
After reading your arguments, I think we don't need to change anything right now. We'll solve it in a different way. Thanks!
Last updated: Apr 12 2022 at 19:14 UTC
