Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
emiltin opened this issue Aug 26, 2024 · 3 comments
Open

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

emiltin opened this issue Aug 26, 2024 · 3 comments

Comments

@emiltin
Copy link
Contributor

emiltin commented Aug 26, 2024

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: rsmp-nordic/rsmp_sxl_traffic_lights#144
M0019 fix: rsmp-nordic/rsmp_sxl_traffic_lights#121
M0020 still mixed up: rsmp-nordic/rsmp_sxl_traffic_lights#191

@emiltin
Copy link
Contributor Author

emiltin commented Aug 29, 2024

@otterdahl input?

@otterdahl
Copy link
Contributor

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.

@emiltin
Copy link
Contributor Author

emiltin commented Jan 7, 2025

We recently had a similar discussion about M020 in the SXL WG:
https://github.com/orgs/rsmp-nordic/discussions/132

Option B in the summary (keep the attribute the way it is, but add a note about the counterintuitive meaning of true/false.) seeems similar to option B above, so perhaps that's what we're converging on?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants