FHIR Chat · Bug in IGPublisher · IG creation

Stream: IG creation

Topic: Bug in IGPublisher

Jens Villadsen (Nov 27 2019 at 14:53):

@Grahame Grieve it seems there's a bug in the IGpublisher. When looking at the capabilitystatement, it looks like it removes https://www.hl7.org/fhir/stu3/capabilitystatement-definitions.html#CapabilityStatement.profile when stated in the capabilitystatement in the rendered version

Grahame Grieve (Nov 27 2019 at 22:36):

fixed next release

Jens Villadsen (Nov 27 2019 at 22:36):

thx

Jens Villadsen (Nov 27 2019 at 22:36):

when is that?

Grahame Grieve (Nov 27 2019 at 22:37):

probably sometime in the next 12 hours

Jens Villadsen (Nov 27 2019 at 22:40):

i had no idea that the capa-statemnt was subject to undergo changes when put through the IG.

Grahame Grieve (Nov 27 2019 at 22:42):

that's a version conversion issue

Jens Villadsen (Nov 27 2019 at 22:43):

makes sense - you're running on R4 internally?

Grahame Grieve (Nov 27 2019 at 22:43):

R5

Jens Villadsen (Nov 27 2019 at 23:00):

wait a minute ... the IGPub also overwrites the fhirVersion stated in all sd's (seems fair) - but also all sd.version

Jens Villadsen (Nov 27 2019 at 23:01):

is that last part really intentional?

Grahame Grieve (Nov 27 2019 at 23:04):

um. maybe. what does it overwrite it with?

Jens Villadsen (Nov 27 2019 at 23:05):

looks like 'fixed-business-version' from ig.json

Grahame Grieve (Nov 27 2019 at 23:05):

that's what it does - overwrites all the versions

Grahame Grieve (Nov 27 2019 at 23:06):

but it should overwrite the fhirVersion with the right version

Jens Villadsen (Nov 27 2019 at 23:06):

also does so

Jens Villadsen (Nov 27 2019 at 23:07):

guess I hadn't read the https://wiki.hl7.org/index.php?title=IG_Publisher_Documentation#Business_Version thoroughly

Jens Villadsen (Nov 29 2019 at 12:50):

its still a bug in v1.0.3-SNAPSHOT i think

Grahame Grieve (Nov 29 2019 at 13:09):

what is?

Jens Villadsen (Nov 29 2019 at 13:28):

Grahame Grieve it seems there's a bug in the IGpublisher. When looking at the capabilitystatement, it looks like it removes https://www.hl7.org/fhir/stu3/capabilitystatement-definitions.html#CapabilityStatement.profile when stated in the capabilitystatement in the rendered version

Grahame Grieve (Nov 29 2019 at 17:35):

should be fixed in 1.0.4

Grahame Grieve (Apr 29 2020 at 09:52):

So @Patrick Werner has found a bug in the IGPublisher that is difficult to fix. It relates to the discriminator format in spreadsheets. The format is

path@type

Though the @type is optional. @type can be @pattern, @profile, @type or @exists (which is the default). The bug is that for all except @exists, the parser chops off the last character of path. for @exists, it chops off the last 2 characters.

I could fix this, at the price of breaking anything that already works. I'm not going to fix it, since I want the spreadsheet format to go away.

Patrick Werner (Apr 29 2020 at 10:07):

fyi @Jamie Jones @Kevin Power @ Bob Milius

Lloyd McKenzie (Apr 29 2020 at 14:03):

It's supposed to be path.@type I thought

Rick Geimer (Apr 29 2020 at 15:05):

Maybe those who want the spreadsheet format to stay (not me) could band together and pull the spreadsheet parsing code out and put it into a separate utility that converts spreadsheets to resources in the folder structure recognized by the publisher?

Lloyd McKenzie (Apr 29 2020 at 15:40):

Need an import too. It's on the list, but not a small undertaking

Patrick Werner (Apr 29 2020 at 16:51):

Grahame Grieve said:

