V7.1 draft updates - EML 310 - Voter Registration

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

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

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.

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.

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