I may
be able to help.
Paul
-----Original Message-----
From: John Borras
[mailto:]
Sent: 08 July 2008
12:18
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!
