RE: [election-services] Fw: VIP/EML CONVERGENCE

Thanks, DW

-------- Original Message --------
Subject: RE: [election-services] Fw: VIP/EML CONVERGENCE
From: Richard J Cardone <richcar@us.ibm.com>
Date: Tue, July 08, 2008 11:37 am
To: "David RR Webber \(XML\)" <david@drrw.info>
Cc: "EML TC" <election-services@lists.oasis-open.org>

David,

I don't know if you've had a chance to look at the EML50Combine package (https://sourceforge.net/projects/eml50combine/), but it's also a utility program that manipulates EML 5.0 schemas. I'm looking forward to exploring your program--we may have the beginnings of a tool suite here.

Here's the short description of EML50Combine:

EML50Combine merges two or more XML schema files defined by OASIS (http://www.oasis-open.org) in the Election Markup Language 5.0 (EML). The merged schema file can be inputted into language binding generators like JAXB or Apache Xmlbeans.

Rich

"David RR Webber \(XML\)" <david@drrw.info>
07/08/2008 10:06 AM

To
"Paul Spencer" <paul.spencer@boynings.co.uk>

cc
"Lori Steele" <lori@everyonecounts.com>, "John Borras" <johnaborras@yahoo.co.uk>, "EML TC" <election-services@lists.oasis-open.org>

Subject
RE: [election-services] Fw: VIP/EML CONVERGENCE

John,

I can definately help.

The key is being able to selectively refine the EML schemas to suit their needs.

I now have tooling that will create subset schemas very easily - and the main need is taming the CIQ v2.0 import - which is gigantic and mostly unneeded for USA. We can create a common pattern there - and that should dramatically simplify things for them and make it alot less confusing.

I should be ready to share that with them later this week. Right now I'm doing performance tuning and testing on each of the EML schemas to make sure its all OK.

The other peice is then producing documentation of the subsetting automatically - for local use pattern - and submission back to us. Again - if they add any of their own fields - or re-use some of ours slightly differently - the tool will build the new subset schema automatically and then the accompanying HTML doc's.

Anyway - suspect I'll need to do a webinar of all this - walk them thru it - and we can use the OASIS Adobe Webinar service for that - once we've figured out a good time for everyone to participate.

Thanks, DW

-------- Original Message --------
Subject: RE: [election-services] Fw: VIP/EML CONVERGENCE
From: "Paul Spencer" <paul.spencer@boynings.co.uk>
Date: Tue, July 08, 2008 10:05 am
To: "John Borras" <johnaborras@yahoo.co.uk>,"EML TC"
<election-services@lists.oasis-open.org>
Cc: "Lori Steele" <lori@everyonecounts.com>

I may be able to help.

Paul
-----Original Message-----
From: John Borras [mailto:johnaborras@yahoo.co.uk]
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 <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.com
To unsubscribe from this group, send email to vip-format-discuss-unsubscribe@googlegroups.com
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!
--------------------------------------------------------------------- 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

election-services message