ࡱ > \ ^ U V W X Y Z [ a B D F H k k
q 5@ ҩ bjbj22 X X S " " " , 8 \ J
, ƿ Z " ^ / ' 6 d ž Ǿ Ǿ Ǿ Ǿ Ǿ Ǿ $ R - " B x B B Z h h h B D " ž h B ž h h j Y ! "
N it c\ t Q t4 r T ƿ v B )^
4
" ( "
D = > h =? l ? v = = = , , ć R d h ( , , R
EML Schema Descriptions
Version 4.0
OASIS Standard, 1st February 2006
Document identifier:
EML v4.0 Schema Descriptions
Editor:
e-Government Unit, Cabinet Office, UK
Contributors:
John Ross
Paul SpencerJohn BorrasFarah Ahmed Charbel AounBruce EltonJim ODonnelRoy HillBernard Van AckerHans von Spakovsky
Abstract:
This document contains the descriptions of the schemas used in EML v4.0. This document provides an explanation of the core schemas used throughout, definitions of the simple and complex datatypes, plus the EML schemas themselves. It also covers the conventions used in the specification and the use of namespaces, as well as the guidance on the constraints, extendibility, and splitting of messages.
Status:
This document is an OASIS Standard.
It is updated periodically on no particular schedule. Committee members should send comments on this specification to the HYPERLINK "mailto:election@lists.oasis-open.org"election@lists.oasis-open.org list. Others should subscribe to and send comments to the HYPERLINK "mailto:election-services-comment@lists.oasis-open.org"election-services-comment@lists.oasis-open.org. To subscribe, send an email message to HYPERLINK "mailto:election-comment-request@lists.oasis-open.org?body=subscribe"election-comment-request@lists.oasis-open.org with the word "subscribe" as the body of the message.For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Election and Voter Services TC web page ( HYPERLINK "http://www.oasis-open.org/committees/election/" http://www.oasis-open.org/committees/election/).
Table of Contents TOC \o "1-3" \h \z
HYPERLINK \l "_Toc94325461" 1 Introduction PAGEREF _Toc94325461 \h 6
HYPERLINK \l "_Toc94325462" 1.1 Background PAGEREF _Toc94325462 \h 6
HYPERLINK \l "_Toc94325463" 1.2 Viewing Schemas PAGEREF _Toc94325463 \h 7
HYPERLINK \l "_Toc94325464" 1.3 Schema Diagrams in this Document PAGEREF _Toc94325464 \h 7
HYPERLINK \l "_Toc94325465" 1.4 EML Message Validation PAGEREF _Toc94325465 \h 9
HYPERLINK \l "_Toc94325466" 1.5 Namespaces PAGEREF _Toc94325466 \h 9
HYPERLINK \l "_Toc94325467" 1.6 Extensibility PAGEREF _Toc94325467 \h 10
HYPERLINK \l "_Toc94325468" 1.7 Additional Constraints PAGEREF _Toc94325468 \h 10
HYPERLINK \l "_Toc94325469" 1.8 Conventions PAGEREF _Toc94325469 \h 10
HYPERLINK \l "_Toc94325470" 2 Processing using Schematron PAGEREF _Toc94325470 \h 11
HYPERLINK \l "_Toc94325471" 2.1 Validation using the Schematron Schemas PAGEREF _Toc94325471 \h 11
HYPERLINK \l "_Toc94325472" 3 Splitting of Messages PAGEREF _Toc94325472 \h 12
HYPERLINK \l "_Toc94325473" 4 Error Messages PAGEREF _Toc94325473 \h 13
HYPERLINK \l "_Toc94325474" 4.1 All Schemas PAGEREF _Toc94325474 \h 13
HYPERLINK \l "_Toc94325475" 4.1.1 XML well-formedness or Schema validation error PAGEREF _Toc94325475 \h 13
HYPERLINK \l "_Toc94325476" 4.1.2 Seal Errors PAGEREF _Toc94325476 \h 13
HYPERLINK \l "_Toc94325477" 4.1.3 EML Additional Rules PAGEREF _Toc94325477 \h 13
HYPERLINK \l "_Toc94325478" 5 EML Core Components PAGEREF _Toc94325478 \h 15
HYPERLINK \l "_Toc94325479" 5.1 Simple Data Types PAGEREF _Toc94325479 \h 16
HYPERLINK \l "_Toc94325480" 5.1.1 ConfirmationReferenceType PAGEREF _Toc94325480 \h 16
HYPERLINK \l "_Toc94325481" 5.1.2 CountingAlgorithmType PAGEREF _Toc94325481 \h 16
HYPERLINK \l "_Toc94325482" 5.1.3 DateType PAGEREF _Toc94325482 \h 16
HYPERLINK \l "_Toc94325483" 5.1.4 EmailType PAGEREF _Toc94325483 \h 16
HYPERLINK \l "_Toc94325484" 5.1.5 ErrorCodeType PAGEREF _Toc94325484 \h 17
HYPERLINK \l "_Toc94325485" 5.1.6 GenderType PAGEREF _Toc94325485 \h 17
HYPERLINK \l "_Toc94325486" 5.1.7 LanguageType PAGEREF _Toc94325486 \h 17
HYPERLINK \l "_Toc94325487" 5.1.8 MessageTypeType PAGEREF _Toc94325487 \h 17
HYPERLINK \l "_Toc94325488" 5.1.9 SealUsageType PAGEREF _Toc94325488 \h 17
HYPERLINK \l "_Toc94325489" 5.1.10 ShortCodeType PAGEREF _Toc94325489 \h 17
HYPERLINK \l "_Toc94325490" 5.1.11 TelephoneNumberType PAGEREF _Toc94325490 \h 17
HYPERLINK \l "_Toc94325491" 5.1.12 VotingChannelType PAGEREF _Toc94325491 \h 17
HYPERLINK \l "_Toc94325492" 5.1.13 VotingMethodType PAGEREF _Toc94325492 \h 18
HYPERLINK \l "_Toc94325493" 5.1.14 VotingValueType PAGEREF _Toc94325493 \h 18
HYPERLINK \l "_Toc94325494" 5.1.15 YesNoType PAGEREF _Toc94325494 \h 18
HYPERLINK \l "_Toc94325495" 5.2 Complex Data Types PAGEREF _Toc94325495 \h 18
HYPERLINK \l "_Toc94325496" 5.2.1 AffiliationIdentifierStructure PAGEREF _Toc94325496 \h 19
HYPERLINK \l "_Toc94325497" 5.2.2 AffiliationStructure PAGEREF _Toc94325497 \h 19
HYPERLINK \l "_Toc94325498" 5.2.3 AgentIdentifierStructure PAGEREF _Toc94325498 \h 19
HYPERLINK \l "_Toc94325499" 5.2.4 AgentStructure PAGEREF _Toc94325499 \h 20
HYPERLINK \l "_Toc94325500" 5.2.5 AreaStructure PAGEREF _Toc94325500 \h 20
HYPERLINK \l "_Toc94325501" 5.2.6 AuditInformationStructure PAGEREF _Toc94325501 \h 21
HYPERLINK \l "_Toc94325502" 5.2.7 AuthorityIdentifierStructure PAGEREF _Toc94325502 \h 21
HYPERLINK \l "_Toc94325503" 5.2.8 BallotIdentifierStructure PAGEREF _Toc94325503 \h 22
HYPERLINK \l "_Toc94325504" 5.2.9 BallotIdentifierRangeStructure PAGEREF _Toc94325504 \h 22
HYPERLINK \l "_Toc94325505" 5.2.10 CandidateIdentifierRangeStructure PAGEREF _Toc94325505 \h 22
HYPERLINK \l "_Toc94325506" 5.2.11 CandidateStructure PAGEREF _Toc94325506 \h 24
HYPERLINK \l "_Toc94325507" 5.2.12 ComplexDateRangeStructure PAGEREF _Toc94325507 \h 25
HYPERLINK \l "_Toc94325508" 5.2.13 ContactDetailsStructure PAGEREF _Toc94325508 \h 26
HYPERLINK \l "_Toc94325509" 5.2.14 ContestIdentifierStructure PAGEREF _Toc94325509 \h 26
HYPERLINK \l "_Toc94325510" 5.2.15 DocumentIdentifierStructure PAGEREF _Toc94325510 \h 26
HYPERLINK \l "_Toc94325511" 5.2.16 ElectionGroupStructure PAGEREF _Toc94325511 \h 27
HYPERLINK \l "_Toc94325512" 5.2.17 ElectionIdentifierStructure PAGEREF _Toc94325512 \h 27
HYPERLINK \l "_Toc94325513" 5.2.18 EmailStructure PAGEREF _Toc94325513 \h 28
HYPERLINK \l "_Toc94325514" 5.2.19 EMLstructure PAGEREF _Toc94325514 \h 28
HYPERLINK \l "_Toc94325515" 5.2.20 EventIdentifierStructure PAGEREF _Toc94325515 \h 29
HYPERLINK \l "_Toc94325516" 5.2.21 EventQualifierStructure PAGEREF _Toc94325516 \h 29
HYPERLINK \l "_Toc94325517" 5.2.22 IncomingGenericCommunicationStructure PAGEREF _Toc94325517 \h 30
HYPERLINK \l "_Toc94325518" 5.2.23 InternalGenericCommunicationStructure PAGEREF _Toc94325518 \h 31
HYPERLINK \l "_Toc94325519" 5.2.24 LogoStructure PAGEREF _Toc94325519 \h 31
HYPERLINK \l "_Toc94325520" 5.2.25 ManagingAuthorityStructure PAGEREF _Toc94325520 \h 32
HYPERLINK \l "_Toc94325521" 5.2.26 MessageStructure PAGEREF _Toc94325521 \h 32
HYPERLINK \l "_Toc94325522" 5.2.27 NominatingOfficerStructure PAGEREF _Toc94325522 \h 32
HYPERLINK \l "_Toc94325523" 5.2.28 OutgoingGenericCommunicationStructure PAGEREF _Toc94325523 \h 33
HYPERLINK \l "_Toc94325524" 5.2.29 PeriodStructure PAGEREF _Toc94325524 \h 34
HYPERLINK \l "_Toc94325525" 5.2.30 PictureDataStructure PAGEREF _Toc94325525 \h 34
HYPERLINK \l "_Toc94325526" 5.2.31 PollingDistrictStructure PAGEREF _Toc94325526 \h 35
HYPERLINK \l "_Toc94325527" 5.2.32 PollingPlaceStructure PAGEREF _Toc94325527 \h 35
HYPERLINK \l "_Toc94325528" 5.2.33 PositionStructure PAGEREF _Toc94325528 \h 36
HYPERLINK \l "_Toc94325529" 5.2.34 ProcessingUnitStructure PAGEREF _Toc94325529 \h 37
HYPERLINK \l "_Toc94325530" 5.2.35 ProposalIdentifierStructure PAGEREF _Toc94325530 \h 37
HYPERLINK \l "_Toc94325531" 5.2.36 ProposalStructure PAGEREF _Toc94325531 \h 37
HYPERLINK \l "_Toc94325532" 5.2.37 ProposerStructure PAGEREF _Toc94325532 \h 38
HYPERLINK \l "_Toc94325533" 5.2.38 ProxyStructure PAGEREF _Toc94325533 \h 39
HYPERLINK \l "_Toc94325534" 5.2.39 ReferendumOptionIdentifierStructure PAGEREF _Toc94325534 \h 40
HYPERLINK \l "_Toc94325535" 5.2.40 ReportingUnitIdentifierStructure PAGEREF _Toc94325535 \h 40
HYPERLINK \l "_Toc94325536" 5.2.41 ResponsibleOfficerStructure PAGEREF _Toc94325536 \h 41
HYPERLINK \l "_Toc94325537" 5.2.42 ScrutinyRequirementStructure PAGEREF _Toc94325537 \h 41
HYPERLINK \l "_Toc94325538" 5.2.43 SealStructure PAGEREF _Toc94325538 \h 41
HYPERLINK \l "_Toc94325539" 5.2.44 SimpleDateRangeStructure PAGEREF _Toc94325539 \h 42
HYPERLINK \l "_Toc94325540" 5.2.45 TelephoneStructure PAGEREF _Toc94325540 \h 42
HYPERLINK \l "_Toc94325541" 5.2.46 VoterIdentificationStructure PAGEREF _Toc94325541 \h 43
HYPERLINK \l "_Toc94325542" 5.2.47 VoterInformationStructure PAGEREF _Toc94325542 \h 44
HYPERLINK \l "_Toc94325543" 5.2.48 VTokenStructure PAGEREF _Toc94325543 \h 46
HYPERLINK \l "_Toc94325544" 5.2.49 VTokenQualifiedStructure PAGEREF _Toc94325544 \h 46
HYPERLINK \l "_Toc94325545" 5.3 Elements PAGEREF _Toc94325545 \h 48
HYPERLINK \l "_Toc94325546" 5.3.1 Accepted PAGEREF _Toc94325546 \h 48
HYPERLINK \l "_Toc94325547" 5.3.2 Election Statement PAGEREF _Toc94325547 \h 48
HYPERLINK \l "_Toc94325548" 5.3.3 MaxVotes PAGEREF _Toc94325548 \h 48
HYPERLINK \l "_Toc94325549" 5.3.4 MinVotes PAGEREF _Toc94325549 \h 48
HYPERLINK \l "_Toc94325550" 5.3.5 NumberInSequence PAGEREF _Toc94325550 \h 48
HYPERLINK \l "_Toc94325551" 5.3.6 NumberOfSequence PAGEREF _Toc94325551 \h 48
HYPERLINK \l "_Toc94325552" 5.3.7 PersonName PAGEREF _Toc94325552 \h 48
HYPERLINK \l "_Toc94325553" 5.3.8 Profile PAGEREF _Toc94325553 \h 48
HYPERLINK \l "_Toc94325554" 5.3.9 SequenceNumber PAGEREF _Toc94325554 \h 49
HYPERLINK \l "_Toc94325555" 5.3.10 TransactionId PAGEREF _Toc94325555 \h 49
HYPERLINK \l "_Toc94325556" 5.3.11 VoterName PAGEREF _Toc94325556 \h 49
HYPERLINK \l "_Toc94325557" 6 The EML Message Schemas PAGEREF _Toc94325557 \h 50
HYPERLINK \l "_Toc94325558" 6.1 Election Event (110) PAGEREF _Toc94325558 \h 51
HYPERLINK \l "_Toc94325559" 6.1.1 Description of Schema PAGEREF _Toc94325559 \h 53
HYPERLINK \l "_Toc94325560" 6.1.2 EML Additional Rules PAGEREF _Toc94325560 \h 54
HYPERLINK \l "_Toc94325561" 6.2 Inter Database (120) PAGEREF _Toc94325561 \h 54
HYPERLINK \l "_Toc94325562" 6.2.1 Description of Schema PAGEREF _Toc94325562 \h 54
HYPERLINK \l "_Toc94325563" 6.3 Response (130) PAGEREF _Toc94325563 \h 55
HYPERLINK \l "_Toc94325564" 6.3.1 Description of Schema PAGEREF _Toc94325564 \h 55
HYPERLINK \l "_Toc94325565" 6.3.2 Additional EML Rules PAGEREF _Toc94325565 \h 56
HYPERLINK \l "_Toc94325566" 6.4 Candidate Nomination (210) PAGEREF _Toc94325566 \h 57
HYPERLINK \l "_Toc94325567" 6.4.1 Description of Schema PAGEREF _Toc94325567 \h 57
HYPERLINK \l "_Toc94325568" 6.5 Response to Nomination (220) PAGEREF _Toc94325568 \h 59
HYPERLINK \l "_Toc94325569" 6.5.1 Description of Schema PAGEREF _Toc94325569 \h 59
HYPERLINK \l "_Toc94325570" 6.5.2 EML Additional Rules PAGEREF _Toc94325570 \h 59
HYPERLINK \l "_Toc94325571" 6.6 Candidate List (230) PAGEREF _Toc94325571 \h 60
HYPERLINK \l "_Toc94325572" 6.6.1 Description of Schema PAGEREF _Toc94325572 \h 60
HYPERLINK \l "_Toc94325573" 6.7 Voter Registration (310) PAGEREF _Toc94325573 \h 61
HYPERLINK \l "_Toc94325574" 6.7.1 Description of Schema PAGEREF _Toc94325574 \h 61
HYPERLINK \l "_Toc94325575" 6.7.2 EML Additional Rules PAGEREF _Toc94325575 \h 61
HYPERLINK \l "_Toc94325576" 6.8 Election List (330) PAGEREF _Toc94325576 \h 62
HYPERLINK \l "_Toc94325577" 6.8.1 Description of Schema PAGEREF _Toc94325577 \h 62
HYPERLINK \l "_Toc94325578" 6.8.2 EML Additional Rules PAGEREF _Toc94325578 \h 63
HYPERLINK \l "_Toc94325579" 6.9 Polling Information (340) PAGEREF _Toc94325579 \h 64
HYPERLINK \l "_Toc94325580" 6.9.1 Description of Schema PAGEREF _Toc94325580 \h 66
HYPERLINK \l "_Toc94325581" 6.10 Outgoing Generic Communication (350a) PAGEREF _Toc94325581 \h 68
HYPERLINK \l "_Toc94325582" 6.10.1 Description of Schema PAGEREF _Toc94325582 \h 68
HYPERLINK \l "_Toc94325583" 6.11 Incoming Generic Communication (350b) PAGEREF _Toc94325583 \h 69
HYPERLINK \l "_Toc94325584" 6.11.1 Description of Schema PAGEREF _Toc94325584 \h 69
HYPERLINK \l "_Toc94325585" 6.12 Internal Generic (350c) PAGEREF _Toc94325585 \h 70
HYPERLINK \l "_Toc94325586" 6.12.1 Description of Schema PAGEREF _Toc94325586 \h 70
HYPERLINK \l "_Toc94325587" 6.13 Outgoing Channel Options (360a) PAGEREF _Toc94325587 \h 71
HYPERLINK \l "_Toc94325588" 6.13.1 Description of Schema PAGEREF _Toc94325588 \h 71
HYPERLINK \l "_Toc94325589" 6.14 Incoming Channel Options (360b) PAGEREF _Toc94325589 \h 72
HYPERLINK \l "_Toc94325590" 6.14.1 Description of Schema PAGEREF _Toc94325590 \h 72
HYPERLINK \l "_Toc94325591" 6.15 Ballots (410) PAGEREF _Toc94325591 \h 73
HYPERLINK \l "_Toc94325592" 6.15.1 Description of Schema PAGEREF _Toc94325592 \h 75
HYPERLINK \l "_Toc94325593" 6.16 Authentication (420) PAGEREF _Toc94325593 \h 76
HYPERLINK \l "_Toc94325594" 6.16.1 Description of Schema PAGEREF _Toc94325594 \h 76
HYPERLINK \l "_Toc94325595" 6.17 Authentication Response (430) PAGEREF _Toc94325595 \h 77
HYPERLINK \l "_Toc94325596" 6.17.1 Description of Schema PAGEREF _Toc94325596 \h 77
HYPERLINK \l "_Toc94325597" 6.18 Cast Vote (440) PAGEREF _Toc94325597 \h 78
HYPERLINK \l "_Toc94325598" 6.18.1 Description of Schema PAGEREF _Toc94325598 \h 78
HYPERLINK \l "_Toc94325599" 6.19 Retrieve Vote (445) PAGEREF _Toc94325599 \h 79
HYPERLINK \l "_Toc94325600" 6.19.1 Description of Schema PAGEREF _Toc94325600 \h 79
HYPERLINK \l "_Toc94325601" 6.20 Vote Confirmation (450) PAGEREF _Toc94325601 \h 80
HYPERLINK \l "_Toc94325602" 6.20.1 Description of Schema PAGEREF _Toc94325602 \h 80
HYPERLINK \l "_Toc94325603" 6.21 Votes (460) PAGEREF _Toc94325603 \h 81
HYPERLINK \l "_Toc94325604" 6.21.1 Description of Schema PAGEREF _Toc94325604 \h 82
HYPERLINK \l "_Toc94325605" 6.22 VToken Log (470) PAGEREF _Toc94325605 \h 83
HYPERLINK \l "_Toc94325606" 6.22.1 Description of Schema PAGEREF _Toc94325606 \h 83
HYPERLINK \l "_Toc94325607" 6.23 Audit Log (480) PAGEREF _Toc94325607 \h 84
HYPERLINK \l "_Toc94325608" 6.23.1 Description of Schema PAGEREF _Toc94325608 \h 85
HYPERLINK \l "_Toc94325609" 6.24 Count (510) PAGEREF _Toc94325609 \h 87
HYPERLINK \l "_Toc94325610" 6.24.1 Description of Schema PAGEREF _Toc94325610 \h 88
HYPERLINK \l "_Toc94325611" 6.25 Result (520) PAGEREF _Toc94325611 \h 89
HYPERLINK \l "_Toc94325612" 6.25.1 Description of Schema PAGEREF _Toc94325612 \h 89
HYPERLINK \l "_Toc94325613" 6.26 Options Nomination (610) PAGEREF _Toc94325613 \h 90
HYPERLINK \l "_Toc94325614" 6.26.1 Description of Schema PAGEREF _Toc94325614 \h 90
HYPERLINK \l "_Toc94325615" 6.27 Options Nomination Response (620) PAGEREF _Toc94325615 \h 91
HYPERLINK \l "_Toc94325616" 6.27.1 Description of Schema PAGEREF _Toc94325616 \h 91
HYPERLINK \l "_Toc94325617" 6.27.2 EML Additional Rules PAGEREF _Toc94325617 \h 91
HYPERLINK \l "_Toc94325618" 6.28 Options List (630) PAGEREF _Toc94325618 \h 92
HYPERLINK \l "_Toc94325619" 6.28.1 Description of Schema PAGEREF _Toc94325619 \h 92
HYPERLINK \l "_Toc94325620" 7 References PAGEREF _Toc94325620 \h 93
HYPERLINK \l "_Toc94325621" Notices PAGEREF _Toc94325621 \h 94
Introduction
This document describes the OASIS Election Mark-up Language (EML) version 4.0 schemas.
The messages that form part of EML are intended for transfer between systems. It is not intended that all outputs of a registration or election system will have a corresponding schema.
This document and its accompanying set of schemas do not claim to satisfy the final requirements of a registration or election system. It is incumbent on the users of this document to identify any mistakes, inconsistencies or missing data and to propose corrections to the OASIS Election and Voter Services Technical Committee.
Background
The following is the Executive Summary of the EML Process & Data Requirements:
OASIS, the XML interoperability consortium, formed the Election and Voter Services Technical Committee in the spring of 2001 to develop standards for election and voter services information using XML. The committees mission statement is, in part, to:
Develop a standard for the structured interchange among hardware, software, and service providers who engage in any aspect of providing election or voter services to public or private organizations.
The objective is to introduce a uniform and reliable way to allow election systems to interact with each other. The overall effort attempts to address the challenges of developing a standard that is:
- Multinational: our aim is to have these standards adopted globally
- Flexible: effective across the different voting regimes. E.g. proportional representation or first past the post.
- Multilingual: flexible enough to accommodate the various languages and dialects and vocabularies.
- Adaptable: resilient enough to support elections in both the private and public sectors.
- Secure: able to secure the relevant data and interfaces from any attempt at corruption, as appropriate to the different requirements of varying election rules.
The primary deliverable of the committee the Election Mark-up Language (EML). This is a set of data and message definitions described as XML schemas. At present EML includes specifications for:
- Candidate Nomination, Response to Nomination and Approved Candidate Lists
- Voter Registration information, including eligible voter lists
- Various communications between voters and election officials, such polling information, election notices, etc.
- Logical Ballot information (races, contests, candidates, etc.)
- Voter Authentication
- Vote Casting and Vote Confirmation
- Election counts and results
- Audit information pertinent to some of the other defined data and interfaces
As an international specification, EML is generic in nature, and so needs to be tailored for specific scenarios. Some aspects of the language are indicated in EML as required for all scenarios and so can be used unchanged. Some aspects (such as the ability to identify a voter easily from their vote) are required in some scenarios but prohibited in others, so EML defines them as optional. Where they are prohibited, their use must be changed from an optional to prohibited classification, and where they are mandatory, their use must be changed from an optional to required classification.
Viewing Schemas
EML schemas are supplied as text documents. For viewing the structure of the schemas, we recommend use of one of the many schema development tools available. Many of these provide graphical displays.
The Schematron schemas are mainly short and simple to understand as text documents for those with a working knowledge of XPath [ REF _Ref22012624 \r \h \* MERGEFORMAT 4].
Schema Diagrams in this Document
The schema diagrams in this document were created using XML Spy 2004. The following is a guide to their interpretation.
In this section, terms with specific meanings in XML or XML Schema are shown in italics, e.g. sequence.
Note that the diagrams in this document do not use the default diagramming options of XML Spy, but have additional information. The additional information to be shown can be set using the menu selections Schema Design | View Config.
In this section, and throughout this document, the prefix "xs" denotes the XML schema namespace http://www.w3.org/2001/XMLSchema.
The diagram below represents a simple schema. The root element of an instance described by this schema is the element A. The content model of this element is a sequence of the elements B, D and E. The element B is of complex data type Bstructure. This contains a choice of either element C or element F. Element C is a restriction of another complex data type Cstructure. In this case, the restriction is to forbid the use of the element G (which is defined in Cstructure as optional). The other elements allowed are H, which can appear any number of times (but must appear at least once), and I, which can appear up to three times (or not at all). Element D is optional, and of data type Dstructure. This has a content model requiring all of elements J and K, which are both of type xs:string. Finally, element E is of simple data type Etype, which is restricted from the xs:NMTOKEN data type by only allowing the values yes and no.
It is important to remember that these diagrams do not include any attributes. In this document, these are shown in tables below the diagrams.
The full schema is shown below the diagram.
EML Message Validation
It is up to each specific system implementation whether it uses these schemas for validation of EML messages for either testing or live use. The recommended approach is to validate incoming messages against the EML schemas (with the application-specific EML externals schema), then further validate against the relevant Schematron schema. The first stage requires the use of an XML processor (parser) that conforms to W3C XML Schema. The second stage requires either an XSLT processor or a dedicated Schematron processor.
However, an implementation may choose to:
modify the EML schemas to incorporate those application-specific constraints that can be represented in W3C XML Schema;
not validate the rules that are encoded as Schematron schemas;
not perform any validation; or
develop some alternative validation.
Namespaces
The message schemas and the core schema are associated with the namespace urn:oasis:names:tc:evs:schema:eml. This is defined using the prefix eml. The XML Schema namespace http://www.w3c.org/2001/XMLSchema is identified by the prefix xs and the XML Schema Instance namespace http://www.w3.org/2001/XMLSchema-instance by the prefix xsi.
Use is also made of namespaces for the Extensible Name and Address Language (xNAL). The Extensible Name Language namespace urn:oasis:tc:ciq:xsdschema:xNL:2.0 is identified by the prefix xnl, and the Extensible Language namespace urn:oasis:names:tc:ciq:xsdschema:xAL:2.0 by the prefix xal.
Extensibility
Various elements allow extensibility through the use of the xs:any element. This is used both for display information (for example, allowing the sending of HTML in a message) and for local extensibility. Note that careless use of this extensibility mechanism could reduce interoperability.
Additional Constraints
The EML schemas provide a set of constraints common to most types of elections worldwide. Each specific election type will require additional constraints, for example, to enforce the use of a seal or to ensure that a cast vote is anonymous. It is recommended that these additional constraints be expressed using the Schematron language. This allows additional constraints to be described without altering or interacting with the EML schemas. Any document that is valid to a localization expressed in Schematron must also be a valid EML document.
Conventions
Within this specification, the following conventions are used throughout:
Diagrams are shown as generated by XML Spy 2004 which was also used to generate the schemas and samples. These diagrams show element content, but not attributes
Elements and attributes in schemas are identified by partial XPath expressions. Enough of a path is used to identify the item without putting in a full path.
Processing using Schematron
This section gives a short introduction to how validation can be achieved using Schematron schemas and an XSLT processor. Alternatively, direct validation using the Schematron schemas can be achieved using a dedicated Schematron processor.
Validation using the Schematron Schemas
A Schematron schema is an XML document that can be converted to XSLT using an XSLT stylesheet. There is a published stylesheet (skeleton1-5.xslt) that can be used to achieve this. This produces an HTML output from the validation. A separate stylesheet can be produced that will create an output to the specification below. This stylesheet can import the skeleton and just over-ride those aspects where changes are required.
This stylesheet can be used once on each Schematron schema to produce the XSLT file that will be used for validating a specific message type. This stylesheet is then used to transform the incoming EML message into an error report based on the additional constraints.
The process is shown in the diagram below.
EMBED Visio.Drawing.6
Splitting of Messages
There is sometimes a need to split long messages into several parts. By their nature, each of these messages will contain a small amount of background information and a single element type that is repeated many times. For example, the 330-electionlist message can have many VoterDetails elements.
When a message is split, each part must be a complete, valid message. This will contain all the background information with a number of the repeated element types. Information in the EML element indicates the sequence number of the message and the number of messages in the sequence. Each message in the sequence must contain the same TransactionId, and must indicate the repeated element according to the table below. Only the messages shown in the table may be split in this way.
MessageRepeated Element330-electionlistVoterDetails340-pollinginformationPolling410-ballotsBallot460-votesCastVote470-vtokenlogVTokens480-auditlogLoggedSealFor ease of implementation, a message that can be split may contain the elements used for splitting even if the entire message is sent in one piece. In this case, the values of SequenceNumber and NumberInSequence will both be "1".
Error Messages
The 130 schema is used to define a message for reporting errors in EML messages.
Error messages are given codes. These fall into one of five series:
1000XML well-formedness or Schema validation error2000Seal error3000EML rule error4000 Localization rule error5000System specific errorIf the error type is not message-specific (or is a general rule applying to several schemas), the series reference above is used. If it is message-specific, the last three digits of the error series (and possibly a final alpha character) reflect the message type. A three digit error code is appended to the series code, separated by a hyphen.
An error code relating to a localization applicable to all message types could therefore be 4000-001. One specific to the localization of schema 110 could be 4110-002.
All Schemas
XML well-formedness or Schema validation error
Error codeError Description1000-001Message is not well-formed1000-002Message is not validSeal Errors
Error codeError Description2000-001The Seal does not match the dataEML Additional Rules
The following rules apply to messages regardless of localization. One of the two rules on splitting will apply to each message type as described in the table below.
Error CodeError Description3000-001If there are processing units in the AuditInformation, one must have the role of sender3000-002If there are processing units in the AuditInformation, one must have the role of receiver3000-003This message must not contain the elements used for splitting3000-004The value of the Id attribute of the EML element is incorrect3000-005The message type must match the Id attribute of the EML element3000-006All messages that are split must include the correct sequenced element name.
3 0 0 0 - 0 0 3 3 0 0 0 - 0 0 6 1 1 0 1 2 0 1 3 0 2 1 0 2 2 0 2 3 0 3 1 0 3 3 0 3 4 0 3 5 0 a 3 5 0 b 3 5 0 c 3 6 0 a 3 6 0 b 4 1 0 4 2 0 4 3 0 4 4 0 4 4 5 4 5 0 4 6 0 4 7 0 4 8 0 5 1 0 5 2 0 6 1 0 6 2 0 6 3 0 E M L C o r e Components
The core schema contains elements and data types that are used throughout the e-voting schemas.
To help message schema diagrams fit on the page, these elements and data types are not expanded each time they appear in other diagrams.
The following schema components are defined in the EML core.
ElementsComplex Data TypesSimple Data TypesAcceptedAffiliationIdentifierStructureConfirmationReferenceTypeAffiliationAffiliationStructureCountingAlgorithmTypeAffiliationIdentifierAgentIdentifierStructureDateTypeAgentAgentStructureEmailTypeAgentIdentifierAreaStructureErrorCodeTypeAreaAuditInformationStructureGenderTypeAuditInformationAuthorityIdentifierStructureLanguageTypeAuthorityIdentifierBallotIdentifierRangeStructureMessageTypeTypeBallotIdentifierBallotIdentifierStructureSealUsageTypeBallotIdentifierRangeCandidateIdentifierStructureShortCodeTypeCandidateCandidateStructureTelephoneNumberTypeCandidateIdentifierComplexDateRangeStructureVotingChannelTypeContactDetailsContactDetailsStructureVotingMethodTypeContestIdentifierContestIdentifierStructureVotingValueTypeCountingAlgorithmDocumentIdentifierStructureYesNoTypeDocumentIdentifierElectionGroupStructureElectionIdentifierElectionIdentifierStructureElectionStatementEmailStructureEventIdentifierEMLStructureEventQualifierEventIdentifierStructureGenderEventQualifierStructureLogoIncomingGenericCommunicationStructureManagingAuthorityInternalGenericCommunicationStructureMaxVotesLogoStructureMessageTypeManagingAuthorityStructureMinVotesMessagesStructureNominatingOfficerNominatingOfficerStructureNumberInSequenceOutgoingGenericCommunicationStructureNumberOfPositionsPeriodStructurePeriodPictureDataStructurePersonNamePollingDistrictStructurePollingDistrictPollingPlaceStructurePollingPlacePositionStructurePositionProcessingUnitStructurePreviousElectoralAddressProposalIdentifierStructureProfileProposalStructureProposalProposerStructureProposalIdentifierProxyStructureProposerReferendumOptionIdentifierStructureProxyReportingUnitIdentifierStructureReferendumOptionIdentifierResponsibleOfficerStructureReportingUnitIdentifierScrutinyRequirementStructureResponsibleOfficerSealStructureScrutinyRequirementSimpleDateRangeStructureSealTelephoneStructureSequenceNumberVoterIdentificationStructureTransactionIdVoterInformationStructureVoterNameVTokenStructureVotingChannelVTokenQualifiedStructureVotingMethodVTokenVTokenQualifiedSimple Data Types
The simple data types are included here with their base data types and any restrictions applied.
ConfirmationReferenceType
xs:token.
The reference generated once the confirmation of a vote has been completed.
CountingAlgorithmType
xs:token
The method of counting used for more complex forms of election.
DateType
Union of xs:date and xs:dateTime
There are several possible dates associated with an election. Some of these can be either just a date or have a time associated with them. These can use this data type.
EmailType
xs:token with restrictions.
Restrictions: xs:maxLength: 129 xs:pattern: [^@]+@[^@]+
This type is a simple definition of an email address, pending a more complete description that is widely accepted in industry and government. It allows any characters except the @ symbol, followed by an @ symbol and another set of characters excluding this symbol.
ErrorCodeType
xs:token
One of a pre-defined set of error codes as described in the section "Error Messages.
GenderType
xs:token with restrictions.
Restrictions: xs:enumeration: male, female, unknown
The gender of a voter or candidate. Options are male, female or unknown (unknown is not allowed in all contexts).
LanguageType
xs:language
Declaration of the type of language used in the election.
MessageTypeType
xs:NMTOKEN
This is the alphanumeric type of the message (e.g. 440 or 350a). This may be required for audit purposes.
SealUsageType
xs:NMTOKEN with restrictions.
Restrictions: xs:enumeration: receiver, sender
Indicates whether a device logging a seal was the sender or receiver of the seal.
ShortCodeType
xs:NMTOKEN
This identifies an aspect of the election (such as a contest or candidate) when voting using SMS or other voting mechanisms where a short identifier is required.
TelephoneNumberType
xs:token with restrictions.
Restrictions: xs:maxLength: 35 xs:minLength: 1 xs:pattern: \+?[0-9\(\)\-\s]{1,35}
Since this must allow for various styles of international telephone number, the pattern has been kept simple. This allows an optional plus sign, then between 1 and 35 characters with a combination of digits, brackets, the dash symbol and white space. If a more complete definition becomes widely accepted in industry and government, this will be adopted.
VotingChannelType
xs:token with restrictions.
Restrictions: xs:enumeration: SMS, WAP, digitalTV, internet, kiosk, polling, postal, telephone, other
This type exists to hold the possible enumerations for the channel through which a vote is cast.
SMS is the Short Message Service (text message). WAP is the Wireless Access Protocol.
If other is used, it is assumed that those managing the election will have a common understanding of the channel in use.
VotingMethodType
xs:token with restrictions.
Restrictions: xs:enumeration: AMS, FPP, OPV, SPV, STV, approval, block, partylist, supplementaryvote, other
The VotingMethod type holds the enumerated values for the type of election (such as first past the post or single transferable vote). The meanings of the acronyms are:
AMS Additional Member System
FPP - First Past the Post
OPV - Optional Preferential Voting
SPV - Single Preferential Vote
STV - Single Transferable Vote
VotingValueType
xs:positiveInteger.
Indicates a value assigned when voting for a candidate or referendum option. This might be a weight or preference order depending on the election type.
YesNoType
xs:token with restrictions.
Restrictions: xs:enumeration: no, yes
This is a simple enumeration of yes and no and is used for elements and attributes that can only take these binary values.
Complex Data Types
The choice between defining an element or a data type for a reusable message component is a significant design issue. It is widely accepted as good practice to use element declarations when there is good reason to always refer to an element by the same name and there is no expectation of a need to derive new definitions. In all other cases, data type declarations are preferable. The term schema component is used to refer to elements and data types collectively.
When defining a complete mark-up language, limiting the use of elements and types can restrict further development of the language. For that reason, both data types and elements are defined in EML. Only where an element is an example of a primitive or derived data type defined in XML Schema part 2 is no explicit data type defined within EML.
In use, it is expected that, for example:
A voting token will always have an element name VToken and so will use the element name;
A logo or a map have similar definitions, so both use the PictureDataStructure. There is no PictureData element.
Within voter identification, some elements will usually need to be made mandatory and so a schema will specify a new element based on the VoterIdentificationStructure data type.
AffiliationIdentifierStructure
ElementAttributeTypeUseCommentAffiliationIdentifierStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalShortCodeShortCodeTypeoptionalExpectedConfirmationReferenceConfirmationReferenceTypeoptionalThis data type is used to identify an affiliation, such as a political party. The identifier indicates the official name and ID of the organization. It supports use of a short code for voting systems such as SMS, and an expected confirmation reference for security systems that require this.
AffiliationStructure
AffiliationStructure data type indicates membership of some organization such as a political party. The description will normally be used to indicate the name usually associated with the organization, and so is the value that will usually be shown on a ballot. An organization may indicate several logos, each with a rle. For example, one rle might indicate that the logo should be used on a ballot paper. Each logo can be identified by a URL or sent as a Base64 encoded binary value. In the latter case, the format of the logo (BMP, TIFF, PNG, GIF or JPEG) must be indicated.
AgentIdentifierStructure
ElementAttributeTypeUseCommentAgentIdenttifierStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalThe agent identifier contains a name and ID. The data type for the name is localized using the EML externals schema.
AgentStructure
ElementAttributeTypeUseCommentAgentStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalRolexs:tokenoptionalA candidate in an election can have one or more agents, each agent having a specific rle, identified by the Role attribute. For example, an agent may be allowed access to the count, but not to amend details of the candidate.
The agent has an identifier, comprising a name and ID, and an affiliation. He or she also has an official address and a standard set of contact details.
AreaStructure
The AreaStructure is an extension of xs:token to add the following attributes:
ElementAttributeTypeUseCommentAreaStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalTypexs:tokenoptionalThis data type is used to define elements defining the geographical area covered by a contest. The Type attribute is used to indicate the type of area, such as "county".
AuditInformationStructure
ElementAttributeTypeUseCommentOtherRolexs:token (restricted) requiredStandard attribute for a ProcessingUnitStructureTypexs:tokenrequiredAdditional attribute for this elementThe AuditInformationStructure is used to define an element to provide information for audit purposes. It allows the voting channel in use to be described, with the identities of those devices that have participated in the message being sent. Each device has an attribute to describe its rle (see ProcessingUnitStructure).
Where a device does not fit any of the categories here, it can be described as Other with the addition of a Type attribute.
AuthorityIdentifierStructure
The AuthorityIdentifierStructure is an extension of xs:token to add the following attributes:
ElementAttributeTypeUseCommentAuthorityIdentifierStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalThis data type defines information to identify an election authority. This may include a system ID and text description.
BallotIdentifierStructure
ElementAttributeTypeUseCommentBallotIdentifierStructureIdxs:NMTOKENrequiredDisplayOrderxs:positiveIntegeroptionalThis data type is used to define an element that is an identifier for a ballot. This will usually use the Id attribute as the identifier, but might use a name to indicate a set of identical ballots. Elements using this data type will usually only be used for paper ballots.
BallotIdentifierRangeStructure
ElementAttributeTypeUseCommentBallotIdentifierRangeStructureColourxs:tokenoptional
This data type is used to define an element that identifies a range of ballots. This might be used, for example, to assign ranges of ballot identifiers to different reporting units for a contest. It is unlikely that the ballot name would be used when defining range, the Id attribute being used instead. Elements using this data type will usually only be used for paper ballots.
CandidateIdentifierRangeStructure
ElementAttributeTypeUseCommentCandidateIdentifierStructureIdxs:NMTOKENrequiredDisplayOrderxs:positiveIntegeroptionalShortCodeShortCodeTypeoptionalExpectedConfirmationReferenceConfirmationReferenceTypeoptionalThe candidate identifier indicates a system ID for the candidate and the candidate's name as it will appear in a ballot. Sometimes an additional line is required on the ballot to help identify the candidate. This will use the KnownAs element of the candidate identifier. A short code can also be included, either for SMS voting or where the security mechanism in place requires it. An ExpectedConfirmationReference attribute also allows for security mechanisms where the confirmation reference may be different for each combination of voter and candidate.
CandidateStructure
ElementAttributeTypeUseCommentCandidateStructureIndependentYesNoTypeoptionalDisplayOrderxs:positiveIntegeroptionalThe candidate description includes all the information required about the candidate. In different messages, the amount of information is reduced, either by restricting the information in EML or as part of a localization.
The candidate has an identifier. The full name of the candidate may also be provided, and whether the candidate is an independent. This is supplied as an attribute rather than affiliation as certain election types treat independents differently from other candidates, even though they may define an affiliation.
The candidate profile describes the candidate. The election statement describes the opinions of the candidate. Optionally, a photo may be included, either as a link or as Base64 encoded binary.
ComplexDateRangeStructure
ElementAttributeTypeUseCommentComplexDateRangeStructureTypexs:tokenrequiredThis data type is used to describe ranges of dates or dates and times. Each date can be a single date, a start date, an end date or include both start and end dates.
The Type attribute is used to indicate the purpose of the date (e.g. "deadline for nominations"). It is likely that this will be removed before release of EML version 4 and applied to elements instead as an extension of this data type.
ContactDetailsStructure
ElementAttributeTypeUseCommentContactDetailsStructureDisplayOrderxs:positiveIntegeroptionalThis data type is used in many places throughout the EML schemas. The mailing address uses whatever format is defined in the EML externals schema document. Where several addresses or numbers can be given (for example, email addresses), there is a facility to indicate whichever is preferred. The overall preferred method of contact can also be provided by placing an XPath to the preferred method in the PreferredContact element.
ContestIdentifierStructure
ElementAttributeTypeUseCommentContestIdentifierStructureIdxs:NMTOKENrequiredDisplayOrderxs:positiveIntegeroptionalShortCodeShortCodeTypeoptionalThis data type is used to define an element that is an identifier for a contest. It holds a name and ID. A short code can also be included, for example, for SMS voting.
DocumentIdentifierStructure
The DocumentIdentifierStructure is an extension of xs:token to add the following attribute:
ElementAttributeTypeUseCommentDocumentIdentifierStructureHrefxs:anyURIrequired
This allows identification of external documents relating to an event, election or contest. The document can have a name and URL.
ElectionGroupStructure
The ElectionGroupStructure is an extension of xs:token to add the following attribute:
ElementAttributeTypeUseCommentDocumentIdentifierStructureIdxs:tokenrequiredThe election group is used to group a number of elections together. This could be required, for example, under the additional member system, where two elections are held, the result of one influencing the result of the other. It could also be used at a company AGM, where proposals might be grouped for display purposes.
ElectionIdentifierStructure
ElementAttributeTypeUseCommentElectionIdentifierStructureIdxs:NMTOKENrequiredDisplayOrderxs:positiveIntegeroptionalShortCodeShortCodeTypeoptionalThe election identifier is used wherever the election needs to be specified. There is an Id attribute, which can often be used on its own to identify the election. In other cases, particularly where the content of a message is to be displayed, the election name can also be provided. The election group is used to group a number of elections together as described above.
The election category is used in messages where several elections are included in the message, but may be treated differently under localisation rules. Each election that requires different treatment will be given a category unique within that election event, allowing a Schematron processor to distinguish between the elections.
EmailStructure
The EmailStructure is an extension of the EmailType to add the following attribute:
ElementAttributeTypeUseCommentEmailStructurePreferredYesNoTypeoptionalThe Preferred attribute is used to distinguish which of several email addresses to use.
EMLstructure
ElementAttributeTypeUseCommentEMLstructureIdMessageTypeTyperequiredSchemaVersionxs:NMTOKENrequriedShortCodeShortCodeTypeoptionalStylesheetTypexs:tokenrequiredThe EML element defined by this data type forms the root element of all EML documents. The transaction ID is used to group messages together, for example, when they are split using the message splitting mechanism. This mechanism is implemented using the next three elements. The optional message language indicates the language of the message using ISO 639 three letter language codes, while the requested response language can be used to indicate the preferred language for a response. This element is used in messages from the voter or candidate to the election organizers.
The display element allows the definition of stylesheets to display the message. Multiple stylesheets can be declared. When displaying on the web, the first is likely to be an XSLT stylesheet, while the second might describe a CSS stylesheet to be incorporated as well. The Type attribute of the Stylesheet element should contain a media types as defined in RFC 2046 Pt 2 [ REF _Ref78185080 \r \h 1] using the list of media types defined by IANA [ REF _Ref78185112 \r \h 2], for example, text/xsl. The final element defined is the seal, which is used to seal the complete message.
EventIdentifierStructure
ElementAttributeTypeUseCommentEventIdentifierStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalThe event identifier is used wherever the election event needs to be specified. There is an Id attribute, which can often be used on its own to identify the event. In other cases, particularly where the content of a message is to be displayed, the event name can also be provided. The event qualifier is used to further identify the event.
EventQualifierStructure
The EventQualifierStructure is an extension of xs:token to add the following attribute:
ElementAttributeTypeUseCommentEventQualifierStructureIdxs:NMTOKENoptionalThe event qualifier is used to further identify the event. For example, there might be "County Elections" covering an entire country, but the events are organized at a county level, so the event qualifier would identify the county.
IncomingGenericCommunicationStructure
This data type provides a common structure for incoming communications. Individual message types, such as that used for selecting a preferred voting channel (schema 360b) are based on extensions of this type.
InternalGenericCommunicationStructure
This data type provides a common structure for communications between entities involved in the organization of an election. Individual message types are based on extensions of this type. The sender and recipient can use any elements defined within EML.
LogoStructure
The LogoStructure is an extension of the PictureDataStructure to add one attribute:
ElementAttributeTypeUseCommentLogoStructureIdxs:NMTOKENoptionalStandard attribute for a PictureDataStructureDisplayOrderxs:positiveIntegeroptionalStandard attribute for a PictureDataStructureRolexs:tokenoptionalAdditional attribute for this elementThis element extends the picture data structure by adding an attribute to define the rle of the logo. This can be used to indicate the purpose of the logo (for example, it is to appear on a ballot).
ManagingAuthorityStructure
The managing authority is the body responsible for an election event, election, contest or reporting unit. In most cases, not all of these will be required, but sometimes more than one is necessary. For example, an election using the additional member system might be organized on a regional basis, whilst local authorities organise their local election events. In this case, the region becomes the managing authority for the contest, whilst the local authority is the managing authority for the event. There will also be an authority responsible for the overall conduct of the election, although this information might not be required.
The managing authority indicates the authority name, address, Id, any logo that might be required for display during the election and a list of responsible officers.
MessageStructure
ElementAttributeTypeUseCommentMessagesStructureDisplayOrderxs:positiveIntegeroptionalMessageFormatxs:topkenoptionalTypexs:tokenoptionalLangLanguageTypeoptionalThe Message element is of mixed type, so can have both text and element content. The intention is that it should have one or the other. The Message element has three attributes: Lang is used to indicate the language of the message using ISO 639 three letter language codes, Format indicates the format of element content using the media types definition from RFC 2046 Pt 2 [ REF _Ref78185080 \r \h 1] and the list of media types defined by IANA [ REF _Ref78185112 \r \h 2], for example, text/html, and Type indicates the purpose of the message.
NominatingOfficerStructure
The nominating officer is the person nominating a party in an election run under, for example, the party list system. The data type includes a name and contact information.
OutgoingGenericCommunicationStructure
This data type provides a common structure for communications from electoral service organisers to voters. Multiple voters can be identified to allow printing of messages. Individual message types, such as that used for offering voting channel options (360a) are based on extensions of this type.
PeriodStructure
This element can be used when appointing a proxy or registering to vote using a specific channel (e.g. postal). It allows this registration to be for a period of time, for specific election events (and possibly elections within those events) or permanently.
PictureDataStructure
ElementAttributeTypeUseCommentPictureDataStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalBinaryFormatxs:NMTOKEN (restricted)requiredWhere a picture (logo, map, photo) is provided, it may be given as either a link or as Base64 encoded binary data. In the latter case, the format of the logo (bmp, gif, jpeg, png or tiff) must be indicated using the Format attribute of the Binary element.
PollingDistrictStructure
ElementAttributeTypeUseCommentPollingDistrictStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalThe polling district indicates where a voter is registered to vote. The polling district can have a name and an Id attribute. It can also be associated with other terms such as a constituency. This is done through the Association element, which has Type attribute and may have an Id attribute as well as a text value.
PollingPlaceStructure
ElementAttributeTypeUseCommentPollingPlaceStructureChannelVotingChannelTyperequiredDisplayOrderxs:positiveIntegeroptionalPhysicalLocationIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalPostalLocationIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalElectronicLocationIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalOtherLocationIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalPollingStationIdxs:NMTOKENoptionalIn general, a polling place will be either a physical location (for paper or kiosk voting), a postal address (for postal votes) or an electronic location (for Internet, SMS, telephone and other electronic means of voting). However, it is possible that none of these types will meet every need, and so an OtherLocation element has been included. Each of these locations must indicate the channel for which it is to be used. If a single location supports multiple channels, it must be included multiple times.
A physical location has an address. Sometimes, several polling stations will be at the same address, so a polling station can be defined by name and/or Id within the address. Access to an external map can also be provided as a URI or Base64 encoded binary data.
An electronic location must indicate its address (e.g. phone number, URL).
An optional TimeAvailable element is also provided. In most cases, this is not required as the time a location is available is the same as the time the channel is available. However, there are circumstances, such as the use of mobile polling stations, where this is not the case.
PositionStructure
The PositionStructure is an extension of xs:token to add the following attributes:
ElementAttributeTypeUseCommentPositionStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalThe element defined by this type indicates the position (e.g. President) for which an election is being held. It has a text description and an optional ID.
ProcessingUnitStructure
ElementAttributeTypeUseCommentProcessingUnitStructureRolexs:token (restricted)requiredA processing unit is a physical system used in the election process. It is identified as part of audit information by its ID (which might be an IP address) and optional name.
Each processing unit has an attribute to describe its rle. The rle can be "sender", "receiver", "previous sender" or "next receiver". The latter two are used when there is a gateway involved. For example, a 440 (cast vote) message might have an OriginatingDevice as its original sender, a gateway as sender and voting system as receiver.
ProposalIdentifierStructure
ElementAttributeTypeUseCommentProposalIdentifierStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalShortCodeShortCodeTypeoptionalExpectedConfirmationReferenceConfirmationReferenceTypeoptionalA proposal is used in a referendum. At a basic level, it is a piece of text with the options (yes and no, for and against etc) to be voted on.
The proposal identifier indicates a system ID for the proposal. A short code can also be included, either for SMS voting or where the security mechanism in place requires it. An ExpectedConfirmationReference attribute also allows for security mechanisms where the confirmation reference may be different for each combination of voter and candidate.
ProposalStructure
ElementAttributeTypeUseCommentProposalStructureTypexs:tokenoptionalThe proposal identifier provides a name and ID. The description is used to provide the information that will be displayed to the voter to indicate the aim of the proposal. The options are then used to indicate how the voter may vote.
The Type attribute allows for referenda where there are different kinds of proposal, for example, initiative or referendum.
ProposerStructure
ElementAttributeTypeUseCommentProposerStructureCategoryxs:token (restricted)optionalA proposer proposes, seconds or endorses a candidate or referendum proposal. A proposer can have a category, which indicates one of "primary", "secondary" or "other". A name is always required, and additional information might be needed.
ProxyStructure
ElementAttributeTypeUseCommentProxyStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalPreferredChannelFixedYesNoTypeoptionalIn many elections, a voter may appoint a proxy to vote on his or her behalf. That proxy may be identified by position (for example, appointing the chairman as proxy at a company AGM), or by name (for example, appointing your spouse as proxy for a public election), or both.
In some elections, the proxy must, for example, be a family member. This is indicated using the Qualification element, while a reason for appointing a proxy can be indicated using the Reason element.
A proxy can be permanent (i.e. appointed until revoked), appointed for one or more election events (and individual elections within each event) or for a period of time. A proxy can also list his or her preferred voting channels. These are listed in order of preference for a given period (which may be specific election events, a date range or permanent), so that information can be sent regarding the most appropriate voting channel at any election. The channel may be fixed, for example, if registering to vote by a specific channel prevents voting by other means.
A proxy may also have a voting token, indicating the right to vote, or a qualified voting token, indicating that there is a question over their right to vote.
ReferendumOptionIdentifierStructure
The ReferendumOptionIdentifierStructure is an extension of xs:token to add the following attributes:
ElementAttributeTypeUseCommentReferendumOptionIdentifierStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalShortCodeShortCodeTypeoptionalExpectedConfirmationReferenceConfirmationReferenceTypeoptionalA referendum option is used to indicate the possible answers to a referendum question, such as "yes" and "no" or "for" and "against".
The referendum option identifier has a text description and can have a system ID. A short code can also be included, either for SMS voting or where the security mechanism in place requires it. An ExpectedConfirmationReference attribute also allows for security mechanisms where the confirmation reference may be different for each combination of voter and option.
ReportingUnitIdentifierStructure
The ReportingUnitIdentifierStructure is an extension of xs:token to add the following attributes:
ElementAttributeTypeUseCommentReportingUnitIdentifierStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalA reporting unit is an entity that reports partial information relating to a contest (votes or the results of a count) without having the full set of information required to generate a result. This will happen when votes from several independently managed areas must be amalgamated to produce a result.
The reporting unit identifier structure defines a string with an optional Id.
ResponsibleOfficerStructure
ElementAttributeTypeUseCommentResponsibleOfficerStructureIdxs:NMTOKENoptionalA responsible officer is someone who has some sort of rle to play in the organization of an election. Each responsible officer has a name and/or responsibility (such as returning officer) and optional contact information. Local rules will usually indicate the values allowed in the Responsibility element.
ScrutinyRequirementStructure
The ScrutinyRequirementStructure is an extension of xs:token to add the following attribute:
ElementAttributeTypeUseCommentScrutinyRequirementStructureTypexs:tokenrequiredA scrutiny requirement has two parts, a Type attribute and a text value. The Type specifies a condition that a candidate must meet, such as an age or membership requirement or the payment of a fee. The text describes how that condition has been met. For example:
8 June 1955
SealStructure
ElementAttributeTypeUseCommentOtherSealTypexs:tokenrequiredThe seal is used to protect information such as a vote, voting token or complete message. The seal provides the means of proving that no alterations have been made to a message or individual parts of a message such as a vote or collection of votes, from when they were originally created by the voter. The seal may also be used to authenticate the identity of the system that collected a vote, and provide proof of the time at which the vote was cast.
If a message is to be divided, each part must be separately sealed to protect the integrity of the data. For example, if votes in several elections are entered on a single ballot, and these votes are being counted in separate locations, each vote must be separately sealed.
A seal may be any structure which provides the required integrity characteristics, including an XML signature [ REF _Ref56591066 \r \h \* MERGEFORMAT 1] or a time-stamp.
The XML signature created by the voting system provides integrity and authentication of the identity of the system that collected the vote. The time-stamp provides integrity of the vote and proof of the time that the vote was cast.
SimpleDateRangeStructure
This data type is used to describe ranges of dates or dates and times.
TelephoneStructure
ElementAttributeTypeUseCommentTelephoneStructurePreferredYesNoTypeoptionalMobileYesNoTypeoptionalThis is an extension of the TelephoneType and adds an Extension element and the two attributes Preferred and Mobile of YesNoType. The Preferred attribute indicates which of several phone numbers or fax numbers is preferred.
VoterIdentificationStructure
ElementAttributeTypeUseCommentVoterIdentificationStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalIdTypexs:tokenrequiredAn element defined by this data type is used wherever identification of a voter is required. It contains the voter's name and electoral address (the address that gives them the right to vote in a specific contest), the voting token (either normal or qualified) and a number of identifiers (such as an electoral registration number). It may also include a previous electoral address if this is required (for example, because a voter has not been at his or her current address for more than a predefined period).
VoterInformationStructure
ElementAttributeTypeUseCommentVoterInformationStructureIdxs:NMTOKENoptionalDisplayOrderxs:positiveIntegeroptionalContactDetailsStructureDisplayOrderxs:positiveIntegeroptionalstandard attribute for this data typeElectionIdxs:NMTOKENoptionaladditional attributePreferredChannelFixedYesNoTypeoptionalCheckboxTypexs:tokenrequiredThis contains more information about the voter. It contains all the information that would typically be included on an electoral register other than that used for identification of the voter. In many cases, it will be restricted to only include the information required in a specific message type.
A voter can list his or her preferred voting channels. These are listed in order of preference for a given period (which may be specific election events, a date range or permanent), so that information can be sent regarding the most appropriate voting channel at any election. The channel may be fixed, for example, if registering to vote by a specific channel prevents voting by other means.
The Qualifier element is used to hold information that might affect a voter's right to vote or how the voting process is managed. Suitable enumerations for this are likely to be added as part of localisation. The CheckBox element with its Type attribute allows binary information such as whether the voter's entry on the electoral register can be sold, or whether the voter wants to participate in the count. The eligibility indicates what election types a voter is eligible to participate in.
Special requests are requests from the voter, for example, for wheelchair access to a polling station.
VTokenStructure
ElementAttributeTypeUseCommentComponentTypexs:NMTOKENrequiredThe voting token contains the information required to authenticate the voters right to vote in a specific election or contest. A voting token can consist of a continuous string of encoded or encrypted data, alternatively it may be constructed from several data components that a user may input at various stages during the voting process (such as PIN, password and other coded data elements). The totality of the voting token data proves that a person with the right to vote in the specific election has cast the vote.
Depending on the type of election, the voter may need to cast their votes anonymously, thus not providing a link to the voters true identity. In this case the voting token data will not identify the actual person casting the vote; it just proves that the vote was cast by a person with the right to do so. Election rules may require a link to be maintained between a vote and a voter, in which case a link is maintained between the voting token data and the voters identity.
The components of the voting token are identified by a Type attribute and may contain text or markup from any namespace depending on the token type. The content could be defined further in separate schemas for specific types of token.
VTokenQualifiedStructure
ElementAttributeTypeUseCommentReasonTypexs:tokenrequiredThere are occasions when a normal voting token cannot be used. For example, if a voter is challenged, or an election officer claims the voter has already voted. In these circumstances a qualified voting token can be used and treated appropriately by the election system according to the election rules. For example, challenged votes might be ignored unless there were sufficient to alter the result of the election, in which case each vote would be investigated and counted if deemed correct to do so.
The VTokenQualifiedStructure is therefore an extension of the VTokenStructure to add the additional information required. This additional information comprises a reason for qualification (as a Reason element with a Type attribute and textual description) and possibly an original VToken.
Elements
The following elements are simply specified by their similarly-named data type and are not described further here:
Affiliation, AffiliationIdentifier, Agent, AgentIdentifier, Area, AuditInformation, AuthorityIdentifier, BallotIdentifier, BallotIdentifierRange, Candidate, CandidateIdentifier, ContactDetails, ContestIdentifier, CountingAlgorithm, DocumentIdentifier, ElectionIdentifier, EventIdentifier, EventQualifier, Gender , Logo, ManagingAuthority, MessageType, NominatingOfficer, NumberOfPositions, Period, PollingDistrict, PollingPlace, Position, Proposal, ProposalIdentifier, Proposer, Proxy, ReferendumOptionIdentifier, ReportingUnitIdentifier, ResponsibleOfficer, ScrutinyRequirement, Seal, VToken, VTokenQualified
Accepted
YesNoType
This element indicates that a candidate, referendum proposal or vote has been accepted.
Election Statement
MessagesStructure
This is the candidate's message to voters.
MaxVotes
xs:positiveInteger
The maximum number of votes allowed (also known as the vote limit). This defaults to the value of "1".
MinVotes
xs:nonNegativeInteger
The minimum number of votes allowed. This defaults to the value of "0".
NumberInSequence
xs:positiveInteger
The number of partial messages when a message is split. See Spitting of Messages
NumberOfSequence
This element represents the number of identical positions that will be elected as the result of a contest. For example, in a contest for a Town Council, three councillors might be elected as the result of the contest in one part of the town. The element is an xs:positiveInteger and defaults to a value of "1".
PersonName
This element uses the PersonNameStructure defined in the EML externals schema.
Profile
MessagesStructure
This is the candidate's profile statement.
SequenceNumber
xs:positiveInteger
The sequence number of a partial message when a message is split. See Splitting of Messages.
TransactionId
xs:token
A reference code for a specific transaction, which may comprise several messages.
VoterName
PersonNameStructure
The name of a voter.
The EML Message Schemas
This section describes the EML messages and how the message specifications change for this application. It uses the element and attribute names from the schemas.
Attributes are shown where they are not the standard attributes of data types already described.
Election Event (110)
ElementAttributeTypeUseCommentAllowedChannelsDisplayOrderxs:positiveIntegeroptionalContestDisplayOrderxs:positiveIntegeroptionalDescription of Schema
This schema is used for messages providing information about an election or set of elections. It is usually used to communicate information from the election organisers to those providing the election service.
The message therefore provides information about the election event, all elections within that event and all contests for each election.
For the election event, the information includes the ID and name of the event, possibly with a qualifier on the event. This qualifier is used when an event has several local organisers. For example, for a UK general election, each constituency organises its own contests. The election event is therefore the general election, whilst the qualifier would indicate the constituency. Other information regarding an election event comprises the languages to be used, the start and end dates of the event, potentially a list of external documents that are applicable (such as the rules governing the election), a description and information about the managing authority.
The managing authority can be indicated for the event, each election, each contest within the election and each reporting unit.
An election can have a number of dates associated with it. For example, there is likely to be a period allowed for nomination of candidates and a date when the list of eligible voters is fixed. Each date can be expressed as a single date when something happens, a start date, an end date, or both start and end dates. These dates can be either just a date or both a date and time using the subset of the ISO 8601 format supported by XML Schema.
Like the event, an election can have both a managing authority and referenced documents. Finally, there is a Messages element for additional information.
A contest has a name and ID. It can also have reporting unit identifiers. A contest may need to specify its geographical area independently from its name, for which purpose the Area element is provided. Each contest can specify the voting channels allowed. In general, the list of possible channels will be further restricted as part of a local customisation. Each channel can specify several methods for authenticating the voter, such as PIN and password, and a response method, indicating the type of response to be given to a cast vote. Finally, facilities are provided to indicate the dates and times when the channel will be available to the voter.
As described previously, a contest can indicate its managing authority. It may also indicate the position (such as President) for which votes are being cast. The Description allows for additional text describing the contest. Each contest indicates the voting method being used, whilst the CountingAlgorithm indicates the method of counting (such as the d'Hondt or Meeks method) that will be used. The minimum and maximum number of votes to be cast by each voter can also be indicated.
A list of polling places can be provided. These can be either physical locations for people to go to vote, postal addresses for postal votes or electronic locations. An other location is also allowed for cases where these do not meet the requirements. A location can also say when it will be available. This is intended for mobile polling stations that will only be available at a given address for a part of the voting period.
Finally, a Messages element allows for additional information that might be communicated to the voter later through other messages.
EML Additional Rules
Error CodeError Description3110-001The allowed channels must not be declared at both the election event level and the contest level.Inter Database (120)
Description of Schema
This schema is used for messages requesting services from other electoral registers or candidate databases. This can, for example, be used to de-dupe databases, check that a candidate in an election is only standing in one contest or confirm that the proposers of a candidate are included on a relevant electoral register. The schema is in two parts, so a message will be either a request or a response.
Both request and response start by identifying the source and destination as processing units.
A request has an Action code to identify the request being made. Possible actions include, but are not limited to, add, delete, replace, confirm and return. The code confirm returns success if the person indicated is included in the database. The code return causes the receiving the database to return the full information for the person identified. The ActionDateTime is used to specify when the action should be carried out, and then there is an optional list of voters or candidates.
A response has a similar structure. It could be that the Action code is no longer required, so this is now optional. The TransactionID must match that given in the request. The Result is either a binary Success flag or a remark or both. Again, there is a date and time, but in this case it is the date and time at which the action took place.
Response (130)
Description of Schema
Some messages have a defined response message that provides useful information. However, there is a need for a more general response, either to indicate that a message has been accepted, or to indicate the reasons for rejection.
The message includes information to identify the message to which the response applies (by using the same transaction id in the EML element and, if necessary, including the sequence number of the message to which the response applies in the Response element), with information on the entity raising the message, whether the message was accepted and information about the errors if it was not. The desired language for a display message can also be included to allow a downstream processor to substitute a language-specific error message if required.
If the message is reporting an error, the location of the error within the message can be indicated. Usually, this will be an XPath to the location of the error. However, errors detected by an XML parser may be in a different format, such as a line number.
Note that a single response can be raised for a series of sub-messages with the same transaction ID. This allows indication, for example, that a sub-message was missing.
Additional EML Rules
Error CodeError Description3130-001If the message is not accepted, there must be an Errors elementCandidate Nomination (210)
Description of Schema
Messages conforming to this schema are used for four purposes:
nominating candidates in an election;
nominating parties in an election;
consenting to be nominated; or
withdrawing a nomination.
Candidate consent can be combined in a single message with a nomination of the candidate or party or sent separately.
Note that the message does not cover nomination for referendums.
The election and contest must be specified. When a candidate is being nominated, there must be information about the candidate and one or more proposers. The candidate must supply a name. Optionally, the candidate can provide contact information, an affiliation (e.g. a political party) and textual profiles and election statements. These two items use the MessagesStructure to allow text in multiple languages. There is also scope to add additional information defined by the election organiser.
The proposers use the standard proposer declaration with a mandatory name and optional contact information and job title. Again, additional information can be required.
If a party is being nominated, the primary proposer will be the contact. Information on candidates in a party list can also be provided.
Candidates, either individuals or on a party list, must define the action being taken and may provide scrutiny information. The scrutiny requirements indicate how the candidate has met any conditions for standing in this election. This could include indicating that a deposit has been paid or providing a reference to prove that he or she lives in the appropriate area. This information can be signed independently of the complete message.
Response to Nomination (220)
Description of Schema
This message is sent from the election organiser to the candidate or nomination authority for a party to say whether the nomination has been accepted. Along with the acceptance information and the basic information of election, contest and party and candidate names, the candidate's contact details and affiliation can be included and a remark explaining the decision.
EML Additional Rules
Error CodeError Description3220-001If the nomination has not been accepted, a reason for rejection is required in the Remark element
Candidate List (230)
Description of Schema
This schema is used for messages transferring candidate lists for specified contests. It has the election event, election and contest identifiers, and optionally the event dates and a contest description. The list itself can be either a list of candidates, each with a name, address, optional affiliation and other useful data, or a list of parties. In the latter case, contact information and a list of candidates under a party list system can also be included.
Voter Registration (310)
Description of Schema
This schema is used for messages registering voters. It uses the VoterIdentificationStructure. The VoterInformationStructure is used unchanged. Proof of ID can be provided.
There is the facility for the transmission channel (for example a trusted web site) to add the time of transmission.
EML Additional Rules
Error CodeError Description3310-001The Proxy must not have a VToken or VTokenQualifiedElection List (330)
ElementAttributeTypeUseCommentBlockedReasonxs:tokenoptionalChannelVotingChannelTypeoptionalDescription of Schema
This schema is primarily used for messages communicating the list of eligible voters for an election or set of elections. It can also be used for any other purpose that involves the transfer of voter information where the 120-interDB message is not appropriate. Partial lists are allowed through the use of the Qualifier, Blocked and VoterGroup elements. So, for example, a list of postal voters or a list of proxies can be produced.
For each voter, information is provided about the voter himself or herself, and optionally about the elections and contests in which the voter can participate. The information about the voter is the same as that defined in the 310-voterregistration schema. Added to this can be a list of elections, each identifying the election and the contest in which this voter is eligible to vote, and the polling places available. Any voter can have a Blocked element set against them with an optional Reason and Channel. This allows a list to be produced for a polling place indicating those that have already voted by another means or who have registered for a postal vote. It can also be used if the complete electoral register must be transmitted (perhaps as a fraud prevention measure) but some people on the register are no longer eligible to vote.
EML Additional Rules
Error CodeError Description3330-002The polling district can only be included for either the voter or the election.3330-003The polling place can only be included for either the voter or the election.
Polling Information (340)
ElementAttributeTypeUseCommentBallotChoicesContestedYesNoTypeoptionalVotingPeriodDisplayOrderxs:positiveIntegerVotingInformationDisplayOrderxs:positiveIntegeroptionalChannelVotingChannelTypeoptionalDescription of Schema
The polling information message defined by this schema is sent to a voter to provide details of how to vote. It can also be sent to a distributor, so multiple sets of information are allowed. In the case of SMS voting, ballot information may also be required, so this can be included. Either one or several sets of polling information may be sent to each voter for any election event.
Some information about the voter and any proxy may be included, for example to print on a polling card. This can also include a mailing address for a distributor to use.
Information about the elections and contests is included for the benefit of the voter. For each voting channel, this includes where to vote (which could be a polling station, address for postal voting, URL for Internet voting, phone number for SMS voting etc) and the times that votes can be placed. Use of the DisplayOrder attribute on these allows the display or printing of information to be tailored from within the XML message.
Ballot information may be included if required. This is a subset of the information defined in the 410-ballots schema. In this case, it is likely that the short code for a candidate will be used for SMS voting. It is possible that an expected response code will be provided as well. Both the short code and expected response code may be tailored to the individual voter as part of a security mechanism.
Outgoing Generic Communication (350a)
Description of Schema
This schema provides a common structure for communications to the voter. Individual message types can be designed based on extensions of this schema.
The voter must always provide a name and might provide one or more identifiers. These are shown as a restriction of the VoterIdentificationStructure, the restriction being to leave out the VToken and VTokenQualified. Contact details are also required, and it is expected that at least one of the allowed contact methods will be included. Inclusion of proxy information is optional.
The identifiers for the election event, election and contest are optional. There is then an element in which a message can be placed in any of several different formats according to the channel being used.
Incoming Generic Communication (350b)
Description of Schema
This schema provides a common structure for communications from the voter. Individual message types can be designed based on extensions of this schema.
The voter's name must be provided and there can be one or more identifiers. These are shown as a restriction of the VoterIdentificationStructure, the restriction being to leave out the VToken and VTokenQualified. Contact details are also required, and it is expected that at least one of the allowed contact methods will be included. Inclusion of proxy information is optional.
The identifiers for the election event, election and contest are optional. There is then an element in which a message can be placed in any of several different formats according to the channel being used.
Internal Generic (350c)
Description of Schema
This schema provides a common structure for communications between those involved in organizing an election. Individual message types can be designed based on extensions of this schema.
There are optional To and From elements, which can contain any EML elements. It is expected that these will usually be a responsible officer or a person's name and contact information.
The identifiers for the election event, election and contest are optional. There is then an element in which a message can be placed in any of several different formats according to the channel being used.
Outgoing Channel Options (360a)
Description of Schema
This schema is used for messages offering a set of voting channels to the voter. It is an extension of schema 350a. A message conforming to this schema will include a list of allowed channels, either to request general preferences or for a specific election event or election within the event.
Incoming Channel Options (360b)
Description of Schema
This schema is used for messages indicating one or more preferred voting channels. It may be sent in response to 360a or as an unsolicited message if this is supported within the relevant jurisdiction.
It is an extension of schema 350b, and indicates a preferred voting channels in order of preference.
Ballots (410)
ElementAttributeTypeUseCommentContestDisplayOrderxs:positiveIntegeroptionalCompletedYesNoTypeoptionalQualifiedReasonxs:tokenrequiredBlockedReasonxs:tokenoptionalChannelVotingChannelTypeoptionalBallotChoicesContestedYesNoTypeoptionalDescription of Schema
This schema is used for messages presenting the ballot to the voter or providing a distributor with the information required to print or display multiple ballots.
In the simplest case, a distributor can be sent information about the election event and a ballot ID to indicate the ballot to print.
In other cases, the full information about the elections will be sent with either an election rule ID to identify the voters to whom that election applies or a set of voter names and contact information. If the ballot is being sent directly to the voter, this information is not required. Since printed ballot papers are likely to require a unique identifier printed on them, the range to be used for each ballot type can be defined.
The election information starts with the election identifier and description. This is followed by information related to the contest and any other messages and information required. Note that each voter can only vote in a single contest per election, so only a single iteration of the Contest element is required.
A contest must have its identifier and a list of choices for which the voter can vote. A voter can vote for a candidate, an affiliation (possibly with a list of candidates) or a referendum proposal. There is also a set of optional information that will be required in some circumstances. Some of this is for display to the voter (HowToVote and Messages) and some controls the ballot and voting process (Rotation, VotingMethod, MaxVotes, MinVotes, MaxWriteIn).
Authentication (420)
Description of Schema
The authentication message defined by this schema may be used to authenticate a user during the voting process. Depending on the type of election, a voter's authentication may be required. The precise mechanism used may be channel and implementation specific, and can be indicated using the LoginMethod element.. In some public elections the voter must be anonymous, in which case the prime method used for authentication is the voting token. The voting token can contain the information required to authenticate the voter's right to vote in a specific election or contest, without revealing the identity of the person voting. Either the VToken or the VTokenQualified must always be present in an authenticated message. The VotingChannel identifies the channel by which the voter has been authenticated.
Authentication Response (430)
ElementAttributeTypeUseCommentContestDisplayOrderxs:positiveIntegeroptionalCompletedYesNoTypeoptionalQualifiedReasonxs:tokenrequiredBlockedReasonxs:tokenoptionalChannelVotingChannelTypeoptionalBallotChoicesContestedYesNoTypeoptionalDescription of Schema
The authentication response is a response to message 420. It indicates whether authentication succeeded using the Authenticated element, and might also present the ballot to the user. This is a restriction of the Ballots element to allow only a single ballot per reply.
Cast Vote (440)
ElementAttributeTypeUseCommentCastVoteSpoiltxs:tokenoptionalContestSpoiltxs:tokenoptionalSelectionValueVotingValueTypeoptionalShortCodeShortCodeTypeoptionalCandidateValueVotingValueTypeoptionalDescription of Schema
This message represents a cast vote, which comprises an optional voting token (which may be qualified) to ensure that the vote is being cast by an authorized voter, information about the election event, each election within the event and the vote or votes being cast in each election, an optional reference to the ballot used, the identifier of the reporting unit if applicable and a set of optional audit information.
For each election, the contest is identified, with a set of, possibly sealed, votes. The votes are sealed at this level if there is a chance that the message will be divided, for example so that votes in different elections can be counted in different locations.
The selection of candidates, affiliations or a referendum option uses the Selection element. If an election requires preferences to be expressed between candidates, multiple Selection elements will be used, each of these having a suitable Value attribute. Some elections allow write-in candidates, and these are handled in a similar way. Preferences can also be expressed between parties, using the Affiliation element. The PersonalIdentifier is used in elections where each voter is given an individual list of codes to indicate their selection.
A more complex election might request the voter to vote for a party, then express a preferences of candidates within the party. In this case, the Affiliation element is used to indicate the party selected, and multiple CandidateIdentifier elements, each with a Value attribute are used to express candidate preferences.
Preferences in a referendum are handled in the same way as they are for candidates and parties, using the ReferendumOptionIdentifier.
Retrieve Vote (445)
Description of Schema
This message is used for voting systems that include a pre-ballot box from which votes can be retrieved and amended before being counted. When a vote is retrieved, it should be deleted from the pre-ballot box.
Vote Confirmation (450)
Description of Schema
The vote confirmation message can be used to show whether a vote has been accepted and provide a reference number in case of future queries. Some voting mechanisms require multiple ConfirmationReference elements. If the vote is rejected, the Remark element can be used to show a reason.
Votes (460)
See 440-CastVote for the detail of the CastVoteStructure.
ElementAttributeTypeUseCommentCastVoteSpoiltxs:tokenoptionalContestSpoiltxs:tokenoptionalSelectionValueVotingValueTypeoptionalShortCodeShortCodeTypeoptionalCandidateValueVotingValueTypeoptionalProposedRejectionReasonxs:tokenoptionalReasonCodexs:tokenrequiredObjectionYesNoTypeoptionalProposedUncountedReasonxs:tokenoptionalReasonCodexs:tokenrequiredObjectionYesNoTypeoptionalDescription of Schema
This schema is used to define a message comprising a set of votes being transferred for counting. It is a set of CastVote elements from schema 440 with the addition of the ProposedRejection and ProposedUncounted elements and audit information for the voting system. If a vote is rejected, for example, because a voter has chosen to spoil a ballot paper, many authorities will want to count that vote as having been cast. The UncountedVotes element is reserved for those cases where that record is not required, for example when the result is thought to be fraudulent. A ProposedRejection or ProposedUncounted element must have a ReasonCode attribute, and may have a Reason attribute to describe the code. They may also have an Objection attribute. This indicates that someone has objected to this vote being rejected or the proposal that it should not be counted.
VToken Log (470)
ElementAttributeTypeUseCommentVTokenStatusxs:token (restricted)requiredVTokenQualifiedStatusxs:token (restricted)requiredDescription of Schema
The message defined by this schema is used to add voting tokens (which may be qualified) to an audit log. The VToken or VTokenQualified is extended by the addition of a Status attribute with a value of voted or unvoted for the VToken and voted, unvoted and withdrawn for the VTokenQualified. In addition to sending single tokens as they are used, the schema can be used to validate a message sending multiple tokens optionally grouped by voting channel. This might be used instead of sending tokens as they used or, for example, to send the unused tokens at the end of an election. The Update element can be used to indicate that an existing log is being updated rather than the message containing a complete new log. The logging system can also be identified for audit purposes.
Audit Log (480)
Description of Schema
The message defined by this schema is used to log the use of each seal with associated information for audit purposes.
An audit log message can be transmitted individually as the message causing the log entry is sent or received, or the logs can be stored, and several seals logged at once. Ideally, every device that can create or consume a message will create a log entry so that pairs of entries can be matched. The most important messages to log are those associated with the voting process itself, and these are shown below.
When used in this message, the Response element will not have an AuditInformation child.
The message may contain the name and ID of the event, election and contest. It can also indicate whether this is an update to an existing log or a new log. Following the logged seals, a text message can be added as well as audit information for the audit logging message itself.
Each seal being logged must indicate whether the device sending the log was the sender or receiver of the sealed message. It may be accompanied by the voting token associated with the seal and possibly additional audit information. This will be the audit information from the message being logged with additional information about the message. Most of this is common to all message types, but some message types require specific audit information. One of these is the 130-response message. When this is used to convey an error, almost the complete message payload (the Response element and its contents apart from the audit information) is logged with the usual message-independent data.
Count (510)
ElementAttributeTypeUseCommentSelectionValueVotingValueTypeoptionalRejectedVotesReasonxs:tokenoptionalReasonCodexs:tokenrequiredUncountedVotesReasonxs:tokenoptionalReasonCodexs:tokenrequiredDescription of Schema
The count message defined by this schema is used to communicate the results of one or more contests that make up one or more elections within an election event. It may also be used to communicate the count of a single reporting unit for amalgamation into a complete count.
The message includes the election event identifier, and for each election, the election identifier, an optional reference to the election rule being used and information concerning the set of contests.
In some cases, reporting for a contest may be required at a lower level (for example, for each county in a state). For this reason, reporting may be done at the level of the reporting unit, the total votes, or for a total vote and the breakdown according to the multiple reporting units.
Each contest indicates its identifier, and optionally the counting system and the maximum number of votes that each voter could cast. The key information is that about the votes cast for each of the choices available and the numbers of abstentions and rejected and uncounted votes. If a vote is rejected, for example, because a voter has chosen to spoil a ballot paper, many authorities will want to count that vote as having been cast. The UncountedVotes element is reserved for those cases where that record is not required, for example when the result is thought to be fraudulent. Both the UncountedVotes and RejectedVotes elements have Reason (optional) and ReasonCode (mandatory) attributes to indicate why the votes were treated as they have been. The former is a textual description, and the latter a code.
For each choice available to the voter, the identifier and number of valid votes are mandatory. The other information provided depends on the type of election. For example, the Value attribute of the Selection element can be used to indicate whether a candidate was a first or second choice in an election run under the single transferable vote system. In the simplest cases, the identifier for the candidate (perhaps with the party), the party or the referendum option are given. If the voter was able to vote for a party and provide a preference for candidates within the party, the AffiliationIdentifier element is used, and multiple CandidateIdentifier elements may be used, each with a Count attribute. This count is the result of whatever algorithm has been used to calculate the ranking of the candidates.
Result (520)
Description of Schema
Messages described by this schema can be used to communicate the results of simple election types. One specific use is to provide an input into the calculation algorithm for elections using the additional member system.
The main part of the schema is held within the Selection element. This allows a choice of candidate, affiliation or referendum option identifiers to be defined with the position that choice achieved (first, second etc). Optionally, the number of votes can be shown. A candidate can be associated with his or her affiliation if required. Write in candidates will be shown in the same way as other candidates, although they will only have an Id attribute if this is assigned in the election system after the votes are cast.
Options Nomination (610)
Description of Schema
This schema is used to submit proposals, for example for a referendum or company AGM. It uses the generic Proposal element to define the proposal itself. One of more proposers can be named and may sign the nomination.
Options Nomination Response (620)
Description of Schema
This message is sent from the election organiser to the proposer to say whether the nomination has been accepted. Along with the acceptance information and the basic information of election, contest and identifier for the proposal, a remark can be made explaining the decision.
EML Additional Rules
Error CodeError Description3620-001If the nomination has not been accepted, a reason for rejection is required in the Remark element
Options List (630)
Description of Schema
This schema is used for messages transferring lists of proposals for a referendum. It may identify the election event, and provides details about the election. Each proposal in a referendum counts as an election, so each election identified will hold a single proposal.
References
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types IETF HYPERLINK "http://www.ietf.org/rfc/rfc2046.txt" http://www.ietf.org/rfc/rfc2046.txt
MIME Media Types IANA HYPERLINK "http://www.iana.org/assignments/media-types/" http://www.iana.org/assignments/media-types/
XML-Signature Syntax and Processing W3C HYPERLINK "http://www.w3.org/TR/xmldsig-core/" http://www.w3.org/TR/xmldsig-core/
XML Path Language (XPath) Version 1.0 W3C HYPERLINK "http://www.w3.org/TR/xpath" http://www.w3.org/TR/xpath
Notices
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.
Copyright OASIS Open 2006. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an AS IS basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
PAGE 2
EML v4.0 Schema Descriptions 01 February 2006
Copyright OASIS Open 2006. All Rights Reserved. Page PAGE 92 of NUMPAGES 94
Copyright 2002 OASIS. All rights reserved. Page PAGE 1 of NUMPAGES 94
the element is crossed out as the restriction is to forbid its occurrence
indicates that this is a sequence
dotted box around element indicates that element is optional
The yellow box represents the content model of the complex data type (in this case, Bstructure)
the data type is in blue, so this is a derivation. The derivation is to allow only the values yes or no
a data type in blue shows a derivation, in this case, a restriction
indicates that this is a choice
indicates that this is an all
shows the data type
indicates zero to three occurrences
indicates one to many occurrences
The Election element is expanded in the next diagram
The Contest element is expanded below
EMBED Excel.Sheet.8
The Contest element is expanded in the next diagram
The BallotInformation element is expanded in the next diagram
The AuditInformation element is expanded in the next diagram
The VoteGroup group is expanded in the next diagram
& 7 9 G - . ;
{ | I J K y z "
#
b c а $j h h
7 0J UmH nH u h
7 mH nH ujy h: PJ U
h: PJ j h: PJ Uj h: Uj h: Uh: 0J PJ j h: Uh%.X h+ h+ H*h+ h: j h: U / & H ^ { ; E
J R ! ! ! ! ! v: ! v: ! v: ! v: ! v: ! v: ! v: ! v: ! v: ! v: ! v: ! v:
!
!
&