Usage of multiple IDS Infomodel Serializer versions

[juliapampus]

After talking to @ronjaquensel and @tmberthold, I want to highlight the following issue we always had with the IDS Infomodel and Serializer libraries: Setting the serializer version as fixed, forces the component to only ensure the compatibility to one Infomodel version, as we do not have any compatibility table. This means an incoming message with 4.2.7 could be deserialized with serializer 4.2.8, but maybe not with 4.2.6 or 5.0.0, although the handling of the IDS objects stays the same. This implies that we need to instant reject messages of another version in order to prevent exceptions. This raises some issues regarding the compatibility to other IDS components both central services and connectors that update their Infomodel versions continously.

Maybe we could find a way to support multiple serializer versions at runtime? In this context, the EDC could recognize what version the incoming message has and take the appropriate serializer version to deserialize objects. This would solve syntax problems. Nevertheless, we also have to keep in mind and implement ways of handling missing properties. So if our message processing depends on an attribute that a newer version of the Infomodel may not cover, we need to check and implement workarounds. Thus, every attribute from an IDS input has to be checked for existence before processing it.

[DominikPinsel]

I also like the idea of running multiple information model versions in the same connector. Currently it's also not possible to run multiple information model versions in the same connector. One of the main issues is, that we would get collisions in the namespace. If we find a solution to run multiple serializer versions, we should apply the same solution to the information model, too.

[jimmarino]

@juliapampus

A couple of questions:

1. Does the serializer support semantic versioning?
2. Related to 1, does the serializer encode versioning in its Java package names?

If the serializer can support those two items, this could be achieved through a simple dispatching mechanism. If the serializer does not support #2, the only way to solve this is to introduce a classloader isolation mechanism or name-mangling, which I don't think are maintainable solutions.

If the serializer does not support 1 & 2, we could adopt an incremental approach where M3 targets one version and later we work with the serializer team to introduce those changes.

[juliapampus]

Does the serializer support semantic versioning?

I would assume it does. However, I am not sure because the Infomodel java library partially doesn't. There, the first digit references the IDS Infomodel version number, that is Infomodel java lib v4.x.x for IDS Information Model v4.x.x. This means that there is already a break because the first digit is not used for major changes in the library (on an implementation level). Thus, with the DSC, we sometimes had problems from changing to a minor release or patch, when implementation details (e.g., methods) were changed. Furthermore, the serializer's version is always the same as the Infomodel java library it supports, no matter what changes are made to its implementation apart from increasing the supported version.

Related to 1, does the serializer encode versioning in its Java package names?

Unfortunately not.

[sebbader]

Regarding semantic versioning of the serialiser, yes, it does, as @juliapampus wrote.

[sebbader]

Second, about the version info in the package, nope, not yet.

[sebbader]

Furthermore, there are a few performance issues when working with big JSON-LD documents. Meaning, I think we need a refactoring of the serializer anyway (to some degree). Integrating a versioning scheme into the package is then probably the smallest part.