text: For the last 11 months, I been involved in an organization called the Open Voting Consortium (OVC) and an associated Free Software project called EVM2003. The OVC’s aim is to replace the closed-source electronic voting machines from proprietary vendors, specifically those that fail to provide a voter-verifiable paper ballot. The initial focus is elections in the U.S., but OVC systems hope to prove useful to other nations in the future. As developerWorks readers well know, software is inevitably prone to errors and to malicious tampering; it is hard to find “just trust us” to be a satisfying answer to the risk of votes being directly misrecorded onto electronic-only storage devices.
  The EVM2003 project, hosted on SourceForge, is a worldwide community effort to build a reference implementation of elections software that meets a set of specifications emerging from the OVC; that organization hopes to act as a kind of standards body for elections systems. EVM2003 is programmed in Python — with various supporting libraries — and uses XML for almost all of its data storage/configuration requirements.
  The OVC’s specifications are quite detailed, and many of those details are still evolving. Issues like the security analysis and full threat model are outside the scope of this article, but are being considered carefully by many of the world’s leaders in computer security and elections technology (with yours truly contributing to this aspect). But it is worth quickly outlining the envisioned system before delving into the XML formats and source code that might support it. The code and formats I present in this installment are preliminary attempts at both; while the details are likely to change, I hope that much of the design will carry forward to voting systems that are eventually used by U.S. voters, or by those in other nations.
  Currently, the OVC has publicly demonstrated its reference design; we are in the process of working with funding agencies, such as the National Science Foundation, and state universities, as well as regulatory bodies and state or federal legislatures.
  An OVC-compliant polling place would contain several types of computer stations. Voting stations would come with both a GUI/touchscreen interface and an interface that allows reading-impaired voters (such as blind people) to vote using headphones and key presses. Either type of station would print out an official ballot after a voter completes his or her selections. A sighted and literate voter would read the face of this ballot to make sure that it records her intended votes; a reading-impaired voter might, as an alternative, take the ballot to an independent, non-networked ballot vocalization station that would read back recorded votes over headphones. Once verified, the paper ballots would be placed in an ordinary locked ballot box. At the end of the day, poll workers would reconcile the official paper ballots with the anonymous electronic records from the EVMs — accounting for spoiled ballots, test ballots, and so on — to provide extra checks against tampering. At higher levels — such as county or state — precincts would be aggregated (called “canvassing” in elections nomenclature), and various other integrity checks would be performed.
  {mospagebreak title=EVM2003 and XML}
  Here’s how the EVM2003 system works. EVM2003 uses or produces three closely related types of XML files:
  - ballot file
  - electronic ballot image (EBI) file
  - reconstructed ballot image (REBI) file
  At the initial stage, an election at a given place/precinct and date — and perhaps for a specific party ballot — is data driven by a ballot file. In production, this file would be uniquely named to indicate place, date, party (if applicable), and natural language (where multilingual ballots are provided). For example, a production ballot XML data file might have a name like election-20041102-US-MA-Franklin-2390-Dem-EN.xml or election-20041102-US-MA-Hampshire-3451-Rep-ES.xml. This exact naming convention is merely my suggestion, but it indicates the type of information that I would expect to find (all of the identifying information is also contained in the content of the data files, so the XML might be stored in, for example, an RDBMS rather than on a file system).
  After a voter has voted, an electronic ballot image (EBI) is stored as an XML file on the voting station; the collection of stored EBIs is written to removable media, such as a CD-R, in randomized order to preserve voter anonymity. The information contained in an EBI should exactly match the information represented on an official printed ballot, though a ballot would contain various formatting such as font choices, placement, rules, and boxes to make verification visually easy for voters.
  During the reconciliation process, poll workers scan the paper ballots to produce reconstructed ballot images (REBIs). These REBIs might not be byte-wise identical to their corresponding EBIs, even if no error occurs. For example, in the demo system (and perhaps for production), we decided to represent votes as barcodes to make scanning simpler; however, our barcode only records the fact of a write-in vote, not the write-in name itself. Jurisdictions differ greatly as to when and whether write-in names will be counted, so this is a fine way to establish boundary conditions for requiring visual examination of write-in names on ballots.
  EBIs and REBIs have a special, and rather elegant, relation to ballot files. An EBI or REBI is almost a proper subset of a ballot file — that is, you create an EBI simply by removing non-selected choices from a ballot file and renaming the root element from <ballot> to <cast_ballot>. One effect of this relation is that a <cast_ballot> XML file is a simpler version of a ballot XML file. The subset relation I state is violated in a couple minor ways within the current CVS snapshot of EVM2003, but it could easily be enforced with minimal modification. For example, in ballot-election.xml, <contest> elements have an allow_writein element that is superfluous to, and not included in, EBIs or REBIs. And symmetrically the root element <cast_ballot> contains an attribute source to distinguish EBIs from REBIs (for example, voting_machine versus ballot_scan).
  If the proper subset relation is enforced in production systems, it provides the somewhat nice property that ballot files and EBIs conform to an identical DTD/schema, providing a basic consistency guarantee. Even if we decide that precise subsetting is unnecessary, the close similarity of EBIs and ballot XML files makes debugging and development easier on developers (and on our frail memories).
  {mospagebreak title=XML Samples}″ country=”US” state=”CA”
  county=”Santa Clara County” precinct=”2216″>
  ″ country=”US” state=”CA”
  county=”Santa Clara County” precinct=”2216″
  number=”1274″ serial=”213″”.
  {mospagebreak title=Comparing XML Ballots}
  ballot =
  comparison tool. If imported, e.g.:
  .
  >>> import evm2003.utils.equiv
  >>> from gnosis.xml.objectify import make_instance
  >>> a = make_instance(‘scanned.xml’)
  >>> b = make_instance(‘stored.xml’)
  >>> a == b
  1
  .
  At the command-line:
  .
  % python equiv.py scanned.xml stored.xml
  .
  (lack of any output means success, in that ultra-terse UNIX-philosophy
  way).
  .
  We implement custom .__eq__() and .__ne__() methods specific to cast
  ballots. Injecting such methods is the recommended technique for enhancing
  gn
  import sys
  class
  gnosis.xml.objectify._XO_cast_ballot = cast_ballot
  #– Command-line operation
  if _.
  {mospagebreak title=Conclusion and Resources}
  Quite aside from the political import of EVM2003, I feel a certain satisfaction in working with a Free Software project where XML is so clearly just the right data storage format to use. In many contexts, XML is something that you force on yourself because it seems like the way to go — but in a few cases, the fit is absolutely perfect. In projects that intersect with standards, I think XML has a particularly strong case in its favor since so many interoperable parsers and binding libraries are available (many of which I have written about in this column). And in projects like EVM2003 where the self-documentation of data formats is important (and while data volume is moderate), XML fits like a glove.
  Resources
  - Participate in the IBM developerWorks discussion forum on this article. (You can also click Discuss at the bottom of the article to access the Dev Shed forum.)
  - Read about the EVM2003 project, which hopes to develop a Free Software infrastructure for elections, and is hosted by SourceForge.
  - Find out more about the Open Voting Consortium at their Web site.
  - Download the Gnosis Utilities as an archive, or browse the package, including its documentation. (For the Gnosis Utilities, see the link in the resources list at the end of the article on developerWorks.)
  - Learn more about David’s Gnosis Utilities in previous installments of the developerWorks column. The module gnosis.xml.objectify was introduced in “On the ‘Pythonic’ treatment of XML documents as objects(II)” (August 2000). An update of the discussion can be found in “Revisiting xml_pickle and xml_objectify” (June 2001). More recently, the performance and updated usage of gnosis.xml.objectify were discussed in “Process XML in Python with ElementTree ” (June 2003).
  David has coauthored two academic papers on the security and privacy issues that underlay voting systems, and the Open Voting Consortium reference design specifically:
  - “Privacy Issues in an Electronic Voting Machine” with Arthur M. Keller, Joseph Lorenzo Hall, and Arnold Urkin
  - “A PC-Based Open-Source Voting Machine with an Accessible Voter-Verifiable Paper Ballot” with Arthur M. Keller, Alan Dechert, and Karl Auerbach
  Find hundreds more XML resources on the developerWorks XML zone.
  Browse a wide range of titles at the developerWorks Developer Bookstore, including Text Processing in Python by David Mertz.
  Learn how you can become an IBM Certified Developer in XML and related technologies.
  About the Author:
  David Mertz, Muckamuck, Gnosis Software, Inc., feels that procedural democracy requires that the technical instruments of governance be open for public inspection, every bit as much as it requires the legal acts of government remain so open. David may be reached at mertz@gnosis.cx; his life pored over at. Suggestions and recommendations on this, past, or future columns are welcomed. Check out David’s book Text Processing in Python.