NIST Analysis on UOCAVA
Relevant Schemas
Carmelo Montanez
National Institute of Standards and Technology
http://vote.nist.gov
IEEE P1622 Meeting, Feb 2011
Relevant Schemas for IOCAVA



310 – Voter Registration
410 – Ballot Definition
505 – Election Information
Analysis was conducted on 505 Schema.
IEEE P1622 Meeting, Feb 2011
Page 2
Localities Structure
IEEE P1622 Meeting, Feb 2011
Page 3
Districts Structure
IEEE P1622 Meeting, Feb 2011
Page 4
Contests Structure
IEEE P1622 Meeting, Feb 2011
Page 5
Ballots Structure
IEEE P1622 Meeting, Feb 2011
Page 6
Candidates Structure
IEEE P1622 Meeting, Feb 2011
Page 7
Propositions Structure
IEEE P1622 Meeting, Feb 2011
Page 8
Polling Locations Structure
IEEE P1622 Meeting, Feb 2011
Page 9
Precinct Boundaries Structure
IEEE P1622 Meeting, Feb 2011
Page 10
Votes Results Structure
IEEE P1622 Meeting, Feb 2011
Page 11
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)
IEEE P1622 Meeting, Feb 2011
Page 12
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)
IEEE P1622 Meeting, Feb 2011
Page 13
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)
IEEE P1622 Meeting, Feb 2011
Page 14
Findings (4)



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)
IEEE P1622 Meeting, Feb 2011
Page 15
Findings (5)

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
IEEE P1622 Meeting, Feb 2011
Page 16
Discussion
IEEE P1622 Meeting, Feb 2011
Page 17