Define the required ComparisonReport structure for non-equivalent structs #5
Description
The ComparisonReport for non-equivalent structs is tricky because structs can have duplicate field names. As such, you can't determine non-equivalence without testing all of the values in the target struct. That means there isn't really a single event in the target struct that can be pointed to as the rhs in a ComparisonReport.
In the ion-c implementation, the lhs will be the field in the source struct that did not have a match in the target struct, and the rhs will always be the CONTAINER_END event of the target struct. This is nice because it at least shows which field in the source did not have a match in the target, but this information could alternatively be conveyed in the message.
Other implementations may not be structured in a way that makes it as easy to identify the exact field in the source struct that didn't match in the destination struct. ion-java, for example, has an Equivalence utility that simply returns a boolean. Being able to use this utility will make the ion-java CLI implementation much simpler, but will not allow for the non-matched field to be pinpointed.
I propose that for non-equivalent structs, the ion-test-driver spec should require that the lhs and rhs events in ComparisonReports of non-equivalent structs always be the CONTAINER_START events for those structs. If possible, implementations may put any additional information in the message to help humans narrow down the source of the comparison failure.