RE: [election-services] Re: Fw: EML 4 issues

-------- Original Message --------
Subject: [election-services] Re: Fw: EML 4 issues
From: John Borras <johnaborras@yahoo.co.uk>
Date: Mon, February 19, 2007 5:06 am
To: David Flater <dflater@nist.gov>, lynne.rosenthal@nist.gov
Cc: EML TC <election-services@lists.oasis-open.org>, wack@nist.gov,
goldfine@nist.gov

David/Lynne

It's a great shame that we have not been able to resolve the outstanding issues in the time available.   We had real difficulties in the early days of EML getting a common understanding of voting concepts and terminology, particularly between USA and UK, so I'm not surprised that this is still causing problems. However we reached a compromise and EML has to be read and understood in the light of the defined vocabulary.  Changes to that would have significant impact on the design and structure of EML. I'm not saying that it couldn't be done but we would need to be very careful about making any changes as it would potential have severe cost implications for the current set of adopters.

I would very much like us to continue to work together to resolve these issues and find a solution that is acceptable to both of us, and which we could incorporate into a future release of EML. I did mention the possibility of a couple of my UK colleagues coming over to explain EML to you and your colleagues. Perhaps they could use the time with you to work on these issues? The guys I have in mind were the architects of the current EML model so they would be able to do a full impact of any further changes you feel are necessary.

In the meantime I need to press on and get the current draft of v5 approved as I have many people in Europe, and also IEEE, waiting on the updates.

Looking forward to our continued collaboration.

Regards
John
M. +44 (0)7976 157745

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

New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes.

election-services message