John -
I am happy to participate if it helps us further EML as the
standard for election data interchange.
- Peter
From: John Borras
[mailto:]
Sent: Tuesday, July 08, 2008 6:18
AM
To: EML TC
Cc: Lori Steele
Subject:
[election-services] Fw: VIP/EML CONVERGENCE
At long last and thanks to Joe's efforts I have started a
dialogue with the VIP team. You may remember we identified
this project some weeks ago and were somewhat concerned about their focus
and direction. You will see from the exchanges below that there is
a willingness to try and converge and map a route from VIP to EML.
The proposal is for a small team to take both sets of requirements and
identify overlaps and differences. We can then agree a plan for either
updating EML in v6 with the new requirements or develop a converter if we think
their needs are outside of our scope.
So I need a couple of volunteers please to help with this work.
David and Peter I think you would be best placed given that
this is very much USA specific, if you can spare the
time? Paul - I assume you will be too busy in the
Caribbean? I will invite the volunteers to join the Google
discussions and we can then organise how best the tackle the task.
Any general thoughts/observations on this would be
appreciated.
Regards
John
M. +44 (0)7976 157745
Skype: gov3john
-----
Forwarded Message ----
From: Aaron B Strauss <>
To:
Sent: Monday, 7 July, 2008 11:32:15
PM
Subject: Re: VIP/EML CONVERGENCE?
To follow-up
1. I
think VIP fits in as an intermediate step in the process to
complete open
e-voting. For example, it's my understanding that the
new guidelines by EAC
allow open source voting systems to be
accredited. But that's a far cry from
embracing open source solutions
for election data management. Being realistic
about the use of
proprietary vendors for Election Management Systems (EMS's),
VIP's
goal is to take the disparate EMS formats and produce an open
format
that in no way threatens vendors (because we need their
cooperation
for any of these endeavors) while also allowing states to
restrict the
use of personally-identifiable information. Eventually, when
elections
systems become completely open then VIP will be much less useful,
and
EML will play its destined role. Until that day, we offer VIP
to
address the pressing need of voters to figure out what they are
voting
on and where they should go to cast a ballot.
2. Absolutely, we
are keeping an eye on the future. A key part of this
is geography -- we are
creating the VIP format with the goal that
geographic elements play similar
functions so that they can be mixed
and matched in future versions. For
instance, right now, the basic
geographic hierarchy is
state->locality->precinct, but there is little
in the spec to prevent a
jurisdiction (e.g., Guam) to have a
state->precinct hierarchy or another
jurisdiction (e.g., Virginia or
Iowa) to have
state->locality->locality->precinct. We want to start
with a
US-centric format, but are trying not to limit ourselves down
the
road.
3. The geography is a key piece for us because we do not expect
states
to release their voter files. Thus, we have to match addresses
to
precincts. And since EML aims to serve the same function
as
proprietary, individually-intifiable EMS formats, I'm not sure I
would
recommend EML to adopt our geographic strategy. I think this is
one
area where our different goals cause us to come up
with
non-overlapping formats.
4. Overall, I completely agree, there is
a great deal of overlap. And
I think we have a lot to learn from the work
you've already done. As
mentioned in point 1, I really see VIP as a stop-gap
measure, and as
such I think a VIP->EML converter would be a great help in
pushing
states toward EML eventually.
5. Our current targets revolve
around this election -- trying to get a
50-state solution by October, which
is when polling places are locked
down and voters really start searching for
this information.
6. Anyone is welcome to join this group: it's open. And
having a small
group work offline sounds like an excellent
plan.
Aaron
On Mon, Jun 30, 2008 at 11:39 AM, John <>
wrote:
>
> Aaron
>
> Thanks for the explanation.
Some brief observations on the three
> points you've made
below.
>
> 1. In an ideal world, and come the glorious day
when politicians and
> the public embrace e-voting, then EML would support
an end to end
> totally integrated voting system However we are
realistic and have
> developed EML to be implemented in separate bits, eg
voter
> registration, e-counting, results declaration, and in fact to
date
> that's how it's being used. I'm not aware of any total
system
> implementation. We clearly have the goal of open systems
and not
> proprietary solutions and I would have thought the vendors in
USA
> would be driven down that route sooner or later by the EAC's
new
> guidelines. So that's the threat to them not us and perhaps we
can
> help vendors acheive that goal?
>
> 2. I can
accept that starting small and being USA centric was
> sensible from your
perspective but perhaps now's the time to start
> thinking and planning
for a longer term solution? Is there a danger
> that without that
longer term stable requirement you will be tinkering
> each year with the
solution?
>
> 3. The geographical angle you are coming from is
one that has not
> emerged in discussions with the USA experts on our
committee nor in
> the EAC's draft guidelines so it's a piece of
functionality that we
> have not built into EML. Having said that
it's not beyond us to do so
> in future releases.
>
> So it
seems we have an area of overlap and an area which at present
> EML is not
designed for. What we need to do then is work through
> exactly
where we have common ground, identifying any slight
> modifications that
might be necessary, and being clear about those
> areas which we do not
currently touch. Do you have any of that
> information from your
original analysis of EML or have we got to just
> grind through it all
from scratch? Once we have got these two lists
> then it would
probably be better to take the work off-line from this
> discussion and
get may be one or two of us to collaborate on preparing
> a solution which
could be brought back for agreement on this list?
> Timescales would
obviously depend on peoples' availability. Do you
> have any current
targets you are trying to meet? We are on hold at
> present until
the ISO process has been concluded, which may take a few
> months as we
are very much in their hands.
>
> Do you mind if I invite one or two
of my committee to join this
> discussion just in case I'm talking
jibberish!!
>
>
> On Jun 30, 2:48 pm, Aaron Strauss <> wrote:
>>
First of all, the EML team has done some outstanding work. The
>>
flexibility, and especially the scope, of EML are truly impressive.
We
>> drew inspiration from your format when developing the VIP spec,
but
>> ultimately felt the need to create our own spec because of
contrasting
>> goals and constraints.
>>
>> There are
several reasons that we opted not to use EML. Here are the
>>
main three, in my opinion, and they provide a good starting point
for
>> discussion.
>>
>> 1) Most importantly, EML and
VIP have different goals. The white paper
>> I read (http://www.oasis-open.org/committees/download.php/22101/The
>>
%20Case%20for%20EML.pdf) speaks mostly of trust in elections as well
>>
as security. Our goal is not an integrated elections system,
e-voting
>> and audits included, but rather a method of disseminating
information
>> to voters. The white paper contrasts the benefits
of using EML vs. a
>> proprietary system. We opt not to frame the
discussion in that manner;
>> instead, we view the VIP spec as a common
format layer on top of
>> existing (usually proprietary)
technologies. Adoption of such a
>> standard in the US requires
partnership with vendors and that pro-con
>> list (p.16) would be
viewed as a direct threat to vendors.
>>
>> 2) Relatedly, we
felt a need to start small and US-centric. States are
>> of course
reluctant to invest time to introduce new products. We felt
>> states
would hesitate before attempting to implement the fully-grown
>> EML.
Thus, we began with a much smaller set of US-centric election
>> data
elements to represent in VIP. Also, with elections in the U.S.,
>>
there is an inherent catch-22: the times when states actually have
the
>> data to present in a new format are the times when they are most
busy
>> (i.e., election seasons). If we had introduced VIP in 2007,
for
>> instance, states would not have had the candidate data to fill
out the
>> spec (as the candidates would not have filed yet). In 2008,
states are
>> either focused on the primary elections (winter, spring)
or general
>> elections (fall). This gave us a small window of
opportunity to
>> introduce a very streamlined spec for the states,
which had to be
>> small and tailored to their needs. An example of
such tailoring is:
>>
>> 3) Personally identifiable
information. Because of our two different
>> goals (#1), the basis of
our two formats are very distinct. A core EML
>> element is the Voter
element (i.e., VoterInformationStructure), which
>> has an an attribute
PollingDistrict. VIP does not handle personally-
>> identifiable
information (many states would be barred from releasing
>> such data),
so we had to go a different route: specifically, setting
>> up a
geography that would allow us to take an address and find the
>>
polling district for that address. From my reading, EML is not
>>
designed for that functionality.
>>
>> That all said, in the
end a subset of the data we produce is also a
>> subset of the EML spec
and one of our goals is to develop a tool for
>> converting VIP data to
EML data.
>>
>> I'm glad that so many minds are thinking about
election data and I
>> look forward to working with all of you from
here on out.
>>
>> Aaron
>>
>> Also, as an
FYI: there's a new version of the spec [the changes are
>> mostly minor
optional additions] proposed here (http://code.google.com/
>>
p/election-info-standard/downloads/list). Feedback is always
welcome.
>>
>> On Jun 27, 10:31 am, John <>
wrote:
>>
>>
>>
>> > To start off this
discussion can I re-iterate Joe Hall's original note
>> > by saying
that we in the OASIS EML TC were a little surprised and
>> >
concerned when we heard about the VIP project and read your FAQ that
>>
> intimated that EML was not fit for your purposes. Let me say right
up
>> > front that we are not trying to dominate the world with EML
but we
>> > have worked very hard over a number of years now and
embraced a very
>> > wide range of voting experts across the globe
to make EML suitable for
>> > use by all known voting regimes.
We are now at a stage where we have
>> > recently submitted EML to
ISO and we hope to get it approved as an ISO
>> > standard in the
near future. As with all standards it's better if
>> > there's
only one rather than several, not only for the end users but
>> >
also for the suppliers so along our journey we have attempted to co-
>>
> operate with and encompass other similar efforts, eg IEEE's
P1622
>> > committee, the Council of Europe's e-voting project, the
U.S. Election
>> > Assistance Commission's (EAC) draft Voluntary
Voting System Guidelines
>> > (VVSG), to avoid confusion for the
punters who want to use the right
>> >
solutions.
>>
>> > So what I would really like to establish
is why you chose not to use
>> > EML at the outset of your project,
where you feel EML is not fit for
>> > your purpose, do you think
the gaps between us are bridgeable, and are
>> > you amenable to
working to that end? We are preparing a Wishes List
>> > for
our next major revision so if we could identify the differences I
>>
> will add them to our List and attempt to accommodate them in our
next
>> > release.- Hide quoted text -
>>
>> -
Show quoted text -
>
>
>
--~--~---------~--~----~------------~-------~--~----~
You
received this message because you are subscribed to the Google Groups "Voting
Information Project: Format Discussion" group.
To post to this group, send
email to
To
unsubscribe from this group, send email to
For
more options, visit this group at http://groups.google.com/group/vip-format-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
Not happy with your email address?
Get the one you really want -
millions of new email addresses available now at Yahoo!
