Stream: IG creation
Topic: NPM package name
Richard Townley-O'Neill (Jul 17 2019 at 04:52):
Is there any guidance on naming FHIR NPM packages for non-HL7 implementation guides?
The best I have found is http://wiki.hl7.org/index.php?title=FHIR_NPM_Package_Spec#Package_name
Our namespace for URIs is "ns.electronichealth.net.au" which when used in to name a FHIR R4 package for event summaries gives something like "ns.electronichealth.net.au.ci.fhir.4.0.eventsummary".
Is that good practice? If not, what would be good practice?
Grahame Grieve (Jul 17 2019 at 12:55):
no. that would be wrong. I would recommend
Grahame Grieve (Jul 17 2019 at 12:55):
au.electronichealth.xxx where xxx is the package name e.g. au.electronichealth.eventsummary
Grahame Grieve (Jul 17 2019 at 12:56):
or even be shorter: au.adha.eventsummary
Jose Costa Teixeira (Dec 10 2021 at 09:17):
Are there any guidelines for package naming?
Jose Costa Teixeira (Dec 10 2021 at 09:19):
If an affiliate wants to create national packages, some issued by the federal government, should there be any structure?
Jose Costa Teixeira (Dec 10 2021 at 09:21):
if org is the organization, should the package be
fhir.be.org.package?
hl7.fhir.be.org.package?
be.fhir.org.package?
be.org.fhir.package?
...
Jose Costa Teixeira (Dec 10 2021 at 09:22):
@Jean-Michel Polfliet @Bart Decuypere
Oliver Egger (Dec 10 2021 at 09:58):
we followed the pattern that we do the inverse of the domain and then add the canonical: e.g.ig is ch-core and cannoncial is http://fhir.ch/ig/ch-core/ we call the package ch.fhir.ig.ch-core
Elliot Silver (Dec 10 2021 at 10:02):
My thought was to leave anything starting with fhir or hl7 to HL7 and affiliates. I don't know what the value of fhir in the middle of the name is; is there a chance that's it's not a fhir package? Then, like @Oliver Egger , follow approximate reverse domain name for country and organization, and the last part or two is project and package: ca.infoway.vc.ps.
Michaela Ziegler (Dec 10 2021 at 10:05):
Jose Costa Teixeira said:
Are there any guidelines for package naming?
Elliot Silver (Dec 10 2021 at 10:11):
Those guidelines are slightly confusing. "The first part...the second part..." and then an example of a 4 part name.
Grahame Grieve (Dec 10 2021 at 10:19):
hl7 will publish non-FHIR packages
Grahame Grieve (Dec 10 2021 at 10:19):
Grahame Grieve (Dec 10 2021 at 10:20):
for instance
Grahame Grieve (Dec 10 2021 at 10:20):
so the pattern for HL7 is hl7.{product}.{name} or hl7.{realm}.{product}.{name}
Grahame Grieve (Dec 10 2021 at 10:21):
if the product is published by HL7 affiliates, I prefer that the package name follow that pattern: hl7.{realm}.{product}.{name} but I recognise that some affiliates are publishing with other names, as Oliver above. And Oliver is right about the general pattern - it's safe to be guided by the domain name (in reverse)
Jose Costa Teixeira (Dec 10 2021 at 10:44):
ok, some anatomy:
ch. <-- ok, top level is country
fhir. <-- ok
ig. <-- would there be anything else besides an ig if it's FHIR ? perhaps, but what?
ch-core <-- IG's id
Jose Costa Teixeira (Dec 10 2021 at 10:45):
For discussion, how would this be?
ch. <-- ok, top level is country
fhir. <-- ok
hl7 <-- who is publishing this - can be hl7, or fgov, or...
ig. <-- would there be anything else besides an ig if it's FHIR ? perhaps, but what?
ch-core <-- IG's id
Grahame Grieve (Dec 10 2021 at 10:47):
I don't think it matters whether it's an IG or not. I use core for the {name} but no one else is going to be publishing core. And things other than IGs... I just use the name, it's not important at that level whether it's an IG, as long as I can ensure names don't clash (I can in the hl7 space)
Grahame Grieve (Dec 10 2021 at 10:48):
I think it makes sense for authority to come before the product. So ch.hl7.fhir.ch-core. (though of course hl7.ch.fhir.ch-core I like even more)
Grahame Grieve (Dec 10 2021 at 10:48):
but the key point is, whoever comes first sets the rules for what follows.
Jose Costa Teixeira (Dec 10 2021 at 10:53):
so fhir is not the type of content but the publishing org?
Grahame Grieve (Dec 10 2021 at 10:55):
it's the focus of package.
Grahame Grieve (Dec 10 2021 at 10:55):
e.g. the HL7 cda packages will actually contain FHIR resources, but the point of the package is to support cda use and implementation
Grahame Grieve (Dec 10 2021 at 10:55):
logical models and profiles etc for CDA (or CCDA, etc)
Oliver Egger (Dec 10 2021 at 11:12):
sorry for making confusion with fhir in the name, we as a hl7 swiss affiliate reservered fhir.ch and put all our implementation guides there, thats why we also included it in the package name :-)
Grahame Grieve (Dec 10 2021 at 11:14):
no confusion, and you're allowed to do that
John Moehrke (Dec 10 2021 at 12:25):
IHE has not yet touched on realm. But we are following the general with ihe.{domain}.{product}
A few historic misteps that will live forever.
I would expect to append the realm. but have not thought deeply
John Moehrke (Dec 10 2021 at 12:27):
personal projects.. I have been similarly following this pattern, mostly by accident starting with johnmoehrke.{product}
John Moehrke (Dec 13 2021 at 14:18):
so, I might have learned that the package name should be all lowercase?
Chris Moesel (Dec 13 2021 at 14:29):
Yeah. Unfortunately, non-lowercase package names have also caused some issues in tooling, as discussed here. We actually tried to make SUSHI handle it better, but it seems that our "fix" just introduced a new and different bug related to mixed-case packages (here).
John Moehrke (Dec 16 2021 at 18:53):
so, is there a declaration that package names should/shall be lowercase?
Chris Moesel (Dec 16 2021 at 20:33):
Yes. From the NPM Package Specification (emphasis mine):
Each package has a canonical name (a globally unique identifier). A package name consists of two or more namespaces separated by a dot. Each namespace starts with a lowercase alphabet character followed by zero-or-more lowercase alphanumeric characters or dashes.
Chris Moesel (Dec 16 2021 at 20:35):
I suppose it does not use the SHALL keyword, but it seems to just state it as undeniable fact.
John Moehrke (Dec 16 2021 at 21:52):
would be good to reflect this in the FHIR spec. I didn't know better, there was no mention, there was no warning. I don't use caps all the time, but I do use them with acronyms.. and that is all I did in my package names
John Moehrke (Dec 16 2021 at 21:52):
not a fan of forced lowercase
Grahame Grieve (Dec 16 2021 at 23:27):
where in the FHIR spec?
Elliot Silver (Dec 16 2021 at 23:30):
John Moehrke said:
would be good to reflect this in the FHIR spec. I didn't know better, there was no mention, there was no warning. I don't use caps all the time, but I do use them with acronyms.. and that is all I did in my package names
John Moehrke (Dec 17 2021 at 12:59):
so, what are the things I should worry about when changing from uppercase to lowercase? Is there something I need to do to invalidate the old? Is there something I need to worry about things breaking? I understand there is lots of magic tied to names, and I am doing the IHE publications.
John Moehrke (Dec 17 2021 at 14:29):
I tried a local build of my just-created and only-ci-built MHDS of yesterday. Changing the id from uppercase "IHE.ITI.MHDS" to lowercase "ihe.iti.mhds"; but now a local build gets a IG NPM exception.
Exception in thread "main" java.lang.Error: Case mismatch of file C:\Users\johnm\.fhir\packages\ihe.iti.mhds#dev: found IHE.ITI.MHDS#dev
I have deleted the user ./.fhir cache; and now it builds locally... so warning, this step is needed.
This was only an IG that had only been ci-built; not formally published.
Last updated: Apr 12 2022 at 19:14 UTC
