Re: data format from evm..

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Thu Sep 11 2003 - 01:20:06 CDT

Chris Schaefer <> wrote:
|I'm chris schaefer. I'll be working on vote tabulation.
|I recently approached this project from the outside and found it
|to be rather tough to get up to speed.

Hi Chris. You are absolutely right!

I took over as dev lead at the beginning of this month; and recognized
that the most important thing that needs to happen to move forward is
publication of documentation for the project. The mailing list is
really no good for that purpose. Unfortunately, I've been busy with
other work, and haven't done much beyond getting up the EVM2003 homepage
(which is really just Alan's old announcement). I.e.

The right place for the documentation to go is really on the homepage,
or on leaf pages linked from that page. We can perhaps use
sourceforge's document check-in to archive stuff, but there should be a
friendlier public face for the most current info. I don't really think
a Wiki is needed, since the basic documents won't change much once they
are there; but if someone will to volunteer to create a Wiki, I
certainly won't object to going that way.

There are several main documents that need to exist:

    (1) Requirements
    (2) Architecture
    (3) The OVM and plans for the future

I'm most concerned about the second; I think it's easier to get a sense
of the requirements, even though being more explicit would be good.
Still, I will happily work with anyone who volunteers to start writing
the former. The last is good to have too, but I'm declaring that outside
my scope as Dev Lead.

On Architecture, there are several parts (sub-documents, or sections, or

  (1) The standard ballot: i.e. Python, wxPython, gnosis.xml, XML
      layout format, MVC approach, etc.

  (2) How to print the cast ballot: The results SHOULD be stored in
      an XML file (but no DTD exists). I do not know any
      details of how that XML data will be converted into both the
      barcode and the human readable ballot. Please volunteer to make
      these decisions (with my supervision/feedback).

  (3) The blind-accessible ballot. The resulting XML cast-ballot file
      will be the same as for the standard ballot, but probably very
      little else. Again, someone please step in.

  (4) The barcoded ballot reader. We need to convert the barcode into
      speech. Again, I have no ideas what technological decisions are
      appropriate here; I need help with this.

|I'm working through ways of tabulating votes. Other than the
|important "paper trail" in a ballot box. I believe the intent is to
|have some sort of a scanner be able to read a bar code on the side of
|the printed ballot.

In the "normal" case we should be able to pull XML file(s) off the
voting machine itself, and tabulation will utilize the data on
transportable media (or possibly sent over a wire; but any modems must
not be plugged in during the voting period, and transmitted data must be

Only in the case of a challenge will it be necessary to verify the
electronic data against the printed ballots. But obviously, the
capability to do so must exist (at some point, perhaps not in time for
the demo).

As to what the barcode itself stores, I really have not followed the
discussion closely. Jan K rrman had some ideas, as did Alan Dechert and
Arthur Keller, and those were discussed on-list. But as with most of
the rest, I could really use someone to step in an formalize the
encoding in the architecture document (both the specific barcode used,
and the way votes are represented within the symbology).

Yours, David...

    _/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: Postmodern Enterprises _/_/_/
   _/_/    ~~~~~~~~~~~~~~~~~~~~[]~~~~~~~~~~~~~~~~~~~~~  _/_/
  _/_/  The opinions expressed here must be those of my employer...   _/_/
 _/_/_/_/_/_/_/_/_/_/ Surely you don't think that *I* believe them!  _/_/
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
Received on Tue Sep 30 23:17:03 2003

This archive was generated by hypermail 2.1.8 : Tue Sep 30 2003 - 23:17:09 CDT