search

DATEX-II-EU / DatexII

Main repository for issues and bugs for the DATEXII standard
0 stars 0 forks source link

[Bug]: Unsuable composite conditions model in TrafficManagementPlan #540

Closed iancornwell1 closed 2 weeks ago

iancornwell1 commented 1 month ago

Bug description?

image In TrafficManagementPlan the Condition class is used only as shown here. So the composite ConditionSet can never be instantiated.

Version

3

iancornwell1 commented 1 month ago

This should be improved, but the first question is whether it is a critical bug for usability of v3.5, which justifies a non-interoperable change in v3.6, or not. We suspect that nobody has implemented v3.5 TrafficManagementPlan, let alone using activationTrigger or deactivationTrigger, but we do not know for sure. A quick fix in v3.6 may be practical. (We should maintain alignment with the CEN TS 16157-8, and that is going to be revised anyway due to other technical errors, so that leaves both choices open - fix or maintain stability in both model and CEN TS.)

iancornwell1 commented 1 month ago

It would be useful to have some confirmation about whether we treat this as a bug needing a non-backwards compatible change @NdwMartin. Martin gave a preliminary view in Bucharest, but was going to confirm I think. Since unusually we have the opportunity to change Part 8 at the same time, I'm going to assume I should make the change, but if others disagree then please let me know.

iancornwell1 commented 1 month ago

The simplest and most efficient fix for v3.6 would be to move the associations from TriggerCondition up to Condition. Remember in v3 that Condition is not yet Common but one that lives in TrafficManagementPlan, so a Condition can only be a TriggerCondition or a ConditionSet, which is what we want here. For v4 we would have to change this to fit the Common::Conditions model. image If there is no disagreement then I will make that change once our configuration management service is restored.

iancornwell1 commented 2 weeks ago

I have committed and pushed that change, so I am closing this issue. The change should be picked up by Martin along with his other fixing of TS 16157-8 for a new formal vote.