search

rsmp-nordic / rsmp_validator

Official RSMP Nordic automated test tool, build with Ruby and Rpec.
https://rsmp-nordic.github.io/rsmp_validator/
MIT License
4 stars 1 forks source link

True/false mixup in M0005, M0019 - how to validate #409

Open emiltin opened 2 months ago

emiltin commented 2 months ago

The mix-ups of true false in some attributes in earlier SXL versions of true/false in M0005, M0019 is unfortunate, and caused a lot of confusion.

To fix it we fixed the SXL from version 1.1, so true=activated, and false=deactivated.

All suppliers that existed at that time assumed (as was the case) that it was a type and implemented true=activated also for SXL <= 1.0.15. You could say they follow the intention of the spec, but not the word.

Because of this situation we modified the validator to test according to the fixed spec for all SXL versions. That way implementations would not have to change.

Later, other suppliers implemented strictly according to the word of the spec, with true=deactivated.

Unfortunately, both types of implementations cannot co-exists without problems, so some implementations will have to change if this is to be solved.

Some options:

a) Backport the spec fix so true=activated, also for older SXL versions. This would match how we test it with the validator.

b) Test strictly according to the spec for SXL < 1.1, with true=deactivated. We would then expect different behaviour for SXL before and after 1.1.

c) Release 1.0.16 with the typos fixed, but otherwise the same as 1.0.15. Equipment that have implemented true=acticated would use this, while equipment using on=deacticated would stay with 1.0.15.

A similar situations must exist for supervisor implementations.

Reference: M0005 fix: https://github.com/rsmp-nordic/rsmp_sxl_traffic_lights/issues/144 M0019 fix: https://github.com/rsmp-nordic/rsmp_sxl_traffic_lights/issues/121 M0020 still mixed up: https://github.com/rsmp-nordic/rsmp_sxl_traffic_lights/issues/191

emiltin commented 2 months ago

@otterdahl input?

otterdahl commented 2 months ago

I think option A is a bad idea. It's confusing to not follow the spec. Option C is OK from a versioning point of view, but I'm not sure releasing yet another version is worth the effort.

I think option B is the best choice, even though it introduces complexity of the test cases.