Open ngfreiter opened 3 years ago
Then again maybe we wouldn't expect these two cases to be the same. We have already a precedent of an alias being used to represent a string value in an assignment rule. I'm not sure how we decide whether an alias should represent a string or an inline instance.
Isn't that determination made by the type it is assigned to? I.e., if it is a string-like type, assign as a string, otherwise treat as an instance. We do something kind of like that w/ concepts because foo#bar
can be a code, Coding, CodeableConcept, or Quantity units depending on what it is being assigned to.
Yeah I think that could work. But I do think that fixing this bug may then require some significant refactoring, since currently we decide if something is an instance or not in import. If we are making that decision based on the type being assigned to, we may need to change that.
Ah. I forgot that bit. So, the string use... we did that in order to support things like:
* compose.include[0].system = LNC
right? Just trying to remember the different use cases...
Well when an instance is assigned, its value is still just a string, but with the isInstance
flag set. Before the ability to assign instances, aliases would always resolve to a string, and on the import side it would be impossible to tell if those strings refer to an instance or not, so the isInstance
flag would not get set.
The following works fine:
but this does not work:
I think we would expect that these two cases should work the same.