What to do with equality/comparisons etc.

[ewoutkramer]

We have tons of comparison operations, duplicated between operations on the POCOs and on the CQL types. Can we make up our mind and implement them on one or the other?

• We can convert any primitive FHIR type to the CQL type, and the CQL type have the comparison operations
• We could assume all IScopedNode trees end in a standard FHIR POCO datatype, and then we can call the operators on those types.

[ewoutkramer]

One way of looking at it, is that the FHIR spec does not define equality and comparisons on the datatypes, it only talks about it for some very specific applications:

• When comparing a fixed/pattern value in an ElementDefinition while doing validation. The description is very unspecific and cannot be interpreted as the definition of equality for all the datatypes.
• When doing a search (see date for an example) - this is clearly specific to matching while doing a search, since it is described in terms of search token types, not FHIR datatypes.

So, the only sources for equality are those of FhirPath and CQL, which are aligned, and for which the CQL spec is the more elaborate. We have implemented those equalities in the System/Cql/FhirPath (;-)) types.

This suggests that we might not pretend to have equality/comparisons for the FHIR types themselves at all, so we should remove those (I think we have them only for dates anyway). We may still assume fixed/pattern matching is done using the corresponding IsExactly and Matches on the POCO's since those methods were written for exactly that purpose.

[ewoutkramer]

Ok, after a few hours of thinking, I think we should upgrade the type of Value for Date/Time/DateTIme to the CQL types (that's already done internally, but we couldn't change the Value prop) and ditch the operators.

Work on #2781 may influence what this means for Value/ObjectValue in general.