Next in thread → Next in month →

RE: [election-services] NIST workshop on common data format for Electronic Voting Systems

From
Zelechoski, Peter <>
Date
2009-07-31T12:55:39+00:00
ID
Thread
RE: [election-services] NIST workshop on common data format for Electronic Voting Systems
Unfortunately, we did not win the Philippines business -- 
if we had you would have had an example for a whole country that used it to 
report at all levels from local to national.  Our bid there used EML for 
sending the definition to the machines and to the reporting units and then to 
send the results to all reporting units and to the press.  But that's how 
business goes; you win some and you lose some.

From: John Borras [mailto:] 

Sent: 2009-07-31 2:46 AM
To: David RR Webber 
(XML)
Cc: eml
Subject: RE: [election-services] NIST workshop 
on common data format for Electronic Voting Systems

David

 

How about then that Laurent presents the political view 
using the brochure as his outline and then you follow on with the technical 
Fisher Price approach specifically targeted at the USA market?  I'll draft 
up Laurent's bit.

 

In terms of no one is using it, I have another recent 
use case that EML was used in the recent European Parliamentary elections, 
unfortunately the website with all the details is in Dutch!  But we now 
have several real world examples of EML being used

 

John

 

From: David RR Webber (XML) 
[]
Sent: 31 July 2009 03:54
To: Joseph 
Lorenzo Hall
Cc: John Borras; eml
Subject: RE: 
[election-services] NIST workshop on common data format for Electronic Voting 
Systems

Joe,

Excellent feedback.  This is exactly the same challenge we are 
addressing for NIEM with the CAM toolkit.

People need the Fisher Price approach - neatly packaged and 
documented.

I had hoped that the simple EML 440 example illustrated this in part - but 
naturally we can extend this to show people the progression from ballot, vote, 
tallying, results - with bare minimum constructs.

Part of this is also here:

http://xml.coverpages.org/Webber-OpenSecure-eVoting-EVT07.pdf

So my sense is we should be close to this - just need to package and 
promote accordingly.

Thanks, DW

  
-------- Original Message --------
Subject: Re: [election-services] 
  NIST workshop on common data format
for Electronic Voting Systems
From: 
  Joseph Lorenzo Hall <>
Date: Thu, July 30, 2009 
  7:34 pm
To: "David RR Webber (XML)" <>
Cc: John 
  Borras <>, 
  eml
<>

One thing I've 
  heard over the past few days from a few different
directions is that it 
  appears very difficult for people to "dive in"
to EML... for example, the 
  "hello world!" equivalent of the various
data models we support in EML. 
  Obviously, I'll probably work up
something specific to our research group's 
  work on the needs of
post-election auditors wrt vote data. But I think a 
  serious tutorial
that gets designers and developers from "hello world!" to 
  working
seriously with EML sounds like a good medium-term deliverable 
  that
would short-circuit some of the criticism. I'm obivously an 
  academic,
so I might be looking through particularly-tinted glasses at all 
  of
this... best, Joe

On Thu, Jul 30, 2009 at 1:03 PM, David RR 
  Webber (XML)<> wrote:
> John,
> Not sure 
  about this.  They clearly are throwing down the gauntlet for
> 
  SPECIFIC use cases - reading between the lines - their conjecture is - 
  noone
> is using this stuff - so that proves its bad - and new is needed 
  instead.
> The most obvious for EML here in the US are two - CA SoS EML 
  statistics and
> the VIP project geodistrict and polling places.
> 
  Then I would suggest a third presentation on overall EML, V6 and
> 
  specifically focusing on US needs and how V6 is covering these. 
   Reporting,
> auditing and statistics are now all strong suits for 
  new EML V6 - whereas
> previously NIST had doubted the ability to handle 
  precinct style recording.
>  Also - we can show specific ballots 
  from NY, Connecticut, Florida, CA and
> more - all being handled using 
  EML 440 - again vital to show actual
> instances.
> I typically 
  like to submit up to 4 or 5 presentations - because it is hard
> to 
  second guess what the organizers exact focus is - and you can expect 
  them
> to reject a couple then - and take a couple.
>
> 
  Thanks, DW
>
> -------- Original Message --------
> Subject: 
  RE: [election-services] NIST workshop on common data format
> for 
  Electronic Voting Systems
> From: John Borras 
  <>
> Date: Wed, July 29, 2009 4:24 am
> To: 
  "eml " <>
>
> Thanks 
  to Joe and David for bringing this to our attention.  I propose 
  to
> submit the updated version of our EML White paper, copy 
  attached.  Please
> let me have any suggested amendments to this in 
  the next few days please.
>
> This looks to be a very important 
  workshop and we would do well to have as
> many supporters at this 
  event as possible, so can you make every endeavour
> to attend 
  please.  Also can I have a volunteer to make a presentation on 
  our
> behalf if our submission is selected.
>
> 
  Regards
> John
>
> ________________________________
> 
  From: David RR Webber (XML) []
> Sent: 28 July 2009 
  21:02
