Stream: ig publishing requirements
Topic: package names
Jose Costa Teixeira (Feb 23 2022 at 19:09):
Package name for affiliates is hl7.fhir.realm.code
What should the package name for other orgs like openHIE?
John Moehrke (Feb 23 2022 at 19:21):
i recall a discussion before where I pointed out the IHE pattern, and @Grahame Grieve said he was going to add that pattern. I guess from my experience today with go-publish that that IHE pattern is not yet in the tooling.
Jose Costa Teixeira (Feb 23 2022 at 19:21):
right. what should the pattern be? for OHIE, IHE, WHO, ?
Jose Costa Teixeira (Feb 23 2022 at 19:23):
any recommendations?
Jose Costa Teixeira (Feb 23 2022 at 19:28):
<org>.fhir.<domain>.<id> ?
John Moehrke (Feb 23 2022 at 19:51):
no all IGs will be fhir
John Moehrke (Feb 23 2022 at 19:52):
and an IG might have FHIR in it, and other standards too.
John Moehrke (Feb 23 2022 at 19:53):
not clear why the id needs to be replicated after org and domain, since id tends to already include the org and domain.
Jose Costa Teixeira (Feb 23 2022 at 19:53):
id include org and domain?
Jose Costa Teixeira (Feb 23 2022 at 19:54):
what I mean by <id>, in IHE would be mhd
John Moehrke (Feb 23 2022 at 19:54):
in ihe case. yes. our id has a pattern of "IHE".<domain>.<ig name>
Jose Costa Teixeira (Feb 23 2022 at 19:54):
ok clearer: <org>.fhir.<domain>.<code> (for the FHIR IGs)
Jens Villadsen (Feb 23 2022 at 19:55):
like: hl7.fhir.dk.core
John Moehrke (Feb 23 2022 at 19:56):
I still don't think ".fhir" should be a mandatory part of it
Jens Villadsen (Feb 23 2022 at 19:56):
it aint mandatory ... but if its a FHIR IG, it should be there
John Moehrke (Feb 23 2022 at 19:56):
Jose is showing it as mandatory
Jens Villadsen (Feb 23 2022 at 19:57):
well ... it should be mandatory for FHIR IG's
Jens Villadsen (Feb 23 2022 at 19:57):
hl7.cda.something.somethingelse should be valid for non-fhir
Jens Villadsen (Feb 23 2022 at 19:57):
but that just aint a FHIR IG
Jose Costa Teixeira (Feb 23 2022 at 19:57):
what would you have for IHE? ihe.iti.mhd? how would you distinguish the FHIR package from the non-FHIR package
Jens Villadsen (Feb 23 2022 at 19:58):
ihe.fhir.iti.mhd would be my sugggestion ... for a IHE IG based on FHIR
Elliot Silver (Feb 23 2022 at 19:58):
I’d disagree. Most organizations aren’t going to publish anything but a FHIR IG. It’s fine to omit. If your really care, the type element in package.json will tel you.
Jens Villadsen (Feb 23 2022 at 19:59):
naming is important
Jens Villadsen (Feb 23 2022 at 19:59):
you should also care
Jose Costa Teixeira (Feb 23 2022 at 20:00):
I couldn't find it before but this is a continuation of the discussion in https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/NPM.20package.20name
Jose Costa Teixeira (Feb 23 2022 at 20:03):
the current structure is hl7.fhir.<realm>.<code> - for hl7 and affiliates
Jens Villadsen (Feb 23 2022 at 20:03):
I guess that is at least something we can/should agree on
Jose Costa Teixeira (Feb 23 2022 at 20:03):
yes
Jose Costa Teixeira (Feb 23 2022 at 20:04):
I guess we can iterate from there if we need to
Jens Villadsen (Feb 23 2022 at 20:04):
now - anyone else could follow along with that naming scheme ... or invent their own to cause confusion for all others
Jens Villadsen (Feb 23 2022 at 20:04):
:grinning_face_with_smiling_eyes:
John Moehrke (Feb 23 2022 at 20:15):
Jose Costa Teixeira said:
what would you have for IHE? ihe.iti.mhd? how would you distinguish the FHIR package from the non-FHIR package
mhd is not a good example, as the name itself says it is fhir... But lets discuss an abstract model with a fhir implementation and a cda implementation. I might suggest that the abstract one would be <org>.<domain>.<name>, and the fhir one would be <org>.<domain>.<name>.fhir, and the cda one would be <org>.<domain>.<name>.cda. Putting this fhir vs cda inbetween the org and domain is not logical at all.
John Moehrke (Feb 23 2022 at 20:16):
hl7 can choose that. I don't want to impose any pattern. I don't see any reason to impose a pattern. I do see a reason to have the publisher know the patterns for the <org> using the publisher.
John Moehrke (Feb 23 2022 at 20:18):
IHE has a long standing pattern like this... with PDQ and PIX... had a pattern going with XD* but consensus agreed that MHD should break that pattern.
Jose Costa Teixeira (Feb 23 2022 at 20:23):
but the .fhir. doesn't mean the technology, it means the type of package
Jose Costa Teixeira (Feb 23 2022 at 20:27):
I don't know about the long standing pattern. Besides HL7, the official IG publications are relatively recent. If that influences our package naming convention, I think now is the time.
Grahame Grieve (Feb 23 2022 at 23:37):
ihe can choose what to do for their own packages. I have advised IHE to think ahead and consider the possibility that they'll publish npm packages for non-fhir use, but they've decided to go for simpler and just use ihe.iti.mhd. That's fine
Grahame Grieve (Feb 23 2022 at 23:38):
the IHE naming rules provider is here:
Grahame Grieve (Feb 23 2022 at 23:38):
org.hl7.fhir.igtools.publisher.utils.WebSiteLayoutRulesProviders.IHENamingRulesProvider
Grahame Grieve (Feb 23 2022 at 23:38):
// IHE case differs, but not predictably, so we can't check case.
// canonical is https://profiles.ihe.net/${domain}/${profile} - see https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/IG.20Release.20Publication.20procedure/near/268010908
Grahame Grieve (Feb 23 2022 at 23:38):
@John Moehrke is this no longer true?
John Moehrke (Feb 24 2022 at 00:09):
I have moved to lowercase all id values. but the canonical paths would still have uppercase in them. I did not understand that canonicals also had to be all lowercase
Grahame Grieve (Feb 24 2022 at 00:20):
no they don't have to be - the check is case insensitive, so I don't understand your problem - the code checks that the canonical URL is https://profiles.ihe.net/ITI/MHD (case insensitively). So what's the problem?
John Moehrke (Feb 24 2022 at 00:56):
the error says it was not "http://profiles.ihe.net/fhir/mhd" note it is looking for 'fhir', not "iti"
John Moehrke (Feb 24 2022 at 01:09):
correction
ERROR @ parameters: canonical URL of http://profiles.ihe.net/ITI/MHD does not match the required canonical of https://profiles.ihe.net/mhd/fhir (src = Publisher)
John Moehrke (Feb 24 2022 at 01:10):
so it is telling me the required canonical is ... "mhd/fhir"
Grahame Grieve (Feb 24 2022 at 02:19):
hmm what's the package id?
Jose Costa Teixeira (Feb 24 2022 at 06:31):
@John Moehrke it seems the package names don't match
ihe.ITI.MHD
or ihe.mhd.fhir?
(the first one is what is in the code and reporting to the zulip discussion; but the IHE package that is currently in MHD is the latter)
Jose Costa Teixeira (Feb 24 2022 at 06:32):
my proposal to fix:
ihe package names should be lowercase and in the format ihe.fhir.<domain>.<id>
Jose Costa Teixeira (Feb 24 2022 at 06:32):
in fact,
<org> package names should be lowercase and in the format <org>.fhir.<domain>.<id>
Grahame Grieve (Feb 24 2022 at 10:20):
I like that pattern, but IHE don't need to follow it
Jose Costa Teixeira (Feb 24 2022 at 10:26):
right, but IHE needs to have one pattern
John Moehrke (Feb 24 2022 at 11:58):
the package name can NOT have a period. They must start with an uppercase character.
John Moehrke (Feb 24 2022 at 12:00):
so it can't be the same as the id, and it can't be lowercase.
John Moehrke (Feb 24 2022 at 12:01):
id: ihe.mhd.fhir
canonical: http://profiles.ihe.net/ITI/MHD
name: IHE_MHD
John Moehrke (Feb 24 2022 at 12:10):
This id is historic, and I don't want to change it. It is close to the current IHE recommended pattern, it was lowercase from the beginning. This name is historic and I don't want to change it. It is also close to the IHE recommended pattern. IHE is changing other IGs id (PIXm, and PDQm) because of this newly declared demand that id values be all lowercase. When will these hidden rules stop? Why is the very last step of publication imposing rules that were never declared and never even warned about during QA? I don't blame, I just ask about process. Specifically process where zulip discussions are declaring that someone elses pattern is wrong.
John Moehrke (Feb 24 2022 at 12:11):
If we have these patterns we want to impose... then have them enforced from the beginning, not change over time and change at random.
Grahame Grieve (Feb 24 2022 at 12:28):
the case thing... not documenting that was an oversight on my part. Other than that... the pattern is fine.
Jose Costa Teixeira (Feb 24 2022 at 13:47):
so, on the original question (what organizations such as OpenHIE can use as a pattern):
Jose Costa Teixeira (Feb 24 2022 at 13:49):
<org>.fhir.<domain>.<id> seems robust(?)
Jose Costa Teixeira (Feb 24 2022 at 19:50):
it seems that I was confused. the IHE pattern is ihe.<domain>.<code>
the thing above, ihe.mhd.fhir is an exception, it is not the rule. So the publisher should support ihe.<domain>.<code> (as it is now, I guess)
Jose Costa Teixeira (Feb 24 2022 at 19:50):
@John Moehrke can you confirm?
Grahame Grieve (Feb 24 2022 at 19:50):
could be. But IHE might prefer <org>.<domain>.<id>.<format> so ihe.iti.mhd.fhir. I did it the other way for HL7 for organizational reasons.
John Moehrke (Feb 24 2022 at 19:51):
yes
John Moehrke (Feb 24 2022 at 19:51):
but the trailing .fhir might be optional.
Jose Costa Teixeira (Feb 24 2022 at 20:03):
I'll see how that works out with profiles that will include GS1 and FHIR for example. I don't think a suffix is needed. and I do think the .fhir. is the type of publication (i.e. not a PDF), not the format of the specification. But I will discuss that in a coming IHE call
John Moehrke (Feb 24 2022 at 20:09):
the IG publisher is not limited to FHIR specifications. I think even you are using it for logical models, and I think it is being used for CDA and v2 soon.
Grahame Grieve (Feb 24 2022 at 20:09):
not going to get a package for a pdf - the packages are inherently supporting collateral. You might have an xml package that contains schemas etc, or you might have a javascript package that has a reference implementation
Jose Costa Teixeira (Feb 24 2022 at 20:11):
I would not make a package for pdf, the point is that the .fhir. there explains that type of package it is.
Jose Costa Teixeira (Feb 24 2022 at 20:11):
but as long as we only publish that kind of package we're good.
Jose Costa Teixeira (Feb 24 2022 at 20:11):
indeed a javascript or other package is interesting - and that is not a suffix IMO
Grahame Grieve (Feb 24 2022 at 20:13):
well, say there was one for mhd, what would the package id be?
Grahame Grieve (Feb 24 2022 at 20:13):
though interesting -for fhir it would be something like hl7.fhir.us.core.js
Jose Costa Teixeira (Feb 24 2022 at 20:17):
I read this as "an hl7-issued package, with FHIR-related content, applicable to the US, called core, and with some javascript things in it"
Jose Costa Teixeira (Feb 24 2022 at 20:18):
(this is academic and subjective but I think the .js would fit best next to the FHIR than at the end)
Jose Costa Teixeira (Feb 24 2022 at 20:19):
I think I'll bring this up when we have some standards mixed in an ig
Elliot Silver (Feb 25 2022 at 01:44):
On @Jose Costa Teixeira 's original question, except for some "well-known" international organizations we should probably encourage reverse domain name for the <org> part to prevent clashes.
Last updated: Apr 12 2022 at 19:14 UTC
