As an EKUTA platform operator,
I want to be able to deploy different typology processors in my evaluation flow,
So that I can perform typology aggregation in different ways for different types of typologies.
Acceptance criteria
Create a separate processor identifier from the (current) typology identifier:
a. The current id attribute in a typologies element (and in fact in every processor in the network map) is supposed to identify the specific typology processor and version that will be used to evaluate a typology, but in our current implementation, the key-value pair: "id": "001@1.0.0" actually identifies the typology (and as a result the version text following the @ is redundant and assumed to always refer to the version of the only typology processor in the platform). It should be possible to operate multiple parallel typology processors in the platform, and also multiple versions of the same typology processor, coordinated through the network map. To fulfil this requirement, the id attribute should refer to the specific typology processor and version, while the cfg attribute should refer to the typology and configuration version. In other words:
b. The typology processor "name" is somewhat arbitrary, but it would make sense to name the typology processor in the configuration after the repository where the typology processor code comes from, i.e. "typology-processor".
c. The change to the typology identifier should follow through to the typology configuration as well.
Story statement
As an EKUTA platform operator, I want to be able to deploy different typology processors in my evaluation flow, So that I can perform typology aggregation in different ways for different types of typologies.
Acceptance criteria
id
attribute in a typologies element (and in fact in every processor in the network map) is supposed to identify the specific typology processor and version that will be used to evaluate a typology, but in our current implementation, the key-value pair:"id": "001@1.0.0"
actually identifies the typology (and as a result the version text following the@
is redundant and assumed to always refer to the version of the only typology processor in the platform). It should be possible to operate multiple parallel typology processors in the platform, and also multiple versions of the same typology processor, coordinated through the network map. To fulfil this requirement, theid
attribute should refer to the specific typology processor and version, while thecfg
attribute should refer to the typology and configuration version. In other words:b. The typology processor "name" is somewhat arbitrary, but it would make sense to name the typology processor in the configuration after the repository where the typology processor code comes from, i.e. "typology-processor". c. The change to the typology identifier should follow through to the typology configuration as well.