Stream: shorthand
Topic: Caret paths and indented text
Elliot Silver (Sep 17 2021 at 23:27):
I have a ValueSet, and I'm trying to set the narrative:
ValueSet: VsX
Title: "X Value Set"
Description: "A X value set"
* ^text.status = #additional
* ^text.div = """
<div xmlns="http://www.w3.org/1999/xhtml">
Blah. Blah. Blah.
"""
* codes from valueset http://hl7.org/fhir/ValueSet/marital-status
This works. However, originally, I tried:
* ^text
* status = #additional
and
* ^text
* ^status = #additional
but neither worked. Are they expected to?
Chris Moesel (Sep 20 2021 at 13:16):
Hi @Elliot Silver. The indent syntax is intended to be used only with primary paths (a term I just made up now, but meaning element paths for instances, profiles, resources, logicals; code paths for code systems). Value Sets don't really have any primary paths per se, so indent rules don't apply there at all.
We had thought about supporting indent rules w/ caret paths, but felt it might be more confusing in profile rules that have an element path and a caret path (for users to know which one is the context in an indented rule).
Elliot Silver (Sep 20 2021 at 16:16):
Understood.
However, the different rules in different contexts has been tripping me up lately. You can't use an extension the same way everywhere (sometimes you can use the url as the index and just supply a value, sometimes you need to explicitly specify url and value elements); indents don't work everywhere; various elements can be accessed directly in some places, but need to be caret-escaped in others. It would be useful if the syntax was more consistent, or there was more clarity about what syntax rules apply when.
Chris Moesel (Sep 20 2021 at 19:04):
Thanks for the feedback, @Elliot Silver. It's tricky trying to weigh tradeoffs between succinctness and ambiguity, striving for consistency across slightly different use cases, etc... I can probably give you a reason for each one of the things you brought up, as most were intentional decisions involving tradeoffs between one less-than-ideal thing and another less-than-ideal thing. BUT... I realize that it still doesn't help you, as a user of the language, know what to do when -- or remember the various little differences. Do you have any recommendations on how we might at least document these things better to support FSH authors?
Elliot Silver (Sep 20 2021 at 21:17):
Yeah, I can understand how we got where we got here. I think your "primary paths" idea is a good start. If the documentation could separate the objects into two classes, and say here are the rules that apply to class A, and here are the rules that apply to class B, that would be helpful. Ideally there are only two cases -- things that "natively" support element paths, and things that don't. At least then I can't claim to be surprised when I get tripped up.
Last updated: Apr 12 2022 at 19:14 UTC
