1. IEEE P1622 Meeting, Feb 2011 NIST Analysis on UOCAVA Relevant Schemas Carmelo Montanez National Institute of Standards and Technology http://vote.nist.gov

2. IEEE P1622 Meeting, Feb 2011 Page 2 Relevant Schemas for IOCAVA 310 – Voter Registration 410 – Ballot Definition 505 – Election Information Analysis was conducted on 505 Schema.

3. IEEE P1622 Meeting, Feb 2011Page 3 Localities Structure

4. IEEE P1622 Meeting, Feb 2011Page 4 Districts Structure

5. IEEE P1622 Meeting, Feb 2011Page 5 Contests Structure

6. IEEE P1622 Meeting, Feb 2011Page 6 Ballots Structure

7. IEEE P1622 Meeting, Feb 2011Page 7 Candidates Structure

8. IEEE P1622 Meeting, Feb 2011Page 8 Propositions Structure

9. IEEE P1622 Meeting, Feb 2011Page 9 Polling Locations Structure

10. IEEE P1622 Meeting, Feb 2011Page 10 Precinct Boundaries Structure

11. IEEE P1622 Meeting, Feb 2011Page 11 Votes Results Structure

12. IEEE P1622 Meeting, Feb 2011Page 12 Findings(1) Schema does not seems to specify who is running for what (example contest do not have pointers to candidate and candidate do not have references to contest) It is not clear where ballots are used (do you need to accommodate different ballots on different electoral districts?) Not placing any uniqueness constraints on Id’s (for instance five candidates can be given the same id)

13. IEEE P1622 Meeting, Feb 2011Page 13 Findings (2) No constraints put on references to other complex type instances (for instance a ballot candidateID candidate may point to something else other than a candidate) Some SimpleTypes should be split. (examples and alternatives given on separate document) Anonymous types are used extensively (in fact all complex types are anonymous)

14. IEEE P1622 Meeting, Feb 2011Page 14 Findings (3) Some Complex Types are assigned suboptimal parents Some child element types probably have the wrong multiplicity Some attributes use specialized types when they should be use standard types (for example for Line1Definition and Line2Definition)

15. IEEE P1622 Meeting, Feb 2011Page 15 Some attributes use standard types when they should used specialized types (for instance email can be assigned “Good Morning”) Some specialized types should be more constrained (for instance EmailDefinition again can have any value) Some simple types are based on the wrong standard type (for instance IssueDateDefinition based on xs:string and not on xs:date) Findings (4)

16. IEEE P1622 Meeting, Feb 2011Page 16 Not Involving Data Integrity Many simple types should be enumerations Telephone information can be better organized Unused namespaces prefixes add to complexity Unused imports add needless to complexity Schematron rules may be necessary to enforce constraints that can not be expressed in XML schemas Some documentation are so obvious that can be useless Findings (5)

17. IEEE P1622 Meeting, Feb 2011 Discussion Page 17