----- Original Message ----
From: David Flater <dflater@nist.gov>
To: John Borras <johnaborras@yahoo.co.uk>; David RR Webber (XML) <david@drrw.info>
Cc: Paul Spencer <paul.spencer@boynings.co.uk>; lynne.rosenthal@nist.gov; wack@nist.gov; goldfine@nist.gov
Sent: Friday, 16 February, 2007 8:21:59 PM
Subject: Re: Fw: EML 4 issues
In a message dated 2007-02-13 13:39-0500, David Flater wrote:
> Regrettably, it is now clear that our understandings do not align.
> Some concepts that must be distinguished to meet our requirements are
> not distinguished from one another in the EML model.
I really appreciate the time and effort that you all have put into
trying to meet my requirements--you were really helpful to me and I
hope that my feedback was helpful to you. Unfortunately, it appears
that reaching a mutually agreeable compromise on the EML schemas would
require significantly more time, and my schedule does not permit me to
work on this any longer. I will of course monitor the progress of v5
and future revisions of EML to see at what point I could successfully
migrate to it as my primary schema. For now I will model my own
schema separately and then generate EML from that on an as-needed
basis.
On the
bright side, some of my colleagues will soon be looking at
potential uses of EML for exporting cast vote records for
interoperability and transparency. Their requirements are more
focused than mine and they might find greater success than I did.
Attached is an analysis of the response to the last round of issues.
I hope it is of some use to you.
With apologies,
--
David Flater, National Institute of Standards and Technology, U.S.A.
Issues in EML-v5-0-schemas-070211 (from openvotingsolutions.net)
---------------------------------
Status of partisan contests is as follows:
- In 110(ElectionEvent), "partisan" is now a VotingMethod, alongside
first past the post, single transferrable vote, etc. Only a single
VotingMethod applies to a given Contest, so this means we
cannot
distinguish a partisan FPP contest from a partisan STV contest.
Moreover, there is no way to identify the political party or parties
that are entitled to vote in the partisan contest. Partisan should
be a separate attribute from the VotingMethod, and there should be a
way to make the association to the political party or parties that
are entitled to vote in the contest.
>>> I made VotingMethod repeatable in the 110 - (actually I thought it
was globally repeatable - missed that in 110 was not the case).
Votingmethod needs to be repeatable - not just for partisan aspects -
as each aspect needs to be separately applicable.
Whether or
not a contest is partisan is orthogonal to the voting
method it uses. To call partisan a VotingMethod and make VotingMethod
repeatable technically allows one to encode the information, but
conceptual integrity suffers.
The political party is able to be identified via the new ballot
form association we added to the 410+ set.
The partisan association between a given contest and a political party
is part of the election definition. The partisan association between
a given ballot style and a political party is an attribute of the
ballot style. These two associations are not equivalent or
interchangeable.
- In 410(Ballots), the same concerns apply at the Contest level.
However, in addition, inside of BallotChoices are a Contested flag
and a Partisan attribute, which are alternate choices
besides
specifying a list of candidates. I do not understand the logic--
one can specify a candidate list *or* identify the contest as
partisan, but not both? Also, shouldn't it be in Contest instead of
inside the BallotChoices?
>>> No Change - these are both @attributes of BallotChoices - so you
can have either or both already - and they apply at that top level -
so will apply to contest level.
It appears now that the attributes are not within the choice, but the
assertion that the attribute applies at the contest level seems
inconsistent with its placement within BallotChoices. As you
observed, the data can be put there, but IMO they don't belong there.
Partisanship and the partisan association to a
political party are
attributes of the Contest, and to model them as attributes of
BallotChoices is misleading.
<<<
- It would also make sense to have an association between
BallotStructure (in 410) and a political party because a given
primary election ballot style will include all partisan contests
applicable to a single party, plus nonpartisan contests and
questions.
>>> No change - the affiliation linkage provides this (term
clarification - Affiliation = Party). Also - change below to allow
contest(*) grouping within election - enables this now.
The only linkage above the Candidate level in 410
is the Partisan
attribute within BallotChoices, which is a token having no definition.
If it is intended that this should reference an Affiliation then there
should be an AffiliationIdentifier.
In general, EML seems not to adhere to a consistent convention for
distinguishing associations from entities (or references from
definitions, to use an alternate terminology). In the case of 410
(Ballots), there is a reference to a Contest that should have been
defined in 110, but then many of the attributes of the Contest are
repeated inline. If the definitions in 110 and 410 were to disagree
with one another it would be difficult to know how to proceed.
3. Why is the AffiliationStructure in 410(Ballots) not harmonized
with the structure in 230(CandidateList), and why does it contain a
CandidateIdentifier?
>>> No change - this
allows cross-referencing and joins via a database
style query select statement.
Side note: You have to bear in mind that I did not do the original
work on these schemas - and people have made requests for things in a
non-US context. So I'm inclined to go with - "if it's not broke don't
fix it!" <<<
The use cases for the alternatives inside of BallotChoices should be
documented somewhere. I think the intent of the AffiliationStructure
in this context was to support types of contests in which one votes
for a party first, and the endorsed candidates only as a side-effect.
This is similar to but different from straight party voting.
<<<
- TotalVotes contains a VoteGroup.
-
ReportingUnitVotes contains a ReportingUnitIdentifier and a
VoteGroup.
- A VoteGroup lists the votes for 1..* Selections, followed by
optional counts of Cast, Read, TotalCounted, Provisionals, and
Abstentions, followed by RejectedVotes categorized by reason and
UncountedVotes categorized by reason.
Questions about this--
1. There seems to be equivocation between ballot counts and vote
tallies in this model. The two are not interchangeable--e.g., you may
count a blank ballot that contains no votes; it is a valid ballot.
The ballot counts must be reported to support ballot accounting.
>>> Will depend on local rules - blank ballot probably gets
rejected
as undervote or spoilt. <<<
By muddling ballot counts with vote tallies, the current schema forces
a certain set of rules and precludes others. It blocks the
implementation of U.S. voting practice as it is incompatible with
ballot accounting. It is also a serious conceptual integrity problem,
IMO.
2. We also want to be able to report ballot counts at the reporting
unit level, independent of any contests. This is not quite as simple
as adding maxOccurs="unbounded" ReportingUnitVotes inside of Election
because at this level the mandatory Selections within VoteGroup are
not applicable.
>>> No change. Assume if they are simply made empty tags - this is not
harmful - will pass XSD validation but null value associated with
them. <<<
If the client is entitled to omit a field, then it is misleading to
declare it as required. This one is moot since the
maxOccurs="unbounded" ReportingUnitVotes were not added inside of
Election, and if they were we still could not distinguish ballots from
votes.
3. Rather than hard-code certain ballot categories it would be
preferable to be able to associate 0..* categories with each cast
ballot and then be capable of reporting counts broken down by category
(in addition to the grand total). Categories could include Early,
Regular, In-Person, Absentee, Provisional, Challenged, Counted (or
Accepted) and Uncounted (or Rejected). These could be combined
with
tags such as NotRegistered, WrongPrecinct, IneligibleVoter or
UnreadableBallot to explain the reason why it was categorized a
certain way, or the reasons could be made a separate field. Support
for categories would need to be added in 440(CastVote) and in the
ballot count fields of 510(Count).
>>> Category of type xs:token added to 440 and 510 count.
Design assumption - obviously this is an area where in-country
extensions, legal and language localizations are anticipated - you can
use the XSD ability to redefine / restrict
these token
values to support these - via your own localized usa-emlcore include.
And PLUS you have the ##other - that you can use to put in more too.
The new attributes Category are problematic in several
respects--440/460 puts them in Contest and Election with maxOccurs=1
in both places, while 510 puts it within Selection, again with
maxOccurs=1, and they exist in parallel to the specific category
fields that were added in a previous iteration instead of obsoleting
them. But as with the previous issue, the inability to distinguish
ballots from votes blocks a proper resolution.