Clarify rule outcome when checking nested fields inside unset parent fields

[thomassedlmayer]

What should be the defined result of rules checking nested fields inside unset parent fields? Should such rules fail if the parent field is not set?

For example:

• BaseMoving of a MovingObject is not set and there is a rule to check if the field position inside BaseMoving is set.
• The field vehicle_classification is not set and there is a rule to check if the nested field "type" is set.

[asadekasam]

OSI Chceker bundle Project / 2025_07_01: At the current state it does not make sense to separate errors to previously not existing fields. We will visit this issue after having the service provider implement the file location.

[pmai]

Based on Project discussions on 2025-09-30, to be approved in the next project meeting:

The current rules are that if a nested message is not set, none of the rules for that message type are checked. This means:

1. If the field that contains the nested message does not have an is_set rule, then no violation is reported.
2. If the field that contains the nested message does have an is_set rule, then only that violation is reported.

For the first case this is exactly right, as it is completely valid to not have the message set at all, so there is nothing to complain about its non-existent contents.

For the second case this is the concise report of what is currently wrong: The field is not set, and we would not know what its contents would be if it were set, so there is nothing further to complain about, than noting the message should be set.

The only reason to report subordinate rules in the second case to have failed is to provide information to the user of what should be in the message if it were to be included, i.e. what rules will apply to it.

This is however redundant information, as the same information can be looked up in more concise form in the specification for that message.

Reporting on it would only help in certain limited use cases, and would however increase the number of reported issues greatly, with little benefit to most users.

Therefore there are no current plans to change this, and a pre-condition to revisit this issue would be the existence of qc-framework infrastructure to efficiently deal with the many related issues that this change would generate.

Proposal: Close issue for now, it can be revisited if there is an expressed user need, and infrastructure for dealing with large numbers of related issues exists or is imminent.