Schema does not enforce constraints from section 5.7.2

[mbeckerle]

The schema should enforce a internal constraints on message type.

A 2045 message header can have an array of message_handling_groups

Each message_handling_group has a UMF indicating if the data is Link16, Binary File, VMF, NITF, etc.

For some of those there is a more granular message_standard_version which tells us which specific version of that standard.

Following that there is an optional vmf_message_identification_group, which obviously applies only to VMF, but this is not enforced. This contains the K-series message ID information (K01.02.03 type identification), which is not held in a VMF-message proper so must come from this header.

Following that there is an optional file_name which is NOT applicable to VMF, but to binary files, and possibly other types.
(E.g., if NITF data is carried it is not clear if there is an associated file name, or just a collection of bytes for an anonymous NITF data block.)

Right now, the message type can indicate VMF, but the data can still contain a file-name as if it was for a binary file.

[mbeckerle]

Section 5.7.2 (same section in both C and D1 specs) is a substantial section of constraint rules. The schema should be enforcing these, and create always-invalid elements when they are not adhered to.

That is, we consider the data well-formed, but just not valid if these constraints are not maintained.

[mbeckerle]

Note that there is some test data that will become invalid once these constraints are enforced. Specifically the "all fields" tests.