> To: eml
> Subject: [election-services] NIST workshop on 
  common data format for
> Electronic Voting Systems
>
> 
  Posting this here for the NIST members on our list.
> Obviously we 
  should submit something on the new EML V6.0 and I am available
> to 
  present as needed.
> 21 August 2009 is the submission 
  deadline.
>
> Thanks, DW
>
> -------- Original Message 
  --------
>
>  NIST is having a workshop in October on common 
  data format for electronic
> Voting Systems. Here's the announcement 
  with some added highlights:
>
>
> http://vote.nist.gov/CDF-WorkshopCallForPapers.htm
>
> 
  CALL FOR PARTICIPATION
>
> NIST Workshop on a Common Data Format 
  for Electronic Voting Systems
> 29-30 OCTOBER 2009, NATIONAL INSTITUTE 
  OF STANDARDS AND TECHNOLOGY,
> GAITHERSBURG, MD
>
> 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.
>
> Different goals have 
  different consequences for the requirements, the scope
> of
> 
  work, and the testing that must follow. For example:
>
> * 
  Requirements
> + Human-readable versus machine 
  readable-human-readability matters for
> transparency and auditing, 
  whereas integration of equipment indicates
> use of an existing data 
  exchange syntax that is optimized for
> machine-reading rather than 
  human-reading.
> + Flexible and extensible versus uniform and 
  complete-interoperability is
> helped by a standard data format only if 
  the format is used in the same
> way by everyone; other goals may 
  accommodate a more flexible and
> extensible format.
> + Secure 
  versus convenient-securing the records to make them valid for
> auditing 
  could also hamper intermediate processing that might be needed
> to 
  integrate disparate pieces of equipment.
> + Format versus content-to 
  "get the data out" it is more important to
> specify the data to be 
  provided, the points in the process at which it
> is to be provided, and 
  the mechanism for export than the format of the
> data.
> * 
  Scope
> + Publishing results involves only the reporting phase of the 
  election
> and should not include such information as individual ballot 
  images.
> + Interoperability might only be needed at certain points in 
  the system
> architecture.
> + Registration may or may not be 
  within scope.
> + Low-level event log data may only be useful for 
  auditing.
> * Testing
> + If the data format is to be used for 
  auditing, usability testing with
> auditors is indicated.
> + If 
  the goal is interoperability, interoperability testing is different
> 
  from conformity assessment
>
> This workshop aims to (a) begin a 
  discussion on the above issues among
> experts
> in the elections 
  community who would work with a common data format,
> including
> 
  election officials, auditors, manufacturers, testing labs, and others
> 
  involved
> in election analysis, and (b) arrive at basic scoping for 
  what a common data
> format is to accomplish and the basic requirements 
  for what it must do.
> Discussions during the workshop will address the 
  following:
>
> * The current state and uses of common data 
  formats;
> * "The customer"-existing and potential;
> * The 
  customer's goals-what data needs to be encoded in the format and how
> 
  will it be used;
> * Next steps towards a common data format;
> * 
  Willing contributors.
>
> Workshop attendees are encouraged to 
  submit papers in advance of the
> workshop.
> Two types of 
  submissions are sought:
>
> 1. Position papers on requirements for 
  common data formats (2-5 pages).
> Topics
> of interest include 
  (but are not limited to) the following:
> + What problems or needs 
  should be addressed by a common data format for
> any particular 
  application, e.g., auditing, transparency of election
> results, device 
  interoperability, or testing;
> + What data should be represented by a 
  common data format;
> + When in the voting process should the data be 
  available.
> 2. Papers describing current uses of data formats in U.S. 
  elections and
> experiences with using the formats (2-10 pages), 
  including (but not limited
> to) the following:
> + What problems 
  were being addressed by use of the format;
> + Whether customization was 
  necessary;
> + Success of the effort;
> + Lessons 
  learned.
>
> Authors may submit papers that have been presented or 
  published elsewhere.
> Accepted papers and presentation slides will be 
  made available on the web as
> well as in printed form to workshop 
  attendees. Manuscripts will not be
> formally
> 
  published.
>
> Manuscripts should be sent to  by 21 
  August 2009. Decisions
> will
> be made by 09 September 
  2009.
>
> ----- End forwarded message -----
> 
  _______________________________________________
>
> 
  --------------------------------------------------------------------- 
  To
> unsubscribe from this mail list, you must leave the OASIS TC that 
  generates
> this mail. Follow this link to all your TCs in OASIS 
  at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
  ________________________________
> 
  ---------------------------------------------------------------------
> 
  To unsubscribe from this mail list, you must leave the OASIS TC that
> 
  generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
> 
  --------------------------------------------------------------------- 
  To
> unsubscribe from this mail list, you must leave the OASIS TC that 
  generates
> this mail. Follow this link to all your TCs in OASIS 
  at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

-- 
  
Joseph Lorenzo Hall
ACCURATE Postdoctoral Research Associate
UC 
  Berkeley School of Information
Princeton Center for Information Technology 
  Policy
http://josephhall.org/
Next in thread → Next in month →