I isolated and fixed this bug. PR is https://github.com/apache/incubator-daffodil/pull/307
Ticket is DAFFODIL-2259 ________________________________ From: Beckerle, Mike <mbecke...@tresys.com> Sent: Tuesday, December 24, 2019 11:46 PM To: dev@daffodil.apache.org <dev@daffodil.apache.org> Subject: found bug in 2.5.0 rc1 I am working on isolating it, but it appears that unparser eventUnparserMaps are not being properly populated. Given an incoming infoset event these maps steer the unparser to select the correct choice branch to unparse. In the schema for mil-std-2045 version 0.0.4, there is a choice between control_release_marking_D1 and control_release_marking_C, so the choice branch map should be a table matching those elements to corresponding branches in the schema. But the eventUnparserMap contains *only* a mapping for control_release_marking_C. There is no test in the mil-std-2045 schema project itself that runs into this bug. There is a test in the vmf project which runs into this (The quite old master branch, which I am updating to use mil-std-2045 version 0.0.4 headers). The test is of a mil-std-2045-header-rev-D1, with a VMF message payload. This test has the control_release_marking_D1 element in it, which is the correct element given that the header says it is rev D1. But the unparser looks for *only* control_release_marking_C. The VMF test is test_K07_1. I will be creating a test for this in mil-std-2045 itself which is publicly releasable, and for daffodil-test in daffodil itself to illustrate the problem. This is a quite serious bug. The master branch version of VMF will not work and I suspect other versons of VMF simply have no tests that contain mil-std-2045 header's control_release_marking_D1 element that unparse.
