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

["Zelechoski, Peter" <pzelechoski@essvote.com>]

Title: Message

David -

 

I finally have some time to review your 330-electionlist changes.

 

What P1622 is after from these changes is the ability to indicate in the election list (a list of those eligible to vote at the polling place, a.k.a. the poll book) the valid information for each voter. 

   1) We need to be able to tie the signature from the voter's registration form to the individual voter.   

   2) We also want to provide the voter id values that are on record for the individual so that they may be validated before allowing the voter to vote

      -- both 1 and 2 allow poll workers to verify the individual is who they say they are before they present the voter with their ballot forms

   3) We also need to be able to tie the ballot form (or forms) that the individual voter is allowed to be given, to the individual voter [in the US, there may be several different forms in a given polling location and not everyone gets the same forms so the poll book shows the specific forms for each individual].

 

This is what we had in mind.  Since I have not been involved in the core EML work, I can't claim to know this is the best way for these items, only that they match the needs from P1622's perspective. I believe you are intending to use VoterArtifact for the various binary images that can be used for validation (signature right now but possibly other later) -- that would change my "RegistrationSignature" element to VoterArtifact.  We do want to send back a captured signature image in voting history (that would be the image captured at the polling place (usually signing of the poll book), but that is a different path and we intend to have that as part of the VTokenLog/VToken [please refer to my reference embodiment document for further clarification]. I would be happy to talk with you anytime you want to email or phone.

 

  <ElectionList>
      <EventIdentifier Id="thiseventid"/>
      <VoterDetails>
          <VoterRegistration>
                          <!-- Repeat the Below Lines for each Voter -->
             <Voter>
                <VoterIdentification Id="12345678"> 
                  <VoterName>
                    <nl:NameLine>John Q Public</nl:NameLine>
                  </VoterName>
                  <ElectoralAddress>
                    <al:Address>123 Main Street, Hometown, AK 22034</al:Address>
                  </ElectoralAddress>
                  <VToken><Component Type="rtvid">12345xyz</Component></VToken>
                  <VoterIdentificationID IDType="TXDriversLicenseType" IDValue="12345678"/>
                  <VoterIdentificationID IDType="SSNType" IDValue="123456789"/>
               </VoterIdentification>
               <VoterInformation>
                 <DateOfBirth>2000-01-01</DateOfBirth>
                 <PreferredLanguage>en-us</PreferredLanguage>
                 <Affiliation>DEM</Affiliation>
                 <BallotFormIdentifier>abc</BallotFormIdentifier>
                 <RegistrationSignature>captured image of voter signature from registration form</RegistrationSignature>
              </VoterInformation>
           </Voter>
                          <!-- Repeat the Above Lines for each Voter -->
        </VoterRegistration>
     </VoterDetails>
  </ElectionList>
</EML>  

 

- Peter

-----Original Message-----
From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Monday, November 13, 2006 8:20 AM
To: Bernard Van Acker
Cc: eml
Subject: RE: [election-services] Revised EML 330 - Election List xsd

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