----- Forwarded Message ----
From: Richard J Cardone <richcar@us.ibm.com>
To: election-services-comment@lists.oasis-open.org
Sent: Tuesday, 6 May, 2008 5:22:25 PM
Subject: [election-services-comment] Comment on EML Structure
As a new user of EML 5.0, I wanted to run the EML schema files through
Apache Xmlbeans or JAXB to generate Java bindings for EML documents. The
generated Java classes would provide a higher level interface than that of
SAX or DOM, both of which force applications to deal directly with XML.
Unfortunately, many of the EML schema files define the same top-level
element, <EML>, which complicates the use of code generating tools.
For example, 440-castvote documents and 410-ballots documents are both
required to start with an <EML> element. Applications cannot easily
generate language bindings for both types of documents together because
name conflict errors will occur during generation. The language bindings
could be generated separately for each EML schema, but the total size of
generated code could easily get out of hand because of the many
definitions duplicated in each library. In addition to the <EML> name
conflict, there are other name conflicts that cause problems, such as the
definition of <Result> elements in 120-interdb and 520-result.
It would be nice if EML 6.0 could better accommodate the use of automated
tools like language binding generators, but maintaining backwards
compatibility might be a challenge. In the meantime, I wrote a utility
program, EML50Combine, that allows users to select which EML 5.0 schema
files should be merged into a single schema file. After EML50Combine
runs, the combined schema file
contains the definitions of all the
selected EML schemas. The combined schema file can then be inputted into
a language binding generator like Apache Xmlbeans to generate classes for
all the definitions it contains.
Documentation and code for EML50Combine can be found at
https://sourceforge.net/projects/eml50combine.
Rich Cardone