You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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?
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
The text was updated successfully, but these errors were encountered: