Thank you for your attention to my comments on the first public
draft of EMLv6:
Here are some followup comments. I've used a narrative style
here to provide background and context, but have also listed along the way a
number of specific comments which I'd like to see addressed.
There is one row which combines
many of my main previous comments together, with this TC disposition:
> Defer to next release in the main, but could do some small changes
> now. Review off line some 530 changes may be possible
In the EML PR2 draft, I don't see any changes in 530. I see
one helpful change in 510: the addition of a "ReportType" string
field which can be used to record the type of ballots included in a given audit
unit - e.g. to differentiate between "absentee",
"in-precinct", "early vote", "mixed", etc.
Thank you!
The "LocalName" field was also added to the core for
contests, presumably in response to my request for both standard names and
local names. I have two follow-on comments:
Comment 1) I suggest renaming LocalName to
"AlternateName", since the "ContestName" would normally
serve as the "local" name, to be used in the actual ballot materials
and traditional reports.
Comment 2) There also needs to be an AlternateName for candidates,
as noted at the NIST meeting on standard data formats.
To motivate the rest of my comments, I cite the American
Statistical Association statement endorsing Risk Limiting Audits:
I think it is clear that risk-limiting post-election vote
tabulation audits are one of the best ways to improve confidence in election
results via independently gathered hand-count evidence. But the timelines
to do post-election audits are stringent and the data processing needs are
challenging. The data needs to be gathered and aggregated from counties
using different election management systems. Audit units need to be
selected and hand counted, and results need to be compared and analyzed,
potentially leading to more hand counts.
Unless the exact format for these reports is specified, including
field names etc, with enough details present for interoperability testing
and use by automated tools, EML will not meet the test of being an
"interoperable" standard, as described at the NIST meeting. It
would only be suitable as a basis for "integration", thus losing much
of its potential.
Two initial drivers for EML were identified at the NIST data
format standard meeting, and one was auditing.
So I still think users of EMLv6 would benefit greatly from a few
new standard elements to support post election tabulation audits.
Comment 3) Standardize the EML 510 data elements needed for auditing
Inside <Contest><ReportingUnitVotes>
a) Type of ballots ("absentee", "in-precinct",
"early vote", "mixed", etc) (using the new ReportType
element)
b) Number of ballots
c) Number of ballots on which this contest appeared
Inside <Contest><TotalVotes>
a) Total number of ballots
b) Total number of ballots on which this contest appeared
c) Number of distinct ReportingUnits reported here
Comment 4) Provide a simple official example program (in XSLT or some
other
language) to aggregate EML 510 from multiple jurisdictions into a
single comprehensive EML 510 file, suitable for re-tabulating the
preliminary results and selecting batches to be audited. Or at
least
get an existance proof that the fields are standardized well enough
that such a program can be written - I'll do it if necessary.
Sponsor an interop test among EML implementors using that program
to test compatibility.
Comment 5) Make post tabulation
audit support a specific goal of EML in
Section 3.2.6 of the EML spec ("The Auditing System"), and add
schemas 510 and 520 as inputs to the audit cross-referencing process
in figure 2H. Reference "Principles and Best Practices for
Post-Election Audits" http://electionaudits.org/principles/
Comment 6) Provide new 5xx
"Audit Results" schema for reporting the results of
an audit, including selections, where discrepancies were found, and
perhaps Or perhaps add a few new standard elements that could make
the
510 report suitable as an Audit Results.
This Audit Results schema could
be delayed until the next version of EML, when we have more experience in what
is needed. But I think the other comments are necessary for the most
demanding and time-sensitive phase of the audit, and they are relatively easy
to address. They would allow EML to become an interoperable standard that
would lower costs for auditing and thus help drive its adoption.
Thank you again for your work on this very important standard!