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

From: Eron Lloyd <elloyd_at_lancaster_dot_lib_dot_pa_dot_us>
Date: Wed Feb 25 2004 - 11:38:53 CST

Hi again,

On Tuesday 24 February 2004 7:03 pm, Alan Dechert wrote:

> 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...

> 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.

> 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)
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)))
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. Otherwise, I'll need
XML input/output formats to work with (are these created?)

Thanks,

Eron

-- 
Eron Lloyd
Technology Coordinator
Lancaster County Library
elloyd@lancaster.lib.pa.us
Phone: 717-239-2116
Fax: 717-394-3083
---
[This E-mail scanned for viruses by Declude Virus]
==================================================================
= 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:20 2004

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