search

mdipierro / evote

A system for secure, trusted, and verifiable voting on the web
Other
115 stars 41 forks source link

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

Open kfogel opened 10 years ago

kfogel commented 10 years ago

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

DavidMertz commented 10 years ago

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 notifications@github.comwrote:

Instead of having test data built into the code in modules/rankingalgorithms.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/mdipierro/evote/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 commented 10 years ago

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 commented 10 years ago

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 notifications@github.com 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/mdipierro/evote/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 commented 10 years ago

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 commented 10 years ago

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

On Tue, Mar 4, 2014 at 8:57 PM, Karl Fogel notifications@github.com 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/mdipierro/evote/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.