RE: [election-services] Language Binding Generators

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

David,

I don't remember exactly how customized
name mapping is done in Xmlbeans, but I think it involves the use of a
poorly documented configuration file.  I also believe JAXB provides
a way to specify non-default class name mappings, but again I try to avoid
these complications whenever possible.  The v6 effort offers us an
opportunity to make EML schemas generally easier to use with code generators.
 My argument for considering at this time a change to the top level
element names in EML schemas goes like this:

1. The top level element in an XML document
should reflect the contents of that document.  For example, it's reasonable
for the top level element in a purchase order document to be <PurchaseOrder>.
 Likewise, it's reasonable for the top level element in an EML ballots
document to be <EMLBallots> (or something similar).  In a sense,
it's misleading that dozens of different documents start with the <EML>
element even though their content and use are unrelated.   

2. The use of language binding generators
is simplified when different schemas define different top level elements.
 These generators are valuable because they remove much of the drudgery
and pitfalls of parsing, reading, and writing complex XML documents, especially
when compared to technologies like SAX and DOM.  By using different
top level element names, generators can use their default name mapping
algorithms without causing name conflicts.  Using the default name
mapping reduces the burden on developers and generally simplifies applications.
 Also, different generators are going to have different levels of
support for name customization and it would be nice to avoid the whole
issue.  

3. If the installed base of EML 5.0
isn't prohibitively large, then breaking upward compatibility to EML 6.0
by renaming top level elements to be more descriptive may be worth it.
 If we don't do it now, it probably will never get done.  I don't
know if any other v6 change breaks upward compatibility (i.e., requires
code changes in applications that use EML 5.0), but the level of near-term
disruption needs to be weighed against long-term payoff. 

Rich