----- Forwarded Message ----
From: Aaron B Strauss <aaronbs@gmail.com>
To: vip-format-discuss@googlegroups.com
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 <
johnaborras@yahoo.co.uk> 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 <
aaro...@gmail.com> 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 <
johnabor...@yahoo.co.uk>
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
vip-format-discuss@googlegroups.comTo unsubscribe from this group, send email to
vip-format-discuss-unsubscribe@googlegroups.comFor more options, visit this group at
http://groups.google.com/group/vip-format-discuss?hl=en-~----------~----~----~----~------~----~------~--~---