RE: [election-services] Revised EML 330 - Election List xsd

["David RR Webber \(XML\)" <david@drrw.info>]

Bernard,

 

Great questions - let me add some thoughts on my rationale here.

 

1) I believe we need to use VoterArtifact both scenarios and XML instances - one for when they register - and then the other when they actually ballot.  What is happening here in the US is that the pollbook tools are providing on-screen photos and signatures to the election official to verify manually - and then having the voter enter their signature and/or scan a registration card that should then match.  This VoterArtifact approach therefore covers those both - and is extensible - because who knows what we have next - finger prints, smartcard, cell phone certificates, GPS, other things.

 

2) It looks OK to me in OxygenXML - I see VoterIDAuthenticated just once (repeatable) under VoterDetails parent - in the graphical structure view.  I think we need repeatable - because they may want to check the photo, the signature and the registration card - so that's 3 items. 

 

The classic case of course is identical twins, or even triplets! Hopefully their names and signatures and ID cards are all different!!

 

3) BallotFormIdentifier - I'd anticipated this being a reference to the ballots that the voter is entitled to cast.  So yes - it is preparation phase details.  The two attributes then indicate if they are permitted to receive it (live in the correct election district, qualify, etc) and then the second attribute is used if they actually received that ballot (again there may be various reasons here - they did not want the ballot, or they ran out of printed ones, etc) - so implementers can track that - and then on the audit side this should tally with the total maximum # of cast ballots.

I believe this is the use cases the P1612 folks had in mind.  Is there anything else we need to take account of here?

 

Thanks, DW

-------- Original Message --------
Subject: Re: [election-services] Revised EML 330 - Election List xsd
From: Bernard Van Acker <bernard_vanacker@be.ibm.com>
Date: Mon, November 13, 2006 5:33 am
To: "David RR Webber (XML)" <david@drrw.info>


David,

Two-three questions, just to be sure I didn't miss something (didn't read the requested changes from IEEE P1612):

1) Concerning VoterArtifact: doesn't it fit even better in the VoterRegistration structure, since it is concerned only with registration?

2) Concerning VoterIDAuthenticated, don't we end up with with twice a VoterIdentification structure within Voterdetails: once within the voterregistration element, and once within the voterdetails element?

3) As to ="BallotFormIdentifier", just to be sure: this only indicates how the voter receives his ballot, and hence is only applicable to the preparation phase of the election, and not for the election itself, right?


Regards,

Bernard

Bernard Van Acker
Certified IS Security Professional
Associate IT Architect
IBM Global Business Services
tel ++32 2 225 2939 mobile ++32 496 84 62 60
e-mail: Bernard_Vanacker@be.ibm.com

"David RR Webber \(XML\)" <david@drrw.info>

11/11/2006 01:06

To	eml <election-services@lists.oasis-open.org>
cc
Subject	[election-services] Revised EML 330 - Election List xsd

Team,
 
I've just spent some hours getting the EML 330 updated for V5.0 - based on the requested changes from IEEE P1612 to support pollbook handling.
 
I've uploaded this to the TC documents section here:
http://www.oasis-open.org/apps/org/workgroup/election/download.php/21108/330-electionlist-v5-0.xsd
 
What takes the time is just finding existing type declarations and then hooking those into the new element, and extending it with additional attributes as needed - and getting the schema editor to check it is OK.
 
Anyway - please take a look.  You will find the top of the schema now has a comments section that calls out the changes added - elements and attributes.  Everything else is from v4.0 - I've not had to change those base schema includes to do this - aim is to re-use v4.0 as much as possible here.
 
Hopefully everyone concurs on the approach - I don't want to do the remaining changes before I've made sure I'm headed in the right direction first!
 
If everyone is happy with this - then I'll work on the other ones - hopefully this will move a bit faster now I've got one done!   I'm estimating I have another 5 or 6 to do to catch all the changes that have been asked for.
 
Thanks, DW