EML Clarifying Questions

[Thom Wysong <wysong@technodemocracy.org>]

In thinking over what we have covered during our first nine days in 
existence as a committee, I've sensed that we may not all be on the same 
page in terms of what we feel the direction and scope of EML should be. I 
thought it'd be worthwhile to pose a few questions that will hopefully get 
everyone's views on the table. Then we can decide what the overall best 
direction and scope will be.

----------

The purpose of our committee is listed on the Election Services committee 
home page (http://www.oasis-open.org/committees/election/index.shtml). It 
is "to 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".

I find it interesting that the stated purpose of the committee focuses 
strictly on vendor-to-vendor and vendor-to-client relationships within the 
elections community. I hadn't noticed this before. I had been working under 
the assumption that EML would be more broadly focused on providing value 
anywhere in the elections community that it could.

It's worth noting that direct 
election-administrator-to-election-administrator, 
election-office-to-election-office, candidate-to-election-office, 
agency-to-agency, jurisdiction-to-jurisdiction, and 
election-office-to-voter data interchange (among others) are not covered by 
our committee's stated purpose.

An initial stated purpose for the committee obviously needed to be 
developed to help define what the committee would be working on. However, 
since this initial stated purpose was developed before the committee ever 
met, it makes me wonder if it's within our powers as a committee to alter 
our stated purpose now that we're together. Does anyone know if this would 
be within the "official rules" of OASIS?

If it is within our powers to do this, a few questions would need to be 
addressed. One is what are the possibilities? What would we change it to? 
Another is what's in the best interest of the committee?  What's in the 
best interest of the elections community?  What will increase EML's chances 
of being widely adopted? And finally, is there sufficient support on the 
committee to alter our stated purpose?

----------

Another issue that would be beneficial to explicitly clarify is what voting 
methods and voting technologies are we targeting EML to be useable by?

Voting methods include paper ballot, lever machine, punch card, optical 
scan, electronic, Internet, and telephone.

It would be logical to assume that only fully electronic voting systems 
would be able to make use of EML. This would include electronic, Internet, 
and telephone voting systems. And would exclude paper ballots, lever 
machines, punch cards, and optical scan voting systems.

However, it seems to me that jurisdictions that use paper and mechanical 
voting systems could make use of EML to a limited degree. The recount of 
Florida's 171,000 undervoted and overvoted ballots from the November 2000 
election (http://recount.usatoday.com) is an example of this. While there 
were many groups who would have liked to view and analyze those ballots, 
because they were only in paper form, re-counters had to be physically 
present as the ballots where handled one by one. Substantial financing was 
required to afford this recount effort and therefore very few groups were 
able to participate.

However, the re-counters could have created an electronic representation of 
the punch card ballots as they processed through them - designating how 
many "corners" of which chads where still connected, which chads were 
"dimpled", etc.  Then the file containing the electronic representation of 
those ballots could be posted on the Internet. Any group wishing to analyze 
the ballots could do so for substantially less cost than it would take to 
process through the physical ballots in person. Additionally, if the 
ballots were represented in a standard xml format, computer programs would 
be able to analyze them from a hundred different angles.

Currently there is no standard way of representing punch card or optically 
scanned ballots in electronic format. However, it would not be difficult to 
create this. It's just a matter of whether it's inside the scope of our 
committee or not.

I'm not sure if anyone else on the committee sees a value in creating xml 
elements for voting systems that are not purely electronic. I'd be 
interested in hearing everyone's comments on this.

----------

Yet another issue I think would be worth discussing is whether **all** 
elements of EML will need to be useable by **all** targeted voting systems? 
Or, will EML contain specialized subsets of elements that may be useable to 
some voting systems, but not to others?

This question came to mind when the brief discussion on ballot presentation 
occurred during our first meeting. It seemed to me that those who objected 
to tackling presentation issues may have been assuming that all voting 
systems would have to be able to successfully handle all 
presentation-related elements. Since no explanation was given for the 
objections, I may be entirely wrong in my interpretation of the situation.

However, regardless of whether or not my understanding was correct, it 
seems that it would be worthwhile for us to decide whether EML is to be 
single set of xml elements useable by all targeted voting methods?  Or, if 
we will create special subsets of elements that are useable by only a 
subset of the targeted voting methods?

----------

After the above matters are discussed, I tend to think it would be 
beneficial for us to lay out an explicit set of simple parameters or 
requirements that would guide the committee's future work.

As a part of this, it would seem beneficial to list any scenarios that, 
ideally, would involve the use of EML. These parameters and usage scenarios 
would help to keep everyone going in the same direction.

----------

I would also like to present some comments and questions on presentation 
and accessibility issues. However, this email is long enough. I'll send 
those thoughts out separately.

Thank you for your time. I look forward to reading everyone's comments.

-Thom