Allow same libraries with different versions to resolve

[csenn]

Hey, thanks again for this library, it's been a great Java learning experience going through this source.

I am working on a project that uses namespaces. When trying to resolve different versions of the same library there is a conflict in the LibraryManager class. Here is an example:

// First Library
library name_space_one.LibraryOne version '0.0.1'
include name_space_two.LibraryTwo version '0.0.1'
include name_space_three.LibraryThree version '0.0.1'

// Second Library
library name_space_two.LibraryTwo version '0.0.1'
include name_space_three.LibraryThree version '1.1.1'

// Third Library 
library name_space_three.LibraryThree version '0.0.1'
define "My Def": 1 + 2

// Third Library - Later Version
library name_space_three.LibraryThree version '1.1.1'
define "My Def": 11 + 22

The issue is that name_space_three.LibraryThree is included in 2 separate namespaces, but with different versions. Then if LibraryOne uses LibraryTwo, there is a run time error.

When dealing with a group of libraries in a single namespace, there probably should not be a case where two libraries use a different version of a library. But let's say there is a namespace that has some utility functions that many other libraries use. In that case it's possible that two namespaces will both use the same utility library, but different versions of it. And then if one of those libraries requires the other, there will be two different versions of the same library in the resolution stack.

Here is a PR that seems to fix the issue in my wrapper around the CQL to ELM translation service. Does this solution make sense? Would this be useful to anyone else, or is this not a common use case?

[JPercival]

Hi @csenn!

The CQL specification currently prohibits referencing more than one version of a given Library:

https://cql.hl7.org/03-developersguide.html#libraries-1

(the relevant text is near the end of that section)

Discussion about the CQL specification happens in HL7 FHIR Workgroups periodically, and on the FHIR Zulip in the #cql channel. Here's a link:

https://chat.fhir.org/#streams/179220/cql

Feel free to raise questions or suggest changes to the CQL spec on that channel.

[csenn]

Hey @JPercival, there it is in the docs ha. I appreciate the pointer and the workgroups. I'll bring it up sometime, I wonder if it would be a useful feature to anyone else.

[cmoesel]

I've actually said before that I think it would be a useful feature -- and one that seems like it could be fairly easily supported. But... I think the primary question is if it's useful enough to justify the complication it might introduce for implementers. Even if it seems technically easy to me (and my CQL implementations), maybe it isn't in some systems -- and there definitely is extra cognitive load in trying to mentally keep track of multiple versions of the same library in a single CQL entrypoint (or even callstack).

[csenn]

Definitely makes sense @cmoesel. Our need mostly arises from the use of namespaces, where different namespaces have different owners and it would not make sense to force all CQL Libraries in the execution stack to point to the exact same version of say a utility library.

The choice to not deal with circular dependencies seems nice because even though possibly useful in some cases it could also end up very complicated. But since a CQL/ELM file is essentially already a specific CQL Library Version, multiple versions of the same library throughout the execution graph would probably not have huge issues with collision during resolution. Maybe if the versions had different Data Models such as FHIR 4.1 and FHIR 4.3 that could be a problem, but that's probably always an issue with any lib in the graph.

Another semi-related idea that could be interesting would be something like:

include external_space.PatientUtils version '^0.0.1'

where you use ^ or ~ to include the latest patch or minor versions of a lib. But that's probably a whole other beast.