Transitive dependencies on common libraries w/ different versions

[cmoesel]

Consider this set of libraries (removed most content for brevity):

library A version '1'
include B version '1'
include X version '1'

library B version '1'
include X version '2'

library X version '1'

library X version '2'

If you run CQL-to-ELM on these libraries, you get an error like this:

Library X was included as version 1, but version 2 of the library was found.

It seems this should be allowed, because there is no ambiguity. It’s always clear what version of X should be used for any given expression (e.g., X.Foo referenced in A refers to X version '1', X.Foo referenced in B refers to X version '2').

As best I can tell, the spec does not forbid this. In fact, the spec's insistence that library references are not transitive sets up the spec nicely to support this situation.

Is this a limitation in CQL-to-ELM? If so, is it intentional, or is it a bug?

[brynrhodes]

Apologies for the delay here, this was an inconsistency that was clarified in the latest version of the spec. The end of the section you reference now specifically requires all references to a given library to be to the same version.

However, as you point it, it is possible to resolve the references theoretically, but there was I think justifiable concern about it being an additional burden on engines to maintain multiple versions of the same library.

A different, but related question is whether different libraries should be able to reference different versions of the same model. The same concern exists, but at the same time, I can see use cases for allowing multiple versions of the same model (version-specific transformations lead to mind).

Should this be submitted as an STU comment on the latest spec to relax that constraint? I'm going to open a discussion on Zulip referencing this and seeking implementer feedback.

[cmoesel]

I actually think that supporting multiple versions of the same library within a single execution context is much more feasible than multiple versions of a model. Assuming no circular dependencies, then there is never any overlap/clash between different versions of a library being referenced from different places. Data, however, passes between all the modules -- so that's a lot more complex.