Election and Voter Services Workshop Day

Date	October 31, 2001
Time: 10:00 am – 3:30 pm

Objective: Produce a draft document for consideration by the Technical Committee on the scope of election and voter services.

Attendees: 	John Borras, UK Cabinet Office
		Paul Spencer, UK Cabinet Office
		Charbel Aoun, election.com

Document drafted by:  Charbel Aoun

When this committee was established it had the following mission statement  “develop a standard for the structured interchange of data among hardware, software, and service providers who engage in any aspect of providing election or voter services to public or private organizations. The services performed for such elections include but are not limited to voter role/membership maintenance (new voter registration, membership and dues collection, change of address tracking, etc.), citizen/membership credentialing, redistricting, requests for absentee/expatriate ballots, election calendaring, logistics management (polling place management), election notification, ballot delivery and tabulation, election results reporting and demographics.” 

We felt it necessary to re-examine the list of services to ensure that we have identified the correct ones for the e-voting process.

The core of the deliverable we are working on is the facilitation of data exchange between client and supplier and between suppliers. This data exchange will be the content of any transaction relating to an election. We found it essential to start from the beginning by defining what is an election, in terms of a process, then from there identify what data is to be communicated.

From the outset we questioned how general we should remain versus how deep we should drill down, and we decided to start at a very global level.  That would be our starting point to share with the committee and from there we can move as far as the majority will agree on.

We felt it necessary to concentrate on public sector elections since any private service will be simply a subset or a simplified version of the public version.

We started with the following picture. 

As shown the core of our work is the process. From this we should derive our final outputs in terms of XML schemas and standards. The challenge is to put on paper a common process accepted by various governments and democracies. A logical bullet point description of the process resulted as follows, and this is depicted also in the following high-level process model:

1-	Voter registration
2-	Voter notification
3-	Candidate nomination
4-	Response to nomination
5-	Ballot
6-	Vote
7-	Results
8-	Post election (like audit, etc…)

XML is a simple, standard way to delimit exchanged data. Any one can use his/her favorite programming language to create an arbitrary data structure, and then share it with anyone else using any other language on any other computing platform. From this we worked to create where our committee should seek to create those standards of communication. We deduced that at this level we should simply define those standards to exchange data related to election services and not interfere with the engine responsible for generating it.

High-Level Process Model

Respond
Y/N

Go to Vote Process

Ballot Results

VOTES

VOTE

Election  List

Respond w Voting Method

Notify Voter of Election

Boundary Changes

GOV

Electoral Roll

Maintain register

Register 
to vote

Produce Ballot

Resolution or Candidate DB

Call for candidates

The architecture above is what we propose to symbolize as this global process and interfaces 1 to 8 mark where we thought we should concentrate our initial effort.

However while doing so we came across exceptions related to cultural divide, language, bylaws, different type of service possible etc… I will illustrate in each point some examples. From this way of thinking we came to the solution of identifying the mandatory and the optional data in each interface. Mandatory is what we thought is the minimum data all governments will agree on needing and the optional will be the part considered as required in one system and either optional or even forbidden in others.

1-	Voter Registration

Mandatory:
	Name
	Address

Optional:
	Date of Birth
	National ID
	Contact Info
		Phone
		Fax
		Email
		Etc …
	Preferred contact method
	Special requests
	Preferred language
	Etc …

Issues
In the USA for example you can collect the date of birth and other information but in the UK you can ask only if at a specific date this voter reached the age of 18 or not yet. And other regulations on data are very strict. What about other countries? Italy, France, etc We suggest the above is the minimum standard but that countries are free to make optional items mandatory should they wish to do so.

2-	Voter notification

Mandatory
Name
Address
	Voter Number
	Election Name
	Voting Place
	Voting Choices
		In person
		Postal
		Electronically
		Etc …

Optional
	TBD?

3-	Candidate Nomination

Mandatory
	Candidate Name
	Candidate Address
	Party Name
	Election Name
	Contact Info
	Seat Name
	Proposers or Endorsers (1 to n) n=number of maximum of endorsers required.
		Name
		Address
		Job Status or Title
		Contact Info
			Phone
			Fax
			Email
			Etc …

Optional
	Fee
	Personal Profile or Biography
	Election Statement
	Etc …

Issues
This step exists naturally in all democracies. Whether it is a statuary requirement or not, governments deal with in various ways. In the UK since it is a major requirement as important as balloting some suppliers moved into automating this process.  Do we want to go into this far? We believe we should.

4-	Response to Nomination

*** To work on this point more ***

Mandatory
	Answer as Yes/No

Optional
TBD?

5-	Ballot

Mandatory
Election Title
	Position
		Candidate Name      This section repeats
		Candidate Party
	Vote Limit
Voting Type/Method
Language
Voting Instructions
Seat Name
Etc …

Optional
Rotation
Etc …

Issues
This outline can cover a wide range of ballots whether FPP or STV, also surveys, referendums etc.. But still does not cover all possibilities. For example the proportional list system widely used in Switzerland and Germany. A complicated system including vote by list, crossing out, combined lists, etc…  Our view is to deal with each special case separately and generate various standards, one / category.

6-	Vote
*** Further reading into Jon Ross Paper also to discuss where does security come in and how much it affects the vote***

Mandatory
	Election Title
	Voter ID (only to be included in non-anonymous vote)
	Seat Name
	Selection (ie. Vote string)
	
Optional
TBD?

7-	Results
*** To work on this point more ***

Mandatory
	Election Name
	Seat name (1 to n)
	Position (1 to  n)
		Candidate         This section repeats n times.
		Choice

Optional
TBD?

Issues
At this level are we supposed to deliver only a bulk of data, which is in reality a ready set of data of the actual vote. If we have 10k votes should our output be another set of 10k records with a standard described in this point? Or shall we simply produce a result and define a standard of communicating this result. If so which result format or conditions we should pick, and how do we incorporate the e-vote outcome with any postal and person votes to produce an overall result ? By doing so, aren’t we limiting the output? EML is supposed to be exchange of data without limitation of format or content, we should simply make data available in a uniform and standard data.
	Exp:
DB content Vote, date, time, election, seat, Region, sub region, sub-sub-region
We have for example 1000 votes with this format distributed in at least 2 or more tables.
Result standard 1
1000 xml node of the content combined in one file
Result standard 2
1 xml node summarizing the content (result/candidate for example)

8-	Post election 
*** To work on this point more ***

Mandatory

Optional