Though the @type is optional. @type can be @pattern, @profile, @type or @exists (which is the default). The bug is that for all except @exists, the parser chops off the last character of path. for @exists, it chops off the last 2 characters.

just curious: in the testcase for this issue only @pattern and @type are used. No @exists was applied. Is this a side-effect? The Creator isn't parsing one of the discriminators and sets it to @exists by default?

Grahame Grieve (Apr 29 2020 at 19:21):

just straight errors in code in the number of characters removed at the end. But actually, I think they are all out by one, hence the spurious character

Patrick Werner (Apr 30 2020 at 06:12):

Thanks to @Kevin Power who found a workaround by just adding extra dots (tried that as well, but must have made some mistake). Discriminator like this: resolve().code..@pattern,resolve()..@typewill be processed to resolve().code with pattern and resolve()with type.

Kevin Power (Apr 30 2020 at 12:52):

Actually @Patrick Werner I didn't do that. In the spreadsheet, I simply did this:
resolve().@type,resolve().code.@pattern (single dot)

The StructureDef that was generated had the discriminator defined like this:

        "id": "Observation.derivedFrom",
        "path": "Observation.derivedFrom",
        "slicing": {
          "discriminator": [
            {
              "type": "type",
              "path": "resolve()"
            },
            {
              "type": "pattern",
              "path": "resolve().code"
            }
          ],
          "rules": "open"

@Lloyd McKenzie said that he thought the dot at the end of the path was required, and it seems like that is enough to get the discriminator defined the way we were trying too? Or am I confused?

Patrick Werner (Apr 30 2020 at 15:10):

it was there with a dot before. Only difference was that it was resolve().code.@pattern,resolve().@type

Patrick Werner (Apr 30 2020 at 15:10):

but very glad it is working again

Jens Villadsen (Aug 06 2020 at 21:47):

image.png - @Grahame Grieve seen that beforer?

Jose Costa Teixeira (Aug 06 2020 at 21:56):

Did you update the publisher? doesn't look like it

Grahame Grieve (Aug 06 2020 at 22:22):

I'm going to have to wear this - it's how the change to a new deployment infrastructure breaks the old publishers

Grahame Grieve (Aug 06 2020 at 22:22):

and of course, I can't fix them

Jens Villadsen (Aug 25 2020 at 11:16):

new bug on the block:

java.lang.NullPointerException
        at org.hl7.fhir.r5.utils.FHIRPathEngine.evaluateDefinition(FHIRPathEngine.java:4842)
        at org.hl7.fhir.validation.instance.InstanceValidator.getCriteriaForDiscriminator(InstanceValidator.java:2712)
        at org.hl7.fhir.validation.instance.InstanceValidator.sliceMatches(InstanceValidator.java:3128)
        at org.hl7.fhir.validation.instance.InstanceValidator.matchSlice(InstanceValidator.java:4264)
        at org.hl7.fhir.validation.instance.InstanceValidator.assignChildren(InstanceValidator.java:4184)
        at org.hl7.fhir.validation.instance.InstanceValidator.validateElement(InstanceValidator.java:3761)
        at org.hl7.fhir.validation.instance.InstanceValidator.startInner(InstanceValidator.java:3527)
        at org.hl7.fhir.validation.instance.InstanceValidator.start(InstanceValidator.java:3425)
        at org.hl7.fhir.validation.instance.InstanceValidator.validateResource(InstanceValidator.java:4496)
        at org.hl7.fhir.validation.instance.InstanceValidator.validate(InstanceValidator.java:686)
        at org.hl7.fhir.validation.instance.InstanceValidator.validate(InstanceValidator.java:668)
        at org.hl7.fhir.igtools.publisher.Publisher.validate(Publisher.java:4668)
        at org.hl7.fhir.igtools.publisher.Publisher.validate(Publisher.java:4541)
        at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:856)
        at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:712)
        at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:7850)

@Grahame Grieve - probably because a structuredef url was incorrect

Grahame Grieve (Aug 25 2020 at 20:59):

ok fixed next release

Last updated: Apr 12 2022 at 19:14 UTC