 XML Page 3 - XML Matters: Practical XML Data Design and Manipulation for Voting Systems |
XML samples - XMLEVM2003 brings XML to the democratic process. In this installment, David discusses his practical experiences developing interrelated XML data formats for the EVM2003 Free Software project to develop voting machines that produce voter-verifiable paper ballots. Some design principles of format subsetting emerge. In addition, David looks at how an application-specific meaning for XML document equivalence can be programmed, and why canonicalization is insufficient. (This intermediate-level article was first published by IBM developerWorks, June 28, 2004, at http://www.ibm.com/developerWorks.)
print this article SEARCH DEV SHED |
Some example XML files will help you get a sense of the formats I have described. The official DTDs or schemas (ideally using RELAX NG in production) are still sufficiently subject to change that I do not want to fixate on those. To save space, I'll simplify the demonstration election that the OVC has used, but keep at least one example of each contest type. First, the ballot file: Listing 1. ballot-election.xml <ballot election_date="2008-11-04" country="US" state="CA" Some of the attributes of <contest> merit further explanation. Contests may be ordered to allow ranked preference votes. Ranked preference votes allow a voter to assign a preference (first, second, third, and so on) among a number of candidates -- you might use many different methods to score those ranks (all outside the scope of this article), but an Instant Runoff is probably the least rare in the U.S. In any case, since a few jurisdictions use ranked preference voting, this ballot XML format needs to accommodate it. Missing from the current ballot DTD is an attribute to indicate the maximum number of ranks that are assignable -- I will show you how to add this shortly. Contests can either allow write-in votes or not. In the example, it makes little sense to write in a vote on a Yes/No initiative; other types of contests may or may not allow write-ins, depending on jurisdictional rules. The name attribute is straightforward -- it simply describes what a contest is in a short phrase. In some contests, child elements may be needed to present the details of a contest to voters (such as initiative descriptions). Again, the exact content is jurisdiction dependent. The coupled attribute is probably a hack, but it's not clear whether there's a better approach. In U.S. presidential elections, we have a relatively unusual system in which votes for a President and Vice President must be paired together -- no a la carte menu selection of "one of each" is allowed, even though both candidate names still appear. For now, this design lists each candidate within a <selection> element, but if coupled is set to Yes, candidates are presented two-at-a-time rather than individually. As I mentioned, a cast ballot (EBI) roughly subsets a raw ballot, but a few details are changed too. EBIs follow a naming convention that indicates both the place and date of the election, and also a distinct ballot ID number (which is not reused on a single machine): Listing 2. v-20081104-US-CA-Santa_Clara_County-2216-1274.xml <cast_ballot election_date="2008-11-04" country="US" state="CA" Notice that the attribute writein now appears within <selection> tags. In a sense, you could deduce whether a vote is a write-in by looking at a corresponding ballot-election.xml file that contains <selection> PCDATA content, but using the attribute adds some useful redundancy. If a non-write-in candidate fails to match the raw ballot, that is a sure sign that you have a data integrity problem. But some jurisdictions only count specific write-in names if certain thresholds are met (contest margin-of-victory, total write-ins, and others); you may never need to look at the content of selections indicated as writein="Yes".
blog comments powered by Disqus |
/ 15 
Integrating XML with J2EE
