Stream: IG creation
Topic: IG Registry
Grahame Grieve (Apr 04 2018 at 01:06):
fhir.org has a registry here: http://www.fhir.org/guides/registry
This has been hard to maintain, so we're moving to a new system. If you want to register a published IG, make a pull request to here: https://github.com/FHIR/ig-registry (well, specifically, on this file: https://github.com/FHIR/ig-registry/blob/master/fhir-ig-list.json). I will change http://www.fhir.org/guides/registry to load off this IG registry soon
Rob Hausam (Apr 04 2018 at 13:53):
So is this for published IGs, not balloted ones? Or both?
Chris Moesel (Apr 04 2018 at 14:03):
I see our US Breast Cancer IG in the registry and this is our very first ballot ever -- so it looks like it's intended to contain balloted IGs as well.
Rob Hausam (Apr 04 2018 at 14:12):
Yes, our International Patient Summary IG is supposed to be there as it's also listed (unfortunately, the links are broken at the moment), so I guess that does answer the question.
Grahame Grieve (Apr 04 2018 at 20:00):
yes balloted as well. and also for anyone else - not just HL7 balloted IGs
John Moehrke (Apr 04 2018 at 21:40):
IHE is adding their IGs (IHE Profiles) to the Registry as they produce conformance resources. This is about 50% at this time. Mostly the ITI domain.
Grahame Grieve (Apr 04 2018 at 21:43):
note that there's 2 different registries
- registry.fhir.org - contains the conformance resources
- fhir.org/guides/registry - a list of all published IGs - where they are found
Grahame Grieve (Apr 04 2018 at 21:44):
there's no IHE IGs on the second, and they should be there - all of them
Eric Haas (Apr 09 2018 at 19:00):
I want to change the links for the IG CI Build to GitHub Pages instead of the autobuilder output. is that going to be an issue? Also who is the reviewer and merger just GG?
Eric Haas (Apr 09 2018 at 19:06):
also can we list non-published ( draft ) IG's as well, like argonaut questionnaire and clin notes?
Grahame Grieve (Apr 09 2018 at 19:12):
yes you can list draft IGs. The reviewer mergers are me, Josh, Lloyd, and I invited you too....
Grahame Grieve (Apr 09 2018 at 19:13):
you'll have to explain the idea of linking to github pages instead of the autobuilder - why?
Eric Haas (Apr 09 2018 at 19:52):
I) Its easier for me to run all igs off a standard local static framework ( common set of includes and templates) and than to have to maintain multiple copies of these files for each ig. Therefore, my repository need only contain only the source files ( profiles, pages, examples) and a docs folder for the output and use GitHub to publish. Autobuild needs all the files.
2) Separates the draft IG from latest IG-pub generated issues or changes. ( especially if the IG is couple of generations behind like US-Core or Argonaut.
Eric Haas (Apr 09 2018 at 19:54):
3) other may prefer be comfortable working in their own sandbox for development than using autobuild too.
Lloyd McKenzie (Apr 09 2018 at 20:56):
My concern with not using the autobuild is how we'd be able to tell that the committed source was sufficiently complete to publish the IG. We don't want a situation where some essential piece is sitting on someone's hard-drive. Everything necessary to produce the publication needs to be in source control and available for inspection.
Eric Haas (Apr 09 2018 at 21:07):
why? The CI is not there primarily to publish the ig locally or to inspect the build architecture its for inspection of the use case content.
Eric Haas (Apr 09 2018 at 21:08):
Those are separate things in my mind.
Lloyd McKenzie (Apr 09 2018 at 21:17):
The CI is a pretty sure-fire way to ensure that all the source is present. If it builds, then everything needed must be there. I'm not sure what automated mechanism we could put in place that would determine the same thing if we just committed the generated IG.
Eric Haas (Apr 09 2018 at 22:13):
I'm not suggesting that the published content not use the autobuilder. But I think it should be up to the editor how they want to publish the developmental content. Eventually to publish they will have to supply everything, but is it needed out of the gate?
Lloyd McKenzie (Apr 09 2018 at 22:31):
I understand the challenge with #1, but I'd rather come up with a way to share the framework across multiple IGs - perhaps by having the build synch with a common source than to simply not check the CI build source in. I don't really understand #2 - are you maintaining multiple forks? As for #3, it's up to the maintainer when they choose to commit. If they're committing the published content, I don't see a downside to committing the source too.
Eric Haas (Apr 09 2018 at 23:09):
Re #1 using submodules in GitHUb is one way but it is a pain and the autopublisher doesn't work with them.
Eric Haas (Apr 09 2018 at 23:11):
re #3 if you are sharing your work why not have frequent commits? Git pages make that pretty painless as long as your local build works. And there is no dependency on the latest version of ig-pub
Eric Haas (Apr 09 2018 at 23:14):
#2 for things like US-Core and Argonuat. They may not work with the latest IG-pub but you can share updates to content with an earlier ig-pub with your community while delaying the pain of updating to the lated version til you are ready to publish.
Lloyd McKenzie (Apr 09 2018 at 23:51):
For #1, I was thinking about the build automatically grabbing the infrastructure from somewhere else. I can do that with Ant, though I'm not sure the autobuild supports that yet.
For #2 & 3, so the issue is that you don't want to be forced to upgrade to the most recent IG Publisher. I agree that can be a pain on occasion, though (hopefully?), the periods of pain will end soon? I'm not sure that that's worthgiving up the CI builds. I know Grahame has had considerable issues with publishing IGs that didn't use the CI Build process.
Eric Haas (Apr 10 2018 at 01:56):
I support using the autopublisher as a prerequisite to publishing.
Grahame Grieve (Apr 10 2018 at 07:25):
what I don't understand is how git hub pages do anything other than narrative.
Grahame Grieve (Apr 10 2018 at 07:25):
if the auto-builder starts supporting submodules, would that stop them being a pain?
Eric Haas (Apr 10 2018 at 10:47):
github submodules are a pain without the autobuild too (for me anyway) they require a lot more care and feeding.
Eric Haas (Apr 10 2018 at 10:50):
Git hub pages show the entire published IG as a static site and is updated everytime I commit. That is what I want to share most of the time. I don't think most of the collaborators are interested in the build logs and errors. This may not work for very large IGs. But I've found it handy.
Grahame Grieve (Apr 10 2018 at 10:51):
I'm not understanding this. the markdown, sure. But what about all the generated content?
Eric Haas (Apr 10 2018 at 10:56):
Here is the Scheduling IG on GitHub pages and I can download the validation files as look at the qa content and all the other stuff I normally want to. I'm not sure what is missing.
Grahame Grieve (Apr 10 2018 at 10:58):
I didn't say anything was missing. I'm just trying to understand what you're doing and why it's offering you some advantages. RIght now, I'm not understanding what you're doing, let alone why it's better
Grahame Grieve (Apr 10 2018 at 10:59):
you're commiting the source of your implementation guide to github, and somehow it's building it?
Eric Haas (Apr 10 2018 at 16:20):
no is completely static - I commit the entire output to the docs folder in master. Its easier not to have to worry autobuilder generated errors or depend on them (e/g/ when the term server is down) or because I'm behind on the latest Ig-pub or working on an IG months or years lated or doing some custom hack that will break the autobuilder. I'm not suggested bypassing the autobuilder for published the final releases but essentially delaying the pitfalls associated with that.
Lloyd McKenzie (Apr 10 2018 at 17:03):
So you want to build with an old version of the IG publisher. I don't think that protects you from terminology issues. In fact, it probably creates some unless you're building with terminology disabled, as the old IG publisher versions won't run with the new terminology server.
Grahame Grieve (Apr 10 2018 at 21:56):
you commit the output... wooah. well, you can do that, I guess. It sounds like a bad workflow to me though we could take about what kind of things you do that result in the IG not even succeeding. Not sure why "working on an IG months or years late" is something that calls for this or what "doing some custom hack that will break the autobuilder" means
Eric Haas (Apr 11 2018 at 01:20):
I run the ig-pub with the term off a lot. (It speeds thing up and isolates problems ) Commiting output works well when the igs are small. When you pick op an IG months later it typically won't build out of the box. I'm also refactoring a lot of old igs to make them simpler and easier to manage. Things that break the build include using a separate path for the framework
filwa and committing only the source files like here .
Eric Haas (Apr 11 2018 at 01:21):
but if you all think its a bad idea I won't protest - but I won't be updating the CI build frequently either.
Grahame Grieve (Apr 11 2018 at 04:30):
so thinking about this... you'd have to have the framework in another github repository, yes? Would we want to the auto-publish to fire for all the guides that depend on it if it's changed?
Lloyd McKenzie (Apr 11 2018 at 05:49):
That would be nice
Grahame Grieve (Apr 11 2018 at 05:50):
but it seems inherently hard....
Grahame Grieve (Apr 11 2018 at 05:51):
anyway, the primary issue with this relates to what is the big unsolved issue for IG publication for me: managing dependency resolution
Lloyd McKenzie (Apr 11 2018 at 14:02):
Regenning dependent repositories isn't critical - especially with that nice UI that lets you force the regen of a bunch just by clicking on some buttons
Grahame Grieve (Apr 12 2018 at 15:22):
thinking about this... I want to move where we are on this. I want to introduce the idea of a template. and move all the jekyll structural templating stuff to a seperate repository. This way, your Ig would only contain the resources and the narratives (markdown or xhtml) and the structure would come from a separate repository that could be shared between IGs. And we would define one or a few standard templates for HL7 workgroups to use (feedback from consumers is that they want more structural consistency).
Eric Haas (Apr 12 2018 at 15:47):
I nominate IG-Template2 and its file tree as a starting point. I think I could combine the mapping, and definitions template into the sd template too.
Eric Haas (Apr 12 2018 at 15:51):
And need a tool to create the ig.json and ig.xml files which I guess will soon be combined - because that is a source of a lot of the pain.
Lloyd McKenzie (Apr 12 2018 at 16:50):
I think we should work to integate that with what I've done for the SDC projects, genomics, etc. I definitely want to preserve the ability to author with XHTML and be able to validate the source files.
Grahame Grieve (Apr 13 2018 at 11:10):
you can hash out the choice of template question with Eric etc. And the ability to author with xhtml is unrelated to this
Jose Costa Teixeira (Apr 13 2018 at 13:06):
I started from the SDC and i find that we do need editing tools/frontends for most of the input files.
My current dream state is a sort of "IG editing Desktop" - an IDE for non-nerds.
Last updated: Apr 12 2022 at 19:14 UTC
