Stream: shorthand
Topic: sushi project direction question
Brian Kaney (May 21 2020 at 03:43):
I'll start by saying that I am a big fan of FSH. And of the all the work on sushi! I was observing the direction of the project, and it got me thinking. The description is "a reference implementation command-line interpreter/compiler for FHIR Shorthand (FSH)", but it seems like it's heading in a direction of increasingly wrapping the IGPublisher.
For maintainability, community adoption, and simplicity I wonder if it would make sense to have the parser/interpreter (with a JSDoc API) cleanly separate from the IGPublisher integration parts? Perhaps go even as far as two npm packages (e.g. sushi and sushi-ig) Thoughts? Is this crazy talk?
Chris Moesel (May 21 2020 at 12:33):
@Brian Kaney -- have you been listening to our private conversations? @Mark Kramer actually brought up this idea during the Connectathon. Mark and I just discussed it further yesterday. While IG components are already somewhat separated in the codebase, we do like the idea of an even cleaner separation by putting them in separate modules -- and we'll be exploring that in the coming weeks.
One of the reasons we like the idea is that we'd like to gradually move away from most of the IG stuff that SUSHI does -- but we also want our users to continue to enjoy some of the simplicity that SUSHI brings to IGs. So... our hope is that as the IG Publisher continues to improve in some of the areas where SUSHI is stronger right now, we can incrementally have SUSHI do less and less w/ IGs and rely on the IG Publisher to do those things instead. Eventually, perhaps the SUSHI IG functionality is no longer needed at all. Or perhaps it becomes more of a test-bed for new IG features or simplifications...
Last updated: Apr 12 2022 at 19:14 UTC
