1 / 17

NIST Analysis on UOCAVA Relevant Schemas

NIST Analysis on UOCAVA Relevant Schemas. Carmelo Montanez National Institute of Standards and Technology http://vote.nist.gov. Relevant Schemas for IOCAVA. 310 – Voter Registration 410 – Ballot Definition 505 – Election Information Analysis was conducted on 505 Schema.

charla
Download Presentation

NIST Analysis on UOCAVA Relevant Schemas

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NIST Analysis on UOCAVA Relevant Schemas Carmelo Montanez National Institute of Standards and Technology http://vote.nist.gov

  2. Relevant Schemas for IOCAVA 310 – Voter Registration 410 – Ballot Definition 505 – Election Information Analysis was conducted on 505 Schema.

  3. Localities Structure

  4. Districts Structure

  5. Contests Structure

  6. Ballots Structure

  7. Candidates Structure

  8. Propositions Structure

  9. Polling Locations Structure

  10. Precinct Boundaries Structure

  11. Votes Results Structure

  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. 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. 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. 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. 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. Discussion

More Related