CodeableReference elements have to be handled a bit carefully because they are sort of like Reference elements, but the FSH Reference keyword usually tries to make things a Reference type. This can lead to issues when a choice element has a CodeableReference type. Make separate rules for constraining the type to CodeableReference and for constraining the target profiles for CodeableReference.
When round-tripping the file in the issue, the only differences are in the ordering of properties. The starting and ending JSON are logically equal.
One thing I noticed that may or may not be in scope to do here is that OnlyRuleExtractor.process can't really handle a case where an element with type Reference or CodeableReference has both profile and targetProfile defined. As far as I know, nothing in the spec prohibits this, so that will need to be addressed.
Fixes #220 and completes task CIMPL-1100.
CodeableReference elements have to be handled a bit carefully because they are sort of like Reference elements, but the FSH Reference keyword usually tries to make things a Reference type. This can lead to issues when a choice element has a CodeableReference type. Make separate rules for constraining the type to CodeableReference and for constraining the target profiles for CodeableReference.
When round-tripping the file in the issue, the only differences are in the ordering of properties. The starting and ending JSON are logically equal.
One thing I noticed that may or may not be in scope to do here is that
OnlyRuleExtractor.process
can't really handle a case where an element with typeReference
orCodeableReference
has bothprofile
andtargetProfile
defined. As far as I know, nothing in the spec prohibits this, so that will need to be addressed.