Stream: IG creation
Topic: Template changes
Lloyd McKenzie (Jan 21 2020 at 21:13):
As promised at the original training, the IG template has been revamped a bit to no longer put as many parameters into the ig.ini. They have been moved to the implementation guide proper. The sample-ig has been updated to follow the new approach, so it may be easiest to just look at it. However, I'll summarize the changes here:
- license and version now go in the corresponding 'core' elements in the IG
- fhirspec gets dropped (we don't need it as a parameter anymore)
- copyrightyear becomes a parameter with code "copyrightyear"
- ballotstatus becomes a parameter with code "releaselabel"
- the various 'exclude' values become parameters with a code of the same name
Lloyd McKenzie (Jan 21 2020 at 21:13):
If you have questions, holler
Sarah Gaunt (Jan 21 2020 at 22:37):
@Lloyd McKenzie So did this _just_ change? i.e. if an IG published properly yesterday it won't publish properly today?
Is this why I'm getting this crash: http://build.fhir.org/ig/HL7/bser/branches/master/build.log
Rick Geimer (Jan 21 2020 at 22:46):
Is it possible to roll this back and schedule the roll out? Remember some folks have built this into tooling, and those tools break unexpectedly when there are surprises like this without the chance to test first. @Lloyd McKenzie
Rick Geimer (Jan 21 2020 at 22:52):
@Sean McIlvenna Please review Lloyd's message above, this will require changes to Trifolia on FHIR
Rick Geimer (Jan 21 2020 at 22:55):
@Sarah Gaunt Confirming that I am seeing the same error in other IGs using the new template.
Sarah Gaunt (Jan 21 2020 at 22:59):
Not only tooling, but we are on FMG agenda tomorrow to get publication approval for the BSeR IG. Now it doesn't even build and I'll have to spend even more time on it to get it working for tomorrow. And +1 about the testing - highly likely that it won't work for me and I'll spend the day debugging.
Jose Costa Teixeira (Jan 21 2020 at 23:05):
@Sarah Gaunt are you using the newest template?
Jose Costa Teixeira (Jan 21 2020 at 23:06):
(trying to debug, so need to make sure where this comes from)
Sarah Gaunt (Jan 21 2020 at 23:07):
Using whatever the CI build uses - not sure whether I have control over which version it uses? Or do I? If I can point to an old version, I'll use that!
Jose Costa Teixeira (Jan 21 2020 at 23:13):
you can chose the templates, but from your file structure I thought you were not using the IG publisher template. (https://github.com/HL7/ig-template-fhir or similar)
Jose Costa Teixeira (Jan 21 2020 at 23:19):
@Sarah Gaunt can you add this to your IG.xml?
Jose Costa Teixeira (Jan 21 2020 at 23:19):
<parameter> <code value="releaselabel"/> <value value="CI build"/> </parameter>
just before the </definition> at the end
Lloyd McKenzie (Jan 21 2020 at 23:23):
@Rick Geimer Yes, I can roll it back if need be. It got accelerated to allow Grahame to do some testing, but that's now done.
Lloyd McKenzie (Jan 21 2020 at 23:23):
Please let me know when you're ready for the change.
Sarah Gaunt (Jan 21 2020 at 23:23):
Yes, I can add all the parameters that Lloyd has updated, I just don't really want to at this late stage in the game. What I'd really like to do woudl be to point to the previous version of the template so that my build doesn't crash. At least just until the end of the week!
Rick Geimer (Jan 21 2020 at 23:23):
I think that would be a good idea. @Sarah Gaunt are you ready for the roll back?
Sarah Gaunt (Jan 21 2020 at 23:23):
Yes!
Jose Costa Teixeira (Jan 21 2020 at 23:23):
well if Lloyd rolls back then it's fixed
Sarah Gaunt (Jan 21 2020 at 23:24):
Hopefully not too many people made the changes already though... Wont' that then cause them to crash?
Rick Geimer (Jan 21 2020 at 23:24):
It's been 2 hours. I doubt anyone else noticed :)
Sarah Gaunt (Jan 21 2020 at 23:25):
A regular day I'd have made the changes already and forgotten about them! HA!
John Moehrke (Jan 21 2020 at 23:25):
I don't think the change broke my IG build...but I certainly have not made the changes yet.
Rick Geimer (Jan 21 2020 at 23:26):
@Sean McIlvenna Please chime in and let Lloyd know how much time you need to test. I'm guessing a day or two.
Rick Geimer (Jan 21 2020 at 23:26):
Thanks Lloyd. Much appreciated during crunch times like this.
Sarah Gaunt (Jan 21 2020 at 23:26):
MUCH appreciated!!!
Rob Hausam (Jan 21 2020 at 23:26):
For those of us who have already made the changes (in UTG and making them in SNOMED right now) can we keep them, in anticipation of them being rolled out - without needing to roll back again now?
Sarah Gaunt (Jan 21 2020 at 23:27):
See!? @Rob Hausam is on the ball...
Lloyd McKenzie (Jan 21 2020 at 23:27):
Keeping them in the IG won't hurt anything
Rob Hausam (Jan 21 2020 at 23:28):
yes, but I would prefer not to have to roll back to have to have the old parameters, too
ideally it would be best for it to work both ways, for now
Lloyd McKenzie (Jan 21 2020 at 23:29):
Rollback should now be effective
Lloyd McKenzie (Jan 21 2020 at 23:31):
@Sean McIlvenna, let me know when you're spitting stuff out into the IG in addition to the ini file. Then I can shift the template. Then you can stop spitting stuff out into the ini
Sarah Gaunt (Jan 21 2020 at 23:47):
BSeR still crashing: http://build.fhir.org/ig/HL7/bser/branches/master/build.log
@Lloyd McKenzie any ideas?
Rob Hausam (Jan 21 2020 at 23:56):
The SNOMED IG is building, but there are a lot of XML related errors similar to this:
onGenerate: Error on line 1 column 1 SXXP0003: Error reported by XML parser: Content is not allowed in prolog.
and a new untracked file: ongenerate-validation-igqa.json
Rick Geimer (Jan 22 2020 at 00:06):
Guessing the rollback was incomplete
Sarah Gaunt (Jan 22 2020 at 00:06):
Yup.
Lloyd McKenzie (Jan 22 2020 at 00:47):
Rolling back with Git isn't working as I expected it to, so I've opted to roll forward to the old version :) Try again...
Sarah Gaunt (Jan 22 2020 at 01:28):
BSeR didn't crash...
Think it's working - thanks!
Rob Hausam (Jan 22 2020 at 02:44):
The SNOMED IG looks better now. Thanks!
Rob Hausam (Jan 22 2020 at 02:54):
But it still has some weird errors like these:
== /Users/rhausam/git-repo/snomed-ig/input/snomed-ig.xml == ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[0].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[1].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[2].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[3].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[4].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[5].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[6].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[7].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[8].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[9].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[10].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[11].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[12].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[13].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[14].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[15].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[16].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve ERROR: ImplementationGuide/hl7.fhir.uv.snomed: ImplementationGuide.definition.extension[17].url: URL value 'http://hl7.org/fhir/tools/StructureDefinition/ig-parameter' does not resolve
Lloyd McKenzie (Jan 22 2020 at 02:55):
That's a validator change, not a template change
Rob Hausam (Jan 22 2020 at 02:56):
Well, I guess you're off the hook, then. :)
Lloyd McKenzie (Jan 22 2020 at 02:57):
Only kind of. The change came about from a complaint I made, so at least some of the culpability is still mine. (@Grahame Grieve may say most of it :>)
Rob Hausam (Jan 22 2020 at 03:02):
On an apparently related matter (I think), what should we do with the 'ongenerate-validation-igqa.json' that I'm now seeing show up in the root directory of the IG. Check it in, or somehow either you or I make it move or go away (hoping it's the latter)?
Lloyd McKenzie (Jan 22 2020 at 03:03):
I will make it go away
Rob Hausam (Jan 22 2020 at 03:03):
thank you!
Lloyd McKenzie (Jan 22 2020 at 03:03):
If you delete, it should stay away. Part of the new template.
Rob Hausam (Jan 22 2020 at 03:04):
ok - yes, I assumed it was
Grahame Grieve (Jan 22 2020 at 04:07):
I can't reproduce this problem
Rob Hausam (Jan 22 2020 at 04:25):
I'll try again and see if it's still the case.
Sarah Gaunt (Jan 22 2020 at 04:25):
I'm getting same errors (http://build.fhir.org/ig/HL7/bser/branches/master/qa.html#_scratch_ig-build-temp-ZYWNFQ_repo_input_bser) - they seem to have replaced some other errors we were getting before - these ones: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/Invalid.20IG.20Parameters.20generated.20by.20IG.20Publisher
Maybe just coincidence that those are gone and these have appeared...
Rob Hausam (Jan 22 2020 at 04:44):
I'm still getting those errors on the snomed-ig new-template branch with 1.0.47-SNAPSHOT.
Brett Marquard (Jan 22 2020 at 17:14):
@Lloyd McKenzie @Eric Haas Is there a roll out schedule for future? I am fuzzy on the enhancement timelines, QA, etc.
Eric Haas (Jan 22 2020 at 17:30):
I was under the impression template are still optional and draft. But @Brett Marquard bring up a good point. Need:
- a more formal roadmap
- a more formal way to update the templates since it seems to be disruptive... since now we have ig-pub updates and template updates
Lloyd McKenzie (Jan 22 2020 at 18:27):
When this next release gets pushed out, I think the key functionality will be there and working. Still need more documentation and we need to document how to migrate stuff that used Eric's framework to the template and verify that everything works. As soon as that's done, we'll presumably set timelines by which HL7 publishers will need to migrate (potentially making exceptions for Simplifier-authored IGs assuming they can publish something that's substantially similar). After that, I expect the template will continue to evolve (perhaps even radically) in terms of appearance as everyone's enhancement efforts are focused on a single approach. I'm somewhat hopeful that the inputs won't need to change too much though going forward.
Jose Costa Teixeira (Jan 22 2020 at 18:27):
We should have formal releases for both
Jose Costa Teixeira (Jan 22 2020 at 18:30):
For the ig pub and for templates. This should allow us to use any stable release we want. And if we want to use the dev version, we can also do that
Lloyd McKenzie (Jan 22 2020 at 18:31):
We have the notion of release versions for templates, but we haven't worked out how that will behave with inheritance.
Lloyd McKenzie (Jan 22 2020 at 18:32):
Also, I don't think we've incorporated support for referencing specific versions in the tools yet.
Jose Costa Teixeira (Jan 22 2020 at 18:32):
@Lloyd McKenzie I believe we may be able to lock one specific release of the template to a specific release of the publisher, right?
Lloyd McKenzie (Jan 22 2020 at 18:32):
Simple question - If there's an update to the base template, should we also need to update the HL7, FHIR and Da Vinci templates to get them to adopt the new version?
Lloyd McKenzie (Jan 22 2020 at 18:33):
"may be able to" as in - could we write code that could make that happen? Almost certainly. I just don't think it's there yet.
Jose Costa Teixeira (Jan 22 2020 at 18:37):
We could do this: when we make a n+1 release of the base template, this may propagate to the n+1 release of the HL7 template, but the n version of the HL7 template still stays on the n version of the base template
Lloyd McKenzie (Jan 22 2020 at 18:51):
Right - but that means that everyone must then update their IG to point to the correct template - so it's a bunch more maintenance effort for everyone. Presumably the expectation would be that to publish you need to always be on the latest and greatest. My preference would be that specifying version would only be done if there's a need to downgrade for some reason. Otherwise there will be a significant delay before issues with the newest template are identified.
Jose Costa Teixeira (Jan 22 2020 at 19:26):
Or everyone is on "Dev" until they need to freeze, and the freeze propagates upstream..?
Lloyd McKenzie (Jan 22 2020 at 19:27):
Not sure how freeze could propagate upstream. @Grahame Grieve may have some ideas
Eric Haas (Jan 22 2020 at 20:00):
Re:
copyrightyear becomes a parameter with code "copyrightyear"
ballotstatus becomes a parameter with code "releaselabel"
the various 'exclude' values become parameters with a code of the same name
assuming
- copyrightyear = string?
- releaselabel = set of codes or string - I am assuming codes = choice of ci|ballot|commentballot|version
- also I think need a separate parameter for ballot: #STU version of IG needed for publishing HL7 guides
- the various exclude = value should be boolean not yes/no
Eric Haas (Jan 22 2020 at 20:02):
also a parameter for changelink = e.g https://github.com/Healthedata1/IG-Template2/issues or http://hl7.org/fhir-issues for hl7 guides
Eric Haas (Jan 22 2020 at 20:05):
- hl7_ig: # 'true' if HL7 ig
here other params to consider:
showMappings: false # 'true' if want to display mappings tab'
showDefs: false # 'true' if want to display Definitions tab'
showExamples: false # 'true' if want to display Examples tab -currently no template for it'
showPsuedoJson: true # 'true' if want to display Psuedo JSON profile view'
showPsuedoXML: true # 'true' if want to display Psuedo JSON profile view'
showIntro: # 'true' if want to display Custom Introduction in profile view'
showQuickStart: # 'true' if want to display QuickStarts in profile view'
showDevView: # 'true' if only want to display summary view in profile view'
default_profile_view: 1 # choice of 0|1|2|3 for summary|differential|full|all views in profile
Lloyd McKenzie (Jan 22 2020 at 20:14):
copyright year is a string. release status is also a string
Lloyd McKenzie (Jan 22 2020 at 20:15):
Change link isn't variable for HL7 FHIR publications - it's built into the HL7 FHIR template
Eric Haas (Jan 22 2020 at 20:15):
I used this:
build: ci # choice of ci|ballot|commentballot|version
Eric Haas (Jan 22 2020 at 20:16):
which is used in title generation mostly
Lloyd McKenzie (Jan 22 2020 at 20:16):
The parameters you've listed aren't supported by the template yet - and I think some of them allow more variability than we'd want in the HL7 IGs
Lloyd McKenzie (Jan 22 2020 at 20:16):
release label is indeed used in title generation, but sometimes you want to say things like "STU release 2, 2nd ballot" or something like that - doesn't lend itself to formal coding.
Eric Haas (Jan 22 2020 at 20:18):
Even though I hate the whole stu thing, if left to string, it will lead to variability in titles which I think should be normalized for HL7
Eric Haas (Jan 22 2020 at 20:21):
In other words, I think that titles need to be nailed down...
Lloyd McKenzie (Jan 22 2020 at 20:30):
If we can come up with a value set that's agreeable for all of HL7 or even just FHIR, we could look at constraining. However, the notion is also used by non HL7 IGS and we can't standardize those. So data type needs to stay string
Eric Haas (Jan 22 2020 at 22:19):
Well ...we say we want to restrict variability ....
Lloyd McKenzie (Jan 22 2020 at 23:20):
Right - and I'm open to doing that for HL7 IGS if we can agree on a valueset. But we can't do it outside of HL7 where our ballot statuses aren't relevant?
Rick Geimer (Jan 23 2020 at 21:37):
@Lloyd McKenzie Any objection to putting a link to the new template IG Guidance documentation (http://build.fhir.org/ig/FHIR/ig-guidance/branches/master/index.html) on the Confluence IG Publisher page (https://confluence.hl7.org/pages/viewpage.action?pageId=35718627#IGPublisherDocumentation-PublishingImplementationGuides)?
Lloyd McKenzie (Jan 23 2020 at 23:35):
Nope :)
Chris Moesel (Jan 30 2020 at 00:57):
copyrightyear becomes a parameter with code "copyrightyear"
ballotstatus becomes a parameter with code "releaselabel"
Did this get rolled back out again? All of a sudden, my IGs are failing to build because these parameters aren't present. I assumed we'd get a warning before they went live again. The weird thing is, I have colleagues who build w/ the same publisher and don't seem to run into these errors (even on IGs without the params).
Also, I couldn't help but notice that those param codes aren't actually valid in R4, as parameter.code is bound to a required valueset without those codes. What's the plan for that with R4?
Grahame Grieve (Jan 30 2020 at 01:18):
we're mid-way through fixing that for R4 - they should be going into extensions in R4 now. If they're not you have an old version of the publisher
Grahame Grieve (Jan 30 2020 at 01:18):
the code that's changed is in the template, not the iG publisher
Sarah Gaunt (Jan 30 2020 at 01:23):
The new template went live about 24 hours ago now.
Kurt Allen (Jan 30 2020 at 01:30):
I spent the day getting this fixed in the Breast Radiology IG.
The c# toolkit doesn't yet support the new values. Dont know about HAPI.
I don't think you use either, so you are probably golden.
Chris Moesel (Jan 30 2020 at 01:35):
we're mid-way through fixing that for R4 - they should be going into extensions in R4 now.
So for an IG that uses the template though, the error says to put them in parameter.code and parameter.value (not extensions). So does the template expect/require that I am providing an R5 ImplementationGuide JSON even for R4 IGs? Is that the idea? Or if I use an R4 one with the extensions, the publisher will do magic to make the template happy?
Lloyd McKenzie (Jan 30 2020 at 01:58):
Yes - the expectation is that the IG will be authored in R5 regardless of what version the IG is for. (It may be that older versions with the appropriate extensions will still work, but that hasn't been tested.)
Grahame Grieve (Jan 30 2020 at 02:07):
older versions with the appropriate extensions will still work
yes they will
Mark Kramer (Jan 30 2020 at 02:07):
I'm sorry, but that's really stupid. R5 is barely in pre-release, and by definition, not a quality-assured release. Keep the tools on R4 until R5 has been fully vetted.
Chris Moesel (Jan 30 2020 at 02:19):
It seems that the publisher or the template (not sure which is responsible) is no longer finding images that we put in the pagecontent folder. Is there something special we're supposed to do now to be able to reference user-provided images from our markdown pages? This worked yesterday as far as I can remember.
Lloyd McKenzie (Jan 30 2020 at 02:20):
Images should go in the "images" folder. The content of that folder is copied directly to the output folder. Content in pageContent is pre-processed and is handled as "include" files by Jekyll
Chris Moesel (Jan 30 2020 at 02:23):
Thanks, @Lloyd McKenzie. It seems like I'm somehow missing some of these important changes that are being made and being caught unaware. Am I not plugged into the right place? Is there a better process for me to keep up?
Mark Kramer (Jan 30 2020 at 02:24):
@Lloyd McKenzie , please stop making non-backward compatible changes and dropping them on our heads without due warning, without pre-announcement, and without quality processes. It's very unfair to the community of IG authors.
Mark Kramer (Jan 30 2020 at 02:24):
I'm sorry I'm not as diplomatic as @Chris Moesel
Lloyd McKenzie (Jan 30 2020 at 02:37):
The "non-backward compatible change" in this case was a bug fix - images should never have been placed in that folder and documentation was quite clear about where images should go in the sample-ig and in the ig-guidance IG where documentation on the template is provided. What was happening with the previous template version is that everything in page content (including .md and .xml files) were being copied directly to the output folder. I'm sorry that the change caused issues for you, but those changes would need to have been made regardless. We're not currently in the middle of a publication cycle and the correction is very simple.
Kevin Mayfield (Feb 02 2020 at 09:49):
Is that this issue?
[xslt] Loading stylesheet /Users/kevinmayfield/Development/kevinmayfield/FHIR-R4-Core-IG-Prototype/template/scripts/onGenerate.genJson.xslt
IG must include a definition parameter with a code of 'releaselabel'. Value can be 'CI build' or some other status.
Lloyd McKenzie (Feb 02 2020 at 10:10):
That is one of the ramifications of the new template release, yes.
Kevin Mayfield (Feb 02 2020 at 10:10):
Resolved: The parameters are in the ImplementationGuide resource (I was trying to add them to the ig.ini)
Ward Weistra (May 15 2020 at 22:09):
@Lloyd McKenzie Validating the IG resource from the Sample-IG project in the FHIR .NET validator gives four errors: https://simplifier.net/snippet/wardweistra/13/$validate
CodeInvalid : Code 'copyrightyear' from system '' does not exist in valueset 'http://hl7.org/fhir/ValueSet/guide-parameter-code'
CodeInvalid : Code 'releaselabel' from system '' does not exist in valueset 'http://hl7.org/fhir/ValueSet/guide-parameter-code'
CodeInvalid : Code 'find-other-resources' from system '' does not exist in valueset 'http://hl7.org/fhir/ValueSet/guide-parameter-code'
CodeInvalid : Code 'path-binary' from system '' does not exist in valueset 'http://hl7.org/fhir/ValueSet/guide-parameter-code'
These parameters indeed don't seem to be allowed by the CodeSystem: https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/82122
Chris Moesel (May 15 2020 at 22:12):
I've asked this question before. I believe the answer is that technically the IG Publisher now runs off the R5 ImplementationGuide (regardless of the FHIR version of your IG). In the R5 IG, parameter.code is no longer bound to any valueset. So when we use an R4 ImplementationGuide, the publisher actually translates it to R5.
Grahame Grieve (May 15 2020 at 22:13):
umm. I believe that the r4 ig is correct. Which IG resource are we talking about?
Chris Moesel (May 15 2020 at 22:16):
I think he's referring to these parameters -- which according to R4 ImplementationGuide resource are invalid because they aren't in the required GuideParameterCode value set:
<parameter>
<code value="copyrightyear"/>
<value value="2019+"/>
</parameter>
<!-- releaselabel should be the ballot status for HL7-published IGs. -->
<parameter>
<code value="releaselabel"/>
<value value="CI Build"/>
</parameter>
https://github.com/FHIR/sample-ig/blob/master/input/myig.xml#L113-L121
Grahame Grieve (May 15 2020 at 22:25):
they are not supposed to appear like that in the R4 output
Chris Moesel (May 15 2020 at 22:36):
I suspect that @Ward Weistra was validating against the input ImplementationGuide resource, assuming that it was R4. There is a little comment hidden in the middle of the file (above fhirVersion) that says this though:
<!-- This is whatever FHIR version(s) the IG artifacts are targeting (not the version of this file, which should always be 'current release') -->
I just ran the publisher on the sample-ig and confirmed that the R4 version of ImplementationGuide that it produces (i.e., the output one, not the input one) does not have those values in parameters anymore (it moves them to extensions under definition).
Ward Weistra (May 15 2020 at 22:39):
@Chris Moesel You are correct. I was just trying to find that output one.
Ward Weistra (May 15 2020 at 22:42):
So, it's just the input IG resource that is already at R5, following the current release.
Chris Moesel (May 15 2020 at 22:43):
I think that if you want to use a valid R4 ImplementationGuide as your input IG, you can. You just need to use those extensions for the parameters that aren't supported. But it may be easier just to use current build as long as its structure remains somewhat stable. (Although I might be wrong about this -- so may be worth double-checking).
Chris Moesel (May 15 2020 at 22:45):
SUSHI may actually be doing some of this wrong -- in that I think we were looking at the R4 ImplementationGuide structure when we wrote the code that exports the ImplementationGuide (even though we use those technically invalid parameter names for R4). I guess as long as the structure of IG didn't change too much from R4 to current (R5) we're probably OK. But I should definitely check!
Grahame Grieve (May 15 2020 at 22:48):
the input IG loader will accept the parameters in either place - the parameters, or the conformant location. For R3 IG, you must use extensions liberally.
Chris Moesel (May 15 2020 at 22:53):
BTW -- just checked and it doesn't look like there are any structural changes in ImplementationGuide from R4 to R5 (yet). Phew!
Last updated: Apr 12 2022 at 19:14 UTC
