FHIR Chat · separate input folders

Stream: shorthand

Topic: separate input folders

David Hay (Jan 07 2020 at 03:53):

It would be great if there could be a folder structure for the fsh tank. That way you could, say, separate extension definitions, profiles and instances into their own folders...

David Hay (Jan 07 2020 at 05:04):

and, perhaps, separate folders for the output as well...

Chris Moesel (Jan 07 2020 at 14:47):

I think allowing the FSH tank to have sub-folders is a great idea. We could certainly do a recursive survey of the tank to find all FSH files. Using this approach, authors could organize the FSH files however they want in the tank. Do you think that would be good? Or would it be better to force some structure by only allowing certain subfolders (e.g., "profiles", "extensions", etc.)?

Chris Moesel (Jan 07 2020 at 14:49):

As for the output, my only concern is we need to figure out how arbitrary folder names in the output affects IG generation. If we can figure out a way to make it work without messing up IG generation, then I'm game. It might not be hard, I just haven't looked into it.

BTW -- thanks for all the great feedback, @David Hay!

Jose Costa Teixeira (Jan 07 2020 at 15:03):

I think a consistent folder structure would be good. Some suggestions, mostly borrowed from the IG template:
capabilities (capstatements)
examples (resource instances)
extensions (.)
models (logical models)
operations (.)
profiles (structureDefs)
vocabulary (codesystems / valuesets)

Jose Costa Teixeira (Jan 07 2020 at 15:04):

if you keep these, it can be reused by ig template

Jose Costa Teixeira (Jan 07 2020 at 15:05):

The IG (i think) either has all resources in a "input/resources" folder or in "input/profiles, etc..."

Chris Moesel (Jan 07 2020 at 16:18):

Right. We currently just dump everything into input/resources. I think it's possible to have arbitrary folders with the template-based publishing framework too. My one concern with forcing a specific folder structure around "profiles", "extensions", etc., is that one of the advantages of FSH is that you can group related things together into the same file -- so someone might choose to put a profile and its related extensions in the same source file, in which case its not clear which sub-folder it should go in.

David Hay (Jan 07 2020 at 16:57):

Alignment with the IG template sounds like a good idea to me, though your point about allowing flexibility is valid (though, I'd err on the side of consistency if pushed).

Couple of other things:

Have you some examples of complex extensions? I'm having issues (see separate thread) and think I've followed the pattern in the spec (though that is currently down, so not sure...)
Also - have you given thought to exposing sushi functionality via a web service? I'm thinking particularly of instance generation which I do in clinFHIR though I have issues with more complex extensions and so would be interested in alternatives. Haven't thought it through at all - just wanting to gauge interest...

Chris Moesel (Jan 07 2020 at 19:03):

@David Hay -- did you see my response in the other thread about complex extensions?

As for a web service, we've thought about how this might fit into the web, but right now we're focusing on core functionality before moving it to other mediums. As a Node.js project, though, it should transfer to the web fairly easily.

David Hay (Jan 07 2020 at 19:07):

Yeah - completely appreciate that - and it is certainly a low priority...

Mark Kramer (Jan 09 2020 at 21:08):

One thing I would like to see regarding subfolders is a clean separation between the fsh files and the /build directory. Right now, the /build is created at the same level as all the fsh files. If you have an editor directed at the folder that has the fsh files, all the build files are suddenly in scope of the editor. That's inconvenient. I'm envisioning something like this: pasted image