Example of optional occurrences

If an occurrence of a component is optional, there may be more than one possibility for a given data object. For example, suppose a type has the following components:

A (1:3)

B

After A is found, the next object in the data stream can either be A or B. Suppose it is B. Therefore, the object fails to be A. A message in the trace file indicates that the object does not match the definition of A in some way. After the validation process has determined that the object is not A, validation occurs to determine whether it is B. Then the object is validated as B.

It is acceptable if an optional occurrence of a component does not exist in the data; it is optional. However, if a required occurrence of a component does not exist, the data object containing that component is invalid.

The optional Message is missing from the data. After finding the Header, the next data object searched for is Message. However, the next object in the data is not a Message, it is a LineItem.

The trace file indicates that the initiator of the data object is not M which is the initiator of a Message. After it is determined that the data object is not a Message, the LineItem is validated as a LineItem.

If you see a message in the trace file saying that a data object does not exist, this is not necessarily the error causing the entire input object to be invalid. Keep in mind the data being validated, and the optional data. Your understanding of optional data is important when reading the trace file.

Example of partitioned types

Another case in which a data object might fail to belong to a certain type is when the type is partitioned. If an object that is presumably a partition is validated, the validation process goes down the list of partitions to determine the partition to which the object belongs. You might see a message that indicates an object failed to be a certain partition. That means it does not belong to that partition, it may belong to one of the other partitions. The validation process checks to see whether it belongs to the next partition, and so on.

For example, suppose Record is partitioned into A, B, and C.

Each record begins with an initiator: A*, B* or C*.

First, validation checks the initiator to determine whether it is an A Record. The initiator will be the wrong value for an A Record. Next, validation checks the initiator to determine whether it is a B Record. The initiator will be the wrong value for a B Record. Next, validation checks to determine whether it is a C Record and the object is validated as a C Record.

Viewing results in hex mode

Run results can be viewed in hex mode, which displays the offset values of the data. This may be helpful if the trace file indicates a problem at a particular offset in the data. To view run results in hex mode, select the Display In Hex Mode check box in the Run Results dialog box.