Re: [election-services] V7.1 draft updates - EML 310 - Voter Registration

[David Webber <david.webber@oracle.com>]

John,

???

I'm not seeing that is on the critical path.

We're working on the 3 member endorsements - we have 1 - 1 pending, and one more possible, so should be enough.

Obviously if Scytl play too - that is a bonus.

DW

----- Original Message -----
From: johnaborras@yahoo.co.uk
To: election-services@lists.oasis-open.org
Sent: Thursday, March 22, 2012 11:54:52 AM GMT -05:00 US/Canada Eastern
Subject: RE: [election-services] V7.1 draft updates - EML 310 - Voter Registration

OK but first things first and that's getting Scytl signed-up.  Without that it's all academic whether we do a 7.1 or not.

John


-----Original Message-----
From: David Webber [mailto:david.webber@oracle.com] 
Sent: 22 March 2012 15:26
To: johnaborras@yahoo.co.uk
Cc: election-services@lists.oasis-open.org
Subject: Re: [election-services] V7.1 draft updates - EML 310 - Voter Registration

John,

I believe the new ISO process can accommodate a submission with then technical maintenance updates inline with that.

Substantively we are not changing the foundation of V7.0 - just correcting some minor fixes.  This was the whole
basis of what the W3C worked out with ISO last year for coordinating technical XML standards work.

DW

----- Original Message -----
From: johnaborras@yahoo.co.uk
To: election-services@lists.oasis-open.org
Sent: Thursday, March 22, 2012 6:48:22 AM GMT -05:00 US/Canada Eastern
Subject: RE: [election-services] V7.1 draft updates - EML 310 - Voter Registration

David

See my specific replies in-line below.  On the general point about a draft 7.1, I would hope we do not have to process this in the foreseeable future as that would only delay our ISO submission even longer.  If we can get Scytl signed up fairly quickly we would be able to move on that but even so it could take 3-6 months.  So having a new version of EML appearing in that period would only confuse matters.  So if there are changes necessary for P1622 then we probably need to let them make them and then update EML some time thereafter.

John

-----Original Message-----
From: election-services@lists.oasis-open.org [mailto:election-services@lists.oasis-open.org] On Behalf Of David Webber
Sent: 21 March 2012 22:38
To: Election-Services
Subject: [election-services] V7.1 draft updates - EML 310 - Voter Registration

Folks - just did some analysis with implementers here in the USA for EML 310.

Once you sit down to work on actual use cases - gaps suddenly are so apparent where before there were none!

So - the idea is that the use case is one system sending another - voter registration details.  

This might be one state, sending another a new voter who is relocating, or could be within a state, the
post office sending updated information, new address, change of name, etc.

Or it could be a state, sending a voter their information to confirm and sign, or notification of 
polling place or ballot entitlement changes, and so on.

Today - the EML 310 seems to be a "delete all and replace" dataset - e.g. every voter in an election - 
what is needed is a surgical tool set - that can make incremental small changes and updates to specific voters.

The good news is that it appears the EML 310 is very close to be able to support these extended
use cases.  The changes and clarifications needed are:

1) Add a Status element to Voter after the DateTimeSubmitted element at the bottom

   Status values - New, Updated, Removed, Pending, Expired, Deceased

JB - From my recollection 310 was not built as a "delete all and replace".  I'm sure individual records could be processed for change as I remember we had included a set of change codes along the lines you have suggested.  Can you double-check this in v7 and in v5 before we proceed.  Maybe we've lost something along the way on this aspect.  

2) Add a @status attribute to VoterInformation / VoterIdentification elements.

   Status values - New, Updated, Removed, Pending, Expired

3) All VToken elements need to be a repeatable - right now they are simply optional; we need to be able to track multiple events and information exchanges in the extended use cases.

JB - this may not be true for all global jurisdictions so this is where EML may have to be specifically localised for P1622.

4) Question - what is the difference between VTokenQualified and VToken?  The definition text is obtuse - we need this more clearly explained in the text.

   We have VTokenQualified: VToken that is permitted to be used for the purpose and context of a particular process and event.

   And then VToken: A unique identifier for a device or entity involved in the voting process.

JB - John Ross is the person to answer this question as he came up with the whole vToken approach.

Can everyone review this and provide feedback.  If this all makes sense - I can raise appropriate change request tracking in JIRA and then we can determine
specific solution details.

Also - in thinking about this - does anyone else have other changes at this stage that make sense?

The time line on this is the next couple of weeks to provide feedback to the USA state development / design folks so they can incorporate the enhancements into what
they are doing as 7.1 draft changes.

Thanks, DW




---------------------------------------------------------------------
To unsubscribe, e-mail: election-services-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: election-services-help@lists.oasis-open.org


---------------------------------------------------------------------
To unsubscribe, e-mail: election-services-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: election-services-help@lists.oasis-open.org


---------------------------------------------------------------------
To unsubscribe, e-mail: election-services-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: election-services-help@lists.oasis-open.org