Store election test data in common format (e.g., EML, P1622).

[kfogel]

Instead of having test data built into the code in modules/ranking_algorithms.py (see the test_* functions toward the end), we should keep test ballots and expected results separate, in a commonly-used format, so that we can more easily compare the results of E-Vote's implementations of voting algorithms against other voting systems, and vice versa.

Some candidates

• Election Markup Language (which may be related to this json)
• P1622
  • See also this P1622 page and this other P1622 page.
  • There's also a P1622 Google Code project, although nothing seems to actually be there yet.
• OpenElections, which seems to offer a Results Data Spec and an Election Metadata Spec
• ...anything else out there?

[DavidMertz]

I served on P1622 for a while, prior and just into, when we/it decided to
follow the EML route as our endorsement. I think it would be a good
thing to store samples and results as EML documents, but there's a
considerable effort involved in correctly parsing that detailed format.
For an actual political/governmental election, that standardization is
highly important; I don't quite see as much urgency for these special
purpose elections by small organizations.

However, it's probably adequate to address only a fairly small subset of
EML within E-Vote, and select very simple EML ballots that are tailored to
this specific need. That said, the OpenElections formats--while
simpler--are really by no stretch a standard. They are just the ad hoc
format used by some other software project, and that may well change as
needed based on the needs of that project. If we want a standard, it's
EML, period.

On Tue, Mar 4, 2014 at 11:11 AM, Karl Fogel [email protected]:

Instead of having test data built into the code in
modules/ranking_algorithms.py (see the test_* functions toward the end),
we should keep test ballots and expected results separate, in a
commonly-used format, so that we can more easily compare the results of
E-Vote's implementations of voting algorithms against other voting systems,
and vice versa.

Some candidates

• Election Markup Languagehttps://en.wikipedia.org/wiki/Election_Markup_Language(which may be related to this
  jsonhttps://github.com/wnyc/election_california_2012/blob/master/examples/sample.json
  )
• P1622 http://standards.ieee.org/develop/project/1622.2.html
  • See also this P1622 page http://grouper.ieee.org/groups/1622/and this
    other P1622 pagehttp://grouper.ieee.org/groups/1622/work-in-progress.html
    .
  • There's also a P1622 Google Code projecthttp://code.google.com/p/p1622-cdf-development/,
    although nothing seems to actually be there yet.
    • OpenElections http://blog.openelections.net/, which seems to
      offer a Results Data Spechttps://github.com/openelections/specs/wiki/Results-Data-Spec-Version-2and an Election
      Metadata Spechttps://github.com/openelections/specs/wiki/Elections-Data-Spec-Version-2
• ...anything else out there?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11
.

Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.

[kfogel]

Thanks for the background. So, it sounds like EML is the way to go, not P1622.

Yeah, I'd simply assumed we'd only be implementing the subset of EML (or for that matter of P1622) that we need. After all, we don't need to parse arbitrary data, we only need to parse our data, and know that our data will be parseable by anyone else who has implemented at least the same subset of the standard that we did.

[DavidMertz]

The P1622 recommendation simply IS EML. For a while we were considering
a different XML format that grew out of one of the vendors in-house
formats; but fortunately, we gave that up after a while and just endorsed
EML. Well, I shouldn't quite say "we" since the formal decision wasn't
made until after I became inactive on the committee; but that's what
happened anyway.

At some obscure edges, IEEE P1622 has some recommendations for some
additional details to add to EML, and I assume all of that will be unified
over time. But the issues where there is any unresolved questions are ones
you are unlikely to encounter in E-Vote general testing/verification.

On Tue, Mar 4, 2014 at 7:22 PM, Karl Fogel [email protected] wrote:

Thanks for the background. So, it sounds like EML is the way to go, not
P1622.

Yeah, I'd simply assumed we'd only be implementing the subset of EML (or
for that matter of P1622) that we need. After all, we don't need to parse
arbitrary data, we only need to parse our data, and know that our data
will be parseable by anyone else who has implemented at least the same
subset of the standard that we did.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-36706526
.

Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.

[kfogel]

Ahhh. I had thought P1622 was its own format, or attempt at a format. You're saying (I think) that it's rather a working group that, while they perhaps contemplated making their own format, decided after surveying the landscape that EML is the way to go, and now they just recommend that. (Possibly with obscure additions that will be of no concern to us.)

Gotcha, and thanks for clarifying.

[DavidMertz]

Yep... you have it exactly correct, Karl.

On Tue, Mar 4, 2014 at 8:57 PM, Karl Fogel [email protected] wrote:

Ahhh. I had thought P1622 was its own format, or attempt at a format.
You're saying (I think) that it's rather a working group that, while they
perhaps contemplated making their own format, decided after surveying the
landscape that EML is the way to go, and now they just recommend that.
(Possibly with obscure additions that will be of no concern to us.)

Gotcha, and thanks for clarifying.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-36710242
.

Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.