FHIR Chat · SUSHI 0.12.7 · shorthand

Stream: shorthand

Topic: SUSHI 0.12.7


view this post on Zulip Chris Moesel (May 21 2020 at 22:00):

Announcing SUSHI 0.12.7 with the following enhancements and bug fixes:

  • No longer exports sparse differentials (#442)
  • Allows constraints on children of choice elements
  • Generates ids for ImplementationGuide.dependsOn (#445)
  • Considers child elements / extensions of primitives when counting cardinality (#393)
  • Reports an error when a profile declares itself as its own parent (#175)
  • Reports an error when authors attempt to add a duplicate slice name (#199)
  • Fixes issue that previously could result in slices having wrong cardinality (#450)
  • Correctly handles profiles of the Reference datatype (#451)
  • Replaces deprecated request library with current axios library (#344)
  • Fixes a typo in an error message (#417)
  • More FSH/fish puns (thanks @Benjamin Langley!)

To install or update:

npm install -g fsh-sushi

For more details, see the release notes: https://github.com/FHIR/sushi/releases/tag/v0.12.7

view this post on Zulip David Hay (May 22 2020 at 01:18):

I seem to be getting an error with inter-IG links (ie a profile defined in one IG can't be found from another). It was all working before I updated - the dependencies seem fine and the IG being 'referenced' is present in the cache. How cal I roll back to the previous version to test a bit more?

view this post on Zulip David Hay (May 22 2020 at 01:24):

My bad - I forgot that I was using the beta version that uses the yaml config file. Rolled back to that (RTFM David!) and all good...

view this post on Zulip David Hay (May 22 2020 at 01:25):

But a side effect is that I can't update sushi until the branch is merged...

view this post on Zulip Chris Moesel (May 22 2020 at 18:13):

Yeah, we plan to apply all these bug fixes to the 0.13 beta line as well -- but might not be until early next week...

view this post on Zulip David Hay (May 23 2020 at 03:29):

no worries...

view this post on Zulip David Hay (May 23 2020 at 23:22):

Actually there could be an issue - as the autobuild uses this version (and not the one that supports config.yaml), it doesn't run correctly (interestingly, one does - but not another) so exits with an error and the IG is not built. Sigh. It was all going so well... :)

view this post on Zulip David Hay (May 24 2020 at 00:54):

Fixed it by setting package.json directly...

view this post on Zulip Bob Milius (May 29 2020 at 18:29):

The IG Publisher doesn't like the id that sushi is generating. It seems the publisher doesn't like dashes in the id. In my package.json

  "dependencies": {
    "hl7.fhir.r4.core": "4.0.1",
    "hl7.fhir.uv.genomics-reporting": "1.0.0"
  },

and sushi creates this in the ImplementationGuide-xxx.json file

"dependsOn": [
    {
      "uri": "http://hl7.org/fhir/uv/genomics-reporting/ImplementationGuide/hl7.fhir.uv.genomics-reporting",
      "packageId": "hl7.fhir.uv.genomics-reporting",
      "id": "hl7_fhir_uv_genomics-reporting",
      "version": "1.0.0"
    }
  ],

which results in this error from IG Publisher

Publishing Content Failed: IG Name must be a valid token (hl7_fhir_uv_genomics-reporting) (00:11.0299)
                                                                                 (00:11.0299)
Use -? to get command line help                                                  (00:11.0299)
                                                                                 (00:11.0299)
Stack Dump (for debugging):                                                      (00:11.0299)
java.lang.Exception: IG Name must be a valid token (hl7_fhir_uv_genomics-reporting)
        at org.hl7.fhir.igtools.publisher.Publisher.loadIg(Publisher.java:2499)
        at org.hl7.fhir.igtools.publisher.Publisher.initializeFromIg(Publisher.java:1726)
        at org.hl7.fhir.igtools.publisher.Publisher.initialize(Publisher.java:1306)
        at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:682)
        at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:7310)

If I remove the dependsOn id, then no complaints from IG Publisher, except the usual warning that it has no id, and it builds ok.
Also, I change the id from "hl7_fhir_uv_genomics-reporting" to "hl7_fhir_uv_genomics_reporting" and the publisher doesn't complain.

view this post on Zulip Jose Costa Teixeira (May 29 2020 at 18:47):

what is dependsOn[].id?

view this post on Zulip Jose Costa Teixeira (May 29 2020 at 19:21):

anyway, this id is indeed checked against isToken - which only considers alphanumerics, _ [ ]
I do not know why

view this post on Zulip Bob Milius (May 29 2020 at 19:39):

Jose Costa Teixeira said:

what is dependsOn[].id?

If there is no id, then the IG Publisher gives this warning,

Dependency 'hla-reporting' has no id, so can't be referred to in markdown in the IG (00:11.0285)

view this post on Zulip Jose Costa Teixeira (May 29 2020 at 19:40):

i know, but ImplementationGuide.dependsOn does not have an id attribute

view this post on Zulip Jose Costa Teixeira (May 29 2020 at 19:42):

and if it does have an id, it is checked and indeed underscore is allowed (whereas normally in an id, underscore is not allowed, only dash)

view this post on Zulip Chris Moesel (May 29 2020 at 19:47):

ImplementationGuide.dependsOn is a BackboneElement, which is an Element, which has an id property. That id is supposed to be just a string (doc) but it seems that the publisher is a little more strict than that. SUSHI uses the packageId as the id, but replaces the . with _ since we discovered the IG Publisher does not like .. We did not realize, however, that the publisher also does not like -, so we missed that one. I think this will need to be resolved via a bug fix in SUSHI.

view this post on Zulip Lloyd McKenzie (May 29 2020 at 19:49):

Every element has an 'id' element - inherited from Element. In XML, it's sent as an attribute.

view this post on Zulip Jose Costa Teixeira (May 29 2020 at 19:49):

@Chris Moesel correct. I did follow that. apologies

view this post on Zulip Chris Moesel (May 29 2020 at 19:50):

@Lloyd McKenzie and/or @Grahame Grieve -- is there anywhere that documents what the valid characters are for ImplementationGuide.dependsOn.id? They clearly aren't every character allowed in string...

view this post on Zulip Jose Costa Teixeira (May 29 2020 at 19:50):

if it is an id, it should not have underscores

view this post on Zulip Jose Costa Teixeira (May 29 2020 at 19:50):

http://build.fhir.org/datatypes#id

view this post on Zulip Chris Moesel (May 29 2020 at 19:50):

But it's not an id. It's a string.

view this post on Zulip Jose Costa Teixeira (May 29 2020 at 19:51):

damn i can't get one straight :)

view this post on Zulip Jose Costa Teixeira (May 29 2020 at 19:51):

i was fixed on that before.

view this post on Zulip Chris Moesel (May 29 2020 at 19:51):

Well... I can see how you might assume something called id would be an id. ;-)

view this post on Zulip Grahame Grieve (May 29 2020 at 19:53):

hmm. several comments:

view this post on Zulip Grahame Grieve (May 29 2020 at 19:54):

the id element originally had an id type but then we discovered some reasons that we did not element id limited in length and allowable characters, so we changed it to string

view this post on Zulip Grahame Grieve (May 29 2020 at 19:55):

but it's still id because it functionally corresponds to xml:id and for legacy reasons

view this post on Zulip Grahame Grieve (May 29 2020 at 19:56):

We could probably document this more clearly

view this post on Zulip Chris Moesel (May 29 2020 at 19:56):

I think an invariant that specifies allowed (or disallowed) characters would be helpful.

view this post on Zulip Grahame Grieve (May 29 2020 at 19:57):

sure. you could make a task for that. It must not contain whitespace, for instance

view this post on Zulip Grahame Grieve (May 29 2020 at 19:58):

however the rule that are concerned with here specifically relates only this specific element - that is, ImplementationGuide.dependsOn.id, and it exists because of the way that this id is used.

view this post on Zulip Grahame Grieve (May 29 2020 at 19:58):

it is used in markdown, liquid, and potentially thymeleaf to refer to the IG

view this post on Zulip Chris Moesel (May 29 2020 at 19:59):

OK. We generate the id for the user right now, based on the packageId -- so if we know the blacklist of disallowed characters (that might be allowed in packageId), we can filter them out.

view this post on Zulip Grahame Grieve (May 29 2020 at 20:00):

well, right now, it's a..z, A..Z, 0..9, _, [, ]

view this post on Zulip Chris Moesel (May 29 2020 at 20:00):

It allows brackets. I would not have guessed that!

view this post on Zulip Grahame Grieve (May 29 2020 at 20:01):

looking at this now, that piece of code is repurposed from some other usage, and thinking about the usage, it should not contain [ or ] , where as - should be allowed

view this post on Zulip Grahame Grieve (May 29 2020 at 20:01):

as should .

view this post on Zulip Grahame Grieve (May 29 2020 at 20:04):

as of the next release, the allowed characters for that specific id will be a..z, A..Z, 0..9, and _-. and it must start with a..z | A..Z

view this post on Zulip Chris Moesel (May 29 2020 at 20:04):

If it's used as a variable in markdown, liquid, etc, I could see how maybe - could cause problems. Might one of those languages mistake foo-bar for an attempt to subtract bar from foo?

view this post on Zulip Grahame Grieve (May 29 2020 at 20:08):

that's a pretty good question. It could indeed, but in fact, this usage hasn't been set up, I discover, looking through the code.

view this post on Zulip Grahame Grieve (May 29 2020 at 20:09):

so for it is only in markdown, and - is ok there.

view this post on Zulip Grahame Grieve (May 29 2020 at 20:09):

There's a variety of names you could try to use that wouldn't, in fact work, either, because they are already defined

view this post on Zulip Grahame Grieve (May 29 2020 at 20:09):

and I'm not going to list them here.

view this post on Zulip Grahame Grieve (May 29 2020 at 20:11):

but I'll take - out, since sushi shouldn't auto-generate it - eventually someone will complain and you'll have a hard time changing if someone does

view this post on Zulip Grahame Grieve (May 29 2020 at 20:12):

so just a..z, A..Z, 0..9, and _. and it must start with a..z | A..Z

view this post on Zulip Grahame Grieve (May 29 2020 at 20:12):

although probably . will be a problem too...

view this post on Zulip Grahame Grieve (May 29 2020 at 20:12):

a..z, A..Z, 0..9, and _ and it must start with a..z | A..Z

view this post on Zulip Grahame Grieve (May 29 2020 at 20:13):

the other question is where this should be documented. It's a business rule in the IG publisher. So eventually, when we get around to redoing the IG Publisher documentation, in there

view this post on Zulip Chris Moesel (May 29 2020 at 20:20):

Alright. Fair enough. Thanks for working through that with me!

view this post on Zulip Jose Costa Teixeira (Jun 10 2020 at 11:15):

Grahame Grieve said:

the other question is where this should be documented. It's a business rule in the IG publisher. So eventually, when we get around to redoing the IG Publisher documentation, in there

  1. in the guidance ig
  2. as a constrain in a Profile on the ImplementationGuide resource?

view this post on Zulip Jose Costa Teixeira (Jun 10 2020 at 11:16):

and I assume that - and . are no longer to be supported?

view this post on Zulip Jose Costa Teixeira (Jun 10 2020 at 11:18):

so
http://build.fhir.org/ig/IHE/ihe-ig-template
should be renamed to
http://build.fhir.org/ig/IHE/ihe_ig_template ?

view this post on Zulip Grahame Grieve (Jun 10 2020 at 12:12):

the name of the repo doesn't matter, so far as I know

view this post on Zulip Jose Costa Teixeira (Jun 10 2020 at 12:15):

I think i was just matching it to the IG id, to have some consistency. I'll keep the repo name, and change ids.
Can you confirm that - and . will no longer be accepted in the id?

view this post on Zulip Grahame Grieve (Jun 10 2020 at 12:20):

yes confirm, but that is specifically the id of the dependency, not the other ids

view this post on Zulip Jose Costa Teixeira (Jun 10 2020 at 12:23):

ok thanks


Last updated: Apr 12 2022 at 19:14 UTC