Closed ClemensLinnhoff closed 6 months ago
As usual, violating rules in a standard leads to unspecified behavior, unless a clear specification on error handling is given.
Hence an implementation may start WW3 - though laws and regulations might not allow one to do exactly that - or it may handle this very robustly. The standard does not say. Of course other mechanisms, like basic common sense or market pressures are likely to lead to implementations not going out of their way to be unhelpful.
It is also unlikely that we want to specify error handling here, because that tends to be a lot of painstaking work, with little impact, as implementors tend to do what they tend to do anyway, and the simplest approach is to just not violate rules.
Now that also might point to the fact that we should not have too strict rules, when they do not make sense.
Describe the problem
In the proto files, rules are defined for certain fields. Let's take the following example: In the SensorData::FeatureData::LidarDetectionData::LidarDetection there is the following rule for the intensity field:
Let's say the intensity is wrongly set to 150 in one LidarDetection.
Ask your question
What does this mean for the rest of the message? Can the other fields of the same LidarDetection still be used, e.g. the position? Or are all other LidarDetection also to be seen as invalid? Is maybe the entire LidarDetectionData invalid if one field does not comply? Or is the entire top-level message, i.e. SensorData, not to be used in such a case?