Stream: mapping-framework
Topic: Implicit casts in the mapping language
Ewout Kramer (Aug 13 2019 at 09:09):
During yesterday's FHIR-I call, we discussed issue GF#22774 (Document support for implicit casts in mapping language), which basically asks us to be explicit about what happens in mapping language statements like these
tgt.active = true
tgt.url = 'http://bla.org'
Although these assignments look obvious (which is why we would love to keep them this way), they implicitly require a cast from a "system" primitive (a bool and a string here) and some datatype in the target model (here FHIR string and FHIR uri). It's not obvious from the current documentation which casts are allowed (could you assign an integer value to a decimal for example?) and how the engine could ask the target model to 'execute' these casts .
The current documentation suggests that the engine can ask the model to create an instance of any target type, but it would need more knowledge about the model to know that it represents a primitive value. It may then assume the target instance has a "value" that it can assign the primitive to. As I stated before, the alternative is that the target model itself runs the casts, which would require some kind of "instantiate and initialize" callback into the target model, passing in the primitive value.
For now, my mapping engine requires you to explicitly call a constructor function like so:
tgt.active = bool(true)
tgt.url = uri('http://bla.org')
which assumes the target model installs these custom extension functions into the language. I really don't like it, so I am interested to discuss better approaches.
Bryn Rhodes (Aug 13 2019 at 17:22):
In CQL we support model-defined implicit conversions, so that we can say tgt.url = 'http://bla.org'. In the CQL case, that's an expression, so what's happening is the tgt.url is being implicitly converted to a string, so it's equivalent to saying tgt.url.value = 'http://bla.org'. It requires context for the compiler to be able to infer the appropriate conversion, so there are cases where it doesn't apply (e.g. in a sort clause) but in general it works quite well.
Grahame Grieve (Aug 15 2019 at 02:06):
so I think that we should be explicit that in FHIRPath, assignments are allowed that involve implicit conversions between types, and that it's the underlying type definitions that define what type conversions are possible.
Then, in FHIR, we'll have to figure out how to document what type conversions are possible, and how they work
Ewout Kramer (Aug 19 2019 at 08:46):
Internally in the .NET FHIR API I am introducing the difference between "FHIR.string" and "System.String", which was implicit so far. I would be helpful if we could tag the 'value' attributes in the definitions of the FHIR primitives so it mentions "System.String".
Grahame Grieve (Aug 19 2019 at 09:46):
see the discussion on the #conformance channel right now
Brian Kaney (Aug 20 2019 at 15:57):
Hi @Ewout Kramer -- Maybe I am missing something obvious, but the grammar defines several types for literals (integer, number, string, datetime, time, bool). In my experimentation, I rely on the parser and use the appropriate type coercion in my engine's implementation language. So if the parser tells me the literal is a kind of BOOL, I don't think I need more explicit instructions... Currently there doesn't seem to be a literal for URI data type defined in the grammar.
Ewout Kramer (Aug 20 2019 at 16:06):
You do need more information, since it is at present unknown how to get from a BOOL (which is of type System.Bool) to a FHIR Bool instance (of type FHIR.bool) - unless all your models target FHIR, in which case you can hard-wire these conversions. E.g. if the target is V2, what would the assignment do?
Brian Kaney (Aug 20 2019 at 16:09):
I see, I am thinking all FHIR atm.
Last updated: Apr 12 2022 at 19:14 UTC
