Re: [OVC-demo-team] Re: Reconciliation System GUI (was: Re: Ballot GUI)

From: Alan Dechert <alan_at_openvotingconsortium_dot_org>
Date: Wed Feb 25 2004 - 12:14:42 CST

Eron,

> > So this leaves a couple of parts to be done for the BRP (what some are
> > calling BRS). We need some code that
>
> I somehow lost what you said after this point...
>
So did I. I'm sure I had something relevant to say...I just don't happen to
know what it was right now.

> > about re-doing parts of it. We are going to make a go/no-go decision
March
> > 1 for a March 15 demo.
>
> I can tell you personally that this demo is going to happen; there is no
> reason we can't get there and it is too important not to.
>
I like hearing that.

> > We'll "nail down harder technical specs" for the production system.
>
> Oh, I understand that... I just don't want to work on stuff that falls
outside
> the current "specs." I'll work with Fred and the other to solidify some
> outstanding questions.
>
> > > Going back to the BRS...
>
> Here is an updated workflow, taking your comments and questions into
account:
>
> 1. User verification/authentication
> 2. Input two witness names
> 3. Input voting station data disc(s) serial number(s)
>
The disk serial numbers would be entered into the system BEFORE voting
begins. This helps to defeat an attempt to switch CDs after voting. The
admin PC has to know in advance the serial number of the disk it expects to
get from the voting station. So this part is not really part of the Ballot
Reconciliation Procedure: It's part of the set up procedure (CDs are removed
from sealed envelop from county HQ; serial numbers entered into admin PC;
pollworker inserts appropriate CD in voting machine, locks the cage and
boots up--witnessed by two people). The relevant operation for the BRP you
have as #6.

When it prompts for the disk for voting machine #2, it should read the
serial number from the disk and compare that to what it has on file. Is
there something like GetCDSerialNumber() in the API?

> 4. Manual voted paper ballot count; input total
> 5. Voted paper ballots scanned/each ballot counted and serialized to
> filesystem as XML file in <scanned ballots>/ folder
> 6. Collect voting station data, counting and transferring each file to
> filesystem in <stored ballots>/ folder
> 7. Input ID numbers for test ballots that were printed on start up
> 8. Register known spoiled ballots
> 9. Compute/report errors on totals, comparing ballot count/scan vs. vote
> station data:
> ((#4 - (#7 + #8)) == (#5 - (#7 - #8)) == (#6 - (#7 + #8)))

I don't get your math here. #6 - (#7 + #8) gives the number of unaccounted
for ballots.

#4 and #5 has to be the same. After the manual count is entered (say 501),
the number of ballots scanned (and the number of xml files written) would be
incremented and displayed until you reach 501.

> 10. Generate/print report and ballot error log
> 11. Verify results and log out
>
> > I'm not sure what you mean by "serialize voter data." Anyway, this part
> > really is part of the previous step (your "7"). That is, in order to
> > produce the report in 7, you have to find the matching v-something file
for
> > each b-something file (as Matteo calls them). Then you have to check
the
> > contents to make sure they have the same vote data (except that the
> > b-something EBIs won't have any write-in data.. other than the
indication
> > that a writein was indicated). If there is no matching v-something for
a
> > b-something, then you have an error to report. If the matching
v-something
> > has some data that differs from the b-something EBI, then you an error
to
> > report.
>
> Right. By serialize, I only mean write-to-disk. In thinking about the
ballot
> format (and I'd like to hear David M.'s thoughts on this) for both the
files
> scanned in and the files stored by the vote station, is there any real
reason
> to have these be XML? If I can simply store the data structures themselves
on
> disk (using Python's pickle facility), then it will be much easier to code
> comparison logic. Perhaps David's xmlpickle module would work for this.
> John-Paul and Jan's code would have to work with it too.
>
I believe we're going with EBIs as XML files at this point.

> Otherwise, I'll need
> XML input/output formats to work with (are these created?)
>
We have [nearly] standardized the format for this XML files. I'm hoping Jan
and Fred will nail this down. I have been trying to get it nailed down for
some time now.

Alan D

==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Thu Apr 1 02:40:21 2004

This archive was generated by hypermail 2.1.8 : Thu Apr 01 2004 - 02:40:36 CST