Comment on EML Structure

[Richard J Cardone <richcar@us.ibm.com>]

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