JP

This will addressed by #167 . The current behavior is also wrong though, according to the spec. That's captured in #43

This PR duplicates effort in #560, not sure if that's intended or not. The source of the xml tests in the cql-engine repo is actually the CQL specification IG here:...

So, at one point we upgraded to 11 to get to the latest LTS release and then discovered many of the institutions we were deploying at only supported 8. So...

The source for this test is actually the CQL specification repo here: https://github.com/HL7/cql/blob/master/tests/cql/CqlTypeOperatorsTest.xml If there are flaws in the test specification lets fix them in the upstream repo.

There's been some effort in this direction since this issue was opened. The data provider in the engine now has some limited ability to customize the queries based on the...

According to the CQL spec the engine should be returning null if it's unable to normalize: https://cql.hl7.org/02-authorsguide.html#quantity-operators

Most likely this will be superseded by cqframework/clinical_quality_language#1071

This is the standard way to convey version information within the Java ecosystem: [https://docs.oracle.com/javase/10/docs/specs/jar/jar.html](https://docs.oracle.com/javase/10/docs/specs/jar/jar.html) Several downstream projects are already dependent upon this behavior to detect the cql translator version used....

That's intentional. We don't currently consider how ELM generation is impacted in the `major.minor.bugfix` versions in the cql compiler so have to assume that a mismatched version is not compatible....

Ah. Actually, I interpreted your comment backwards. The code looks at the compatibility level and not the implementation version. You are right. That's incorrect.