<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>After creating two native formats for a Vote Counting program
      (both designed to be the minimum that could implement the ballots
      I needed at the moment, not suitable as a standard), what I would
      propose is an expressive format that can be implemented
      identically in either JSON or YAML. <br>
      <br>
      A record would need two top level keys HEADER and BALLOTS.<br>
      <br>
      The HEADER would contain fields used to describe the election.
      These might include an alphanumeric identifier for the ballot set
      itself, keys for date and location of the election, division (if a
      partial) and a candidate key that would allow assigning a short
      identifier to each choice. If a Choice is "Maine Blueberry Sorbet,
      Maggie\'s Ice Cream and Confectionery, Collinsport, Maine, USA" or
      "<span class="VIiyi" lang="ja"><span class="JLqJ4b ChMk0b"
          data-language-for-alternatives="ja"
          data-language-to-translate-into="en" data-phrase-index="0"><span>抹茶アイスクリーム、京都ナンバーワンアイスクリーム、京都、日本</span></span></span>"
      a shorter Numeric or ASCII Alpha-Numeric identifier is desirable
      for the BALLOTS section, the long field could default to the short
      one when the long was omitted. <br>
      <br>
      The BALLOTS section would have several different structures
      defined. regular RCV ballots are easily represented with a simple
      array, Range Ballots need to be key value pairs, RCV ballots
      allowing equal preferences are different, etc. The ballot format
      would be indicated in the HEADER. This would also help future
      proof the format, permitting revision to add new ballot structures
      if they are ever needed.<br>
      <br>
      If anyone on this list has experience with the procedures of
      bodies (like ietf) that set standards is willing to volunteer to
      help organize a working group, I would be eager to participate.</p>
    <p>ABIF is a good acronym / short name for such a standard. <br>
    </p>
    <blockquote>
      <pre class="moz-quote-pre" wrap="">----------------------------------------------------------------------
Date: Sun, 6 Jun 2021 13:29:46 +0200
From: Jan ?imbera <a class="moz-txt-link-rfc2396E" href="mailto:simbera.jan@gmail.com"><simbera.jan@gmail.com></a>
Subject: Re: [EM] Ballot Data Format

Hi Rob and all,
I like the simultaneous readability, versatility and robustness of ABIF.
If the multiplier separator is made variant (asterisk / colon / both),
I think the only difference between Pivot and ABIF would be the
significance of whitespace in candidate tokens, something that the
parser could also be liberal in accepting - I see the [] bracketed form
as more readable (and thus default) but no problem in making
the non-bracketed form acceptable.
Also, if leaving out the scores for the unordered variant is allowed,
the format will be able to record approval votes in a very readable
form, which I would support.
If the community eventually arrives at some sort of consensus,
I'll put the ABIF read/write implementation into the backlog of
votelib (which can already read BLT and STV formats) so that
it has an interchange format for ordinal ballots as well.
The implementation would benefit from a formal parsing definition
(BNF or similar); if not, I might create it in the process.
All the best,
Jan</pre>
    </blockquote>
  </body>
</html>