Support Selections Ballot Record

[JDziurlaj]

The earlier prototypes mixed selections with ballot definition (EML410), creating a non conformant EML410 instance. This had a number of issues, including inability to schema validate the EML410 instance, and inability to sign the ballot definition. A new structure should be devised to separate the two.

<RBM>
<EML>...</EML>
<Selections>...</Selections>
</RBM>

The CVR Prototype will need to be updated to convert this into a durable CVR.

[JDziurlaj]

The RCV form fragment is barrier to this approach. The problem is that table based representation expects a very particular structure, which causes data binding issues. Specifically, each row needs to space to bind to the EML structures, then a space to switch to the Selections XML fragment. However, each table is expected to have a subform for each row, and that subform must contain N form elements for N columns (i.e. ranks). This precludes nesting a subform to redirect to a different portion of the XML Data DOM.

A workaround could be to multiply nest tables, but this will lead to a very complex form. The second workaround is to place a subform in each column, restructure the checkButton to render correctly, and add related fields. This will emit a Selection once per column, regardless of selection status. That means that the Selections Ballot Record will contain all ranks, rather than effective rank.

[JDziurlaj]

Actually neither of these solutions work. The problem with the table approach is that to avoid duplicate headers, the headers will need to be in the parent table, which means that it will also need multiple columns. But this breaks the one cell per parent table configuration. The subform workaround does not work because it breaks the mutual exclusion logic enforced by sharing a common binding for all the ranks.