Title: RE: EML Clarifying Questions
Thom,
I think that you are reading too much into the statement of purpose. It's not to limit this interchange to for-profit vendors or selected implimentations. Any interchange of data will be to a software package or a hardware device. A software provider could be a for-profit vendor or someone in an election office who writes software. The intention of the committee is to design a specification that will best anticipate all the elecments of voting and voter service and allow for modification and enhancements as necessary. We used generic terms in the purpose statement and "provider" was meant to mean any system or process. One of the action items for the group is to identify and define the functionality needed to service the industry. Everything will be considered.
Since XML is an electronic data interchange standard the primary focus would be on communications between electronic devices and systems. However manual counts and mechanical devices have the summary counts recorded and these counts could be transposed to electonic media for inclusion in a tabualtion and/or reporting system.
We could and I think should create sub-specifications to EML. We may want to form sub-committees for this purpose with those who having specific expertise participating. For instance, I am preparing a document for the creation of a ballot which I tentatively call BML (ballot markup language). This would be used to create a ballot on any device which needed to present a ballot to a voter. It would be up to the receiver of this data to present the ballot to the voter in a manner appropriate for that device. There may be elements in the ballot specification or even in the actual ballot data stream that would not be applicable to all presentations. Perhaps there are certain data elements crucial to presentation of ballots for accessibility purposes. The beauty of XML is that these elements may be omitted or ignored if they are unnecessary. EML will be more of an over-all specification rather than an implimentation of a specific data structure. We could have VML for return votes, regXML for voter registration data, etc. These name are not set in stone and can be changed if we as a committee decide to do so.
I will be sure to address some of these concerns at the next teleconference meeting if they aren't resolved by email sooner. I will post the agenda at least 1 week prior to the next meeting for reeview and comment.
-----Original Message-----
From: Thom Wysong [mailto:]
Sent: Thursday, May 24, 2001 12:09 PM
To:
Subject: EML Clarifying Questions
In thinking over what we have covered during our first nine days in
existence as a committee, I've sensed that we may not all be on the same
page in terms of what we feel the direction and scope of EML should be. I
thought it'd be worthwhile to pose a few questions that will hopefully get
everyone's views on the table. Then we can decide what the overall best
direction and scope will be.
----------
The purpose of our committee is listed on the Election Services committee
home page (http://www.oasis-open.org/committees/election/index.shtml). It
is "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".
I find it interesting that the stated purpose of the committee focuses
strictly on vendor-to-vendor and vendor-to-client relationships within the
elections community. I hadn't noticed this before. I had been working under
the assumption that EML would be more broadly focused on providing value
anywhere in the elections community that it could.
It's worth noting that direct
election-administrator-to-election-administrator,
election-office-to-election-office, candidate-to-election-office,
agency-to-agency, jurisdiction-to-jurisdiction, and
election-office-to-voter data interchange (among others) are not covered by
our committee's stated purpose.
An initial stated purpose for the committee obviously needed to be
developed to help define what the committee would be working on. However,
since this initial stated purpose was developed before the committee ever
met, it makes me wonder if it's within our powers as a committee to alter
our stated purpose now that we're together. Does anyone know if this would
be within the "official rules" of OASIS?
If it is within our powers to do this, a few questions would need to be
addressed. One is what are the possibilities? What would we change it to?
Another is what's in the best interest of the committee? What's in the
best interest of the elections community? What will increase EML's chances
of being widely adopted? And finally, is there sufficient support on the
committee to alter our stated purpose?
----------
Another issue that would be beneficial to explicitly clarify is what voting
methods and voting technologies are we targeting EML to be useable by?
Voting methods include paper ballot, lever machine, punch card, optical
scan, electronic, Internet, and telephone.
It would be logical to assume that only fully electronic voting systems
would be able to make use of EML. This would include electronic, Internet,
and telephone voting systems. And would exclude paper ballots, lever
machines, punch cards, and optical scan voting systems.
However, it seems to me that jurisdictions that use paper and mechanical
voting systems could make use of EML to a limited degree. The recount of
Florida's 171,000 undervoted and overvoted ballots from the November 2000
election (http://recount.usatoday.com) is an example of this. While there
were many groups who would have liked to view and analyze those ballots,
because they were only in paper form, re-counters had to be physically
present as the ballots where handled one by one. Substantial financing was
required to afford this recount effort and therefore very few groups were
able to participate.
However, the re-counters could have created an electronic representation of
the punch card ballots as they processed through them - designating how
many "corners" of which chads where still connected, which chads were
"dimpled", etc. Then the file containing the electronic representation of
those ballots could be posted on the Internet. Any group wishing to analyze
the ballots could do so for substantially less cost than it would take to
process through the physical ballots in person. Additionally, if the
ballots were represented in a standard xml format, computer programs would
be able to analyze them from a hundred different angles.
Currently there is no standard way of representing punch card or optically
scanned ballots in electronic format. However, it would not be difficult to
create this. It's just a matter of whether it's inside the scope of our
committee or not.
I'm not sure if anyone else on the committee sees a value in creating xml
elements for voting systems that are not purely electronic. I'd be
interested in hearing everyone's comments on this.
----------
Yet another issue I think would be worth discussing is whether **all**
elements of EML will need to be useable by **all** targeted voting systems?
Or, will EML contain specialized subsets of elements that may be useable to
some voting systems, but not to others?
This question came to mind when the brief discussion on ballot presentation
occurred during our first meeting. It seemed to me that those who objected
to tackling presentation issues may have been assuming that all voting
systems would have to be able to successfully handle all
presentation-related elements. Since no explanation was given for the
objections, I may be entirely wrong in my interpretation of the situation.
However, regardless of whether or not my understanding was correct, it
seems that it would be worthwhile for us to decide whether EML is to be
single set of xml elements useable by all targeted voting methods? Or, if
we will create special subsets of elements that are useable by only a
subset of the targeted voting methods?
----------
After the above matters are discussed, I tend to think it would be
beneficial for us to lay out an explicit set of simple parameters or
requirements that would guide the committee's future work.
As a part of this, it would seem beneficial to list any scenarios that,
ideally, would involve the use of EML. These parameters and usage scenarios
would help to keep everyone going in the same direction.
----------
I would also like to present some comments and questions on presentation
and accessibility issues. However, this email is long enough. I'll send
those thoughts out separately.
Thank you for your time. I look forward to reading everyone's comments.
-Thom
