A Committee Specification for TC approval has been released for public review by the OASIS Election and Voter Services Technical Committee. Under the title Election Markup Language (EML): e-Voting Process and Data Requirements, this document constitutes one of several early TC deliverables being used in pilot studies designed to test the effectiveness of the prototype EML standard across a number of different international jurisdictions. It represents a "general and global study of the electoral process, introducing the transition from a complete human process by defining the data structure to be exchanged and where needed; an EML schema is introduced and clearly marked." The supporting schemas package also under vote as part of the TC release includes thirty-nine (39) XML schemas and a reference document Election Markup Language (EML): XML Schemas. The TC has been chartered to "develop a standard for the structured interchange of data among hardware, software, and service providers who engage in any aspect of providing election or voter services to public or private organizations. The services performed for such elections include but are not limited to voter role/membership maintenance (new voter registration, membership and dues collection, change of address tracking, etc.), citizen/membership credentialing, redistricting, requests for absentee/expatriate ballots, election calendaring, logistics management (polling place management), election notification, ballot delivery and tabulation, election results reporting and demographics."

Bibliographic information:

Election Markup Language (EML): e-Voting Process and Data Requirements. From the OASIS Election and Voter Services TC. April 29, 2002. 57 pages.

Election Markup Language (EML): XML Schemas. From the OASIS Election and Voter Services TC. April 29, 2002. 41 pages. See the 39 associated XML schema files.

The EML [Schema] Specifications consist of "a library of XML schemas used in EML. The XML schemas define the formal structures of the election data that needs to be exchanged." The TC is also producing a document with ' Scenarios'; it will be a selected set of scenarios with variations in election type/country. The objective of the scenarios is to show how the EML process/datatypes and EML specifications documents can be used in practice. Each scenario will be made of two documents specific to the country and type of election under discussion."

EML specification structure: "The Election Markup Language specification defines a vocabulary (the EML core) and a message syntax (the individual message schemas). Thus most voting-related terms are defined as elements in the core with the message schemas referencing these definitions. The core also contains data type definitions so that types can be re-used with different names (for example, there is a common type to allow messages in different channel formats), or used as bases for deriving new definitions. There is a third category of schema document within EML - the EML externals. This schema document contains definitions that are expected to be changed on a national basis. Currently this comprises the name and address elements, which are based on the OASIS Extensible Name and Address Language, but may be replaced by national standards such as those contained in the UK Government Address and Personal Details schemas . Such changes can be made by replacing just this single file... Each message (or message group) type is specified within a separate a schema document. All messages use the EML element from the election core as their document element. Elements declared in the individual schema documents are as descendents of the EML element. The example instance messages in the scenarios document demonstrate this structure."

From the 'Data Requirements' section: "... we came across exceptions related to cultural divide, language, bylaws, different type of service possible etc. To limit the impact of these differences, the current specification limits itself to identifying a common set of data not related or affected by such differences. Thereby providing the core data that meets most election scenarios and something that meets most election requirements. The 'mandatory' elements are the minimum set of common data elements that must be present when the schema is used. All other elements are 'optional', which means the optional elements may, or may not, be present in a message using this schema. Any system that claims to support the schema must always generate mandatory elements and most be able to generate optional elements when required. Any system that claims to support the schema must always process all mandatory and optional elements correctly on reception. Note that some of the optional data will be partly considered as required in one system and either optional or even not accepted in others. Data Protection legislation and Privacy regulations will play a major role in defining what is to be included and under which section..."