Adding empty elemnts to valid objects

[mbencik999]

OSI allows raw pointer handling and handling data in any way we see fit. But this approach creates problems when item are added to classes. For example the TrafficSign class has the possibility to add a DetectedTrafficSign_DetectedSupplementarySign item, but the problem is, this item can exists without any values. This is very inconvenient since the count of the items is increased but the items can bee empty. Should OSI provide a validation mechanism which enforces the minimal information required for the item to be valid? Shouldn't be mandatory to give an ID to the object? Also there can be objects without and ID, and they can later not be identified.

[pmai]

OSI itself does not deal in pointers, so this is a (perceived) problem with the relevant ProtoBuf => Language Mapping, which should be taken up with the ProtoBuf guys...

Similarly, the way ProtoBufs are designed, the programmer has to expect that all fields are optional.

That said, the OSI documentation specifies which fields are mandatory in the relevant Doxygen entries (e.g. IDs). This is, again by design, not done via "non-optional" ProtoBuf fields, since this impeeds upward/downward code compatibility, and runs counter ProtoBuf best practices.

A worthwhile project, which is e.g. needed for GroundTruth or Sensor Validation is of coure to provide a checker that checks an OSI data stream against such invariants as documented in the OSI Spec/Documentation. And I'm sure that there are areas in the documentation/spec that should be tightened.

Whether ProtoBuf is the best basis for OSI going forward is something that is already under consideration (see issue #56 for example)...

[mbencik999]

The problem that I have at this point there is no way to enforce the mandatory fields to be filed. Regarding the checker that module would be quite slow. This could be avoided if there would be a way to enforce the completeness and basic validity of data.

[pmai]

As stated, this is by design (of ProtoBuf, but also to a lesser extent by design of OSI). And for a serialization format, you will always have to have that checker, since you cannot trust the other side of the communication in any case (both due to bugs, version skew, and active subversion). Or in other words: For externalized data, there is never a way of enforcing completeness and basic valdity of data, you always have to check (and when contrasted with the overhead that the ProtoBuf protocols create for encoding/decoding, the checker is likely going to be negligible in terms of overhead).

So the only discussion is whether that checking is to be baked into the serialization/deserialization stage, or tacked on afterwards. That's a discussion that can be had, but would more or less require switching away from ProtoBufs (or putting a layer on top of that). Again see issue #56.