The goal of this two-day workshop is to identify and agree upon a set of requirements for a common data format for voting systems. While there have been many calls for a common data format for voting systems, there is little consensus on the requirements for this format or what it is to accomplish. Possible goals for a common data format include interoperability of different equipment, auditability, transparency, publishing (communication with consumers of election data, such as media outlets), integration between polls and registration, transition to electronic record-keeping, or the ability just to "get the data out" by any means possible. Stakeholders include manufacturers, election officials, the EAC, consumers of election data, voters, organizations with existing data formats (including OASIS and the Voting Information Project), academics, and others with related work.
I believe this workshop comes in the right time, we really need a common data format. Actually, there are too many different formats, each vendor use its own one for final reports, configuration files and communication messages. So far, not only Interoperability is a dream but also integratability is very far from the current voting systems. EML seems to be the far light and the common criteria for each system, but it is also very huge. Just to let a little flavour, EML takes care about four big set:
- Transactions (Pre-election, Election and Post-election)
- Specification (otlines voting process, identifies data requirenments, contains glossary of term, addresses security issues, overview aof the XML schemas)
- Data Dictionary (Defines all exchanged data componets)
- XML Schema (Family of 38 components, 29 specific exchange schema, 2 new US driven schema developed for UML 6.0 )
In addition we ha to remember that laws are different from state to state and EML may permit to do something which maybe it's forbidden in some states. On the other side of the coin we cannot implement different EML's slangs... we'll back to the present situation. Moreover US' precincts are so different, some are huge like LA (millions of voters) and other ones are small (hundred of voters) and they use different kind of voting systems. This is another issue, it's difficult to figure out a so much general Data Format able to satisfy each precinct.
- Transactions (Pre-election, Election and Post-election)
- Specification (otlines voting process, identifies data requirenments, contains glossary of term, addresses security issues, overview aof the XML schemas)
- Data Dictionary (Defines all exchanged data componets)
- XML Schema (Family of 38 components, 29 specific exchange schema, 2 new US driven schema developed for UML 6.0 )
In addition we ha to remember that laws are different from state to state and EML may permit to do something which maybe it's forbidden in some states. On the other side of the coin we cannot implement different EML's slangs... we'll back to the present situation. Moreover US' precincts are so different, some are huge like LA (millions of voters) and other ones are small (hundred of voters) and they use different kind of voting systems. This is another issue, it's difficult to figure out a so much general Data Format able to satisfy each precinct.
So, let's go ! We have a lot to do to improve our democracy.
