----- Original Message ----
From: David RR Webber (XML) <david@drrw.info>
To: John Borras <johnaborras@yahoo.co.uk>
Cc: EML TC <election-services@lists.oasis-open.org>
Sent: Wednesday, 8 November, 2006 2:33:06 PM
Subject: RE: [election-services] Fw: Report on the suitability of EML for the Norwegian electoral system.
John,
This is excellent work indeed.
Some comments -
1) I've seen a few times that people think that VToken is unique ID - rather than realizing it can also represent a
token that enables access to voting - and hence would be re-used by several voters in a polling station type
environment (e.g. randomly assigned scanned plastic access wand or smartcard key) - or even in a distributed
remote access election - may not necessarily uniquely ID - but simply verify their right to vote.
2) The counting process - the provisional count can use the same method we've used in our OpenScan EML
code - to ensure anonymous counting of initial ballots. Important from audit and ensuring trusted count.
The second step - the final count - with voter changes - is very interesting. We'd have to look at that
in more detail to see how that could be done in a way to provide audit and trust.
3) They are concerned about backward compatibility - I think we need to make clear that we have logical
backward compatibility - e.g. even if you have to make changes to your schema / XML - the content
itself should remain logically supported and enhanced. Unless of course we find that some technique
exposes risk of compromising either the vote or legal aspects - then you would expect them to make
changes to fix that. Going forward though - I think it's important for people to see that EML is stable
and that changes will be incremental. Right now people thinking they have to change everything
when we come out with a new version - just is not what I'm seeing as the case! (Section 3.1.2)
I guess this is also because their architecture is based on Java objects that then persist the XML,
whereas the approach in OpenScan is the reverse - the Java is driven by the XML - hence
dynamically the Java is adjusted by changes in the XML. Their use of XMLBeans re-inforces this
notion of static hard binding too. XMLBeans is also a convenient quick way for Java programmers
to handle XML - but in reality simple tokenizing code is sufficient - since XMLBeans is designed
for complex XML that can be factored out of your actual EML implementation.
This is also a question of trust and verification. Even though the source is open - its easier to
understand what is going on if the linkages and connections are exposed thru the XML and
the content in the XML - rather than thru hand cut Java code.
Page 76 shows we still need to refine the message. I'm not sure we really are wanting to have people
change the standard for all national sub-sets. I think it is OK for them to add unique items
occassionally. Obviously the message about publishing national subsets is not getting thru!
Simple change like adding Proposers Date of Birth however - seems like something 5.x could handle.
4) Page 77 - Again - because of the nature of the proportional counting - noting increase share of the poll?
Would this be handled by storing two copies? One from initial count - and then revised count?
But in any case - they ARE treating this as a local extension - cool!
5) I would be tempted to rely on Bronnesund Registry to ensure voter entitlement information.
The EML would be stored in the Registry - and then entitlement determined that way - either
through mailing out printed lists prior to election - or live connection. Prevents people voting
in more than one place.
6) Page 79 - this looks like something we should address in V5.x - ability to extend the information
on the ballot - I could see all kinds of local varients here - better to provide a means for
people to extend a TYPE here to be what they need...
7) Item 4.3.3 - what we do in OpenScan is pass in the tokenized anonymous list. So the counting
process has no knowledge of candidates - just IDRefs (this is like putting beans in numbered tins -
where you don't know what the tins actually are for). I'd recommend the same approach for Norway.
8) Item 4.5.1 - they need to break down the "one large doc" approach - XMLBeans again is causing
this to occur - whereas they could use lookups to minimize actual content in the XML. Again
re-count and audit strategies should be independent. This avoids creating a bottleneck. In
fact for a trusted audit - you NEED completely separate pathways!
Overall the conclusion appears to be sound - except for the fact that they need actual changes in our standard to proceed! Somehow we need to cross that bridge - so that adopters realize clearly what the process is here -and how they develop local implementations - with feedback to the next standard release.
Thanks, DW
-------- Original Message --------
Subject: [election-services] Fw: Report on the suitability of EML for
the Norwegian electoral system.
From: John Borras <johnaborras@yahoo.co.uk>
Date: Wed, November 08, 2006 6:22 am
To: EML TC <election-services@lists.oasis-open.org>
Colleagues
Please see the e-mail below. This report is a very thorough evaluation of EML in the Norwegian context, and in general, and raises several issues for our consideration. I would welcome your comments in the next couple of weeks before I see Gerhard at the Council of Europe meeting on Nov 23rd. (That meeting is to review the COE's Recommendation on e-Voting Standards.)
I do not propose that we delay version 5 any further to debate and accommodate the points raised in this report but we should table them for the next release.
Regards
John
M. +44 (0)7976 157745
----- Forwarded Message ----
From: Gerhard Skagestein <gerhard@ifi.uio.no>
To: johnaborras@yahoo.co.uk
Sent: Tuesday, 7 November, 2006 3:18:10 PM
Subject: Report on the suitability of EML for the Norwegian electoral system.
Dear John Borras,
I have noted that we are going to speak in the same session in the
Council of Europe meeting in Strasboug on November 23.
It may be of interest to you that we have had a master student investigating the suitability of EML for the Norwegian electoral system.
Her report may be found on
http://www.duo.uio.no/publ/informatikk/2005/28266/Documentation.pdf
Best regards
Gerhard Skagestein
Associate professor
Department of
Informatics
University of Oslo
Send instant messages to your online friends http://uk.messenger.yahoo.com